From mary.ietf.barnes@gmail.com Mon Oct 1 05:40:59 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 AC0FA11E8108 for ; Mon, 1 Oct 2012 05:40:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=-0.565, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5ghH9wyCRRD for ; Mon, 1 Oct 2012 05:40:58 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCA411E810E for ; Mon, 1 Oct 2012 05:40:57 -0700 (PDT) Received: by lbok13 with SMTP id k13so4477050lbo.31 for ; Mon, 01 Oct 2012 05:40:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=9y6KdYGEHg8sOJrN9wpJdV+YSU3Qw/O8XMbqzx2kIk4=; b=SavFWXdNgwodAK1HPWbC6cc3VmBK1AS+kbJW5q2On5778dcpW3M1C/fph7Sp2nvo7D zyH05eMqn2jLMNSFi778Xa3rq90vSWLO/JoDCkeAf1+ONtxdXWlSUeTCignLZuXesQx2 31guQ/15r6bZ8UwH3Ptl4UpNCYz0XFd6SwTIN0FFuOhv9MdINiAit5vDtYOGwxxZrKp9 qX67l1CWAmbdqH2DTLxzRCjQoMRnNBEkUOT/VzXCwh7GeDNCdXrUBRFGy8qNAC0fVcy7 i+3Q3g72rJcaa9I8NknbEd3WxSlK0S9hvogF6c5clMyEF7jseZceLttXrmcRUpd3PDpV zK4g== MIME-Version: 1.0 Received: by 10.152.114.3 with SMTP id jc3mr11752744lab.11.1349095257000; Mon, 01 Oct 2012 05:40:57 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Mon, 1 Oct 2012 05:40:56 -0700 (PDT) Date: Mon, 1 Oct 2012 07:40:56 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d04088c7f8fcb5c04cafeb79c Cc: Roberta Presta Subject: [clue] Today's Design Team call Topic: CLUE schema definition proposal 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, 01 Oct 2012 12:40:59 -0000 --f46d04088c7f8fcb5c04cafeb79c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, In case you missed this thread, this will be the topic of today's meeting. Note, that we moved to Monday based on the doodle poll. The details on the wiki (it's the same information): http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Regards, Mary. ---------- Forwarded message ---------- From: Mary Barnes Date: Thu, Sep 27, 2012 at 4:01 PM Subject: Re: [clue] CLUE schema definition proposal To: Paul Kyzivat Cc: clue@ietf.org I think it would be really good to have some discussion of this on Monday's design team call as well. Mary. On Thu, Sep 27, 2012 at 3:03 PM, Paul Kyzivat wrote= : > Simon, Roberta, > > Thank you! Thank you! Thank you!!!! > > We really need this and until now it seemed we had nobody with the > knowledge, cycles, and interest to do it. > > EVERYBODY: Please review this carefully and comment on things that don't > agree with your understanding. > > I don't expect this to be "right" initially. One of the primary values it > has is that it gives a formal syntax, rather than a vague one. So it is > easier for someone to decide if it agrees with their understanding. So I > expect review and discussion of this to result in a feedback loop with > refinements to both this syntax and the framework. > > I will do a review myself. I expect I will do it a bit at a time, sending > comments/questions as I go. I know enough XML to read and understand this= , > but not enough to write such a schema correctly, with good style and > according to current best practice. > > Thanks, > Paul > > > On 9/27/12 10:37 AM, Simon Pietro Romano wrote: > >> Dear all, >> >> together with Roberta Presta, I have lately tried to get in synch with >> the current state of the art in CLUE. In the next few days, we're going >> to provide you with some feedback about both the framework and the data >> model. >> In the meantime, we have started to work on a schema definition for >> CLUE, which has been included in a straw-man draft proposal that you can >> find on-line at the following URL: >> >> http://www.ietf.org/id/draft-**presta-clue-data-model-schema-**00.txt >> >> We hope this can foster discussion and prove useful for completing the >> on-going work. As a first, very high level comment, we think that the >> framework document might be somehow restructured in order to just >> contain the >> overall description of the CLUE architecture and components, without >> delving into the details associated with the data structures. On the >> other hand, a new document might be proposed, which basically merges the >> already existing >> data model draft from Allyn and Andy >> (http://tools.ietf.org/html/**draft-romanow-clue-data-model-**01) >> and the >> 'schema definition' draft we are working on. If this sounds reasonable >> to the WG, we might then also add some more information >> to the current call flows documents >> (http://tools.ietf.org/html/**draft-romanow-clue-call-flow-**02and >> http://tools.ietf.org/html/**draft-kyzivat-clue-**telemedical-callflow-0= 1 >> ), >> basically showing the exact content of the CLUE messages (and >> transported data). For this last part, we might work on automatically >> generating CLUE-compliant data structures, starting from the schema >> definition, in much the same way as we did for both XCON and MEDIACTRL >> in the past. >> >> If you think this is worth discussing, we can talk about the details >> during next Monday's conference call. >> >> Cheers, >> >> Simon and Roberta >> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> >> (_/ >> >> >> >> >> >> >> >> ______________________________**_________________ >> 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 > --f46d04088c7f8fcb5c04cafeb79c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

In case you missed this thread, this will be the= topic of today's meeting. =A0Note, that we moved to Monday based on th= e doodle poll. The details on the wiki (it's the same information):

<= /div>
Regards,
Mary.

------= ---- Forwarded message ----------
From: Mary Barnes <<= a href=3D"mailto:mary.ietf.barnes@gmail.com">mary.ietf.barnes@gmail.com= >
Date: Thu, Sep 27, 2012 at 4:01 PM
Subject: Re: [clue] CL= UE schema definition proposal
To: Paul Kyzivat <pkyzivat@alum= .mit.edu>
Cc: clue@ietf.org<= br>

I think it would be really good to have some discussion of this = on Monday's design team call as well.

Mary.=A0


On Thu, Sep 27, 2012 at 3:03 PM, Paul Kyzivat <<= a href=3D"mailto:pkyzivat@alum.mit.edu" target=3D"_blank">pkyzivat@alum.mit= .edu> wrote:
Simon, Roberta,

Thank you! Thank you! Thank you!!!!

We really need this and until now it seemed we had nobody with the knowledg= e, cycles, and interest to do it.

EVERYBODY: Please review this carefully and comment on things that don'= t agree with your understanding.

I don't expect this to be "right" initially. One of the prima= ry values it has is that it gives a formal syntax, rather than a vague one.= So it is easier for someone to decide if it agrees with their understandin= g. So I expect review and discussion of this to result in a feedback loop w= ith refinements to both this syntax and the framework.

I will do a review myself. I expect I will do it a bit at a time, sending c= omments/questions as I go. I know enough XML to read and understand this, b= ut not enough to write such a schema correctly, with good style and accordi= ng to current best practice.

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


On 9/27/12 10:37 AM, Simon Pietro Romano wrote:
Dear all,

together with Roberta Presta, I have lately tried to get in synch with
the current state of the art in CLUE. In the next few days, we're going=
to provide you with some feedback about both the framework and the data
model.
In the meantime, we have started to work on a schema definition for
CLUE, which has been included in a straw-man draft proposal that you can find on-line at the following URL:

http://www.ietf.org/id/draft-presta-clue-data-m= odel-schema-00.txt

We hope this can foster discussion and prove useful for completing the
on-going work. As a first, very high level comment, we think that the
framework document might be somehow restructured in order to just
contain the
overall description of the CLUE architecture and components, without
delving into the details associated with the data structures. On the
other hand, a new document might be proposed, which basically merges the already existing
data model draft from Allyn and Andy
(http://tools.ietf.org/html/draft-romanow-clue-data-m= odel-01) and the
'schema definition' draft we are working on. If this sounds reasona= ble
to the WG, we might then also add some more information
to the current call flows documents
(http://tools.ietf.org/html/draft-romanow-clue-call-fl= ow-02 and
http://tools.ietf.org/html/draft-kyzivat-cl= ue-telemedical-callflow-01),
basically showing the exact content of the CLUE messages (and
transported data). For this last part, we might work on automatically
generating CLUE-compliant data structures, starting from the schema
definition, in much the same way as we did for both XCON and MEDIACTRL
in the past.

If you think this is worth discussing, we can talk about the details
during next Monday's conference call.

Cheers,

Simon and Roberta


=A0 =A0 =A0 =A0_\\|//_
=A0 =A0 =A0 =A0( O-O )
=A0 =A0 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~<= br> Simon Pietro Romano
Universita' di Napoli Federico II
=A0 =A0 =A0 Computer Engineering Department
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Phone: +39 081 7683823 -- Fax: +3= 9 081 7683816
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 e-mail: spromano@unina.it
<mailto:spromano@= unina.it>


=A0 =A0 =A0<<Molti mi dicono che lo scoraggiamento =CB l'alibi de= gli
=A0 =A0 =A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte= .
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 oooO
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\_) = =A0 =A0 =A0 =A0 =A0) /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (_/






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


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


--f46d04088c7f8fcb5c04cafeb79c-- From pkyzivat@alum.mit.edu Mon Oct 1 08:31:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E5C81F0D1D for ; Mon, 1 Oct 2012 08:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.392 X-Spam-Level: X-Spam-Status: No, score=-0.392 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8jhQArTlTee for ; Mon, 1 Oct 2012 08:31:57 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id E777F1F0D1B for ; Mon, 1 Oct 2012 08:31:56 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta03.westchester.pa.mail.comcast.net with comcast id 5p6f1k00R0QuhwU53rY0rx; Mon, 01 Oct 2012 15:32:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id 5rSX1k00r3ZTu2S3NrSXis; Mon, 01 Oct 2012 15:26:31 +0000 Message-ID: <5069B63F.8060608@alum.mit.edu> Date: Mon, 01 Oct 2012 11:26:55 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 15:31:57 -0000 I posted my notes from the design team meeting today on the wiki. You can look at them at: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121001.txt The entire meeting was spent discussing whether the spatialDescription element in the mediaCaptureType should be optional. This was really a discussion about the framework rather than the schema, because the schema is simply representing what the framework called for. I don't think we reached a conclusion. Thanks, Paul From mary.ietf.barnes@gmail.com Mon Oct 1 09:15: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 A477721F87B5 for ; Mon, 1 Oct 2012 09:15:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=-0.553, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H09rIE8Ub7Fr for ; Mon, 1 Oct 2012 09:15:40 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C097D21F87B2 for ; Mon, 1 Oct 2012 09:15:39 -0700 (PDT) Received: by lbok13 with SMTP id k13so4741761lbo.31 for ; Mon, 01 Oct 2012 09:15:35 -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=smy1UfVsZIlRFHA70Bzg6mWNMQHFeFai6Jmavrwogy4=; b=MqzduTygjddyYYaHi8PRXWnGZa498mlNGifzwGbAhSJxA6akjDVrw/ab+nbIatTHHC ezDmaCbM7k1x8Z7UlspPPUzGUGLnnPACkcHMtHNMDzLXt9lHVAYJcueDvAuWassX68rW DhKAG+ZaELHfs+Y5FzudfVRxZRMx69Y652UsTTG/8QpLIYJeZyyp0dGSNz3T1+ZGwstz iydGz10Cvs5pV1YlSrAof3uHef9CYs6gNIKNZC5katx4YCsioiK3l0uqzie6u4RPn2ui ALJSAeZ3uXWKObpJzRXnX9CPwJUf1+NIZeM4gbgZRLxA7rLx1YqXWrqKJkKJooNZoC3O r5rg== MIME-Version: 1.0 Received: by 10.112.43.137 with SMTP id w9mr5374632lbl.134.1349108135580; Mon, 01 Oct 2012 09:15:35 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Mon, 1 Oct 2012 09:15:35 -0700 (PDT) In-Reply-To: <5069B63F.8060608@alum.mit.edu> References: <5069B63F.8060608@alum.mit.edu> Date: Mon, 1 Oct 2012 11:15:35 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec54a32c02f57ab04cb01b7af Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 16:15:40 -0000 --bcaec54a32c02f57ab04cb01b7af Content-Type: text/plain; charset=ISO-8859-1 I thought the conclusion was that we needed to have the spatialDescription in the mediaCaptureType in the schema as mandatory (as opposed to the current minoccurs="0"). Then, define the spatialDescriptionType to have two (either/or) subtypes under that: 1) the existing schema 2)a schema allowing less specific information in cases where the entirety of the spatial description is not required. I don't know right off what the XML schema for that might be, but we can discuss that on the list. I don't think we decided exactly how/if that might impact the framework, since the framework doesn't necessarily require that a media capture have spatial information. Mary. On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat wrote: > I posted my notes from the design team meeting today on the wiki. > You can look at them at: > > http://trac.tools.ietf.org/wg/**clue/trac/attachment/wiki/** > Design-Team/minutes-121001.txt > > The entire meeting was spent discussing whether the spatialDescription > element in the mediaCaptureType should be optional. This was really a > discussion about the framework rather than the schema, because the schema > is simply representing what the framework called for. > > I don't think we reached a conclusion. > > Thanks, > Paul > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --bcaec54a32c02f57ab04cb01b7af Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I thought the conclusion was that we needed to have the spatialDescription = in the mediaCaptureType in the schema as mandatory (as opposed to the curre= nt minoccurs=3D"0"). =A0Then, define the spatialDescriptionType t= o have two (either/or) subtypes under that: 1) the existing schema 2)a sche= ma allowing less specific information in cases where the entirety of the sp= atial description is not required. =A0I don't know right off what the X= ML schema for that might be, but we can discuss that on the list.

I don't think we decided exactly how/if that might = impact the framework, since the framework doesn't necessarily require t= hat a media capture have spatial information.

Mary.=A0

On Mon, Oct 1, 2012 at 10:26 AM,= Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
I posted my notes from the design team meeting today on the wiki.
You can look at them at:

http://trac.tools.ietf.org/wg/= clue/trac/attachment/wiki/Design-Team/minutes-121001.txt

The entire meeting was spent discussing whether the spatialDescription elem= ent in the mediaCaptureType should be optional. This was really a discussio= n about the framework rather than the schema, because the schema is simply = representing what the framework called for.

I don't think we reached a conclusion.

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

--bcaec54a32c02f57ab04cb01b7af-- From pkyzivat@alum.mit.edu Mon Oct 1 09:17:05 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 1A7CE21F87BF for ; Mon, 1 Oct 2012 09:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.393 X-Spam-Level: X-Spam-Status: No, score=-0.393 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVHi3cJQ0r+E for ; Mon, 1 Oct 2012 09:17:04 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 5473121F87B9 for ; Mon, 1 Oct 2012 09:17:04 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id 5mSw1k00616LCl053sH8rT; Mon, 01 Oct 2012 16:17:08 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 5sBi1k00J3ZTu2S3SsBilu; Mon, 01 Oct 2012 16:11:42 +0000 Message-ID: <5069C0D3.9000908@alum.mit.edu> Date: Mon, 01 Oct 2012 12:12:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: CLUE References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> , <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCB@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCB@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" 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, 01 Oct 2012 16:17:05 -0000 Including all of clue. On 10/1/12 11:10 AM, Christer Holmberg wrote: > Hi Mary, > > Maybe I was calling in one hour too late, because I assumed it was going to start at 9am (Pacific). It was 9am Central (Texas, where Mary lives) time. IOW, only the day changed (to Monday), the time remained the same. We commented on the call today that we must be careful in the coming weeks as daylight savings time will be ending at different times in different geographies. The intent is to leave the time at 9am Central Time. So if my time zone arithmetic is right it starts at 9:00 UTC-5 (14:00 UTC) from now through October, and will start at 9:00 UTC-6 (15:00 UTC) in November and beyond. Thanks, Paul From christer.holmberg@ericsson.com Mon Oct 1 09:22: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 7D88B21F89B6 for ; Mon, 1 Oct 2012 09:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FnsU5fZ1Sh-6 for ; Mon, 1 Oct 2012 09:22:01 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 0ABD621F89B4 for ; Mon, 1 Oct 2012 09:22:00 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-10-5069c327c9f7 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 87.3F.17130.723C9605; Mon, 1 Oct 2012 18:21:59 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 1 Oct 2012 18:21:59 +0200 From: Christer Holmberg To: Paul Kyzivat , CLUE Date: Mon, 1 Oct 2012 18:18:49 +0200 Thread-Topic: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" Thread-Index: Ac2f8DchldHw7fa3T5+YMf1w/GK8kgAADnZb Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCC@ESESSCMS0356.eemea.ericsson.se> References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> , <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCB@ESESSCMS0356.eemea.ericsson.se>, <5069C0D3.9000908@alum.mit.edu> In-Reply-To: <5069C0D3.9000908@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 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrFLMWRmVeSWpSXmKPExsUyM+Jvra764cwAg60HbSz2n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj+5UlTAVPuStOX/nJ3sC4jrOLkZNDQsBE Ys3NHkYIW0ziwr31bCC2kMApRom7XTVdjFxA9mxGiSurepi6GDk42AQsJLr/aYPUiAjYSczf cpUVJMwioCLxfS4TSFhYIEBia/M/RpCwiECgxIQXGhDVRhJHNzSDlfAKhEv0fZzEDDF9DrPE 057F7CAJTgEdiQt7G8HOYQQ65/upNWANzALiEreezGeCOFNAYsme88wQtqjEy8f/WCHqRSXu tK9nhKjXkViw+xMbhK0tsWzha2aIxYISJ2c+YZnAKDoLydhZSFpmIWmZhaRlASPLKkbh3MTM nPRyc73Uoszk4uL8PL3i1E2MwPg4uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgt ii8qzUktPsTIxMEp1cAYYHHeIsn9681Fum3rzs1gWjt3s67tjdLLfYc2slkc2Ru87wmTy0Ye S4fa5F4LCX5jlrnLfknvUAp5xc/MtOHX0QkXz/wqjfzoe2mVqdhsdokTZy2YpwnvmH34u9+T Agae1cH6Myc8TVF59LHyYrSlqP3UuD+v+g2+P17yfK7v9Zv/DXxsTinwKbEUZyQaajEXFScC ACov84pdAgAA Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" 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, 01 Oct 2012 16:22:06 -0000 Hi, I guess I'm messing up the time zones, so let my try again :) According to the Doodle poll, 10 am central would have been ok for everyone= (eventhough there were two "yellows", compared to one "yellow" at 9 am), s= o I assumed that was the time that had been picked (my misstake for not che= cking more carefully). Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Paul Kyziv= at [pkyzivat@alum.mit.edu] Sent: Monday, October 01, 2012 7:12 PM To: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team mee= ting" Including all of clue. On 10/1/12 11:10 AM, Christer Holmberg wrote: > Hi Mary, > > Maybe I was calling in one hour too late, because I assumed it was going = to start at 9am (Pacific). It was 9am Central (Texas, where Mary lives) time. IOW, only the day changed (to Monday), the time remained the same. We commented on the call today that we must be careful in the coming weeks as daylight savings time will be ending at different times in different geographies. The intent is to leave the time at 9am Central Time. So if my time zone arithmetic is right it starts at 9:00 UTC-5 (14:00 UTC) from now through October, and will start at 9:00 UTC-6 (15:00 UTC) in November and beyond. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From mary.ietf.barnes@gmail.com Mon Oct 1 09:28: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 D214D21F89BD for ; Mon, 1 Oct 2012 09:28:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.307 X-Spam-Level: X-Spam-Status: No, score=-103.307 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WxBiDhFmpzd for ; Mon, 1 Oct 2012 09:28:13 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88E21F8910 for ; Mon, 1 Oct 2012 09:28:11 -0700 (PDT) Received: by lbok13 with SMTP id k13so4757154lbo.31 for ; Mon, 01 Oct 2012 09:28:11 -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=xnEUB7x1q2OVL5eaS4QClMVw4ejvoKumdBCFvXKT21k=; b=iNEoLv/JojVifzPKtels/TR8GRGm4/HrSKYXoOEu4vTtFyR32MquAlJfSgkmFLKaza 3RXGBFaLsFjq8HNmsH2dpZHk4ryevJiyan6gxJtWysyEJJNy5rMtyUkv0wH+VPJW5M5M IQDH7WSjdrPYjc2aSQPR9700kCp3wD9dF4+cGFSkUqwAnzhP1Wc+ObzvQDDg8cdbSH3z Jik7a8F9e30QsMwIIRODFGTLxjFh8+QQYrJMxSBPx21UsE9SMYXp53bNS01GgvD+h42q LS7ooj3AkmAw6v615etjexM3wThwJANSLM1IWOseXjqxd0foHH73rH60R70nBrhcu4MJ PVvw== MIME-Version: 1.0 Received: by 10.152.106.81 with SMTP id gs17mr12449304lab.2.1349108891098; Mon, 01 Oct 2012 09:28:11 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Mon, 1 Oct 2012 09:28:11 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCC@ESESSCMS0356.eemea.ericsson.se> References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCB@ESESSCMS0356.eemea.ericsson.se> <5069C0D3.9000908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCC@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 1 Oct 2012 11:28:11 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=f46d0408d583379fbe04cb01e4ff Cc: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" 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, 01 Oct 2012 16:28:14 -0000 --f46d0408d583379fbe04cb01e4ff Content-Type: text/plain; charset=ISO-8859-1 When I last looked at the doodle, you had not responded. Espen was a maybe, however, he wasn't even on today's call. So, I will post a note and see if folks are okay to make it an hour later. Mary. On Mon, Oct 1, 2012 at 11:18 AM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I guess I'm messing up the time zones, so let my try again :) > > According to the Doodle poll, 10 am central would have been ok for > everyone (eventhough there were two "yellows", compared to one "yellow" at > 9 am), so I assumed that was the time that had been picked (my misstake for > not checking more carefully). > > Regards, > > Christer > > ________________________________________ > From: clue-bounces@ietf.org [clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat [pkyzivat@alum.mit.edu] > Sent: Monday, October 01, 2012 7:12 PM > To: CLUE > Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team > meeting" > > Including all of clue. > > On 10/1/12 11:10 AM, Christer Holmberg wrote: > > Hi Mary, > > > > Maybe I was calling in one hour too late, because I assumed it was going > to start at 9am (Pacific). > > It was 9am Central (Texas, where Mary lives) time. IOW, only the day > changed (to Monday), the time remained the same. > > We commented on the call today that we must be careful in the coming > weeks as daylight savings time will be ending at different times in > different geographies. The intent is to leave the time at 9am Central Time. > > So if my time zone arithmetic is right it starts at 9:00 UTC-5 (14:00 > UTC) from now through October, and will start at 9:00 UTC-6 (15:00 UTC) > in November and beyond. > > 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 > --f46d0408d583379fbe04cb01e4ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When I last looked at the doodle, you had not responded. =A0Espen was a may= be, however, he wasn't even on today's call. =A0So, I will post a n= ote and see if folks are okay to make it an hour later. =A0

<= div> Mary.=A0

On Mon, Oct 1, 2012 at 11:18 AM,= Christer Holmberg <christer.holmberg@ericsson.com> wrote:
Hi,

I guess I'm messing up the time zones, so let my try again :)

According to the Doodle poll, 10 am central would have been ok for everyone= (eventhough there were two "yellows", compared to one "yell= ow" at 9 am), so I assumed that was the time that had been picked (my = misstake for not checking more carefully).

Regards,

Christer

________________________________________
From: clue-bounces@ietf.org [<= a href=3D"mailto:clue-bounces@ietf.org">clue-bounces@ietf.org] On Behal= f Of Paul Kyzivat [pkyzivat@alum.m= it.edu]
Sent: Monday, October 01, 2012 7:12 PM
To: CLUE
Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team = =A0 meeting"

Including all of clue.

On 10/1/12 11:10 AM, Christer Holmberg wrote:
> Hi Mary,
>
> Maybe I was calling in one hour too late, because I assumed it was goi= ng to start at 9am (Pacific).

It was 9am Central (Texas, where Mary lives) time. IOW, only the day
changed (to Monday), the time remained the same.

We commented on the call today that we must be careful in the coming
weeks as daylight savings time will be ending at different times in
different geographies. The intent is to leave the time at 9am Central Time.=

So if my time zone arithmetic is right it starts at 9:00 UTC-5 (14:00
UTC) from now through October, and will start at 9:00 UTC-6 (15:00 UTC)
in November and beyond.

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

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

--f46d0408d583379fbe04cb01e4ff-- From christer.holmberg@ericsson.com Mon Oct 1 10:32:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A619121F899C for ; Mon, 1 Oct 2012 10:32:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.101 X-Spam-Level: X-Spam-Status: No, score=-6.101 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69xprF0y2ObG for ; Mon, 1 Oct 2012 10:32:47 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 97C5321F8992 for ; Mon, 1 Oct 2012 10:32:46 -0700 (PDT) X-AuditID: c1b4fb2d-b7fea6d000002ccb-57-5069d3bdf3d4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D8.78.11467.DB3D9605; Mon, 1 Oct 2012 19:32:45 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0256.eemea.ericsson.se ([153.88.115.96]) with mapi; Mon, 1 Oct 2012 19:32:45 +0200 From: Christer Holmberg To: Mary Barnes Date: Mon, 1 Oct 2012 19:31:01 +0200 Thread-Topic: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" Thread-Index: Ac2f8tMSFRC8zKygRmqMsxeMat+ITAAB7QOH Message-ID: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCE@ESESSCMS0356.eemea.ericsson.se> References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCB@ESESSCMS0356.eemea.ericsson.se> <5069C0D3.9000908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCC@ESESSCMS0356.eemea.ericsson.se>, In-Reply-To: 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+NgFnrMLMWRmVeSWpSXmKPExsUyM+Jvre7ey5kBBg+eKlvsP3WZ2eLz/v3M Fis2HGB1YPb4+/4Dk8fOWXfZPZYs+ckUwBzFZZOSmpNZllqkb5fAlfHx32q2gjkiFb2vHrI2 MG4R6GLk5JAQMJFY8mUiM4QtJnHh3nq2LkYuDiGBU4wS065MZ4Jw5jNKfJzwnrWLkYODTcBC ovufNkiDiICOxLfPb9lAbGYBO4lvEzeA2SwCKhINC96wgNjCAgESG6/dYYGoD5S48XAFK4Rt JLGo8x3YYl6BcIldxxewQuzawCKx8sslsCJOoIYdz+aCNTMCXff91BomiGXiEreezGeCuFpA Ysme81AfiEq8fPyPFaJeVOJO+3pGiHo9iRtTp0Adqi2xbOFrqMWCEidnPmGZwCg2C8nYWUha ZiFpmYWkZQEjyypG4dzEzJz0ckO91KLM5OLi/Dy94tRNjMCIOrjlt+4OxlPnRA4xSnOwKInz ciXt9xcSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXA6LnqRtuf4vMHPfV3uko+y4267lVWxBbA KeWwi62xa3Hy6tmu/t2Sd9oXRUf9EWBa581mdmbubs0vr68/XrBxd6rKa5H2gm0t268ePXnx 50H3V8cCrkYXPFxlfTZxd/kNrhWHVP4+Z7npKr6y7lDu85bSPTsS/7NuXHMv8HWuo55P6WzV QjtpHSWW4oxEQy3mouJEAGljcAZ2AgAA Cc: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" 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, 01 Oct 2012 17:32:48 -0000 Hi, I believe I responded before your deadline. I don't want to cause any trouble. I just thought the whole reason to re-sc= hedule was to try to find a time that fits everyone :) Regards, Christer ________________________________ From: Mary Barnes [mary.ietf.barnes@gmail.com] Sent: Monday, October 01, 2012 7:28 PM To: Christer Holmberg Cc: Paul Kyzivat; CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeti= ng" When I last looked at the doodle, you had not responded. Espen was a maybe= , however, he wasn't even on today's call. So, I will post a note and see = if folks are okay to make it an hour later. Mary. On Mon, Oct 1, 2012 at 11:18 AM, Christer Holmberg > wrote: Hi, I guess I'm messing up the time zones, so let my try again :) According to the Doodle poll, 10 am central would have been ok for everyone= (eventhough there were two "yellows", compared to one "yellow" at 9 am), s= o I assumed that was the time that had been picked (my misstake for not che= cking more carefully). Regards, Christer ________________________________________ From: clue-bounces@ietf.org [clue-bounces@iet= f.org] On Behalf Of Paul Kyzivat [pkyzivat@al= um.mit.edu] Sent: Monday, October 01, 2012 7:12 PM To: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team mee= ting" Including all of clue. On 10/1/12 11:10 AM, Christer Holmberg wrote: > Hi Mary, > > Maybe I was calling in one hour too late, because I assumed it was going = to start at 9am (Pacific). It was 9am Central (Texas, where Mary lives) time. IOW, only the day changed (to Monday), the time remained the same. We commented on the call today that we must be careful in the coming weeks as daylight savings time will be ending at different times in different geographies. The intent is to leave the time at 9am Central Time. So if my time zone arithmetic is right it starts at 9:00 UTC-5 (14:00 UTC) from now through October, and will start at 9:00 UTC-6 (15:00 UTC) in November and beyond. 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 spromano@unina.it Mon Oct 1 10:37:18 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 DE0CB1F0D0A for ; Mon, 1 Oct 2012 10:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGJbNwCcT+I6 for ; Mon, 1 Oct 2012 10:37:18 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id B82E31F0CCD for ; Mon, 1 Oct 2012 10:37:17 -0700 (PDT) Received: from [10.219.28.12] ([10.219.28.12]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q91HbBe4022508 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 1 Oct 2012 19:37:12 +0200 Message-ID: <5069D4BC.6010201@unina.it> Date: Mon, 01 Oct 2012 19:37:00 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <5069B63F.8060608@alum.mit.edu> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060503060804040905080104" Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Oct 2012 17:37:19 -0000 This is a multi-part message in MIME format. --------------060503060804040905080104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi all, first of all let me 'publicly' apologize for missing the call. Please find in-line our answers to your first comments on the schema file. > I thought the conclusion was that we needed to have the > spatialDescription in the mediaCaptureType in the schema as mandatory > (as opposed to the current minoccurs="0"). OK. No problem with this. Fixed in version -01 of the draft. > Then, define the spatialDescriptionType to have two (either/or) > subtypes under that: 1) the existing schema 2)a schema allowing less > specific information in cases where the entirety of the spatial > description is not required. I don't know right off what the XML > schema for that might be, but we can discuss that on the list. This has also been taken into account in version -01 of the draft, which also contains an ad hoc "diff" section that should help you track down the changes we made. So, please comment on such version from now on. In the meantime, we'll keep on working on our revision of the current documents and come back to you soon on this list. Looking forward to your comments and suggestions, Simon and Roberta > > I don't think we decided exactly how/if that might impact the > framework, since the framework doesn't necessarily require that a > media capture have spatial information. > > Mary. > > On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat > wrote: > > I posted my notes from the design team meeting today on the wiki. > You can look at them at: > > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121001.txt > > The entire meeting was spent discussing whether the > spatialDescription element in the mediaCaptureType should be > optional. This was really a discussion about the framework rather > than the schema, because the schema is simply representing what > the framework called for. > > I don't think we reached a conclusion. > > 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 -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ --------------060503060804040905080104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

first of all let me 'publicly' apologize for missing the call.
Please find in-line our answers to your first comments on the schema file.

I thought the conclusion was that we needed to have the spatialDescription in the mediaCaptureType in the schema as mandatory (as opposed to the current minoccurs="0"). 
OK. No problem with this. Fixed in version -01 of the draft.
Then, define the spatialDescriptionType to have two (either/or) subtypes under that: 1) the existing schema 2)a schema allowing less specific information in cases where the entirety of the spatial description is not required.  I don't know right off what the XML schema for that might be, but we can discuss that on the list.
This has also been taken into account in version -01 of the draft, which also contains an ad hoc "diff" section that should help you track down the changes we made. So, please comment on such version from now on.
In the meantime, we'll keep on working on our revision of the current documents and come back to you soon
on this list.

Looking forward to your comments and suggestions,

Simon and Roberta


I don't think we decided exactly how/if that might impact the framework, since the framework doesn't necessarily require that a media capture have spatial information.

Mary. 

On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
I posted my notes from the design team meeting today on the wiki.
You can look at them at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121001.txt

The entire meeting was spent discussing whether the spatialDescription element in the mediaCaptureType should be optional. This was really a discussion about the framework rather than the schema, because the schema is simply representing what the framework called for.

I don't think we reached a conclusion.

        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


-- 
                            _\\|//_
                            ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    Simon Pietro Romano
              Universita' di Napoli Federico II
                 Computer Science Department 
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano

    <<Molti mi dicono che lo scoraggiamento è l'alibi degli 
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                         oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                          \ (    (   )
                           \_)    ) /
                                 (_/
--------------060503060804040905080104-- From pkyzivat@alum.mit.edu Mon Oct 1 10:47:29 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 1F31111E8117 for ; Mon, 1 Oct 2012 10:47:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.395 X-Spam-Level: X-Spam-Status: No, score=-0.395 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JI26-HLp5YQ for ; Mon, 1 Oct 2012 10:47:28 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 95B8A11E80D5 for ; Mon, 1 Oct 2012 10:47:28 -0700 (PDT) Received: from omta09.westchester.pa.mail.comcast.net ([76.96.62.20]) by QMTA11.westchester.pa.mail.comcast.net with comcast id 5oiu1k0040SCNGk5BtnYF8; Mon, 01 Oct 2012 17:47:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta09.westchester.pa.mail.comcast.net with comcast id 5tir1k00e3ZTu2S3Vtirb3; Mon, 01 Oct 2012 17:42:51 +0000 Message-ID: <5069D603.2080902@alum.mit.edu> Date: Mon, 01 Oct 2012 13:42:27 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.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: [clue] Some comments on draft-presta-clue-data-model-schema-00 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, 01 Oct 2012 17:47:29 -0000 I read through the schema again making notes on things that seem worthy of discussion: ISTM that clueInfoType is an odd choice of name. I think this is really the type for the body of an advertisement, with the exception of some housekeeping related to the protocol, such as a sequence number. The configuration message will also contain some clue info, but not the same as this. There is a single mediaCaptures element in a clueInfoType, shared by all the captureScenes. This suggests that it is ok for a single mediaCapture to appear in multiple scenes. But that logically makes no sense. So ISTM that there ought to be a separate mediaCaptures element within each captureScene. That would also scope the names, so that references to a capture would need to be qualified by a reference to a scene. (So far there seem to be no references, but there will be in the configure message.) The element (within a mediaCaptureType) should probably be of a defined type rather than just a string. (We may still have more to discuss about what that type is.) Re captureAreaType: I agree with other comments that the labels for these points could be better. What we intend is that the four points describe a planar quadrilateral. It would be nice if the representation guaranteed that, though I can see no convenient way to ensure that. Is sceneAreaType really needed? Couldn’t the captureSceneType simply contain a captureAreaType and then the scale independently? Based on the interim, the WG has more work to do on switching policies, which is likely to affect the schema representation. Thanks, Paul (as individual) From mary.ietf.barnes@gmail.com Mon Oct 1 15:11:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 635BE1F0417 for ; Mon, 1 Oct 2012 15:11:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.313 X-Spam-Level: X-Spam-Status: No, score=-103.313 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIoyo7qyp2ZF for ; Mon, 1 Oct 2012 15:11:24 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC3B21F86C2 for ; Mon, 1 Oct 2012 15:11:23 -0700 (PDT) Received: by lbok13 with SMTP id k13so5097517lbo.31 for ; Mon, 01 Oct 2012 15:11:23 -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=y5KhgHjL6sKJhqc3NhRlhvePU8LBo0ONdiMWNg3ACfA=; b=dY/lefh7zF45IedHbrZf96zrYV3U3mqNpHUC4RovaGw2HXnhjWf3H6DLssrE3W4VWd bkewzQOaZgsKLVWQoB2NZdPzIGS9iFeKArhs53jCzL+9BYL5Rlt3tkYn10tCb3ZTo0G2 lUHNdkqjw1jQqxqd6BnBZOvIzV2099RseCwwy+mBxGUOzp8vDagHUDKy9H4O+CfzjAGD JFKRWJmevBQrxvtaiQGArk06/cHqBJgfFtZnjWpxHDYHKfGv2jc2LLPHzxogLu6VUzjF BrPG+snQ93ZzGoeHZYrvREuxNDqZrSb0Lp/skBYRmnytkSJ3Rx3m3CHNGe4JAg5kGWTD l1Ag== MIME-Version: 1.0 Received: by 10.112.24.74 with SMTP id s10mr5746352lbf.122.1349129482960; Mon, 01 Oct 2012 15:11:22 -0700 (PDT) Received: by 10.114.4.130 with HTTP; Mon, 1 Oct 2012 15:11:22 -0700 (PDT) In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCE@ESESSCMS0356.eemea.ericsson.se> References: <1257229063.2388580.1348184107825.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCB@ESESSCMS0356.eemea.ericsson.se> <5069C0D3.9000908@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCC@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FCE@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 1 Oct 2012 17:11:22 -0500 Message-ID: From: Mary Barnes To: Christer Holmberg Content-Type: multipart/alternative; boundary=90e6ba25e841967e8d04cb06af7d Cc: CLUE Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team meeting" 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, 01 Oct 2012 22:11:27 -0000 --90e6ba25e841967e8d04cb06af7d Content-Type: text/plain; charset=ISO-8859-1 So, I got the notification from doodle after the deadline. So, let's confuse everyone and move the meeting an hour out. I'll update the Webex meeting and send the new .ics so people can update their calendars. One very important thing to note is that Europe and the US (and maybe others) fall back sometime this month but not at the same time. So, I will leave the timezone math to you all. It will be 8am Pacific/10am Central. Espen - I hope this works okay for you since you were a maybe. Holler fast if it's not. Thanks, Mary. On Mon, Oct 1, 2012 at 12:31 PM, Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi, > > I believe I responded before your deadline. > > I don't want to cause any trouble. I just thought the whole reason to > re-schedule was to try to find a time that fits everyone :) > > Regards, > > Christer > > ________________________________ > From: Mary Barnes [mary.ietf.barnes@gmail.com] > Sent: Monday, October 01, 2012 7:28 PM > To: Christer Holmberg > Cc: Paul Kyzivat; CLUE > Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team > meeting" > > When I last looked at the doodle, you had not responded. Espen was a > maybe, however, he wasn't even on today's call. So, I will post a note and > see if folks are okay to make it an hour later. > > Mary. > > On Mon, Oct 1, 2012 at 11:18 AM, Christer Holmberg < > christer.holmberg@ericsson.com> > wrote: > Hi, > > I guess I'm messing up the time zones, so let my try again :) > > According to the Doodle poll, 10 am central would have been ok for > everyone (eventhough there were two "yellows", compared to one "yellow" at > 9 am), so I assumed that was the time that had been picked (my misstake for > not checking more carefully). > > Regards, > > Christer > > ________________________________________ > From: clue-bounces@ietf.org [ > clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat [pkyzivat@alum.mit.edu] > Sent: Monday, October 01, 2012 7:12 PM > To: CLUE > Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team > meeting" > > Including all of clue. > > On 10/1/12 11:10 AM, Christer Holmberg wrote: > > Hi Mary, > > > > Maybe I was calling in one hour too late, because I assumed it was going > to start at 9am (Pacific). > > It was 9am Central (Texas, where Mary lives) time. IOW, only the day > changed (to Monday), the time remained the same. > > We commented on the call today that we must be careful in the coming > weeks as daylight savings time will be ending at different times in > different geographies. The intent is to leave the time at 9am Central Time. > > So if my time zone arithmetic is right it starts at 9:00 UTC-5 (14:00 > UTC) from now through October, and will start at 9:00 UTC-6 (15:00 UTC) > in November and beyond. > > 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 > > --90e6ba25e841967e8d04cb06af7d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, I got the notification from doodle after the deadline. =A0 =A0So, let&#= 39;s confuse everyone and move the meeting an hour out. =A0I'll update = the Webex meeting and send the new .ics so people can update their calendar= s. =A0One very important thing to note is that Europe and the US (and maybe= others) fall back sometime this month but not at the same time. =A0So, I w= ill leave the timezone math to you all. =A0It will be 8am Pacific/10am Cent= ral. =A0 =A0

Espen - I hope this works okay for you since you were a mayb= e. =A0Holler fast if it's not. =A0

Thanks,
=
Mary.

On Mon, Oct 1, 2012 at 12:31 P= M, Christer Holmberg <christer.holmberg@ericsson.com><= /span> wrote:
Hi,

I believe I responded before your deadline.

I don't want to cause any trouble. I just thought the whole reason to r= e-schedule was to try to find a time that fits everyone :)

Regards,

Christer

________________________________
From: Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Monday, October 01, 2012 7:28 PM
To: Christer Holmberg
Cc: Paul Kyzivat; CLUE
Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design = team meeting"

When I last looked at the doodle, you had not responded. =A0Espe= n was a maybe, however, he wasn't even on today's call. =A0So, I wi= ll post a note and see if folks are okay to make it an hour later.

Mary.

On Mon, Oct 1, 2012 at 11:18 AM, Christer Holmberg <christer.holmb= erg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote: Hi,

I guess I'm messing up the time zones, so let my try again :)

According to the Doodle poll, 10 am central would have been ok for everyone= (eventhough there were two "yellows", compared to one "yell= ow" at 9 am), so I assumed that was the time that had been picked (my = misstake for not checking more carefully).

Regards,

Christer

________________________________________
From: clue= -bounces@ietf.org<mailto:clue-bounces@ietf.org> [clue-bounces@ietf.org<mailto:clue-bounces@ietf.org>] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu<mailto:pkyzivat@alum.mit.edu>]
Sent: Monday, October 01, 2012 7:12 PM
To: CLUE
Subject: Re: [clue] Doodle: Link for poll "CLUE WG weekly design team = =A0 meeting"

Including all of clue.

On 10/1/12 11:10 AM, Christer Holmberg wrote:
> Hi Mary,
>
> Maybe I was calling in one hour too late, because I assumed it was goi= ng to start at 9am (Pacific).

It was 9am Central (Texas, where Mary lives) time. IOW, only the day
changed (to Monday), the time remained the same.

We commented on the call today that we must be careful in the coming
weeks as daylight savings time will be ending at different times in
different geographies. The intent is to leave the time at 9am Central Time.=

So if my time zone arithmetic is right it starts at 9:00 UTC-5 (14:00
UTC) from now through October, and will start at 9:00 UTC-6 (15:00 UTC)
in November and beyond.

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

_______________________________________________
clue mailing list
clue@ietf.org&= lt;mailto:clue@ietf.org<= /a>>
https://www.ietf.org/mailman/listinfo/clue
_______________________________________________
clue mailing list
clue@ietf.org&= lt;mailto:clue@ietf.org<= /a>>
ht= tps://www.ietf.org/mailman/listinfo/clue


--90e6ba25e841967e8d04cb06af7d-- From mary.ietf.barnes@gmail.com Thu Oct 4 11:57:34 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 22D9F11E80E4 for ; Thu, 4 Oct 2012 11:57:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.324 X-Spam-Level: X-Spam-Status: No, score=-103.324 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qo3VI47VhVZ for ; Thu, 4 Oct 2012 11:57:33 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFF6611E80E0 for ; Thu, 4 Oct 2012 11:57:25 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so757708lbo.31 for ; Thu, 04 Oct 2012 11:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=18+BmhTmMU3PoyB2Jj/bHOLaX74CsENuI7lP1LUhiEQ=; b=nbSYYafvMnVHJJiC2kbq8xquenGEIeE1k7uz8nYmrFL5ZFttAZka81x791dmiBYDt1 B6paQTPPWYBwte+fmjssgpnoqrNfXJaEa1VOGHL46CliAgy9rsKnIoGHcqNBar3jyt3n mmOJ2Glm7Vw1GVPHRrssfQfDjyihnqlpN1lLjZzfwcbMhQVsUZse+uVZKmcm8d8ubCXO BAuGFMDJoHCyzRV73k2p7CDc8bn/kCSAEiVXc+S3/s5P1YMgJnrzzr0KEC0EXBCh5lOE kmb+wy5DQzqwbITR1Hhn50fztv5VwovMQ4gcPDhyMoYseSO09Dv31nbECQ5eT716pUbc 4r1w== MIME-Version: 1.0 Received: by 10.152.113.165 with SMTP id iz5mr4853362lab.48.1349377044890; Thu, 04 Oct 2012 11:57:24 -0700 (PDT) Received: by 10.114.25.102 with HTTP; Thu, 4 Oct 2012 11:57:24 -0700 (PDT) In-Reply-To: <20121004182934.25538.10432.idtracker@ietfa.amsl.com> References: <20121004182934.25538.10432.idtracker@ietfa.amsl.com> Date: Thu, 4 Oct 2012 13:57:24 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0408393b6dc62604cb40535c Subject: [clue] Fwd: clue - Requested sessions have been scheduled for IETF 85 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Oct 2012 18:57:34 -0000 --f46d0408393b6dc62604cb40535c Content-Type: text/plain; charset=ISO-8859-1 FYI. As *always* these slots are subject to change. Mary ---------- Forwarded message ---------- From: "IETF Secretariat" Date: Thu, Oct 4, 2012 at 1:29 PM Subject: clue - Requested sessions have been scheduled for IETF 85 To: mary.ietf.barnes@gmail.com Cc: clue-ads@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, wlo@amsl.com Dear Mary Barnes, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. clue Session 1 (2:30:00) Monday, Morning Session I 0900-1130 Room Name: Salon E --------------------------------------------- clue Session 2 (2:00:00) Tuesday, Afternoon Session I 1300-1500 Room Name: Salon A --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Area Name: Session Requester: Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: atoca avtcore avtext bfcpbis bliss clue codec cuss ecrit geopriv insipid mmusic p2psip payload rtcweb straw simple sipcore siprec vipr xmpp xrblock Second Priority: drinks soc sipclf Special Requests: Meetecho --------------------------------------------------------- --f46d0408393b6dc62604cb40535c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI. =A0 As *always* these slots are subject to change.

= Mary

---------- Forwarded message -------= ---
From: "IETF Secretariat"= <agenda@ietf.org>
Date: Thu, Oct 4, 2012 at 1:29 PM
Subject: clue - Requested sessions hav= e been scheduled for IETF 85
To: mary.ietf.barnes@gmail.com
Cc: clue-ads@tools.ietf.org, mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, wlo@a= msl.com


Dear Mary Barnes,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request.

clue Session 1 (2:30:00)
=A0 =A0 Monday, Morning Session I 0900-1130
=A0 =A0 Room Name: Salon E
=A0 =A0 ---------------------------------------------
=A0 =A0 clue Session 2 (2:00:00)
=A0 =A0 Tuesday, Afternoon Session I 1300-1500
=A0 =A0 Room Name: Salon A
=A0 =A0 ---------------------------------------------



Request Information:


---------------------------------------------------------
Working Group Name:
Area Name:
Session Requester:

Number of Sessions: 2
Length of Session(s): =A02.5 Hours, 2 Hours
Number of Attendees: 100
Conflicts to Avoid:
=A0First Priority: atoca avtcore avtext bfcpbis bliss clue codec cuss ecrit= geopriv insipid mmusic p2psip payload rtcweb straw simple sipcore siprec v= ipr xmpp xrblock
=A0Second Priority: drinks soc sipclf



Special Requests:
=A0 Meetecho
---------------------------------------------------------


--f46d0408393b6dc62604cb40535c-- From ron.even.tlv@gmail.com Fri Oct 5 10:26:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADBF921F87D3 for ; Fri, 5 Oct 2012 10:26:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id se01PNEgIPfy for ; Fri, 5 Oct 2012 10:26:47 -0700 (PDT) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBF621F87DC for ; Fri, 5 Oct 2012 10:26:47 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id hq12so861392wib.13 for ; Fri, 05 Oct 2012 10:26:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=Q7FQKwg9/ok8Jv3cW5BBc5XX86CcRoQ+Q3AwngbAMiY=; b=YgjqhDczBSqul97BsBzIDNHA8617NzE/jSzGuD2YWp9y/Rz3kGoIfRfhxbpsBWZ0FR 8C75U7SgsCVFWJ1t0UP+1J/5C71QKHM6mYlVB1kivtLnoL8ALwD+kkuwVnWCTs4haafB RuA6fxVLIzXYm1T+/BU7dzcr5hxK70nu+zlHk6IRHO9PhU+n3Mbmk+CazV95kWMaCiDA z05opMBgM53gAUr/v4QpP9k551xW4uS5x32Oy/9WbmxlJuC8hLAG1r3S1xCwLMgzVTEk amFmfIGEiEhFfgtLdb3GhtUQjeXNf0lun+ziTOycmepxVx1JnH0K/Shi2yFafnd/XSnQ oR7g== Received: by 10.180.78.102 with SMTP id a6mr4658543wix.20.1349458006209; Fri, 05 Oct 2012 10:26:46 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id cl8sm3408895wib.10.2012.10.05.10.26.43 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 05 Oct 2012 10:26:45 -0700 (PDT) From: "Roni Even" To: "'Simon Pietro Romano'" , "'Paul Kyzivat'" Date: Fri, 5 Oct 2012 19:24:49 +0200 Message-ID: <020e01cda31e$548fd0b0$fdaf7210$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_020F_01CDA32F.1819D930" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2jHlJpMf8zKV2rTqGx0qKUqX8s9A== Content-Language: en-us Cc: 'CLUE' Subject: [clue] comment on data-model-schema-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 17:26:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_020F_01CDA32F.1819D930 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Simon, The major problem is that the example demonstrates the need to have the spatial description. Currently there is no way to know from the example which stream is left, middle and right. The text name is a free text description field and not machine readable. Just moving the minoccur=3D0 to the spatialDescriptionType structure = does not address the problem. There are two case, when you describe a room you = must at list specify the capture point and the area of capture in order to provide the left to right relation. (this needs to be explicitly = specified). If you want to provide streams which have no need for spatial = information than you can provide unspecified value, my view is that this is a scene definition if you need to provide spatial information. The point made at a meeting is what about a switched view, like a media capture that will send the media of the active speaker and is changing dynamically, how to provide spatial information for this case, is it the whole room as the area of capture and the switched hints that you will = get part of it each time. =20 Thanks Roni =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro Romano Sent: 01 October, 2012 7:37 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 =20 Hi all, first of all let me 'publicly' apologize for missing the call. Please find in-line our answers to your first comments on the schema = file. =20 I thought the conclusion was that we needed to have the = spatialDescription in the mediaCaptureType in the schema as mandatory (as opposed to the current minoccurs=3D"0"). =20 OK. No problem with this. Fixed in version -01 of the draft. Then, define the spatialDescriptionType to have two (either/or) subtypes under that: 1) the existing schema 2)a schema allowing less specific information in cases where the entirety of the spatial description is = not required. I don't know right off what the XML schema for that might be, = but we can discuss that on the list. This has also been taken into account in version -01 of the draft, which also contains an ad hoc "diff" section that should help you track down = the changes we made. So, please comment on such version from now on.=20 In the meantime, we'll keep on working on our revision of the current documents and come back to you soon=20 on this list. Looking forward to your comments and suggestions, Simon and Roberta =20 I don't think we decided exactly how/if that might impact the framework, since the framework doesn't necessarily require that a media capture = have spatial information. =20 Mary.=20 On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat = wrote: I posted my notes from the design team meeting today on the wiki. You can look at them at: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minut= es- 121001.txt The entire meeting was spent discussing whether the spatialDescription element in the mediaCaptureType should be optional. This was really a discussion about the framework rather than the schema, because the = schema is simply representing what the framework called for. I don't think we reached a conclusion. Thanks, Paul _______________________________________________ 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 --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano =20 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ =20 ------=_NextPart_000_020F_01CDA32F.1819D930 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Simon,

The major problem is that the example demonstrates the need to have = the spatial description. Currently there is no way to know from the = example which stream is left, middle and right. The text name is a free = text description field and not machine readable.

Just moving the minoccur=3D0 to the spatialDescriptionType structure does not address the problem. There are two case, when you = describe a room you must at list specify the capture point and the area = of capture in order to provide the left to right relation. (this needs = to be explicitly specified).

If you want to=A0 provide streams which have no need for spatial = information than you can provide unspecified value, my view is that this = is a scene definition if you need to provide spatial = information.

The point made at a meeting is what about a switched view, like a = media capture that will send the media of the active speaker and is = changing dynamically, how to provide spatial information for this case, = is it the whole room as the area of capture and the switched hints that = you will get part of it each time.

 

Thanks

Roni

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Simon Pietro Romano
Sent: 01 October, 2012 7:37 = PM
To: Paul Kyzivat
Cc: CLUE
Subject: Re: = [clue] Minutes for design team meeting today, = 1-oct-2012

 

Hi = all,

first of all let me 'publicly' apologize for missing the = call.
Please find in-line our answers to your first comments on the = schema file.

 

I = thought the conclusion was that we needed to have the spatialDescription = in the mediaCaptureType in the schema as mandatory (as opposed to the = current minoccurs=3D"0"). 

OK. No problem with this. Fixed in version -01 of the = draft.

Then, define the = spatialDescriptionType to have two (either/or) subtypes under that: 1) = the existing schema 2)a schema allowing less specific information in = cases where the entirety of the spatial description is not required. =  I don't know right off what the XML schema for that might be, but = we can discuss that on the list.

This = has also been taken into account in version -01 of the draft, which also = contains an ad hoc "diff" section that should help you track = down the changes we made. So, please comment on such version from now = on.
In the meantime, we'll keep on working on our revision of the = current documents and come back to you soon
on this = list.

Looking forward to your comments and = suggestions,

Simon and = Roberta


 

I = don't think we decided exactly how/if that might impact the framework, = since the framework doesn't necessarily require that a media capture = have spatial information.

 

Mary. 

On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I posted my notes from the design team meeting today = on the wiki.
You can look at them at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki= /Design-Team/minutes-121001.txt

The entire meeting was spent = discussing whether the spatialDescription element in the = mediaCaptureType should be optional. This was really a discussion about = the framework rather than the schema, because the schema is simply = representing what the framework called for.

I don't think we = reached a conclusion.

        = 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



-- =

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0_\\|//_
=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 ( =
O-O )
=A0=A0 =
~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Simon =
Pietro =
Romano
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Universita' di Napoli Federico =
II
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
Computer Science Department =

=A0=A0=A0=A0=A0=A0=A0=A0Phone: +39 081 7683823 -- =
Fax: +39 081 =
7684219
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 e-mail: spromano@unina.it
<=
pre>=A0=A0=A0 =A0=A0=A0=A0=A0=A0http://www.comics.=
unina.it/simonpietro.romano
 
=A0=A0=A0 <<Molti mi dicono che lo scoraggiamento =E8 =
l'alibi degli 
=A0=A0=A0idioti. Ci rifletto un =
istante; e mi scoraggio>>. =
Magritte.
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0oooO
=A0=A0 =
~~~~~~~~~~~~~~~~~~~~~~(=A0=A0 )~~ =
Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \ (=A0=A0=A0 (=A0=A0 =
)
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 \_)=A0=A0=A0 ) =
/
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
(_/
 
------=_NextPart_000_020F_01CDA32F.1819D930-- From gunnar.hellstrom@omnitor.se Fri Oct 5 14:42: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 4DB4221F8702 for ; Fri, 5 Oct 2012 14:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0s0cwPvUf-hE for ; Fri, 5 Oct 2012 14:42:12 -0700 (PDT) Received: from vsp-authed-02-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id F0E9D21F8470 for ; Fri, 5 Oct 2012 14:42:11 -0700 (PDT) Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-02-02.binero.net (Halon Mail Gateway) with ESMTP for ; Fri, 5 Oct 2012 23:41:35 +0200 (CEST) Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-08-01.atm.binero.net (Postfix) with ESMTPA id D6D943A2C5 for ; Fri, 5 Oct 2012 23:41:34 +0200 (CEST) Message-ID: <506F5411.6040409@omnitor.se> Date: Fri, 05 Oct 2012 23:41:37 +0200 From: =?ISO-8859-1?Q?Gunnar_Hellstr=F6m?= User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: [clue] Text media in clue X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Oct 2012 21:42:13 -0000 I am sorry, I have not followed clue closely since long. When I now rapidly browsed the framework, I noticed that there is only mentioning of the video and audio media. In an early discussion we found it feasible to include also the third common real-time medium - text. All conference-like tools today have some kind of text communication. I suggest that also CLUE gets its explicit specification about how text is handled. We had some very early discussions about this topic, but we had at that time a bit hard to decide what features of text was clue specific and what was more normal multimedia communication specific. With the experience and structure you have now, I think it will be easy for you to amend the specifications to include at least the real-time text medium in a fruitful way. I made a brief description about how I imagine real-time text might be used in a clue environment. Is this a description suitable to start with with the goal to include what is needed for the text medium in clue specifications? -----Description of use of text in a clue environment-------------------------- Text belongs to a modern conference environment. Not only for accessibility. It has special characteristics such as -positioning in general -positioning in relation to specific video presentation -positioning overlaid or not with video, or in unrelated area -size of text, -size of area to display in -background and foreground colour -visual effects to use if presented overlayed on video -source address or nickname -source role -joint display with other sources or not -language -script -scope of real-time edits -division in messages -label style For many of these parameters, there is interest to have a default value assigned by the conference organizer or the source, and a viewer value assigned by the viewer. The viewer value should in most cases dominate over the organizer value. Characteristics that should have this double source are: -positioning in general -positioning in relation to specific video presentation -positioning overlaid or not with video, or in unrelated area -size of text, -size of area to display in -background and foreground colour -visual effects to use if presented overlayed on video -joint display with other sources or not -label style Some simple use cases: 1. Each participant contribute text to a text box underneath their video. Used for comments, facts that need exact spelling, cut and paste material. Text flows in real-time as typed in order to minimize wait time. 2. Each participant contribute text to a text box underneath their video. Used for typed contributions by participants who do not speak or sign, or to be understood by participants who do not hear. 3. All participants contribute to text display in a common text box. Contributions are labeled. Display may be in real-time so that many entries are built up in real-time simultaneously and moved to a history area when messages are completed. 4. One single source of text, a text interpreter, listening to mixed audio and producing text. Text displayed by default underneath the video view of the speaking or signing person. 5. One single source of text, a text interpreter, listening to mixed audio from the speaking participants and producing text. Text displayed in one statically placed text box. Source indicated in labels mixed with the text. 6. One single source of text, a text interpreter, listening to mixed audio from the speaking participants and producing text. Text displayed in one statically placed text box underneath the video of a sign language interpreter. Source indicated in labels mixed with the text. 7. Multiple sources of text in different labeled languages, a text interpreter per language, listening to mixed audio from the speaking participants and producing text. Text displayed in one statically placed text box per language. Language indicated on the text box. Source indicated in labels mixed with the text. Regards Gunnar -- ___________________________________________________ Gunnar Hellström Omnitor gunnar.hellstrom@omnitor.se +46708204288 From ron.even.tlv@gmail.com Sat Oct 6 10:06: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 389D321F853A for ; Sat, 6 Oct 2012 10:06:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aihzoV6usTR5 for ; Sat, 6 Oct 2012 10:06:27 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 20AA121F856C for ; Sat, 6 Oct 2012 10:06:17 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id hm2so1791716wib.1 for ; Sat, 06 Oct 2012 10:06:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=NnnM5RNwhLdA+BoypObEz4HNzesV6mI0IozL535o2cE=; b=MT6aswYjIZ1kGmLUb/fjnDygmYHHuRCxhWCw6NGfMoj7sWbUrVt8Q1sWTKPNKICqF4 vE8u3n4frcfHEFg70gW8Hsg2DhB5xDpWivyDgSwM0sg0qxOyCJnhkHQ/Z155eg9Lyt1e gMleUxF9d7OkDLRbqsO+1y304ZtchXUmVhZzWBW1EDo7BuD2rr+14BUIVZOKm7RvE66O kP/vPOODsGOL+N2Rb8+aTcUm1i6wdGbAAGM5ld67kfi9nZuVfKZbpVEdlbSwBIeYVGL9 t0QGXqllbhyFCi29GrVZeKrMkD2fP93TQ5FQ2R2kDJt0x90szuwizGkefPlJEIPdQo88 4eEw== Received: by 10.180.91.169 with SMTP id cf9mr10423856wib.1.1349543176976; Sat, 06 Oct 2012 10:06:16 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id p4sm10334044wix.0.2012.10.06.10.06.14 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Oct 2012 10:06:16 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'Paul Kyzivat'" References: <5069B63F.8060608@alum.mit.edu> In-Reply-To: Date: Sat, 6 Oct 2012 19:04:20 +0200 Message-ID: <024701cda3e4$a2503990$e6f0acb0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0248_01CDA3F5.65D9CCE0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG1PonVXd2XM5v5zQwixwtmh49IJAHKCvE6l877TGA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 17:06:28 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0248_01CDA3F5.65D9CCE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My view is that Spatial description is a SHOULD in the framework in order to provide the order. This was implied in the past by the order in the capture scene entry but we decided to have explicit information Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 01 October, 2012 6:16 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 I thought the conclusion was that we needed to have the spatialDescription in the mediaCaptureType in the schema as mandatory (as opposed to the current minoccurs="0"). Then, define the spatialDescriptionType to have two (either/or) subtypes under that: 1) the existing schema 2)a schema allowing less specific information in cases where the entirety of the spatial description is not required. I don't know right off what the XML schema for that might be, but we can discuss that on the list. I don't think we decided exactly how/if that might impact the framework, since the framework doesn't necessarily require that a media capture have spatial information. Mary. On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat wrote: I posted my notes from the design team meeting today on the wiki. You can look at them at: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes- 121001.txt The entire meeting was spent discussing whether the spatialDescription element in the mediaCaptureType should be optional. This was really a discussion about the framework rather than the schema, because the schema is simply representing what the framework called for. I don't think we reached a conclusion. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_0248_01CDA3F5.65D9CCE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

My view is that Spatial description is a SHOULD in the framework in = order to provide the order. This was implied in the past by the order in = the capture scene entry but we decided to have explicit = information

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 01 October, 2012 6:16 PM
To: = Paul Kyzivat
Cc: CLUE
Subject: Re: [clue] Minutes = for design team meeting today, 1-oct-2012

 

I thought = the conclusion was that we needed to have the spatialDescription in the = mediaCaptureType in the schema as mandatory (as opposed to the current = minoccurs=3D"0").  Then, define the = spatialDescriptionType to have two (either/or) subtypes under that: 1) = the existing schema 2)a schema allowing less specific information in = cases where the entirety of the spatial description is not required. =  I don't know right off what the XML schema for that might be, but = we can discuss that on the list.

 

I = don't think we decided exactly how/if that might impact the framework, = since the framework doesn't necessarily require that a media capture = have spatial information.

 

Mary. 

On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I posted my notes from the design team meeting today = on the wiki.
You can look at them at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki= /Design-Team/minutes-121001.txt

The entire meeting was spent = discussing whether the spatialDescription element in the = mediaCaptureType should be optional. This was really a discussion about = the framework rather than the schema, because the schema is simply = representing what the framework called for.

I don't think we = reached a conclusion.

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

 

------=_NextPart_000_0248_01CDA3F5.65D9CCE0-- From mary.ietf.barnes@gmail.com Sat Oct 6 11:03: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 88E6921F84E2 for ; Sat, 6 Oct 2012 11:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.31 X-Spam-Level: X-Spam-Status: No, score=-103.31 tagged_above=-999 required=5 tests=[AWL=0.288, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NacJ59IXY+gK for ; Sat, 6 Oct 2012 11:03:22 -0700 (PDT) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id BA00321F84D8 for ; Sat, 6 Oct 2012 11:03:22 -0700 (PDT) Received: by mail-oa0-f44.google.com with SMTP id n5so3270127oag.31 for ; Sat, 06 Oct 2012 11:03:22 -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=k2vggYOvZqy9/pi1/TlSMiLJHZF1M+ueuXEhxC6XX88=; b=B/29tVYMk+391ZPOqx/ZcQf0iadVCQJo1ZKXRmJcyWEfQMQLbtT9gV1lswinrFIDNF AnZumrt1w3Dl9WB2JeBdY5ODVnp+GFF9joKbpDX6uomQVYSzssPYCYPhNoWh4VR9vDr9 NVWjpOac3uZHLDk8Xr30HcbM0M7sV5u3Om7uIEji6FJG8yb2DisQ7h2U3JREGfZQppgp M/arYki06beC9OUh3rQbzC2jBtXL32mvqZXCHm+6ORu9yH2au7DIYXCpPJ0UgKC6SpaL wvc6ZL0MkbxfAvdvm1AQzJaArVHHYH6YhIAw8buTgmhXtzkPqZZ/Feg5Xep1kxagAg2y +tyQ== MIME-Version: 1.0 Received: by 10.182.8.10 with SMTP id n10mr9314211oba.19.1349546602235; Sat, 06 Oct 2012 11:03:22 -0700 (PDT) Received: by 10.60.62.199 with HTTP; Sat, 6 Oct 2012 11:03:22 -0700 (PDT) In-Reply-To: <024701cda3e4$a2503990$e6f0acb0$@gmail.com> References: <5069B63F.8060608@alum.mit.edu> <024701cda3e4$a2503990$e6f0acb0$@gmail.com> Date: Sat, 6 Oct 2012 13:03:22 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d04448159d5869804cb67cd41 Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 18:03:23 -0000 --f46d04448159d5869804cb67cd41 Content-Type: text/plain; charset=ISO-8859-1 So, I am really puzzled since your concern on the call seemed to that the spatialDescription was an optional element - which would be the case to support a SHOULD. Mary On Sat, Oct 6, 2012 at 12:04 PM, Roni Even wrote: > Hi,**** > > My view is that Spatial description is a SHOULD in the framework in order > to provide the order. This was implied in the past by the order in the > capture scene entry but we decided to have explicit information**** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 01 October, 2012 6:16 PM > *To:* Paul Kyzivat > *Cc:* CLUE > *Subject:* Re: [clue] Minutes for design team meeting today, 1-oct-2012*** > * > > ** ** > > I thought the conclusion was that we needed to have the spatialDescription > in the mediaCaptureType in the schema as mandatory (as opposed to the > current minoccurs="0"). Then, define the spatialDescriptionType to have > two (either/or) subtypes under that: 1) the existing schema 2)a schema > allowing less specific information in cases where the entirety of the > spatial description is not required. I don't know right off what the XML > schema for that might be, but we can discuss that on the list.**** > > ** ** > > I don't think we decided exactly how/if that might impact the framework, > since the framework doesn't necessarily require that a media capture have > spatial information.**** > > ** ** > > Mary. **** > > On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat > wrote:**** > > I posted my notes from the design team meeting today on the wiki. > You can look at them at: > > > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121001.txt > > The entire meeting was spent discussing whether the spatialDescription > element in the mediaCaptureType should be optional. This was really a > discussion about the framework rather than the schema, because the schema > is simply representing what the framework called for. > > I don't think we reached a conclusion. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > ** ** > --f46d04448159d5869804cb67cd41 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So, I am really puzzled since your concern on the call seemed to that the s= patialDescription was an optional element - which would be the case to supp= ort a SHOULD. =A0

Mary

On Sat, Oct 6, 2012 at 12:04 PM, Roni Even <ron.even.tlv@gmail.com> wrote:

Hi,

My view is that Spatial description is a = SHOULD in the framework in order to provide the order. This was implied in = the past by the order in the capture scene entry but we decided to have exp= licit information

Roni=

=A0

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 01 October, 2012 6:16 PM
To: Paul Kyzivat
Cc:<= /b> CLUE
Subject: Re: [clue] Minutes for design team meeting toda= y, 1-oct-2012

=A0

I thought the conclusion was th= at we needed to have the spatialDescription in the mediaCaptureType in the = schema as mandatory (as opposed to the current minoccurs=3D"0"). = =A0Then, define the spatialDescriptionType to have two (either/or) subtypes= under that: 1) the existing schema 2)a schema allowing less specific infor= mation in cases where the entirety of the spatial description is not requir= ed. =A0I don't know right off what the XML schema for that might be, bu= t we can discuss that on the list.

=A0

I don't think we decided exactly how/if that might impac= t the framework, since the framework doesn't necessarily require that a= media capture have spatial information.

=A0

Mary.=A0

On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat <= pkyzivat@alum.mi= t.edu> wrote:

I posted my notes from the design team meeting today= on the wiki.
You can look at them at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Des= ign-Team/minutes-121001.txt

The entire meeting was spent discussing whether the spatialDescription = element in the mediaCaptureType should be optional. This was really a discu= ssion about the framework rather than the schema, because the schema is sim= ply representing what the framework called for.

I don't think we reached a conclusion.

=A0 =A0 =A0 =A0 Thank= s,
=A0 =A0 =A0 =A0 Paul
_____________________________________________= __
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

=A0


--f46d04448159d5869804cb67cd41-- From mary.ietf.barnes@gmail.com Sat Oct 6 12:30:29 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 DF58421F8498 for ; Sat, 6 Oct 2012 12:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.316 X-Spam-Level: X-Spam-Status: No, score=-103.316 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrTn2-wNwBFZ for ; Sat, 6 Oct 2012 12:30:28 -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 3873F21F849A for ; Sat, 6 Oct 2012 12:30:25 -0700 (PDT) Received: by mail-ob0-f172.google.com with SMTP id v19so3263074obq.31 for ; Sat, 06 Oct 2012 12:30:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yG491qRDbA0JPCtbIAwFFXgnMFt1tEhEAA3kyo4qjTg=; b=KRWJSeb/x67dEz7tqwKJTx33tTrH3QYoWJGHPvzS55MJD1NF6q+saptYH/o/8h1OV/ ZW590YcK6cFyfSutTtJI1BNxaJ17M/YfS4vnvTYm1BGifLxZo0QmicYoPxbt6634lSvp hnfbPkzJqoKnztB03sJZ8ed2KhYd/9vlZnwfOcJXKOC34b1Ps52hBuUv8hYevI/U185r OTjy3VvwHP+svBrJzA9cpwP/vuJpwmYkf9DbT/DQqzax2j3KwxsqBxCdqQjN2ZbqlDWv hyICqfGUxPUsyY8OLIJMEbLwB24LHaCGSGNLluipygQIFqGnrRqUfmr4eKNphlSENo4p SKeA== MIME-Version: 1.0 Received: by 10.60.11.162 with SMTP id r2mr9532727oeb.114.1349551825383; Sat, 06 Oct 2012 12:30:25 -0700 (PDT) Received: by 10.60.62.199 with HTTP; Sat, 6 Oct 2012 12:30:25 -0700 (PDT) In-Reply-To: <2073045598.25196.1349551574096.JavaMail.nobody@jva2tc002.webex.com> References: <2073045598.25196.1349551574096.JavaMail.nobody@jva2tc002.webex.com> Date: Sat, 6 Oct 2012 14:30:25 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e89a8fb1f83228706504cb69051a Subject: [clue] Meeting rescheduled: CLUE Design Team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 19:30:30 -0000 --e89a8fb1f83228706504cb69051a Content-Type: text/plain; charset=ISO-8859-1 Per this thread last week (and the fact that I missed Christer's response), the meeting is being pushed out one hour. As noted before, the Webex info is the same and the wiki has been updated with the new time. Hopefully, this will be the last time change for this meeting. As I mentioned on the call last Monday, folks will start falling back this month, so the time in your timezone may change for a few weeks. Regards, Mary. ---------- Forwarded message ---------- From: Clue Working Group Date: Sat, Oct 6, 2012 at 2:26 PM Subject: Meeting rescheduled: CLUE Design Team To: mary.ietf.barnes@gmail.com Hello , Clue Working Group changed the time for this online meeting. Topic: CLUE Design Team Date: Every Monday, from Monday, October 8, 2012 to Monday, March 4, 2013 Time: 10:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 642 221 028 Meeting Password: 1234 ------------------------------------------------------- To join the online meeting (Now from mobile devices!) ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1277075847&PW=NNWRkOGVjYTBh&RT=MiM3 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: 1234 4. Click "Join". To view in other time zones or languages, please click the link: https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1277075847&PW=NNWRkOGVjYTBh&ORT=MiM3 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:642 221 028 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/mc 2. On the left navigation bar, click "Support". You can contact me at: clue-chairs@tools.ietf.org To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://ietf.webex.com/ietf/j.php?ED=158121817&UID=1277075847&ICS=MRS3&LD=1&RD=2&ST=1&SHA2=CINcvltIc8xfwWESFmEaLirEBrosW39VhHEDfiB8mAE=&AID=1265811087&RT=MiM3 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://ietf.webex.com/ietf/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php. Sign up for a free trial of WebEx http://www.webex.com/go/mcemfreetrial http://www.webex.com CCP:+16504793208x642221028# IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. --e89a8fb1f83228706504cb69051a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Per this thread last week (and the fact that I missed Christer's respon= se), the meeting is being pushed out one hour. =A0As noted before, the Webe= x info is the same and the wiki has been updated with the new time. =A0Hope= fully, this will be the last time change for this meeting. As I mentioned o= n the call last Monday, folks will start falling back this month, so the ti= me in your timezone may change for a few weeks.=A0

Regards,
Mary.=A0

---------- Forwarded message ----------
From: Clue Working Group <messenger@webex.com>
Date: Sat, Oct 6, 2012 at 2:26 PM
Subject: Meeting rescheduled: CLUE Des= ign Team
To: mary.ietf.bar= nes@gmail.com



Hello ,

Clue Working Group changed the time for this online meet= ing.

Topic: CLUE Design Team
Date: Every Monday, from Monday= , October 8, 2012 to Monday, March 4, 2013
Time: 10:00 am, Central Day= light Time (Chicago, GMT-05:00)
Meeting Number: 642 221 028
Meeting Password: 1234


---= ----------------------------------------------------
To join the onlin= e meeting (Now from mobile devices!)
---------------------------------= ----------------------
1. Go to htt= ps://ietf.webex.com/ietf/j.php?ED=3D158121817&UID=3D1277075847&PW= =3DNNWRkOGVjYTBh&RT=3DMiM3
2. If requested, enter your name and email address.
3. If a password = is required, enter the meeting password: 1234
4. Click "Join"= ;.

To view in other time zones or languages, please click the lin= k:
https://iet= f.webex.com/ietf/j.php?ED=3D158121817&UID=3D1277075847&PW=3DNNWRkOG= VjYTBh&ORT=3DMiM3

-------------------------------------------------------
To join = the audio conference only
--------------------------------------------= -----------
Call-in toll number (US/Canada): 1-650-479-3208

Access code:642 221 028

-----------------------------------= --------------------
For assistance
-----------------------------= --------------------------
1. Go to https://ietf.webex.com/ietf/mc
2. On the left navigation bar, click "Support".

You ca= n contact me at:
clue-chairs@tools.ietf.org


To update this me= eting to your calendar program (for example Microsoft Outlook), click this = link:
https://ietf.webex.com/ietf/j.php?ED=3D158121817&UID= =3D1277075847&ICS=3DMRS3&LD=3D1&RD=3D2&ST=3D1&SHA2=3DCI= NcvltIc8xfwWESFmEaLirEBrosW39VhHEDfiB8mAE=3D&AID=3D1265811087&RT=3D= MiM3


WebEx will automatically setup Meeting Manager for Windows the f= irst time you join a meeting. To save time, you can setup prior to the meet= ing by clicking this link:
https://ietf.webex.com/ietf/meetin= gcenter/mcsetup.php


The playback of UCF (Universal Communications Format) rich media= files requires appropriate players. To view this type of rich media files = in the meeting, please check whether you have the players installed on your= computer by going to https://ietf.webex.com/ietf/systemdiagnosis.php.

Sign up for a free trial of WebEx
http://www.webex.com/go/mcemfreetrial=

http://ww= w.webex.com

CCP:+16504793208x642221028#

IMPORTANT NOTICE: This WebEx se= rvice includes a feature that allows audio and any documents and other mate= rials exchanged or viewed during the session to be recorded. By joining thi= s session, you automatically consent to such recordings. If you do not cons= ent to the recording, discuss your concerns with the meeting host prior to = the start of the recording or do not join the session. Please note that any= such recordings may be subject to discovery in the event of litigation.

--e89a8fb1f83228706504cb69051a-- From ron.even.tlv@gmail.com Sat Oct 6 14:47:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C92321F84CD for ; Sat, 6 Oct 2012 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X+TTyyAd-YYt for ; Sat, 6 Oct 2012 14:47:21 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 41EFB21F84C9 for ; Sat, 6 Oct 2012 14:47:21 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so1688544wgb.13 for ; Sat, 06 Oct 2012 14:47:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=CnCgYlTIKm9JrBsYTj2tmK70Go7GOvY8GwttX6+hwqQ=; b=aXAKpdfktIVwueBf+o6VViv5tUc0uoRC5lNgL4NkNuRULB82uYWELJDHqfhbuuhnqy LCGU8HZzJMN1tT+x2gZROSeqQRhANdJRMNmqbRYCs9ky2RGgM6SRlNTJQbzn5mKE1pyO JsaQn8nptAR5HqriNqaV45ZBmZgTM6nFVdFijVKbmpqA1a/sdG7TXaUxB4XGlRz2COR1 M/dKkiv5qw2sj0y7KT58JtgBTm5v79CamA0YqWR6JeGjpmmY+A99c3LRDvt+ny54m+g1 4JwNLyD56v/IIAuAz0/9uUSBlgx09RYDbJFKzW+ZVMHenJK8X23oiuMILWT80K3WfV6c IJ+w== Received: by 10.180.87.230 with SMTP id bb6mr11167865wib.6.1349560039911; Sat, 06 Oct 2012 14:47:19 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id gg4sm11740069wib.6.2012.10.06.14.47.17 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Oct 2012 14:47:19 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <5069B63F.8060608@alum.mit.edu> <024701cda3e4$a2503990$e6f0acb0$@gmail.com> In-Reply-To: Date: Sat, 6 Oct 2012 23:45:22 +0200 Message-ID: <026a01cda40b$e5316eb0$af944c10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_026B_01CDA41C.A8BB5020" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG1PonVXd2XM5v5zQwixwtmh49IJAHKCvE6AXK35fYBw8DOOZe1kWaQ Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Oct 2012 21:47:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_026B_01CDA41C.A8BB5020 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There is a big difference between a may and a should. Should is mandatory except for specific cases. My point is that an advertisement should provide the area of capture with real co-ordinate using the the millimeter or unknown scale and for the other cases where there is no real value it should have the no scale value with the capture area. As for the schema, I think that the Spatial description should be mandatory. Even in the new schema the issue is not resolved. My view is that the capture area should not have a minoccur=0, every media capture should provide capture area but using the scale to specify the spatial order or none. Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 06 October, 2012 8:03 PM To: Roni Even Cc: Paul Kyzivat; CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 So, I am really puzzled since your concern on the call seemed to that the spatialDescription was an optional element - which would be the case to support a SHOULD. Mary On Sat, Oct 6, 2012 at 12:04 PM, Roni Even wrote: Hi, My view is that Spatial description is a SHOULD in the framework in order to provide the order. This was implied in the past by the order in the capture scene entry but we decided to have explicit information Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 01 October, 2012 6:16 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 I thought the conclusion was that we needed to have the spatialDescription in the mediaCaptureType in the schema as mandatory (as opposed to the current minoccurs="0"). Then, define the spatialDescriptionType to have two (either/or) subtypes under that: 1) the existing schema 2)a schema allowing less specific information in cases where the entirety of the spatial description is not required. I don't know right off what the XML schema for that might be, but we can discuss that on the list. I don't think we decided exactly how/if that might impact the framework, since the framework doesn't necessarily require that a media capture have spatial information. Mary. On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat wrote: I posted my notes from the design team meeting today on the wiki. You can look at them at: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes- 121001.txt The entire meeting was spent discussing whether the spatialDescription element in the mediaCaptureType should be optional. This was really a discussion about the framework rather than the schema, because the schema is simply representing what the framework called for. I don't think we reached a conclusion. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_026B_01CDA41C.A8BB5020 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There is a big difference between a may and a should. Should is = mandatory except for specific cases. My point is that an advertisement = should provide the area of capture with real co-ordinate using the the = millimeter or unknown scale and for the other cases where there is no = real value it should have the no scale value with the capture = area.

 

As for the schema, I think that the Spatial description should be = mandatory. Even in the new schema the issue is not resolved.  My = view is that the capture area should not have a minoccur=3D0, every = media capture should provide capture area but using the scale to specify = the spatial order or none.

 

 

 

 

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 06 = October, 2012 8:03 PM
To: Roni Even
Cc: Paul = Kyzivat; CLUE
Subject: Re: [clue] Minutes for design team = meeting today, 1-oct-2012

 

So, I am = really puzzled since your concern on the call seemed to that the = spatialDescription was an optional element - which would be the case to = support a SHOULD.  

 

Mary

On Sat, Oct 6, 2012 at 12:04 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi,

My view is that Spatial description is a SHOULD in the framework in = order to provide the order. This was implied in the past by the order in = the capture scene entry but we decided to have explicit = information

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 01 October, 2012 6:16 PM
To: Paul = Kyzivat
Cc: CLUE
Subject: Re: [clue] Minutes for = design team meeting today, 1-oct-2012

 <= /o:p>

I thought = the conclusion was that we needed to have the spatialDescription in the = mediaCaptureType in the schema as mandatory (as opposed to the current = minoccurs=3D"0").  Then, define the = spatialDescriptionType to have two (either/or) subtypes under that: 1) = the existing schema 2)a schema allowing less specific information in = cases where the entirety of the spatial description is not required. =  I don't know right off what the XML schema for that might be, but = we can discuss that on the list.

 <= /o:p>

I don't = think we decided exactly how/if that might impact the framework, since = the framework doesn't necessarily require that a media capture have = spatial information.

 <= /o:p>

Mary. 

On Mon, Oct = 1, 2012 at 10:26 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I posted my = notes from the design team meeting today on the wiki.
You can look at = them at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki= /Design-Team/minutes-121001.txt

The entire meeting was spent = discussing whether the spatialDescription element in the = mediaCaptureType should be optional. This was really a discussion about = the framework rather than the schema, because the schema is simply = representing what the framework called for.

I don't think we = reached a conclusion.

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

 <= /o:p>

 

------=_NextPart_000_026B_01CDA41C.A8BB5020-- From christer.holmberg@ericsson.com Mon Oct 8 01:57:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D177E21F8754 for ; Mon, 8 Oct 2012 01:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.119 X-Spam-Level: X-Spam-Status: No, score=-6.119 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t+Ar4rLg58w for ; Mon, 8 Oct 2012 01:57:19 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8219E21F874C for ; Mon, 8 Oct 2012 01:57:18 -0700 (PDT) X-AuditID: c1b4fb30-b7f7d6d0000042ea-2a-5072956d4999 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 94.53.17130.D6592705; Mon, 8 Oct 2012 10:57:17 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.243]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Mon, 8 Oct 2012 10:57:16 +0200 From: Christer Holmberg To: "clue@ietf.org" Date: Mon, 8 Oct 2012 10:57:14 +0200 Thread-Topic: Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00 Thread-Index: Ac2lMfyN5xbhjaInQoWNm7/ewW3hIAAAOcmA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585340BAD0314@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A0585340BAD030B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585340BAD030B@ESESSCMS0356.eemea.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM+JvrW7u1KIAg00vVCz2n7rM7MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujHXrdrIWLNGqODPvC0sD41q1LkZODgkBE4m9hx+zQdhiEhfu rQeyuTiEBE4xSvQdvsAM4cxhlJj/5StQhoODTcBCovufNkiDiICyxNHN/WDNLAIqEpvvd4GV CAu4SBy86Q9R4irxcMYvFgjbSKLz/jxGEJtXIFzi1pE+MFsIyN5/fyKYzSkQIbH26n1WEJsR 6J7vp9YwgdjMAuISt57MZ4K4U0Ti4cXTUDeLSrx8/A+qXlTiTvt6RpATmAUyJT69LoBYJShx cuYTlgmMIrOQTJqFUDULSRVESb7EprmT2SBsHYkFuz9B2doSyxa+Zoaxzxx4zIQpritx5Pwx dghbUaJtezNU7wpGiZdv5GDiU7ofsi9g5FnFKJybmJmTXm6ul1qUmVxcnJ+nV5y6iREYsQe3 /DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPfvfOUm+2PG 9svq3P8fxxg4qJT33Y9sPPuClc3fKLNsR1uoA0sxR3Kdr8Gva/4n/lnFyk+2eW/F76jctPn9 IZeHTsdV2Dn99rBcqK5aq8rNrvbumfOcLR/3H7U6pDZv9pUHtyt+Wh2a5LJjlfvM/bXpyX7x PGtnB0q+N/zN8vy+2vn3OX6LNJVYijMSDbWYi4oTAfyAXDamAgAA Subject: [clue] FW: Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00 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, 08 Oct 2012 08:57:20 -0000 --_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_ Content-Type: multipart/alternative; boundary="_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_" --_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, For those of you interested in media multiplexing. Regards, Christer From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf Of= Christer Holmberg Sent: 8. lokakuuta 2012 11:55 To: mmusic@ietf.org Subject: [MMUSIC] Draft new: draft-holmberg-mmusic-sdp-mmt-negotiation-00 Hi, We've submitted a new draft, which describes the 'm=3Dbundle' mechanism. In order to avoid confusion, we're not using bundle terminology in the draf= t. Regards, Christer --_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FYI,

 

For those of you interested in media multiplexing.=

&n= bsp;

Reg= ards,

 

Christer

 

 

From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On B= ehalf Of Christer Holmberg
Sent: 8. lokakuuta 2012 11:55
<= b>To: mmusic@ietf.org
Subject: [MMUSIC] Draft new: draft-holm= berg-mmusic-sdp-mmt-negotiation-00

 

Hi,=

 

We’ve submitted a new draft, which d= escribes the ’m=3Dbundle’ mechanism.

 

In order to avoid confus= ion, we’re not using bundle terminology in the draft.

<= p class=3DMsoNormal> 

Regards,=

 

Ch= rister

= --_000_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_-- --_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=133; creation-date="Mon, 08 Oct 2012 08:54:56 GMT"; modification-date="Mon, 08 Oct 2012 08:54:56 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm1tdXNpYyBt YWlsaW5nIGxpc3QNCm1tdXNpY0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tbXVzaWMNCg== --_004_7F2072F1E0DE894DA4B517B93C6A0585340BAD0314ESESSCMS0356e_-- From mary.ietf.barnes@gmail.com Mon Oct 8 07:19:31 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8660111E80AE for ; Mon, 8 Oct 2012 07:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.497 X-Spam-Level: X-Spam-Status: No, score=-102.497 tagged_above=-999 required=5 tests=[AWL=-0.565, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0i6LG7Lyy6s for ; Mon, 8 Oct 2012 07:19:30 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D61B411E80BA for ; Mon, 8 Oct 2012 07:19:29 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3295154lbo.31 for ; Mon, 08 Oct 2012 07:19:28 -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=v3nBVB/NZf0kZ88coKAOWhpXaGsI6jPUjGVsupMZCNA=; b=MMhgbdBqTcpEE227Rls5ZrNK59n5byAb37gJFi/6+8n+/bERHmyMVkC63TUEbB+y+9 1gQyz6Sz2qkY+topBkihrNs/KOFejEis6DX3zfxb1IQRi++cQp1+PUx/+lzE6l0p9bre p7gh/HcGuqkbVDrIvas5h7I77GWxtjenKVzxRZPZk4oHi2xtPPVSYlJzH+R0GF5XRKik 29KPZK6/l7+M3uQoLrvBtJ5eX1K3vDjQZAcZeZ7izhtLRpUyeMkhYtCAJT7RPDeDU4BD B3IWWQSckuKJVBb4U5CLF5Olvf6DnD/PMWYTJZALDJ46LTSXFLsMt1rSMuaYzpfYJpRh l96w== MIME-Version: 1.0 Received: by 10.112.39.138 with SMTP id p10mr5586775lbk.54.1349705968736; Mon, 08 Oct 2012 07:19:28 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 8 Oct 2012 07:19:28 -0700 (PDT) In-Reply-To: <50728D45.7000105@ericsson.com> References: <50728D45.7000105@ericsson.com> Date: Mon, 8 Oct 2012 09:19:28 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=485b390f7ac4d15be004cb8ce88a Subject: [clue] SDP and datachanel 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, 08 Oct 2012 14:19:31 -0000 --485b390f7ac4d15be004cb8ce88a Content-Type: text/plain; charset=ISO-8859-1 This will be of interest to CLUE as well. Regards, Mary. ---------- Forwarded message ---------- From: Salvatore Loreto Date: Mon, Oct 8, 2012 at 3:22 AM Subject: [rtcweb] SDP and datachanel To: rtcweb@ietf.org Hi there, I have just sent an email to the mmusic mailing list to restart the discussion of what should go in SDP for the SCTP (over DTLS) association setup: http://www.ietf.org/mail-**archive/web/mmusic/current/**msg09667.html In particular what is general enough to be inserted in the current wg item (http://tools.ietf.org/html/**draft-ietf-mmusic-sctp-sdp ) and what is specific of the Datachannel protocol but needs to be eventually specified in a separate draft. Please go to the mmusic mailing list and discuss the (SDP related )issues there without cross-posting thanks Salvatore -- Salvatore Loreto, PhD www.sloreto.com ______________________________**_________________ rtcweb mailing list rtcweb@ietf.org https://www.ietf.org/mailman/**listinfo/rtcweb --485b390f7ac4d15be004cb8ce88a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This will be of interest to CLUE as well.

Regards,
=
Mary.

---------- Forwarded message -= ---------
From: Salvatore Loreto <salvatore= .loreto@ericsson.com>
Date: Mon, Oct 8, 2012 at 3:22 AM
Subject: [rtcweb] SDP and datachanelTo: rtcweb@ietf.org


Hi = there,

I have just sent an email to the mmusic mailing list to restart the discuss= ion
of what should go in SDP for the SCTP (over DTLS) association setup:
http://www.ietf.org/mail-archive/web/mmusic/cur= rent/msg09667.html

In particular what is general enough to be inserted in the current wg item<= br> (http://tools.ietf.org/html/draft-ietf-mmusic-sctp-sdp)
and what is specific of the Datachannel protocol but needs to be eventually= specified
in a separate draft.

Please go to the mmusic mailing list and discuss the (SDP related )issues t= here
without cross-posting

thanks
Salvatore

--
Salvatore Loreto, PhD
www.sloreto.com
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org = https://www.ietf.org/mailman/listinfo/rtcweb

--485b390f7ac4d15be004cb8ce88a-- From mary.ietf.barnes@gmail.com Mon Oct 8 07:39:16 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 DD65F21F85C3 for ; Mon, 8 Oct 2012 07:39:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.321 X-Spam-Level: X-Spam-Status: No, score=-103.321 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i87FxI-t7xA4 for ; Mon, 8 Oct 2012 07:39:15 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9194621F853A for ; Mon, 8 Oct 2012 07:38:51 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3312619lbo.31 for ; Mon, 08 Oct 2012 07:38:50 -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=OIQiZMoCPZuvcJOkCvt47H8m1GlLgWYyErXmoiEEpcU=; b=FqrddBjkkDLav3mBSR5C8VqrCmo6aGBUYbJCExaryYZuDBmKUamJbhLPhZTUqS/3zY BB/YCqGhraXQXaflxX3pEGF4tLskk7SoOssf5GVjarpMF/fT6k77VIhUhe4QgZ+fH5Cl WXFuAAtjFvczidx3ukaHwSQbcejQzQtZuGZnEgfPSKgLoLo0SN0xDzcuC8aF2oZXL7Ci vA6EZsAOBmS8AnNnVQ7tewH9LjmyHXXbbATtmK/+OWQu2rsC68E12cmw9SaqXWAndkpS Ht9qPO6QAfVtQ5FqlfL4tLFcPR2Ofdd1AyRfo0GnkGuVds4rG8tsrmQZIGtLT/gojpGx AEPg== MIME-Version: 1.0 Received: by 10.112.87.5 with SMTP id t5mr2781936lbz.24.1349707130248; Mon, 08 Oct 2012 07:38:50 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 8 Oct 2012 07:38:50 -0700 (PDT) In-Reply-To: <026a01cda40b$e5316eb0$af944c10$@gmail.com> References: <5069B63F.8060608@alum.mit.edu> <024701cda3e4$a2503990$e6f0acb0$@gmail.com> <026a01cda40b$e5316eb0$af944c10$@gmail.com> Date: Mon, 8 Oct 2012 09:38:50 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d040168bb0c9f5904cb8d2e65 Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 14:39:16 -0000 --f46d040168bb0c9f5904cb8d2e65 Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 6, 2012 at 4:45 PM, Roni Even wrote: > Hi,**** > > There is a big difference between a may and a should. Should is mandatory > except for specific cases. My point is that an advertisement should provide > the area of capture with real co-ordinate using the the millimeter or > unknown scale and for the other cases where there is no real value it > should have the no scale value with the capture area. > [MB] We discussed on the call that this would be overloading the "scale" element. [/MB] > **** > > ** ** > > As for the schema, I think that the Spatial description should be > mandatory. Even in the new schema the issue is not resolved. My view is > that the capture area should not have a minoccur=0, every media capture > should provide capture area but using the scale to specify the spatial > order or none. > [MB] So, the spatialDescription is now mandatory in the updated schema, which was your original concern. The captureArea isn't mandatory because it's meaningless if you "noscale". Can you provide an example that shows why it is better to have the captureArea as mandatory? [/MB] **** > > ** ** > > ** ** > > ** ** > > ** ** > > Roni**** > > ** ** > > *From:* Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > *Sent:* 06 October, 2012 8:03 PM > *To:* Roni Even > *Cc:* Paul Kyzivat; CLUE > > *Subject:* Re: [clue] Minutes for design team meeting today, 1-oct-2012*** > * > > ** ** > > So, I am really puzzled since your concern on the call seemed to that the > spatialDescription was an optional element - which would be the case to > support a SHOULD. **** > > ** ** > > Mary**** > > On Sat, Oct 6, 2012 at 12:04 PM, Roni Even wrote: > **** > > Hi,**** > > My view is that Spatial description is a SHOULD in the framework in order > to provide the order. This was implied in the past by the order in the > capture scene entry but we decided to have explicit information**** > > Roni**** > > **** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 01 October, 2012 6:16 PM > *To:* Paul Kyzivat > *Cc:* CLUE > *Subject:* Re: [clue] Minutes for design team meeting today, 1-oct-2012*** > * > > **** > > I thought the conclusion was that we needed to have the spatialDescription > in the mediaCaptureType in the schema as mandatory (as opposed to the > current minoccurs="0"). Then, define the spatialDescriptionType to have > two (either/or) subtypes under that: 1) the existing schema 2)a schema > allowing less specific information in cases where the entirety of the > spatial description is not required. I don't know right off what the XML > schema for that might be, but we can discuss that on the list.**** > > **** > > I don't think we decided exactly how/if that might impact the framework, > since the framework doesn't necessarily require that a media capture have > spatial information.**** > > **** > > Mary. **** > > On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat > wrote:**** > > I posted my notes from the design team meeting today on the wiki. > You can look at them at: > > > http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes-121001.txt > > The entire meeting was spent discussing whether the spatialDescription > element in the mediaCaptureType should be optional. This was really a > discussion about the framework rather than the schema, because the schema > is simply representing what the framework called for. > > I don't think we reached a conclusion. > > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue**** > > **** > > ** ** > --f46d040168bb0c9f5904cb8d2e65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Oct 6, 2012 at 4:45 PM, Roni Eve= n <ron.even.tlv@gmail.com> wrote:

Hi,

There is a big difference between a may a= nd a should. Should is mandatory except for specific cases. My point is tha= t an advertisement should provide the area of capture with real co-ordinate= using the the millimeter or unknown scale and for the other cases where th= ere is no real value it should have the no scale value with the capture are= a.

[MB] We discussed on the call that this would= be overloading the "scale" element. [/MB]

=A0

As for the schema, I thin= k that the Spatial description should be mandatory. Even in the new schema = the issue is not resolved. =A0My view is that the capture area should not h= ave a minoccur=3D0, every media capture should provide capture area but usi= ng the scale to specify the spatial order or none.

[MB] So, the spatialDescription is now mandat= ory in the updated schema, which was your original concern. The captureArea= isn't mandatory because it's meaningless if you "noscale"= ;.=A0

Can you provide an example that shows why it is better = to have the captureArea as mandatory?
=A0[/MB]



=A0

=A0<= /p>

=A0

=A0<= /p>

Roni

=A0<= /p>

From: Mary = Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 06 October, 2012 8:03 PM
To: Roni Even
Cc:= Paul Kyzivat; CLUE


Subject: Re= : [clue] Minutes for design team meeting today, 1-oct-2012

=A0

So, I am really puzzled since your concern on t= he call seemed to that the spatialDescription was an optional element - whi= ch would be the case to support a SHOULD. =A0

=A0

Mary

On Sat, Oct 6, 2012 at 12:04 PM, Roni Even <ron.even.tlv@gmail.com&g= t; wrote:

Hi,

My view is t= hat Spatial description is a SHOULD in the framework in order to provide th= e order. This was implied in the past by the order in the capture scene ent= ry but we decided to have explicit information

Roni=

=A0<= /u>

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 01 October, 2012 6:16 PM
To: Paul Kyzivat
Cc:<= /b> CLUE
Subject: Re: [clue] Minutes for design team meeting toda= y, 1-oct-2012

=A0<= u>

I thought the conclusion was that we needed to have = the spatialDescription in the mediaCaptureType in the schema as mandatory (= as opposed to the current minoccurs=3D"0"). =A0Then, define the s= patialDescriptionType to have two (either/or) subtypes under that: 1) the e= xisting schema 2)a schema allowing less specific information in cases where= the entirety of the spatial description is not required. =A0I don't kn= ow right off what the XML schema for that might be, but we can discuss that= on the list.

=A0

I don't think we decided exactly how/if that might impac= t the framework, since the framework doesn't necessarily require that a= media capture have spatial information.

=A0

Mary.=A0

On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat <= pkyzivat@alum.mi= t.edu> wrote:

I posted my notes from the design team meeting today= on the wiki.
You can look at them at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Des= ign-Team/minutes-121001.txt

The entire meeting was spent discussing whether the spatialDescription = element in the mediaCaptureType should be optional. This was really a discu= ssion about the framework rather than the schema, because the schema is sim= ply representing what the framework called for.

I don't think we reached a conclusion.

=A0 =A0 =A0 =A0 Thank= s,
=A0 =A0 =A0 =A0 Paul
_____________________________________________= __
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue

=A0

=A0

<= /blockquote>

--f46d040168bb0c9f5904cb8d2e65-- From ron.even.tlv@gmail.com Mon Oct 8 08:00:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FC221F86D9 for ; Mon, 8 Oct 2012 08:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xgyn0YhyoXtq for ; Mon, 8 Oct 2012 08:00:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E928B21F8702 for ; Mon, 8 Oct 2012 08:00:08 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2885552wey.31 for ; Mon, 08 Oct 2012 08:00:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=qomGPjS37MC/2dekr5mInK2F6U61u2rSveiGWrzbahs=; b=B3K6k7OTMqk8boJGx8Pq7rfL5A4qcFJCBbY8P+nHaFIqaPnA7O2Kbndj32Rbgh51zo aqDhsV3h2r6pF+8TUvbXAVnxD2UC5F8syVauZoVxP+QX0WsCXBtdkDwQy5xhMiLgqIgH BpQYybHV9CdEcI5iQPWJZhyIzTDfG2wXNAycRyJuqA8I8E+l2KcIY33/amqNwmtGnHz3 pQVhe2tZ8iQdUFImXTmTYLAaecEe2sh5AEI+He2q6eQsXObVLvBzTi7oj1tw5MICI+n8 gHf2yCKsgheFbyL8zYdtaq3EYeYCjF0ZVZsUBllLHiGgfBxAhOj82UoWxPoTTgdVbr0f FOqA== Received: by 10.180.79.7 with SMTP id f7mr22507975wix.22.1349708407813; Mon, 08 Oct 2012 08:00:07 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id p4sm22524694wix.0.2012.10.08.08.00.05 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 08:00:07 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <5069B63F.8060608@alum.mit.edu> <024701cda3e4$a2503990$e6f0acb0$@gmail.com> <026a01cda40b$e5316eb0$af944c10$@gmail.com> In-Reply-To: Date: Mon, 8 Oct 2012 16:58:11 +0200 Message-ID: <004c01cda565$57ace140$0706a3c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004D_01CDA576.1B3737E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG1PonVXd2XM5v5zQwixwtmh49IJAHKCvE6AXK35fYBw8DOOQHSle73Afy0z9+Xmc7mcA== Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 15:00:10 -0000 This is a multipart message in MIME format. ------=_NextPart_000_004D_01CDA576.1B3737E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, If you have a capture scene entry of more than one media capture, the capture area must be mandatory Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 08 October, 2012 4:39 PM To: Roni Even Cc: Paul Kyzivat; CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 On Sat, Oct 6, 2012 at 4:45 PM, Roni Even wrote: Hi, There is a big difference between a may and a should. Should is mandatory except for specific cases. My point is that an advertisement should provide the area of capture with real co-ordinate using the the millimeter or unknown scale and for the other cases where there is no real value it should have the no scale value with the capture area. [MB] We discussed on the call that this would be overloading the "scale" element. [/MB] As for the schema, I think that the Spatial description should be mandatory. Even in the new schema the issue is not resolved. My view is that the capture area should not have a minoccur=0, every media capture should provide capture area but using the scale to specify the spatial order or none. [MB] So, the spatialDescription is now mandatory in the updated schema, which was your original concern. The captureArea isn't mandatory because it's meaningless if you "noscale". Can you provide an example that shows why it is better to have the captureArea as mandatory? [/MB] Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 06 October, 2012 8:03 PM To: Roni Even Cc: Paul Kyzivat; CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 So, I am really puzzled since your concern on the call seemed to that the spatialDescription was an optional element - which would be the case to support a SHOULD. Mary On Sat, Oct 6, 2012 at 12:04 PM, Roni Even wrote: Hi, My view is that Spatial description is a SHOULD in the framework in order to provide the order. This was implied in the past by the order in the capture scene entry but we decided to have explicit information Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 01 October, 2012 6:16 PM To: Paul Kyzivat Cc: CLUE Subject: Re: [clue] Minutes for design team meeting today, 1-oct-2012 I thought the conclusion was that we needed to have the spatialDescription in the mediaCaptureType in the schema as mandatory (as opposed to the current minoccurs="0"). Then, define the spatialDescriptionType to have two (either/or) subtypes under that: 1) the existing schema 2)a schema allowing less specific information in cases where the entirety of the spatial description is not required. I don't know right off what the XML schema for that might be, but we can discuss that on the list. I don't think we decided exactly how/if that might impact the framework, since the framework doesn't necessarily require that a media capture have spatial information. Mary. On Mon, Oct 1, 2012 at 10:26 AM, Paul Kyzivat wrote: I posted my notes from the design team meeting today on the wiki. You can look at them at: http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki/Design-Team/minutes- 121001.txt The entire meeting was spent discussing whether the spatialDescription element in the mediaCaptureType should be optional. This was really a discussion about the framework rather than the schema, because the schema is simply representing what the framework called for. I don't think we reached a conclusion. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue ------=_NextPart_000_004D_01CDA576.1B3737E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

If you have a capture scene entry of more than one media capture, the = capture area must be mandatory

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 08 = October, 2012 4:39 PM
To: Roni Even
Cc: Paul = Kyzivat; CLUE
Subject: Re: [clue] Minutes for design team = meeting today, 1-oct-2012

 

 

On Sat, Oct 6, 2012 at 4:45 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi,

There is a big difference between a may and a should. Should is = mandatory except for specific cases. My point is that an advertisement = should provide the area of capture with real co-ordinate using the the = millimeter or unknown scale and for the other cases where there is no = real value it should have the no scale value with the capture = area.

[MB] We = discussed on the call that this would be overloading the = "scale" element. [/MB]

 

As for the schema, I think that the Spatial description should be = mandatory. Even in the new schema the issue is not resolved.  My = view is that the capture area should not have a minoccur=3D0, every = media capture should provide capture area but using the scale to specify = the spatial order or = none.

[MB] So, the spatialDescription is now mandatory in = the updated schema, which was your original concern. The captureArea = isn't mandatory because it's meaningless if you = "noscale". 

 

Can you provide an example that shows why it is better = to have the captureArea as mandatory?

 [/MB]

 

 

 

 

 

 

 

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 06 = October, 2012 8:03 PM
To: Roni Even
Cc: Paul = Kyzivat; CLUE


Subject: Re: [clue] Minutes for design team = meeting today, 1-oct-2012

 <= /o:p>

So, I am = really puzzled since your concern on the call seemed to that the = spatialDescription was an optional element - which would be the case to = support a SHOULD.  

 <= /o:p>

Mary

On Sat, Oct = 6, 2012 at 12:04 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi,

My view is that Spatial description is a SHOULD in the framework in = order to provide the order. This was implied in the past by the order in = the capture scene entry but we decided to have explicit = information

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 01 October, 2012 6:16 PM
To: Paul = Kyzivat
Cc: CLUE
Subject: Re: [clue] Minutes for = design team meeting today, 1-oct-2012

 <= /o:p>

I thought = the conclusion was that we needed to have the spatialDescription in the = mediaCaptureType in the schema as mandatory (as opposed to the current = minoccurs=3D"0").  Then, define the = spatialDescriptionType to have two (either/or) subtypes under that: 1) = the existing schema 2)a schema allowing less specific information in = cases where the entirety of the spatial description is not required. =  I don't know right off what the XML schema for that might be, but = we can discuss that on the list.

 <= /o:p>

I don't = think we decided exactly how/if that might impact the framework, since = the framework doesn't necessarily require that a media capture have = spatial information.

 <= /o:p>

Mary. 

On Mon, Oct = 1, 2012 at 10:26 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

I posted my = notes from the design team meeting today on the wiki.
You can look at = them at:

http://trac.tools.ietf.org/wg/clue/trac/attachment/wiki= /Design-Team/minutes-121001.txt

The entire meeting was spent = discussing whether the spatialDescription element in the = mediaCaptureType should be optional. This was really a discussion about = the framework rather than the schema, because the schema is simply = representing what the framework called for.

I don't think we = reached a conclusion.

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

 <= /o:p>

 <= /o:p>

 

------=_NextPart_000_004D_01CDA576.1B3737E0-- From mary.ietf.barnes@gmail.com Mon Oct 8 10:52:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 015DA11E8091 for ; Mon, 8 Oct 2012 10:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.325 X-Spam-Level: X-Spam-Status: No, score=-103.325 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDUYzB2pvI-d for ; Mon, 8 Oct 2012 10:52:42 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9D5D711E808A for ; Mon, 8 Oct 2012 10:52:41 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3459251lbo.31 for ; Mon, 08 Oct 2012 10:52:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=3cHGbPHkmZmpUp1vWiQ+MRxRbXRP4llDlZbizffx0QU=; b=Qg4QE2RVg/lufYqUY5o0UDXP0kviMYMKLhdIssW3R3V6ucwQprQ76ny+HrM1M4Yt01 bAsMxQnC5duxFqQg+SDWkdO56ihRpN5gVlSPMEGV0Bxdis0aa/6Es397dLi3QKP6SEmj 87p+iFRNZkrnnYUWS1mcd+l0Ps4yK6m6o3SLJQWo4ZiN2rr4gHyUchSPaXIqCDjxwlaO yaM3jvRoTqi/SHgX7iHyMKjAhkC0BN0KOF6vLtZjBd+LYkMWz9xj0REFaigFmqs6O5PP +4ztDPL+gNzColeWi8h0sRki6pRYpFsh53/3qFprJnKveTGA/Xn9okcA95xx+7fiOqAv adPg== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr14374850lab.30.1349718760540; Mon, 08 Oct 2012 10:52:40 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 8 Oct 2012 10:52:40 -0700 (PDT) Date: Mon, 8 Oct 2012 12:52:40 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e89a8f23466544ca4904cb8fe3b5 Subject: [clue] Minutes: Interim Meeting Sept. 19-20, 2012, San Jose, CA 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, 08 Oct 2012 17:52:43 -0000 --e89a8f23466544ca4904cb8fe3b5 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The detailed minutes (Andy's, Rob's and mine) along with summaries of Conclusion, New Issues, Action Item and Way forward for the documents are now available in the proceedings: http://www.ietf.org/proceedings/interim/2012/09/19/clue/minutes/minutes-interim-2012-clue-3 Note, that I parsed the information from the summary slides into each of the relevant sections and tried to cross-reference those. If people think it would be helpful, I can change the cross-references to real issue #s. Please note that there are assignees for all action items except one. I am going to put all the new issues in the wiki Tickets by the end of today, so please comment on each of the issues using the issue #. Also, we haven't been as conscientious as we should have been in keeping track of action items. I tried at one time to list them on the Design Team wiki page, but that didn't work well. So, I am going to also add each of these to the wiki Tickets and include "Action Item:" in the title (and see if there isn't a unique label we can use for these). Ideally, these will be closed or proposals made before IETF-85. Thanks, Mary. --e89a8f23466544ca4904cb8fe3b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The detailed minutes (Andy's, Rob's and = mine) along with summaries of Conclusion, New Issues, Action Item and Way f= orward for the documents are now available in the proceedings:
Note, that I pa= rsed the information from the summary slides into each of the relevant sect= ions and tried to cross-reference those. =A0If people think it would be hel= pful, I can change the cross-references to real issue #s.=A0

Please note that there are assignees for all action ite= ms except one. =A0I am going to put all the new issues in the wiki Tickets = by the end of today, so please comment on each of the issues using the issu= e #. =A0

Also, we haven't been as conscientious as we should= have been in keeping track of action items. =A0I tried at one time to list= them on the Design Team wiki page, but that didn't work well. So, I am= going to also add each of these to the wiki Tickets and include "Acti= on Item:" in the title (and see if there isn't a unique label we c= an use for these). =A0Ideally, these will be closed or proposals made befor= e IETF-85. =A0

Thanks,
Mary.=A0
--e89a8f23466544ca4904cb8fe3b5-- From mary.ietf.barnes@gmail.com Mon Oct 8 11:02: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 B879C21F87A8 for ; Mon, 8 Oct 2012 11:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.33 X-Spam-Level: X-Spam-Status: No, score=-103.33 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tU6QG14cTtJS for ; Mon, 8 Oct 2012 11:02:45 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id E96E521F86F9 for ; Mon, 8 Oct 2012 11:02:44 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3465890lbo.31 for ; Mon, 08 Oct 2012 11:02:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ZoN+bvXUdmm7sDZCGeJlZ60BqT6etUct1v7LpgilVSw=; b=Kb+M35ltwBKEdnDN7emi+/FSXkpoBGzxKQknEIXlJuZglSAxZ85TLYK+B2s0mGe1Ky o+V5ox/VocUXqsJ9Y09xCCpvqK9hYCajjLVL1VfQRrWC462FuScEHDknJDtOTA//5v+Y WjEc37H8IbjDsUUYSpUeOYpFkyVeJaGJX5qZKlNiAequEoSu3BeXTlOdYkw3kyCWJINF PedDKSSi9JN8XrG4Zgqfsttda+IPbX8VN8YH1gNz5i1aqdlRTkXuwB1srViRCzeniI0M RyHayZhsDXnOZbL2U+/Zh9aHPU/hlmvKQMhl3bYRewlvH9BNEyHPbTCDt3j2QlyG4wxX j41Q== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr14401945lab.30.1349719363737; Mon, 08 Oct 2012 11:02:43 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 8 Oct 2012 11:02:43 -0700 (PDT) Date: Mon, 8 Oct 2012 13:02:43 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e89a8f23466538d77d04cb9007a6 Subject: [clue] IETF-85 plans and agenda 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, 08 Oct 2012 18:02:45 -0000 --e89a8f23466538d77d04cb9007a6 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We will likely need agenda time to run through all the new issues, but discussion of those before the meeting would be really helpful. Note, that the -00 deadline is in one week's time (Oct. 15th). The final document deadline is Oct. 22nd. We will allocate agenda time for the following topics (not necessarily in this order) based upon the amount of discussion and specific requests: - Issue summary, Action item status (chairs) - Framework (if needed) (Andy) - RTP usage (Roni, Jonathan) - CLUE schema (Simon, Roberta) - CLUE signaling, examples (Simon, Roberta, Rob) - SDP impacts (Christer, Roni) - Call flows (Rob, Paul K, Simon/Roberta) - Issue summary (revised), Way Forward (Chairs) Please let us know if you would like agenda time for a specific issue or if you've submitted a new document (it might be really helpful to do this to set the context for discussion of issues). Obviously, comments on the agenda items are also welcome. Regards, Mary and Paul --e89a8f23466538d77d04cb9007a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

We will likely need agenda time to run through a= ll the new issues, but discussion of those before the meeting would be real= ly helpful.

Note, that the -00 deadline is in one = week's time (Oct. 15th). =A0The final document deadline is Oct. 22nd. = =A0

We will allocate agenda time for the following topics (= not necessarily in this order) based upon the amount of discussion and spec= ific requests:
- Issue summary, Action item status (chairs)
- Framework (if needed) (Andy)
- RTP usage =A0(Roni, Jonatha= n)=A0
- CLUE schema (Simon, Roberta)
- CLUE signaling, = examples (Simon, Roberta, Rob)=A0
- SDP impacts (Christer, Roni)<= /div>
- Call flows (Rob, Paul K, Simon/Roberta)
- Issue summary (r= evised), Way Forward (Chairs)

Please let us know i= f you would like agenda time for a specific issue or if you've submitte= d a new document (it might be really helpful to do this to set the context = for discussion of issues). =A0 Obviously, comments on the agenda items are = also welcome.=A0

Regards,
Mary and Paul
--e89a8f23466538d77d04cb9007a6-- From mary.ietf.barnes@gmail.com Mon Oct 8 11:27:41 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 BABFD21F87FE for ; Mon, 8 Oct 2012 11:27:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.334 X-Spam-Level: X-Spam-Status: No, score=-103.334 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5iG70an1OCM for ; Mon, 8 Oct 2012 11:27:40 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 60AA621F87C5 for ; Mon, 8 Oct 2012 11:27:40 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so2721344lam.31 for ; Mon, 08 Oct 2012 11:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=GUoehFDkMQyF7x+P2N+YEZpi+HdxEi/L9V8pXYUUxrE=; b=YiZZqcpyJnUhjoNgiQNO/Xzbvp7WA051tccGvGHXzAgzujvgjsatV7ICUSFqm+GZzJ U8Y1b6/LecIE9DntpLRgnZFcu+LEhOf1WpSJ+5Dsy6vHY15mOWXnO7tNCy8nytyCmD6w vyPGO0PfdbYmgY7hoEJ7oLbQL2/6+6EepJ1ejbviZyaEvz1Z9DmTSCiScxuq/t2A33oO JG4FaIcsxhVKpG9hsGE22Wamzxt8hwiGLwfrxGdkwHYGbUexHHLS/gUXJDxqFd+vBHmO dE5tBclwmOxbQPoy/fJ84Rw+My6hroJqBLjBP5Uw9Bkf657dFjQmliSMexTWZxN0Wikr 3jxg== MIME-Version: 1.0 Received: by 10.112.8.226 with SMTP id u2mr6694764lba.22.1349720859294; Mon, 08 Oct 2012 11:27:39 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 8 Oct 2012 11:27:39 -0700 (PDT) Date: Mon, 8 Oct 2012 13:27:39 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e0cb4efe32705d3b2604cb906079 Subject: [clue] Minutes: Design Team meeting - Oct. 8th, 2012 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Oct 2012 18:27:41 -0000 --e0cb4efe32705d3b2604cb906079 Content-Type: text/plain; charset=ISO-8859-1 Hi all, Here are my notes based upon my chicken scratches during the meeting. Thanks to everyone for attending. IETF CLUE WG design team meeting, Oct. 8th, 2012 Participants: ------------ Mary Barnes Roni Even Rob Hansen Christer Holmberg Paul Kyzivat Roberta Presta Simon Pietro Romano Recording: ---------- https://ietf.webex.com/ietf/ldr.php?AT=pb&SP=MC&rID=8546972&rKey=a1502e66142c8a2b New action items: ----------------- - Simon/Roberta: update the schema per discussion below - Roni: propose how we can do codecs in the encodingGroup New issues: ------------- - Simultaneous sets (per below) - How to describe codecs in the encodingGroup (per below) Notes by Mary ============== Discussing this thread: http://www.ietf.org/mail-archive/web/clue/current/msg01971.html Discussing Schema: - Roni: why are coordinates required if you have one camera? Can just do this in SDP with content attribute. Unless you have spatial information, you don't need CLUE. - Question: what about a hybrid model - i.e., CLUE in one direction? Advertisement is uni-directional - Simon: Maybe this can be done by just including a pointer/identifier to the capturePoint - Distinction between audio and video was noted. Simon's suggestion would then provide different constructs depending upon media type. i.e., separate elements for capturePoint and captureArea . Video would have both. Audio just needs capturePoint. - Simon noted this could nicely solve the issue with simultaneous sets - Action: Simon and Roberta - update the data-model-schema to reflect this proposal. - Roni: discussing example (noted spatial information missing from VC1, VC2 and VC3) Discussing Simultaneous sets [New issue]: - If you have audio & video, do they need to be in a simultaneous set? - If you have two capture scenes are they in simultaneous sets or do they need to be in the same capture scene - Paul: model lets you define captures that can be in multiple scenes. Maybe this should not be allowed. MCU example. - Roni: MCU will define own mediaCapture names Discussing Encoding groups: - Simon: this is based on the framework. Put some stuff in the schema to show how the encoding type can be extended. Propose to remove H.264 stuff. - Roni: Will there be a value used for any codec or is it codec specific or do we always use same units. Action: Roni to propose how this should be done. [New issue] --e0cb4efe32705d3b2604cb906079 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

Here are my notes based upon my chicken scratche= s during the meeting. =A0Thanks to everyone for attending.=A0
IETF CLUE WG design team meeting, Oct. 8th, 2012

Participants:=A0
------------=A0
Mary Ba= rnes
Roni Even
Rob Hansen
Christer Holmberg
Paul Kyzivat
Roberta Presta
Simon Pietro Roman= o

Recording:
----------


New action items:
------------= -----
- Simon/Roberta: update the schema per discussion below
- Roni: propose how we can do codecs in the encodingGroup

New issues:=A0
-------------
- Simultane= ous sets (per below)
- How to describe codecs in the encodingGrou= p (per below)

Notes by Mary
=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Discussing this thread:

Discussing Schema= :
- Roni: why are coordinates required if you have one camera? =A0Can ju= st do this in SDP with content attribute. =A0Unless you have spatial inform= ation, you don't need CLUE.
- Question: what about a hybrid m= odel - i.e., CLUE in one direction? =A0Advertisement is uni-directional
- Simon: Maybe this can be done by just including a pointer/identifier= to the capturePoint
- Distinction between audio and video was no= ted. =A0Simon's suggestion would then provide different constructs depe= nding upon media type. =A0i.e., separate elements for capturePoint and capt= ureArea . Video would have both. Audio just needs capturePoint.
- Simon noted this could nicely solve the issue with simultaneous sets=
- Action: Simon and Roberta - update the data-model-schema to re= flect this proposal.
- Roni: discussing example (noted spatial in= formation missing from VC1, VC2 and VC3)

Discussing Simultaneous sets [New issue]:=A0
= - If you have audio & video, do they need to be in a simultaneous set?<= /div>
- If you have two capture scenes are they in simultaneous sets or= do they need to be in the same capture scene
- Paul: model lets you define captures that can be in multiple scenes.= =A0Maybe this should not be allowed. =A0MCU example. =A0=A0
- Ro= ni: MCU will define own mediaCapture names

Discuss= ing Encoding groups:
- Simon: this is based on the framework. =A0Put some stuff in the sche= ma to show how the encoding type can be extended. Propose to remove H.264 s= tuff.
- Roni: Will there be a value used for any codec or is it c= odec specific or do we always use same units. =A0Action: Roni to propose ho= w this should be done. [New issue]

--e0cb4efe32705d3b2604cb906079-- From ron.even.tlv@gmail.com Mon Oct 8 16:17:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6346221F8722 for ; Mon, 8 Oct 2012 16:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4Y4kCW-AO8U for ; Mon, 8 Oct 2012 16:17:00 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4829A21F874C for ; Mon, 8 Oct 2012 16:17:00 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so3155906wey.31 for ; Mon, 08 Oct 2012 16:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=4W2cf1WxRqmDyXdOM+l1jK7Fup6u/zW/NdYsaBBp7ho=; b=MsHCblTtvJJK04n1ysxjJBJqua+DvxcpLeWUp5lDqIgcZ72wdcYx6RnXmEBRBb73Wn 8J/T1rqAir0kibS9HUB83i5YoBDTGKvaXNvi2jwkmiSfGuOMgypkzDpKwxlhyOdAkQ9H hJjYDGFJxfbM3YXeGCzQrYVlo2hnf1YFzvaCuDWwV812Ln4qyV++ZDHfF6jZgWlif8jR CkMH64HLXMsn1rAOdHK6OLMkn8MK/IlHDR97Eze6HrxOUL/7LdNA4WjsQQ1z6WFnukvi X1nfptWFVhL/i4ylPAsZCyjmt7AirLCB8MNGdiCWLWlIwHciWd+dPJPKLz4+mMB03eer VVvQ== Received: by 10.180.97.35 with SMTP id dx3mr21497wib.14.1349738219035; Mon, 08 Oct 2012 16:16:59 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id b3sm22005097wie.0.2012.10.08.16.16.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Oct 2012 16:16:57 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Tue, 9 Oct 2012 01:15:02 +0200 Message-ID: <00a201cda5aa$c06ec280$414c4780$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A3_01CDA5BB.83F82EC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFTVd5IMJJeBF30PB0bC/Y8NRewqZikqYNA Content-Language: en-us Subject: Re: [clue] IETF-85 plans and agenda 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, 08 Oct 2012 23:17:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00A3_01CDA5BB.83F82EC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mary, On the framework agenda item there is also http://tools.ietf.org/html/draft-groves-clue-capture-attr-00 that I would like to discuss, it was deferred from the interim meeting Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 08 October, 2012 8:03 PM To: CLUE Subject: [clue] IETF-85 plans and agenda Hi all, We will likely need agenda time to run through all the new issues, but discussion of those before the meeting would be really helpful. Note, that the -00 deadline is in one week's time (Oct. 15th). The final document deadline is Oct. 22nd. We will allocate agenda time for the following topics (not necessarily in this order) based upon the amount of discussion and specific requests: - Issue summary, Action item status (chairs) - Framework (if needed) (Andy) - RTP usage (Roni, Jonathan) - CLUE schema (Simon, Roberta) - CLUE signaling, examples (Simon, Roberta, Rob) - SDP impacts (Christer, Roni) - Call flows (Rob, Paul K, Simon/Roberta) - Issue summary (revised), Way Forward (Chairs) Please let us know if you would like agenda time for a specific issue or if you've submitted a new document (it might be really helpful to do this to set the context for discussion of issues). Obviously, comments on the agenda items are also welcome. Regards, Mary and Paul ------=_NextPart_000_00A3_01CDA5BB.83F82EC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mary,

On the framework agenda item there is also

htt= p://tools.ietf.org/html/draft-groves-clue-capture-attr-00 that I = would like to discuss, it was deferred from the interim = meeting

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 08 October, 2012 8:03 PM
To: = CLUE
Subject: [clue] IETF-85 plans and = agenda

 

Hi all,

 

We will likely need agenda time to run through all the = new issues, but discussion of those before the meeting would be really = helpful.

 

Note, that the -00 deadline is in one week's time = (Oct. 15th).  The final document deadline is Oct. 22nd. =  

 

We will allocate agenda time for the following topics = (not necessarily in this order) based upon the amount of discussion and = specific requests:

- Issue = summary, Action item status (chairs)

- Framework (if needed) = (Andy)

- RTP usage =  (Roni, Jonathan) 

- CLUE schema (Simon, = Roberta)

- CLUE signaling, = examples (Simon, Roberta, Rob) 

- SDP impacts (Christer, = Roni)

- Call flows (Rob, = Paul K, Simon/Roberta)

- = Issue summary (revised), Way Forward = (Chairs)

 

Please let us know if you would like agenda time for a = specific issue or if you've submitted a new document (it might be really = helpful to do this to set the context for discussion of issues).   = Obviously, comments on the agenda items are also = welcome. 

 

Regards,

Mary and Paul

------=_NextPart_000_00A3_01CDA5BB.83F82EC0-- From Christian.Groves@nteczone.com Mon Oct 8 17:31: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 F084611E80F4 for ; Mon, 8 Oct 2012 17:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.166 X-Spam-Level: X-Spam-Status: No, score=-2.166 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qr+Rad44fQVF for ; Mon, 8 Oct 2012 17:31:39 -0700 (PDT) Received: from ipmail05.adl6.internode.on.net (ipmail05.adl6.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:6:5]) by ietfa.amsl.com (Postfix) with ESMTP id 6BCA411E80DF for ; Mon, 8 Oct 2012 17:31:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAOtvc1B20Sxo/2dsb2JhbAANOLtvhmoBAQEDATIBBRsVCAICBAYLCxgJFg8JAwIBAgFFEwgBAYd7pn+DKZAti0eGEwOSOpZg Received: from ppp118-209-44-104.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.44.104]) by ipmail05.adl6.internode.on.net with ESMTP; 09 Oct 2012 11:01:13 +1030 Message-ID: <5073704C.6070509@nteczone.com> Date: Tue, 09 Oct 2012 11:31:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <506F5411.6040409@omnitor.se> In-Reply-To: <506F5411.6040409@omnitor.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Text media in clue 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, 09 Oct 2012 00:31:40 -0000 Hello Gunnar, A few comments/questions please see my responses below marked [CNG]. Regards, Christian On 6/10/2012 7:41 AM, Gunnar Hellström wrote: > I am sorry, I have not followed clue closely since long. > When I now rapidly browsed the framework, I noticed that there is only > mentioning of the video and audio media. In an early discussion we > found it feasible to include also the third common real-time medium - > text. > All conference-like tools today have some kind of text communication. > I suggest that also CLUE gets its explicit specification about how > text is handled. [CNG] Yes the framework currently only has audio and video based captures. I would agree that there should be something included in the framework to discuss the relationship to text. To what level I think needs to be discussed further. > > We had some very early discussions about this topic, but we had at > that time a bit hard to decide what features of text was clue specific > and what was more normal multimedia communication specific. With the > experience and structure you have now, I think it will be easy for you > to amend the specifications to include at least the real-time text > medium in a fruitful way. [CNG] You've probably seen my draft I think this goes some way in supporting multimedia conferencing scenarios where text is used. However this is in light of text associated with a video capture, not as a separate media stream. > > I made a brief description about how I imagine real-time text might be > used in a clue environment. > Is this a description suitable to start with with the goal to include > what is needed for the text medium in clue specifications? > > -----Description of use of text in a clue > environment-------------------------- > > Text belongs to a modern conference environment. Not only for > accessibility. > It has special characteristics such as [CNG] I think what needs to be considered above is which of the characteristics are applicable to a CLUE advertisement and what would be applicable to being associated with the media stream. I think CLUE information falls largely into two categories: 1. information used to determine what captures to receive and 2. information used to render the received media. With this in mind i'll address the parameters below: > > -positioning in general [CNG] How do you see this as being related to the current spatial attributes in CLUE? Given that a text stream doesn't exist in a physical space is this positioning information associated with where the person generating the text stream is? > -positioning in relation to specific video presentation > -positioning overlaid or not with video, or in unrelated area > -size of text, > -size of area to display in > -background and foreground colour > -visual effects to use if presented overlayed on video > -source address or nickname [CNG] It seems to me that these are largely consumer determined attributes. They don't seem to be the sort of thing that you would base the decision to use one advertised capture over another one on. I guess these could be attributes associated with the media stream itself i.e. signalled via SDP. Is there any support in SDP for these sorts of things today? > -source role [CNG] My draft on CLUE attributes has a parameter for role. Is this the sort of thing you are talking about? > -joint display with other sources or not [CNG] What do you have in mind here? Are you talking about mixing multiple text streams or by other sources do you mean audio and video? > -language > -script [CNG] My draft on CLUE attributes has a parameter for language. I think that this also supports script unless you have something else in mind? > -scope of real-time edits [CNG] Do you have more information on this? From initial reading it seems like this would be more suitable in SDP. > -division in messages > -label style [CNG] Again I'm not sure what these relate to. From initial reading it seems something for SDP. > > For many of these parameters, there is interest to have a default > value assigned by the conference organizer or the source, and a viewer > value assigned by the viewer. The viewer value should in most cases > dominate over the organizer value. > > Characteristics that should have this double source are: > -positioning in general > -positioning in relation to specific video presentation > -positioning overlaid or not with video, or in unrelated area > -size of text, > -size of area to display in > -background and foreground colour > -visual effects to use if presented overlayed on video > -joint display with other sources or not > -label style [CNG] I think this could fall into the realm of SDP. i.e. Once the support of a text capture is decided these specific attributes are sent from the provider to the consumer in the SDP setting up the media stream. > > Some simple use cases: > > 1. Each participant contribute text to a text box underneath their > video. Used for comments, facts that need exact spelling, cut and > paste material. Text flows in real-time as typed in order to minimize > wait time. > > 2. Each participant contribute text to a text box underneath their > video. Used for typed contributions by participants who do not speak > or sign, or to be understood by participants who do not hear. [CNG] I guess the technical requirement for the above two cases is the ability to link a text stream with a particular CLUE video capture. This could be done by assigning a spatial region to a text capture or could be done at a later stage via SDP. > > 3. All participants contribute to text display in a common text box. > Contributions are labeled. Display may be in real-time so that many > entries are built up in real-time simultaneously and moved to a > history area when messages are completed. [CNG] I'm not sure that there's a impact for CLUE in this case. > > 4. One single source of text, a text interpreter, listening to mixed > audio and producing text. Text displayed by default underneath the > video view of the speaking or signing person. [CNG] I think this could be largely supported by the attributes in my draft. > > 5. One single source of text, a text interpreter, listening to mixed > audio from the speaking participants and producing text. Text > displayed in one statically placed text box. Source indicated in > labels mixed with the text. [CNG] I'm not sure there's an impact on CLUE here. There's no spatial relation and it doesn't appear this would drive the selection of audio/video captures. > > 6. One single source of text, a text interpreter, listening to mixed > audio from the speaking participants and producing text. Text > displayed in one statically placed text box underneath the video of a > sign language interpreter. Source indicated in labels mixed with the > text. [CNG] I think the decision of where to display the text i.e. under the sign language interpreter could be driven by a language ("sl") capture parameter value. It doesn't seem that there's other impacts. > > 7. Multiple sources of text in different labeled languages, a text > interpreter per language, listening to mixed audio from the speaking > participants and producing text. Text displayed in one statically > placed text box per language. Language indicated on the text box. > Source indicated in labels mixed with the text. [CNG] I guess if a TEXT capture was introduced and multiple languages were offered then the language attribute could be used to select the language/s to be received. > > > Regards > Gunnar > From ron.even.tlv@gmail.com Tue Oct 9 00:05:38 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 138E221F8758 for ; Tue, 9 Oct 2012 00:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id juWafV4rtc3P for ; Tue, 9 Oct 2012 00:05:37 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7064021F86F7 for ; Tue, 9 Oct 2012 00:05:32 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so2938134wgb.13 for ; Tue, 09 Oct 2012 00:05:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=L+wF9GQF1H90fyYN/WWafmkXPVkin9SpwFU13xL3z7A=; b=zcS26bJJlKczcGwkVAxRhBwj+kbJKrVzLav/7K/DBL3Geazg+rFQaV+aZmu7vgE+GX Vh5IL171aJoHZb9hVzYbgQTxgUWyzOuhuGvbJyOzWswofZfGzBeXZSkbt+vrXVbuFi5f Kss1d9osVDMjWTjladP4FLzgd6iVyfHjPFjddR9bymx/TvEt0EVEtxkWvG6yk/PosrH7 vF2xVGv37vJC0i/+hOrtsb2IXdKiMz2Z1sx8wB2uK1pqixuqZckVGfq77yHv7A/HHlLK Rj/zCLQcvtX6hI1/9/Osl7DtgHYnL15eokx79QGb/srQy0j/IENn12nGRpCH0fbskuX6 zkJg== Received: by 10.180.79.34 with SMTP id g2mr2173075wix.19.1349766331363; Tue, 09 Oct 2012 00:05:31 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id f1sm23554750wiy.2.2012.10.09.00.05.29 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 00:05:30 -0700 (PDT) From: "Roni Even" To: Date: Tue, 9 Oct 2012 09:03:34 +0200 Message-ID: <00f201cda5ec$34d0daa0$9e728fe0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F3_01CDA5FC.F85A6DF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2l68JK0y6ATPvmRa2kC009WuKWiA== Content-Language: en-us Subject: [clue] comment on coclusion 7 of the iterim meeting report 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, 09 Oct 2012 07:05:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00F3_01CDA5FC.F85A6DF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi 7) Empty Advertisement: Is this allowed and what does it mean? Conclusion: Yes. It means you have nothing you are willing to send. May also still want media in other direction. I think that the correct sentence is "It means you have nothing you are willing to advertise". The SDP is still there and you can still send media based on the SDP. BTW: conclusion 9 has some weird characters. Roni ------=_NextPart_000_00F3_01CDA5FC.F85A6DF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

7) Empty = Advertisement:  Is this allowed and what does it mean? =

Conclusion: Yes. It means you have = nothing you are willing to send. May also still want media in other = direction.

 

 

I think that = the correct sentence is “It means you have nothing you are willing = to advertise”. The SDP is still there and you can still send media = based on the SDP.

 

 

BTW: = conclusion 9 has some weird characters.

 

Roni

------=_NextPart_000_00F3_01CDA5FC.F85A6DF0-- From mary.ietf.barnes@gmail.com Tue Oct 9 06:24: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 4BA1221F8746 for ; Tue, 9 Oct 2012 06:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.342 X-Spam-Level: X-Spam-Status: No, score=-103.342 tagged_above=-999 required=5 tests=[AWL=0.256, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aNyL6id+USt for ; Tue, 9 Oct 2012 06:24:20 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2502821F8738 for ; Tue, 9 Oct 2012 06:24:19 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so3355585lam.31 for ; Tue, 09 Oct 2012 06:24:19 -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=ogEaKLVzzToWlCfZCFgNO0MSFbxOjEQ0AHJLsj9IVFc=; b=vME8MWVV8bl9SaNJRsck5WDz73S4I2uI8ajlgWj0J8L/RtXGIB8x9ZmPFb9PFGXPQ4 H0sqCwyaspAVXGW7zU15iFO7yao1IQjpy9mB3XaIGgrvid7cnfhYomuRshQDSgfyIWr2 j+SFHqJhmX/sin8QY4hZjNt+XWXbjnDahmH6t66KBJdIwf+IK0/eB6PZn7sVmpBDvsKa BFrRwVm0FckIbgGJZB3rW2syYYCC30QQSelySzBreIuloi7W9l90LbMtn+qMbcDW3b4d OryjKhb1T4RZnIoHU3jI6sWg0JA/cecQOIajW6xT6EkzOAD4jadJlRge5B5huITP5mBo G/DQ== MIME-Version: 1.0 Received: by 10.152.148.8 with SMTP id to8mr8558910lab.2.1349789058946; Tue, 09 Oct 2012 06:24:18 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 9 Oct 2012 06:24:18 -0700 (PDT) In-Reply-To: <00a201cda5aa$c06ec280$414c4780$@gmail.com> References: <00a201cda5aa$c06ec280$414c4780$@gmail.com> Date: Tue, 9 Oct 2012 08:24:18 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=e89a8f22bd096156c304cba04144 Cc: CLUE Subject: Re: [clue] IETF-85 plans and agenda 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, 09 Oct 2012 13:24:21 -0000 --e89a8f22bd096156c304cba04144 Content-Type: text/plain; charset=ISO-8859-1 If folks can please discuss this document on the mailing list, we'll see where we are at the IET-85 meeting. Mary. On Mon, Oct 8, 2012 at 6:15 PM, Roni Even wrote: > Hi Mary,**** > > On the framework agenda item there is also**** > > http://tools.ietf.org/html/draft-groves-clue-capture-attr-00 that I would > like to discuss, it was deferred from the interim meeting**** > > Roni**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 08 October, 2012 8:03 PM > *To:* CLUE > *Subject:* [clue] IETF-85 plans and agenda**** > > ** ** > > Hi all,**** > > ** ** > > We will likely need agenda time to run through all the new issues, but > discussion of those before the meeting would be really helpful.**** > > ** ** > > Note, that the -00 deadline is in one week's time (Oct. 15th). The final > document deadline is Oct. 22nd. **** > > ** ** > > We will allocate agenda time for the following topics (not necessarily in > this order) based upon the amount of discussion and specific requests:**** > > - Issue summary, Action item status (chairs)**** > > - Framework (if needed) (Andy)**** > > - RTP usage (Roni, Jonathan) **** > > - CLUE schema (Simon, Roberta)**** > > - CLUE signaling, examples (Simon, Roberta, Rob) **** > > - SDP impacts (Christer, Roni)**** > > - Call flows (Rob, Paul K, Simon/Roberta)**** > > - Issue summary (revised), Way Forward (Chairs)**** > > ** ** > > Please let us know if you would like agenda time for a specific issue or > if you've submitted a new document (it might be really helpful to do this > to set the context for discussion of issues). Obviously, comments on the > agenda items are also welcome. **** > > ** ** > > Regards,**** > > Mary and Paul**** > --e89a8f22bd096156c304cba04144 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable If folks can please discuss this document on the mailing list, we'll se= e where we are at the IET-85 meeting.

Mary.

On Mon, Oct 8, 2012 at 6:15 PM, Roni Even <ro= n.even.tlv@gmail.com> wrote:

Hi Mary,

On the framework agenda i= tem there is also

http://tools.ietf.org/html/draft-groves-cl= ue-capture-attr-00 that I would like to discuss, it was deferred from t= he interim meeting

Roni=

=A0

From: clue-bounces@ietf.org [mailto:clue-= bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 08 October, 2012 8:03 PM
To: CLUE
Subject:= [clue] IETF-85 plans and agenda

=A0

Hi = all,

=A0

We will likely need agenda time to run through all the new issues, = but discussion of those before the meeting would be really helpful.<= u>

=A0

Note, that the -00 deadline is in one week's time (Oct. = 15th). =A0The final document deadline is Oct. 22nd. =A0

=A0

We will allocate agenda time for the following topics (not necessarily i= n this order) based upon the amount of discussion and specific requests:=

- Issue summary, Action item status (chai= rs)

- Framework (if need= ed) (Andy)

- RTP usage = =A0(Roni, Jonathan)=A0

- CLUE schema (Simon, Roberta)<= /u>

- CLUE signaling, examples (Simon,= Roberta, Rob)=A0

- SDP = impacts (Christer, Roni)

- Call flows (Rob, Paul K, Simon/Roberta)=

- Issue summary (revise= d), Way Forward (Chairs)

=A0

Please let us know if you would like agen= da time for a specific issue or if you've submitted a new document (it = might be really helpful to do this to set the context for discussion of iss= ues). =A0 Obviously, comments on the agenda items are also welcome.=A0

=A0

Regards,

= Mary and Paul

<= /div>
--e89a8f22bd096156c304cba04144-- From ron.even.tlv@gmail.com Tue Oct 9 08:10:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6141411E808D for ; Tue, 9 Oct 2012 08:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMVQaJO+0d9z for ; Tue, 9 Oct 2012 08:10:03 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3A44A21F854F for ; Tue, 9 Oct 2012 08:10:03 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id dr13so3188122wgb.13 for ; Tue, 09 Oct 2012 08:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=JwZaNzqR6v5W0xgs88wRMEHhEhrF51QrbFRELJBDgjQ=; b=0yswGyTxTXcBxCIF6oYUx0h/VD77x6JPdccJc2n/zzyuq8u/V5ybcjIL4TFBcVXT3F knTH33cmUgkMDu9nIZvOj4WLqrz48DHlecWFBUbjXtyAZoqHQkxuHwv6tiJNQcH5az7J Ha2bbPMXiVaaQfqhiNNHkinNApOPI3qxU1YjxG3PzUh4HhR2qvOK92+bMARkkduPrawC 6GsWdNgI+hE/raZOtSdX16PWLNp1aHSkfduPwROIsOlsOdaycxtSq6Wy+j04fBqZNGHJ /PTsM6qGXVS80YVa6pDZiH15UGJCrgxF9rcGlLSqZOMCSXcyP0wM6LkPgDQU9mPMvnZ7 a8OQ== Received: by 10.180.87.34 with SMTP id u2mr5437460wiz.3.1349795402239; Tue, 09 Oct 2012 08:10:02 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id k20sm25383543wiv.11.2012.10.09.08.09.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 08:10:01 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" References: <00a201cda5aa$c06ec280$414c4780$@gmail.com> In-Reply-To: Date: Tue, 9 Oct 2012 17:08:05 +0200 Message-ID: <010f01cda62f$e4375e40$aca61ac0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0110_01CDA640.A7C13FB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFTVd5IMJJeBF30PB0bC/Y8NRewqQH7TfZaAksv/EiYg3/60A== Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] IETF-85 plans and agenda 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, 09 Oct 2012 15:10:04 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0110_01CDA640.A7C13FB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Mary, I believe that this draft has to do with ticket #10 Roni From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] Sent: 09 October, 2012 3:24 PM To: Roni Even Cc: CLUE Subject: Re: [clue] IETF-85 plans and agenda If folks can please discuss this document on the mailing list, we'll see where we are at the IET-85 meeting. Mary. On Mon, Oct 8, 2012 at 6:15 PM, Roni Even wrote: Hi Mary, On the framework agenda item there is also http://tools.ietf.org/html/draft-groves-clue-capture-attr-00 that I would like to discuss, it was deferred from the interim meeting Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 08 October, 2012 8:03 PM To: CLUE Subject: [clue] IETF-85 plans and agenda Hi all, We will likely need agenda time to run through all the new issues, but discussion of those before the meeting would be really helpful. Note, that the -00 deadline is in one week's time (Oct. 15th). The final document deadline is Oct. 22nd. We will allocate agenda time for the following topics (not necessarily in this order) based upon the amount of discussion and specific requests: - Issue summary, Action item status (chairs) - Framework (if needed) (Andy) - RTP usage (Roni, Jonathan) - CLUE schema (Simon, Roberta) - CLUE signaling, examples (Simon, Roberta, Rob) - SDP impacts (Christer, Roni) - Call flows (Rob, Paul K, Simon/Roberta) - Issue summary (revised), Way Forward (Chairs) Please let us know if you would like agenda time for a specific issue or if you've submitted a new document (it might be really helpful to do this to set the context for discussion of issues). Obviously, comments on the agenda items are also welcome. Regards, Mary and Paul ------=_NextPart_000_0110_01CDA640.A7C13FB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Mary,

I believe that this draft has to do with ticket = #10

Roni

 

From:= = Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
Sent: 09 = October, 2012 3:24 PM
To: Roni Even
Cc: = CLUE
Subject: Re: [clue] IETF-85 plans and = agenda

 

If folks can please discuss this document on the = mailing list, we'll see where we are at the IET-85 = meeting.

 

Mary.

On Mon, Oct 8, 2012 at 6:15 PM, Roni Even <ron.even.tlv@gmail.com> = wrote:

Hi Mary,

On the framework agenda item there is also

http://tools.ietf.org/html/draft-groves-clue-capture-at= tr-00 that I would like to discuss, it was deferred from the interim = meeting

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 08 October, 2012 8:03 PM
To: = CLUE
Subject: [clue] IETF-85 plans and = agenda

 <= /o:p>

Hi = all,

 <= /o:p>

We will = likely need agenda time to run through all the new issues, but = discussion of those before the meeting would be really = helpful.

 <= /o:p>

Note, that = the -00 deadline is in one week's time (Oct. 15th).  The final = document deadline is Oct. 22nd.  

 <= /o:p>

We will = allocate agenda time for the following topics (not necessarily in this = order) based upon the amount of discussion and specific = requests:

- Issue = summary, Action item status (chairs)

- Framework = (if needed) (Andy)

- RTP usage =  (Roni, Jonathan) 

- CLUE = schema (Simon, Roberta)

- CLUE = signaling, examples (Simon, Roberta, = Rob) 

- SDP = impacts (Christer, Roni)

- Call = flows (Rob, Paul K, Simon/Roberta)

- Issue = summary (revised), Way Forward (Chairs)

 <= /o:p>

Please let = us know if you would like agenda time for a specific issue or if you've = submitted a new document (it might be really helpful to do this to set = the context for discussion of issues).   Obviously, comments on the = agenda items are also welcome. 

 <= /o:p>

Regards,

Mary and = Paul

 

------=_NextPart_000_0110_01CDA640.A7C13FB0-- From pkyzivat@alum.mit.edu Tue Oct 9 08:59: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 DA7B021F8698 for ; Tue, 9 Oct 2012 08:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uM8sjSsGOQEL for ; Tue, 9 Oct 2012 08:59:51 -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 3251921F8694 for ; Tue, 9 Oct 2012 08:59:51 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta02.westchester.pa.mail.comcast.net with comcast id 8zSL1k0031c6gX8513zvjf; Tue, 09 Oct 2012 15:59:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id 93uD1k0073ZTu2S3j3uDD4; Tue, 09 Oct 2012 15:54:13 +0000 Message-ID: <507448C9.2080306@alum.mit.edu> Date: Tue, 09 Oct 2012 11:54:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <00f201cda5ec$34d0daa0$9e728fe0$@gmail.com> In-Reply-To: <00f201cda5ec$34d0daa0$9e728fe0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] comment on conclusion 7 of the interim meeting report 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, 09 Oct 2012 15:59:52 -0000 Roni, On 10/9/12 3:03 AM, Roni Even wrote: > Hi > > 7) Empty Advertisement: Is this allowed and what does it mean? > > Conclusion: Yes. It means you have nothing you are willing to send. May > also still want media in other direction. > > I think that the correct sentence is “It means you have nothing you are > willing to advertise”. The SDP is still there and you can still send > media based on the SDP. Hmm. I think what you say requires some discussion. When a clue endpoint connects with another endpoint that doesn't support clue it is clear that one should decide what to do based on the SDP in a normal non-clue way. But when both ends support clue and exchange advertisements it isn't clear to me what should be done about stuff described in SDP that isn't negotiated via the advertisements. ISTM that there are different possible philosophies here, that we haven't discussed, or even realized need to be discussed. Off the top of my head: 1) we could consider that advertisements and configurations provide the high level view of the session, while the SDP provides a lower level mechanism to support that and fill in details. There is a clear mapping from elements in the configurations to elements in the SDP. The meaning of the SDP for proper rendering can't be discerned from the SDP alone - the advertisement and configuration are required to understand it. Any "extra" SDP that isn't referenced from the advertisements and configurations then probably doesn't apply to the telepresence session. It may be ignored, or else may relate to some other "application" sharing the same session. 2) we could consider that the negotiated SDP in the session is the primary representation of the telepresence session. In principle this could be sufficient without exchange of any advertisements and configurations. Advertisements and configurations are exchanged to *supplement* this - provide extra hints about what to do when the SDP itself isn't sufficient, and also to provide hints about what SDP would be fruitful to negotiate. Any SDP that isn't referenced by advertisements and configurations should be taken at face value and fitted into the telepresence session using local algorithms. Frankly I had been thinking that (1) was the intended way. It wasn't until your message that I realized there might be another view. It seems to me that this needs careful consideration. Thanks, Paul From ron.even.tlv@gmail.com Tue Oct 9 09:51:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01A4C1F0C9B for ; Tue, 9 Oct 2012 09:51:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oR7KIr9JE7Rj for ; Tue, 9 Oct 2012 09:51:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4241F0C99 for ; Tue, 9 Oct 2012 09:51:08 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so3713133wey.31 for ; Tue, 09 Oct 2012 09:51:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=QZTw1CS7xNzD7hEcu8GJxed84oChjk8B9r0bsGiReAc=; b=LkYXLgd29RKJgWGxxalrNlC9AaQWKKD3uNd9lVRhAb6o7Y+Js4w7KMg0WjeGs2FuRM mVVadrWcEyeLnfZ7cr8MCCuvXtWuaehPXSTkbNOOHS3hSgcEZfR7ziivzs/FzEP9ryV5 mZQVFYbsm/5HpqBmw9poOLfHmDRAPQv6nvUeJh6gtKBUNWQj4apfKvUXE1GahL62A4+0 fbhcvtsE8zUIj0dySB3Sa5MuWT+dsTbpCcD2myLIileg2Nfa+Yl/wskfPCJXrs1qAn5M f7QNCUxWOKWJe9R8eLVXwYkjHzw6vxZjzcuh0r1u5CclNi4WgqrEYBxkDzGkgUgU4NJ/ NYhw== Received: by 10.180.79.103 with SMTP id i7mr5974701wix.13.1349801468126; Tue, 09 Oct 2012 09:51:08 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id gm7sm29046541wib.10.2012.10.09.09.51.05 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 09:51:06 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <00f201cda5ec$34d0daa0$9e728fe0$@gmail.com> <507448C9.2080306@alum.mit.edu> In-Reply-To: <507448C9.2080306@alum.mit.edu> Date: Tue, 9 Oct 2012 18:49:11 +0200 Message-ID: <012201cda63e$03b1cea0$0b156be0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzf4R9PFNsxej62fgSd5XWrLedBgI5q4MOl1OunTA= Content-Language: en-us Subject: Re: [clue] comment on conclusion 7 of the interim meeting report 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, 09 Oct 2012 16:51:10 -0000 Paul, I think that the change I proposed is in-line with conclusion 9, where the media started based on the first offer answer and the advertisement may be done later. This is also the call flow in http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 . Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 09 October, 2012 5:55 PM To: clue@ietf.org Subject: Re: [clue] comment on conclusion 7 of the interim meeting report Roni, On 10/9/12 3:03 AM, Roni Even wrote: > Hi > > 7) Empty Advertisement: Is this allowed and what does it mean? > > Conclusion: Yes. It means you have nothing you are willing to send. > May also still want media in other direction. > > I think that the correct sentence is "It means you have nothing you > are willing to advertise". The SDP is still there and you can still > send media based on the SDP. Hmm. I think what you say requires some discussion. When a clue endpoint connects with another endpoint that doesn't support clue it is clear that one should decide what to do based on the SDP in a normal non-clue way. But when both ends support clue and exchange advertisements it isn't clear to me what should be done about stuff described in SDP that isn't negotiated via the advertisements. ISTM that there are different possible philosophies here, that we haven't discussed, or even realized need to be discussed. Off the top of my head: 1) we could consider that advertisements and configurations provide the high level view of the session, while the SDP provides a lower level mechanism to support that and fill in details. There is a clear mapping from elements in the configurations to elements in the SDP. The meaning of the SDP for proper rendering can't be discerned from the SDP alone - the advertisement and configuration are required to understand it. Any "extra" SDP that isn't referenced from the advertisements and configurations then probably doesn't apply to the telepresence session. It may be ignored, or else may relate to some other "application" sharing the same session. 2) we could consider that the negotiated SDP in the session is the primary representation of the telepresence session. In principle this could be sufficient without exchange of any advertisements and configurations. Advertisements and configurations are exchanged to *supplement* this - provide extra hints about what to do when the SDP itself isn't sufficient, and also to provide hints about what SDP would be fruitful to negotiate. Any SDP that isn't referenced by advertisements and configurations should be taken at face value and fitted into the telepresence session using local algorithms. Frankly I had been thinking that (1) was the intended way. It wasn't until your message that I realized there might be another view. It seems to me that this needs careful consideration. Thanks, Paul _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Tue Oct 9 11:31:19 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3092E21F8871 for ; Tue, 9 Oct 2012 11:31:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.376 X-Spam-Level: X-Spam-Status: No, score=-0.376 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWvuVzcyqt+V for ; Tue, 9 Oct 2012 11:31:18 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 5FF3D21F8857 for ; Tue, 9 Oct 2012 11:31:18 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta15.westchester.pa.mail.comcast.net with comcast id 90au1k0090mv7h05F6Xmwy; Tue, 09 Oct 2012 18:31:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id 96S81k00K3ZTu2S3X6S8yd; Tue, 09 Oct 2012 18:26:09 +0000 Message-ID: <50746C48.7030604@alum.mit.edu> Date: Tue, 09 Oct 2012 14:26:16 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roni Even References: <00f201cda5ec$34d0daa0$9e728fe0$@gmail.com> <507448C9.2080306@alum.mit.edu> <012201cda63e$03b1cea0$0b156be0$@gmail.com> In-Reply-To: <012201cda63e$03b1cea0$0b156be0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] comment on conclusion 7 of the interim meeting report 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, 09 Oct 2012 18:31:19 -0000 On 10/9/12 12:49 PM, Roni Even wrote: > Paul, > I think that the change I proposed is in-line with conclusion 9, where the > media started based on the first offer answer and the advertisement may be > done later. > This is also the call flow in > http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 . I think there is a difference (at least there could be) between the defaults that apply before the first exchange of advertisements, and what happens later. We discussed the possibility that there could be a well defined "default" advertisement that is assumed until an actual advertisement is received. (Though I don't think we reached any conclusion.) What we didn't discuss what what that default might be, or whether it would be "fixed" or "derived" from the SDP. We *did* discuss the possibility that if there was an explicit way to say you wanted the default advertisement then you might be able to revert to the default advertisement at a later point in the session, and that that could be useful. Perhaps you are suggesting that the "empty" advertisement means the same as the "default" advertisement - to do whatever is implied by the SDP. That is *possible*, but it doesn't seem like the obvious choice to me. Thanks, Paul > Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 09 October, 2012 5:55 PM > To: clue@ietf.org > Subject: Re: [clue] comment on conclusion 7 of the interim meeting report > > Roni, > > On 10/9/12 3:03 AM, Roni Even wrote: >> Hi >> >> 7) Empty Advertisement: Is this allowed and what does it mean? >> >> Conclusion: Yes. It means you have nothing you are willing to send. >> May also still want media in other direction. >> >> I think that the correct sentence is "It means you have nothing you >> are willing to advertise". The SDP is still there and you can still >> send media based on the SDP. > > Hmm. I think what you say requires some discussion. > > When a clue endpoint connects with another endpoint that doesn't support > clue it is clear that one should decide what to do based on the SDP in a > normal non-clue way. > > But when both ends support clue and exchange advertisements it isn't clear > to me what should be done about stuff described in SDP that isn't negotiated > via the advertisements. > > ISTM that there are different possible philosophies here, that we haven't > discussed, or even realized need to be discussed. Off the top of my head: > > 1) we could consider that advertisements and configurations provide the high > level view of the session, while the SDP provides a lower level mechanism to > support that and fill in details. There is a clear mapping from elements in > the configurations to elements in the SDP. The meaning of the SDP for proper > rendering can't be discerned from the SDP alone - the advertisement and > configuration are required to understand it. Any "extra" SDP that isn't > referenced from the advertisements and configurations then probably doesn't > apply to the telepresence session. > It may be ignored, or else may relate to some other "application" > sharing the same session. > > 2) we could consider that the negotiated SDP in the session is the primary > representation of the telepresence session. In principle this could be > sufficient without exchange of any advertisements and configurations. > Advertisements and configurations are exchanged to > *supplement* this - provide extra hints about what to do when the SDP itself > isn't sufficient, and also to provide hints about what SDP would be fruitful > to negotiate. Any SDP that isn't referenced by advertisements and > configurations should be taken at face value and fitted into the > telepresence session using local algorithms. > > Frankly I had been thinking that (1) was the intended way. It wasn't until > your message that I realized there might be another view. > > It seems to me that this needs careful consideration. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From ron.even.tlv@gmail.com Tue Oct 9 12:01: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 4B1B11F0CB8 for ; Tue, 9 Oct 2012 12:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXJxUv9lTTdt for ; Tue, 9 Oct 2012 12:01:38 -0700 (PDT) Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 9B19511E8159 for ; Tue, 9 Oct 2012 12:01:36 -0700 (PDT) Received: by mail-wg0-f42.google.com with SMTP id fm10so2924885wgb.1 for ; Tue, 09 Oct 2012 12:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=mj79fQGqDAQ13f4rIf2hHLjGux8VgmbL3MuOqmypJrg=; b=urD2kFCXXoi3tp+fZNMV5q8UG/4sVix9U99s7shXqhKeE94tflz/G4GbL/KesEWEyj dN5WRBffAbCXVdqRHK1/kCyxBnUDC01P5PzNxezf3r1N6LnKoB8v0AEwJF1Jas96+DnB 77+qj2KD7Oc4RpOBusLKOUFNBE4V+X048lWBtrl+mldvrtvSmuLAzHMSzRX9rkssZmeC Xft1bJ4/QQsP2HktLBAJjTB5f5GIVRnB6bQLrUWsc7fV2/NaEjy5ozFH2f7EawBQaf/P +zGGiq4LAUN9r56crh21jPPauIoqCQgkKrvx0GjzzSrnit0BTmvWooEon59JMdWwJZUh 8GXQ== Received: by 10.216.194.26 with SMTP id l26mr8149186wen.17.1349809295621; Tue, 09 Oct 2012 12:01:35 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id q7sm29685295wiy.11.2012.10.09.12.01.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 12:01:34 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <00f201cda5ec$34d0daa0$9e728fe0$@gmail.com> <507448C9.2080306@alum.mit.edu> <012201cda63e$03b1cea0$0b156be0$@gmail.com> <50746C48.7030604@alum.mit.edu> In-Reply-To: <50746C48.7030604@alum.mit.edu> Date: Tue, 9 Oct 2012 20:59:27 +0200 Message-ID: <001e01cda650$36baf8f0$a430ead0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHzf4R9PFNsxej62fgSd5XWrLedBgI5q4MOAIWyPNICptO505c6bIbA Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] comment on conclusion 7 of the interim meeting report 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, 09 Oct 2012 19:01:39 -0000 Paul, Here is a scenario two endpoints A and B support CLUE. Let's say that A is a one camera system with two monitors that support also H.239 like presentation. So it sends an offer with CLUE channel and the SDP will include the people video stream and the support for BFCP and the content. B responds with similar SDP and the CLUE channel is opened, now B sends an advertisement with one video media capture and also a second capture scene indicating it can send a presentation. So this looks like two similar systems. Now what is the reason for A to send an advertisement, for all-purpose he can close the clue channel and continue as non-clue call. The reason to open the CLUE channel is because the systems do not know when starting the call what is in the other side before opening a CLUE channel. I am not sure what a default advertisement is? I am not sure that there is a requirement to have advertisements in both directions. Also According to SIP, media can flow when a receive port is available in the O/A and I do not think we intend to change the semantic of SIP and this is also what the call flow document described. Practically, it make sense to send media ASAP (at least audio and probably video) in order to provide a better user experience (once connected you expect to be able to speak and hear the other side. BTW: I think that having max-ssrc for SSRC multiplexing can help both side to see that there is no need for CLUE here. Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: 09 October, 2012 8:26 PM To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] comment on conclusion 7 of the interim meeting report On 10/9/12 12:49 PM, Roni Even wrote: > Paul, > I think that the change I proposed is in-line with conclusion 9, where > the media started based on the first offer answer and the > advertisement may be done later. > This is also the call flow in > http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 . I think there is a difference (at least there could be) between the defaults that apply before the first exchange of advertisements, and what happens later. We discussed the possibility that there could be a well defined "default" advertisement that is assumed until an actual advertisement is received. (Though I don't think we reached any conclusion.) What we didn't discuss what what that default might be, or whether it would be "fixed" or "derived" from the SDP. We *did* discuss the possibility that if there was an explicit way to say you wanted the default advertisement then you might be able to revert to the default advertisement at a later point in the session, and that that could be useful. Perhaps you are suggesting that the "empty" advertisement means the same as the "default" advertisement - to do whatever is implied by the SDP. That is *possible*, but it doesn't seem like the obvious choice to me. Thanks, Paul > Roni > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: 09 October, 2012 5:55 PM > To: clue@ietf.org > Subject: Re: [clue] comment on conclusion 7 of the interim meeting > report > > Roni, > > On 10/9/12 3:03 AM, Roni Even wrote: >> Hi >> >> 7) Empty Advertisement: Is this allowed and what does it mean? >> >> Conclusion: Yes. It means you have nothing you are willing to send. >> May also still want media in other direction. >> >> I think that the correct sentence is "It means you have nothing you >> are willing to advertise". The SDP is still there and you can still >> send media based on the SDP. > > Hmm. I think what you say requires some discussion. > > When a clue endpoint connects with another endpoint that doesn't > support clue it is clear that one should decide what to do based on > the SDP in a normal non-clue way. > > But when both ends support clue and exchange advertisements it isn't > clear to me what should be done about stuff described in SDP that > isn't negotiated via the advertisements. > > ISTM that there are different possible philosophies here, that we > haven't discussed, or even realized need to be discussed. Off the top of my head: > > 1) we could consider that advertisements and configurations provide > the high level view of the session, while the SDP provides a lower > level mechanism to support that and fill in details. There is a clear > mapping from elements in the configurations to elements in the SDP. > The meaning of the SDP for proper rendering can't be discerned from > the SDP alone - the advertisement and configuration are required to > understand it. Any "extra" SDP that isn't referenced from the > advertisements and configurations then probably doesn't apply to the telepresence session. > It may be ignored, or else may relate to some other "application" > sharing the same session. > > 2) we could consider that the negotiated SDP in the session is the > primary representation of the telepresence session. In principle this > could be sufficient without exchange of any advertisements and configurations. > Advertisements and configurations are exchanged to > *supplement* this - provide extra hints about what to do when the SDP > itself isn't sufficient, and also to provide hints about what SDP > would be fruitful to negotiate. Any SDP that isn't referenced by > advertisements and configurations should be taken at face value and > fitted into the telepresence session using local algorithms. > > Frankly I had been thinking that (1) was the intended way. It wasn't > until your message that I realized there might be another view. > > It seems to me that this needs careful consideration. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > From ron.even.tlv@gmail.com Tue Oct 9 12:50: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 6DE7311E80A4 for ; Tue, 9 Oct 2012 12:50:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h0v3PZgXZ8wv for ; Tue, 9 Oct 2012 12:50:12 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE6C11E808D for ; Tue, 9 Oct 2012 12:50:11 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hr7so4461564wib.13 for ; Tue, 09 Oct 2012 12:50:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=tEKPL7mCNgJaH+2AK0BwC9E2UMrnwm9ynwYW5VaET+M=; b=b2Wceq8OXmB/eNo0nHsclMYmf1L82EbAggvyi/+XItHe2T0vZlBGag4ajiSMnwndI3 veMAmfh1J72ASK02hsQlA1apW4svxCgb7rKA3d00VvCtvNebIdlH2ydF8W8tDyORbhRJ 1s1zQkuA+eA1h5UJDnAIq2+gVQJrIyMBFbuDzNK4aRTcUyWDscw9HUxW+L0Kt/GPGUBV gPQVMfYxflminIq4keVdCZ77DIyG9s+x1FRxHGtlMKEkuXP1hSS1lQLNAuotnK8ICY4y Nbh2GjBNgiM99C7wERevPou4XVog8CCXwIT2f1Ko982RkoEeATgA+naKxFbaES33OrfV Q9nQ== Received: by 10.180.97.35 with SMTP id dx3mr7008277wib.14.1349812211008; Tue, 09 Oct 2012 12:50:11 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id j8sm26449362wiy.9.2012.10.09.12.50.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Oct 2012 12:50:10 -0700 (PDT) From: "Roni Even" To: Date: Tue, 9 Oct 2012 21:48:03 +0200 Message-ID: <002501cda657$00853d70$018fb850$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CDA667.C4105760" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac2mVUodzypxwnDdRGiUxWgPtoJQSQ== Content-Language: en-us Subject: [clue] Individual and group encode 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, 09 Oct 2012 19:50:13 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0026_01CDA667.C4105760 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, During the conference call yesterday one question was about how to represent individual encodes. Currently the framework has a video encode in table 2 and audio in table 3. For the audio the only parameter is bandwidth The question is do we think we will have one video and one audio for all codecs so for video we will always use from the following table +--------------+----------------------------------------------------+ | Name | Description | +--------------+----------------------------------------------------+ | encodeID | A unique identifier for the individual encoding | | maxBandwidth | Maximum number of bits per second | | maxH264Mbps | Maximum number of macroblocks per second: ((width | | | + 15) / 16) * ((height + 15) / 16) * | | | framesPerSecond | | maxWidth | Video resolution's maximum supported width, | | | expressed in pixels | | maxHeight | Video resolution's maximum supported height, | | | expressed in pixels | | maxFrameRate | Maximum supported frame rate | +--------------+----------------------------------------------------+ Maxh264Mpbs regardless of the coded. In which case the proposal was to change the name to generic maxMbps If we think that there will be a different one for other codecs for example for H.265 we will have a different individual encodes as in the following table, we will need a different element in the schema per codec. +--------------+----------------------------------------------------+ | Name | Description | +--------------+----------------------------------------------------+ | encodeID | A unique identifier for the individual encoding | | maxBandwidth | Maximum number of bits per second | | maxH265Mbps | Maximum number of macroblocks per second: ((width | | | + 15) / 16) * ((height + 15) / 16) * | | | framesPerSecond | | maxWidth | Video resolution's maximum supported width, | | | expressed in pixels | | maxHeight | Video resolution's maximum supported height, | | | expressed in pixels | | maxFrameRate | Maximum supported frame rate | +--------------+----------------------------------------------------+ If we use the two encodes how will the group encode look like using table4 from the framework, how do you calculate all combinations of H264 and H.265. It will work if you use maxgroupMbps as a generic value but does it mean that this is true for different video codecs. +-------------------+-----------------------------------------------+ | Name | Description | +-------------------+-----------------------------------------------+ | encodeGroupID | A unique identifier for the encoding group | | maxGroupBandwidth | Maximum number of bits per second relating to | | | all encodings combined | | maxGroupH264Mbps | Maximum number of macroblocks per second | | | relating to all video encodings combined | | maxGroupH265Mbps | Maximum number of macroblocks per second | | | relating to all video encodings combined | |videoEncodings[264]| Set of potential encodings (list of | | | encodeIDs) | |videoEncodings[265]| Set of potential encodings (list of | | | encodeIDs) | | audioEncodings[] | Set of potential encodings (list of | | | encodeIDs) | +-------------------+-----------------------------------------------+ Thanks Roni ------=_NextPart_000_0026_01CDA667.C4105760 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

During the = conference call yesterday one question was about how to represent = individual encodes.

Currently the = framework has a video encode in table 2 and audio in table = 3.

For the audio the only parameter = is bandwidth

 

The question is do we think we will have one video and = one audio for all codecs so for video we will always use from the = following table

 

+--------------+---------------------------------------------------= -+

   | = Name         | = Description          &n= bsp;           &nb= sp;           &nbs= p;     |

   = +--------------+----------------------------------------------------+

   | = encodeID     | A unique identifier for the = individual encoding    |

   | = maxBandwidth | Maximum number of bits per = second           &= nbsp;      |

   | = maxH264Mbps  | Maximum number of macroblocks per second: = ((width  |

   = |            =   | + 15) / 16) * ((height + 15) / 16) = *            =    |

   = |            =   | = framesPerSecond         &nbs= p;            = ;            =   |

   | = maxWidth     | Video resolution's maximum supported = width,        = |

   = |            =   | expressed in = pixels           &= nbsp;           &n= bsp;        |

   | = maxHeight    | Video resolution's maximum supported = height,       |

   = |            =   | expressed in = pixels           &= nbsp;           &n= bsp;        |

   | = maxFrameRate | Maximum supported frame = rate           &nb= sp;           = |

   = +--------------+----------------------------------------------------+

 

Maxh264Mpbs regardless of the coded. In which case the = proposal was to change the name to generic maxMbps

 

If we think = that there will be a different one for other codecs for example for = H.265 we will have a different individual encodes as in the following = table, we will need a different element in the schema per = codec.

 

+--------------+------------------------------=
----------------------+
   | =
Name         | =
Description          &n=
bsp;           &nb=
sp;           &nbs=
p;     |
   =
+--------------+----------------------------------------------------+
   | =
encodeID     | A unique identifier for the =
individual encoding    |
   | maxBandwidth | Maximum number =
of bits per =
second           &=
nbsp;      |
   | maxH265Mbps  | Maximum =
number of macroblocks per second: ((width  =
|
   =
|            =
  | + 15) / 16) * ((height + 15) / 16) =
*            =
   |
   =
|            =
  | =
framesPerSecond         &nbs=
p;            =
;            =
  |
   | =
maxWidth     | Video resolution's maximum supported =
width,        =
|
   =
|            =
  | expressed in =
pixels           &=
nbsp;           &n=
bsp;        =
|
   | =
maxHeight    | Video resolution's maximum supported =
height,       =
|
   =
|            =
  | expressed in =
pixels           &=
nbsp;           &n=
bsp;        =
|
   | maxFrameRate | =
Maximum supported frame =
rate           &nb=
sp;           =
|
   =
+--------------+----------------------------------------------------+
 

 

 

 

If we use = the two encodes how will the group encode look like using  table4 = from the framework, how do you  calculate all combinations of H264 = and H.265. It will work if you use maxgroupMbps as a generic value but = does it mean that this is true for different video = codecs.

 

 

 

+-------------------+-------------------------=
----------------------+
   | =
Name           &nb=
sp;  | =
Description          &n=
bsp;           &nb=
sp;            =
|
   =
+-------------------+-----------------------------------------------+
   | =
encodeGroupID     | A unique identifier for the =
encoding group    |
   | maxGroupBandwidth | Maximum =
number of bits per second relating to |
   =
|            =
       | all encodings =
combined           =
;            =
 |
   | =
maxGroupH264Mbps  | Maximum number of macroblocks per =
second      |
   =
|            =
       | relating to all video encodings =
combined      |
   | maxGroupH265Mbps  | =
Maximum number of macroblocks per second      =
|
   =
|            =
       | relating to all video encodings =
combined      |
   |videoEncodings[264]| Set of =
potential encodings (list =
of           =
|
   =
|            =
       | =
encodeIDs)          &nb=
sp;           &nbs=
p;            =
; |
   |videoEncodings[265]| =
Set of potential encodings (list =
of           =
|
   =
|            =
       | =
encodeIDs)          &nb=
sp;           &nbs=
p;            =
; |
   | =
audioEncodings[]  | Set of potential encodings (list =
of           =
|
   =
|            =
       | =
encodeIDs)          &nb=
sp;           &nbs=
p;            =
; |
   =
+-------------------+-----------------------------------------------+
 

 

Thanks

Roni

 

------=_NextPart_000_0026_01CDA667.C4105760-- From pkyzivat@alum.mit.edu Tue Oct 9 13:18:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35B6F1F0C44 for ; Tue, 9 Oct 2012 13:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35GxoTi+DxdL for ; Tue, 9 Oct 2012 13:18:03 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 2927E1F0422 for ; Tue, 9 Oct 2012 13:18:01 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta04.westchester.pa.mail.comcast.net with comcast id 900i1k00416LCl0548J6QC; Tue, 09 Oct 2012 20:18:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id 98Cd1k00v3ZTu2S3S8Cdr8; Tue, 09 Oct 2012 20:12:38 +0000 Message-ID: <5074854C.5010705@alum.mit.edu> Date: Tue, 09 Oct 2012 16:13:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roni Even References: <00f201cda5ec$34d0daa0$9e728fe0$@gmail.com> <507448C9.2080306@alum.mit.edu> <012201cda63e$03b1cea0$0b156be0$@gmail.com> <50746C48.7030604@alum.mit.edu> <001e01cda650$36baf8f0$a430ead0$@gmail.com> In-Reply-To: <001e01cda650$36baf8f0$a430ead0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] comment on conclusion 7 of the interim meeting report 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, 09 Oct 2012 20:18:04 -0000 On 10/9/12 2:59 PM, Roni Even wrote: > Paul, > Here is a scenario two endpoints A and B support CLUE. Let's say that A is > a one camera system with two monitors that support also H.239 like > presentation. So it sends an offer with CLUE channel and the SDP will > include the people video stream and the support for BFCP and the content. > B responds with similar SDP and the CLUE channel is opened, now B sends an > advertisement with one video media capture and also a second capture scene > indicating it can send a presentation. So this looks like two similar > systems. Now what is the reason for A to send an advertisement, for OK. That is plausible. System A can decide that the default handling will be sufficient, so that it need not send an advertisement. But it should still send a config for the advertisement from B. > all-purpose he can close the clue channel and continue as non-clue call. The > reason to open the CLUE channel is because the systems do not know when > starting the call what is in the other side before opening a CLUE channel. But advertisements can change mid-call. If the clue channel is closed then that won't be possible. > I am not sure what a default advertisement is? I'm not sure either. We would have to decide how to infer one, and how that relates to the SDP that is negotiated. We need to decide what one does based on the initial SDP in the absence of any advertisement. > I am not sure that there is a requirement to have advertisements in both > directions. Maybe not. But if we can count of them it can ease the initial call setup, possibly eliminating an O/A exchange. (Though we haven't decided if we care about that.) > Also According to SIP, media can flow when a receive port is available in > the O/A and I do not think we intend to change the semantic of SIP and this > is also what the call flow document described. Media can flow. There is no promise about what happens to it. It may all be ignored. The advertisement and config give context to decide how to do something useful with it. > Practically, it make sense to send media ASAP (at least audio and probably > video) in order to provide a better user experience (once connected you > expect to be able to speak and hear the other side. Certainly it makes sense to send *something*. But it might not be what you ultimately want. It might just be a single video stream with a slide announcing the session, and a single audio stream with background music. It might be nothing else gets sent until after an advertisement is sent and a config received. The important thing here is that we are clear enough about expectations that things will interoperate properly. > BTW: I think that having max-ssrc for SSRC multiplexing can help both side > to see that there is no need for CLUE here. I now remember that there was some discussion in SJ that we provide some indication in SDP of those m-lines that are in use by CLUE. Then *other* m-lines could be treated via other mechanisms. Perhaps there is more that we can do with SDP so that some subset of clue can be accomplished without need of clue messaging. But we need to decide if we want to go that way. AFAIK it hasn't been considered. ISTM the minimum is that prior to advertisement/config exchange the media is handled as if this was not a clue session. After the advertisement/config exchange the media would then be processed according to what is written in the clue specs. But I assume there are other ways to define this. I hope some other people will give opinions here so that this isn't just a dialog. I don't have strong opinions about what the right way is here - just that so far we haven't decided and we need to. Thanks, Paul > Roni > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] > Sent: 09 October, 2012 8:26 PM > To: Roni Even > Cc: clue@ietf.org > Subject: Re: [clue] comment on conclusion 7 of the interim meeting report > > On 10/9/12 12:49 PM, Roni Even wrote: >> Paul, >> I think that the change I proposed is in-line with conclusion 9, where >> the media started based on the first offer answer and the >> advertisement may be done later. >> This is also the call flow in >> http://tools.ietf.org/html/draft-romanow-clue-call-flow-02 . > > I think there is a difference (at least there could be) between the defaults > that apply before the first exchange of advertisements, and what happens > later. > > We discussed the possibility that there could be a well defined "default" > advertisement that is assumed until an actual advertisement is received. > (Though I don't think we reached any conclusion.) > > What we didn't discuss what what that default might be, or whether it would > be "fixed" or "derived" from the SDP. > > We *did* discuss the possibility that if there was an explicit way to say > you wanted the default advertisement then you might be able to revert to the > default advertisement at a later point in the session, and that that could > be useful. > > Perhaps you are suggesting that the "empty" advertisement means the same as > the "default" advertisement - to do whatever is implied by the SDP. > That is *possible*, but it doesn't seem like the obvious choice to me. > > Thanks, > Paul > >> Roni >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: 09 October, 2012 5:55 PM >> To: clue@ietf.org >> Subject: Re: [clue] comment on conclusion 7 of the interim meeting >> report >> >> Roni, >> >> On 10/9/12 3:03 AM, Roni Even wrote: >>> Hi >>> >>> 7) Empty Advertisement: Is this allowed and what does it mean? >>> >>> Conclusion: Yes. It means you have nothing you are willing to send. >>> May also still want media in other direction. >>> >>> I think that the correct sentence is "It means you have nothing you >>> are willing to advertise". The SDP is still there and you can still >>> send media based on the SDP. >> >> Hmm. I think what you say requires some discussion. >> >> When a clue endpoint connects with another endpoint that doesn't >> support clue it is clear that one should decide what to do based on >> the SDP in a normal non-clue way. >> >> But when both ends support clue and exchange advertisements it isn't >> clear to me what should be done about stuff described in SDP that >> isn't negotiated via the advertisements. >> >> ISTM that there are different possible philosophies here, that we >> haven't discussed, or even realized need to be discussed. Off the top of > my head: >> >> 1) we could consider that advertisements and configurations provide >> the high level view of the session, while the SDP provides a lower >> level mechanism to support that and fill in details. There is a clear >> mapping from elements in the configurations to elements in the SDP. >> The meaning of the SDP for proper rendering can't be discerned from >> the SDP alone - the advertisement and configuration are required to >> understand it. Any "extra" SDP that isn't referenced from the >> advertisements and configurations then probably doesn't apply to the > telepresence session. >> It may be ignored, or else may relate to some other "application" >> sharing the same session. >> >> 2) we could consider that the negotiated SDP in the session is the >> primary representation of the telepresence session. In principle this >> could be sufficient without exchange of any advertisements and > configurations. >> Advertisements and configurations are exchanged to >> *supplement* this - provide extra hints about what to do when the SDP >> itself isn't sufficient, and also to provide hints about what SDP >> would be fruitful to negotiate. Any SDP that isn't referenced by >> advertisements and configurations should be taken at face value and >> fitted into the telepresence session using local algorithms. >> >> Frankly I had been thinking that (1) was the intended way. It wasn't >> until your message that I realized there might be another view. >> >> It seems to me that this needs careful consideration. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > > From trac+clue@trac.tools.ietf.org Sat Oct 13 11:00:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8636621F84A0 for ; Sat, 13 Oct 2012 11:00:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkLGMsv5MtXd for ; Sat, 13 Oct 2012 11:00:01 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 52C2B21F84A2 for ; Sat, 13 Oct 2012 11:00:00 -0700 (PDT) Received: from localhost ([127.0.0.1]:59405 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN5zz-00008T-Rh; Sat, 13 Oct 2012 19:59:43 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 17:59:43 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/17 Message-ID: <068.25a4178fb63cd674b6552283ea553062@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013180000.52C2B21F84A2@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:00:00 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #17: Action Item: Capture Encoding term X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:00:01 -0000 #17: Action Item: Capture Encoding term Action item ii from 19-20 Sept. 2012 interim. Propose text/definition for "capture encoding" term. Work with Mark to get framework updated. -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: Severity: - | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:01:58 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFB7621F84C5 for ; Sat, 13 Oct 2012 11:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VyGH7QChsqIw for ; Sat, 13 Oct 2012 11:01:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBC421F84A0 for ; Sat, 13 Oct 2012 11:01:57 -0700 (PDT) Received: from localhost ([127.0.0.1]:59637 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN620-0001oR-BJ; Sat, 13 Oct 2012 20:01:48 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:01:48 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/18 Message-ID: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013180157.0BBC421F84A0@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:01:57 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #18: Action Item (v): Limitations on Simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:01:58 -0000 #18: Action Item (v): Limitations on Simulcast From 19-20 Sept. 2012 interim. Andy: Need to define the mechanism to indicate limitations on simulcast in the advertisement. -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: defect | Status: new Priority: major | Milestone: Component: framework | Version: Severity: - | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:04:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8A9A21F84EC for ; Sat, 13 Oct 2012 11:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D0L4WRnRBu0l for ; Sat, 13 Oct 2012 11:04:10 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 490F921F84F1 for ; Sat, 13 Oct 2012 11:04:09 -0700 (PDT) Received: from localhost ([127.0.0.1]:60060 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN64C-0002Qj-4Q; Sat, 13 Oct 2012 20:04:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:04:04 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/19 Message-ID: <068.d87f05873cc859a2fd28e4041467a1a4@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, jonathan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013180409.490F921F84F1@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:04:09 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: jonathan@vidyo.com, clue@ietf.org Subject: [clue] #19: Action item (vi): Site Switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:04:14 -0000 #19: Action item (vi): Site Switching Action vi from 19-20 Sept. 2012 interim. Jonathan: Put out a proposal for discussion of Site Switching (Issue b) -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: - | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:06:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D092621F8513 for ; Sat, 13 Oct 2012 11:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2WBIZWIcJrPd for ; Sat, 13 Oct 2012 11:06:55 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 5C83C21F8532 for ; Sat, 13 Oct 2012 11:06:54 -0700 (PDT) Received: from localhost ([127.0.0.1]:60370 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN66j-00008Z-3f; Sat, 13 Oct 2012 20:06:41 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:06:41 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/20 Message-ID: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> X-Trac-Ticket-ID: 20 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #20: Action item vii: Rejecting Configure X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:06:57 -0000 #20: Action item vii: Rejecting Configure Action item vii from 19-20 Sept. 2012 interim. Andy: Add text to Framework for rejecting Configure -- --------------------------------+---------------------------- Reporter: mary.ietf.barnes@… | Owner: Andy Pepperell Type: task | Status: new Priority: minor | Milestone: Component: framework | Version: Severity: - | Keywords: --------------------------------+---------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:08: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 720D321F84FF for ; Sat, 13 Oct 2012 11:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uunCJfQHZd+I for ; Sat, 13 Oct 2012 11:08:32 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id ADD5F21F84F8 for ; Sat, 13 Oct 2012 11:08:31 -0700 (PDT) Received: from localhost ([127.0.0.1]:60405 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN68M-0005n8-Ih; Sat, 13 Oct 2012 20:08:22 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:08:22 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/18#comment:1 Message-ID: <083.f56300f15d5b06ffea92ab5fe5e8dca1@trac.tools.ietf.org> References: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> X-Trac-Ticket-ID: 18 In-Reply-To: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013180831.ADD5F21F84F8@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:08:31 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:08:32 -0000 #18: Action Item (v): Limitations on Simulcast Changes (by mary.ietf.barnes@…): * type: defect => task * milestone: => milestone1 -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:09: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 BC1BC21F8504 for ; Sat, 13 Oct 2012 11:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D93dAeStmuzM for ; Sat, 13 Oct 2012 11:09:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A428F21F84FF for ; Sat, 13 Oct 2012 11:09:07 -0700 (PDT) Received: from localhost ([127.0.0.1]:60420 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN692-0001gN-9U; Sat, 13 Oct 2012 20:09:04 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:09:04 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/17#comment:1 Message-ID: <083.5613598acbeaccc52aac0d0c13f1bc49@trac.tools.ietf.org> References: <068.25a4178fb63cd674b6552283ea553062@trac.tools.ietf.org> X-Trac-Ticket-ID: 17 In-Reply-To: <068.25a4178fb63cd674b6552283ea553062@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, apeppere@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013180907.A428F21F84FF@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:09:07 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #17: Action Item: Capture Encoding term X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:09:08 -0000 #17: Action Item: Capture Encoding term Changes (by mary.ietf.barnes@…): * type: defect => task -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:12:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76EF021F854C for ; Sat, 13 Oct 2012 11:12:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fXMwd2c+ldL7 for ; Sat, 13 Oct 2012 11:12:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id CEC9921F8533 for ; Sat, 13 Oct 2012 11:12:21 -0700 (PDT) Received: from localhost ([127.0.0.1]:60547 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6C1-0007Sy-KK; Sat, 13 Oct 2012 20:12:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:12:09 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/21 Message-ID: <068.74ec49e3b2befa77b3fe755825856d18@trac.tools.ietf.org> X-Trac-Ticket-ID: 21 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #21: Action Item (viii): CLUE requirements for SCTP/UDP work X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:12:22 -0000 #21: Action Item (viii): CLUE requirements for SCTP/UDP work Action item viii from 19-20 Sept. 2012 interim. Roni: Fwd our requirements to the SCTP/UDP work to define a CLUE channel -- --------------------------------+------------------------ Reporter: mary.ietf.barnes@… | Owner: Roni Even Type: task | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: Severity: - | Keywords: --------------------------------+------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:14:38 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 0D00121F84CE for ; Sat, 13 Oct 2012 11:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EWYYkWmctpDT for ; Sat, 13 Oct 2012 11:14:37 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 715D021F8496 for ; Sat, 13 Oct 2012 11:14:37 -0700 (PDT) Received: from localhost ([127.0.0.1]:60931 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6EL-0005vn-EJ; Sat, 13 Oct 2012 20:14:33 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:14:33 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/22 Message-ID: <068.fb5e79bb27ae7c1fb4b12d1afbef9e96@trac.tools.ietf.org> X-Trac-Ticket-ID: 22 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, keith.drage@alcatel-lucent.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #22: Action item (ix): Out-of-date Advertisements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:14:38 -0000 #22: Action item (ix): Out-of-date Advertisements Action item (ix) from 19-20 Sept. 2012 interim. Keith: Propose text as to how handling of out-of-date advertisements will work. Describe how this optimizes glare as opposed to current model. -- --------------------------------+------------------------- Reporter: mary.ietf.barnes@… | Owner: Keith Drage Type: task | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Keywords: --------------------------------+------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:17:05 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 CC36021F8587 for ; Sat, 13 Oct 2012 11:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cks0N8iWB++T for ; Sat, 13 Oct 2012 11:17:05 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 34CA121F8581 for ; Sat, 13 Oct 2012 11:16:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:32955 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6Gd-0007g3-8L; Sat, 13 Oct 2012 20:16:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:16:55 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/23 Message-ID: <068.b69c95e94f5dac00e03442a516ec8779@trac.tools.ietf.org> X-Trac-Ticket-ID: 23 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, christer.holmberg@ericsson.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #23: Action item (x): Mechanism to know which m-lines are under CLUE control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:17:06 -0000 #23: Action item (x): Mechanism to know which m-lines are under CLUE control Action item x from 19-20 Sept. 2012 interim. Christer: propose a mechanism – e.g, grouping, labels or whatever to know which m-lines are under CLUE control within SDP. (Issue e). Also, need to define how this works within O/A. -- --------------------------------+------------------------------- Reporter: mary.ietf.barnes@… | Owner: Christer Holmberg Type: task | Status: new Priority: major | Milestone: Component: charter | Version: Severity: - | Keywords: --------------------------------+------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:18:59 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 8ED9121F84A1 for ; Sat, 13 Oct 2012 11:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOzZ3rfR9hXz for ; Sat, 13 Oct 2012 11:18:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E9E2321F8498 for ; Sat, 13 Oct 2012 11:18:58 -0700 (PDT) Received: from localhost ([127.0.0.1]:32991 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6IQ-0006Kb-FB; Sat, 13 Oct 2012 20:18:46 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:18:46 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/24 Message-ID: <068.c48fbd7adf469a2fed5e232a09e9eaf6@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, keith.drage@alcatel-lucent.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: [clue] #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:18:59 -0000 #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line Action item xi from 19-20 Sept 2012 interim. Keith: Propose A use case with CLUE and BFCP controlling same m-line. -- ------------------------------------+------------------------- Reporter: mary.ietf.barnes@… | Owner: Keith Drage Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: telepresence-use-cases | Version: Severity: - | Keywords: ------------------------------------+------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:19: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 2E06A21F84EE for ; Sat, 13 Oct 2012 11:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qQ0C0edOE2B for ; Sat, 13 Oct 2012 11:19:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id A2B8F21F84DE for ; Sat, 13 Oct 2012 11:19:20 -0700 (PDT) Received: from localhost ([127.0.0.1]:33004 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6Iw-0002I1-Qt; Sat, 13 Oct 2012 20:19:18 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:19:18 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/24#comment:1 Message-ID: <083.6133aa0428226d8ac4754e7ee1bb08fc@trac.tools.ietf.org> References: <068.c48fbd7adf469a2fed5e232a09e9eaf6@trac.tools.ietf.org> X-Trac-Ticket-ID: 24 In-Reply-To: <068.c48fbd7adf469a2fed5e232a09e9eaf6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: mary.ietf.barnes@gmail.com, keith.drage@alcatel-lucent.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: clue@ietf.org Subject: Re: [clue] #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:19:21 -0000 #24: Action item (xi): Use case - CLUE and BFCP controlling same m-line Changes (by mary.ietf.barnes@…): * type: defect => task -- ------------------------------------+-------------------------- Reporter: mary.ietf.barnes@… | Owner: Keith Drage Type: task | Status: new Priority: minor | Milestone: milestone1 Component: telepresence-use-cases | Version: Severity: - | Resolution: Keywords: | ------------------------------------+-------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:27:16 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 E282521F84F2 for ; Sat, 13 Oct 2012 11:27:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq50tFY6fzeP for ; Sat, 13 Oct 2012 11:27:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 4AC0E21F84F1 for ; Sat, 13 Oct 2012 11:27:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:33761 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6QP-0001J9-Vu; Sat, 13 Oct 2012 20:27:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:27:01 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/16#comment:1 Message-ID: <078.590d9f3d0cee89669120c53780722961@trac.tools.ietf.org> References: <063.e267b5f53214b9814e5c7ad751f09f3f@trac.tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <063.e267b5f53214b9814e5c7ad751f09f3f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013182716.4AC0E21F84F1@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:27:16 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #16: Need a term for a particular encoding of a capture X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:27:17 -0000 #16: Need a term for a particular encoding of a capture Changes (by mary.ietf.barnes@…): * status: new => closed * resolution: => fixed Comment: As discussed at the 19-20 Sept 2012 interim, we have agreed to use the term "capture encoding". A new ticket has been opened for the action item to update the framework accordingly (Ticket #17) -- ------------------------+------------------------------------------ Reporter: pkyzivat@… | Owner: draft-ietf-clue-framework@… Type: task | Status: closed Priority: major | Milestone: milestone1 Component: framework | Version: 1.0 Severity: - | Resolution: fixed Keywords: | ------------------------+------------------------------------------ Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:52: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 D0BD021F8476 for ; Sat, 13 Oct 2012 11:52:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Xm5XJcFcbcq for ; Sat, 13 Oct 2012 11:52:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 20C3321F847C for ; Sat, 13 Oct 2012 11:52:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:35493 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6oV-0008WA-SG; Sat, 13 Oct 2012 20:51:55 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:51:55 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/25 Message-ID: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> X-Trac-Ticket-ID: 25 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013185213.20C3321F847C@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:52:13 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #25: Advertisement: Complete "all" or "delta" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:52:13 -0000 #25: Advertisement: Complete "all" or "delta" Issue a from 19-20 Sept. 2012 interim Need to decide whether advertisement is complete information "all" or just a "delta" [Note: current framework is "all"] -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: framework | Version: Severity: - | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:54:14 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C2821F8487 for ; Sat, 13 Oct 2012 11:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nlImCSxbJucE for ; Sat, 13 Oct 2012 11:54:13 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 55F0421F8480 for ; Sat, 13 Oct 2012 11:54:13 -0700 (PDT) Received: from localhost ([127.0.0.1]:35925 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6qe-0002iQ-Ok; Sat, 13 Oct 2012 20:54:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:54:08 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/26 Message-ID: <068.ed5c91e0436084bdd4318f958b3567b5@trac.tools.ietf.org> X-Trac-Ticket-ID: 26 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121013185413.55F0421F8480@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:54:13 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #26: Site Switching with multiple captures X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:54:14 -0000 #26: Site Switching with multiple captures Issue b from 19-20 Sept. 2012 interim. Site Switching: there is an issue when you have multiple captures and do site switching. It needs to be consistent. May need real-time updates for spatial information, time synchronization, etc. - e.g., RTCP, XCON notifications. This relates to action item/ticket #19. -- --------------------------------+----------------------------------------- Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: - | Keywords: --------------------------------+----------------------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:55:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D121F8493 for ; Sat, 13 Oct 2012 11:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o9cVODsc6aDR for ; Sat, 13 Oct 2012 11:55:57 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id DD1E421F848B for ; Sat, 13 Oct 2012 11:55:56 -0700 (PDT) Received: from localhost ([127.0.0.1]:36321 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6sJ-00043V-N9; Sat, 13 Oct 2012 20:55:51 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:55:51 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/27 Message-ID: <068.49ad0f56a1b7e4e24ddd9a9c01135741@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121013185556.DD1E421F848B@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:55:56 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #27: Avoiding 3rd O/A exchange X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:55:57 -0000 #27: Avoiding 3rd O/A exchange Issue c from 19-20 Sept. 2012 interim. Is there an advantage to not having a 3rd O/A exchange in the session setup? -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: minor | Milestone: Component: charter | Version: 1.0 Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:57:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFF9521F8495 for ; Sat, 13 Oct 2012 11:57:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l9vSLMeqdoD for ; Sat, 13 Oct 2012 11:57:22 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBD421F8493 for ; Sat, 13 Oct 2012 11:57:18 -0700 (PDT) Received: from localhost ([127.0.0.1]:36412 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6tW-0004C8-DJ; Sat, 13 Oct 2012 20:57:06 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:57:06 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/28 Message-ID: <068.16d36ac893f61090f351de0e3f0fd234@trac.tools.ietf.org> X-Trac-Ticket-ID: 28 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121013185718.0BBD421F8493@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:57:18 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #28: Configure message & SDP consistency X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:57:22 -0000 #28: Configure message & SDP consistency Issue d from the 19-20 Sept 2012 interim. Must the configure message be consistent with the current SDP? Needs further consideration….e.g. order that things are changed, etc. Overarching objective is to minimize what info might be duplicated. -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 11:59:16 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 AA32D21F84BF for ; Sat, 13 Oct 2012 11:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNfnf2bCcS8A for ; Sat, 13 Oct 2012 11:59:16 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC2621F8493 for ; Sat, 13 Oct 2012 11:59:16 -0700 (PDT) Received: from localhost ([127.0.0.1]:36559 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6vZ-0004G1-M9; Sat, 13 Oct 2012 20:59:13 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 18:59:13 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/29 Message-ID: <068.e9bc54eab5ae71c56706b1c99a6ebe43@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121013185916.0FC2621F8493@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 11:59:16 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #29: Mechanism to know which m-lines are under CLUE control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 18:59:16 -0000 #29: Mechanism to know which m-lines are under CLUE control -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: major | Milestone: Component: charter | Version: Severity: - | Keywords: Signaling --------------------------------+--------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 12:01:59 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 B4F3921F84D9 for ; Sat, 13 Oct 2012 12:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zQn7BxeTutoN for ; Sat, 13 Oct 2012 12:01:59 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1E84A21F84D2 for ; Sat, 13 Oct 2012 12:01:59 -0700 (PDT) Received: from localhost ([127.0.0.1]:36817 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN6yA-00009z-4C; Sat, 13 Oct 2012 21:01:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 19:01:54 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/29#comment:1 Message-ID: <083.555bfdf31ede12b95395a67b0be66957@trac.tools.ietf.org> References: <068.e9bc54eab5ae71c56706b1c99a6ebe43@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <068.e9bc54eab5ae71c56706b1c99a6ebe43@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121013190159.1E84A21F84D2@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 12:01:59 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #29: Mechanism to know which m-lines are under CLUE control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 19:01:59 -0000 #29: Mechanism to know which m-lines are under CLUE control Changes (by mary.ietf.barnes@…): * milestone: => milestone1 -- --------------------------------+---------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: Severity: - | Resolution: Keywords: Signaling | --------------------------------+---------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 12:06:30 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 0471021F84D4 for ; Sat, 13 Oct 2012 12:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O55RUYewr-TN for ; Sat, 13 Oct 2012 12:06:28 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id EB1CF21F84DD for ; Sat, 13 Oct 2012 12:06:25 -0700 (PDT) Received: from localhost ([127.0.0.1]:37554 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN72D-00020d-9f; Sat, 13 Oct 2012 21:06:05 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 19:06:05 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/29#comment:2 Message-ID: <083.0698b63b219f67931b895b1be00128d5@trac.tools.ietf.org> References: <068.e9bc54eab5ae71c56706b1c99a6ebe43@trac.tools.ietf.org> X-Trac-Ticket-ID: 29 In-Reply-To: <068.e9bc54eab5ae71c56706b1c99a6ebe43@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121013190625.EB1CF21F84DD@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 12:06:25 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #29: Mechanism to know which m-lines are under CLUE control X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 19:06:30 -0000 #29: Mechanism to know which m-lines are under CLUE control Comment (by mary.ietf.barnes@…): [This should be the ticket description, but the tool won't let me add it.] Issue e from 19-20 Sept. 2012 interim. Note: this relates to Ticket #23 (Action item). Need a mechanism to know which m-lines are under CLUE control within SDP. Also, need to define how this works within O/A. -- --------------------------------+---------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: Severity: - | Resolution: Keywords: Signaling | --------------------------------+---------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 12:07:59 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 112FB21F84D5 for ; Sat, 13 Oct 2012 12:07:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IG0PvvDVY0Ok for ; Sat, 13 Oct 2012 12:07:58 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 7898D21F84D4 for ; Sat, 13 Oct 2012 12:07:51 -0700 (PDT) Received: from localhost ([127.0.0.1]:37586 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN73t-0000Ib-St; Sat, 13 Oct 2012 21:07:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 19:07:49 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/30 Message-ID: <068.ff18224b821beed6e12e974e9a67a456@trac.tools.ietf.org> X-Trac-Ticket-ID: 30 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121013190751.7898D21F84D4@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 12:07:51 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #30: CLUE and BFCP: controlling same m-line X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 19:07:59 -0000 #30: CLUE and BFCP: controlling same m-line Issue f from 19-20 Sept. 2012 interim. Note: this relates to Ticket #24 (Action item). Can CLUE and BFCP control the same m-line? How do CLUE and BFCP interact? What resources do we want to control with a floor in CLUE? To the level of capture (or scene)? What are semantics? Who drives? Configure or Advertisement? A use case would be helpful. -- --------------------------------+--------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: minor | Milestone: milestone1 Component: charter | Version: Severity: - | Keywords: Signaling --------------------------------+--------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Sat Oct 13 12:09:20 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 A36B021F8467 for ; Sat, 13 Oct 2012 12:09:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIvUlUh7N92a for ; Sat, 13 Oct 2012 12:09:20 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id E664521F845F for ; Sat, 13 Oct 2012 12:09:19 -0700 (PDT) Received: from localhost ([127.0.0.1]:37610 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TN75J-0001rt-RJ; Sat, 13 Oct 2012 21:09:17 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Sat, 13 Oct 2012 19:09:17 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/31 Message-ID: <068.63e0efe6ab2aba726bfb581e35939a76@trac.tools.ietf.org> X-Trac-Ticket-ID: 31 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121013190919.E664521F845F@ietfa.amsl.com> Resent-Date: Sat, 13 Oct 2012 12:09:19 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: [clue] #31: CLUE state machine X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 19:09:20 -0000 #31: CLUE state machine Issue g from 19-20 Sept. 2012 interim. Define a (minimal) state machine. (Note this relates to the CLUE instance and is couple with protocol state machine) -- --------------------------------+-------------------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: charter | Version: Severity: - | Keywords: Signaling, State Machine --------------------------------+-------------------------------------- Ticket URL: clue From ron.even.tlv@gmail.com Sat Oct 13 16:22:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543A221F8445 for ; Sat, 13 Oct 2012 16:22:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjJXGK5b25XK for ; Sat, 13 Oct 2012 16:22:09 -0700 (PDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 97F0221F8444 for ; Sat, 13 Oct 2012 16:22:09 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id u46so2623821wey.31 for ; Sat, 13 Oct 2012 16:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=uzTOf8Zb32LoPjemqMBiuU74wMisztIpuJOviswkSlM=; b=wdmgeHZa7UpvS5fxxMG3aqs0wOTA4qgKYnLYbiB1j2DVZIdnENYy5KCYFERap2esN0 IpO8p2PyzGSGUTRBhvvnrb1ox7OtGBuNjQP9Ib8EtClMfwZyUHzXoq3JPgD7o3FEVGcI gcUsFnTz/9LoQaReBUsb4bkj7FEx7GzmxBRy/tVdfR2eZJji8ZhzS2TUJTIJxTGu0WYp qmVmF7x1Fmc8KFMLirdoHW3PPnCeCEXqnmmbRcRdrIVgzWX6IExKJFCaLsPsWH/O0E8S 5JW8yjl9bZCdKGW3UHdm/Hao/O5ZxYXDLjjSVtGhYZNLDRTsulBVEEKeV6B98o3KntrT 9CYQ== Received: by 10.180.79.34 with SMTP id g2mr14334809wix.19.1350170528619; Sat, 13 Oct 2012 16:22:08 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id a10sm6369962wiz.4.2012.10.13.16.22.05 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 13 Oct 2012 16:22:07 -0700 (PDT) From: "Roni Even" To: "'clue issue tracker'" , , References: <068.49ad0f56a1b7e4e24ddd9a9c01135741@trac.tools.ietf.org> In-Reply-To: <068.49ad0f56a1b7e4e24ddd9a9c01135741@trac.tools.ietf.org> Date: Sun, 14 Oct 2012 01:20:00 +0200 Message-ID: <024501cda999$4687d590$d39780b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFBYrvKS66aIPB0U+J/ZHaFt8xaHJjQbM4g Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] #27: Avoiding 3rd O/A exchange X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Oct 2012 23:22:10 -0000 Hi, I am not sure what this means, what are the first and second O/A in the = session setup Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = clue issue tracker Sent: 13 October, 2012 8:56 PM To: clue-chairs@tools.ietf.org; mary.ietf.barnes@gmail.com Cc: clue@ietf.org Subject: [clue] #27: Avoiding 3rd O/A exchange #27: Avoiding 3rd O/A exchange Issue c from 19-20 Sept. 2012 interim. Is there an advantage to not having a 3rd O/A exchange in the session = setup? --=20 --------------------------------+--------------------------- Reporter: mary.ietf.barnes@=E2=80=A6 | Owner: = clue-chairs@=E2=80=A6 Type: enhancement | Status: new Priority: minor | Milestone: Component: charter | Version: 1.0 Severity: - | Keywords: --------------------------------+--------------------------- Ticket URL: clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Sun Oct 14 10:58: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 AB40821F8469 for ; Sun, 14 Oct 2012 10:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.368 X-Spam-Level: X-Spam-Status: No, score=-0.368 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weD4ly4dhuxY for ; Sun, 14 Oct 2012 10:58:51 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 4797721F8459 for ; Sun, 14 Oct 2012 10:58:51 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta09.westchester.pa.mail.comcast.net with comcast id B5ek1k0011swQuc595yv19; Sun, 14 Oct 2012 17:58:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id B5wa1k00K3ZTu2S3b5wab4; Sun, 14 Oct 2012 17:56:34 +0000 Message-ID: <507AFC2E.3030008@alum.mit.edu> Date: Sun, 14 Oct 2012 13:53:50 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> In-Reply-To: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Rejecting Advertisements X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 17:58:52 -0000 (as individual) Perhaps it shouldn't overload Issue#20 on rejecting configure messages, but ISTM there also needs to be a way to reject an advertisement. There are more reasons for rejecting a config (e.g. it references an advertisement that is no longer remembered), but there are reasons in common between the two: e.g. syntactically incorrect message. Thanks, Paul On 10/13/12 2:06 PM, clue issue tracker wrote: > #20: Action item vii: Rejecting Configure > > Action item vii from 19-20 Sept. 2012 interim. > > Andy: Add text to Framework for rejecting Configure > From pkyzivat@alum.mit.edu Sun Oct 14 11:37:34 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 6DD6121F84D6 for ; Sun, 14 Oct 2012 11:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORFQ2uEotULK for ; Sun, 14 Oct 2012 11:37:34 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id BD32B21F8496 for ; Sun, 14 Oct 2012 11:37:33 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id B0Gq1k0060mv7h0536ddoS; Sun, 14 Oct 2012 18:37:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id B6YN1k00r3ZTu2S3X6YNCN; Sun, 14 Oct 2012 18:32:23 +0000 Message-ID: <507B053F.5090801@alum.mit.edu> Date: Sun, 14 Oct 2012 14:32:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <068.49ad0f56a1b7e4e24ddd9a9c01135741@trac.tools.ietf.org> <024501cda999$4687d590$d39780b0$@gmail.com> In-Reply-To: <024501cda999$4687d590$d39780b0$@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #27: Avoiding 3rd O/A exchange X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Oct 2012 18:37:34 -0000 On 10/13/12 7:20 PM, Roni Even wrote: > Hi, > I am not sure what this means, what are the first and second O/A in the session setup > Roni Maybe it can be stated better. As I see it, the point is that a new configure *may* require an O/A (before or after the configure) to set up the sip session to convey what has been configured. At the start of a new clue session it will be common to exchange advertisements and configures. This *could* result in: - an initial O/A to establish the sip session and clue channel - an O/A to set up the media for the configure from A to B - an O/A to set up the media for the configure from B to A There may be lots of cases one or two of these may not be needed even without special care. But worst case could require this. So the first question - the one that this Issue raises - is whether we care about this enough to even worry about it. (Suppose it turns out that this will be required *most* of the time. Do we care then?) If we care, and would like to have a high probability that only two O/As, or only one, are required, then we need to consider it as part of the signaling design. I think I can safely say that session establishment between dissimilar systems cannot be guaranteed to take less than two O/As. The more we put into SDP the less likely it is that it will *ever* be possible to do it with a single O/A. If we structure things so that advertisements and configurations can be *exchanged* prior to the 2nd O/A of the session, then I think we can largely guarantee that 2nd O/A will be sufficient to satisfy both configurations. This will require some planning so that both sides understand and know to defer the O/A until the exchange is complete. While it is highly likely that there will be a roughly concurrent exchange of configurations at the beginning of the session, after that it will probably be highly unlikely to get concurrent configs. So in that mode it will be appropriate to initiate any needed O/A change in conjunction with the single config, without first awaiting one from the other side. Since the non-concurrent case needs to be supported anyway, it will simplify protocol specification and implementation to omit any special case handling of the initial session setup, and just live with the extra O/A this might cause. Thanks, Paul > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of clue issue tracker > Sent: 13 October, 2012 8:56 PM > To: clue-chairs@tools.ietf.org; mary.ietf.barnes@gmail.com > Cc: clue@ietf.org > Subject: [clue] #27: Avoiding 3rd O/A exchange > > #27: Avoiding 3rd O/A exchange > > Issue c from 19-20 Sept. 2012 interim. > > Is there an advantage to not having a 3rd O/A exchange in the session setup? > From spromano@unina.it Mon Oct 15 08:44:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2DEB21F8751 for ; Mon, 15 Oct 2012 08:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.468 X-Spam-Level: X-Spam-Status: No, score=-98.468 tagged_above=-999 required=5 tests=[AWL=-0.163, BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sskQZemrzEyN for ; Mon, 15 Oct 2012 08:44:01 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7F16521F8749 for ; Mon, 15 Oct 2012 08:44:01 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q9FFhb5t026607 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 15 Oct 2012 17:43:56 +0200 Message-ID: <507C2F0C.6040101@unina.it> Date: Mon, 15 Oct 2012 17:43:08 +0200 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 8bit Cc: Roberta Presta Subject: [clue] Clue data model updates 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, 15 Oct 2012 15:44:02 -0000 Hi all, by following the comments we received during the last call, we propose to modify the data model as follows: * New media capture type definition: The main change is the insertion of a choice section which is devoted to convey the spatial information of the capture: Such a definition requires that only one among the three elements (, , ) can appear inside a media capture type. - case : when this element is present inside a media capture, it means that we are describing a capture gathered inside the telepresence room from a certain capture point. That can be the case of participants' video streams, or of the loudest panel stream, etc. A reference to the capture point must be provided inside the element. The spatial information represented by the capture point is the minimum possible one and it is mandatory for each stream captured in the telepresence room that would be sent. Such a spatial information can be enriched with further information in case of video captures: the video capture type, indeed, envisions the presence of a element that specifies the area represented by the stream. - case : this is the case for streams associated with registrations, DVDs, registered presentation, or external streams, that are played in the telepresence room and transmitted to remote sites. For such streams, it does not exist a capture point inside the room. This can also be the case of text streams that are sent from a remote site to another one, or for the output analysis document of a telemedicine machinary. Since such streams are not associated with spatial coordinates inside the room, it does not make sense provide them with spatial information. The reproduction of them in a remote site does not need any spatial information knowledge. - case : when this element is shown in a media capture, it means that the capture is made by mixing more captures together. This is the case of the telepresence room audio stream composed by the participants' audio taken from different camera microphones. Moreover, this can be the case of a video stream realized by overlapping picture-in-picture (PiP) the loudest panel stream with the other participants' streams. Such captures don't have a single point of capture. As stated in the framework document regarding the PiP video example, the biggest area which is represented by such a stream should be indicated. The datamodel schema preserves that possibility, since there is a element in the video capture type which can be used to convey that information. On the other hand, for mixed audio streams, no spatial information is provided. A possible alternative to that approach could be the one of listing the capture points of each component stream. However, this can be onerous and not always possible when including in the mix also non-spatially-definible streams. * capture point type and capture axis point The capture axis point, as envisioned in the framework document, provides the direction pointed by the capture device placed in a certain capture point. Since specifying a capture axis point without a capture point does not make any sense, the capture point type has a child element named : in such a way a capture axis point can not exist without a capture point. The definition of the capture point type is then the following: * a new child: In order to list the capture points in a telepresence room, a new child element of the clue info type has been added: . The capture points therein listed can be referred in the media captures through the element. The current aspect of the clue info type is then the following: The definition of the capture points type is the following: Comments are welcome. Cheers, Roberta & Simon -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From trac+clue@trac.tools.ietf.org Mon Oct 15 08:45: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 7323921F87BD for ; Mon, 15 Oct 2012 08:45:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHuQJdD3oW4f for ; Mon, 15 Oct 2012 08:45:07 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id D5DE521F8749 for ; Mon, 15 Oct 2012 08:45:02 -0700 (PDT) Received: from localhost ([127.0.0.1]:42965 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNmqX-0004Hw-LD; Mon, 15 Oct 2012 17:44:49 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: clue-chairs@tools.ietf.org, ron.even.tlv@gmail.com, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 15 Oct 2012 15:44:49 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/27#comment:2 Message-ID: <083.1e186f27c35a685512bec6f581044f43@trac.tools.ietf.org> References: <068.49ad0f56a1b7e4e24ddd9a9c01135741@trac.tools.ietf.org> X-Trac-Ticket-ID: 27 In-Reply-To: <068.49ad0f56a1b7e4e24ddd9a9c01135741@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: clue-chairs@tools.ietf.org, ron.even.tlv@gmail.com, mary.ietf.barnes@gmail.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu, Resent-Message-Id: <20121015154502.D5DE521F8749@ietfa.amsl.com> Resent-Date: Mon, 15 Oct 2012 08:45:02 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: clue@ietf.org Subject: Re: [clue] #27: Avoiding 3rd O/A exchange X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:45:08 -0000 #27: Avoiding 3rd O/A exchange Comment (by mary.ietf.barnes@…): Discussion at Oct. 15, 2012 design team meeting: - Paul noted that he explicitly avoided 3rd O/A in his call flows - Issue may be more due to glare - Can't really decide this in isolation - Suggest to provide guidelines on how to do media so that we can avoid the 3rd O/A - Usually want to send SDP before config to provide context (initially) - Discussion as to whether config should always be within the context of the O/A(SDP) - Suggestion that anything needed by intermediary needs to be in SDP Need to revisit this one once signaling details (what goes in CLUE, what goes in SDP) are resolved. -- --------------------------------+---------------------------- Reporter: mary.ietf.barnes@… | Owner: clue-chairs@… Type: enhancement | Status: new Priority: minor | Milestone: Component: charter | Version: 1.0 Severity: - | Resolution: Keywords: | --------------------------------+---------------------------- Ticket URL: clue From trac+clue@trac.tools.ietf.org Mon Oct 15 08:55:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96C41F0C6E for ; Mon, 15 Oct 2012 08:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPAE9ulqwpuk for ; Mon, 15 Oct 2012 08:55:36 -0700 (PDT) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [77.72.230.30]) by ietfa.amsl.com (Postfix) with ESMTP id 1ABCD1F0C44 for ; Mon, 15 Oct 2012 08:55:36 -0700 (PDT) Received: from localhost ([127.0.0.1]:44070 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1TNn0h-0008Ch-NM; Mon, 15 Oct 2012 17:55:19 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "clue issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com X-Trac-Project: clue Date: Mon, 15 Oct 2012 15:55:19 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/19#comment:1 Message-ID: <083.c29d9acd1ca22cb048d5ddd90655e287@trac.tools.ietf.org> References: <068.d87f05873cc859a2fd28e4041467a1a4@trac.tools.ietf.org> X-Trac-Ticket-ID: 19 In-Reply-To: <068.d87f05873cc859a2fd28e4041467a1a4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mary.ietf.barnes@gmail.com, jonathan@vidyo.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: allyn@cisco.com, apeppere@gmail.com, bbaldino@cisco.com, mark.duckworth@polycom.com Resent-Message-Id: <20121015155536.1ABCD1F0C44@ietfa.amsl.com> Resent-Date: Mon, 15 Oct 2012 08:55:36 -0700 (PDT) Resent-From: trac+clue@trac.tools.ietf.org Cc: jonathan@vidyo.com, clue@ietf.org Subject: Re: [clue] #19: Action item (vi): Site Switching X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Oct 2012 15:55:36 -0000 #19: Action item (vi): Site Switching Description changed by mary.ietf.barnes@…: Old description: > Action vi from 19-20 Sept. 2012 interim. > > Jonathan: Put out a proposal for discussion of Site Switching (Issue b) New description: Action vi from 19-20 Sept. 2012 interim. Jonathan: Put out a proposal for discussion of Site Switching (Ticket #26) -- -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@… | Owner: draft-ietf-clue-framework@… Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue From pkyzivat@alum.mit.edu Mon Oct 15 09:32: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 0928821F873E for ; Mon, 15 Oct 2012 09:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.358 X-Spam-Level: X-Spam-Status: No, score=-0.358 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDfjvo-bmeLc for ; Mon, 15 Oct 2012 09:32:53 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 45D2421F872E for ; Mon, 15 Oct 2012 09:32:53 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta03.westchester.pa.mail.comcast.net with comcast id BNHe1k00916LCl053UYxFi; Mon, 15 Oct 2012 16:32:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id BUTU1k00i3ZTu2S3SUTUgz; Mon, 15 Oct 2012 16:27:28 +0000 Message-ID: <507C3988.8050001@alum.mit.edu> Date: Mon, 15 Oct 2012 12:27:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <507C2F0C.6040101@unina.it> In-Reply-To: <507C2F0C.6040101@unina.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Clue data model updates 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, 15 Oct 2012 16:32:54 -0000 (as individual) Simon & Roberta, For the most part this seems good. I have a few comments inline. Thanks, Paul On 10/15/12 11:43 AM, Simon Pietro Romano wrote: [snip] > - case : > when this element is shown in a media capture, it means that the capture > is made by mixing more captures together. > This is the case of the telepresence room audio stream composed by the > participants' audio taken from different camera microphones. > Moreover, this can be the case of a video stream realized by overlapping > picture-in-picture (PiP) the loudest panel stream with the other > participants' streams. > Such captures don't have a single point of capture. > As stated in the framework document regarding the PiP video example, the > biggest area which is represented by such a stream should be indicated. > The datamodel schema preserves that possibility, since there is a > element in the video capture type which can be used to > convey that information. > On the other hand, for mixed audio streams, no spatial information is > provided. Now that you have detailed the video case, ISTM that there ought to be *some* spatial information about audio. (Disclaimer: I know *nothing* about audio processing.) I realize that audio can't be bounded the way video is. But surely there is a big difference between an omni-directional mic at the capture point and a mic that is focused along the capture axis. Shouldn't that distinction be captured? (I realize this is primarily a question about the framework, not the data model.) [snip] > * a new child: > > In order to list the capture points in a telepresence room, a new child > element of the clue info type has been added: . > The capture points therein listed can be referred in the media captures > through the element. > The current aspect of the clue info type is then the following: > > > > > > > > > > > maxOccurs="unbounded"/> > > > > > > The definition of the capture points type is the following: > > > > > maxOccurs="unbounded"/> > > > > I think this mishandles some of the semantic constraints in the framework. An advertisement contains multiple scenes. Each scene has a single scaletype and coordinate space. While a capture can be present in multiple capture sets, it can only be in the capture sets of a single scene. That constraint isn't reflected in the model. If it were, then there would be a separate set of capturepoints for each scene, and no need to specify the scaletype within capturePointsType. As written above all capture points, even from multiple scenes, must have the same scale type, and so all scenes are also forced to have the same scale type. From roni.even@mail01.huawei.com Mon Oct 15 10:10:24 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 1B32F11E80F9 for ; Mon, 15 Oct 2012 10:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.495 X-Spam-Level: X-Spam-Status: No, score=-0.495 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aUC7h+Ao+yDS for ; Mon, 15 Oct 2012 10:10:22 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (unknown [58.251.153.224]) by ietfa.amsl.com (Postfix) with ESMTP id 19E9911E80F7 for ; Mon, 15 Oct 2012 10:10:21 -0700 (PDT) Received: from szxpml201-edg.exmail.huawei.com ([172.17.1.119]) by hwsga02-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id ADR43679; Tue, 16 Oct 2012 01:10:17 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml201-edg.exmail.huawei.com 5 none From: Roni Even To: "clue@ietf.org" Thread-Topic: New Version Notification for draft-even-clue-sdp-clue-relation-00.txt Thread-Index: AQHNqvfCxXkS6QqUpk6HlvQYG67ltZe6maSY Date: Mon, 15 Oct 2012 17:10:15 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B455AC@szxpml504-mbx.exmail.huawei.com> References: <20121015170853.17272.43082.idtracker@ietfa.amsl.com> In-Reply-To: <20121015170853.17272.43082.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] FW: New Version Notification for draft-even-clue-sdp-clue-relation-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: Mon, 15 Oct 2012 17:10:24 -0000 Hi, This is an initial draft specifying the objectives of the draft, I will add= content during the week and submit a new revision Roni ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, October 15, 2012 7:08 PM To: Roni Even Subject: New Version Notification for draft-even-clue-sdp-clue-relation-00.= txt A new version of I-D, draft-even-clue-sdp-clue-relation-00.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-clue-sdp-clue-relation Revision: 00 Title: Signalling of CLUE and SDP offer/answer Creation date: 2012-10-15 WG ID: Individual Submission Number of pages: 4 URL: http://www.ietf.org/internet-drafts/draft-even-clue-sdp-cl= ue-relation-00.txt Status: http://datatracker.ietf.org/doc/draft-even-clue-sdp-clue-r= elation Htmlized: http://tools.ietf.org/html/draft-even-clue-sdp-clue-relati= on-00 Abstract: This document describes the relation between the different CLUE attributes as specified in the CLUE framework and the SDP attrbutes. The document will discuss the issues with the CLUE call signalling in order to keep the consisyency bewteen the Offer/answer state and the CLUE state. The IETF Secretariat= From mary.ietf.barnes@gmail.com Mon Oct 15 11:02:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A94B21F8864 for ; Mon, 15 Oct 2012 11:02:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.379 X-Spam-Level: X-Spam-Status: No, score=-103.379 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SpJ3-Czay9Un for ; Mon, 15 Oct 2012 11:02:36 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5A2A321F8880 for ; Mon, 15 Oct 2012 11:02:36 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4084033lam.31 for ; Mon, 15 Oct 2012 11:02:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=yqXbj7y/OV2cCTOZcsmbm0V2gQVsrqLCQktkLyN2l/8=; b=Lq+1a27mMz3qhAo69jpowq38z5T6gARACZ3CJxTFJyOHOtwAJpTKzOzzZR0e2YAoz6 AeutVKRUI6ogR7S/xFK0w2nzrzY2UxK0N8631WgmXCfgw+PfKDE+fDbSw3PX+OmfQFpe bwfMXggf28KVs3ovLr2PnbCFgY6xwfaDZ3mkQLaH0/ILG9X68ogTx7l/DM2Inz9+fkBU 42cTEPyPFx/oEdlENPj7aRzWl1uZdDb2obY+nm7yn0A4GyzFv0nWDUbHYD8nv7anLi3v Sx1wD+sqrZN7QFjzNmrWkg6YRMNRR8lPVEeN1Gq81iWmH533zHPMiZNnC9BeAZ6yNDu5 zNtA== MIME-Version: 1.0 Received: by 10.112.8.226 with SMTP id u2mr4645685lba.22.1350324155271; Mon, 15 Oct 2012 11:02:35 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 15 Oct 2012 11:02:35 -0700 (PDT) In-Reply-To: <20121015175109.26451.17876.idtracker@ietfa.amsl.com> References: <20121015175109.26451.17876.idtracker@ietfa.amsl.com> Date: Mon, 15 Oct 2012 13:02:35 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e0cb4efe32709b49c604cc1cd773 Subject: [clue] Fwd: Internet Draft Initial Version (-00) Cut-Off Today 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, 15 Oct 2012 18:02:37 -0000 --e0cb4efe32709b49c604cc1cd773 Content-Type: text/plain; charset=ISO-8859-1 FYI... ---------- Forwarded message ---------- From: IETF Secretariat Date: Mon, Oct 15, 2012 at 12:51 PM Subject: Internet Draft Initial Version (-00) Cut-Off Today To: IETF Announcement List This is a reminder that the Internet Draft Initial Version (-00) cut-off is today, Monday, October 15, 2012. All Initial Version (-00) submissions are due by UTC 24:00. All drafts can be uploaded using the ID submission tool located here: https://datatracker.ietf.org/submit/ The Internet-Draft cutoff dates as well as other significant dates for IETF 85 can be found at: https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85 Thank you for your understanding and cooperation. If you have any questions or concerns, then please send a message to internet-drafts@ietf.org. --e0cb4efe32709b49c604cc1cd773 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable FYI...

---------- Forwarded message -----= -----
From: IETF Secretariat <ietf-secretariat@= ietf.org>
Date: Mon, Oct 15, 2012 at 12:51 PM
Subject: Internet Draft Initial Vers= ion (-00) Cut-Off Today
To: IETF Announcement List <ietf-announce@ietf.org>


This is = a reminder that the Internet Draft Initial Version (-00) cut-off
is today, Monday, October 15, 2012.

All Initial Version (-00) submissions are due by UTC 24:00.

All drafts can be uploaded using the ID submission tool located here:
https://= datatracker.ietf.org/submit/

The Internet-Draft cutoff dates as well as other significant dates for =A0I= ETF 85 can be found at:
https://www.ietf.org/meeting/cutoff-dates-2012.html#IETF85

Thank you for your understanding and cooperation. If you have any =A0questi= ons or concerns, then please send a message to internet-drafts@ietf.org.

--e0cb4efe32709b49c604cc1cd773-- From Mark.Duckworth@polycom.com Tue Oct 16 04:19:42 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 132C721F885F for ; Tue, 16 Oct 2012 04:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZRSflTFPLUf for ; Tue, 16 Oct 2012 04:19:40 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B889521F87D2 for ; Tue, 16 Oct 2012 04:19:40 -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, 16 Oct 2012 04:19:39 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Tue, 16 Oct 2012 04:19:38 -0700 Thread-Topic: Framework Ticket #9 - axis of capture wording. Thread-Index: Ac2rj5ePhf5/Uj96T+akXXRmTVolWA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610390EB2C4B@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_44C6B6B2D0CF424AA90B6055548D7A610390EB2C4BCRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Framework Ticket #9 - axis of capture wording. 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, 16 Oct 2012 11:19:42 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A610390EB2C4BCRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm trying to get caught up on Framework issues, starting with this simple = one. Ticket #9 said Rob still had a concern. I got a note from Rob saying he is= n't concerned anymore, so I will update the framework with the text submitt= ed by Christian. Regards, Mark =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Rob wrote: Hi Mark, It was a minor concern about whether the language: "When the Point on Line of Capture attribute is specified, it must include = X, Y and Z coordinates. These coordinates MUST NOT be identical to the Poi= nt of Capture coordinates" could be interpreted by someone suitably pedantic to read that the X, Y and= Z values must all be different from the X, Y and Z values in the Point of = Capture. To be honest, on rereading I think you have to work pretty hard to= misinterpret it like that and I think the original language is actually fi= ne. Rob --_000_44C6B6B2D0CF424AA90B6055548D7A610390EB2C4BCRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m trying= to get caught up on Framework issues, starting with this simple one.<= /o:p>

Ticket #9 said Rob still had a concern. = I got a note from Rob saying he isn’t concerned anymore, so I will u= pdate the framework with the text submitted by Christian.

 

Regards,

Mark

<= o:p> 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /o:p>

Rob wrote:

 

Hi Mark,

 

It was a min= or concern about whether the language:

 

"When the Point on Line= of Capture attribute is specified, it must include X, Y and Z coordinates.=   These coordinates MUST NOT be identical to the Point of Capture coor= dinates"

 

could be interpreted by someone suitably pedantic to = read that the X, Y and Z values must all be different from the X, Y and Z v= alues in the Point of Capture. To be honest, on rereading I think you have = to work pretty hard to misinterpret it like that and I think the original l= anguage is actually fine.

 =

Rob

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A610390EB2C4BCRPMBOXPRD01p_-- From roberta.presta@unina.it Tue Oct 16 08:10: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 4983A21F8661 for ; Tue, 16 Oct 2012 08:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zPNHVN1buIR for ; Tue, 16 Oct 2012 08:09:59 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 98D2321F8647 for ; Tue, 16 Oct 2012 08:09:58 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.198]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id q9GF9pP0024470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 Oct 2012 17:09:52 +0200 Message-ID: <507D78BF.70805@unina.it> Date: Tue, 16 Oct 2012 17:09:51 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Paul Kyzivat , clue@ietf.org References: <507D73C0.8020305@unina.it> In-Reply-To: <507D73C0.8020305@unina.it> X-Forwarded-Message-Id: <507D73C0.8020305@unina.it> Content-Type: multipart/alternative; boundary="------------070409030604020202030306" X-Antivirus: avast! (VPS 121016-0, 16/10/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] Clue data model updates 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, 16 Oct 2012 15:10:00 -0000 This is a multi-part message in MIME format. --------------070409030604020202030306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, please find below my comments in-line. Il 15/10/2012 18:27, Paul Kyzivat ha scritto: > > [snip] > >> - case : >> when this element is shown in a media capture, it means that the capture >> is made by mixing more captures together. >> This is the case of the telepresence room audio stream composed by the >> participants' audio taken from different camera microphones. >> Moreover, this can be the case of a video stream realized by overlapping >> picture-in-picture (PiP) the loudest panel stream with the other >> participants' streams. >> Such captures don't have a single point of capture. >> As stated in the framework document regarding the PiP video example, the >> biggest area which is represented by such a stream should be indicated. >> The datamodel schema preserves that possibility, since there is a >> element in the video capture type which can be used to >> convey that information. >> On the other hand, for mixed audio streams, no spatial information is >> provided. > > Now that you have detailed the video case, ISTM that there ought to be > *some* spatial information about audio. (Disclaimer: I know *nothing* > about audio processing.) I realize that audio can't be bounded the way > video is. But surely there is a big difference between an > omni-directional mic at the capture point and a mic that is focused > along the capture axis. Shouldn't that distinction be captured? (I > realize this is primarily a question about the framework, not the data > model.) > Actually, with the current version of the data model, there is the possibility to discriminate between (non-composed) audio streams captured by directional microphones and omni-directional microphones, but we can not provide spatial information for composed audio captures. When a simple audio capture is captured by a directional mic, its representation in the datamodel contains the reference to a element, which is the position of the mic, with a child element that gives the mic direction. On the other hand, if the capture is captured by an omni-directional mic, its representation in the datamodel contains the reference to a , which is the position of the mic, without a child. Just to provide you with an example, let's call the omni-directional capture "AC0" and the directional one "AC1". AC0 and AC1 are captured by different mics. The corresponding representation according to the current datamodel should be the following: room audio captured by an omni-directional mic EG0 audio CP0 main mono room audio captured by a directional mic EG0 audio CP1 main mono [...] 1500 1500 0 1500 1500 1500 0 0 0 The media capture type, which we updated in the last mail, is an *abstract* type conceived to be a general description suitable for different capture types. Video capture type and audio capture type extends such abstract type. They are already specified in the -01 version of the datamodel document. Video capture type extends the media capture type by adding optional spatial information about the captured area. Audio capture type extends the media capture type by adding information about the format of the audio channel and no further spatial information, since the possibility of referring to a capture point, as envisioned in the abstract media capture type, seems to be sufficient. > [snip] > >> * a new child: >> >> In order to list the capture points in a telepresence room, a new child >> element of the clue info type has been added: . >> The capture points therein listed can be referred in the media captures >> through the element. >> The current aspect of the clue info type is then the following: >> >> >> >> >> >> >> >> >> > type="simultaneousSetsType"/> >> >> > maxOccurs="unbounded"/> >> >> >> >> >> >> The definition of the capture points type is the following: >> >> >> >> >> > maxOccurs="unbounded"/> >> > minOccurs="0"/> >> >> >> > > I think this mishandles some of the semantic constraints in the > framework. > > An advertisement contains multiple scenes. Each scene has a single > scaletype and coordinate space. While a capture can be present in > multiple capture sets, it can only be in the capture sets of a single > scene. That constraint isn't reflected in the model. If it were, then > there would be a separate set of capturepoints for each scene, and no > need to specify the scaletype within capturePointsType. As written > above all capture points, even from multiple scenes, must have the > same scale type, and so all scenes are also forced to have the same > scale type. I see your point. The current format of the data model is suitable for telepresence room that provides spatial information about capture scene areas and capture points by using a single coordinate space, having it a physical scale ("millimeters") or a simply relative scale ("unknown"). If we want to use different coordinate spaces inside each capture scene, the proposed datamodel doesn't work anymore. In such a case, we should define in each capture scene the position of the capture points according to the adopted coordinate space and scale. We should then link, in each capture scene, the media captures with such spatial information. I am wondering if we need using different coordinate spaces for describing capture scenes belonging to the same telepresence room (I refer to an end-point site and not to a middle box forwarding strems from different sites). Also when using an unknown scale, if the coordinate space is not the same among capture scenes, we are not able to understand the spatial relationship among their captured area. Are we interested in such relationship? Are capture scenes from a telepresence room conceived to be spatially independent from each other? Cheers, Roberta --------------070409030604020202030306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Paul,

please find below my comments in-line.


Il 15/10/2012 18:27, Paul Kyzivat ha scritto:

[snip]

- case <composed>:
when this element is shown in a media capture, it means that the capture
is made by mixing more captures together.
This is the case of the telepresence room audio stream composed by the
participants' audio taken from different camera microphones.
Moreover, this can be the case of a video stream realized by overlapping
picture-in-picture (PiP) the loudest panel stream with the other
participants' streams.
Such captures don't have a single point of capture.
As stated in the framework document regarding the PiP video example, the
biggest area which is represented by such a stream should be indicated.
The datamodel schema preserves that possibility, since there is a
<captureArea> element in the video capture type which can be used to
convey that information.
On the other hand, for mixed audio streams, no spatial information is
provided.

Now that you have detailed the video case, ISTM that there ought to be *some* spatial information about audio. (Disclaimer: I know *nothing* about audio processing.) I realize that audio can't be bounded the way video is. But surely there is a big difference between an omni-directional mic at the capture point and a mic that is focused along the capture axis. Shouldn't that distinction be captured? (I realize this is primarily a question about the framework, not the data model.)


Actually, with the current version of the data model, there is the possibility to discriminate between (non-composed) audio streams captured by directional microphones and omni-directional microphones, but we can not provide spatial information for composed audio captures.
When a simple audio capture is captured by a directional mic, its representation in the datamodel contains the reference to a <capturePoint> element, which is the position of the mic, with a <captureAxisPoint> child element that gives the mic direction.
On the other hand, if the capture is captured by an omni-directional mic, its representation in the datamodel contains the reference to a <capturePoint>, which is the position of the mic, without a <captureAxisPoint> child.
Just to provide you with an example, let's call the omni-directional capture "AC0" and the directional one "AC1".
AC0 and AC1 are captured by different mics.
The corresponding representation according to the current datamodel should be the following:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<clueInfo xmlns="urn:ietf:params:xml:ns:clue-info">
    <mediaCaptures>
        <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"         xsi:type="audioCaptureType" captureID="AC0">
            <description>room audio captured by an omni-directional mic</description>
            <encGroupIDREF>EG0</encGroupIDREF>
            <capturedMedia>audio</capturedMedia>
            <capturePointIDREF>CP0</capturePointIDREF>
            <content>main</content>
            <audioChannelFormat>mono</audioChannelFormat>
        </mediaCapture>
        <mediaCapture xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="audioCaptureType" captureID="AC1">
            <description>room audio captured by a directional mic</description>
            <encGroupIDREF>EG0</encGroupIDREF>
            <capturedMedia>audio</capturedMedia>
            <capturePointIDREF>CP1</capturePointIDREF>
            <content>main</content>
            <audioChannelFormat>mono</audioChannelFormat>
        </mediaCapture>
    </mediaCaptures>
    
    [...]

    <capturePoints scale="millimeters">
        <capturePoint pointID="CP0">
            <x>1500</x>
            <y>1500</y>
            <z>0</z>
        </capturePoint>
        <capturePoint pointID="CP1">
            <x>1500</x>
            <y>1500</y>
            <z>1500</z>
            <captureAxisPoint>
                <x>0</x>
                <y>0</y>
                <z>0</z>
            </captureAxisPoint>
        </capturePoint>
    </capturePoints>
</clueInfo>

The media capture type, which we updated in the last mail, is an *abstract* type conceived to be a general description suitable for different capture types. Video capture type and audio capture type extends such abstract type. They are already specified in the -01 version of the datamodel document. Video capture type extends the media capture type by adding optional spatial information about the captured area. Audio capture type extends the media capture type by adding information about the format of the audio channel and no further spatial information, since the possibility of referring to a capture point, as envisioned in the abstract media capture type, seems to be sufficient.


[snip]

* a new <clueInfo> child: <capturePoints>

In order to list the capture points in a telepresence room, a new child
element of the clue info type has been added: <capturePoints>.
The capture points therein listed can be referred in the media captures
through the <captureIDREF> element.
The current aspect of the clue info type is then the following:

       <!-- CLUE INFO TYPE -->
       <xs:complexType name="clueInfoType">
        <xs:sequence>
         <xs:element name="mediaCaptures" type="mediaCapturesType"/>
         <xs:element name="captureScenes" type="captureScenesType"/>
         <xs:element name="encodings" type="encodingsType"/>
         <xs:element name="encodingGroups" type="encodingGroupsType"/>
         <xs:element name="simultaneousSets" type="simultaneousSetsType"/>
         <xs:element name="capturePoints" type="capturePointsType"/>
         <xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
        </xs:sequence>
        <xs:attribute name="clueInfoID" type="xs:ID" use="required"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
       </xs:complexType>

The definition of the capture points type is the following:

       <!-- CAPTURE POINTS TYPE -->
       <xs:complexType name="capturePointsType">
        <xs:sequence>
         <xs:element name="capturePoint" type="capturePointType"
maxOccurs="unbounded"/>
         <xs:element name="descritption" type="xs:string" minOccurs="0"/>
        </xs:sequence>
        <xs:attribute name="scale" type="scaleType" use="required"/>
       </xs:complexType>

I think this mishandles some of the semantic constraints in the framework.

An advertisement contains multiple scenes. Each scene has a single scaletype and coordinate space. While a capture can be present in multiple capture sets, it can only be in the capture sets of a single scene. That constraint isn't reflected in the model. If it were, then there would be a separate set of capturepoints for each scene, and no need to specify the scaletype within capturePointsType. As written above all capture points, even from multiple scenes, must have the same scale type, and so all scenes are also forced to have the same scale type.
I see your point.

The current format of the data model is suitable for telepresence room that provides spatial information about capture scene areas and capture points by using a single coordinate space, having it a physical scale ("millimeters") or a simply relative scale ("unknown").

If we want to use different coordinate spaces inside each capture scene, the proposed datamodel doesn't work anymore. In such a case, we should define in each capture scene the position of the capture points according to the adopted coordinate space and scale. We should then link, in each capture scene,  the media captures with such spatial information.

I am wondering if we need using different coordinate spaces for describing capture scenes belonging to the same telepresence room (I refer to an end-point site and not to a middle box forwarding strems from different sites). Also when using an unknown scale, if the coordinate space is not the same among capture scenes, we are not able to understand the spatial relationship among their captured area. Are we interested in such relationship? Are capture scenes from a telepresence room conceived to be spatially independent from each other?

Cheers,

Roberta



--------------070409030604020202030306-- From john@jlc.net Tue Oct 16 08:52: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 3271C21F89FF for ; Tue, 16 Oct 2012 08:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.437 X-Spam-Level: X-Spam-Status: No, score=-106.437 tagged_above=-999 required=5 tests=[AWL=0.162, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqRrhGyDCyjs for ; Tue, 16 Oct 2012 08:52:07 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id E831221F89CA for ; Tue, 16 Oct 2012 08:52:06 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 58B6D33C22; Tue, 16 Oct 2012 11:52:06 -0400 (EDT) Date: Tue, 16 Oct 2012 11:52:06 -0400 From: John Leslie To: Roberta Presta Message-ID: <20121016155206.GB44606@verdi> References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <507D78BF.70805@unina.it> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 16 Oct 2012 15:52:08 -0000 Roberta Presta wrote: > Il 15/10/2012 18:27, Paul Kyzivat ha scritto: >>... >> Now that you have detailed the video case, ISTM that there ought to be >> *some* spatial information about audio... > > Actually, with the current version of the data model, there is the > possibility to discriminate between (non-composed) audio streams > captured by directional microphones and omni-directional microphones, > but we can not provide spatial information for composed audio captures. True. > When a simple audio capture is captured by a directional mic, its > representation in the datamodel contains the reference to a > element, which is the position of the mic, with a > child element that gives the mic direction. Actually, all mikes are directional (though some have a figure-8 pattern and should be called bi-directional, and others are multiple microphones capable of being processed to _any_ directionality). > On the other hand, if the capture is captured by an omni-directional > mic, its representation in the datamodel contains the reference to a > , which is the position of the mic, without a > child. For what is generally called "omni-directional", this is technically wrong. "Omni-directional" mikes have a directional pattern, but it is less pronounced than "cardioid" or "shotgun" mikes. I would recommend that we keep for all mikes, understanding that there are cases where the sensitivity pattern is too close to unity to be worth using. I also recommend that for all mikes there be a field for "pattern" -- most likely an enumeration of cases starting with "omni-directional" and "cardioid". In many applications, even these differences wouldn't be worth spending any processing time; but I believe the data structure should allow for specifying them. -- John Leslie From pkyzivat@alum.mit.edu Tue Oct 16 09:55: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 3BB9121F8A5C for ; Tue, 16 Oct 2012 09:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.362 X-Spam-Level: X-Spam-Status: No, score=-0.362 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8krWNRE9eM2J for ; Tue, 16 Oct 2012 09:55:05 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id ABDC721F8A4F for ; Tue, 16 Oct 2012 09:55:05 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta06.westchester.pa.mail.comcast.net with comcast id Bsn11k0011swQuc56sv9oH; Tue, 16 Oct 2012 16:55:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id Bssw1k00l3ZTu2S3bsswT5; Tue, 16 Oct 2012 16:52:56 +0000 Message-ID: <507D903B.8010508@alum.mit.edu> Date: Tue, 16 Oct 2012 12:50:03 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: John Leslie References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <20121016155206.GB44606@verdi> In-Reply-To: <20121016155206.GB44606@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 16 Oct 2012 16:55:06 -0000 John, Thanks for providing input from somebody who knows what they are talking about! Thanks, Paul On 10/16/12 11:52 AM, John Leslie wrote: > Roberta Presta wrote: >> Il 15/10/2012 18:27, Paul Kyzivat ha scritto: >>> ... >>> Now that you have detailed the video case, ISTM that there ought to be >>> *some* spatial information about audio... >> >> Actually, with the current version of the data model, there is the >> possibility to discriminate between (non-composed) audio streams >> captured by directional microphones and omni-directional microphones, >> but we can not provide spatial information for composed audio captures. > > True. > >> When a simple audio capture is captured by a directional mic, its >> representation in the datamodel contains the reference to a >> element, which is the position of the mic, with a >> child element that gives the mic direction. > > Actually, all mikes are directional (though some have a figure-8 > pattern and should be called bi-directional, and others are multiple > microphones capable of being processed to _any_ directionality). > >> On the other hand, if the capture is captured by an omni-directional >> mic, its representation in the datamodel contains the reference to a >> , which is the position of the mic, without a >> child. > > For what is generally called "omni-directional", this is technically > wrong. "Omni-directional" mikes have a directional pattern, but it is > less pronounced than "cardioid" or "shotgun" mikes. > > I would recommend that we keep for all mikes, > understanding that there are cases where the sensitivity pattern is > too close to unity to be worth using. I also recommend that for all > mikes there be a field for "pattern" -- most likely an enumeration > of cases starting with "omni-directional" and "cardioid". > > In many applications, even these differences wouldn't be worth > spending any processing time; but I believe the data structure should > allow for specifying them. > > -- > John Leslie > From Christian.Groves@nteczone.com Tue Oct 16 14: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 5363621F86F0 for ; Tue, 16 Oct 2012 14:49:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kY4y7ngTKqDF for ; Tue, 16 Oct 2012 14:49:24 -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 81ECC21F86EB for ; Tue, 16 Oct 2012 14:49:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIjVfVB20dhi/2dsb2JhbAANOMM9AQEBBAEBAS8BBRsbChELGAkWDwkDAgECARUwEwYCAQEFiAanLpNpi08aCoJ7gyEDqR6BTw Received: from ppp118-209-216-98.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.216.98]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Oct 2012 08:19:22 +1030 Message-ID: <507DD660.9090001@nteczone.com> Date: Wed, 17 Oct 2012 08:49:20 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <44C6B6B2D0CF424AA90B6055548D7A610390EB2C4B@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610390EB2C4B@CRPMBOXPRD01.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Framework Ticket #9 - axis of capture wording. 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, 16 Oct 2012 21:49:25 -0000 Hello Mark, No complaints from me. Regards, Christian On 16/10/2012 10:19 PM, Duckworth, Mark wrote: > > I’m trying to get caught up on Framework issues, starting with this > simple one. > > Ticket #9 said Rob still had a concern. I got a note from Rob saying > he isn’t concerned anymore, so I will update the framework with the > text submitted by Christian > . > > Regards, > > Mark > > ================================== > > Rob wrote: > > Hi Mark, > > It was a minor concern about whether the language: > > "When the Point on Line of Capture attribute is specified, it must > include X, Y and Z coordinates. These coordinates MUST NOT be > identical to the Point of Capture coordinates" > > could be interpreted by someone suitably pedantic to read that the X, > Y and Z values must all be different from the X, Y and Z values in the > Point of Capture. To be honest, on rereading I think you have to work > pretty hard to misinterpret it like that and I think the original > language is actually fine. > > Rob > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From Christian.Groves@nteczone.com Tue Oct 16 15:33: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 45A2821F8552 for ; Tue, 16 Oct 2012 15:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bg-1LyUsoBov for ; Tue, 16 Oct 2012 15:33:31 -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 8482D21F85A0 for ; Tue, 16 Oct 2012 15:33:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApcBAEHgfVB20dhi/2dsb2JhbAANOIYRtk2GXwEBAQQjFRslEQsYAgIFFgsCAgkDAgECAUUTCAEBrz1uknqBIYougx+CD4ESA6ke Received: from ppp118-209-216-98.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.216.98]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Oct 2012 09:03:10 +1030 Message-ID: <507DE0A4.1010202@nteczone.com> Date: Wed, 17 Oct 2012 09:33:08 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> In-Reply-To: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" 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, 16 Oct 2012 22:33:32 -0000 Hello, I guess this also applies to "Configure" messages also? When "all" or "delta" is mentioned is this based on the previous instance of a message (i.e. Advertisement followed by another advertisement) or some CLUE state (i.e. State advertised by an Advertisement and then confirmed by a Configure message.) Regards, Christian On 14/10/2012 5:51 AM, clue issue tracker wrote: > #25: Advertisement: Complete "all" or "delta" > > Issue a from 19-20 Sept. 2012 interim > > Need to decide whether advertisement is complete information "all" or just > a "delta" [Note: current framework is "all"] > From Christian.Groves@nteczone.com Tue Oct 16 15:41: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 0916E1F0CA7 for ; Tue, 16 Oct 2012 15:41:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.382 X-Spam-Level: X-Spam-Status: No, score=-2.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jp0Uva5TrLFb for ; Tue, 16 Oct 2012 15:41: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 0FDB61F0CA4 for ; Tue, 16 Oct 2012 15:41:00 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAFHhfVB20dhi/2dsb2JhbAANOMM9AQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiAunM5NkBItPgx+DIQOpHg Received: from ppp118-209-216-98.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.216.98]) by ipmail04.adl6.internode.on.net with ESMTP; 17 Oct 2012 09:10:59 +1030 Message-ID: <507DE27A.5040204@nteczone.com> Date: Wed, 17 Oct 2012 09:40:58 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> <507AFC2E.3030008@alum.mit.edu> In-Reply-To: <507AFC2E.3030008@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Rejecting Advertisements 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, 16 Oct 2012 22:41:03 -0000 Hello Paul, I agree that there needs to be a way to reject a configure especially if the framework allows the consumer to select configuration other than what is advertised. With respect to the advertisement, what do we mean by "reject"? Are you thinking more of error handling (i.e. I can't parse what you sent me) or the consumer doesn't like the configurations being offerred? Regards, Christian On 15/10/2012 4:53 AM, Paul Kyzivat wrote: > (as individual) > > Perhaps it shouldn't overload Issue#20 on rejecting configure messages, > but ISTM there also needs to be a way to reject an advertisement. > > There are more reasons for rejecting a config (e.g. it references an > advertisement that is no longer remembered), but there are reasons in > common between the two: e.g. syntactically incorrect message. > > Thanks, > Paul > > On 10/13/12 2:06 PM, clue issue tracker wrote: >> #20: Action item vii: Rejecting Configure >> >> Action item vii from 19-20 Sept. 2012 interim. >> >> Andy: Add text to Framework for rejecting Configure >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Oct 16 16:06:43 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E65D1F0CB0 for ; Tue, 16 Oct 2012 16:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.364 X-Spam-Level: X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5f2v-m-vzJY for ; Tue, 16 Oct 2012 16:06:43 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id D94671F0CA6 for ; Tue, 16 Oct 2012 16:06:42 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta05.westchester.pa.mail.comcast.net with comcast id BnRC1k00817dt5G55z6nKE; Tue, 16 Oct 2012 23:06:47 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Bz2b1k0153ZTu2S3Zz2bNi; Tue, 16 Oct 2012 23:02:35 +0000 Message-ID: <507DE755.7090404@alum.mit.edu> Date: Tue, 16 Oct 2012 19:01:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <068.3aa6453a0a9afc5e087600f68497cddd@trac.tools.ietf.org> <507DE0A4.1010202@nteczone.com> In-Reply-To: <507DE0A4.1010202@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] #25: Advertisement: Complete "all" or "delta" 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, 16 Oct 2012 23:06:43 -0000 (As individual) On 10/16/12 6:33 PM, Christian Groves wrote: > Hello, > > I guess this also applies to "Configure" messages also? I think these can be considered separately. Advertisements can get large, so there may be *some* motivation to minimize them with deltas. I believe Configure messages will be quite small and so there will be little motivation for deltas. > When "all" or "delta" is mentioned is this based on the previous > instance of a message (i.e. Advertisement followed by another > advertisement) or some CLUE state (i.e. State advertised by an > Advertisement and then confirmed by a Configure message.) The proposal is that once an Advertisement has been sent, a sequence of different Configure messages can be sent against it. So a Configure doesn't remove anything from the advertisement. And a new Advertisement need not take account of the prior one, or outstanding Configures. (Though it might want to.) So I believe a delta on an Advertisement should be to the prior Advertisement. IMO we need to be convinced that the Advertisement is likely to be intolerably large before we go down this path. I am inclined to postpone this decision until we have a detailed proposal for a full encoding of the Advertisement. Thanks, Paul > Regards, Christian > > On 14/10/2012 5:51 AM, clue issue tracker wrote: >> #25: Advertisement: Complete "all" or "delta" >> >> Issue a from 19-20 Sept. 2012 interim >> >> Need to decide whether advertisement is complete information "all" >> or just >> a "delta" [Note: current framework is "all"] >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Tue Oct 16 16:27:01 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0F611E80A3 for ; Tue, 16 Oct 2012 16:27:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.065 X-Spam-Level: X-Spam-Status: No, score=-0.065 tagged_above=-999 required=5 tests=[AWL=-0.228, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_39=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fga4S2g81YLd for ; Tue, 16 Oct 2012 16:27:00 -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 5E71111E80A2 for ; Tue, 16 Oct 2012 16:27:00 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta01.westchester.pa.mail.comcast.net with comcast id BpX71k0070Fqzac51zT4jr; Tue, 16 Oct 2012 23:27:04 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id BzMp1k0083ZTu2S3UzMpvW; Tue, 16 Oct 2012 23:21:49 +0000 Message-ID: <507DEC16.6030000@alum.mit.edu> Date: Tue, 16 Oct 2012 19:21:58 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <068.fd288eefa5d58bb02dedc2afe8131a92@trac.tools.ietf.org> <507AFC2E.3030008@alum.mit.edu> <507DE27A.5040204@nteczone.com> In-Reply-To: <507DE27A.5040204@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Rejecting Advertisements 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, 16 Oct 2012 23:27:01 -0000 On 10/16/12 6:40 PM, Christian Groves wrote: > Hello Paul, > > I agree that there needs to be a way to reject a configure especially if > the framework allows the consumer to select configuration other than > what is advertised. The advertisement is like a menu for a take out restaurant, with a date on it. When you call to order, you can only order off the menu. You are expected to mention *which* menu you are ordering from, and you may be told that the menu you are ordering from is no longer supported. The only menu you can be sure is supported is the one that was most recently sent. (And it *could* happen that a new menu is "in the mail" and you have not yet received it. So your order may be refused and you will then need to wait for the new menu before you can order.) But based on discussion from the interim, there was a suggestion that the labels for items on the menu be maintained as stable across menu changes whenever possible. In such a case, it may be possible to honor an order on an old menu even though the old menu isn'available any longer, because the items are understood relative to the newer menu. > With respect to the advertisement, what do we mean by "reject"? Are you > thinking more of error handling (i.e. I can't parse what you sent me) or > the consumer doesn't like the configurations being offerred? Having said all that above, if you send a configure that references an unknown/unremembered advertisement, then there may be need to reject it. Or if you send a configure referencing the most recent advertisement, but it references things not mentioned in that advertisement, then you would need to reject. Also if syntactically malformed. There was some discussion of rejecting superficially valid configurations (based on the advertisement) as a way of imposing additional constraints indescribable in the advertisement. Personally I am opposed to that, because it can make the process of finding a valid configuration unsolvable. IMO any configuration that is consistent with the advertisement should be acceptable. Thanks, Paul > Regards, Christian > > On 15/10/2012 4:53 AM, Paul Kyzivat wrote: >> (as individual) >> >> Perhaps it shouldn't overload Issue#20 on rejecting configure messages, >> but ISTM there also needs to be a way to reject an advertisement. >> >> There are more reasons for rejecting a config (e.g. it references an >> advertisement that is no longer remembered), but there are reasons in >> common between the two: e.g. syntactically incorrect message. >> >> Thanks, >> Paul >> >> On 10/13/12 2:06 PM, clue issue tracker wrote: >>> #20: Action item vii: Rejecting Configure >>> >>> Action item vii from 19-20 Sept. 2012 interim. >>> >>> Andy: Add text to Framework for rejecting Configure >>> >> >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Tue Oct 16 16:47:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC5921F8602 for ; Tue, 16 Oct 2012 16:47:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9hAn8PkjfPs for ; Tue, 16 Oct 2012 16:47:03 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id D477A21F85F4 for ; Tue, 16 Oct 2012 16:47:02 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta04.westchester.pa.mail.comcast.net with comcast id BvUZ1k0070xGWP854zn6im; Tue, 16 Oct 2012 23:47:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id Bzh31k00p3ZTu2S3Yzh4Mh; Tue, 16 Oct 2012 23:41:04 +0000 Message-ID: <507DF0C8.3020401@alum.mit.edu> Date: Tue, 16 Oct 2012 19:42:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roberta Presta References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> In-Reply-To: <507D78BF.70805@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 16 Oct 2012 23:47:04 -0000 Hi Roberta, Thanks for helping. I've included responses inline. On 10/16/12 11:09 AM, Roberta Presta wrote: > > Hi Paul, > > please find below my comments in-line. > > > Il 15/10/2012 18:27, Paul Kyzivat ha scritto: >> >> [snip] >> >>> - case : >>> when this element is shown in a media capture, it means that the capture >>> is made by mixing more captures together. >>> This is the case of the telepresence room audio stream composed by the >>> participants' audio taken from different camera microphones. >>> Moreover, this can be the case of a video stream realized by overlapping >>> picture-in-picture (PiP) the loudest panel stream with the other >>> participants' streams. >>> Such captures don't have a single point of capture. >>> As stated in the framework document regarding the PiP video example, the >>> biggest area which is represented by such a stream should be indicated. >>> The datamodel schema preserves that possibility, since there is a >>> element in the video capture type which can be used to >>> convey that information. >>> On the other hand, for mixed audio streams, no spatial information is >>> provided. >> >> Now that you have detailed the video case, ISTM that there ought to be >> *some* spatial information about audio. (Disclaimer: I know *nothing* >> about audio processing.) I realize that audio can't be bounded the way >> video is. But surely there is a big difference between an >> omni-directional mic at the capture point and a mic that is focused >> along the capture axis. Shouldn't that distinction be captured? (I >> realize this is primarily a question about the framework, not the data >> model.) >> > > Actually, with the current version of the data model, there is the > possibility to discriminate between (non-composed) audio streams [snip] I'll defer to John Leslie and his comments on this part. He knows *way* more about it than I do. >>> * a new child: >>> >>> In order to list the capture points in a telepresence room, a new child >>> element of the clue info type has been added: . >>> The capture points therein listed can be referred in the media captures >>> through the element. >>> The current aspect of the clue info type is then the following: >>> >>> >>> >>> >>> >>> >>> >>> >>> >> type="simultaneousSetsType"/> >>> >>> >> maxOccurs="unbounded"/> >>> >>> >>> >>> >>> >>> The definition of the capture points type is the following: >>> >>> >>> >>> >>> >> maxOccurs="unbounded"/> >>> >> minOccurs="0"/> >>> >>> >>> >> >> I think this mishandles some of the semantic constraints in the >> framework. >> >> An advertisement contains multiple scenes. Each scene has a single >> scaletype and coordinate space. While a capture can be present in >> multiple capture sets, it can only be in the capture sets of a single >> scene. That constraint isn't reflected in the model. If it were, then >> there would be a separate set of capturepoints for each scene, and no >> need to specify the scaletype within capturePointsType. As written >> above all capture points, even from multiple scenes, must have the >> same scale type, and so all scenes are also forced to have the same >> scale type. > I see your point. > > The current format of the data model is suitable for telepresence room > that provides spatial information about capture scene areas and capture > points by using a single coordinate space, having it a physical scale > ("millimeters") or a simply relative scale ("unknown"). > > If we want to use different coordinate spaces inside each capture scene, > the proposed datamodel doesn't work anymore. In such a case, we should > define in each capture scene the position of the capture points > according to the adopted coordinate space and scale. We should then > link, in each capture scene, the media captures with such spatial > information. That is what I think needs to be done, more or less. > I am wondering if we need using different coordinate spaces for > describing capture scenes belonging to the same telepresence room (I > refer to an end-point site and not to a middle box forwarding strems > from different sites). Also when using an unknown scale, if the > coordinate space is not the same among capture scenes, we are not able > to understand the spatial relationship among their captured area. Are we > interested in such relationship? Are capture scenes from a telepresence > room conceived to be spatially independent from each other? The only reason to have scenes is to support coexistence of different coordinate spaces. You haven't been involved for that discussion so I'll summarize the main points and use cases. One reason for different coordinate spaces came about from the inclusion of presentations that originate on a computer. For these there is no camera and no area of focus within a room. Each room may have a different place to display presentations, and where the sender might want to display it has no bearing on where the receiver will display it. The presentation may not even be displayed in a public place in the room - it may be viewed on individual screens, something like people using webex inside a telepresence session. Another reason has to do with MCUs. I think the expected typical behavior of an MCU is that it will advertise a scene with a "synthetic" coordinate space, and map the captures it receives onto captures within that synthetic space. (I've been calling it a "virtual room" or "virtual scene".) But another possible behavior for the MCU is to directly advertise some or all of the scenes it receives from other rooms, instead of, or in addition to, a virtual scene. Thanks, Paul From roberta.presta@unina.it Wed Oct 17 04:33: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 E6AD621F84C2 for ; Wed, 17 Oct 2012 04:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TU9ePULWNIRU for ; Wed, 17 Oct 2012 04:33:45 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0607521F84B5 for ; Wed, 17 Oct 2012 04:33:39 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.198]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q9HBXXVD006165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Oct 2012 13:33:34 +0200 Message-ID: <507E978F.2090409@unina.it> Date: Wed, 17 Oct 2012 13:33:35 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Paul Kyzivat References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <507DF0C8.3020401@alum.mit.edu> In-Reply-To: <507DF0C8.3020401@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 121016-1, 16/10/2012), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 17 Oct 2012 11:33:46 -0000 Paul and John, thank you for your clarifications. I'll try to update the data model in light of your comments and to propose the results on the mailing list as soon as possible. Cheers, Roberta Il 17/10/2012 01:42, Paul Kyzivat ha scritto: > Hi Roberta, > > Thanks for helping. I've included responses inline. > > On 10/16/12 11:09 AM, Roberta Presta wrote: >> >> Hi Paul, >> >> please find below my comments in-line. >> >> >> Il 15/10/2012 18:27, Paul Kyzivat ha scritto: >>> >>> [snip] >>> >>>> - case : >>>> when this element is shown in a media capture, it means that the >>>> capture >>>> is made by mixing more captures together. >>>> This is the case of the telepresence room audio stream composed by the >>>> participants' audio taken from different camera microphones. >>>> Moreover, this can be the case of a video stream realized by >>>> overlapping >>>> picture-in-picture (PiP) the loudest panel stream with the other >>>> participants' streams. >>>> Such captures don't have a single point of capture. >>>> As stated in the framework document regarding the PiP video >>>> example, the >>>> biggest area which is represented by such a stream should be >>>> indicated. >>>> The datamodel schema preserves that possibility, since there is a >>>> element in the video capture type which can be used to >>>> convey that information. >>>> On the other hand, for mixed audio streams, no spatial information is >>>> provided. >>> >>> Now that you have detailed the video case, ISTM that there ought to be >>> *some* spatial information about audio. (Disclaimer: I know *nothing* >>> about audio processing.) I realize that audio can't be bounded the way >>> video is. But surely there is a big difference between an >>> omni-directional mic at the capture point and a mic that is focused >>> along the capture axis. Shouldn't that distinction be captured? (I >>> realize this is primarily a question about the framework, not the data >>> model.) >>> >> >> Actually, with the current version of the data model, there is the >> possibility to discriminate between (non-composed) audio streams > > [snip] > > I'll defer to John Leslie and his comments on this part. > He knows *way* more about it than I do. > >>>> * a new child: >>>> >>>> In order to list the capture points in a telepresence room, a new >>>> child >>>> element of the clue info type has been added: . >>>> The capture points therein listed can be referred in the media >>>> captures >>>> through the element. >>>> The current aspect of the clue info type is then the following: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> type="simultaneousSetsType"/> >>>> >>>> >>> minOccurs="0" >>>> maxOccurs="unbounded"/> >>>> >>>> >>>> >>>> >>>> >>>> The definition of the capture points type is the following: >>>> >>>> >>>> >>>> >>>> >>> maxOccurs="unbounded"/> >>>> >>> minOccurs="0"/> >>>> >>>> >>>> >>> >>> I think this mishandles some of the semantic constraints in the >>> framework. >>> >>> An advertisement contains multiple scenes. Each scene has a single >>> scaletype and coordinate space. While a capture can be present in >>> multiple capture sets, it can only be in the capture sets of a single >>> scene. That constraint isn't reflected in the model. If it were, then >>> there would be a separate set of capturepoints for each scene, and no >>> need to specify the scaletype within capturePointsType. As written >>> above all capture points, even from multiple scenes, must have the >>> same scale type, and so all scenes are also forced to have the same >>> scale type. >> I see your point. >> >> The current format of the data model is suitable for telepresence room >> that provides spatial information about capture scene areas and capture >> points by using a single coordinate space, having it a physical scale >> ("millimeters") or a simply relative scale ("unknown"). >> >> If we want to use different coordinate spaces inside each capture scene, >> the proposed datamodel doesn't work anymore. In such a case, we should >> define in each capture scene the position of the capture points >> according to the adopted coordinate space and scale. We should then >> link, in each capture scene, the media captures with such spatial >> information. > > That is what I think needs to be done, more or less. > >> I am wondering if we need using different coordinate spaces for >> describing capture scenes belonging to the same telepresence room (I >> refer to an end-point site and not to a middle box forwarding strems >> from different sites). Also when using an unknown scale, if the >> coordinate space is not the same among capture scenes, we are not able >> to understand the spatial relationship among their captured area. Are we >> interested in such relationship? Are capture scenes from a telepresence >> room conceived to be spatially independent from each other? > > The only reason to have scenes is to support coexistence of different > coordinate spaces. You haven't been involved for that discussion so > I'll summarize the main points and use cases. > > One reason for different coordinate spaces came about from the > inclusion of presentations that originate on a computer. For these > there is no camera and no area of focus within a room. Each room may > have a different place to display presentations, and where the sender > might want to display it has no bearing on where the receiver will > display it. The presentation may not even be displayed in a public > place in the room - it may be viewed on individual screens, something > like people using webex inside a telepresence session. > > Another reason has to do with MCUs. I think the expected typical > behavior of an MCU is that it will advertise a scene with a > "synthetic" coordinate space, and map the captures it receives onto > captures within that synthetic space. (I've been calling it a "virtual > room" or "virtual scene".) But another possible behavior for the MCU > is to directly advertise some or all of the scenes it receives from > other rooms, instead of, or in addition to, a virtual scene. > > Thanks, > Paul > > > From pkyzivat@alum.mit.edu Wed Oct 17 08:59: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 02F4121F8605 for ; Wed, 17 Oct 2012 08:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.363 X-Spam-Level: X-Spam-Status: No, score=-0.363 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tn8SjrtNKdyp for ; Wed, 17 Oct 2012 08:59:38 -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 E8C1421F85E7 for ; Wed, 17 Oct 2012 08:59:37 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta02.westchester.pa.mail.comcast.net with comcast id CEB41k0061HzFnQ51Fzi0n; Wed, 17 Oct 2012 15:59:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id CFug1k00V3ZTu2S3aFuhY8; Wed, 17 Oct 2012 15:54:41 +0000 Message-ID: <507ED4BB.4010904@alum.mit.edu> Date: Wed, 17 Oct 2012 11:54:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Roberta Presta References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <507DF0C8.3020401@alum.mit.edu> <507E978F.2090409@unina.it> In-Reply-To: <507E978F.2090409@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 17 Oct 2012 15:59:39 -0000 On 10/17/12 7:33 AM, Roberta Presta wrote: > Paul and John, > thank you for your clarifications. > I'll try to update the data model in light of your comments and to > propose the results on the mailing list as soon as possible. > Cheers, Thanks Roberta! I really appreciate the help you are giving us. Paul > Roberta > > > > Il 17/10/2012 01:42, Paul Kyzivat ha scritto: >> Hi Roberta, >> >> Thanks for helping. I've included responses inline. >> >> On 10/16/12 11:09 AM, Roberta Presta wrote: >>> >>> Hi Paul, >>> >>> please find below my comments in-line. >>> >>> >>> Il 15/10/2012 18:27, Paul Kyzivat ha scritto: >>>> >>>> [snip] >>>> >>>>> - case : >>>>> when this element is shown in a media capture, it means that the >>>>> capture >>>>> is made by mixing more captures together. >>>>> This is the case of the telepresence room audio stream composed by the >>>>> participants' audio taken from different camera microphones. >>>>> Moreover, this can be the case of a video stream realized by >>>>> overlapping >>>>> picture-in-picture (PiP) the loudest panel stream with the other >>>>> participants' streams. >>>>> Such captures don't have a single point of capture. >>>>> As stated in the framework document regarding the PiP video >>>>> example, the >>>>> biggest area which is represented by such a stream should be >>>>> indicated. >>>>> The datamodel schema preserves that possibility, since there is a >>>>> element in the video capture type which can be used to >>>>> convey that information. >>>>> On the other hand, for mixed audio streams, no spatial information is >>>>> provided. >>>> >>>> Now that you have detailed the video case, ISTM that there ought to be >>>> *some* spatial information about audio. (Disclaimer: I know *nothing* >>>> about audio processing.) I realize that audio can't be bounded the way >>>> video is. But surely there is a big difference between an >>>> omni-directional mic at the capture point and a mic that is focused >>>> along the capture axis. Shouldn't that distinction be captured? (I >>>> realize this is primarily a question about the framework, not the data >>>> model.) >>>> >>> >>> Actually, with the current version of the data model, there is the >>> possibility to discriminate between (non-composed) audio streams >> >> [snip] >> >> I'll defer to John Leslie and his comments on this part. >> He knows *way* more about it than I do. >> >>>>> * a new child: >>>>> >>>>> In order to list the capture points in a telepresence room, a new >>>>> child >>>>> element of the clue info type has been added: . >>>>> The capture points therein listed can be referred in the media >>>>> captures >>>>> through the element. >>>>> The current aspect of the clue info type is then the following: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> type="simultaneousSetsType"/> >>>>> >>>>> >>>> minOccurs="0" >>>>> maxOccurs="unbounded"/> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> The definition of the capture points type is the following: >>>>> >>>>> >>>>> >>>>> >>>>> >>>> maxOccurs="unbounded"/> >>>>> >>>> minOccurs="0"/> >>>>> >>>>> >>>>> >>>> >>>> I think this mishandles some of the semantic constraints in the >>>> framework. >>>> >>>> An advertisement contains multiple scenes. Each scene has a single >>>> scaletype and coordinate space. While a capture can be present in >>>> multiple capture sets, it can only be in the capture sets of a single >>>> scene. That constraint isn't reflected in the model. If it were, then >>>> there would be a separate set of capturepoints for each scene, and no >>>> need to specify the scaletype within capturePointsType. As written >>>> above all capture points, even from multiple scenes, must have the >>>> same scale type, and so all scenes are also forced to have the same >>>> scale type. >>> I see your point. >>> >>> The current format of the data model is suitable for telepresence room >>> that provides spatial information about capture scene areas and capture >>> points by using a single coordinate space, having it a physical scale >>> ("millimeters") or a simply relative scale ("unknown"). >>> >>> If we want to use different coordinate spaces inside each capture scene, >>> the proposed datamodel doesn't work anymore. In such a case, we should >>> define in each capture scene the position of the capture points >>> according to the adopted coordinate space and scale. We should then >>> link, in each capture scene, the media captures with such spatial >>> information. >> >> That is what I think needs to be done, more or less. >> >>> I am wondering if we need using different coordinate spaces for >>> describing capture scenes belonging to the same telepresence room (I >>> refer to an end-point site and not to a middle box forwarding strems >>> from different sites). Also when using an unknown scale, if the >>> coordinate space is not the same among capture scenes, we are not able >>> to understand the spatial relationship among their captured area. Are we >>> interested in such relationship? Are capture scenes from a telepresence >>> room conceived to be spatially independent from each other? >> >> The only reason to have scenes is to support coexistence of different >> coordinate spaces. You haven't been involved for that discussion so >> I'll summarize the main points and use cases. >> >> One reason for different coordinate spaces came about from the >> inclusion of presentations that originate on a computer. For these >> there is no camera and no area of focus within a room. Each room may >> have a different place to display presentations, and where the sender >> might want to display it has no bearing on where the receiver will >> display it. The presentation may not even be displayed in a public >> place in the room - it may be viewed on individual screens, something >> like people using webex inside a telepresence session. >> >> Another reason has to do with MCUs. I think the expected typical >> behavior of an MCU is that it will advertise a scene with a >> "synthetic" coordinate space, and map the captures it receives onto >> captures within that synthetic space. (I've been calling it a "virtual >> room" or "virtual scene".) But another possible behavior for the MCU >> is to directly advertise some or all of the scenes it receives from >> other rooms, instead of, or in addition to, a virtual scene. >> >> Thanks, >> Paul >> >> >> > > > From apeppere@gmail.com Wed Oct 17 09:35:35 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5CA21F8570 for ; Wed, 17 Oct 2012 09:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.298 X-Spam-Level: X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xLGF3RKACb8q for ; Wed, 17 Oct 2012 09:35:34 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 6D07121F8518 for ; Wed, 17 Oct 2012 09:35:34 -0700 (PDT) Received: by mail-qa0-f51.google.com with SMTP id j40so643326qab.10 for ; Wed, 17 Oct 2012 09:35:33 -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=od9NSvT+OYNRRmNwvqKWQYaoZ7cAVj6BoTV6K4NVPKE=; b=Co9QBSFtdMDNynMQPWwQRyk8p2+gNFhuKqM84NmBCY9W+fFUZl507m1vsMslLW80wr MBPh4CRBTSnVpap2gpHVHzVsx+MmD4QDM1EQ/VR0n6iMYs6Ugl5KDgBgGbaH7HAUqmcI wa1MeBwap1+ZSduRqNSjB1CVE1aYP43x66FcjBYwF9+w3dC4oP5eAeK6lc8rWjhQN5TE RiDcLJrgsqaCLd24uJBcFEYKN5KrT3Yuut7/CJRHY3+Delo9TdM1CCMm2jnWmx/Goi+w +OHGtNPChTqOfILJIFcCMFlp353C1JhSY0FbFTv5NkOKmOWcAcUri+MzzI6zVxT70SzX YDEg== MIME-Version: 1.0 Received: by 10.49.72.3 with SMTP id z3mr44864403qeu.19.1350491733745; Wed, 17 Oct 2012 09:35:33 -0700 (PDT) Received: by 10.49.96.98 with HTTP; Wed, 17 Oct 2012 09:35:33 -0700 (PDT) In-Reply-To: <083.f56300f15d5b06ffea92ab5fe5e8dca1@trac.tools.ietf.org> References: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> <083.f56300f15d5b06ffea92ab5fe5e8dca1@trac.tools.ietf.org> Date: Wed, 17 Oct 2012 17:35:33 +0100 Message-ID: From: Andy Pepperell To: clue issue tracker Content-Type: multipart/alternative; boundary=047d7b6da0f00fe08704cc43dc42 Cc: draft-ietf-clue-framework@tools.ietf.org, clue@ietf.org Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast 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, 17 Oct 2012 16:35:35 -0000 --047d7b6da0f00fe08704cc43dc42 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think I may have rashly volunteered to send something about this one... The proposal is to define within the framework a new, optional, "maxEncodings" attribute that can be applied to a media capture (audio or video) in the provider's capture advertisement to convey to the consumer the maximum number of capture encodings that can be simultaneously active for the media capture in question. If absent, this parameter defaults to 1 - thus, systems that traditionally have not supported any form of simulcast will not be obliged to do so as part of supporting CLUE, and systems which are capable of simulcast can supply values greater than 1 for some or all of their media captures. The number of capture encodings possible would still be limited by the restrictions of the provider's media captures' encoding groups, as before. Hopefully this proposal is sufficiently detailed to at least foster some debate. I have a small concern that having to cope with this extra parameter for each media capture will make the consumer's task more complex; however, just as a provider can now choose to omit this value at leave all media captures with a default maxEncodings of 1, so a consumer could choose to treat all values above 1 as 1 and so avoid the complexity of simulcast itself too. Regards, Andy On Sat, Oct 13, 2012 at 7:08 PM, clue issue tracker < trac+clue@trac.tools.ietf.org> wrote: > #18: Action Item (v): Limitations on Simulcast > > Changes (by mary.ietf.barnes@=85): > > * type: defect =3D> task > * milestone: =3D> milestone1 > > > -- > --------------------------------+----------------------------------------= -- > Reporter: mary.ietf.barnes@=85 | Owner: draft-ietf-clue-framewo= rk@ > =85 > Type: task | Status: new > Priority: major | Milestone: milestone1 > Component: framework | Version: > Severity: - | Resolution: > Keywords: | > --------------------------------+----------------------------------------= -- > > Ticket URL: > clue > > --047d7b6da0f00fe08704cc43dc42 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think I may have rashly volunteered to send something about this one...
The proposal is to define within the framework a new, optional, "= ;maxEncodings" attribute that can be applied to a media capture (audio= or video) in the provider's capture advertisement to convey to the con= sumer the maximum number of capture encodings that can be simultaneously ac= tive for the media capture in question. If absent, this parameter defaults = to 1 - thus, systems that traditionally have not supported any form of simu= lcast will not be obliged to do so as part of supporting CLUE, and systems = which are capable of simulcast can supply values greater than 1 for some or= all of their media captures. The number of capture encodings possible woul= d still be limited by the restrictions of the provider's media captures= ' encoding groups, as before.

Hopefully this proposal is sufficiently detailed to at least foster som= e debate. I have a small concern that having to cope with this extra parame= ter for each media capture will make the consumer's task more complex; = however, just as a provider can now choose to omit this value at leave all = media captures with a default maxEncodings of 1, so a consumer could choose= to treat all values above 1 as 1 and so avoid the complexity of simulcast = itself too.

Regards,

Andy



On Sat, = Oct 13, 2012 at 7:08 PM, clue issue tracker <trac+clue@trac.= tools.ietf.org> wrote:
#18: Action Item (v): =A0L= imitations on Simulcast

Changes (by mary.ietf.barnes@=85):

=A0* type: =A0defect =3D> task
=A0* milestone: =A0 =3D> milestone1


--
--------------------------------+------------------------------------------=
=A0Reporter: =A0mary.ietf.barnes@=85 =A0| =A0 =A0 =A0 Owner: =A0draft-ietf-= clue-framework@=85
=A0 =A0 =A0Type: =A0task =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0Status= : =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: =A0miles= tone1
Component: =A0framework =A0 =A0 =A0 =A0 =A0 | =A0 =A0 Version:
=A0Severity: =A0- =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0Resolution:
=A0Keywords: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0|
--------------------------------+------------------------------------------=

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/tick= et/18#comment:1>
clue <http:= //tools.ietf.org/wg/clue/>


--047d7b6da0f00fe08704cc43dc42-- From Mark.Duckworth@polycom.com Wed Oct 17 10:04:17 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFC221F8634 for ; Wed, 17 Oct 2012 10:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 86zfwiB1YWTl for ; Wed, 17 Oct 2012 10:04:15 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA8F21F857A for ; Wed, 17 Oct 2012 10:04:15 -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; Wed, 17 Oct 2012 10:04:13 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 17 Oct 2012 10:04:12 -0700 Thread-Topic: [clue] #18: Action Item (v): Limitations on Simulcast Thread-Index: Ac2shXL8qMIpvC0SREOv1tjSjK2FDgAA6nHw Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610390EB3218@CRPMBOXPRD01.polycom.com> References: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> <083.f56300f15d5b06ffea92ab5fe5e8dca1@trac.tools.ietf.org> In-Reply-To: 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_44C6B6B2D0CF424AA90B6055548D7A610390EB3218CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast 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, 17 Oct 2012 17:04:17 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A610390EB3218CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, This proposal for a new "maxEncodings" attribute sounds good to me. It fit= s nicely in the existing framework. I don't see it adding too much extra c= omplexity. Regards, Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of And= y Pepperell Sent: Wednesday, October 17, 2012 12:36 PM To: clue issue tracker Cc: draft-ietf-clue-framework@tools.ietf.org; clue@ietf.org Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast I think I may have rashly volunteered to send something about this one... The proposal is to define within the framework a new, optional, "maxEncodin= gs" attribute that can be applied to a media capture (audio or video) in th= e provider's capture advertisement to convey to the consumer the maximum nu= mber of capture encodings that can be simultaneously active for the media c= apture in question. If absent, this parameter defaults to 1 - thus, systems= that traditionally have not supported any form of simulcast will not be ob= liged to do so as part of supporting CLUE, and systems which are capable of= simulcast can supply values greater than 1 for some or all of their media = captures. The number of capture encodings possible would still be limited b= y the restrictions of the provider's media captures' encoding groups, as be= fore. Hopefully this proposal is sufficiently detailed to at least foster some de= bate. I have a small concern that having to cope with this extra parameter = for each media capture will make the consumer's task more complex; however,= just as a provider can now choose to omit this value at leave all media ca= ptures with a default maxEncodings of 1, so a consumer could choose to trea= t all values above 1 as 1 and so avoid the complexity of simulcast itself t= oo. Regards, Andy On Sat, Oct 13, 2012 at 7:08 PM, clue issue tracker > wrote: #18: Action Item (v): Limitations on Simulcast Changes (by mary.ietf.barnes@...): * type: defect =3D> task * milestone: =3D> milestone1 -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@... | Owner: draft-ietf-clue-framework= @... Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue --_000_44C6B6B2D0CF424AA90B6055548D7A610390EB3218CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,<= o:p>

This proposal for a new &#= 8220;maxEncodings” attribute sounds good to me.  It fits nicely = in the existing framework.  I don’t see it adding too much extra= complexity.

Regards,=

Mark

 

<= p class=3DMsoNormal>From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org= ] On Behalf Of Andy Pepperell
Sent: Wednesday, October 17,= 2012 12:36 PM
To: clue issue tracker
Cc: draft-ietf-cl= ue-framework@tools.ietf.org; clue@ietf.org
Subject: Re: [clue] #1= 8: Action Item (v): Limitations on Simulcast

 

I think I may have rashly volunteered to send somethi= ng about this one...

The proposal is to define within the framework = a new, optional, "maxEncodings" attribute that can be applied to = a media capture (audio or video) in the provider's capture advertisement to= convey to the consumer the maximum number of capture encodings that can be= simultaneously active for the media capture in question. If absent, this p= arameter defaults to 1 - thus, systems that traditionally have not supporte= d any form of simulcast will not be obliged to do so as part of supporting = CLUE, and systems which are capable of simulcast can supply values greater = than 1 for some or all of their media captures. The number of capture encod= ings possible would still be limited by the restrictions of the provider's = media captures' encoding groups, as before.

Hopefully this proposal = is sufficiently detailed to at least foster some debate. I have a small con= cern that having to cope with this extra parameter for each media capture w= ill make the consumer's task more complex; however, just as a provider can = now choose to omit this value at leave all media captures with a default ma= xEncodings of 1, so a consumer could choose to treat all values above 1 as = 1 and so avoid the complexity of simulcast itself too.

Regards,
<= br>Andy


On Sat, Oct 13,= 2012 at 7:08 PM, clue issue tracker <trac+clue@trac.tools.ietf.org> wrot= e:

#= 18: Action Item (v):  Limitations on Simulcast

Changes (by mary.ietf.barn= es@…):

 * type:  defect =3D> task
 * mile= stone:   =3D> milestone1


<= span class=3Dhoenzb>--
---------------------= -----------+------------------------------------------
 Reporter:  mary.ietf.barnes@…  |   &n= bsp;   Owner:  draft-ietf-clue-framework@…
     Type:  task       &n= bsp;        |      Status:  new
 Priority:  major      = ;         |   Milestone:  milestone1Component:  framework       &nbs= p;   |     Version:
 Sev= erity:  -                 &nbs= p; |  Resolution:
 Keywords:  = ;                    |
--------------------------------+-------------= -----------------------------

Ticket URL= : <http://trac.tools.ietf.org/wg/clue/trac/ticket/18#comm= ent:1>
clue <http://tools.ietf.org/wg/clue/&= gt;

 

= --_000_44C6B6B2D0CF424AA90B6055548D7A610390EB3218CRPMBOXPRD01p_-- From pkyzivat@alum.mit.edu Wed Oct 17 15:14: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 A888821F856D for ; Wed, 17 Oct 2012 15:14:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.367 X-Spam-Level: X-Spam-Status: No, score=-0.367 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 98zPET5-eq5N for ; Wed, 17 Oct 2012 15:14:21 -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 EBBDA21F854E for ; Wed, 17 Oct 2012 15:14:20 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta01.westchester.pa.mail.comcast.net with comcast id CBdX1k0011vXlb851NERqH; Wed, 17 Oct 2012 22:14:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta17.westchester.pa.mail.comcast.net with comcast id CN9V1k00D3ZTu2S3dN9VaX; Wed, 17 Oct 2012 22:09:29 +0000 Message-ID: <507F2C8E.5050305@alum.mit.edu> Date: Wed, 17 Oct 2012 18:09:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Thoughts on relation between clue messages and SDP 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, 17 Oct 2012 22:14:21 -0000 After discussions at the interim around the call flows and signaling issues, and subsequent discussion, I have some revised ideas about how the clue messages and SDP O/A can be coordinated. The Configure message selects capture encodings that the receiver wants the sender to send to it via RTP sessions RTP streams within those sessions that are specified in SDP. In some cases it may be that a new Configure can reuse the RTP resources already present in a previously established O/A. But it is also possible that a new Configure will ask for capture encodings that require RTP resources that aren't present in the previously established O/A. In that case a new O/A will be needed, before or after that Configure is sent. One of the questions that came up at the interim is whether the O/A to prep for a Configure should come before, or after, the Configure. An argument for doing the O/A *before* the Configure is that then it is known that the resources to support the Configure are available, and allows the Configure to reference elements present in the SDP. An argument for doing the O/A *after* the Configure is that then the answerer will understand *why* it is being asked to configure the SDP as specified, and so help it decide whether it wants to accept that. I finally realized that the the Advertisement defines what is possible, and implicitly indicates what SDP will be required to support that. Hence, I think we can expect that an offerer can construct a new offer in contemplation of a Configure message it plans to send plus the last one it received, and in the context of the corresponding Advertisements. The Answerer can then evaluate that offer in the context of the same Advertisements. As long as the offer is consistent with current advertisements it should aim to construct an answer that accepts it. With that approach, a Configure can be constructed relative to the most recent O/A. During initial session setup, before the first Advertisements are exchanged, the offerer will have to construct the first offer without the context of an advertisement from the other side. It can however still construct the offer to be consistent with the Advertisement it plans to send. The Answerer can construct the answer in the context of the Advertisement it plans to send, constrained by what is in the offer. (The offer may not be sufficient for everything the answerer wishes to include.) Each side can then begin sending media that fits within that initial O/A, using a default Configure constructed locally. Concurrently Advertisements can be exchanged. After that Configure messages may be exchanged. (Or not if what is being received is satisfactory.) It may turn out that in many cases the initial O/A is sufficient for the initial Configure that each side wants to send. If so then no new O/A is needed. Or it may turn out that it isn't. If not, then either side may initiate an O/A with an offer compatible with the desired Configure, I described above. This also helps clarify that the Configure is both a selection from the advertisement and a mapping of that selection onto the SDP. This also clarifies that the Advertisement must contain sufficient information to map a Configure onto the SDP needed to convey that. For instance, if the sender has encoders with independent IP addr/port, then the offer will require multiple m-lines for those, but if both the sender and receiver have all encoders on a single addr/port then one m-line may be sufficient. Since the offerer determines the set of m-lines in the O/A, it needs to figure this out on behalf of the answerer. What do people think of this approach? Thanks, Paul (as individual) From Mark.Duckworth@polycom.com Thu Oct 18 12:44:11 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F5A21F85C1 for ; Thu, 18 Oct 2012 12:44:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a5tTnmc5cUFj for ; Thu, 18 Oct 2012 12:44:10 -0700 (PDT) Received: from crpehubprd02.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7A021F8489 for ; Thu, 18 Oct 2012 12:44:10 -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; Thu, 18 Oct 2012 12:44:09 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 18 Oct 2012 12:44:07 -0700 Thread-Topic: Ticket #17 - "capture encoding" term Thread-Index: Ac2tZ4C4oqMP7qH1TDW/yXWLHrA0eA== Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610390FF1FC4@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_44C6B6B2D0CF424AA90B6055548D7A610390FF1FC4CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: [clue] Ticket #17 - "capture encoding" term X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 19:44:11 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A610390FF1FC4CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Andy and I have updated the framework for this ticket, to include a definit= ion for "capture encoding". We also changed the definition of "stream" to = better define that term for how it is used in this document. And used the = term "capture encoding" throughout the document where appropriate, replacin= g some cases of "stream" and "encoding". We'll include these changes in the next version of the framework, for the A= tlanta meeting, including any improvements discussed on the list before the= deadline. New definition: Capture Encoding: A specific encoding of a media capture, to be sent by a m= edia provider to a media consumer via RTP. Old stream definition: Stream: RTP stream as in [RFC3550]. New stream definition: Stream: a capture encoding sent from a media provider to a media consumer v= ia RTP [RFC3550]. If anybody wants to see all the changes, it is available here: http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-cl= ue-framework-06.txt&url2=3Dhttp://home.comcast.net/~mducky/clue/draft-ietf-= clue-framework-07c.txt Changes from version 06: 1. Ticket #9. Rename Axis of Capture Point attribute to Point on Line = of Capture. Clarify the description of this attribute. 2. Ticket #17. Add "capture encoding" definition. Use this new term t= hroughout document as appropriate, replacing some usage of the terms "strea= m" and "encoding". 3. Add clarification that different capture scene entries are not neces= sarily mutually exclusive. Regards, Mark Duckworth --_000_44C6B6B2D0CF424AA90B6055548D7A610390FF1FC4CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy and I have = updated the framework for this ticket, to include a definition for “c= apture encoding”.  We also changed the definition of “stre= am” to better define that term for how it is used in this document.&n= bsp; And used the term “capture encoding” throughout the docume= nt where appropriate, replacing some cases of “stream” and R= 20;encoding”.

 

We’ll include these changes in the next version= of the framework, for the Atlanta meeting, including any improvements disc= ussed on the list before the deadline.

<= o:p> 

New definition:

Capture Encoding: A specific encoding of a media capture, = to be sent by a media provider to a media consumer via RTP.

<= p class=3DMsoNormal> 

Old stream de= finition:

Stream: RTP stream as in [RFC3= 550].

 

New stream definition:

Stream: a= capture encoding sent from a media provider to a media consumer via RTP [R= FC3550].

 

If anybody wants to see all the changes, it is available here:=

= http://tools.ietf.org/rfcdiff?url1=3Dhttp://tools.ietf.org/id/draft-ietf-cl= ue-framework-06.txt&url2=3Dhttp://home.comcast.net/~mducky/clue/draft-i= etf-clue-framework-07c.txt

Changes f= rom version 06:

   1.  Ti= cket #9.  Rename Axis of Capture Point attribute to Point on Line of C= apture.  Clarify the description of this attribute.

   2.  Ticket #17.  Add "capture = encoding" definition.  Use this new term throughout document as a= ppropriate, replacing some usage of the terms "stream" and "= encoding".

   3.  Ad= d clarification that different capture scene entries are not necessarily mu= tually exclusive.

 

<= p class=3DMsoNormal>Regards,

Mark Duckwo= rth

= --_000_44C6B6B2D0CF424AA90B6055548D7A610390FF1FC4CRPMBOXPRD01p_-- From Mark.Duckworth@polycom.com Thu Oct 18 14:13:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2D8221F84F2 for ; Thu, 18 Oct 2012 14:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFS--DFrIW+5 for ; Thu, 18 Oct 2012 14:13:25 -0700 (PDT) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id B2FBF21F84EC for ; Thu, 18 Oct 2012 14:13:24 -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, 18 Oct 2012 14:13:24 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 18 Oct 2012 14:13:22 -0700 Thread-Topic: [clue] #18: Action Item (v): Limitations on Simulcast Thread-Index: Ac2shXL8qMIpvC0SREOv1tjSjK2FDgAA6nHwADonlZA= Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610390FF2065@CRPMBOXPRD01.polycom.com> References: <068.b6260d8ab33b49c5640cb5e9fb52e513@trac.tools.ietf.org> <083.f56300f15d5b06ffea92ab5fe5e8dca1@trac.tools.ietf.org> <44C6B6B2D0CF424AA90B6055548D7A610390EB3218@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610390EB3218@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_44C6B6B2D0CF424AA90B6055548D7A610390FF2065CRPMBOXPRD01p_" MIME-Version: 1.0 Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Oct 2012 21:13:28 -0000 --_000_44C6B6B2D0CF424AA90B6055548D7A610390FF2065CRPMBOXPRD01p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Conclusion 2 from the interim meeting says we need a way for the provider t= o indicate limitations on simulcast. So I'd like to add this to the next f= ramework version for the Atlanta meeting, plus any improvements discussed o= n the list before the deadline. Here is a more specific proposal to add this text to the framework, in the = section for Media Capture Attributes. =3D=3D=3D=3D begin new text =3D=3D=3D=3D=3D Max Capture Encodings: {unsigned integer} An optional attribute indicating the maximum number of capture encodings th= at can be simultaneously active for the media capture. If absent, this par= ameter defaults to 1. The number of simultaneous capture encodings is als= o limited by the restrictions of the encoding group for the media capture. =3D=3D=3D=3D end new text =3D=3D=3D=3D=3D Should the minimum allowed value be 1? Or is there some use for a value of= 0 (zero)? 0 would mean the media provider can't encode this capture at al= l, so the consumer cannot ask for it. Also modify this sentence from the section for "Associating Media Captures = with Encoding Groups": =3D=3D=3D=3D begin modified text =3D=3D=3D=3D=3D If there are multiple individual encodings in the group, then the media con= sumer can configure the media provider to encode a single media capture int= o multiple different capture encodings at the same time, subject to the Max= Capture Encodings constraint, with each capture encoding following the con= straints of a different individual encoding. =3D=3D=3D=3D end modified text =3D=3D=3D=3D=3D Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duc= kworth, Mark Sent: Wednesday, October 17, 2012 1:04 PM To: clue@ietf.org Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast Hi Andy, This proposal for a new "maxEncodings" attribute sounds good to me. It fit= s nicely in the existing framework. I don't see it adding too much extra c= omplexity. Regards, Mark From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of And= y Pepperell Sent: Wednesday, October 17, 2012 12:36 PM To: clue issue tracker Cc: draft-ietf-clue-framework@tools.ietf.org; clue@ietf.org Subject: Re: [clue] #18: Action Item (v): Limitations on Simulcast I think I may have rashly volunteered to send something about this one... The proposal is to define within the framework a new, optional, "maxEncodin= gs" attribute that can be applied to a media capture (audio or video) in th= e provider's capture advertisement to convey to the consumer the maximum nu= mber of capture encodings that can be simultaneously active for the media c= apture in question. If absent, this parameter defaults to 1 - thus, systems= that traditionally have not supported any form of simulcast will not be ob= liged to do so as part of supporting CLUE, and systems which are capable of= simulcast can supply values greater than 1 for some or all of their media = captures. The number of capture encodings possible would still be limited b= y the restrictions of the provider's media captures' encoding groups, as be= fore. Hopefully this proposal is sufficiently detailed to at least foster some de= bate. I have a small concern that having to cope with this extra parameter = for each media capture will make the consumer's task more complex; however,= just as a provider can now choose to omit this value at leave all media ca= ptures with a default maxEncodings of 1, so a consumer could choose to trea= t all values above 1 as 1 and so avoid the complexity of simulcast itself t= oo. Regards, Andy On Sat, Oct 13, 2012 at 7:08 PM, clue issue tracker > wrote: #18: Action Item (v): Limitations on Simulcast Changes (by mary.ietf.barnes@...): * type: defect =3D> task * milestone: =3D> milestone1 -- --------------------------------+------------------------------------------ Reporter: mary.ietf.barnes@... | Owner: draft-ietf-clue-framework= @... Type: task | Status: new Priority: major | Milestone: milestone1 Component: framework | Version: Severity: - | Resolution: Keywords: | --------------------------------+------------------------------------------ Ticket URL: clue --_000_44C6B6B2D0CF424AA90B6055548D7A610390FF2065CRPMBOXPRD01p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Conclusio= n 2 from the interim meeting says we need a way for the provider to indicat= e limitations on simulcast.  So I’d like to add this to the next= framework version for the Atlanta meeting, plus any improvements discussed= on the list before the deadline.

 

Here is a m= ore specific proposal to add this text to the framework, in the section for= Media Capture Attributes.

 

=3D=3D=3D=3D begin= new text =3D=3D=3D=3D=3D

= Max Capture Encodings: {unsigned integer}

 

An = optional attribute indicating the maximum number of capture encodings that = can be simultaneously active for the media capture.  If absent, this p= arameter defaults  to 1.  The number of simultaneous capture enco= dings is also limited by the restrictions of the encoding group for the med= ia capture.

=3D=3D=3D=3D e= nd new text =3D=3D=3D=3D=3D

 

Should the minimu= m allowed value be 1?  Or is there some use for a value of 0 (zero)?&n= bsp; 0 would mean the media provider can’t encode this capture at all= , so the consumer cannot ask for it.

 

Also mod= ify this sentence from the section for “Associating Media Captures wi= th Encoding Groups”:

 

=3D=3D=3D=3D begin= modified text =3D=3D=3D=3D=3D

If there are multiple individual encodings in the group, then the medi= a consumer can configure the media provider to encode a single media captur= e into multiple different capture encodings at the same time, subject to th= e Max Capture Encodings constraint, with each capture encoding following th= e constraints of a different individual encoding.

=3D=3D=3D=3D end modified text =3D=3D=3D=3D=3D=

 

Mark

 

= From:= clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark
Sent: Wednesday, October 17, 2012 1:04 PM
To: clue@ietf.org
Subject: Re: [clue] #18: Action Item (v): = Limitations on Simulcast

 

Hi Andy,

This proposal for a new “maxEncod= ings” attribute sounds good to me.  It fits nicely in the existi= ng framework.  I don’t see it adding too much extra complexity.<= o:p>

Regards,=

Mark

 

From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf= Of Andy Pepperell
Sent: Wednesday, October 17, 2012 12:36 PM=
To: clue issue tracker
Cc: draft-ietf-clue-framework@t= ools.ietf.org; clue@ietf.org
Subject: Re: [clue] #18: Action Item= (v): Limitations on Simulcast

 

I think I may have rashly volunteered to send something about this = one...

The proposal is to define within the framework a new, optiona= l, "maxEncodings" attribute that can be applied to a media captur= e (audio or video) in the provider's capture advertisement to convey to the= consumer the maximum number of capture encodings that can be simultaneousl= y active for the media capture in question. If absent, this parameter defau= lts to 1 - thus, systems that traditionally have not supported any form of = simulcast will not be obliged to do so as part of supporting CLUE, and syst= ems which are capable of simulcast can supply values greater than 1 for som= e or all of their media captures. The number of capture encodings possible = would still be limited by the restrictions of the provider's media captures= ' encoding groups, as before.

Hopefully this proposal is sufficientl= y detailed to at least foster some debate. I have a small concern that havi= ng to cope with this extra parameter for each media capture will make the c= onsumer's task more complex; however, just as a provider can now choose to = omit this value at leave all media captures with a default maxEncodings of = 1, so a consumer could choose to treat all values above 1 as 1 and so avoid= the complexity of simulcast itself too.

Regards,

Andy

On Sat, Oct 13, 2012 at 7:08 PM, = clue issue tracker <trac+clue@trac.tools.ietf.org> wrote:

<= div>

#18: Action Item (v= ):  Limitations on Simulcast

Changes (by mary.ietf.barnes@…):
 * type:  defect =3D> task
 * milestone:   =3D&= gt; milestone1


--
--------------------------------+------= ------------------------------------
 R= eporter:  mary.ietf.barnes@…  |       Owner:=  draft-ietf-clue-framework@…
&nb= sp;    Type:  task            =    |      Status:  new
 Priority:  major           &n= bsp;   |   Milestone:  milestone1
Component:  framework           |  =   Version:
 Severity:  - &nb= sp;                 |  Resolut= ion:
 Keywords:       &n= bsp;              |
--------------------------------+-------------------------------= -----------

Ticket URL: <http://trac.tools.ietf.org/wg/clue/trac/ticket/18#comment:1>
clue <http://tools.ietf.org/wg/clue/><= o:p>

 

<= /div>= --_000_44C6B6B2D0CF424AA90B6055548D7A610390FF2065CRPMBOXPRD01p_-- From roni.even@mail01.huawei.com Sun Oct 21 13:06: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 B75D721F851B for ; Sun, 21 Oct 2012 13:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.424 X-Spam-Level: X-Spam-Status: No, score=-2.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWt-GvKcBiyc for ; Sun, 21 Oct 2012 13:05:59 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (hwsga02-in.huaweimarine.com [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id 76B3A21F86C8 for ; Sun, 21 Oct 2012 13:05:59 -0700 (PDT) Received: from szxpml203-edg.exmail.huawei.com ([172.17.1.119]) by hwsga02-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id ADU02800; Mon, 22 Oct 2012 04:05:56 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none Received: from SZXPML405-HUB.exmail.huawei.com (10.82.67.69) by szxpml203-edg.exmail.huawei.com (172.24.2.14) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 22 Oct 2012 04:05:55 +0800 Received: from SZXPML504-MBX.exmail.huawei.com ([169.254.3.218]) by szxpml405-hub.exmail.huawei.com ([10.82.67.69]) with mapi id 14.01.0323.003; Mon, 22 Oct 2012 04:05:55 +0800 From: Roni Even To: "clue@ietf.org" Thread-Topic: New Version Notification for draft-even-clue-sdp-clue-relation-01.txt Thread-Index: AQHNr8aXv0sDwYTW3EWBXPwYaDvGWpfEL1J0 Date: Sun, 21 Oct 2012 20:05:55 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B52B14@szxpml504-mbx.exmail.huawei.com> References: <20121021195913.2327.27708.idtracker@ietfa.amsl.com> In-Reply-To: <20121021195913.2327.27708.idtracker@ietfa.amsl.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [clue] FW: New Version Notification for draft-even-clue-sdp-clue-relation-01.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: Sun, 21 Oct 2012 20:06:00 -0000 ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Sunday, October 21, 2012 9:59 PM To: Roni Even Subject: New Version Notification for draft-even-clue-sdp-clue-relation-01.= txt A new version of I-D, draft-even-clue-sdp-clue-relation-01.txt has been successfully submitted by Roni Even and posted to the IETF repository. Filename: draft-even-clue-sdp-clue-relation Revision: 01 Title: Signalling of CLUE and SDP offer/answer Creation date: 2012-10-21 WG ID: Individual Submission Number of pages: 7 URL: http://www.ietf.org/internet-drafts/draft-even-clue-sdp-cl= ue-relation-01.txt Status: http://datatracker.ietf.org/doc/draft-even-clue-sdp-clue-r= elation Htmlized: http://tools.ietf.org/html/draft-even-clue-sdp-clue-relati= on-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-even-clue-sdp-clu= e-relation-01 Abstract: This document describes the relation between the different CLUE attributes as specified in the CLUE framework and the SDP attributes. The document will discuss the issues with the CLUE call signalling in order to keep the consistency between the Offer/answer state and the CLUE state. The IETF Secretariat= From pkyzivat@alum.mit.edu Mon Oct 22 06:28:46 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 9433221F8566 for ; Mon, 22 Oct 2012 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.38 X-Spam-Level: X-Spam-Status: No, score=-0.38 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0QSE++h7qDF for ; Mon, 22 Oct 2012 06:28:45 -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 A8F5C21F85B0 for ; Mon, 22 Oct 2012 06:28:45 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta02.westchester.pa.mail.comcast.net with comcast id ECxE1k00B1HzFnQ51DUqKe; Mon, 22 Oct 2012 13:28:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta14.westchester.pa.mail.comcast.net with comcast id EDUp1k0053ZTu2S3aDUprE; Mon, 22 Oct 2012 13:28:49 +0000 Message-ID: <50854A0B.7030009@alum.mit.edu> Date: Mon, 22 Oct 2012 09:28:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] Cancelling today's design team meeting 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, 22 Oct 2012 13:28:46 -0000 There has been little activity on the list this last week. Also Mary isn't available today. So I propose we just skip the call today, and people can spend the time getting ready for Atlanta. Next week I expect we will want to discuss plans for the Atlanta meeting. Thanks, Paul From pkyzivat@alum.mit.edu Mon Oct 22 06:33:42 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 915D521F8B89 for ; Mon, 22 Oct 2012 06:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WjukT9bZt48U for ; Mon, 22 Oct 2012 06:33:39 -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 F3A8221F8B8D for ; Mon, 22 Oct 2012 06:33:38 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id EASN1k00E0mv7h051DZgVo; Mon, 22 Oct 2012 13:33:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id EDZP1k00n3ZTu2S3XDZPe6; Mon, 22 Oct 2012 13:33:23 +0000 Message-ID: <50854B2E.8030105@alum.mit.edu> Date: Mon, 22 Oct 2012 09:33:34 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <507F2C8E.5050305@alum.mit.edu> In-Reply-To: <507F2C8E.5050305@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Thoughts on relation between clue messages and SDP 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, 22 Oct 2012 13:33:42 -0000 I've been surprised that there have been no replies to this message. Is that because it is so obvious and uncontroversial that no comment is needed? Or did I write it so poorly that nobody understands what I'm saying? Thanks, Paul On 10/17/12 6:09 PM, Paul Kyzivat wrote: > After discussions at the interim around the call flows and signaling > issues, and subsequent discussion, I have some revised ideas about how > the clue messages and SDP O/A can be coordinated. > > The Configure message selects capture encodings that the receiver wants > the sender to send to it via RTP sessions RTP streams within those > sessions that are specified in SDP. > > In some cases it may be that a new Configure can reuse the RTP resources > already present in a previously established O/A. But it is also possible > that a new Configure will ask for capture encodings that require RTP > resources that aren't present in the previously established O/A. In that > case a new O/A will be needed, before or after that Configure is sent. > > One of the questions that came up at the interim is whether the O/A to > prep for a Configure should come before, or after, the Configure. An > argument for doing the O/A *before* the Configure is that then it is > known that the resources to support the Configure are available, and > allows the Configure to reference elements present in the SDP. An > argument for doing the O/A *after* the Configure is that then the > answerer will understand *why* it is being asked to configure the SDP as > specified, and so help it decide whether it wants to accept that. > > I finally realized that the the Advertisement defines what is possible, > and implicitly indicates what SDP will be required to support that. > Hence, I think we can expect that an offerer can construct a new offer > in contemplation of a Configure message it plans to send plus the last > one it received, and in the context of the corresponding Advertisements. > The Answerer can then evaluate that offer in the context of the same > Advertisements. As long as the offer is consistent with current > advertisements it should aim to construct an answer that accepts it. > > With that approach, a Configure can be constructed relative to the most > recent O/A. > > During initial session setup, before the first Advertisements are > exchanged, the offerer will have to construct the first offer without > the context of an advertisement from the other side. It can however > still construct the offer to be consistent with the Advertisement it > plans to send. The Answerer can construct the answer in the context of > the Advertisement it plans to send, constrained by what is in the offer. > (The offer may not be sufficient for everything the answerer wishes to > include.) Each side can then begin sending media that fits within that > initial O/A, using a default Configure constructed locally. Concurrently > Advertisements can be exchanged. After that Configure messages may be > exchanged. (Or not if what is being received is satisfactory.) > > It may turn out that in many cases the initial O/A is sufficient for the > initial Configure that each side wants to send. If so then no new O/A is > needed. Or it may turn out that it isn't. If not, then either side may > initiate an O/A with an offer compatible with the desired Configure, I > described above. > > This also helps clarify that the Configure is both a selection from the > advertisement and a mapping of that selection onto the SDP. > > This also clarifies that the Advertisement must contain sufficient > information to map a Configure onto the SDP needed to convey that. For > instance, if the sender has encoders with independent IP addr/port, then > the offer will require multiple m-lines for those, but if both the > sender and receiver have all encoders on a single addr/port then one > m-line may be sufficient. Since the offerer determines the set of > m-lines in the O/A, it needs to figure this out on behalf of the answerer. > > What do people think of this approach? > > Thanks, > Paul (as individual) > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Oct 22 08:08:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0185821F8C41 for ; Mon, 22 Oct 2012 08:08:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5RosB03pc1sL for ; Mon, 22 Oct 2012 08:08:06 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id 3234421F8C2E for ; Mon, 22 Oct 2012 08:08:06 -0700 (PDT) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta09.westchester.pa.mail.comcast.net with comcast id EBTe1k0030Fqzac59F8Aor; Mon, 22 Oct 2012 15:08:10 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id EF7u1k00T3ZTu2S3UF7u4m; Mon, 22 Oct 2012 15:07:54 +0000 Message-ID: <50856154.4030207@alum.mit.edu> Date: Mon, 22 Oct 2012 11:08:04 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <20121021195913.2327.27708.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B52B14@szxpml504-mbx.exmail.huawei.com> In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B52B14@szxpml504-mbx.exmail.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] FW: New Version Notification for draft-even-clue-sdp-clue-relation-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:08:07 -0000 Roni, Thanks for submitting this. A few observations: Section 3: The CLUE framework [I-D.ietf-clue-framework] recommends using one transport connection for each media type multiplexing using one RTP session. This also makes it simple to add and remove media capture by the consumer without a need for an [RFC3264] offer answer. The exception is if the consumer prefers using a separate RTP non multiplex session. IMO the last statement isn't quite right. There may well be a desire for multiple transport connections for a media type even though there is an intent to multiplex multiple RTP media streams on each of them. For instance, there indeed might be a separate m-lines with content 'main' and 'slides', and yet both might be multiplexed - multiple cameras in main, and multiple presentation sessions in slides. Or it may be that there are multiple m-lines with content 'main', each multiplexed, because of using independent encoding hardware. So I would recommend either simply removing the sentence above "The exception...", or else replacing it with one or more that mention the various motivations for this. That same section then goes on to say: When multiplexing RTP streams in a single RTP session there is probably no need for offer answer exchange when the consumer send a new configuration. Is this really true? Suppose there is a single RTP session, and the advertisement gives the possibility of from one to three captures, and with a range of encodings. The amount of bandwidth required for this one m-line could vary by an order of magnitude or more depending on which capture encodings are configured. It is unlikely to be acceptable to negotiate the maximal bandwidth just on the off chance that it will be required. So it seems likely that some configurations will require a new O/A. (Of course there are also cases that will not - e.g. when a configuration simply replaces one capture encoding with another having similar encoding requirements.) I am still struggling to understand when the SDP maps to "captures", "encodings" and "capture encodings". Section 4 talks about bandwidth in the context of encodings, but in that part there is little mention of the relationship to when O/As will be needed for this part. I suppose one way to view things is that the O/A should be used to establish/enable a set of encodings from among those in the advertisement, while the Configure message is used to select which capture is mapped to each of those encodings. Is that what you have in mind? If so, then a new O/A may be required each time one is planning to send a Configure that selects encodings that have not already been negotiated in SDP. That also may put a slightly different spin on the "static" mapping, in that perhaps it will only identify an 'encoding', not a 'capture encoding'. Thanks, Paul On 10/21/12 4:05 PM, Roni Even wrote: > > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Sunday, October 21, 2012 9:59 PM > To: Roni Even > Subject: New Version Notification for draft-even-clue-sdp-clue-relation-01.txt > > A new version of I-D, draft-even-clue-sdp-clue-relation-01.txt > has been successfully submitted by Roni Even and posted to the > IETF repository. > > Filename: draft-even-clue-sdp-clue-relation > Revision: 01 > Title: Signalling of CLUE and SDP offer/answer > Creation date: 2012-10-21 > WG ID: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-even-clue-sdp-clue-relation-01.txt > Status: http://datatracker.ietf.org/doc/draft-even-clue-sdp-clue-relation > Htmlized: http://tools.ietf.org/html/draft-even-clue-sdp-clue-relation-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-sdp-clue-relation-01 > > Abstract: > This document describes the relation between the different CLUE > attributes as specified in the CLUE framework and the SDP attributes. > The document will discuss the issues with the CLUE call signalling in > order to keep the consistency between the Offer/answer state and the > CLUE state. > > > > > The IETF Secretariat > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From ron.even.tlv@gmail.com Mon Oct 22 08:44: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 7819021F88D5 for ; Mon, 22 Oct 2012 08:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NG2xmM9Hv7t1 for ; Mon, 22 Oct 2012 08:44:53 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4B54F21F8A6E for ; Mon, 22 Oct 2012 08:44:53 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so1219730eek.31 for ; Mon, 22 Oct 2012 08:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=BDoQpw2Kpr7108gXI4I8quDnFm9YEeYB+h+xULE6T88=; b=MeOhFskTUwTWOqQF3hx2x/b0lDmdHBzgSONinlLN63/9CfuW6BLyHR/cmD7GaNQPil jIzJrRe1+le4iruARLC7bqFlOEJ3KSNLjy2+CERJpb+QP6nZpeLLzCpSbaXEIGZlHsMP lgSvJnBL2fxg4lyBTlnRZhf6Un40pvmnBMxrpBEUbNbtt/V1elT9tOW+wfs0G+ejmHu2 0lgfmEwx3W/HsT9RWS91TGgbjU/I6ewO8zXEUa0iYQbzIa25LFa3OuozZwwiYQJ3yjOj 5WfpFgqPN0WKkQVAL/PbK7acVIE/Y53Lh19PLWI0JOWD1PfRxVF+agFKqeZWUTqWYNGL 7VVQ== Received: by 10.14.173.195 with SMTP id v43mr12504699eel.39.1350920692446; Mon, 22 Oct 2012 08:44:52 -0700 (PDT) Received: from RoniE (bzq-79-176-243-9.red.bezeqint.net. [79.176.243.9]) by mx.google.com with ESMTPS id a44sm3244100eeo.7.2012.10.22.08.44.49 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 22 Oct 2012 08:44:51 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <20121021195913.2327.27708.idtracker@ietfa.amsl.com> <760B7D45D1EFF74988DBF5C2122830C205B52B14@szxpml504-mbx.exmail.huawei.com> <50856154.4030207@alum.mit.edu> In-Reply-To: <50856154.4030207@alum.mit.edu> Date: Mon, 22 Oct 2012 17:42:38 +0200 Message-ID: <032501cdb06b$df71aa50$9e54fef0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIGjrS1SQOpeG9KVPiMEeHBZ4qxpgFCKsdeASoOVseXQFZsEA== Content-Language: en-us Subject: Re: [clue] FW: New Version Notification for draft-even-clue-sdp-clue-relation-01.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 15:44:54 -0000 Hi Paul, Thanks, see inline Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 22 October, 2012 5:08 PM To: clue@ietf.org Subject: Re: [clue] FW: New Version Notification for draft-even-clue-sdp-clue-relation-01.txt Roni, Thanks for submitting this. A few observations: Section 3: The CLUE framework [I-D.ietf-clue-framework] recommends using one transport connection for each media type multiplexing using one RTP session. This also makes it simple to add and remove media capture by the consumer without a need for an [RFC3264] offer answer. The exception is if the consumer prefers using a separate RTP non multiplex session. IMO the last statement isn't quite right. There may well be a desire for multiple transport connections for a media type even though there is an intent to multiplex multiple RTP media streams on each of them. For instance, there indeed might be a separate m-lines with content 'main' and 'slides', and yet both might be multiplexed - multiple cameras in main, and multiple presentation sessions in slides. Or it may be that there are multiple m-lines with content 'main', each multiplexed, because of using independent encoding hardware. So I would recommend either simply removing the sentence above "The exception...", or else replacing it with one or more that mention the various motivations for this. Roni E: you are right and I can change the text, the issue is that there may be a need to open a new transport connection later, it can be multiplexed or not. That same section then goes on to say: When multiplexing RTP streams in a single RTP session there is probably no need for offer answer exchange when the consumer send a new configuration. Is this really true? Suppose there is a single RTP session, and the advertisement gives the possibility of from one to three captures, and with a range of encodings. The amount of bandwidth required for this one m-line could vary by an order of magnitude or more depending on which capture encodings are configured. It is unlikely to be acceptable to negotiate the maximal bandwidth just on the off chance that it will be required. So it seems likely that some configurations will require a new O/A. (Of course there are also cases that will not - e.g. when a configuration simply replaces one capture encoding with another having similar encoding requirements.) Roni E: I did not say that there is no need but you can do without it. I do not think that current implementation will send a new offer/answer to lower bandwidth if they are not using it since it is a maximum receive value and not reservation for sending. This is different from the encoding value which is the sending bandwidth. I am still struggling to understand when the SDP maps to "captures", "encodings" and "capture encodings". Section 4 talks about bandwidth in the context of encodings, but in that part there is little mention of the relationship to when O/As will be needed for this part. Roni E: I think I covered it considering that the b= in the SDP is receive value while the encoding is send value. The b= say that the sender cannot send more so both provide the limit. I suppose one way to view things is that the O/A should be used to establish/enable a set of encodings from among those in the advertisement, while the Configure message is used to select which capture is mapped to each of those encodings. Is that what you have in mind? If so, then a new O/A may be required each time one is planning to send a Configure that selects encodings that have not already been negotiated in SDP. Roni E: I do not see the case for that. Again the SDP is receive values so a configuration will not ask for something it cannot receive. That also may put a slightly different spin on the "static" mapping, in that perhaps it will only identify an 'encoding', not a 'capture encoding'. Thanks, Paul On 10/21/12 4:05 PM, Roni Even wrote: > > > ________________________________________ > From: internet-drafts@ietf.org [internet-drafts@ietf.org] > Sent: Sunday, October 21, 2012 9:59 PM > To: Roni Even > Subject: New Version Notification for > draft-even-clue-sdp-clue-relation-01.txt > > A new version of I-D, draft-even-clue-sdp-clue-relation-01.txt > has been successfully submitted by Roni Even and posted to the IETF > repository. > > Filename: draft-even-clue-sdp-clue-relation > Revision: 01 > Title: Signalling of CLUE and SDP offer/answer > Creation date: 2012-10-21 > WG ID: Individual Submission > Number of pages: 7 > URL: http://www.ietf.org/internet-drafts/draft-even-clue-sdp-clue-relation-01.txt > Status: http://datatracker.ietf.org/doc/draft-even-clue-sdp-clue-relation > Htmlized: http://tools.ietf.org/html/draft-even-clue-sdp-clue-relation-01 > Diff: http://www.ietf.org/rfcdiff?url2=draft-even-clue-sdp-clue-relation-01 > > Abstract: > This document describes the relation between the different CLUE > attributes as specified in the CLUE framework and the SDP attributes. > The document will discuss the issues with the CLUE call signalling in > order to keep the consistency between the Offer/answer state and the > CLUE state. > > > > > The IETF Secretariat > _______________________________________________ > 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 internet-drafts@ietf.org Mon Oct 22 11:47: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 6B28A11E8099; Mon, 22 Oct 2012 11:47:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.54 X-Spam-Level: X-Spam-Status: No, score=-102.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQHoy+xBqaaJ; Mon, 22 Oct 2012 11:47:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED2A011E809A; Mon, 22 Oct 2012 11:47:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.34 Message-ID: <20121022184739.19087.89111.idtracker@ietfa.amsl.com> Date: Mon, 22 Oct 2012 11:47:39 -0700 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-07.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Oct 2012 18:47:40 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Author(s) : Allyn Romanow Mark Duckworth Andrew Pepperell Brian Baldino Filename : draft-ietf-clue-framework-07.txt Pages : 35 Date : 2012-10-22 Abstract: This memo offers a framework for a protocol that enables devices in a telepresence conference to interoperate by specifying the relationships between multiple media streams. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-framework There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-framework-07 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-framework-07 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From roberta.presta@unina.it Wed Oct 24 07:27: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 31DEC21F8A8C for ; Wed, 24 Oct 2012 07:27:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bND54iXcdach for ; Wed, 24 Oct 2012 07:27:02 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 42C2121F8A89 for ; Wed, 24 Oct 2012 07:27:02 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.198]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id q9OEQvZq014358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Oct 2012 16:26:58 +0200 Message-ID: <5087FAB3.2040500@unina.it> Date: Wed, 24 Oct 2012 16:26:59 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <20121016155206.GB44606@verdi> In-Reply-To: <20121016155206.GB44606@verdi> Content-Type: multipart/alternative; boundary="------------050709090900000902020200" X-Antivirus: avast! (VPS 121024-0, 24/10/2012), Outbound message X-Antivirus-Status: Clean Subject: Re: [clue] Clue data model updates 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, 24 Oct 2012 14:27:03 -0000 This is a multi-part message in MIME format. --------------050709090900000902020200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi all, in order to convey the information about the mic type, I propose the introduction of the element as a further feature describing an audio capture. The updated schema would be the following: Do you think this could accomplish John's recommendations? Is there any main mic pattern missing? Cheers, Roberta Il 16/10/2012 17:52, John Leslie ha scritto: > Roberta Presta wrote: >> Il 15/10/2012 18:27, Paul Kyzivat ha scritto: >>> ... >>> Now that you have detailed the video case, ISTM that there ought to be >>> *some* spatial information about audio... >> Actually, with the current version of the data model, there is the >> possibility to discriminate between (non-composed) audio streams >> captured by directional microphones and omni-directional microphones, >> but we can not provide spatial information for composed audio captures. > True. > >> When a simple audio capture is captured by a directional mic, its >> representation in the datamodel contains the reference to a >> element, which is the position of the mic, with a >> child element that gives the mic direction. > Actually, all mikes are directional (though some have a figure-8 > pattern and should be called bi-directional, and others are multiple > microphones capable of being processed to _any_ directionality). > >> On the other hand, if the capture is captured by an omni-directional >> mic, its representation in the datamodel contains the reference to a >> , which is the position of the mic, without a >> child. > For what is generally called "omni-directional", this is technically > wrong. "Omni-directional" mikes have a directional pattern, but it is > less pronounced than "cardioid" or "shotgun" mikes. > > I would recommend that we keep for all mikes, > understanding that there are cases where the sensitivity pattern is > too close to unity to be worth using. I also recommend that for all > mikes there be a field for "pattern" -- most likely an enumeration > of cases starting with "omni-directional" and "cardioid". > > In many applications, even these differences wouldn't be worth > spending any processing time; but I believe the data structure should > allow for specifying them. > > -- > John Leslie > --------------050709090900000902020200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi all,

in order to convey the information about the mic type, I propose the introduction of the <micPattern> element as a further feature describing an audio capture.
The updated schema would be the following:

     <!-- AUDIO CAPTURE TYPE -->
     <xs:complexType name="audioCaptureType">
        <xs:complexContent>
         <xs:extension base="tns:mediaCaptureType">
          <xs:sequence>         
           <xs:element name="audioChannelFormat" type="tns:audioChannelFormatType" minOccurs="0"/>
           <xs:element name="micPattern" type="tns:micPatternType" minOccurs="0"/>
          </xs:sequence>
         </xs:extension>
        </xs:complexContent>
     </xs:complexType>
    
     <!-- MIC PATTERN TYPE -->
     <xs:simpleType name="micPatternType">
      <xs:restriction>
       <xs:enumeration value="shotgun"/>      
       <xs:enumeration value="uni"/>
       <xs:enumeration value="omni"/>
       <xs:enumeration value="figure8"/>
       <xs:enumeration value="cardioid"/>
       <xs:enumeration value="hyper-cardioid"/>             
      </xs:restriction>
     </xs:simpleType>

Do you think this could accomplish John's recommendations?
Is there any main mic pattern  missing?

Cheers,

Roberta




Il 16/10/2012 17:52, John Leslie ha scritto:
Roberta Presta <roberta.presta@unina.it> wrote:

Il 15/10/2012 18:27, Paul Kyzivat ha scritto:

...
Now that you have detailed the video case, ISTM that there ought to be 
*some* spatial information about audio...

Actually, with the current version of the data model, there is the 
possibility to discriminate between (non-composed) audio streams 
captured by directional microphones and omni-directional microphones, 
but we can not provide spatial information for composed audio captures.

   True.


When a simple audio capture is captured by a directional mic, its 
representation in the datamodel contains the reference to a 
<capturePoint> element, which is the position of the mic, with a 
<captureAxisPoint> child element that gives the mic direction.

   Actually, all mikes are directional (though some have a figure-8
pattern and should be called bi-directional, and others are multiple
microphones capable of being processed to _any_ directionality).


On the other hand, if the capture is captured by an omni-directional 
mic, its representation in the datamodel contains the reference to a 
<capturePoint>, which is the position of the mic, without a 
<captureAxisPoint> child.

   For what is generally called "omni-directional", this is technically
wrong. "Omni-directional" mikes have a directional pattern, but it is
less pronounced than "cardioid" or "shotgun" mikes.

   I would recommend that we keep <captureAxisPoint> for all mikes,
understanding that there are cases where the sensitivity pattern is
too close to unity to be worth using. I also recommend that for all
mikes there be a field for "pattern" -- most likely an enumeration
of cases starting with "omni-directional" and "cardioid".

   In many applications, even these differences wouldn't be worth
spending any processing time; but I believe the data structure should
allow for specifying them.

--
John Leslie <john@jlc.net>

--------------050709090900000902020200-- From pkyzivat@alum.mit.edu Wed Oct 24 09:26:46 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 4ADE321F860C for ; Wed, 24 Oct 2012 09:26:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VvHLAeaG3Bb for ; Wed, 24 Oct 2012 09:26:45 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 40F0C21F85F3 for ; Wed, 24 Oct 2012 09:26:45 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta03.westchester.pa.mail.comcast.net with comcast id F1YH1k01f0xGWP8534Sp1J; Wed, 24 Oct 2012 16:26:49 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id F4Rj1k0063ZTu2S3Y4Rjtm; Wed, 24 Oct 2012 16:25:43 +0000 Message-ID: <508816C1.4070104@alum.mit.edu> Date: Wed, 24 Oct 2012 12:26:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <20121016155206.GB44606@verdi> <5087FAB3.2040500@unina.it> In-Reply-To: <5087FAB3.2040500@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Clue data model updates 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, 24 Oct 2012 16:26:46 -0000 inline On 10/24/12 10:26 AM, Roberta Presta wrote: > Hi all, > > in order to convey the information about the mic type, I propose the > introduction of the element as a further feature describing > an audio capture. > The updated schema would be the following: > > > > > > > type="tns:audioChannelFormatType" minOccurs="0"/> > minOccurs="0"/> > > > > > > > > > > > > > > > > Speaking from total ignorance: Do any/all of these pattern types require numbers to parameterize them, in addition to the axis of capture? These seem to describe classes of geometric shapes. If we had "square" I would want to know "how big". I imagine the same would be true for "figure8". John? Thanks, Paul > Do you think this could accomplish John's recommendations? > Is there any main mic pattern missing? > > Cheers, > > Roberta > > > > > Il 16/10/2012 17:52, John Leslie ha scritto: >> Roberta Presta wrote: >>> Il 15/10/2012 18:27, Paul Kyzivat ha scritto: >>>> ... >>>> Now that you have detailed the video case, ISTM that there ought to be >>>> *some* spatial information about audio... >>> Actually, with the current version of the data model, there is the >>> possibility to discriminate between (non-composed) audio streams >>> captured by directional microphones and omni-directional microphones, >>> but we can not provide spatial information for composed audio captures. >> True. >> >>> When a simple audio capture is captured by a directional mic, its >>> representation in the datamodel contains the reference to a >>> element, which is the position of the mic, with a >>> child element that gives the mic direction. >> Actually, all mikes are directional (though some have a figure-8 >> pattern and should be called bi-directional, and others are multiple >> microphones capable of being processed to _any_ directionality). >> >>> On the other hand, if the capture is captured by an omni-directional >>> mic, its representation in the datamodel contains the reference to a >>> , which is the position of the mic, without a >>> child. >> For what is generally called "omni-directional", this is technically >> wrong. "Omni-directional" mikes have a directional pattern, but it is >> less pronounced than "cardioid" or "shotgun" mikes. >> >> I would recommend that we keep for all mikes, >> understanding that there are cases where the sensitivity pattern is >> too close to unity to be worth using. I also recommend that for all >> mikes there be a field for "pattern" -- most likely an enumeration >> of cases starting with "omni-directional" and "cardioid". >> >> In many applications, even these differences wouldn't be worth >> spending any processing time; but I believe the data structure should >> allow for specifying them. >> >> -- >> John Leslie >> > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From john@jlc.net Wed Oct 24 09:41:16 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 227A121F8C6E for ; Wed, 24 Oct 2012 09:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.452 X-Spam-Level: X-Spam-Status: No, score=-106.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCsBL7cQQyVj for ; Wed, 24 Oct 2012 09:41:15 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 287C021F8C48 for ; Wed, 24 Oct 2012 09:41:15 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id CABD233C22; Wed, 24 Oct 2012 12:41:14 -0400 (EDT) Date: Wed, 24 Oct 2012 12:41:14 -0400 From: John Leslie To: Roberta Presta Message-ID: <20121024164114.GG27557@verdi> References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <20121016155206.GB44606@verdi> <5087FAB3.2040500@unina.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5087FAB3.2040500@unina.it> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 24 Oct 2012 16:41:16 -0000 Roberta Presta wrote: > > in order to convey the information about the mic type, I propose the > introduction of the element as a further feature describing > an audio capture. > The updated schema would be the following: > > > > > > > type="tns:audioChannelFormatType" minOccurs="0"/> > minOccurs="0"/> > > > > > > > > > > > > > > > > > > Do you think this could accomplish John's recommendations? In essence, this is right. However, it would be good to reference a definition of the patterns. I suggest from Wiki:Microphone http://en.wikipedia.org/wiki/File:Polar_pattern_directional.png http://en.wikipedia.org/wiki/File:Polar_pattern_omnidirectional.png http://en.wikipedia.org/wiki/File:Polar_pattern_figure_eight.png http://en.wikipedia.org/wiki/File:Polar_pattern_cardioid.png http://en.wikipedia.org/wiki/File:Polar_pattern_hypercardioid.png > Is there any main mic pattern missing? That Wiki page also has subcardiod and supercardiod, but I don't consider them terribly important. What we should have is a mechanism to add more patterns during the life of the standard. (I don't recommend simply linking to the Wiki:Microphone page: it's a bit too ephemeral, while these "File:" entries aren't likely to see major changes.) -- John Leslie From pkyzivat@alum.mit.edu Wed Oct 24 10:11:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC39921F8691 for ; Wed, 24 Oct 2012 10:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.374 X-Spam-Level: X-Spam-Status: No, score=-0.374 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XKZcuAbSFWx for ; Wed, 24 Oct 2012 10:11:02 -0700 (PDT) Received: from qmta09.westchester.pa.mail.comcast.net (qmta09.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:96]) by ietfa.amsl.com (Postfix) with ESMTP id CA39A21F8856 for ; Wed, 24 Oct 2012 10:11:01 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta09.westchester.pa.mail.comcast.net with comcast id EynF1k0051c6gX8595B6mV; Wed, 24 Oct 2012 17:11:06 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id F5AG1k0123ZTu2S3j5AGwp; Wed, 24 Oct 2012 17:10:17 +0000 Message-ID: <50882123.1000907@alum.mit.edu> Date: Wed, 24 Oct 2012 13:10:59 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <20121016155206.GB44606@verdi> <5087FAB3.2040500@unina.it> <20121024164114.GG27557@verdi> In-Reply-To: <20121024164114.GG27557@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Clue data model updates 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, 24 Oct 2012 17:11:02 -0000 On 10/24/12 12:41 PM, John Leslie wrote: > Roberta Presta wrote: >> >> in order to convey the information about the mic type, I propose the >> introduction of the element as a further feature describing >> an audio capture. >> The updated schema would be the following: >> >> >> >> >> >> >> > type="tns:audioChannelFormatType" minOccurs="0"/> >> > minOccurs="0"/> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Do you think this could accomplish John's recommendations? > > In essence, this is right. However, it would be good to reference > a definition of the patterns. I suggest from Wiki:Microphone > > http://en.wikipedia.org/wiki/File:Polar_pattern_directional.png > http://en.wikipedia.org/wiki/File:Polar_pattern_omnidirectional.png > http://en.wikipedia.org/wiki/File:Polar_pattern_figure_eight.png > http://en.wikipedia.org/wiki/File:Polar_pattern_cardioid.png > http://en.wikipedia.org/wiki/File:Polar_pattern_hypercardioid.png > >> Is there any main mic pattern missing? > > That Wiki page also has subcardiod and supercardiod, but I don't > consider them terribly important. What we should have is a mechanism > to add more patterns during the life of the standard. > > (I don't recommend simply linking to the Wiki:Microphone page: > it's a bit too ephemeral, while these "File:" entries aren't likely > to see major changes.) John: Is there any stable document (preferably from some SDO) that can be referenced for these? And, as I asked in an earlier message, should these patterns be parameterized in some way? E.g. I *guess* that some shotgun mics are more narrowly focused than others, and so would expect some metric that indicates how narrow that focus is. Thanks, Paul From john@jlc.net Wed Oct 24 10:37: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 B59CA21F8727 for ; Wed, 24 Oct 2012 10:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.455 X-Spam-Level: X-Spam-Status: No, score=-106.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B-c39tKNnwJc for ; Wed, 24 Oct 2012 10:37:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id BF36B21F8711 for ; Wed, 24 Oct 2012 10:37:23 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id DADBE33C23; Wed, 24 Oct 2012 13:37:23 -0400 (EDT) Date: Wed, 24 Oct 2012 13:37:23 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20121024173723.GH27557@verdi> References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <20121016155206.GB44606@verdi> <5087FAB3.2040500@unina.it> <20121024164114.GG27557@verdi> <50882123.1000907@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50882123.1000907@alum.mit.edu> User-Agent: Mutt/1.4.1i Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 24 Oct 2012 17:37:25 -0000 Paul Kyzivat wrote: > On 10/24/12 12:41 PM, John Leslie wrote: >>... >> http://en.wikipedia.org/wiki/File:Polar_pattern_directional.png >> http://en.wikipedia.org/wiki/File:Polar_pattern_omnidirectional.png >> http://en.wikipedia.org/wiki/File:Polar_pattern_figure_eight.png >> http://en.wikipedia.org/wiki/File:Polar_pattern_cardioid.png >> http://en.wikipedia.org/wiki/File:Polar_pattern_hypercardioid.png > > John: Is there any stable document (preferably from some SDO) that can > be referenced for these? I'm not aware of any: I have seen patterns like these from vendors, not standards bodies. Furthermore, these are idealizations: no actual microphone will exactly match any of these, and the patterns are always different at different frequencies. > And, as I asked in an earlier message, should these patterns be > parameterized in some way? E.g. I *guess* that some shotgun mics are > more narrowly focused than others, and so would expect some metric that > indicates how narrow that focus is. I have never run into a parameterized version, though I have certainly seen detail differences on _actual_ polar patters measured by vendors. If we ever get there, we could perhaps have vendors register actual patterns for specific models. -- John Leslie From coverdale@sympatico.ca Wed Oct 24 14:52:30 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 DC61E21F883E for ; Wed, 24 Oct 2012 14:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.896 X-Spam-Level: X-Spam-Status: No, score=-0.896 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599, MSGID_FROM_MTA_HEADER=0.803] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aBTtfkp+SrJq for ; Wed, 24 Oct 2012 14:52:17 -0700 (PDT) Received: from blu0-omc1-s30.blu0.hotmail.com (blu0-omc1-s30.blu0.hotmail.com [65.55.116.41]) by ietfa.amsl.com (Postfix) with ESMTP id C8EA721F8C71 for ; Wed, 24 Oct 2012 14:52:14 -0700 (PDT) Received: from BLU0-SMTP70 ([65.55.116.7]) by blu0-omc1-s30.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 14:52:13 -0700 X-Originating-IP: [70.26.38.196] X-EIP: [Y3+bBWVTr11oEZr7Ve5UJMeLDWCAakiT] X-Originating-Email: [coverdale@sympatico.ca] Message-ID: Received: from PaulNewPC ([70.26.38.196]) by BLU0-SMTP70.blu0.hotmail.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 24 Oct 2012 14:52:12 -0700 From: Paul Coverdale To: "'John Leslie'" , "'Paul Kyzivat'" References: <507D73C0.8020305@unina.it> <507D78BF.70805@unina.it> <20121016155206.GB44606@verdi> <5087FAB3.2040500@unina.it> <20121024164114.GG27557@verdi> <50882123.1000907@alum.mit.edu> <20121024173723.GH27557@verdi> In-Reply-To: <20121024173723.GH27557@verdi> Date: Wed, 24 Oct 2012 17:52:04 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac2yDkH9hJePdcaVQdyrVbBAuuffGAAIvqqw Content-Language: en-us X-OriginalArrivalTime: 24 Oct 2012 21:52:12.0626 (UTC) FILETIME=[D2F89320:01CDB231] Cc: clue@ietf.org Subject: Re: [clue] Clue data model updates 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, 24 Oct 2012 21:52:30 -0000 Maybe I missed it, but I presume that somewhere you're going to capture the electro-acoustic sensitivity of the microphones as well? In the ITU-T Telepresence work, this has been rolled up into the overall sending loudness rating of the system. ...Paul >-----Original Message----- >From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >John Leslie >Sent: Wednesday, October 24, 2012 1:37 PM >To: Paul Kyzivat >Cc: clue@ietf.org >Subject: Re: [clue] Clue data model updates > >Paul Kyzivat wrote: >> On 10/24/12 12:41 PM, John Leslie wrote: >>>... >>> http://en.wikipedia.org/wiki/File:Polar_pattern_directional.png >>> http://en.wikipedia.org/wiki/File:Polar_pattern_omnidirectional.png >>> http://en.wikipedia.org/wiki/File:Polar_pattern_figure_eight.png >>> http://en.wikipedia.org/wiki/File:Polar_pattern_cardioid.png >>> http://en.wikipedia.org/wiki/File:Polar_pattern_hypercardioid.png >> >> John: Is there any stable document (preferably from some SDO) that can >> be referenced for these? > > I'm not aware of any: I have seen patterns like these from vendors, >not standards bodies. > > Furthermore, these are idealizations: no actual microphone will >exactly match any of these, and the patterns are always different at >different frequencies. > >> And, as I asked in an earlier message, should these patterns be >> parameterized in some way? E.g. I *guess* that some shotgun mics are >> more narrowly focused than others, and so would expect some metric >> that indicates how narrow that focus is. > > I have never run into a parameterized version, though I have >certainly seen detail differences on _actual_ polar patters measured by >vendors. > > If we ever get there, we could perhaps have vendors register actual >patterns for specific models. > >-- >John Leslie >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From roberta.presta@unina.it Fri Oct 26 03:13: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 6D75121F84C4 for ; Fri, 26 Oct 2012 03:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2lHTAxe5lKZz for ; Fri, 26 Oct 2012 03:13:27 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id C2DD021F84C0 for ; Fri, 26 Oct 2012 03:13:26 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.198]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id q9QADHsF012916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 26 Oct 2012 12:13:18 +0200 Message-ID: <508A6242.80001@unina.it> Date: Fri, 26 Oct 2012 12:13:22 +0200 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org Content-Type: multipart/alternative; boundary="------------050302010806090807050906" X-Antivirus: avast! (VPS 121026-0, 26/10/2012), Outbound message X-Antivirus-Status: Clean Subject: [clue] again on X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 10:13:28 -0000 This is a multi-part message in MIME format. --------------050302010806090807050906 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi all, we have tried to restructure the data model format according to the following considerations: - we are interested in spatial relationship among media captures belonging to the same capture scene - we are not interested in spatial relationship among media captures belonging to different capture scenes - each capture scene has an independent coordinate space (different capture scenes can have different coordinate spaces) - coordinates within the same scene must share the same unit of measure and coordinate space Given these assumptions, spatial information associated with media captures makes sense only within the scope of the same capture scene. Spatial information of media captures must be then associated with a certain capture scene, in order to be spatially related. We have reintroduced a element in the media capture type with a mandatory attribute, "sceneIDREF", containing the ID of the scene the media capture is associated with. The element appears only in "spatially definible" media captures (i.e., captures that can be spatially described) and provides information about capture points, capture axis points and capture areas. Below you please find the datamodel updates and further comments: * Media capture type still presents a element allowing to distinguish between spatially definible captures and non spatially definible captures. Capture of the last case are for example those related to registrations, DVDs, registered presentation, or external streams, that are played in the telepresence room and transmitted to remote sites. Spatially definible captures are those for which we can provide some spatial information in a element. * The element is referred to the coordinate space of the capture scene indicated in the "sceneIDREF" attribute. The framework doesn't seem to force a capture to be associated with only one scene (or, at least, I don't remember to have read such a constraint in the framework document). If a capture is involved in more than one scene, more than one should be provided, each one related to the coordinate space of the involving scene. * We have brought out of the choice section the element because even composed streams can be differentiated in "spatially definible" or not. If we can provide some spatial information for a composed stream, it is "spatially definible"; otherwise, we mark that composed stream with a element. We can consider the case of the composed PiP video. The framework document states that the biggest captured area should be provided - that's a spatial characterization of the capture. You would have a capture with a element with the information of the biggest capture area provided in the / element. In that case, the would be the vertex of the angular sector corresponding to the maximum captured space. The same rationale can be applied to composed audio captures - you can define a capture with an indication of the captured space in the element. You can also choose not to provide any spatial information and describe the composed capture as and . There is also a third alternative, i.e. the one of providing a for each spatially definible contribution of the composed stream, each of such elements referring to the same capture scene. What are your feelings about this proposal? Cheers, Roberta & Simon --------------050302010806090807050906 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Hi all,

we have tried to restructure the data model format according to the following considerations:
- we are interested in spatial relationship among media captures belonging to the same capture scene
- we are not interested in spatial relationship among media captures belonging to different capture scenes
- each capture scene has an independent coordinate space (different capture scenes can have different coordinate spaces)
- coordinates within the same scene must share the same unit of measure and coordinate space

Given these assumptions, spatial information associated with media captures makes sense only within the scope of the same capture scene.
Spatial information of media captures must be then associated with a certain capture scene, in order to be spatially related.
We have reintroduced a <spatialInformation> element in the media capture type with a mandatory attribute, "sceneIDREF", containing the ID of the scene the media capture is associated with.
The <spatialInformation> element appears only in "spatially definible" media captures (i.e., captures that can be spatially described) and provides information about capture points, capture axis points and capture areas.

Below you please find the datamodel updates and further comments:

     <!-- MEDIA CAPTURE TYPE -->
     <xs:complexType name="mediaCaptureType" abstract="true">
        <xs:sequence>
         <xs:element ref="description" minOccurs="0"/>
         <xs:element name="capturedMedia" type="xs:string" minOccurs="0"/>            
         <xs:element name="encGroupIDREF" type="xs:IDREF"/>
         <xs:element name="content" type="xs:string" minOccurs="0"/>        
         <xs:element name="switched" type="xs:boolean" minOccurs="0"/> 
         <xs:element name="composed" type="xs:boolean" minOccurs="0"/>                                                        
         <xs:element name="maxCaptureEncodings" type="xs:unsignedInt" minOccurs="0"/>
         <xs:choice>
             <xs:sequence>
              <xs:element name="spatialInformation" type="tns:spatialInformationType" maxOccurs="unbounded"/>
            </xs:sequence>                
             <xs:element name="nonSpatiallyDefinible" type="xs:boolean" fixed="true"/>                         
         </xs:choice>                                                                          
         <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>                 
        </xs:sequence>
        <xs:attribute name="captureID" type="xs:ID" use="required"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>
    
     <!-- SPATIAL INFORMATION TYPE -->
     <xs:complexType name="spatialInformationType">
     <xs:sequence>           
       <xs:element name="capturePoint" type="capturePointType"/>
       <xs:element name="captureArea" type="captureAreaType" minOccurs="0"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>       
      </xs:sequence>           
      <xs:attribute name="sceneIDREF" type="xs:IDREF" use="required"/>
       <xs:anyAttribute namespace="##other" processContents="lax"/>   
     </xs:complexType>

* Media capture type still presents a <choice> element allowing to distinguish between spatially definible captures and non spatially definible captures.

         <xs:choice>
             <xs:sequence>
              <xs:element name="spatialInformation" type="tns:spatialInformationType" maxOccurs="unbounded"/>
            </xs:sequence>                
             <xs:element name="nonSpatiallyDefinible" type="xs:boolean" fixed="true"/>                         
         </xs:choice>                                                                          

Capture of the last case are for example those related to registrations, DVDs, registered presentation, or external streams, that are played in the telepresence room and transmitted to remote sites. Spatially definible captures are those for which we can provide some spatial information in a <spatialInformation> element.

* The <spatialInformation> element is referred to the coordinate space of the capture scene indicated in the "sceneIDREF" attribute.
The framework doesn't seem to force a capture to be associated with only one scene (or, at least, I don't remember to have read such a constraint in the framework document).
If a capture is involved in more than one scene, more than one <spatialInformation> should be provided, each one related to the coordinate space of the involving scene.

*  We have brought out of the choice section the <composed> element because even composed streams can be differentiated in "spatially definible" or not.
If we can provide some spatial information for a composed stream, it is "spatially definible"; otherwise, we mark that composed stream with a <nonSpatiallyDefinible> element.
We can consider the case of the composed PiP video. The framework document states that the biggest captured area  should be provided - that's a spatial characterization of the capture.
You would have a <composed> capture with a <spatialInformation> element with the information of the biggest capture area provided in the <spatialInformation>/<captureArea> element. In that case, the <capturePoint> would be the vertex of the angular sector corresponding to the maximum captured space.
The same rationale can be applied to composed audio captures - you can define a <composed> capture with an indication of the captured space in the <spatialInformation> element.
You can also choose not to provide any spatial information and describe the composed capture as <composed> and <nonSpatiallyDefinible>.
There is also a third alternative, i.e. the one of providing a <spatialInformation> for each spatially definible contribution of the composed stream, each of such <spatialInformation> elements referring to the same capture scene.

What are your feelings about this proposal?

Cheers,

Roberta & Simon


--------------050302010806090807050906-- From pkyzivat@alum.mit.edu Fri Oct 26 12:49: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 59A1C21F8467 for ; Fri, 26 Oct 2012 12:49:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.379 X-Spam-Level: X-Spam-Status: No, score=-0.379 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nB9pNYQBSm1E for ; Fri, 26 Oct 2012 12:49:08 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id CF82021F8451 for ; Fri, 26 Oct 2012 12:49:07 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta05.westchester.pa.mail.comcast.net with comcast id FrBN1k00E0QuhwU55vpCgF; Fri, 26 Oct 2012 19:49:12 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id Fvod1k00E3ZTu2S3Nvodo9; Fri, 26 Oct 2012 19:48:37 +0000 Message-ID: <508AE931.3040702@alum.mit.edu> Date: Fri, 26 Oct 2012 15:49:05 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <508A6242.80001@unina.it> In-Reply-To: <508A6242.80001@unina.it> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] again on X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2012 19:49:08 -0000 Roberta, I don't see how this addresses the problem. I think I see why. Comment inline On 10/26/12 6:13 AM, Roberta Presta wrote: [snip] > * The element is referred to the coordinate space > of the capture scene indicated in the "sceneIDREF" attribute. > The framework doesn't seem to force a capture to be associated with only > one scene (or, at least, I don't remember to have read such a constraint > in the framework document). > If a capture is involved in more than one scene, more than one > should be provided, each one related to the > coordinate space of the involving scene. Whether clear or not, IMO it is *intended* that each capture is associated (belongs to) a single scene. ISTM an obvious way to represent this would be to have an instance of mediaCapturesType within captureSceneType, rather than within clueInfoType. Thanks, Paul From pkyzivat@alum.mit.edu Sat Oct 27 09:03:22 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB82521F8555 for ; Sat, 27 Oct 2012 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.52 X-Spam-Level: X-Spam-Status: No, score=0.52 tagged_above=-999 required=5 tests=[AWL=-0.843, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pw7MDon1ENNp for ; Sat, 27 Oct 2012 09:03:22 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id CA31821F8551 for ; Sat, 27 Oct 2012 09:03:21 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta14.westchester.pa.mail.comcast.net with comcast id GG0i1k00216LCl05EG3SfJ; Sat, 27 Oct 2012 16:03:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta06.westchester.pa.mail.comcast.net with comcast id GG2t1k00b3ZTu2S3SG2tkf; Sat, 27 Oct 2012 16:02:53 +0000 Message-ID: <508C05C7.3060305@alum.mit.edu> Date: Sat, 27 Oct 2012 12:03:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: CLUE References: <50880010.2070503@alvestrand.no> In-Reply-To: <50880010.2070503@alvestrand.no> X-Forwarded-Message-Id: <50880010.2070503@alvestrand.no> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: [clue] FYI: RTCWEB proposal using a=content X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2012 16:03:22 -0000 The message below has overlap with work we are doing. It is proposing using "a=content", and exposing it on the MediaStreamTracks api as a way of mapping individual mediaStreamTracks to particular m-lines. I haven't formed an opinion about this - whether it will help with clue compatibility or hurt. Thanks, Paul -------- Original Message -------- Subject: Mapping multiple media sources to few or many M-lines Resent-Date: Wed, 24 Oct 2012 14:50:28 +0000 Resent-From: public-webrtc@w3.org Date: Wed, 24 Oct 2012 16:49:52 +0200 From: Harald Alvestrand To: public-webrtc@w3.org Cullen, Justin and I have been working on a proposal for this issue, which is one of the things we have to settle in order to know what we're designing our signalling for. One proposal is outlined below - it depends on defining a new attribute of a MediaStreamTrack called "content", and using that to direct tracks onto different M-lines when negotiating SDP. Details below. ==Proposal for controlling the allocation of multiple media sources to RTP sessions== ===Problem description=== There are a number of applications that can be envisioned using WebRTC. The applications where one audio and one video stream is connected between two participants are trivial; there is no real controversy there. But other styles are more difficult. Two important cases are: A single PeerConnection is used to connect an end-user to a central non-mixing MCU (a "RTCP-terminating MCU" in RFC 5117 terminology) and the connection between the MCU and the user has a large number of audio and/or video tracks (for example, a “thumbnail strip” + one or more large video images). A single PeerConnection is used to connect an end-user to a non-RTCWEB SIP system, through a signalling gateway but not through a media gateway, using multiple video sessions that are distinguished by use of the “a=content” attribute (for example, a main video feed plus a presentation video feed). In the first case, we definitely want all the video sources in the same RTP session, which helps us be able to add or remove video sources with minimal overhead (no new ICE ports and NAT pinholes). In the second case, we want to have specific video sources on different RTP sessions, and we want to have exact control over which video streams get assigned to what RTP sessions. Solution Description The basic idea is to expose a new "content" property on MediaStreamTracks, as defined in RFC 4796, which would indicate the "usage" of the media in that particular track. When createOffer is called to create a session description, it will include a m= line for each [media, content] tuple that exists within the list of attached MediaStreamTracks. Since normally m= lines are omitted for tuples that have no associated MediaStreamTracks, the application can also include an empty m= line for a given tuple by specifying a constraint to createOffer, similar to how the existing OfferToReceiveAudio and OfferToReceiveVideo can be used to add empty m= lines for audio and video. The suggested form for this constraint is to use the existing OfferToReceiveAudio and OfferToReceiveVideo keys, but use the content property as the value, e.g. "OfferToReceiveVideo:slides". Individual MediaStreamTracks are represented via a=ssrc attributes on the appropriate m= lines; the MSID attribute on the a=ssrc line identifies the MediaStreamTrack. There can be an arbitrary number of MediaStreamTracks associated with a given m= line, including zero; demuxing of these MediaStreamTracks is performed done according to the SSRC specified with the a=ssrc attribute. By default, the content property for MediaStreamTracks is left empty. This means that MediaStreamTracks are by default associated with m= lines that have no a=content attribute. createAnswer works the same way as createOffer, using its attached MediaStreamTracks, and the constraints supplied; note that it will always include m= lines as needed to match the offer, even if no MediaStreamTracks are attached. Through this mechanism, applications that want to make use of multiple media streams can generate SDP that best matches what existing videoconferencing equipment expects, but this usage is not required; sophisticated applications can use the content property to assign their own grouping of MediaStreamTracks to m= lines, including the creation of individual m= lines for each MediaStreamTrack, or the combination of all video MediaStreamTracks into a single m= line. Of course, these applications could also do so by generating the SDP themselves and passing this SDP into setLocalDescription. ===Examples=== MediaStream ms1 contains an audio track (denoted a0 in msid lines) and video track (v0), as obtained from getUserMedia(). The label of ms1 is . MediaStream ms2 contains a single video track (also denoted v0, since it’s the first video track in its mediastream), taken from the desktop. The label of ms2 is . PeerConnection pc exists, with no streams attached. pc.addStream(ms1, null); pc.createOffer(null); produces: m=audio a=ssrc:1234 msid: a0 m=video // nothing fancy a=ssrc:5678 msid: v0 pc.addStream(ms1, null); pc.addStream(ms2, null); pc.createOffer(null); produces: m=audio a=ssrc:1234 msid: a0 m=video // both tracks associated with one m= line a=ssrc:5678 msid: v0 a=ssrc:6789 msid: v0 pc.addStream(ms1, null); pc.createOffer({mandatory:{"OfferToReceiveVideo:slides"}}); produces: m=audio a=ssrc:1234 msid: a0 m=video a=ssrc:5678 msid: v0 m=video // note this empty m= line a=content:slides pc.addStream(ms1, null); v2.content = "slides"; pc.addStream(ms2, null); pc.createOffer(null); produces: m=audio a=ssrc:1234 msid: a0 m=video a=ssrc:5678 msid: v0 m=video // this m= line has an a=content attribute and a track a=content:slides a=ssrc:6789 msid: v0 From mary.ietf.barnes@gmail.com Mon Oct 29 08:02:15 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1857F21F8514 for ; Mon, 29 Oct 2012 08:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5rHFJCgGSze for ; Mon, 29 Oct 2012 08:02:14 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD10A21F8533 for ; Mon, 29 Oct 2012 08:02:13 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4289592lam.31 for ; Mon, 29 Oct 2012 08:02:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=KT6Zknz4OIh0R6gg/rUd3Lan9wl8qzThfP2exBVUrJY=; b=VrIXAmoKtbufm3vrjKwfGie3AqV9JNfTEsa+b2KEAPXm9MqtJCgWz9favY4F37rzQH OyOZjPafoiTd/XHVSIR1X7kcrCX7etECDc32GiuEEMDmk64uvdrMsCWL1NAZrVQs64NT 7+n4wyiQUE20sBU63V0svbBZzUf2szuou1vv8JAisJpE6389cxuQSWUTv1jZ3WbbaDGK JTPx56gCZRUO+lBwT20JfXKzfB6c4s1BQQC4U399HL5+AbC8p5ctGCXRkD4m/X1t8JAD l2XIeW1JJrTNvK7Uk2S2nCjcReSzpjeWOWWo9o7Ck7fN6Jfkrp9Q6U68TftoDAeZnAqa eaaw== MIME-Version: 1.0 Received: by 10.152.104.148 with SMTP id ge20mr26998770lab.51.1351522932437; Mon, 29 Oct 2012 08:02:12 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 29 Oct 2012 08:02:12 -0700 (PDT) In-Reply-To: <2080252443.964901351521974885.JavaMail.nobody@rva2rmd001.webex.com> References: <2080252443.964901351521974885.JavaMail.nobody@rva2rmd001.webex.com> Date: Mon, 29 Oct 2012 10:02:12 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d040711694b34d104cd33f438 Subject: [clue] Fwd: Meeting reminder: CLUE Design Team X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Oct 2012 15:02:15 -0000 --f46d040711694b34d104cd33f438 Content-Type: text/plain; charset=ISO-8859-1 Hi all, We were planning to have a call today - we'd like to discuss agenda, meeting objectives and work plans. I know Sandy is impacting a few folks. So, if we don't get a reasonable quorum, we'll start the discussion on the list. Thanks, Mary ---------- Forwarded message ---------- From: Date: Mon, Oct 29, 2012 at 9:46 AM Subject: Meeting reminder: CLUE Design Team To: clue-chairs@tools.ietf.org You are scheduled to host this online meeting. Topic: CLUE Design Team Date: Monday, October 29, 2012 Time: 10:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 642 221 028 Meeting Password: 1234 ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?ED=158121817&UID=491198362&PW=NNWRkOGVjYTBh&RT=MiM3 2. If you are not logged in, log in to your account. ------------------------------------------------------- Audio conference information ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:642 221 028 To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ietf.webex.com/ietf/systemdiagnosis.php http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. --f46d040711694b34d104cd33f438 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

We were planning to have a call today - we'd= like to discuss agenda, meeting objectives and work plans. =A0I know Sandy= is impacting a few folks. =A0So, if we don't get a reasonable quorum, = we'll start the discussion on the list.

Thanks,
Mary

---------- Forwarded message ----------
From: <mes= senger@webex.com>
Date: Mon, Oct 29, 2012 at 9:46 AM
Subject: Meeting reminder: CLUE Desig= n Team
To: clue-chairs@too= ls.ietf.org



You are scheduled to host this online meeting.

Topic: CLUE Desig= n Team
Date: Monday, October 29, 2012
Time: 10:00 am, Central Day= light Time (Chicago, GMT-05:00)
Meeting Number: 642 221 028
Meeti= ng Password: 1234


-------------------------------------------------------
To s= tart the online meeting
----------------------------------------------= ---------
1. Go to https://ietf.webex.com/ietf/j.php?ED=3D158121817&UID=3D4911= 98362&PW=3DNNWRkOGVjYTBh&RT=3DMiM3
2. If you are not logged in, log in to your account.

-----------= --------------------------------------------
Audio conference informat= ion
-------------------------------------------------------
Call-= in toll number (US/Canada): 1-650-479-3208

Access code:642 221 028
To check whether you have the appropriat= e players installed for UCF (Universal Communications Format) rich media fi= les, go to https://ietf.webex.com/ietf/systemdiagnosis.php

http://www.webex.c= om



IMPORTANT NOTICE: This WebEx service includes a = feature that allows audio and any documents and other materials exchanged o= r viewed during the session to be recorded. You should inform all meeting a= ttendees prior to recording if you intend to record the meeting. Please not= e that any such recordings may be subject to discovery in the event of liti= gation.

--f46d040711694b34d104cd33f438-- From pkyzivat@alum.mit.edu Mon Oct 29 10:06: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 EE1BC21F8711 for ; Mon, 29 Oct 2012 10:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1yMYELH2YVm for ; Mon, 29 Oct 2012 10:06:49 -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 D33FB21F8705 for ; Mon, 29 Oct 2012 10:06:46 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta01.westchester.pa.mail.comcast.net with comcast id H3Yk1k0020EZKEL5156mxF; Mon, 29 Oct 2012 17:06:46 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id H5731k00Y3ZTu2S3M573Yb; Mon, 29 Oct 2012 17:07:03 +0000 Message-ID: <508EB79F.1070803@alum.mit.edu> Date: Mon, 29 Oct 2012 13:06:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <507F2C8E.5050305@alum.mit.edu> <50854B2E.8030105@alum.mit.edu> In-Reply-To: <50854B2E.8030105@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Thoughts on relation between clue messages and SDP 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, 29 Oct 2012 17:06:50 -0000 We just had a design team meeting with a very few people. One of the things we discussed was which of the information that we need to transmit should be in clue messages vs. what should be in SDP. One goal of our meeting in Atlanta will be to seek agreement on this. It is a slightly different subject than I was trying to get at in this thread, but the two questions are tightly coupled. The proposal I floated here embodies my assumption about that: ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of captures that *could* be sent, and to "order" from that menu (via Configure messages) the selection of captures that *should* be sent. All the information necessary to do that (descriptions of attributes of the available captures) is CLUE information, and belongs in the CLUE signaling protocol. The SDP only needs to be sufficient to support the Configurations in effect. The way SDP is used with offer/answer is that each side specifies what it is prepared to *receive*, in contrast with the Advertisement which describes what can be sent. The alternative that I think some have in mind is that SDP might carry much of the Advertisement. Doing so requires that SDP be able to convey many aspects of what can be *sent* in addition to its more common usage to carry what can be received. There is SDP notation to do this for some things, but not all things, so trying this would potentially require a number of SDP extensions. Also, the advertisement potentially describes many more alternatives than will be configured, so attempting to convey the advertisement in SDP is likely to explode the size of the SDP. PLEASE, think about this, comment on the list prior to the meeting, and be prepared to discuss it at the meeting. It is really hard to make more progress without an agreement on this point. Thanks, Paul On 10/22/12 9:33 AM, Paul Kyzivat wrote: > I've been surprised that there have been no replies to this message. > Is that because it is so obvious and uncontroversial that no comment is > needed? Or did I write it so poorly that nobody understands what I'm > saying? > > Thanks, > Paul > > On 10/17/12 6:09 PM, Paul Kyzivat wrote: >> After discussions at the interim around the call flows and signaling >> issues, and subsequent discussion, I have some revised ideas about how >> the clue messages and SDP O/A can be coordinated. >> >> The Configure message selects capture encodings that the receiver wants >> the sender to send to it via RTP sessions RTP streams within those >> sessions that are specified in SDP. >> >> In some cases it may be that a new Configure can reuse the RTP resources >> already present in a previously established O/A. But it is also possible >> that a new Configure will ask for capture encodings that require RTP >> resources that aren't present in the previously established O/A. In that >> case a new O/A will be needed, before or after that Configure is sent. >> >> One of the questions that came up at the interim is whether the O/A to >> prep for a Configure should come before, or after, the Configure. An >> argument for doing the O/A *before* the Configure is that then it is >> known that the resources to support the Configure are available, and >> allows the Configure to reference elements present in the SDP. An >> argument for doing the O/A *after* the Configure is that then the >> answerer will understand *why* it is being asked to configure the SDP as >> specified, and so help it decide whether it wants to accept that. >> >> I finally realized that the the Advertisement defines what is possible, >> and implicitly indicates what SDP will be required to support that. >> Hence, I think we can expect that an offerer can construct a new offer >> in contemplation of a Configure message it plans to send plus the last >> one it received, and in the context of the corresponding Advertisements. >> The Answerer can then evaluate that offer in the context of the same >> Advertisements. As long as the offer is consistent with current >> advertisements it should aim to construct an answer that accepts it. >> >> With that approach, a Configure can be constructed relative to the most >> recent O/A. >> >> During initial session setup, before the first Advertisements are >> exchanged, the offerer will have to construct the first offer without >> the context of an advertisement from the other side. It can however >> still construct the offer to be consistent with the Advertisement it >> plans to send. The Answerer can construct the answer in the context of >> the Advertisement it plans to send, constrained by what is in the offer. >> (The offer may not be sufficient for everything the answerer wishes to >> include.) Each side can then begin sending media that fits within that >> initial O/A, using a default Configure constructed locally. Concurrently >> Advertisements can be exchanged. After that Configure messages may be >> exchanged. (Or not if what is being received is satisfactory.) >> >> It may turn out that in many cases the initial O/A is sufficient for the >> initial Configure that each side wants to send. If so then no new O/A is >> needed. Or it may turn out that it isn't. If not, then either side may >> initiate an O/A with an offer compatible with the desired Configure, I >> described above. >> >> This also helps clarify that the Configure is both a selection from the >> advertisement and a mapping of that selection onto the SDP. >> >> This also clarifies that the Advertisement must contain sufficient >> information to map a Configure onto the SDP needed to convey that. For >> instance, if the sender has encoders with independent IP addr/port, then >> the offer will require multiple m-lines for those, but if both the >> sender and receiver have all encoders on a single addr/port then one >> m-line may be sufficient. Since the offerer determines the set of >> m-lines in the O/A, it needs to figure this out on behalf of the >> answerer. >> >> What do people think of this approach? >> >> Thanks, >> Paul (as individual) >> _______________________________________________ >> 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 ron.even.tlv@gmail.com Mon Oct 29 10:36: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 D8EE221F86FB for ; Mon, 29 Oct 2012 10:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AZxhcUICzhIt for ; Mon, 29 Oct 2012 10:36:38 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6E67C21F86F3 for ; Mon, 29 Oct 2012 10:36:38 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so2570002eek.31 for ; Mon, 29 Oct 2012 10:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=UzLyqd26MqBRdZ1kvxlZVW6m27PQr8SVHruxgTp7NeE=; b=AAPmA7vLTfSy7dS1SDQwwPtZSAupfSz4JJGPLgI7yrQPFG8gvokQL4NfFN1L/kvHeY I+8J9oed/BUd7z2/Isl2zsWpMh5HYahkLtMP1fW1tY7e14osk2EIOwZzbUeB1ERM+8YY t8seCZE6vDDpvDLFVVXJeQO3rzeo5Mn/yBebhBwqYrAg2EOPlLwX4LHhcUKO3Ds25Efu me58GczmFMH9IB8mbjdgkSr/B8bKRIb8OXymCeK5I3GakeHelO41VyoI+XnieraX+7pC Dp5J7rKvdyAcBM367Vsr31BXWfzsJ2Jf48DM7wtsm4wDMn9v2VGZNewQocY/J66UoGjK xdBQ== Received: by 10.14.194.72 with SMTP id l48mr63917851een.9.1351532197617; Mon, 29 Oct 2012 10:36:37 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id g47sm24011364eeo.6.2012.10.29.10.36.34 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 10:36:36 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <507F2C8E.5050305@alum.mit.edu> <50854B2E.8030105@alum.mit.edu> <508EB79F.1070803@alum.mit.edu> In-Reply-To: <508EB79F.1070803@alum.mit.edu> Date: Mon, 29 Oct 2012 19:34:23 +0200 Message-ID: <00d301cdb5fb$a55f2ff0$f01d8fd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQFV+XycLw/ZO7agTMK8lm4KBVa4zwJcfUBSAO6070GYpai7QA== Content-Language: en-us Subject: Re: [clue] Thoughts on relation between clue messages and SDP 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, 29 Oct 2012 17:36:40 -0000 Paul, Your assumption about SDP attributes being receive value is not precise. I can agree that for part of the SSP attributes that have similar CLUE attributes mostly the encoding ones that this is true. For the rest this is not correct. Example "content" or ""ssrc" SDP attributes which are sender ones. As for what is in CLUE , my major issue is with the encoding groups which I do not see the value of. The data model has a group assigned to a media capture and not individual encodes. I also do not see how you will have different individual encodes for media captures based on the current definition of a capture scene. There was some mention of simulcast which cannot be described with the current encoding structure while we show in RTP mapping how it is done in SDP Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29 October, 2012 7:07 PM To: clue@ietf.org Subject: Re: [clue] Thoughts on relation between clue messages and SDP We just had a design team meeting with a very few people. One of the things we discussed was which of the information that we need to transmit should be in clue messages vs. what should be in SDP. One goal of our meeting in Atlanta will be to seek agreement on this. It is a slightly different subject than I was trying to get at in this thread, but the two questions are tightly coupled. The proposal I floated here embodies my assumption about that: ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of captures that *could* be sent, and to "order" from that menu (via Configure messages) the selection of captures that *should* be sent. All the information necessary to do that (descriptions of attributes of the available captures) is CLUE information, and belongs in the CLUE signaling protocol. The SDP only needs to be sufficient to support the Configurations in effect. The way SDP is used with offer/answer is that each side specifies what it is prepared to *receive*, in contrast with the Advertisement which describes what can be sent. The alternative that I think some have in mind is that SDP might carry much of the Advertisement. Doing so requires that SDP be able to convey many aspects of what can be *sent* in addition to its more common usage to carry what can be received. There is SDP notation to do this for some things, but not all things, so trying this would potentially require a number of SDP extensions. Also, the advertisement potentially describes many more alternatives than will be configured, so attempting to convey the advertisement in SDP is likely to explode the size of the SDP. PLEASE, think about this, comment on the list prior to the meeting, and be prepared to discuss it at the meeting. It is really hard to make more progress without an agreement on this point. Thanks, Paul On 10/22/12 9:33 AM, Paul Kyzivat wrote: > I've been surprised that there have been no replies to this message. > Is that because it is so obvious and uncontroversial that no comment > is needed? Or did I write it so poorly that nobody understands what > I'm saying? > > Thanks, > Paul > > On 10/17/12 6:09 PM, Paul Kyzivat wrote: >> After discussions at the interim around the call flows and signaling >> issues, and subsequent discussion, I have some revised ideas about >> how the clue messages and SDP O/A can be coordinated. >> >> The Configure message selects capture encodings that the receiver >> wants the sender to send to it via RTP sessions RTP streams within >> those sessions that are specified in SDP. >> >> In some cases it may be that a new Configure can reuse the RTP >> resources already present in a previously established O/A. But it is >> also possible that a new Configure will ask for capture encodings >> that require RTP resources that aren't present in the previously >> established O/A. In that case a new O/A will be needed, before or after that Configure is sent. >> >> One of the questions that came up at the interim is whether the O/A >> to prep for a Configure should come before, or after, the Configure. >> An argument for doing the O/A *before* the Configure is that then it >> is known that the resources to support the Configure are available, >> and allows the Configure to reference elements present in the SDP. An >> argument for doing the O/A *after* the Configure is that then the >> answerer will understand *why* it is being asked to configure the SDP >> as specified, and so help it decide whether it wants to accept that. >> >> I finally realized that the the Advertisement defines what is >> possible, and implicitly indicates what SDP will be required to support that. >> Hence, I think we can expect that an offerer can construct a new >> offer in contemplation of a Configure message it plans to send plus >> the last one it received, and in the context of the corresponding Advertisements. >> The Answerer can then evaluate that offer in the context of the same >> Advertisements. As long as the offer is consistent with current >> advertisements it should aim to construct an answer that accepts it. >> >> With that approach, a Configure can be constructed relative to the >> most recent O/A. >> >> During initial session setup, before the first Advertisements are >> exchanged, the offerer will have to construct the first offer without >> the context of an advertisement from the other side. It can however >> still construct the offer to be consistent with the Advertisement it >> plans to send. The Answerer can construct the answer in the context >> of the Advertisement it plans to send, constrained by what is in the offer. >> (The offer may not be sufficient for everything the answerer wishes >> to >> include.) Each side can then begin sending media that fits within >> that initial O/A, using a default Configure constructed locally. >> Concurrently Advertisements can be exchanged. After that Configure >> messages may be exchanged. (Or not if what is being received is >> satisfactory.) >> >> It may turn out that in many cases the initial O/A is sufficient for >> the initial Configure that each side wants to send. If so then no new >> O/A is needed. Or it may turn out that it isn't. If not, then either >> side may initiate an O/A with an offer compatible with the desired >> Configure, I described above. >> >> This also helps clarify that the Configure is both a selection from >> the advertisement and a mapping of that selection onto the SDP. >> >> This also clarifies that the Advertisement must contain sufficient >> information to map a Configure onto the SDP needed to convey that. >> For instance, if the sender has encoders with independent IP >> addr/port, then the offer will require multiple m-lines for those, >> but if both the sender and receiver have all encoders on a single >> addr/port then one m-line may be sufficient. Since the offerer >> determines the set of m-lines in the O/A, it needs to figure this out >> on behalf of the answerer. >> >> What do people think of this approach? >> >> Thanks, >> Paul (as individual) >> _______________________________________________ >> 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 spromano@unina.it Mon Oct 29 10:40: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 0852121F86F3 for ; Mon, 29 Oct 2012 10:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBlkZrfw7VwK for ; Mon, 29 Oct 2012 10:40:24 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 0E6E421F8668 for ; Mon, 29 Oct 2012 10:40:23 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q9THeI51013547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Oct 2012 18:40:19 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_72BC3F4A-55D7-4BEF-AC20-CC4BB928B120" From: Simon Pietro Romano In-Reply-To: <508EB79F.1070803@alum.mit.edu> Date: Mon, 29 Oct 2012 18:40:28 +0100 Message-Id: <7B542C07-0D3D-43BA-A7B2-E51C26305D75@unina.it> References: <507F2C8E.5050305@alum.mit.edu> <50854B2E.8030105@alum.mit.edu> <508EB79F.1070803@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: clue@ietf.org Subject: Re: [clue] Thoughts on relation between clue messages and SDP 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, 29 Oct 2012 17:40:26 -0000 --Apple-Mail=_72BC3F4A-55D7-4BEF-AC20-CC4BB928B120 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Paul, > ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of = captures that *could* be sent, and to "order" from that menu (via = Configure messages) the selection of captures that *should* be sent. All = the information necessary to do that (descriptions of attributes of the = available captures) is CLUE information, and belongs in the CLUE = signaling protocol. >=20 > The SDP only needs to be sufficient to support the Configurations in = effect. The way SDP is used with offer/answer is that each side = specifies what it is prepared to *receive*, in contrast with the = Advertisement which describes what can be sent. A big +1 from my side to both the assumption and its corollary about SDP = utilization in CLUE. Simon >=20 > The alternative that I think some have in mind is that SDP might carry = much of the Advertisement. Doing so requires that SDP be able to convey = many aspects of what can be *sent* in addition to its more common usage = to carry what can be received. There is SDP notation to do this for some = things, but not all things, so trying this would potentially require a = number of SDP extensions. Also, the advertisement potentially describes = many more alternatives than will be configured, so attempting to convey = the advertisement in SDP is likely to explode the size of the SDP. >=20 > PLEASE, think about this, comment on the list prior to the meeting, = and be prepared to discuss it at the meeting. It is really hard to make = more progress without an agreement on this point. >=20 > Thanks, > Paul >=20 > On 10/22/12 9:33 AM, Paul Kyzivat wrote: >> I've been surprised that there have been no replies to this message. >> Is that because it is so obvious and uncontroversial that no comment = is >> needed? Or did I write it so poorly that nobody understands what I'm >> saying? >>=20 >> Thanks, >> Paul >>=20 >> On 10/17/12 6:09 PM, Paul Kyzivat wrote: >>> After discussions at the interim around the call flows and signaling >>> issues, and subsequent discussion, I have some revised ideas about = how >>> the clue messages and SDP O/A can be coordinated. >>>=20 >>> The Configure message selects capture encodings that the receiver = wants >>> the sender to send to it via RTP sessions RTP streams within those >>> sessions that are specified in SDP. >>>=20 >>> In some cases it may be that a new Configure can reuse the RTP = resources >>> already present in a previously established O/A. But it is also = possible >>> that a new Configure will ask for capture encodings that require RTP >>> resources that aren't present in the previously established O/A. In = that >>> case a new O/A will be needed, before or after that Configure is = sent. >>>=20 >>> One of the questions that came up at the interim is whether the O/A = to >>> prep for a Configure should come before, or after, the Configure. An >>> argument for doing the O/A *before* the Configure is that then it is >>> known that the resources to support the Configure are available, and >>> allows the Configure to reference elements present in the SDP. An >>> argument for doing the O/A *after* the Configure is that then the >>> answerer will understand *why* it is being asked to configure the = SDP as >>> specified, and so help it decide whether it wants to accept that. >>>=20 >>> I finally realized that the the Advertisement defines what is = possible, >>> and implicitly indicates what SDP will be required to support that. >>> Hence, I think we can expect that an offerer can construct a new = offer >>> in contemplation of a Configure message it plans to send plus the = last >>> one it received, and in the context of the corresponding = Advertisements. >>> The Answerer can then evaluate that offer in the context of the same >>> Advertisements. As long as the offer is consistent with current >>> advertisements it should aim to construct an answer that accepts it. >>>=20 >>> With that approach, a Configure can be constructed relative to the = most >>> recent O/A. >>>=20 >>> During initial session setup, before the first Advertisements are >>> exchanged, the offerer will have to construct the first offer = without >>> the context of an advertisement from the other side. It can however >>> still construct the offer to be consistent with the Advertisement it >>> plans to send. The Answerer can construct the answer in the context = of >>> the Advertisement it plans to send, constrained by what is in the = offer. >>> (The offer may not be sufficient for everything the answerer wishes = to >>> include.) Each side can then begin sending media that fits within = that >>> initial O/A, using a default Configure constructed locally. = Concurrently >>> Advertisements can be exchanged. After that Configure messages may = be >>> exchanged. (Or not if what is being received is satisfactory.) >>>=20 >>> It may turn out that in many cases the initial O/A is sufficient for = the >>> initial Configure that each side wants to send. If so then no new = O/A is >>> needed. Or it may turn out that it isn't. If not, then either side = may >>> initiate an O/A with an offer compatible with the desired Configure, = I >>> described above. >>>=20 >>> This also helps clarify that the Configure is both a selection from = the >>> advertisement and a mapping of that selection onto the SDP. >>>=20 >>> This also clarifies that the Advertisement must contain sufficient >>> information to map a Configure onto the SDP needed to convey that. = For >>> instance, if the sender has encoders with independent IP addr/port, = then >>> the offer will require multiple m-lines for those, but if both the >>> sender and receiver have all encoders on a single addr/port then one >>> m-line may be sufficient. Since the offerer determines the set of >>> m-lines in the O/A, it needs to figure this out on behalf of the >>> answerer. >>>=20 >>> What do people think of this approach? >>>=20 >>> Thanks, >>> Paul (as individual) >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_72BC3F4A-55D7-4BEF-AC20-CC4BB928B120 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Paul,


ASSUMPTION: A primary CLUE purpose is to advertise a = "menu" of captures that *could* be sent, and to "order" from that menu = (via Configure messages) the selection of captures that *should* be = sent. All the information necessary to do that (descriptions of = attributes of the available captures) is CLUE information, and belongs = in the CLUE signaling protocol.

The SDP only needs to be = sufficient to support the Configurations in effect. The way SDP is used = with offer/answer is that each side specifies what it is prepared to = *receive*, in contrast with the Advertisement which describes what can = be sent.

A big +1 from my side = to both the assumption and its corollary about SDP utilization in = CLUE.

Simon


The alternative that I think some have in mind is = that SDP might carry much of the Advertisement. Doing so requires that = SDP be able to convey many aspects of what can be *sent* in addition to = its more common usage to carry what can be received. There is SDP = notation to do this for some things, but not all things, so trying this = would potentially require a number of SDP extensions. Also, the = advertisement potentially describes many more alternatives than will be = configured, so attempting to convey the advertisement in SDP is likely = to explode the size of the SDP.

PLEASE, think about this, comment = on the list prior to the meeting, and be prepared to discuss it at the = meeting. It is really hard to make more progress without an agreement on = this point.

Thanks,
= Paul

On 10/22/12 9:33 AM, Paul Kyzivat = wrote:
I've been surprised that there have = been no replies to this message.
Is that because it is so obvious and uncontroversial that = no comment is
needed? Or did I = write it so poorly that nobody understands what = I'm
saying?

=     Thanks,
=     Paul

On 10/17/12 = 6:09 PM, Paul Kyzivat wrote:
After discussions at the interim = around the call flows and = signaling
issues, and subsequent = discussion, I have some revised ideas about = how
the clue messages and SDP O/A can be = coordinated.

The Configure message selects = capture encodings that the receiver = wants
the sender to send to it via RTP sessions RTP streams = within those
sessions that are specified in = SDP.

In some cases it may be that a = new Configure can reuse the RTP = resources
already present in a previously = established O/A. But it is also = possible
that a new Configure will ask = for capture encodings that require = RTP
resources that aren't present in the previously = established O/A. In that
case a new O/A will be needed, = before or after that Configure is = sent.

One of the questions that came = up at the interim is whether the O/A = to
prep for a Configure should come before, or after, the = Configure. An
argument for doing the O/A = *before* the Configure is that then it = is
known that the resources to support the Configure are = available, and
allows the Configure to = reference elements present in the SDP. = An
argument for doing the O/A *after* the Configure is that = then the
answerer will understand *why* = it is being asked to configure the SDP = as
specified, and so help it decide whether it wants to = accept that.

I finally realized that the the = Advertisement defines what is = possible,
and implicitly indicates what = SDP will be required to support = that.
Hence, I think we can expect that an offerer can construct = a new offer
in contemplation of a Configure = message it plans to send plus the = last
one it received, and in the context of the corresponding = Advertisements.
The Answerer can then evaluate = that offer in the context of the = same
Advertisements. As long as the offer is consistent with = current
advertisements it should aim to construct an answer that = accepts it.

With that approach, a Configure = can be constructed relative to the = most
recent O/A.

During initial session setup, = before the first Advertisements = are
exchanged, the offerer will have to construct the first = offer without
the context of an advertisement = from the other side. It can = however
still construct the offer to be consistent with the = Advertisement it
plans to send. The Answerer can = construct the answer in the context = of
the Advertisement it plans to send, constrained by what is = in the offer.
(The offer may not be sufficient = for everything the answerer wishes = to
include.) Each side can then begin sending media that fits = within that
initial O/A, using a default = Configure constructed locally. = Concurrently
Advertisements can be exchanged. = After that Configure messages may = be
exchanged. (Or not if what is being received is = satisfactory.)

It may turn out that in many = cases the initial O/A is sufficient for = the
initial Configure that each side wants to send. If so then = no new O/A is
needed. Or it may turn out that = it isn't. If not, then either side = may
initiate an O/A with an offer compatible with the desired = Configure, I
described = above.

This also helps clarify that the = Configure is both a selection from = the
advertisement and a mapping of that selection onto the = SDP.

This also clarifies that the = Advertisement must contain = sufficient
information to map a Configure = onto the SDP needed to convey that. = For
instance, if the sender has encoders with independent IP = addr/port, then
the offer will require multiple = m-lines for those, but if both = the
sender and receiver have all encoders on a single = addr/port then one
m-line may be sufficient. Since = the offerer determines the set = of
m-lines in the O/A, it needs to figure this out on behalf = of the
answerer.

What do people think of this = approach?

=     Thanks,
    Paul = (as individual)
_______________________________________________
clue = mailing list
clue@ietf.org
https://www.ietf.org/m= ailman/listinfo/clue


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


_______________________________________= ________
clue mailing list
clue@ietf.org
https://www.ietf.org/ma= ilman/listinfo/clue


      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_72BC3F4A-55D7-4BEF-AC20-CC4BB928B120-- From mary.ietf.barnes@gmail.com Mon Oct 29 10:52: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 EDE5321F8732 for ; Mon, 29 Oct 2012 10:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.448 X-Spam-Level: X-Spam-Status: No, score=-103.448 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEIQLRfbl2qq for ; Mon, 29 Oct 2012 10:52:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id D3A6D21F873A for ; Mon, 29 Oct 2012 10:52:11 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so3629388lbo.31 for ; Mon, 29 Oct 2012 10:52:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=P1Y9c/wM1Wi1ImJ3Gwd0P7Hr5FIwzsqXlVsMPUkHWbI=; b=rfPLx+waQmGJ9OohexZFwFFvVo0lcRsCUWLj22xOCxvjxcWeQU0oHhqqCys4dVYEFl rFgDyorNProYmuJABuXfJCZl+ex5gkOrM8uHaMfl44JfLLHdj0zgsOy0cuGI8R15HU5m lJWdo3Y43PQzt02wY0N9u4ySdrCAJDHvDg9CyU3VB6JoPSZHAf3sF3ibczOsL+6xWe6+ lZH0BShPWeRwMRHj6AspIZlOGOrO36Cw1oeYBmzifBsh8b+ozhmO+h848GHJm6YD6eL6 AvR2ScyEPrmJnUDkc4q2F97p78Gv30BeBswWdTra3YeuALV83oWozICLq73qCHt0v478 8ixQ== MIME-Version: 1.0 Received: by 10.112.99.37 with SMTP id en5mr12249789lbb.1.1351533130629; Mon, 29 Oct 2012 10:52:10 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 29 Oct 2012 10:52:10 -0700 (PDT) Date: Mon, 29 Oct 2012 12:52:10 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0401f9ff27412604cd36541f Subject: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 17:52:13 -0000 --f46d0401f9ff27412604cd36541f Content-Type: text/plain; charset=ISO-8859-1 On the call earlier today, we also discussed the data model. The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. The application data would be used to populate CLUE messages, as well as SDP and would reflect updates based on both the CLUE and SDP signaling. If we can get agreement on that before the meeting, I believe our discussions can be much more productive. If folks could please reply "Yes" or "No" reflecting agreement with the above, that would be helpful. If you reply "No", please explain why. Regards, Mary as CLUE WG co-chair --f46d0401f9ff27412604cd36541f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On the call earlier today, we also discussed the data model. =A0The general= agreement on the call is that the data model as reflected in draft-presta-= clue-data-model-schema describes the data needed by the CLUE application - = i.e., it's the CLUE instance concept. =A0It does not directly reflect t= he contents of a CLUE message. =A0The application data would be used to pop= ulate CLUE messages, as well as SDP and would reflect updates based on both= the CLUE and SDP signaling. =A0

If we can get agreement on that before the meeting, I believ= e our discussions can be much more productive. If folks could please reply = "Yes" or "No" reflecting agreement with the above, that= would be helpful. =A0If you reply "No", please explain why. =A0<= /div>

Regards,
Mary
as CLUE WG co-chair --f46d0401f9ff27412604cd36541f-- From pkyzivat@alum.mit.edu Mon Oct 29 11:44:57 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9DD421F86E7 for ; Mon, 29 Oct 2012 11:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5sJEIdhSDgL for ; Mon, 29 Oct 2012 11:44:56 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D105921F866D for ; Mon, 29 Oct 2012 11:44:55 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta03.westchester.pa.mail.comcast.net with comcast id GzjQ1k0040vyq2s536l02l; Mon, 29 Oct 2012 18:45:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id H6lN1k0103ZTu2S3R6lNHa; Mon, 29 Oct 2012 18:45:23 +0000 Message-ID: <508ECEA5.4030809@alum.mit.edu> Date: Mon, 29 Oct 2012 14:44:53 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Roni Even References: <507F2C8E.5050305@alum.mit.edu> <50854B2E.8030105@alum.mit.edu> <508EB79F.1070803@alum.mit.edu> <00d301cdb5fb$a55f2ff0$f01d8fd0$@gmail.com> In-Reply-To: <00d301cdb5fb$a55f2ff0$f01d8fd0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Thoughts on relation between clue messages and SDP 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, 29 Oct 2012 18:44:57 -0000 On 10/29/12 1:34 PM, Roni Even wrote: > Paul, > Your assumption about SDP attributes being receive value is not precise. I > can agree that for part of the SSP attributes that have similar CLUE > attributes mostly the encoding ones that this is true. For the rest this is > not correct. > Example "content" or ""ssrc" SDP attributes which are sender ones. Yes, I realize it's not entirely true. But it is true enough to be an issue. > As for what is in CLUE , my major issue is with the encoding groups which I > do not see the value of. The data model has a group assigned to a media > capture and not individual encodes. I also do not see how you will have > different individual encodes for media captures based on the current > definition of a capture scene. I'm sure others know much better than I what is realistic with implementations, now and planned. But I understand this conceptually. Certainly if an MCU is involved, and has transcoding and scaling capabilities, then it might be able to offer a menu of alternative encodings for a particular capture. And I don't see how you would offer this menu of encodings in SDP. If it was done via a separate line for each possible capture-encoding, then it will require (number-of-captures)*(number of encodings) lines, which could get ugly. I'm willing to be convinced otherwise, but it still seems to me that the set of encodings makes more sense as part of the clue "menu" than as part of the sip session. > There was some mention of simulcast which cannot be described with the > current encoding structure while we show in RTP mapping how it is done in > SDP The way I have been thinking about it, simulcast would only be represented in the SDP if the selected Configuration actually selects multiple encodings of the same capture. Thanks, Paul > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 29 October, 2012 7:07 PM > To: clue@ietf.org > Subject: Re: [clue] Thoughts on relation between clue messages and SDP > > We just had a design team meeting with a very few people. > One of the things we discussed was which of the information that we need to > transmit should be in clue messages vs. what should be in SDP. > > One goal of our meeting in Atlanta will be to seek agreement on this. > > It is a slightly different subject than I was trying to get at in this > thread, but the two questions are tightly coupled. > > The proposal I floated here embodies my assumption about that: > > ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of captures that > *could* be sent, and to "order" from that menu (via Configure > messages) the selection of captures that *should* be sent. All the > information necessary to do that (descriptions of attributes of the > available captures) is CLUE information, and belongs in the CLUE signaling > protocol. > > The SDP only needs to be sufficient to support the Configurations in effect. > The way SDP is used with offer/answer is that each side specifies what it is > prepared to *receive*, in contrast with the Advertisement which describes > what can be sent. > > The alternative that I think some have in mind is that SDP might carry much > of the Advertisement. Doing so requires that SDP be able to convey many > aspects of what can be *sent* in addition to its more common usage to carry > what can be received. There is SDP notation to do this for some things, but > not all things, so trying this would potentially require a number of SDP > extensions. Also, the advertisement potentially describes many more > alternatives than will be configured, so attempting to convey the > advertisement in SDP is likely to explode the size of the SDP. > > PLEASE, think about this, comment on the list prior to the meeting, and be > prepared to discuss it at the meeting. It is really hard to make more > progress without an agreement on this point. > > Thanks, > Paul > > On 10/22/12 9:33 AM, Paul Kyzivat wrote: >> I've been surprised that there have been no replies to this message. >> Is that because it is so obvious and uncontroversial that no comment >> is needed? Or did I write it so poorly that nobody understands what >> I'm saying? >> >> Thanks, >> Paul >> >> On 10/17/12 6:09 PM, Paul Kyzivat wrote: >>> After discussions at the interim around the call flows and signaling >>> issues, and subsequent discussion, I have some revised ideas about >>> how the clue messages and SDP O/A can be coordinated. >>> >>> The Configure message selects capture encodings that the receiver >>> wants the sender to send to it via RTP sessions RTP streams within >>> those sessions that are specified in SDP. >>> >>> In some cases it may be that a new Configure can reuse the RTP >>> resources already present in a previously established O/A. But it is >>> also possible that a new Configure will ask for capture encodings >>> that require RTP resources that aren't present in the previously >>> established O/A. In that case a new O/A will be needed, before or after > that Configure is sent. >>> >>> One of the questions that came up at the interim is whether the O/A >>> to prep for a Configure should come before, or after, the Configure. >>> An argument for doing the O/A *before* the Configure is that then it >>> is known that the resources to support the Configure are available, >>> and allows the Configure to reference elements present in the SDP. An >>> argument for doing the O/A *after* the Configure is that then the >>> answerer will understand *why* it is being asked to configure the SDP >>> as specified, and so help it decide whether it wants to accept that. >>> >>> I finally realized that the the Advertisement defines what is >>> possible, and implicitly indicates what SDP will be required to support > that. >>> Hence, I think we can expect that an offerer can construct a new >>> offer in contemplation of a Configure message it plans to send plus >>> the last one it received, and in the context of the corresponding > Advertisements. >>> The Answerer can then evaluate that offer in the context of the same >>> Advertisements. As long as the offer is consistent with current >>> advertisements it should aim to construct an answer that accepts it. >>> >>> With that approach, a Configure can be constructed relative to the >>> most recent O/A. >>> >>> During initial session setup, before the first Advertisements are >>> exchanged, the offerer will have to construct the first offer without >>> the context of an advertisement from the other side. It can however >>> still construct the offer to be consistent with the Advertisement it >>> plans to send. The Answerer can construct the answer in the context >>> of the Advertisement it plans to send, constrained by what is in the > offer. >>> (The offer may not be sufficient for everything the answerer wishes >>> to >>> include.) Each side can then begin sending media that fits within >>> that initial O/A, using a default Configure constructed locally. >>> Concurrently Advertisements can be exchanged. After that Configure >>> messages may be exchanged. (Or not if what is being received is >>> satisfactory.) >>> >>> It may turn out that in many cases the initial O/A is sufficient for >>> the initial Configure that each side wants to send. If so then no new >>> O/A is needed. Or it may turn out that it isn't. If not, then either >>> side may initiate an O/A with an offer compatible with the desired >>> Configure, I described above. >>> >>> This also helps clarify that the Configure is both a selection from >>> the advertisement and a mapping of that selection onto the SDP. >>> >>> This also clarifies that the Advertisement must contain sufficient >>> information to map a Configure onto the SDP needed to convey that. >>> For instance, if the sender has encoders with independent IP >>> addr/port, then the offer will require multiple m-lines for those, >>> but if both the sender and receiver have all encoders on a single >>> addr/port then one m-line may be sufficient. Since the offerer >>> determines the set of m-lines in the O/A, it needs to figure this out >>> on behalf of the answerer. >>> >>> What do people think of this approach? >>> >>> Thanks, >>> Paul (as individual) >>> _______________________________________________ >>> 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 ron.even.tlv@gmail.com Mon Oct 29 12:21:27 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9EF21F86C7 for ; Mon, 29 Oct 2012 12:21:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DNxuUu3aDeT3 for ; Mon, 29 Oct 2012 12:21:26 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2026821F872E for ; Mon, 29 Oct 2012 12:21:24 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so2628410eek.31 for ; Mon, 29 Oct 2012 12:21:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=x+e2eIIIzXVxjMP2xR+c7XMHa6zwYXNGW2Cfs664rdE=; b=nPvXLiqdbRfTSc5XOMzbF7RaDT5qe0Ic2vrDPZxm5dRH0CZQcDdmdyUMb75vPbxylg 4t1sr/IHsOz0apQ0pFc5cxwyBxK2WIFeJJw4g5/0BsJiJ4t8b60YseZiIy0STFyBqlJ2 vB6818YeUx2ND4rVP9Oibvhm9XE7CtJuk5M4qnIsj8K6rPBrluAAVaDBw4QzT1NfMjvX P2LbrlbNHnxQCliJ8/eSX5+wC27ZdoND9qJJsfp9m/S93LEeQmZpLzkLe3+FW2CtbJ00 oQWXtivii7YuPoIBVJ8jKXMx3n5LrzzAi/w9QLFwCns5ynxKaerulI2KnLqFJAZH7p9B vOUA== Received: by 10.14.214.2 with SMTP id b2mr64698550eep.32.1351538484345; Mon, 29 Oct 2012 12:21:24 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id z43sm24560879een.16.2012.10.29.12.21.21 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 12:21:23 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Mon, 29 Oct 2012 21:19:11 +0200 Message-ID: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EE_01CDB61B.0C36E9B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1H205IYhCmcjSpxYAUxN6zg5tspeB1GsQ Content-Language: en-us Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 19:21:27 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00EE_01CDB61B.0C36E9B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, My view is 'no". I still fail to see the need for the encoding groups and individual encodes. In the current definition of capture scene, I am not sure what is the meaning of different individual encodes and eventually the receiver can define what it can receive (Typically H.264 is symmetric in terms of profile but does not need to be in the level) and can ask for specific resolution with the SDP image attribute Roni Even From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 29 October, 2012 7:52 PM To: CLUE Subject: [clue] Data model - agreement on objective and basic approach On the call earlier today, we also discussed the data model. The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. The application data would be used to populate CLUE messages, as well as SDP and would reflect updates based on both the CLUE and SDP signaling. If we can get agreement on that before the meeting, I believe our discussions can be much more productive. If folks could please reply "Yes" or "No" reflecting agreement with the above, that would be helpful. If you reply "No", please explain why. Regards, Mary as CLUE WG co-chair ------=_NextPart_000_00EE_01CDB61B.0C36E9B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

My view is ‘no”. I still fail to see the need for the = encoding groups and individual encodes.

In the current definition of capture scene, I am not sure what is the = meaning of different individual encodes and eventually the receiver can = define what it can receive (Typically H.264 is symmetric in terms of = profile but does not need to be in the level) and can ask for specific = resolution with the SDP image attribute

 

Roni Even

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 29 October, 2012 7:52 PM
To: = CLUE
Subject: [clue] Data model - agreement on objective and = basic approach

 

On the call = earlier today, we also discussed the data model.  The general = agreement on the call is that the data model as reflected in = draft-presta-clue-data-model-schema describes the data needed by the = CLUE application - i.e., it's the CLUE instance concept.  It does = not directly reflect the contents of a CLUE message.  The = application data would be used to populate CLUE messages, as well as SDP = and would reflect updates based on both the CLUE and SDP signaling. =  

 

If we can get agreement on that before the meeting, I = believe our discussions can be much more productive. If folks could = please reply "Yes" or "No" reflecting agreement with = the above, that would be helpful.  If you reply "No", = please explain why.  

 

Regards,

Mary

as = CLUE WG co-chair

------=_NextPart_000_00EE_01CDB61B.0C36E9B0-- From pkyzivat@alum.mit.edu Mon Oct 29 12:25: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 949A321F8668 for ; Mon, 29 Oct 2012 12:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYmdxYIYf+1v for ; Mon, 29 Oct 2012 12:25:39 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE1021F8661 for ; Mon, 29 Oct 2012 12:25:38 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta05.westchester.pa.mail.comcast.net with comcast id GzKD1k0020EZKEL557Rjob; Mon, 29 Oct 2012 19:25:43 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id H7S01k00n3ZTu2S3M7S0ch; Mon, 29 Oct 2012 19:26:00 +0000 Message-ID: <508ED830.4030802@alum.mit.edu> Date: Mon, 29 Oct 2012 15:25:36 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Mary Barnes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: CLUE Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 19:25:39 -0000 On 10/29/12 1:52 PM, Mary Barnes wrote: > On the call earlier today, we also discussed the data model. The > general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the > CLUE application - i.e., it's the CLUE instance concept. It does not > directly reflect the contents of a CLUE message. The application data > would be used to populate CLUE messages, as well as SDP and would > reflect updates based on both the CLUE and SDP signaling. > > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would be > helpful. If you reply "No", please explain why. Well, while that is *possible*, it seems odd to me. The XML schema defines an *encoding*. What you are describing would make more sense to me if we were doing a more abstract model, such as via UML, that isn't directly tied to an encoding. What is in the data model right now doesn't exactly map onto clue messages. But the "clueInfo" element comes very close to mapping onto an Advertisement as described in the framework. And there isn't (yet) anything in the schema that maps in an obvious way to a Configure message. Nevertheless I'm ok with acknowledging that some of the stuff in the model may end up in the SDP until we get this sorted out and find a better way to represent it. Thanks, Paul (as individual) From pkyzivat@alum.mit.edu Mon Oct 29 12:45: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 B4ABF21F8645 for ; Mon, 29 Oct 2012 12:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZBlHE6qbuO2 for ; Mon, 29 Oct 2012 12:45:47 -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 1AB8421F85E0 for ; Mon, 29 Oct 2012 12:45:46 -0700 (PDT) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta02.westchester.pa.mail.comcast.net with comcast id H0691k0061ZXKqc517lrAn; Mon, 29 Oct 2012 19:45:51 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta21.westchester.pa.mail.comcast.net with comcast id H7n01k00a3ZTu2S3h7n0UF; Mon, 29 Oct 2012 19:47:00 +0000 Message-ID: <508EDCE7.6090204@alum.mit.edu> Date: Mon, 29 Oct 2012 15:45:43 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> In-Reply-To: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 19:45:47 -0000 On 10/29/12 3:19 PM, Roni Even wrote: > Hi, > > My view is ‘no”. I still fail to see the need for the encoding groups > and individual encodes. > > In the current definition of capture scene, I am not sure what is the > meaning of different individual encodes and eventually the receiver can > define what it can receive (Typically H.264 is symmetric in terms of > profile but does not need to be in the level) and can ask for specific > resolution with the SDP image attribute ISTM that you are answering a different question than the one Mary asked. You seem to be saying that you disagree with the framework as it is - that it can/should be simpler. That is a separate question. If such changes were made it might affect a lot. Thanks, Paul > Roni Even > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on objective and basic approach > > On the call earlier today, we also discussed the data model. The > general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the > CLUE application - i.e., it's the CLUE instance concept. It does not > directly reflect the contents of a CLUE message. The application data > would be used to populate CLUE messages, as well as SDP and would > reflect updates based on both the CLUE and SDP signaling. > > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would be > helpful. If you reply "No", please explain why. > > Regards, > > Mary > > as CLUE WG co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Mon Oct 29 14:19: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 DB87721F870C for ; Mon, 29 Oct 2012 14:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.498 X-Spam-Level: X-Spam-Status: No, score=-103.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHca9IusY5Ad for ; Mon, 29 Oct 2012 14:19:08 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 79ED521F85EE for ; Mon, 29 Oct 2012 14:19:07 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so4576801lam.31 for ; Mon, 29 Oct 2012 14:19:06 -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=yEWNRFwqkVl8RD653WPGv7prctwkZows/dcBmfZVmAo=; b=oOIbeFbiIkaI6I55yA8bBmQI+YFnkRicLoPOHp5/VNU4VsyYK6X4WP9WRZEneqqc+R eRax3huf6FbttQ11PbpDmH7O52V9qLPHvyPX8KJWvr82p+NvF484SkccYybKuxeFaSak Y/kOwfp5MECt9ZSquROjk+xAPRC95mh+ePQJ9LW/puSZNEoOjo8Kij7kFEZbzhsupId8 +8wKmzipQ5DLi/5/UY8mdoXT908yuSBBqmvEJtN3tgPjFPaBcm8P6C5DgyIjWD2MzqyM b9z6DhjIphR4OWgs28UdGt4duWjgOlBvKiajSVyFbKsHsq2RzcEbdB/E8pEFRhNgtTdD NeCQ== MIME-Version: 1.0 Received: by 10.152.148.8 with SMTP id to8mr28805011lab.2.1351545546432; Mon, 29 Oct 2012 14:19:06 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Mon, 29 Oct 2012 14:19:06 -0700 (PDT) In-Reply-To: <508ED830.4030802@alum.mit.edu> References: <508ED830.4030802@alum.mit.edu> Date: Mon, 29 Oct 2012 16:19:06 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e89a8f22bd0931615504cd3938a1 Cc: CLUE Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 21:19:09 -0000 --e89a8f22bd0931615504cd3938a1 Content-Type: text/plain; charset=ISO-8859-1 This was the discussion we had on one of the calls a while back, although, I can't find the specific one quickly reviewing the minutes, so it may not have been appropriately captured but I am recalling we had an email thread. I'll dig for that. One of the key points was that you will have user actions that result in changes to the information that may or may not result in new signaling - e.g., a Configure. So, you need to keep some form of an instance and some form of state. We agreed to use XML rather than UML. I can envision as you note that some of the XML blobs from the schema would be carried in a CLUE message. And other information is used to inform what should be carried in the SDP. Mary. On Mon, Oct 29, 2012 at 2:25 PM, Paul Kyzivat wrote: > On 10/29/12 1:52 PM, Mary Barnes wrote: > >> On the call earlier today, we also discussed the data model. The >> general agreement on the call is that the data model as reflected in >> draft-presta-clue-data-model-**schema describes the data needed by the >> CLUE application - i.e., it's the CLUE instance concept. It does not >> directly reflect the contents of a CLUE message. The application data >> would be used to populate CLUE messages, as well as SDP and would >> reflect updates based on both the CLUE and SDP signaling. >> >> If we can get agreement on that before the meeting, I believe our >> discussions can be much more productive. If folks could please reply >> "Yes" or "No" reflecting agreement with the above, that would be >> helpful. If you reply "No", please explain why. >> > > Well, while that is *possible*, it seems odd to me. The XML schema defines > an *encoding*. What you are describing would make more sense to me if we > were doing a more abstract model, such as via UML, that isn't directly tied > to an encoding. > > What is in the data model right now doesn't exactly map onto clue > messages. But the "clueInfo" element comes very close to mapping onto an > Advertisement as described in the framework. And there isn't (yet) anything > in the schema that maps in an obvious way to a Configure message. > > Nevertheless I'm ok with acknowledging that some of the stuff in the model > may end up in the SDP until we get this sorted out and find a better way to > represent it. > > Thanks, > Paul (as individual) > --e89a8f22bd0931615504cd3938a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This was the discussion we had on one of the calls a while back, although, = I can't find the specific one quickly reviewing the minutes, so it may = not have been appropriately captured but I am recalling we had an email thr= ead. =A0I'll dig for that.=A0

One of the key points was that you will have user actio= ns that result in changes to the information that may or may not result in = new signaling - e.g., a Configure. So, you need to keep some form of an ins= tance and some form of state. =A0

We agreed to use XML rather than UML. I can envision as= you note that some of the XML blobs from the schema would be carried in a = CLUE message. =A0And other information is used to inform what should be car= ried in the SDP. =A0

Mary.=A0

On Mo= n, Oct 29, 2012 at 2:25 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>= ; wrote:
On 1= 0/29/12 1:52 PM, Mary Barnes wrote:
On the call earlier today, we also discussed the data model. =A0The
general agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the=
CLUE application - i.e., it's the CLUE instance concept. =A0It does not=
directly reflect the contents of a CLUE message. =A0The application data would be used to populate CLUE messages, as well as SDP and would
reflect updates based on both the CLUE and SDP signaling.

If we can get agreement on that before the meeting, I believe our
discussions can be much more productive. If folks could please reply
"Yes" or "No" reflecting agreement with the above, that= would be
helpful. =A0If you reply "No", please explain why.

Well, while that is *possible*, it seems odd to me. The XML schema defines = an *encoding*. What you are describing would make more sense to me if we we= re doing a more abstract model, such as via UML, that isn't directly ti= ed to an encoding.

What is in the data model right now doesn't exactly map onto clue messa= ges. But the "clueInfo" element comes very close to mapping onto = an Advertisement as described in the framework. And there isn't (yet) a= nything in the schema that maps in an obvious way to a Configure message.
Nevertheless I'm ok with acknowledging that some of the stuff in the mo= del may end up in the SDP until we get this sorted out and find a better wa= y to represent it.

=A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 Paul (as individual)

--e89a8f22bd0931615504cd3938a1-- From ron.even.tlv@gmail.com Mon Oct 29 15:25: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 DB39F21F8647 for ; Mon, 29 Oct 2012 15:25:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YPxqjhLkV8Op for ; Mon, 29 Oct 2012 15:25:28 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 155B621F8646 for ; Mon, 29 Oct 2012 15:25:27 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2193914eaa.31 for ; Mon, 29 Oct 2012 15:25:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=5MApRCq4eQkBs+iNK2sF3sfSm2r9VS7/g7WhehLYIOE=; b=l6ef82g5to2x5SVjRWMnwrhnxs/7SXquZbdg6H5lsLkFI25PBt1d06vEQsWWCkKXHa Guab9Nd6Ztkk+meS1DlKxc897+P6XynL7YonTARSwl05IjYil1qHQ7rZOXNaPapuyTFY vtI8uEdBW2rURY28UdHMHv1DX+XLpFmFsJpRYH2H6eG95j205VUN9pKihdAWZxRRfREa aImQcAXYntMaESVe9LQBX/sVxcXm1JGpZtngmAKRWH1RU7AhiYyr4/mOoBNA4Q6yNMHf 7IUxiE8fAVBewgy7nkKJ7s669PCWXjJ2rTG8048elOzNx5UGoAEaWnm7aP9XyleRXktq 59yg== Received: by 10.14.223.4 with SMTP id u4mr65430200eep.19.1351549527228; Mon, 29 Oct 2012 15:25:27 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id a44sm25491365eeo.7.2012.10.29.15.25.25 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 15:25:26 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> In-Reply-To: <508EDCE7.6090204@alum.mit.edu> Date: Tue, 30 Oct 2012 00:23:14 +0200 Message-ID: <00fc01cdb623$fed20620$fc761260$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1H205IYhCmcjSpxYAUxN6zg5tsgC/Cc7eAw1ugkaXY6SI4A== Content-Language: en-us Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 22:25:29 -0000 Paul, This was the statement I answered "no" " The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application" I disagree that it reflects that data needed by a CLUE application and I explained why. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29 October, 2012 9:46 PM To: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach On 10/29/12 3:19 PM, Roni Even wrote: > Hi, > > My view is 'no". I still fail to see the need for the encoding groups > and individual encodes. > > In the current definition of capture scene, I am not sure what is the > meaning of different individual encodes and eventually the receiver > can define what it can receive (Typically H.264 is symmetric in terms > of profile but does not need to be in the level) and can ask for > specific resolution with the SDP image attribute ISTM that you are answering a different question than the one Mary asked. You seem to be saying that you disagree with the framework as it is - that it can/should be simpler. That is a separate question. If such changes were made it might affect a lot. Thanks, Paul > Roni Even > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on objective and basic > approach > > On the call earlier today, we also discussed the data model. The > general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the > CLUE application - i.e., it's the CLUE instance concept. It does not > directly reflect the contents of a CLUE message. The application data > would be used to populate CLUE messages, as well as SDP and would > reflect updates based on both the CLUE and SDP signaling. > > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would be > helpful. If you reply "No", please explain why. > > Regards, > > Mary > > as CLUE WG co-chair > > > > _______________________________________________ > 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 ron.even.tlv@gmail.com Mon Oct 29 15:28:55 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98FF521F8566 for ; Mon, 29 Oct 2012 15:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1JJLE9Lj+gLM for ; Mon, 29 Oct 2012 15:28:55 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9552921F8516 for ; Mon, 29 Oct 2012 15:28:54 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so2194836eaa.31 for ; Mon, 29 Oct 2012 15:28:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=5byH3bBKcqDiQyxzgV44bWjRM8E3tt30X0r/0ydjnJA=; b=EIKaWacLKvIwTtho2YVzszc5kNEufQwowf5Q2Pm4SMFVgxDeBdihMWYBDbmJ93agSA O3Xb4ZsxJ1cxMZiVLDU2SToC/ADOtYv7QTQ4tc6C1PEHviYUSHegpnTa4SsiYCGopiep n2BeSF9El41lE/e4xxIeR6g2GsCY3l6D+LQZIhjWdvf3P1WkdGTgkaA2TOuYuwZUy0Pd Au+85ePANR+iW2zxNGnhp0o9nY8T3vVKR8YHI1hBU0Yf6Ekb+kdT+zOYTvqm3jaJ2TWx Enk0eB4Qr8SzflntPLLDoPHw8TfhB4mpkivZwjy1QvClAKWdNclDX2jhVJj7o18ogURr lDzw== Received: by 10.14.173.195 with SMTP id v43mr65140624eel.39.1351549730731; Mon, 29 Oct 2012 15:28:50 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id d44sm25506121eeo.10.2012.10.29.15.28.48 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Oct 2012 15:28:49 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Tue, 30 Oct 2012 00:26:38 +0200 Message-ID: <00fd01cdb624$7824d4d0$686e7e70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FE_01CDB635.3BAE4110" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1H205IYhCmcjSpxYAUxN6zg5tspeCCZYw Content-Language: en-us Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 22:28:55 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FE_01CDB635.3BAE4110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Small question Is there a difference in the data model if we decide to support delta advertisement? Roni From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Mary Barnes Sent: 29 October, 2012 7:52 PM To: CLUE Subject: [clue] Data model - agreement on objective and basic approach On the call earlier today, we also discussed the data model. The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. The application data would be used to populate CLUE messages, as well as SDP and would reflect updates based on both the CLUE and SDP signaling. If we can get agreement on that before the meeting, I believe our discussions can be much more productive. If folks could please reply "Yes" or "No" reflecting agreement with the above, that would be helpful. If you reply "No", please explain why. Regards, Mary as CLUE WG co-chair ------=_NextPart_000_00FE_01CDB635.3BAE4110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Small question

Is there a difference in the data model if we decide to support delta = advertisement?

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 29 October, 2012 7:52 PM
To: = CLUE
Subject: [clue] Data model - agreement on objective and = basic approach

 

On the call = earlier today, we also discussed the data model.  The general = agreement on the call is that the data model as reflected in = draft-presta-clue-data-model-schema describes the data needed by the = CLUE application - i.e., it's the CLUE instance concept.  It does = not directly reflect the contents of a CLUE message.  The = application data would be used to populate CLUE messages, as well as SDP = and would reflect updates based on both the CLUE and SDP signaling. =  

 

If we can get agreement on that before the meeting, I = believe our discussions can be much more productive. If folks could = please reply "Yes" or "No" reflecting agreement with = the above, that would be helpful.  If you reply "No", = please explain why.  

 

Regards,

Mary

as = CLUE WG co-chair

------=_NextPart_000_00FE_01CDB635.3BAE4110-- From pkyzivat@alum.mit.edu Mon Oct 29 16:00: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 867C621F86EA for ; Mon, 29 Oct 2012 16:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KDEDgG-2KmxX for ; Mon, 29 Oct 2012 16:00:51 -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 A0EC321F86DD for ; Mon, 29 Oct 2012 16:00:51 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta02.westchester.pa.mail.comcast.net with comcast id H0vz1k0020xGWP851B0w9A; Mon, 29 Oct 2012 23:00:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id HAzm1k01C3ZTu2S3YAznTo; Mon, 29 Oct 2012 22:59:47 +0000 Message-ID: <508F0AA1.2010006@alum.mit.edu> Date: Mon, 29 Oct 2012 19:00:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Roni Even References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> In-Reply-To: <00fc01cdb623$fed20620$fc761260$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 23:00:52 -0000 On 10/29/12 6:23 PM, Roni Even wrote: > Paul, > This was the statement I answered "no" > " The general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the CLUE > application" > I disagree that it reflects that data needed by a CLUE application and I > explained why. OK, fair enough. Mary can comment, but my take was that the point of her question was to distinguish between two alternatives: - the data model represents all the data needed by the clue app. (which implies to me that it encompasses all the data in the framework.) - the data model represents the data to be exchanged in clue messages. It is a bigger deal if the framework includes things that are not needed by the clue application. I was of the impression that, except for some fine tuning, we were largely in agreement on the framework. If we don't have consensus on *that* then resolving that is of higher priority that much of the other stuff we are discussing. Thanks, Paul > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 29 October, 2012 9:46 PM > To: clue@ietf.org > Subject: Re: [clue] Data model - agreement on objective and basic approach > > On 10/29/12 3:19 PM, Roni Even wrote: >> Hi, >> >> My view is 'no". I still fail to see the need for the encoding groups >> and individual encodes. >> >> In the current definition of capture scene, I am not sure what is the >> meaning of different individual encodes and eventually the receiver >> can define what it can receive (Typically H.264 is symmetric in terms >> of profile but does not need to be in the level) and can ask for >> specific resolution with the SDP image attribute > > ISTM that you are answering a different question than the one Mary asked. > You seem to be saying that you disagree with the framework as it is - that > it can/should be simpler. > > That is a separate question. If such changes were made it might affect a > lot. > > Thanks, > Paul > >> Roni Even >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Mary Barnes >> *Sent:* 29 October, 2012 7:52 PM >> *To:* CLUE >> *Subject:* [clue] Data model - agreement on objective and basic >> approach >> >> On the call earlier today, we also discussed the data model. The >> general agreement on the call is that the data model as reflected in >> draft-presta-clue-data-model-schema describes the data needed by the >> CLUE application - i.e., it's the CLUE instance concept. It does not >> directly reflect the contents of a CLUE message. The application data >> would be used to populate CLUE messages, as well as SDP and would >> reflect updates based on both the CLUE and SDP signaling. >> >> If we can get agreement on that before the meeting, I believe our >> discussions can be much more productive. If folks could please reply >> "Yes" or "No" reflecting agreement with the above, that would be >> helpful. If you reply "No", please explain why. >> >> Regards, >> >> Mary >> >> as CLUE WG co-chair >> >> >> >> _______________________________________________ >> 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 pkyzivat@alum.mit.edu Mon Oct 29 16:02:05 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 357CE21F865B for ; Mon, 29 Oct 2012 16:02:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR5-8Q1TtYHU for ; Mon, 29 Oct 2012 16:02:04 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC3E21F8562 for ; Mon, 29 Oct 2012 16:02:04 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta03.westchester.pa.mail.comcast.net with comcast id H7451k01017dt5G53B29Rn; Mon, 29 Oct 2012 23:02:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id HB321k0053ZTu2S3ZB32oJ; Mon, 29 Oct 2012 23:03:02 +0000 Message-ID: <508F0AEA.1040408@alum.mit.edu> Date: Mon, 29 Oct 2012 19:02:02 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <00fd01cdb624$7824d4d0$686e7e70$@gmail.com> In-Reply-To: <00fd01cdb624$7824d4d0$686e7e70$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 29 Oct 2012 23:02:05 -0000 On 10/29/12 6:26 PM, Roni Even wrote: > Hi, > > Small question > > Is there a difference in the data model if we decide to support delta > advertisement? IMO - NO. Thanks, Paul (as individual) > Roni > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on objective and basic approach > > On the call earlier today, we also discussed the data model. The > general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the > CLUE application - i.e., it's the CLUE instance concept. It does not > directly reflect the contents of a CLUE message. The application data > would be used to populate CLUE messages, as well as SDP and would > reflect updates based on both the CLUE and SDP signaling. > > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would be > helpful. If you reply "No", please explain why. > > Regards, > > Mary > > as CLUE WG co-chair > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Oct 29 18:38:44 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 1675521F862C for ; Mon, 29 Oct 2012 18:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, J_CHICKENPOX_17=0.6] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tt8dnyqO4NOU for ; Mon, 29 Oct 2012 18:38:43 -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 9554221F861F for ; Mon, 29 Oct 2012 18:38:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIEuj1B20W3v/2dsb2JhbAANN8ZAAQEBAwEBAQEvAQUbGwoGBwQLEQMBAgEJFg8JAwIBAgEVKAgTBgIBAReHZRGoT4MpkBUEi3WGXQOSQpZ3 Received: from ppp118-209-109-239.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.109.239]) by ipmail06.adl6.internode.on.net with ESMTP; 30 Oct 2012 12:08:40 +1030 Message-ID: <508F2F9E.9070707@nteczone.com> Date: Tue, 30 Oct 2012 12:38:38 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <50880010.2070503@alvestrand.no> <508C05C7.3060305@alum.mit.edu> In-Reply-To: <508C05C7.3060305@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] FYI: RTCWEB proposal using a=content 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, 30 Oct 2012 01:38:44 -0000 Hello Paul, Given a multi-stream environment I don't think that a=content will be sufficient in its current form. I think it originates from a "Video stream + 1" background and not really defined when you could have more than two content streams. Regards, Christian On 28/10/2012 3:03 AM, Paul Kyzivat wrote: > The message below has overlap with work we are doing. It is proposing > using "a=content", and exposing it on the MediaStreamTracks api as a > way of mapping individual mediaStreamTracks to particular m-lines. > > I haven't formed an opinion about this - whether it will help with > clue compatibility or hurt. > > Thanks, > Paul > > > -------- Original Message -------- > Subject: Mapping multiple media sources to few or many M-lines > Resent-Date: Wed, 24 Oct 2012 14:50:28 +0000 > Resent-From: public-webrtc@w3.org > Date: Wed, 24 Oct 2012 16:49:52 +0200 > From: Harald Alvestrand > To: public-webrtc@w3.org > > Cullen, Justin and I have been working on a proposal for this issue, > which is one of the things we have to settle in order to know what we're > designing our signalling for. > > One proposal is outlined below - it depends on defining a new attribute > of a MediaStreamTrack called "content", and using that to direct tracks > onto different M-lines when negotiating SDP. > > Details below. > > ==Proposal for controlling the allocation of multiple media sources to > RTP sessions== > > ===Problem description=== > > There are a number of applications that can be envisioned using WebRTC. > The applications where one audio and one video stream is connected > between two participants are trivial; there is no real controversy > there. But other styles are more difficult. > Two important cases are: > A single PeerConnection is used to connect an end-user to a central > non-mixing MCU (a "RTCP-terminating MCU" in RFC 5117 terminology) and > the connection between the MCU and the user has a large number of audio > and/or video tracks (for example, a “thumbnail strip” + one or more > large video images). > A single PeerConnection is used to connect an end-user to a non-RTCWEB > SIP system, through a signalling gateway but not through a media > gateway, using multiple video sessions that are distinguished by use of > the “a=content” attribute (for example, a main video feed plus a > presentation video feed). > > In the first case, we definitely want all the video sources in the same > RTP session, which helps us be able to add or remove video sources with > minimal overhead (no new ICE ports and NAT pinholes). > > In the second case, we want to have specific video sources on different > RTP sessions, and we want to have exact control over which video streams > get assigned to what RTP sessions. > Solution Description > > > The basic idea is to expose a new "content" property on > MediaStreamTracks, as defined in RFC 4796, which would indicate the > "usage" of the media in that particular track. When createOffer is > called to create a session description, it will include a m= line for > each [media, content] tuple that exists within the list of attached > MediaStreamTracks. > > Since normally m= lines are omitted for tuples that have no associated > MediaStreamTracks, the application can also include an empty m= line for > a given tuple by specifying a constraint to createOffer, similar to how > the existing OfferToReceiveAudio and OfferToReceiveVideo can be used to > add empty m= lines for audio and video. The suggested form for this > constraint is to use the existing OfferToReceiveAudio and > OfferToReceiveVideo keys, but use the content property as the value, > e.g. "OfferToReceiveVideo:slides". > > Individual MediaStreamTracks are represented via a=ssrc attributes on > the appropriate m= lines; the MSID attribute on the a=ssrc line > identifies the MediaStreamTrack. There can be an arbitrary number of > MediaStreamTracks associated with a given m= line, including zero; > demuxing of these MediaStreamTracks is performed done according to the > SSRC specified with the a=ssrc attribute. > > By default, the content property for MediaStreamTracks is left empty. > This means that MediaStreamTracks are by default associated with m= > lines that have no a=content attribute. > > createAnswer works the same way as createOffer, using its attached > MediaStreamTracks, and the constraints supplied; note that it will > always include m= lines as needed to match the offer, even if no > MediaStreamTracks are attached. > > Through this mechanism, applications that want to make use of multiple > media streams can generate SDP that best matches what existing > videoconferencing equipment expects, but this usage is not required; > sophisticated applications can use the content property to assign their > own grouping of MediaStreamTracks to m= lines, including the creation of > individual m= lines for each MediaStreamTrack, or the combination of all > video MediaStreamTracks into a single m= line. Of course, these > applications could also do so by generating the SDP themselves and > passing this SDP into setLocalDescription. > > ===Examples=== > > MediaStream ms1 contains an audio track (denoted a0 in msid lines) and > video track (v0), as obtained from getUserMedia(). The label of ms1 is > . > MediaStream ms2 contains a single video track (also denoted v0, since > it’s the first video track in its mediastream), taken from the desktop. > The label of ms2 is . > PeerConnection pc exists, with no streams attached. > pc.addStream(ms1, null); > pc.createOffer(null); > > produces: > > > m=audio > a=ssrc:1234 msid: a0 > m=video // nothing fancy > a=ssrc:5678 msid: v0 > pc.addStream(ms1, null); > pc.addStream(ms2, null); > pc.createOffer(null); > > produces: > > > m=audio > a=ssrc:1234 msid: a0 > m=video // both tracks associated with one m= line > a=ssrc:5678 msid: v0 > a=ssrc:6789 msid: v0 > pc.addStream(ms1, null); > pc.createOffer({mandatory:{"OfferToReceiveVideo:slides"}}); > > produces: > > > m=audio > a=ssrc:1234 msid: a0 > m=video > a=ssrc:5678 msid: v0 > m=video // note this empty m= line > a=content:slides > pc.addStream(ms1, null); > v2.content = "slides"; > pc.addStream(ms2, null); > pc.createOffer(null); > > produces: > > > m=audio > a=ssrc:1234 msid: a0 > m=video > a=ssrc:5678 msid: v0 > m=video // this m= line has an a=content attribute and a track > a=content:slides > a=ssrc:6789 msid: v0 > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From Christian.Groves@nteczone.com Mon Oct 29 18:42:42 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 E4BED21F84C8 for ; Mon, 29 Oct 2012 18:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.900, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5m1rCJwQo0U3 for ; Mon, 29 Oct 2012 18:42:42 -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 58AF621F84C6 for ; Mon, 29 Oct 2012 18:42:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAIsvj1B20W3v/2dsb2JhbAANN8ZRAQEBBAEBATUbGwQGEQsYCRYPCQMCAQIBFTATBgIBAYgNqFCDKZAYBIt1hl0DkkKWdw Received: from ppp118-209-109-239.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.109.239]) by ipmail06.adl6.internode.on.net with ESMTP; 30 Oct 2012 12:12:39 +1030 Message-ID: <508F308D.3020601@nteczone.com> Date: Tue, 30 Oct 2012 12:42:37 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <507F2C8E.5050305@alum.mit.edu> <50854B2E.8030105@alum.mit.edu> <508EB79F.1070803@alum.mit.edu> In-Reply-To: <508EB79F.1070803@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Thoughts on relation between clue messages and SDP 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, 30 Oct 2012 01:42:43 -0000 Hello Paul, I agree with the assumption. I think that the advertisement should contain all the information needed to describe capture so that the receiver can make an educated decision on which capture/s to chose. Regards, Christian On 30/10/2012 4:06 AM, Paul Kyzivat wrote: > We just had a design team meeting with a very few people. > One of the things we discussed was which of the information that we > need to transmit should be in clue messages vs. what should be in SDP. > > One goal of our meeting in Atlanta will be to seek agreement on this. > > It is a slightly different subject than I was trying to get at in this > thread, but the two questions are tightly coupled. > > The proposal I floated here embodies my assumption about that: > > ASSUMPTION: A primary CLUE purpose is to advertise a "menu" of > captures that *could* be sent, and to "order" from that menu (via > Configure messages) the selection of captures that *should* be sent. > All the information necessary to do that (descriptions of attributes > of the available captures) is CLUE information, and belongs in the > CLUE signaling protocol. > > The SDP only needs to be sufficient to support the Configurations in > effect. The way SDP is used with offer/answer is that each side > specifies what it is prepared to *receive*, in contrast with the > Advertisement which describes what can be sent. > > The alternative that I think some have in mind is that SDP might carry > much of the Advertisement. Doing so requires that SDP be able to > convey many aspects of what can be *sent* in addition to its more > common usage to carry what can be received. There is SDP notation to > do this for some things, but not all things, so trying this would > potentially require a number of SDP extensions. Also, the > advertisement potentially describes many more alternatives than will > be configured, so attempting to convey the advertisement in SDP is > likely to explode the size of the SDP. > > PLEASE, think about this, comment on the list prior to the meeting, > and be prepared to discuss it at the meeting. It is really hard to > make more progress without an agreement on this point. > > Thanks, > Paul > > On 10/22/12 9:33 AM, Paul Kyzivat wrote: >> I've been surprised that there have been no replies to this message. >> Is that because it is so obvious and uncontroversial that no comment is >> needed? Or did I write it so poorly that nobody understands what I'm >> saying? >> >> Thanks, >> Paul >> >> On 10/17/12 6:09 PM, Paul Kyzivat wrote: >>> After discussions at the interim around the call flows and signaling >>> issues, and subsequent discussion, I have some revised ideas about how >>> the clue messages and SDP O/A can be coordinated. >>> >>> The Configure message selects capture encodings that the receiver wants >>> the sender to send to it via RTP sessions RTP streams within those >>> sessions that are specified in SDP. >>> >>> In some cases it may be that a new Configure can reuse the RTP >>> resources >>> already present in a previously established O/A. But it is also >>> possible >>> that a new Configure will ask for capture encodings that require RTP >>> resources that aren't present in the previously established O/A. In >>> that >>> case a new O/A will be needed, before or after that Configure is sent. >>> >>> One of the questions that came up at the interim is whether the O/A to >>> prep for a Configure should come before, or after, the Configure. An >>> argument for doing the O/A *before* the Configure is that then it is >>> known that the resources to support the Configure are available, and >>> allows the Configure to reference elements present in the SDP. An >>> argument for doing the O/A *after* the Configure is that then the >>> answerer will understand *why* it is being asked to configure the >>> SDP as >>> specified, and so help it decide whether it wants to accept that. >>> >>> I finally realized that the the Advertisement defines what is possible, >>> and implicitly indicates what SDP will be required to support that. >>> Hence, I think we can expect that an offerer can construct a new offer >>> in contemplation of a Configure message it plans to send plus the last >>> one it received, and in the context of the corresponding >>> Advertisements. >>> The Answerer can then evaluate that offer in the context of the same >>> Advertisements. As long as the offer is consistent with current >>> advertisements it should aim to construct an answer that accepts it. >>> >>> With that approach, a Configure can be constructed relative to the most >>> recent O/A. >>> >>> During initial session setup, before the first Advertisements are >>> exchanged, the offerer will have to construct the first offer without >>> the context of an advertisement from the other side. It can however >>> still construct the offer to be consistent with the Advertisement it >>> plans to send. The Answerer can construct the answer in the context of >>> the Advertisement it plans to send, constrained by what is in the >>> offer. >>> (The offer may not be sufficient for everything the answerer wishes to >>> include.) Each side can then begin sending media that fits within that >>> initial O/A, using a default Configure constructed locally. >>> Concurrently >>> Advertisements can be exchanged. After that Configure messages may be >>> exchanged. (Or not if what is being received is satisfactory.) >>> >>> It may turn out that in many cases the initial O/A is sufficient for >>> the >>> initial Configure that each side wants to send. If so then no new >>> O/A is >>> needed. Or it may turn out that it isn't. If not, then either side may >>> initiate an O/A with an offer compatible with the desired Configure, I >>> described above. >>> >>> This also helps clarify that the Configure is both a selection from the >>> advertisement and a mapping of that selection onto the SDP. >>> >>> This also clarifies that the Advertisement must contain sufficient >>> information to map a Configure onto the SDP needed to convey that. For >>> instance, if the sender has encoders with independent IP addr/port, >>> then >>> the offer will require multiple m-lines for those, but if both the >>> sender and receiver have all encoders on a single addr/port then one >>> m-line may be sufficient. Since the offerer determines the set of >>> m-lines in the O/A, it needs to figure this out on behalf of the >>> answerer. >>> >>> What do people think of this approach? >>> >>> Thanks, >>> Paul (as individual) >>> _______________________________________________ >>> 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 Christian.Groves@nteczone.com Mon Oct 29 18:53:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AAD21F862C for ; Mon, 29 Oct 2012 18:53:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jlpu8xXONKJv for ; Mon, 29 Oct 2012 18:53:08 -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 4C67721F8510 for ; Mon, 29 Oct 2012 18:53:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACcyj1B20W3v/2dsb2JhbAANN8ZfAQEBBAEBATUbGwoRCxgJFg8JAwIBAgEVMBMGAgEBiA2oRYMpkBYEi3WDOYMkA6k5 Received: from ppp118-209-109-239.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.109.239]) by ipmail06.adl6.internode.on.net with ESMTP; 30 Oct 2012 12:23:07 +1030 Message-ID: <508F3300.3010003@nteczone.com> Date: Tue, 30 Oct 2012 12:53:04 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 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] Data model - agreement on objective and basic approach 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, 30 Oct 2012 01:53:10 -0000 Hello Mary, I haven't been party to the telephone discussions but I wonder why we need an abstraction like a CLUE instance concept in what is a pretty simple protocol? I wonder what the benefit would be in having a data model based on a CLUE instance and then a seperate XML to define the actual messages? I think it would be good to understand the rationale why the data model schema was written in this way and what the benefit is. I think this would be good background before one can definitely say yes or no. If you want a definite answer now, then no. Regards, Christian On 30/10/2012 4:52 AM, Mary Barnes wrote: > On the call earlier today, we also discussed the data model. The > general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the > CLUE application - i.e., it's the CLUE instance concept. It does not > directly reflect the contents of a CLUE message. The application data > would be used to populate CLUE messages, as well as SDP and would > reflect updates based on both the CLUE and SDP signaling. > > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would be > helpful. If you reply "No", please explain why. > > Regards, > Mary > as CLUE WG co-chair > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From spromano@unina.it Tue Oct 30 01:02:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6150921F8464 for ; Tue, 30 Oct 2012 01:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htbuEMtmJfPx for ; Tue, 30 Oct 2012 01:02:55 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id BC0C521F8453 for ; Tue, 30 Oct 2012 01:02:54 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id q9U82mLp009198 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 30 Oct 2012 09:02:48 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_F9025600-509C-4A8F-98FB-84F5DBF5F554" From: Simon Pietro Romano In-Reply-To: <508F0AA1.2010006@alum.mit.edu> Date: Tue, 30 Oct 2012 09:03:00 +0100 Message-Id: References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1283) Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 08:02:56 -0000 --Apple-Mail=_F9025600-509C-4A8F-98FB-84F5DBF5F554 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi all, just to be clear on the current structure of the data model schema: all = the things you find there were 'extracted' (by Roberta and me) from = information currently contained inside the framework draft (as well as = from some side documents, associated with either the data model or the = envisaged call flows). So, unless we have misinterpreted the above = document(s) (which is obviously possible), we should first of all focus = on the framework in order to try and converge on an agreed-upon CLUE = architecture. Once done with this, we can fine-tune the data model. As I = already stated on this list, it is my personal opinion that we should = remove from the framework document all of the data-model stuff that it = currently contains, and rather focus on a clear definition of framework = components and interfaces. I might look naif, but I would like to arrive = at an 'ordinary' set of documents: (i) general framework; (ii) data = model; (iii) clue protocol (with advertisement and configuration = messages); (iv) call flows (showing how SDP O/A and CLUE protocol = messages concur in effectively setting up a CLUE session). As to the 'UML vs XML' querelle, I would suggest that: 1. Both UML class diagrams and XML schema can be adopted for the = description of the data model, i.e., the STATIC part of the framework, = associated with the description of what some of you properly called a = 'CLUE instance'; 2. UML sequence diagrams can be adopted to describe CLUE call flows, = i.e. the DYNAMIC part of the framework, which clearly envisages the = co-existence of SDP and CLUE protocol messages. XML schemas are not = suitable for this dynamic part. This said, it is clear that CLUE protocol messages (in particular, CLUE = advertisements) will be constructed by leveraging information contained = inside a CLUE instance. Which parts of a CLUE instance should go into an = advertisement and which should be carried inside SDP can be a matter of = discussion. My 2 cents, Simon Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: > On 10/29/12 6:23 PM, Roni Even wrote: >> Paul, >> This was the statement I answered "no" >> " The general agreement on the call is that the data model as = reflected in >> draft-presta-clue-data-model-schema describes the data needed by the = CLUE >> application" >> I disagree that it reflects that data needed by a CLUE application = and I >> explained why. >=20 > OK, fair enough. >=20 > Mary can comment, but my take was that the point of her question was = to distinguish between two alternatives: > - the data model represents all the data needed by the clue app. > (which implies to me that it encompasses all the data in the > framework.) > - the data model represents the data to be exchanged in > clue messages. >=20 > It is a bigger deal if the framework includes things that are not = needed by the clue application. I was of the impression that, except for = some fine tuning, we were largely in agreement on the framework. >=20 > If we don't have consensus on *that* then resolving that is of higher = priority that much of the other stuff we are discussing. >=20 > Thanks, > Paul >=20 >> Roni >>=20 >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Paul >> Kyzivat >> Sent: 29 October, 2012 9:46 PM >> To: clue@ietf.org >> Subject: Re: [clue] Data model - agreement on objective and basic = approach >>=20 >> On 10/29/12 3:19 PM, Roni Even wrote: >>> Hi, >>>=20 >>> My view is 'no". I still fail to see the need for the encoding = groups >>> and individual encodes. >>>=20 >>> In the current definition of capture scene, I am not sure what is = the >>> meaning of different individual encodes and eventually the receiver >>> can define what it can receive (Typically H.264 is symmetric in = terms >>> of profile but does not need to be in the level) and can ask for >>> specific resolution with the SDP image attribute >>=20 >> ISTM that you are answering a different question than the one Mary = asked. >> You seem to be saying that you disagree with the framework as it is - = that >> it can/should be simpler. >>=20 >> That is a separate question. If such changes were made it might = affect a >> lot. >>=20 >> Thanks, >> Paul >>=20 >>> Roni Even >>>=20 >>> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On = Behalf >>> Of *Mary Barnes >>> *Sent:* 29 October, 2012 7:52 PM >>> *To:* CLUE >>> *Subject:* [clue] Data model - agreement on objective and basic >>> approach >>>=20 >>> On the call earlier today, we also discussed the data model. The >>> general agreement on the call is that the data model as reflected in >>> draft-presta-clue-data-model-schema describes the data needed by the >>> CLUE application - i.e., it's the CLUE instance concept. It does = not >>> directly reflect the contents of a CLUE message. The application = data >>> would be used to populate CLUE messages, as well as SDP and would >>> reflect updates based on both the CLUE and SDP signaling. >>>=20 >>> If we can get agreement on that before the meeting, I believe our >>> discussions can be much more productive. If folks could please reply >>> "Yes" or "No" reflecting agreement with the above, that would be >>> helpful. If you reply "No", please explain why. >>>=20 >>> Regards, >>>=20 >>> Mary >>>=20 >>> as CLUE WG co-chair >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>>=20 >>=20 >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >>=20 >>=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_F9025600-509C-4A8F-98FB-84F5DBF5F554 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = all,

just to be clear on the current structure of the = data model schema: all the things you find there were 'extracted' (by = Roberta and me) from information currently contained inside the = framework draft (as well as from some side documents, associated with = either the data model or the envisaged call flows). So, unless we have = misinterpreted the above document(s) (which is obviously possible), we = should first of all focus on the framework in order to try and converge = on an agreed-upon CLUE architecture. Once done with this, we can = fine-tune the data model. As I already stated on this list, it is my = personal opinion that we should remove from the framework document all = of the data-model stuff that it currently contains, and rather focus on = a clear definition of framework components and interfaces. I might look = naif, but I would like to arrive at an 'ordinary' set of documents: (i) =  general framework; (ii) data model; (iii) clue protocol (with = advertisement and configuration messages); (iv) call flows (showing how = SDP O/A and CLUE protocol messages concur in effectively setting up a = CLUE session).

As to the 'UML vs XML' querelle, = I would suggest that:

1. Both UML class = diagrams and XML schema can be adopted for the description of the data = model, i.e., the STATIC part of the framework, associated with the = description of what some of you properly called a 'CLUE = instance';
2. UML sequence diagrams can be adopted to describe = CLUE call flows, i.e. the DYNAMIC part of the framework, which clearly = envisages the co-existence of SDP and CLUE protocol messages. XML = schemas are not suitable for this dynamic = part.

This said, it is clear that CLUE protocol = messages  (in particular, CLUE advertisements) will be constructed = by leveraging information contained inside a CLUE instance. Which parts = of a CLUE instance should go into an advertisement and which should be = carried inside SDP can be a matter of = discussion.

My 2 = cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha = scritto:

On 10/29/12 6:23 PM, Roni Even wrote:
Paul,
This was = the statement I answered "no"
" = The general agreement on the call is that the data model as reflected = in
draft-presta-clue-data-model-schema describes the data = needed by the CLUE
application"
I = disagree that it reflects that data needed by a CLUE application and = I
explained = why.

OK, fair enough.

Mary can comment, but = my take was that the point of her question was to distinguish between = two alternatives:
- the data model represents all the data needed by = the clue app.
 (which implies to me that it encompasses all the = data in the
 framework.)
- the data model represents the = data to be exchanged in
 clue messages.

It is a bigger = deal if the framework includes things that are not needed by the clue = application. I was of the impression that, except for some fine tuning, = we were largely in agreement on the framework.

If we don't have = consensus on *that* then resolving that is of higher priority that much = of the other stuff we are discussing.

= Thanks,
Paul

Roni

-----Original = Message-----
From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf Of = Paul
Kyzivat
Sent: 29 = October, 2012 9:46 PM
To: clue@ietf.org
Subject: Re: [clue] Data model - agreement on objective = and basic approach

On 10/29/12 = 3:19 PM, Roni Even wrote:
Hi,

My view is 'no". I still fail to = see the need for the encoding = groups
and individual = encodes.

In the current definition of = capture scene, I am not sure what is = the
meaning of different individual encodes and eventually the = receiver
can define what it can receive = (Typically H.264 is symmetric in = terms
of profile but does not need to be in the level) and can = ask for
specific resolution with the SDP image = attribute

ISTM that you = are answering a different question than the one Mary = asked.
You seem to be saying = that you disagree with the framework as it is - = that
it can/should be = simpler.

That is a = separate question. If such changes were made it might affect = a
lot.

= Thanks,
= Paul

Roni Even

*From:*clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] *On = Behalf
Of *Mary Barnes
*Sent:* 29 October, 2012 7:52 = PM
*To:* CLUE
*Subject:* [clue] Data model - = agreement on objective and = basic
approach

On the call earlier today, we = also discussed the data model. =  The
general agreement on the call is = that the data model as reflected = in
draft-presta-clue-data-model-schema describes the data = needed by the
CLUE application - i.e., it's = the CLUE instance concept.  It does = not
directly reflect the contents of a CLUE message.  The = application data
would be used to populate CLUE = messages, as well as SDP and = would
reflect updates based on both the CLUE and SDP = signaling.

If we can get agreement on that = before the meeting, I believe = our
discussions can be much more productive. If folks could = please reply
"Yes" or "No" reflecting = agreement with the above, that would = be
helpful.  If you reply "No", please explain = why.

Regards,

Mary

as CLUE WG = co-chair



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


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



_______________________________________= ________
clue mailing list
clue@ietf.org
https://www.ietf.org/ma= ilman/listinfo/clue


      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_F9025600-509C-4A8F-98FB-84F5DBF5F554-- From Christian.Groves@nteczone.com Tue Oct 30 02:33:59 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 2F21E21F84D6 for ; Tue, 30 Oct 2012 02:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zz7+HOKVFScK for ; Tue, 30 Oct 2012 02:33:58 -0700 (PDT) Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 684A721F84CF for ; Tue, 30 Oct 2012 02:33:57 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAD2ej1B20W3v/2dsb2JhbAANN8ZbAQEBBAEBAS8BBRsUBwoNAgILEQEDAQEBCRYIBwkDAgECAQkMHwMGCBMGAgEBiA2odYMpkCQEBItxGoZDA4tFhn2KDYxqgVA Received: from ppp118-209-109-239.lns20.mel4.internode.on.net (HELO [127.0.0.1]) ([118.209.109.239]) by ipmail06.adl2.internode.on.net with ESMTP; 30 Oct 2012 20:03:55 +1030 Message-ID: <508F9F00.8040709@nteczone.com> Date: Tue, 30 Oct 2012 20:33:52 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: clue@ietf.org References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 09:33:59 -0000 Hello Simon, When you say that you want to remove "all" the data model stuff from the framework can you be a bit more specific as to what parts you want removed? Regards, Christian On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > Hi all, > > just to be clear on the current structure of the data model schema: > all the things you find there were 'extracted' (by Roberta and me) > from information currently contained inside the framework draft (as > well as from some side documents, associated with either the data > model or the envisaged call flows). So, unless we have misinterpreted > the above document(s) (which is obviously possible), we should first > of all focus on the framework in order to try and converge on an > agreed-upon CLUE architecture. Once done with this, we can fine-tune > the data model. As I already stated on this list, it is my personal > opinion that we should remove from the framework document all of the > data-model stuff that it currently contains, and rather focus on a > clear definition of framework components and interfaces. I might look > naif, but I would like to arrive at an 'ordinary' set of documents: > (i) general framework; (ii) data model; (iii) clue protocol (with > advertisement and configuration messages); (iv) call flows (showing > how SDP O/A and CLUE protocol messages concur in effectively setting > up a CLUE session). > > As to the 'UML vs XML' querelle, I would suggest that: > > 1. Both UML class diagrams and XML schema can be adopted for the > description of the data model, i.e., the STATIC part of the framework, > associated with the description of what some of you properly called a > 'CLUE instance'; > 2. UML sequence diagrams can be adopted to describe CLUE call flows, > i.e. the DYNAMIC part of the framework, which clearly envisages the > co-existence of SDP and CLUE protocol messages. XML schemas are not > suitable for this dynamic part. > > This said, it is clear that CLUE protocol messages (in particular, > CLUE advertisements) will be constructed by leveraging information > contained inside a CLUE instance. Which parts of a CLUE instance > should go into an advertisement and which should be carried inside SDP > can be a matter of discussion. > > My 2 cents, > > Simon > > > Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: > >> On 10/29/12 6:23 PM, Roni Even wrote: >>> Paul, >>> This was the statement I answered "no" >>> " The general agreement on the call is that the data model as >>> reflected in >>> draft-presta-clue-data-model-schema describes the data needed by the >>> CLUE >>> application" >>> I disagree that it reflects that data needed by a CLUE application and I >>> explained why. >> >> OK, fair enough. >> >> Mary can comment, but my take was that the point of her question was >> to distinguish between two alternatives: >> - the data model represents all the data needed by the clue app. >> (which implies to me that it encompasses all the data in the >> framework.) >> - the data model represents the data to be exchanged in >> clue messages. >> >> It is a bigger deal if the framework includes things that are not >> needed by the clue application. I was of the impression that, except >> for some fine tuning, we were largely in agreement on the framework. >> >> If we don't have consensus on *that* then resolving that is of higher >> priority that much of the other stuff we are discussing. >> >> Thanks, >> Paul >> >>> Roni >>> >>> -----Original Message----- >>> From: clue-bounces@ietf.org >>> [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>> Kyzivat >>> Sent: 29 October, 2012 9:46 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] Data model - agreement on objective and basic >>> approach >>> >>> On 10/29/12 3:19 PM, Roni Even wrote: >>>> Hi, >>>> >>>> My view is 'no". I still fail to see the need for the encoding groups >>>> and individual encodes. >>>> >>>> In the current definition of capture scene, I am not sure what is the >>>> meaning of different individual encodes and eventually the receiver >>>> can define what it can receive (Typically H.264 is symmetric in terms >>>> of profile but does not need to be in the level) and can ask for >>>> specific resolution with the SDP image attribute >>> >>> ISTM that you are answering a different question than the one Mary >>> asked. >>> You seem to be saying that you disagree with the framework as it is >>> - that >>> it can/should be simpler. >>> >>> That is a separate question. If such changes were made it might affect a >>> lot. >>> >>> Thanks, >>> Paul >>> >>>> Roni Even >>>> >>>> *From:*clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] *On Behalf >>>> Of *Mary Barnes >>>> *Sent:* 29 October, 2012 7:52 PM >>>> *To:* CLUE >>>> *Subject:* [clue] Data model - agreement on objective and basic >>>> approach >>>> >>>> On the call earlier today, we also discussed the data model. The >>>> general agreement on the call is that the data model as reflected in >>>> draft-presta-clue-data-model-schema describes the data needed by the >>>> CLUE application - i.e., it's the CLUE instance concept. It does not >>>> directly reflect the contents of a CLUE message. The application data >>>> would be used to populate CLUE messages, as well as SDP and would >>>> reflect updates based on both the CLUE and SDP signaling. >>>> >>>> If we can get agreement on that before the meeting, I believe our >>>> discussions can be much more productive. If folks could please reply >>>> "Yes" or "No" reflecting agreement with the above, that would be >>>> helpful. If you reply "No", please explain why. >>>> >>>> Regards, >>>> >>>> Mary >>>> >>>> as CLUE WG co-chair >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >> > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From spromano@unina.it Tue Oct 30 03:24:10 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E2FC21F84EB for ; Tue, 30 Oct 2012 03:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OXfdQPdQylE for ; Tue, 30 Oct 2012 03:24:09 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD9821F84E9 for ; Tue, 30 Oct 2012 03:24:09 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q9UAO5Hm011574 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 30 Oct 2012 11:24:06 +0100 Message-ID: <508FAABC.2000404@unina.it> Date: Tue, 30 Oct 2012 11:23:56 +0100 From: Simon Pietro Romano User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1 MIME-Version: 1.0 To: Christian Groves References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> In-Reply-To: <508F9F00.8040709@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 10:24:10 -0000 Hi Christian, a rough estimation would be the following: a) keep sections 1 through 4 inside the framework document; b) move sections 5 through 8 to the data model document c) move the XML schema to the data model document (final section of the data model, which provides 'one possible' example of how to formally describe the things in the document); d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protocol document; e) move subsection 9.4 to the call flows document; f) move section 10 to the data model document; g) move section 11 to the call flows document. Obviously, the resulting framework document should be revised (and enriched) in view of the proposed distribution of work inside the WG. I would like it to represent an orchestration document, providing an overview of issues, requirements, architecture and protocols. A sort of summary reference for all of the related "drill-down" documents, each expanding on a specific WG item (data model, protocol, call flows, etc.). I acknowledge the fact that this looks much like a revolution, but I nonetheless believe that we already have most of the needed material at hand and just need to better distribute it across the documents produced by the WG. Cheers, Simon Il 30/10/2012 10:33, Christian Groves ha scritto: > Hello Simon, > > When you say that you want to remove "all" the data model stuff from > the framework can you be a bit more specific as to what parts you want > removed? > > Regards, Christian > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >> Hi all, >> >> just to be clear on the current structure of the data model schema: >> all the things you find there were 'extracted' (by Roberta and me) >> from information currently contained inside the framework draft (as >> well as from some side documents, associated with either the data >> model or the envisaged call flows). So, unless we have misinterpreted >> the above document(s) (which is obviously possible), we should first >> of all focus on the framework in order to try and converge on an >> agreed-upon CLUE architecture. Once done with this, we can fine-tune >> the data model. As I already stated on this list, it is my personal >> opinion that we should remove from the framework document all of the >> data-model stuff that it currently contains, and rather focus on a >> clear definition of framework components and interfaces. I might look >> naif, but I would like to arrive at an 'ordinary' set of documents: >> (i) general framework; (ii) data model; (iii) clue protocol (with >> advertisement and configuration messages); (iv) call flows (showing >> how SDP O/A and CLUE protocol messages concur in effectively setting >> up a CLUE session). >> >> As to the 'UML vs XML' querelle, I would suggest that: >> >> 1. Both UML class diagrams and XML schema can be adopted for the >> description of the data model, i.e., the STATIC part of the >> framework, associated with the description of what some of you >> properly called a 'CLUE instance'; >> 2. UML sequence diagrams can be adopted to describe CLUE call flows, >> i.e. the DYNAMIC part of the framework, which clearly envisages the >> co-existence of SDP and CLUE protocol messages. XML schemas are not >> suitable for this dynamic part. >> >> This said, it is clear that CLUE protocol messages (in particular, >> CLUE advertisements) will be constructed by leveraging information >> contained inside a CLUE instance. Which parts of a CLUE instance >> should go into an advertisement and which should be carried inside >> SDP can be a matter of discussion. >> >> My 2 cents, >> >> Simon >> >> >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >> >>> On 10/29/12 6:23 PM, Roni Even wrote: >>>> Paul, >>>> This was the statement I answered "no" >>>> " The general agreement on the call is that the data model as >>>> reflected in >>>> draft-presta-clue-data-model-schema describes the data needed by >>>> the CLUE >>>> application" >>>> I disagree that it reflects that data needed by a CLUE application >>>> and I >>>> explained why. >>> >>> OK, fair enough. >>> >>> Mary can comment, but my take was that the point of her question was >>> to distinguish between two alternatives: >>> - the data model represents all the data needed by the clue app. >>> (which implies to me that it encompasses all the data in the >>> framework.) >>> - the data model represents the data to be exchanged in >>> clue messages. >>> >>> It is a bigger deal if the framework includes things that are not >>> needed by the clue application. I was of the impression that, except >>> for some fine tuning, we were largely in agreement on the framework. >>> >>> If we don't have consensus on *that* then resolving that is of >>> higher priority that much of the other stuff we are discussing. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org >>>> [mailto:clue-bounces@ietf.org] On Behalf Of Paul >>>> Kyzivat >>>> Sent: 29 October, 2012 9:46 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Data model - agreement on objective and basic >>>> approach >>>> >>>> On 10/29/12 3:19 PM, Roni Even wrote: >>>>> Hi, >>>>> >>>>> My view is 'no". I still fail to see the need for the encoding groups >>>>> and individual encodes. >>>>> >>>>> In the current definition of capture scene, I am not sure what is the >>>>> meaning of different individual encodes and eventually the receiver >>>>> can define what it can receive (Typically H.264 is symmetric in terms >>>>> of profile but does not need to be in the level) and can ask for >>>>> specific resolution with the SDP image attribute >>>> >>>> ISTM that you are answering a different question than the one Mary >>>> asked. >>>> You seem to be saying that you disagree with the framework as it is >>>> - that >>>> it can/should be simpler. >>>> >>>> That is a separate question. If such changes were made it might >>>> affect a >>>> lot. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Roni Even >>>>> >>>>> *From:*clue-bounces@ietf.org >>>>> [mailto:clue-bounces@ietf.org] *On Behalf >>>>> Of *Mary Barnes >>>>> *Sent:* 29 October, 2012 7:52 PM >>>>> *To:* CLUE >>>>> *Subject:* [clue] Data model - agreement on objective and basic >>>>> approach >>>>> >>>>> On the call earlier today, we also discussed the data model. The >>>>> general agreement on the call is that the data model as reflected in >>>>> draft-presta-clue-data-model-schema describes the data needed by the >>>>> CLUE application - i.e., it's the CLUE instance concept. It does not >>>>> directly reflect the contents of a CLUE message. The application >>>>> data >>>>> would be used to populate CLUE messages, as well as SDP and would >>>>> reflect updates based on both the CLUE and SDP signaling. >>>>> >>>>> If we can get agreement on that before the meeting, I believe our >>>>> discussions can be much more productive. If folks could please reply >>>>> "Yes" or "No" reflecting agreement with the above, that would be >>>>> helpful. If you reply "No", please explain why. >>>>> >>>>> Regards, >>>>> >>>>> Mary >>>>> >>>>> as CLUE WG co-chair >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ From mary.ietf.barnes@gmail.com Tue Oct 30 14:25:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C5621F847D for ; Tue, 30 Oct 2012 14:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.69 X-Spam-Level: X-Spam-Status: No, score=-102.69 tagged_above=-999 required=5 tests=[AWL=-0.758, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZoi8zeol3D6 for ; Tue, 30 Oct 2012 14:25:05 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD93421F844B for ; Tue, 30 Oct 2012 14:25:04 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so606251lam.31 for ; Tue, 30 Oct 2012 14:25:03 -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=AdsktZNas6Cg/CYKjjfDFkSP2HyeSoc7g6wL5+e1qrY=; b=uUzo4ip1KiJtRDseUeFGcDjInzvQlHVqocrYRX/b4STiDJYU91yMBj8Hmxu4V1KxIL L5L/4iGaVtwUwAuvTK7KvR5RfOQWjplBZ10Zcd75kHnhFX9f0tvigaROdncEUxbQtwT6 jOU0/sxNck0Xzjpn+2GgxgPrQqWCVYFgrZkerl1EjOhz7S6dyp+1MnP/Ni1gYypW6+hz WDC9WMNQgE/U1jnPMgXNCR/gpSFOBcpwKAqN9sUovT8ZycN7blZOEL5bLKM4P3JXWb+X 3NAX8J45TI3ao2J1jVoQD/6KosWqrGeJMeekm5FmKN0AhUxu8LSyWaMNwSVbv1ruUz11 t25w== MIME-Version: 1.0 Received: by 10.152.104.148 with SMTP id ge20mr31088111lab.51.1351632303677; Tue, 30 Oct 2012 14:25:03 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 30 Oct 2012 14:25:03 -0700 (PDT) In-Reply-To: <508FAABC.2000404@unina.it> References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> Date: Tue, 30 Oct 2012 16:25:03 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0407116953e1fe04cd4d6bb4 Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 21:25:07 -0000 --f46d0407116953e1fe04cd4d6bb4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this is a reasonable split and I don't think it's that much of a killer task to do so. We have talked in the past about whether we should split some material from the framework. I think doing so will make it easier for individuals to edit the various pieces. We will of course have to ensure consistency. However, this approach adds some good checks and balances, I believe. This model is quite similar to what worked very well for the XCON work and it's quite similar to what other WGs are doing (e.g., SIPREC). The chairs have delayed updating our milestones since we had not decided individual deliverables related to the solution. As chair I would like to gauge consensus on this approach. So, if people could please respond as to whether they support the general idea of splitting the work into the following documents/deliverables: 1) Framework 2) Data model 3) Protocol 4) Call Flows If we can get consensus on the basic idea, then we can work out the details starting with Simon's suggestion. I do have one comment about the "orchestration document" as I think that might be appropriate for the framework, but we could certainly work on that separately and decide later. Thanks, Mary. On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano wro= te: > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final section of the > data model, which provides 'one possible' example of how to formally > describe the things in the document); > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the > protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. > > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside the WG. I > would like it to represent an orchestration document, providing an overvi= ew > of issues, requirements, architecture and protocols. > A sort of summary reference for all of the related "drill-down" documents= , > each expanding on a specific WG item (data model, protocol, call flows, > etc.). > > I acknowledge the fact that this looks much like a revolution, but I > nonetheless believe that we already have most of the needed material at > hand and just need to better distribute it across the documents produced = by > the WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, >> >> When you say that you want to remove "all" the data model stuff from the >> framework can you be a bit more specific as to what parts you want remov= ed? >> >> Regards, Christian >> >> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >> >>> Hi all, >>> >>> just to be clear on the current structure of the data model schema: all >>> the things you find there were 'extracted' (by Roberta and me) from >>> information currently contained inside the framework draft (as well as = from >>> some side documents, associated with either the data model or the envis= aged >>> call flows). So, unless we have misinterpreted the above document(s) (w= hich >>> is obviously possible), we should first of all focus on the framework i= n >>> order to try and converge on an agreed-upon CLUE architecture. Once don= e >>> with this, we can fine-tune the data model. As I already stated on this >>> list, it is my personal opinion that we should remove from the framewor= k >>> document all of the data-model stuff that it currently contains, and ra= ther >>> focus on a clear definition of framework components and interfaces. I m= ight >>> look naif, but I would like to arrive at an 'ordinary' set of documents= : >>> (i) general framework; (ii) data model; (iii) clue protocol (with >>> advertisement and configuration messages); (iv) call flows (showing how= SDP >>> O/A and CLUE protocol messages concur in effectively setting up a CLUE >>> session). >>> >>> As to the 'UML vs XML' querelle, I would suggest that: >>> >>> 1. Both UML class diagrams and XML schema can be adopted for the >>> description of the data model, i.e., the STATIC part of the framework, >>> associated with the description of what some of you properly called a '= CLUE >>> instance'; >>> 2. UML sequence diagrams can be adopted to describe CLUE call flows, >>> i.e. the DYNAMIC part of the framework, which clearly envisages the >>> co-existence of SDP and CLUE protocol messages. XML schemas are not >>> suitable for this dynamic part. >>> >>> This said, it is clear that CLUE protocol messages (in particular, CLU= E >>> advertisements) will be constructed by leveraging information contained >>> inside a CLUE instance. Which parts of a CLUE instance should go into a= n >>> advertisement and which should be carried inside SDP can be a matter of >>> discussion. >>> >>> My 2 cents, >>> >>> Simon >>> >>> >>> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >>> >>> On 10/29/12 6:23 PM, Roni Even wrote: >>>> >>>>> Paul, >>>>> This was the statement I answered "no" >>>>> " The general agreement on the call is that the data model as >>>>> reflected in >>>>> draft-presta-clue-data-model-**schema describes the data needed by >>>>> the CLUE >>>>> application" >>>>> I disagree that it reflects that data needed by a CLUE application an= d >>>>> I >>>>> explained why. >>>>> >>>> >>>> OK, fair enough. >>>> >>>> Mary can comment, but my take was that the point of her question was t= o >>>> distinguish between two alternatives: >>>> - the data model represents all the data needed by the clue app. >>>> (which implies to me that it encompasses all the data in the >>>> framework.) >>>> - the data model represents the data to be exchanged in >>>> clue messages. >>>> >>>> It is a bigger deal if the framework includes things that are not >>>> needed by the clue application. I was of the impression that, except f= or >>>> some fine tuning, we were largely in agreement on the framework. >>>> >>>> If we don't have consensus on *that* then resolving that is of higher >>>> priority that much of the other stuff we are discussing. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto: >>>>> clue-bounces@ietf.org] On Behalf Of Paul >>>>> Kyzivat >>>>> Sent: 29 October, 2012 9:46 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Data model - agreement on objective and basic >>>>> approach >>>>> >>>>> On 10/29/12 3:19 PM, Roni Even wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> My view is 'no". I still fail to see the need for the encoding group= s >>>>>> and individual encodes. >>>>>> >>>>>> In the current definition of capture scene, I am not sure what is th= e >>>>>> meaning of different individual encodes and eventually the receiver >>>>>> can define what it can receive (Typically H.264 is symmetric in term= s >>>>>> of profile but does not need to be in the level) and can ask for >>>>>> specific resolution with the SDP image attribute >>>>>> >>>>> >>>>> ISTM that you are answering a different question than the one Mary >>>>> asked. >>>>> You seem to be saying that you disagree with the framework as it is - >>>>> that >>>>> it can/should be simpler. >>>>> >>>>> That is a separate question. If such changes were made it might affec= t >>>>> a >>>>> lot. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Roni Even >>>>>> >>>>>> *From:*clue-bounces@ietf.org [mailto: >>>>>> clue-bounces@ietf.org] *On Behalf >>>>>> Of *Mary Barnes >>>>>> *Sent:* 29 October, 2012 7:52 PM >>>>>> *To:* CLUE >>>>>> *Subject:* [clue] Data model - agreement on objective and basic >>>>>> approach >>>>>> >>>>>> On the call earlier today, we also discussed the data model. The >>>>>> general agreement on the call is that the data model as reflected in >>>>>> draft-presta-clue-data-model-**schema describes the data needed by >>>>>> the >>>>>> CLUE application - i.e., it's the CLUE instance concept. It does not >>>>>> directly reflect the contents of a CLUE message. The application da= ta >>>>>> would be used to populate CLUE messages, as well as SDP and would >>>>>> reflect updates based on both the CLUE and SDP signaling. >>>>>> >>>>>> If we can get agreement on that before the meeting, I believe our >>>>>> discussions can be much more productive. If folks could please reply >>>>>> "Yes" or "No" reflecting agreement with the above, that would be >>>>>> helpful. If you reply "No", please explain why. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Mary >>>>>> >>>>>> as CLUE WG co-chair >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> 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 >>>> >>>> >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Engineering Department >>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>> e-mail: spromano@unina.it >>> >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>> >>> >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> 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 >> >> > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/**simonpietro.romano > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > \_) ) / > (_/ > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --f46d0407116953e1fe04cd4d6bb4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think this is a reasonable split and I don't think it's that much= of a killer task to do so. =A0We have talked in the past about whether we = should split some material from the framework. =A0I think doing so will mak= e it easier for individuals to edit the various pieces. =A0We will of cours= e have to ensure consistency. =A0However, =A0this approach adds some good c= hecks and balances, I believe. =A0 This model is quite similar to what work= ed very well for the XCON work and it's quite similar to what other WGs= are doing (e.g., SIPREC). =A0

The chairs have delayed updating our milestones since we had= not decided individual deliverables related to the solution. =A0

As chair I would like to gauge consensus on this approach. = =A0So, if people could please respond as to whether they support the genera= l idea of splitting the work into the following documents/deliverables:
1) Framework
2) Data model
3) Protocol
4= ) Call Flows

If we can get consensus on the basic = idea, then we can work out the details starting with Simon's suggestion= .

I do have one comment about the "orchestration doc= ument" as I think that might be appropriate for the framework, but we = could certainly work on that separately and decide later.

Thanks,
Mary.=A0

On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano = <spromano@unina.i= t> wrote:
Hi Christian,

a rough estimation would be the following:

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the dat= a model, which provides 'one possible' example of how to formally d= escribe the things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protoc= ol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and enriched= ) in view of the proposed distribution of work inside the WG. I would like = it to represent an orchestration document, providing an overview of issues,= requirements, architecture and protocols.
=A0
A sort of summary reference fo= r all of the related "drill-down" documents, each expanding on a = specific WG item (data model, protocol, call flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I noneth= eless believe that we already have most of the needed material at hand and = just need to better distribute it across the documents produced by the WG.<= br>
Cheers,

Simon




Il 30/10/2012 10:33, Christian Groves ha scritto:
Hello Simon,

When you say that you want to remove "all" the data model stuff f= rom the framework can you be a bit more specific as to what parts you want = removed?

Regards, Christian

On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
Hi all,

just to be clear on the current structure of the data model schema: all the= things you find there were 'extracted' (by Roberta and me) from in= formation currently contained inside the framework draft (as well as from s= ome side documents, associated with either the data model or the envisaged = call flows). So, unless we have misinterpreted the above document(s) (which= is obviously possible), we should first of all focus on the framework in o= rder to try and converge on an agreed-upon CLUE architecture. Once done wit= h this, we can fine-tune the data model. As I already stated on this list, = it is my personal opinion that we should remove from the framework document= all of the data-model stuff that it currently contains, and rather focus o= n a clear definition of framework components and interfaces. I might look n= aif, but I would like to arrive at an 'ordinary' set of documents: = (i) =A0general framework; (ii) data model; (iii) clue protocol (with advert= isement and configuration messages); (iv) call flows (showing how SDP O/A a= nd CLUE protocol messages concur in effectively setting up a CLUE session).=

As to the 'UML vs XML' querelle, I would suggest that:

1. Both UML class diagrams and XML schema can be adopted for the descriptio= n of the data model, i.e., the STATIC part of the framework, associated wit= h the description of what some of you properly called a 'CLUE instance&= #39;;
2. UML sequence diagrams can be adopted to describe CLUE call flows, i.e. t= he DYNAMIC part of the framework, which clearly envisages the co-existence = of SDP and CLUE protocol messages. XML schemas are not suitable for this dy= namic part.

This said, it is clear that CLUE protocol messages =A0(in particular, CLUE = advertisements) will be constructed by leveraging information contained ins= ide a CLUE instance. Which parts of a CLUE instance should go into an adver= tisement and which should be carried inside SDP can be a matter of discussi= on.

My 2 cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto:

On 10/29/12 6:23 PM, Roni Even wrote:
Paul,
This was the statement I answered "no"
" The general agreement on the call is that the data model as reflecte= d in
draft-presta-clue-data-model-schema describes the data needed by the= CLUE
application"
I disagree that it reflects that data needed by a CLUE application and I explained why.

OK, fair enough.

Mary can comment, but my take was that the point of her question was to dis= tinguish between two alternatives:
- the data model represents all the data needed by the clue app.
=A0(which implies to me that it encompasses all the data in the
=A0framework.)
- the data model represents the data to be exchanged in
=A0clue messages.

It is a bigger deal if the framework includes things that are not needed by= the clue application. I was of the impression that, except for some fine t= uning, we were largely in agreement on the framework.

If we don't have consensus on *that* then resolving that is of higher p= riority that much of the other stuff we are discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounc= es@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] On Behalf Of P= aul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: clue@ietf.org &l= t;mailto:clue@ietf.org>
Subject: Re: [clue] Data model - agreement on objective and basic approach<= br>
On 10/29/12 3:19 PM, Roni Even wrote:
Hi,

My view is 'no". I still fail to see the need for the encoding gro= ups
and individual encodes.

In the current definition of capture scene, I am not sure what is the
meaning of different individual encodes and eventually the receiver
can define what it can receive (Typically H.264 is symmetric in terms
of profile but does not need to be in the level) and can ask for
specific resolution with the SDP image attribute

ISTM that you are answering a different question than the one Mary asked. You seem to be saying that you disagree with the framework as it is - that<= br> it can/should be simpler.

That is a separate question. If such changes were made it might affect a lot.

Thanks,
Paul

Roni Even

*From:*clue-boun= ces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] *On Behalf
Of *Mary Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* [clue] Data model - agreement on objective and basic
approach

On the call earlier today, we also discussed the data model. =A0The
general agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the=
CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. =A0The application data would be used to populate CLUE messages, as well as SDP and would
reflect updates based on both the CLUE and SDP signaling.

If we can get agreement on that before the meeting, I believe our
discussions can be much more productive. If folks could please reply
"Yes" or "No" reflecting agreement with the above, that= would be
helpful. =A0If you reply "No", please explain why.

Regards,

Mary

as CLUE WG co-chair



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_\\|//_
=A0 =A0 =A0 ( O-O )
=A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
Simon Pietro Romano
Universita' di Napoli Federico II
=A0Computer Engineering Department
=A0 Phone: +39 081 7683823 -- Fax: +39 081 7683816
=A0e-mail: spromano@= unina.it <mailto:spromano@unina.it>

<<Molti mi dicono che lo scoraggiamento =CB l'alibi degli
=A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0\ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 =A0 =A0 =A0 =A0) /<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(_/







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

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


--
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _\\|//_
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( O-O )
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Simon Pietro Romano
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Universita' di Napoli Federico II
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Computer Science Department
=A0 =A0 =A0 =A0 Phone: +39 081 7683823 -- Fax: +39 081 768421= 9
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 e-mail: spromano@unina.it
=A0 =A0 =A0 =A0 =A0 http://www.comics.unina.it/simonpietro.romano


=A0 =A0 <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=
=A0 =A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

--f46d0407116953e1fe04cd4d6bb4-- From mary.ietf.barnes@gmail.com Tue Oct 30 14:41:46 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 53A1E21F85E6 for ; Tue, 30 Oct 2012 14:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.538 X-Spam-Level: X-Spam-Status: No, score=-102.538 tagged_above=-999 required=5 tests=[AWL=-0.606, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZI5JJRHI1hV for ; Tue, 30 Oct 2012 14:41:44 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 727C121F85DB for ; Tue, 30 Oct 2012 14:41:43 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so633839lbo.31 for ; Tue, 30 Oct 2012 14:41:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=GSetLr6hgSrdtKDU+psZeGh5IlYdB+R8AHobSCNS4Lw=; b=0hL/EEmc4ifw2rxLUjJWWQxuJFvkGSJpKHwqgVu7sMDIcNZNoJRQtAdHEc5VVUnhN8 9mgXI5C2QfUjQ1+mspenjape8F/Rld7E/Nhh5vvkwyULeMHQdSqcS/UwjNLFugAvkw2G YVXa6PNUAKiDlAEXeMTe3ZRmjJ/CDeZNUhApUPkQnbysUFuB4UPBZhIVOnP8IGA1w4lp h6u43XYXkCT7QBhcRKF+2ZkMsjwo8OZdpKncgwHI/0tr5oJwLHBpfjA0T2cmI2cBtBOX Qzt/+zHfwbqKIfGYlUUJKT0j5KOuW+JW9VJ3YuYIeZqtEBNWurnjzbjiL48LkcTy7vMU Xwkw== MIME-Version: 1.0 Received: by 10.112.38.163 with SMTP id h3mr7327217lbk.134.1351633302207; Tue, 30 Oct 2012 14:41:42 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 30 Oct 2012 14:41:42 -0700 (PDT) Date: Tue, 30 Oct 2012 16:41:42 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=e0cb4efe2a7ad83bf604cd4da659 Subject: [clue] Consensus Call: WG deliverables - splitting some material from framework document. 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, 30 Oct 2012 21:41:46 -0000 --e0cb4efe2a7ad83bf604cd4da659 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should have changed the title since this discussion has morphed into a more general discussion of WG deliverables. Please see the proposal below and respond as to whether you agree with the discrete deliverables as listed. If you don't agree, please explain why. Please note we're not discussing details - we just want to know if folks agree with the division of work. Thanks, Mary. ---------- Forwarded message ---------- From: Mary Barnes Date: Tue, Oct 30, 2012 at 4:25 PM Subject: Re: [clue] Data model - agreement on objective and basic approach To: CLUE Cc: Christian Groves , Simon Pietro Romano < spromano@unina.it>, Paul Kyzivat I think this is a reasonable split and I don't think it's that much of a killer task to do so. We have talked in the past about whether we should split some material from the framework. I think doing so will make it easier for individuals to edit the various pieces. We will of course have to ensure consistency. However, this approach adds some good checks and balances, I believe. This model is quite similar to what worked very well for the XCON work and it's quite similar to what other WGs are doing (e.g., SIPREC). The chairs have delayed updating our milestones since we had not decided individual deliverables related to the solution. As chair I would like to gauge consensus on this approach. So, if people could please respond as to whether they support the general idea of splitting the work into the following documents/deliverables: 1) Framework 2) Data model 3) Protocol 4) Call Flows If we can get consensus on the basic idea, then we can work out the details starting with Simon's suggestion. I do have one comment about the "orchestration document" as I think that might be appropriate for the framework, but we could certainly work on that separately and decide later. Thanks, Mary. On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano wro= te: > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final section of the > data model, which provides 'one possible' example of how to formally > describe the things in the document); > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the > protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. > > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside the WG. I > would like it to represent an orchestration document, providing an overvi= ew > of issues, requirements, architecture and protocols. > A sort of summary reference for all of the related "drill-down" documents= , > each expanding on a specific WG item (data model, protocol, call flows, > etc.). > > I acknowledge the fact that this looks much like a revolution, but I > nonetheless believe that we already have most of the needed material at > hand and just need to better distribute it across the documents produced = by > the WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, >> >> When you say that you want to remove "all" the data model stuff from the >> framework can you be a bit more specific as to what parts you want remov= ed? >> >> Regards, Christian >> >> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >> >>> Hi all, >>> >>> just to be clear on the current structure of the data model schema: all >>> the things you find there were 'extracted' (by Roberta and me) from >>> information currently contained inside the framework draft (as well as = from >>> some side documents, associated with either the data model or the envis= aged >>> call flows). So, unless we have misinterpreted the above document(s) (w= hich >>> is obviously possible), we should first of all focus on the framework i= n >>> order to try and converge on an agreed-upon CLUE architecture. Once don= e >>> with this, we can fine-tune the data model. As I already stated on this >>> list, it is my personal opinion that we should remove from the framewor= k >>> document all of the data-model stuff that it currently contains, and ra= ther >>> focus on a clear definition of framework components and interfaces. I m= ight >>> look naif, but I would like to arrive at an 'ordinary' set of documents= : >>> (i) general framework; (ii) data model; (iii) clue protocol (with >>> advertisement and configuration messages); (iv) call flows (showing how= SDP >>> O/A and CLUE protocol messages concur in effectively setting up a CLUE >>> session). >>> >>> As to the 'UML vs XML' querelle, I would suggest that: >>> >>> 1. Both UML class diagrams and XML schema can be adopted for the >>> description of the data model, i.e., the STATIC part of the framework, >>> associated with the description of what some of you properly called a '= CLUE >>> instance'; >>> 2. UML sequence diagrams can be adopted to describe CLUE call flows, >>> i.e. the DYNAMIC part of the framework, which clearly envisages the >>> co-existence of SDP and CLUE protocol messages. XML schemas are not >>> suitable for this dynamic part. >>> >>> This said, it is clear that CLUE protocol messages (in particular, CLU= E >>> advertisements) will be constructed by leveraging information contained >>> inside a CLUE instance. Which parts of a CLUE instance should go into a= n >>> advertisement and which should be carried inside SDP can be a matter of >>> discussion. >>> >>> My 2 cents, >>> >>> Simon >>> >>> >>> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >>> >>> On 10/29/12 6:23 PM, Roni Even wrote: >>>> >>>>> Paul, >>>>> This was the statement I answered "no" >>>>> " The general agreement on the call is that the data model as >>>>> reflected in >>>>> draft-presta-clue-data-model-**schema describes the data needed by >>>>> the CLUE >>>>> application" >>>>> I disagree that it reflects that data needed by a CLUE application an= d >>>>> I >>>>> explained why. >>>>> >>>> >>>> OK, fair enough. >>>> >>>> Mary can comment, but my take was that the point of her question was t= o >>>> distinguish between two alternatives: >>>> - the data model represents all the data needed by the clue app. >>>> (which implies to me that it encompasses all the data in the >>>> framework.) >>>> - the data model represents the data to be exchanged in >>>> clue messages. >>>> >>>> It is a bigger deal if the framework includes things that are not >>>> needed by the clue application. I was of the impression that, except f= or >>>> some fine tuning, we were largely in agreement on the framework. >>>> >>>> If we don't have consensus on *that* then resolving that is of higher >>>> priority that much of the other stuff we are discussing. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Roni >>>>> >>>>> -----Original Message----- >>>>> From: clue-bounces@ietf.org [mailto: >>>>> clue-bounces@ietf.org] On Behalf Of Paul >>>>> Kyzivat >>>>> Sent: 29 October, 2012 9:46 PM >>>>> To: clue@ietf.org >>>>> Subject: Re: [clue] Data model - agreement on objective and basic >>>>> approach >>>>> >>>>> On 10/29/12 3:19 PM, Roni Even wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> My view is 'no". I still fail to see the need for the encoding group= s >>>>>> and individual encodes. >>>>>> >>>>>> In the current definition of capture scene, I am not sure what is th= e >>>>>> meaning of different individual encodes and eventually the receiver >>>>>> can define what it can receive (Typically H.264 is symmetric in term= s >>>>>> of profile but does not need to be in the level) and can ask for >>>>>> specific resolution with the SDP image attribute >>>>>> >>>>> >>>>> ISTM that you are answering a different question than the one Mary >>>>> asked. >>>>> You seem to be saying that you disagree with the framework as it is - >>>>> that >>>>> it can/should be simpler. >>>>> >>>>> That is a separate question. If such changes were made it might affec= t >>>>> a >>>>> lot. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Roni Even >>>>>> >>>>>> *From:*clue-bounces@ietf.org [mailto: >>>>>> clue-bounces@ietf.org] *On Behalf >>>>>> Of *Mary Barnes >>>>>> *Sent:* 29 October, 2012 7:52 PM >>>>>> *To:* CLUE >>>>>> *Subject:* [clue] Data model - agreement on objective and basic >>>>>> approach >>>>>> >>>>>> On the call earlier today, we also discussed the data model. The >>>>>> general agreement on the call is that the data model as reflected in >>>>>> draft-presta-clue-data-model-**schema describes the data needed by >>>>>> the >>>>>> CLUE application - i.e., it's the CLUE instance concept. It does not >>>>>> directly reflect the contents of a CLUE message. The application da= ta >>>>>> would be used to populate CLUE messages, as well as SDP and would >>>>>> reflect updates based on both the CLUE and SDP signaling. >>>>>> >>>>>> If we can get agreement on that before the meeting, I believe our >>>>>> discussions can be much more productive. If folks could please reply >>>>>> "Yes" or "No" reflecting agreement with the above, that would be >>>>>> helpful. If you reply "No", please explain why. >>>>>> >>>>>> Regards, >>>>>> >>>>>> Mary >>>>>> >>>>>> as CLUE WG co-chair >>>>>> >>>>>> >>>>>> >>>>>> ______________________________**_________________ >>>>>> 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 >>>> >>>> >>> _\\|//_ >>> ( O-O ) >>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>> Simon Pietro Romano >>> Universita' di Napoli Federico II >>> Computer Engineering Department >>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>> e-mail: spromano@unina.it >>> >>> <>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>> oooO >>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>> \ ( ( ) >>> \_) ) / >>> (_/ >>> >>> >>> >>> >>> >>> >>> >>> ______________________________**_________________ >>> 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 >> >> > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/**simonpietro.romano > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > \ ( ( ) > \_) ) / > (_/ > > ______________________________**_________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/**listinfo/clue > --e0cb4efe2a7ad83bf604cd4da659 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I should have changed the title since this discussion has morphed into a mo= re general discussion of WG deliverables. =A0Please see the proposal below = and respond as to whether you agree with the discrete deliverables as liste= d. =A0If you don't agree, please explain why. =A0Please note we're = not discussing details - we just want to know if folks agree with the divis= ion of work.=A0

Thanks,
Mary.=A0

---------- Forwarded message ----------
From: Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Tue, Oct 30, 2012 at 4:25 PM
Subject: Re: [clue] Data model - agre= ement on objective and basic approach
To: CLUE <clue@ietf.org>
Cc: Christian Groves <Christian.Groves@nteczone.com>, = Simon Pietro Romano <spromano@unina= .it>, Paul Kyzivat <pkyz= ivat@alum.mit.edu>


I think this is a reasonable split and I don't think it's t= hat much of a killer task to do so. =A0We have talked in the past about whe= ther we should split some material from the framework. =A0I think doing so = will make it easier for individuals to edit the various pieces. =A0We will = of course have to ensure consistency. =A0However, =A0this approach adds som= e good checks and balances, I believe. =A0 This model is quite similar to w= hat worked very well for the XCON work and it's quite similar to what o= ther WGs are doing (e.g., SIPREC). =A0

The chairs have delayed updating our milestones since we had= not decided individual deliverables related to the solution. =A0

As chair I would like to gauge consensus on this approach. = =A0So, if people could please respond as to whether they support the genera= l idea of splitting the work into the following documents/deliverables:
1) Framework
2) Data model
3) Protocol
4= ) Call Flows

If we can get consensus on the basic = idea, then we can work out the details starting with Simon's suggestion= .

I do have one comment about the "orchestration doc= ument" as I think that might be appropriate for the framework, but we = could certainly work on that separately and decide later.

Thanks,
Mary.=A0

On Tue, Oct 30, 2012 at 5:23 AM= , Simon Pietro Romano <spromano@unina.it> wrote:
Hi Christian,

a rough estimation would be the following:

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the dat= a model, which provides 'one possible' example of how to formally d= escribe the things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protoc= ol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and enriched= ) in view of the proposed distribution of work inside the WG. I would like = it to represent an orchestration document, providing an overview of issues,= requirements, architecture and protocols.
=A0
A sort of summary reference fo= r all of the related "drill-down" documents, each expanding on a = specific WG item (data model, protocol, call flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I noneth= eless believe that we already have most of the needed material at hand and = just need to better distribute it across the documents produced by the WG.<= br>
Cheers,

Simon




Il 30/10/2012 10:33, Christian Groves ha scritto:

Hello Simon,

When you say that you want to remove "all" the data model stuff f= rom the framework can you be a bit more specific as to what parts you want = removed?

Regards, Christian

On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
Hi all,

just to be clear on the current structure of the data model schema: all the= things you find there were 'extracted' (by Roberta and me) from in= formation currently contained inside the framework draft (as well as from s= ome side documents, associated with either the data model or the envisaged = call flows). So, unless we have misinterpreted the above document(s) (which= is obviously possible), we should first of all focus on the framework in o= rder to try and converge on an agreed-upon CLUE architecture. Once done wit= h this, we can fine-tune the data model. As I already stated on this list, = it is my personal opinion that we should remove from the framework document= all of the data-model stuff that it currently contains, and rather focus o= n a clear definition of framework components and interfaces. I might look n= aif, but I would like to arrive at an 'ordinary' set of documents: = (i) =A0general framework; (ii) data model; (iii) clue protocol (with advert= isement and configuration messages); (iv) call flows (showing how SDP O/A a= nd CLUE protocol messages concur in effectively setting up a CLUE session).=

As to the 'UML vs XML' querelle, I would suggest that:

1. Both UML class diagrams and XML schema can be adopted for the descriptio= n of the data model, i.e., the STATIC part of the framework, associated wit= h the description of what some of you properly called a 'CLUE instance&= #39;;
2. UML sequence diagrams can be adopted to describe CLUE call flows, i.e. t= he DYNAMIC part of the framework, which clearly envisages the co-existence = of SDP and CLUE protocol messages. XML schemas are not suitable for this dy= namic part.

This said, it is clear that CLUE protocol messages =A0(in particular, CLUE = advertisements) will be constructed by leveraging information contained ins= ide a CLUE instance. Which parts of a CLUE instance should go into an adver= tisement and which should be carried inside SDP can be a matter of discussi= on.

My 2 cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto:

On 10/29/12 6:23 PM, Roni Even wrote:
Paul,
This was the statement I answered "no"
" The general agreement on the call is that the data model as reflecte= d in
draft-presta-clue-data-model-schema describes the data needed by the= CLUE
application"
I disagree that it reflects that data needed by a CLUE application and I explained why.

OK, fair enough.

Mary can comment, but my take was that the point of her question was to dis= tinguish between two alternatives:
- the data model represents all the data needed by the clue app.
=A0(which implies to me that it encompasses all the data in the
=A0framework.)
- the data model represents the data to be exchanged in
=A0clue messages.

It is a bigger deal if the framework includes things that are not needed by= the clue application. I was of the impression that, except for some fine t= uning, we were largely in agreement on the framework.

If we don't have consensus on *that* then resolving that is of higher p= riority that much of the other stuff we are discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounc= es@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] On Behalf Of P= aul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: clue@ietf.org &l= t;mailto:clue@ietf.org>
Subject: Re: [clue] Data model - agreement on objective and basic approach<= br>
On 10/29/12 3:19 PM, Roni Even wrote:
Hi,

My view is 'no". I still fail to see the need for the encoding gro= ups
and individual encodes.

In the current definition of capture scene, I am not sure what is the
meaning of different individual encodes and eventually the receiver
can define what it can receive (Typically H.264 is symmetric in terms
of profile but does not need to be in the level) and can ask for
specific resolution with the SDP image attribute

ISTM that you are answering a different question than the one Mary asked. You seem to be saying that you disagree with the framework as it is - that<= br> it can/should be simpler.

That is a separate question. If such changes were made it might affect a lot.

Thanks,
Paul

Roni Even

*From:*clue-boun= ces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] *On Behalf
Of *Mary Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* [clue] Data model - agreement on objective and basic
approach

On the call earlier today, we also discussed the data model. =A0The
general agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the=
CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. =A0The application data would be used to populate CLUE messages, as well as SDP and would
reflect updates based on both the CLUE and SDP signaling.

If we can get agreement on that before the meeting, I believe our
discussions can be much more productive. If folks could please reply
"Yes" or "No" reflecting agreement with the above, that= would be
helpful. =A0If you reply "No", please explain why.

Regards,

Mary

as CLUE WG co-chair



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_\\|//_
=A0 =A0 =A0 ( O-O )
=A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
Simon Pietro Romano
Universita' di Napoli Federico II
=A0Computer Engineering Department
=A0 Phone: +39 081 7683823 -- Fax: +39 081 7683816
=A0e-mail: spromano@= unina.it <mailto:spromano@unina.it>

<<Molti mi dicono che lo scoraggiamento =CB l'alibi degli
=A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0\ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 =A0 =A0 =A0 =A0) /<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(_/







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

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


--
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _\\|//_
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( O-O )
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Simon Pietro Romano
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Universita' di Napoli Federico II
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Computer Science Department
=A0 =A0 =A0 =A0 Phone: +39 081 7683823 -- Fax: +39 081 768421= 9
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 e-mail: spromano@unina.it
=A0 =A0 =A0 =A0 =A0 http://www.comics.unina.it/simonpietro.romano


=A0 =A0 <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=
=A0 =A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~


--e0cb4efe2a7ad83bf604cd4da659-- From roni.even@mail01.huawei.com Tue Oct 30 14:43:48 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F184121F85DB for ; Tue, 30 Oct 2012 14:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.172 X-Spam-Level: * X-Spam-Status: No, score=1.172 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbaNBD3zNuWh for ; Tue, 30 Oct 2012 14:43:46 -0700 (PDT) Received: from hwsga02-in.huaweimarine.com (unknown [119.145.15.224]) by ietfa.amsl.com (Postfix) with ESMTP id 7B29021F8459 for ; Tue, 30 Oct 2012 14:43:45 -0700 (PDT) Received: from szxpml203-edg.exmail.huawei.com ([172.17.1.119]) by hwsga02-in.huaweimarine.com (MOS 4.1.3-GA) with ESMTP id ADX61975; Wed, 31 Oct 2012 05:42:51 +0800 X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none X-Mirapoint-Received-SPF: 172.17.1.119 szxpml203-edg.exmail.huawei.com 5 none Received: from SZXPML404-HUB.exmail.huawei.com (10.82.67.165) by szxpml203-edg.exmail.huawei.com (172.24.2.14) with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 31 Oct 2012 05:42:45 +0800 Received: from SZXPML504-MBS.exmail.huawei.com ([169.254.4.23]) by szxpml404-hub.exmail.huawei.com ([10.82.67.165]) with mapi id 14.01.0323.003; Wed, 31 Oct 2012 05:42:50 +0800 From: Roni Even To: Mary Barnes , CLUE Thread-Topic: [clue] Data model - agreement on objective and basic approach Thread-Index: AQHNtf4mdZQDnZnBTkiYXkU8oD1gV5fQInSAgAAHaYCAACwDAIAACoCAgACXfACAABljAIAADf0AgAC4t4CAAIquYw== Date: Tue, 30 Oct 2012 21:42:49 +0000 Message-ID: <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it>, In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.24.1.63] Content-Type: multipart/alternative; boundary="_000_760B7D45D1EFF74988DBF5C2122830C205B6195Bszxpml504mbsexm_" MIME-Version: 1.0 Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 21:43:48 -0000 --_000_760B7D45D1EFF74988DBF5C2122830C205B6195Bszxpml504mbsexm_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Mary, What about the mapping of RTP streams to Media Captures, where does it fall BTW: the mapping may require an identfier for the media capture Roni ________________________________ From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barne= s [mary.ietf.barnes@gmail.com] Sent: Tuesday, October 30, 2012 11:25 PM To: CLUE Subject: Re: [clue] Data model - agreement on objective and basic approach I think this is a reasonable split and I don't think it's that much of a ki= ller task to do so. We have talked in the past about whether we should spl= it some material from the framework. I think doing so will make it easier = for individuals to edit the various pieces. We will of course have to ensu= re consistency. However, this approach adds some good checks and balances= , I believe. This model is quite similar to what worked very well for the= XCON work and it's quite similar to what other WGs are doing (e.g., SIPREC= ). The chairs have delayed updating our milestones since we had not decided in= dividual deliverables related to the solution. As chair I would like to gauge consensus on this approach. So, if people c= ould please respond as to whether they support the general idea of splittin= g the work into the following documents/deliverables: 1) Framework 2) Data model 3) Protocol 4) Call Flows If we can get consensus on the basic idea, then we can work out the details= starting with Simon's suggestion. I do have one comment about the "orchestration document" as I think that mi= ght be appropriate for the framework, but we could certainly work on that s= eparately and decide later. Thanks, Mary. On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano > wrote: Hi Christian, a rough estimation would be the following: a) keep sections 1 through 4 inside the framework document; b) move sections 5 through 8 to the data model document c) move the XML schema to the data model document (final section of the dat= a model, which provides 'one possible' example of how to formally describe = the things in the document); d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protoc= ol document; e) move subsection 9.4 to the call flows document; f) move section 10 to the data model document; g) move section 11 to the call flows document. Obviously, the resulting framework document should be revised (and enriched= ) in view of the proposed distribution of work inside the WG. I would like = it to represent an orchestration document, providing an overview of issues,= requirements, architecture and protocols. A sort of summary reference for all of the related "drill-down" documents, = each expanding on a specific WG item (data model, protocol, call flows, etc= .). I acknowledge the fact that this looks much like a revolution, but I noneth= eless believe that we already have most of the needed material at hand and = just need to better distribute it across the documents produced by the WG. Cheers, Simon Il 30/10/2012 10:33, Christian Groves ha scritto: Hello Simon, When you say that you want to remove "all" the data model stuff from the fr= amework can you be a bit more specific as to what parts you want removed? Regards, Christian On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: Hi all, just to be clear on the current structure of the data model schema: all the= things you find there were 'extracted' (by Roberta and me) from informatio= n currently contained inside the framework draft (as well as from some side= documents, associated with either the data model or the envisaged call flo= ws). So, unless we have misinterpreted the above document(s) (which is obvi= ously possible), we should first of all focus on the framework in order to = try and converge on an agreed-upon CLUE architecture. Once done with this, = we can fine-tune the data model. As I already stated on this list, it is my= personal opinion that we should remove from the framework document all of = the data-model stuff that it currently contains, and rather focus on a clea= r definition of framework components and interfaces. I might look naif, but= I would like to arrive at an 'ordinary' set of documents: (i) general fra= mework; (ii) data model; (iii) clue protocol (with advertisement and config= uration messages); (iv) call flows (showing how SDP O/A and CLUE protocol m= essages concur in effectively setting up a CLUE session). As to the 'UML vs XML' querelle, I would suggest that: 1. Both UML class diagrams and XML schema can be adopted for the descriptio= n of the data model, i.e., the STATIC part of the framework, associated wit= h the description of what some of you properly called a 'CLUE instance'; 2. UML sequence diagrams can be adopted to describe CLUE call flows, i.e. t= he DYNAMIC part of the framework, which clearly envisages the co-existence = of SDP and CLUE protocol messages. XML schemas are not suitable for this dy= namic part. This said, it is clear that CLUE protocol messages (in particular, CLUE ad= vertisements) will be constructed by leveraging information contained insid= e a CLUE instance. Which parts of a CLUE instance should go into an adverti= sement and which should be carried inside SDP can be a matter of discussion= . My 2 cents, Simon Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: On 10/29/12 6:23 PM, Roni Even wrote: Paul, This was the statement I answered "no" " The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application" I disagree that it reflects that data needed by a CLUE application and I explained why. OK, fair enough. Mary can comment, but my take was that the point of her question was to dis= tinguish between two alternatives: - the data model represents all the data needed by the clue app. (which implies to me that it encompasses all the data in the framework.) - the data model represents the data to be exchanged in clue messages. It is a bigger deal if the framework includes things that are not needed by= the clue application. I was of the impression that, except for some fine t= uning, we were largely in agreement on the framework. If we don't have consensus on *that* then resolving that is of higher prior= ity that much of the other stuff we are discussing. Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29 October, 2012 9:46 PM To: clue@ietf.org > Subject: Re: [clue] Data model - agreement on objective and basic approach On 10/29/12 3:19 PM, Roni Even wrote: Hi, My view is 'no". I still fail to see the need for the encoding groups and individual encodes. In the current definition of capture scene, I am not sure what is the meaning of different individual encodes and eventually the receiver can define what it can receive (Typically H.264 is symmetric in terms of profile but does not need to be in the level) and can ask for specific resolution with the SDP image attribute ISTM that you are answering a different question than the one Mary asked. You seem to be saying that you disagree with the framework as it is - that it can/should be simpler. That is a separate question. If such changes were made it might affect a lot. Thanks, Paul Roni Even *From:*clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org<= mailto:clue-bounces@ietf.org>] *On Behalf Of *Mary Barnes *Sent:* 29 October, 2012 7:52 PM *To:* CLUE *Subject:* [clue] Data model - agreement on objective and basic approach On the call earlier today, we also discussed the data model. The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. The application data would be used to populate CLUE messages, as well as SDP and would reflect updates based on both the CLUE and SDP signaling. If we can get agreement on that before the meeting, I believe our discussions can be much more productive. If folks could please reply "Yes" or "No" reflecting agreement with the above, that would be helpful. If you reply "No", please explain why. Regards, Mary as CLUE WG co-chair _______________________________________________ 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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816= e-mail: spromano@unina.it > <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ 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 -- _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7= 684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --_000_760B7D45D1EFF74988DBF5C2122830C205B6195Bszxpml504mbsexm_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Mary,

What about the mapping of RTP streams to Media Captures, where does it f= all

BTW: the mapping may require an identfier for the media capture

 

Roni

From: clue-bounces@ietf.org [clue-bounces@= ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]
Sent: Tuesday, October 30, 2012 11:25 PM
To: CLUE
Subject: Re: [clue] Data model - agreement on objective and basic ap= proach

I think this is a reasonable split and I don't think it's that much of= a killer task to do so.  We have talked in the past about whether we = should split some material from the framework.  I think doing so will = make it easier for individuals to edit the various pieces.  We will of course have to ensure consistency.  = However,  this approach adds some good checks and balances, I believe.=   This model is quite similar to what worked very well for the XCON w= ork and it's quite similar to what other WGs are doing (e.g., SIPREC).  

The chairs have delayed updating our milestones since we had not decid= ed individual deliverables related to the solution.  

As chair I would like to gauge consensus on this approach.  So, i= f people could please respond as to whether they support the general idea o= f splitting the work into the following documents/deliverables:
1) Framework
2) Data model
3) Protocol
4) Call Flows

If we can get consensus on the basic idea, then we can work out the de= tails starting with Simon's suggestion.

I do have one comment about the "orchestration document" as = I think that might be appropriate for the framework, but we could certainly= work on that separately and decide later.

Thanks,
Mary. 

On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Ro= mano <spromano@unina.i= t> wrote:
Hi Christian,

a rough estimation would be the following:

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the dat= a model, which provides 'one possible' example of how to formally describe = the things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protoc= ol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and enriched= ) in view of the proposed distribution of work inside the WG. I would like = it to represent an orchestration document, providing an overview of issues,= requirements, architecture and protocols.
 
A sort of summary reference for all of the related "drill-down" d= ocuments, each expanding on a specific WG item (data model, protocol, call = flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I noneth= eless believe that we already have most of the needed material at hand and = just need to better distribute it across the documents produced by the WG.<= br>
Cheers,

Simon




Il 30/10/2012 10:33, Christian Groves ha scritto:

Hello Simon,

When you say that you want to remove "all" the data model stuff f= rom the framework can you be a bit more specific as to what parts you want = removed?

Regards, Christian

On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
Hi all,

just to be clear on the current structure of the data model schema: all the= things you find there were 'extracted' (by Roberta and me) from informatio= n currently contained inside the framework draft (as well as from some side= documents, associated with either the data model or the envisaged call flows). So, unless we have misinterpr= eted the above document(s) (which is obviously possible), we should first o= f all focus on the framework in order to try and converge on an agreed-upon= CLUE architecture. Once done with this, we can fine-tune the data model. As I already stated on this list, i= t is my personal opinion that we should remove from the framework document = all of the data-model stuff that it currently contains, and rather focus on= a clear definition of framework components and interfaces. I might look naif, but I would like to arrive a= t an 'ordinary' set of documents: (i)  general framework; (ii) data mo= del; (iii) clue protocol (with advertisement and configuration messages); (= iv) call flows (showing how SDP O/A and CLUE protocol messages concur in effectively setting up a CLUE session).
As to the 'UML vs XML' querelle, I would suggest that:

1. Both UML class diagrams and XML schema can be adopted for the descriptio= n of the data model, i.e., the STATIC part of the framework, associated wit= h the description of what some of you properly called a 'CLUE instance'; 2. UML sequence diagrams can be adopted to describe CLUE call flows, i.e. t= he DYNAMIC part of the framework, which clearly envisages the co-existence = of SDP and CLUE protocol messages. XML schemas are not suitable for this dy= namic part.

This said, it is clear that CLUE protocol messages  (in particular, CL= UE advertisements) will be constructed by leveraging information contained = inside a CLUE instance. Which parts of a CLUE instance should go into an ad= vertisement and which should be carried inside SDP can be a matter of discussion.

My 2 cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto:

On 10/29/12 6:23 PM, Roni Even wrote:
Paul,
This was the statement I answered "no"
" The general agreement on the call is that the data model as reflecte= d in
draft-presta-clue-data-model-schema describes the data needed by the= CLUE
application"
I disagree that it reflects that data needed by a CLUE application and I explained why.

OK, fair enough.

Mary can comment, but my take was that the point of her question was to dis= tinguish between two alternatives:
- the data model represents all the data needed by the clue app.
 (which implies to me that it encompasses all the data in the
 framework.)
- the data model represents the data to be exchanged in
 clue messages.

It is a bigger deal if the framework includes things that are not needed by= the clue application. I was of the impression that, except for some fine t= uning, we were largely in agreement on the framework.

If we don't have consensus on *that* then resolving that is of higher prior= ity that much of the other stuff we are discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounc= es@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] On Behalf Of Paul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: clue@ietf.org &l= t;mailto:clue@ietf.org>
Subject: Re: [clue] Data model - agreement on objective and basic approach<= br>
On 10/29/12 3:19 PM, Roni Even wrote:
Hi,

My view is 'no". I still fail to see the need for the encoding groups<= br> and individual encodes.

In the current definition of capture scene, I am not sure what is the
meaning of different individual encodes and eventually the receiver
can define what it can receive (Typically H.264 is symmetric in terms
of profile but does not need to be in the level) and can ask for
specific resolution with the SDP image attribute

ISTM that you are answering a different question than the one Mary asked. You seem to be saying that you disagree with the framework as it is - that<= br> it can/should be simpler.

That is a separate question. If such changes were made it might affect a lot.

Thanks,
Paul

Roni Even

*From:*clue-boun= ces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] *On Behalf
Of *Mary Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* [clue] Data model - agreement on objective and basic
approach

On the call earlier today, we also discussed the data model.  The
general agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the=
CLUE application - i.e., it's the CLUE instance concept. It does not
directly reflect the contents of a CLUE message.  The application data=
would be used to populate CLUE messages, as well as SDP and would
reflect updates based on both the CLUE and SDP signaling.

If we can get agreement on that before the meeting, I believe our
discussions can be much more productive. If folks could please reply
"Yes" or "No" reflecting agreement with the above, that= would be
helpful.  If you reply "No", please explain why.

Regards,

Mary

as CLUE WG co-chair



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_\\|//_
      ( O-O )
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano
Universita' di Napoli Federico II
 Computer Engineering Department
  Phone: +39 081 7683823 -- Fax: +39 081 7683816
 e-mail: sproma= no@unina.it <mailto:spromano@unina.it>

<<Molti mi dicono che lo scoraggiamento =CB l'alibi degli
 idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                     = ;oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
       \ (            ( &= nbsp; )
                     = ;   \_)          ) /
                     = ;    (_/







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

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


--
                &= nbsp;           _\\|//_
                     = ;       ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~= ~~~~
                    Simon= Pietro Romano
              Universita' di Napoli Fede= rico II
                 Computer Scie= nce Department
        Phone: +39 081 7683823 -- Fax: +39 081 7684219
                e-mail: spromano@unina.it
          http://www.comics.unina.it/simonpietro.romano


    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi deg= li
   idioti. Ci rifletto un istante; e mi scoraggio>>. Magrit= te.
                     = ;    oooO
   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~= ~~

                     = ;     \ (    (   )
                     = ;      \_)    ) /
                     = ;            (_/

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

--_000_760B7D45D1EFF74988DBF5C2122830C205B6195Bszxpml504mbsexm_-- From mary.ietf.barnes@gmail.com Tue Oct 30 14:44:56 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD60621F85DB for ; Tue, 30 Oct 2012 14:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.27 X-Spam-Level: X-Spam-Status: No, score=-103.27 tagged_above=-999 required=5 tests=[AWL=0.328, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXpSrr1T0duM for ; Tue, 30 Oct 2012 14:44:56 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4F1E521F8459 for ; Tue, 30 Oct 2012 14:44:55 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so618281lam.31 for ; Tue, 30 Oct 2012 14:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JohJEw8JvAZSIytd2LXDdV47jXn5mClHW/Y2aIiPlhU=; b=SsjE0amESqLpUJig41ur1D0PxKClUOOhBfpwSi23an0cDE6+IS9Yl+IWdTepLMGNmE ZkeXXCLV1ZM+uNMtFnMpoa4UMk8x9RBWhnAHZ3H7510YSdMDZbKrlO2FxoxJPYmxMQW1 X/ESBgXoIdQ/Yz8OK6bsyWCkwgRn1vXziW1jl20mec5rnNtczDKuuGAaRMqNzrwOn/6F O5LpA/8r1FYIcAFJc4SP1M1uH7Iqq0KW5uN7j3XPS6EIxztoUTlG7Kyy29weqw8mcGtb 0OJ8Xrkz9PEeELYXtvDl4FFmb3Vbf7avpFkKey0Z75LVGyhBiwSta7Ac8BOzoUys1Vj6 oAkg== MIME-Version: 1.0 Received: by 10.112.29.9 with SMTP id f9mr13984174lbh.22.1351633494103; Tue, 30 Oct 2012 14:44:54 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 30 Oct 2012 14:44:54 -0700 (PDT) In-Reply-To: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> Date: Tue, 30 Oct 2012 16:44:54 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=bcaec55556be4855e704cd4db2fd Cc: CLUE Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 21:44:56 -0000 --bcaec55556be4855e704cd4db2fd Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As Paul noted, you are not answering the question that was posed and you are bringing up a framework issue. I believe you are getting into the discussion as to what we can carry in SDP, which is the topic of your draft that we will discuss at the meeting next week. As noted, by Simon later in this thread, the information in the data model has been taken *directly* from the framework. I think we are having some cross-talk and misunderstandings. If you don't agree with some fundamentals in the framework, please identify specific sections independent of how we agree to signal (i.e., SDP versus CLUE signaling). Mary. On Mon, Oct 29, 2012 at 2:19 PM, Roni Even wrote: > Hi,**** > > My view is =91no=94. I still fail to see the need for the encoding groups= and > individual encodes. **** > > In the current definition of capture scene, I am not sure what is the > meaning of different individual encodes and eventually the receiver can > define what it can receive (Typically H.264 is symmetric in terms of > profile but does not need to be in the level) and can ask for specific > resolution with the SDP image attribute**** > > ** ** > > Roni Even**** > > ** ** > > *From:* clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on objective and basic approach*= * > ** > > ** ** > > On the call earlier today, we also discussed the data model. The general > agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the CLUE > application - i.e., it's the CLUE instance concept. It does not directly > reflect the contents of a CLUE message. The application data would be us= ed > to populate CLUE messages, as well as SDP and would reflect updates based > on both the CLUE and SDP signaling. **** > > ** ** > > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply "Yes= " > or "No" reflecting agreement with the above, that would be helpful. If y= ou > reply "No", please explain why. **** > > ** ** > > Regards,**** > > Mary**** > > as CLUE WG co-chair**** > --bcaec55556be4855e704cd4db2fd Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable As Paul noted, you are not answering the question that was posed and you ar= e bringing up a framework issue. =A0I believe you are getting into the disc= ussion as to what we can carry in SDP, which is the topic of your draft tha= t we will discuss at the meeting next week. =A0 As noted, by Simon later in= this thread, the information in the data model has been taken *directly* f= rom the framework. =A0I think we are having some cross-talk and misundersta= ndings. =A0 If you don't agree with some fundamentals in the framework,= please identify specific sections independent of how we agree to signal (i= .e., SDP versus CLUE signaling).

Mary.

On Mon, Oct 29, 2012= at 2:19 PM, Roni Even <ron.even.tlv@gmail.com> wrote:<= br>

Hi,

My view is =91no=94. I still fail to see = the need for the encoding groups and individual encodes.

In the current definition= of capture scene, I am not sure what is the meaning of different individua= l encodes and eventually the receiver can define what it can receive (Typic= ally H.264 is symmetric in terms of profile but does not need to be in the = level) and can ask for specific resolution with the SDP image attribute<= /u>

=A0<= /p>

Roni Even

=A0<= /p>

From: clue-bounces@ietf.org= [mailto:clu= e-bounces@ietf.org] On Behalf Of Mary Barnes
Sent: 29 October, 2012 7:52 PM
To: CLUE
Subject:= [clue] Data model - agreement on objective and basic approach

=A0=

On the call earlier today, we also discussed the dat= a model. =A0The general agreement on the call is that the data model as ref= lected in draft-presta-clue-data-model-schema describes the data needed by = the CLUE application - i.e., it's the CLUE instance concept. =A0It does= not directly reflect the contents of a CLUE message. =A0The application da= ta would be used to populate CLUE messages, as well as SDP and would reflec= t updates based on both the CLUE and SDP signaling. =A0

=A0

If we can get agreement on that before the meeting, I believe our d= iscussions can be much more productive. If folks could please reply "Y= es" or "No" reflecting agreement with the above, that would = be helpful. =A0If you reply "No", please explain why. =A0<= u>

=A0

Regards,

= Mary

as CLUE WG co-chair=


--bcaec55556be4855e704cd4db2fd-- From mary.ietf.barnes@gmail.com Tue Oct 30 14:49: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 D9CCC21F85C4 for ; Tue, 30 Oct 2012 14:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.484 X-Spam-Level: X-Spam-Status: No, score=-102.484 tagged_above=-999 required=5 tests=[AWL=-0.552, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ptCUmRtn9B4Z for ; Tue, 30 Oct 2012 14:49:12 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7FAA621F85BC for ; Tue, 30 Oct 2012 14:49:11 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so638098lbo.31 for ; Tue, 30 Oct 2012 14:49:10 -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=rbjDMqmEX7zLFEcQyBfIPOsuteF8hIzihd0ncjqqFv4=; b=nqHJxkQo5q01hg+c5CX3a5CMAhv2PRQtlTzCOXx/B/cP8TN4KYi8BHEqU/3YdRsziJ GEtHbdxdF0q8I+afb5rZ4qjZvvL7q0aLJK/1LHiWOFlR1z26HRjJMWRIoDgtIfRHGIL1 KFq9ucsQcZeEGD9tj77N28AsHJ0HAXtxv6v4DqbJGCqYnI/rs9hSXGJ2LV7M4GW7CFIa nvAt+KGozP12bRAmyw3TGXZLZolTkb/mBCmjbAoXrPsgPBemJFvGccpvfsNWdRE9yq1b QLaayEhr3fkOPylAOpsp7LmTF6f9dppxVXCG5WF8MoFfxBRsdDNax6l8hVPvGzaePt7s bBwA== MIME-Version: 1.0 Received: by 10.152.148.40 with SMTP id tp8mr31741922lab.30.1351633750288; Tue, 30 Oct 2012 14:49:10 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Tue, 30 Oct 2012 14:49:10 -0700 (PDT) In-Reply-To: <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> Date: Tue, 30 Oct 2012 16:49:10 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=e89a8f2346658d686604cd4dc10f Cc: CLUE Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 21:49:14 -0000 --e89a8f2346658d686604cd4dc10f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that would belong in the protocol document - that is where the SIPREC WG has described their usage of RTP. Any specific changes to the RTP and SDP would of course be submitted as documents in the AVTCORE and MMUSIC WGs. However, it may be better to keep that document separate for a while - that is also the model that SIPREC used/ Mary. On Tue, Oct 30, 2012 at 4:42 PM, Roni Even wro= te: > Hi Mary, > > What about the mapping of RTP streams to Media Captures, where does it > fall > > BTW: the mapping may require an identfier for the media capture > > > > Roni > ------------------------------ > *From:* clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary > Barnes [mary.ietf.barnes@gmail.com] > *Sent:* Tuesday, October 30, 2012 11:25 PM > *To:* CLUE > > *Subject:* Re: [clue] Data model - agreement on objective and basic > approach > > I think this is a reasonable split and I don't think it's that much of a > killer task to do so. We have talked in the past about whether we should > split some material from the framework. I think doing so will make it > easier for individuals to edit the various pieces. We will of course hav= e > to ensure consistency. However, this approach adds some good checks and > balances, I believe. This model is quite similar to what worked very we= ll > for the XCON work and it's quite similar to what other WGs are doing (e.g= ., > SIPREC). > > The chairs have delayed updating our milestones since we had not decided > individual deliverables related to the solution. > > As chair I would like to gauge consensus on this approach. So, if > people could please respond as to whether they support the general idea o= f > splitting the work into the following documents/deliverables: > 1) Framework > 2) Data model > 3) Protocol > 4) Call Flows > > If we can get consensus on the basic idea, then we can work out the > details starting with Simon's suggestion. > > I do have one comment about the "orchestration document" as I think that > might be appropriate for the framework, but we could certainly work on th= at > separately and decide later. > > Thanks, > Mary. > > On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano w= rote: > >> Hi Christian, >> >> a rough estimation would be the following: >> >> a) keep sections 1 through 4 inside the framework document; >> b) move sections 5 through 8 to the data model document >> c) move the XML schema to the data model document (final section of the >> data model, which provides 'one possible' example of how to formally >> describe the things in the document); >> d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the >> protocol document; >> e) move subsection 9.4 to the call flows document; >> f) move section 10 to the data model document; >> g) move section 11 to the call flows document. >> >> Obviously, the resulting framework document should be revised (and >> enriched) in view of the proposed distribution of work inside the WG. I >> would like it to represent an orchestration document, providing an overv= iew >> of issues, requirements, architecture and protocols. > > > >> A sort of summary reference for all of the related "drill-down" >> documents, each expanding on a specific WG item (data model, protocol, c= all >> flows, etc.). >> >> I acknowledge the fact that this looks much like a revolution, but I >> nonetheless believe that we already have most of the needed material at >> hand and just need to better distribute it across the documents produced= by >> the WG. >> >> Cheers, >> >> Simon >> >> >> >> >> Il 30/10/2012 10:33, Christian Groves ha scritto: >> >> Hello Simon, >>> >>> When you say that you want to remove "all" the data model stuff from th= e >>> framework can you be a bit more specific as to what parts you want remo= ved? >>> >>> Regards, Christian >>> >>> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >>> >>>> Hi all, >>>> >>>> just to be clear on the current structure of the data model schema: al= l >>>> the things you find there were 'extracted' (by Roberta and me) from >>>> information currently contained inside the framework draft (as well as= from >>>> some side documents, associated with either the data model or the envi= saged >>>> call flows). So, unless we have misinterpreted the above document(s) (= which >>>> is obviously possible), we should first of all focus on the framework = in >>>> order to try and converge on an agreed-upon CLUE architecture. Once do= ne >>>> with this, we can fine-tune the data model. As I already stated on thi= s >>>> list, it is my personal opinion that we should remove from the framewo= rk >>>> document all of the data-model stuff that it currently contains, and r= ather >>>> focus on a clear definition of framework components and interfaces. I = might >>>> look naif, but I would like to arrive at an 'ordinary' set of document= s: >>>> (i) general framework; (ii) data model; (iii) clue protocol (with >>>> advertisement and configuration messages); (iv) call flows (showing ho= w SDP >>>> O/A and CLUE protocol messages concur in effectively setting up a CLUE >>>> session). >>>> >>>> As to the 'UML vs XML' querelle, I would suggest that: >>>> >>>> 1. Both UML class diagrams and XML schema can be adopted for the >>>> description of the data model, i.e., the STATIC part of the framework, >>>> associated with the description of what some of you properly called a = 'CLUE >>>> instance'; >>>> 2. UML sequence diagrams can be adopted to describe CLUE call flows, >>>> i.e. the DYNAMIC part of the framework, which clearly envisages the >>>> co-existence of SDP and CLUE protocol messages. XML schemas are not >>>> suitable for this dynamic part. >>>> >>>> This said, it is clear that CLUE protocol messages (in particular, >>>> CLUE advertisements) will be constructed by leveraging information >>>> contained inside a CLUE instance. Which parts of a CLUE instance shoul= d go >>>> into an advertisement and which should be carried inside SDP can be a >>>> matter of discussion. >>>> >>>> My 2 cents, >>>> >>>> Simon >>>> >>>> >>>> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >>>> >>>> On 10/29/12 6:23 PM, Roni Even wrote: >>>>> >>>>>> Paul, >>>>>> This was the statement I answered "no" >>>>>> " The general agreement on the call is that the data model as >>>>>> reflected in >>>>>> draft-presta-clue-data-model-**schema describes the data needed by >>>>>> the CLUE >>>>>> application" >>>>>> I disagree that it reflects that data needed by a CLUE application >>>>>> and I >>>>>> explained why. >>>>>> >>>>> >>>>> OK, fair enough. >>>>> >>>>> Mary can comment, but my take was that the point of her question was >>>>> to distinguish between two alternatives: >>>>> - the data model represents all the data needed by the clue app. >>>>> (which implies to me that it encompasses all the data in the >>>>> framework.) >>>>> - the data model represents the data to be exchanged in >>>>> clue messages. >>>>> >>>>> It is a bigger deal if the framework includes things that are not >>>>> needed by the clue application. I was of the impression that, except = for >>>>> some fine tuning, we were largely in agreement on the framework. >>>>> >>>>> If we don't have consensus on *that* then resolving that is of higher >>>>> priority that much of the other stuff we are discussing. >>>>> >>>>> Thanks, >>>>> Paul >>>>> >>>>> Roni >>>>>> >>>>>> -----Original Message----- >>>>>> From: clue-bounces@ietf.org [mailto: >>>>>> clue-bounces@ietf.org] On Behalf Of Paul >>>>>> Kyzivat >>>>>> Sent: 29 October, 2012 9:46 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] Data model - agreement on objective and basic >>>>>> approach >>>>>> >>>>>> On 10/29/12 3:19 PM, Roni Even wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> My view is 'no". I still fail to see the need for the encoding grou= ps >>>>>>> and individual encodes. >>>>>>> >>>>>>> In the current definition of capture scene, I am not sure what is t= he >>>>>>> meaning of different individual encodes and eventually the receiver >>>>>>> can define what it can receive (Typically H.264 is symmetric in ter= ms >>>>>>> of profile but does not need to be in the level) and can ask for >>>>>>> specific resolution with the SDP image attribute >>>>>>> >>>>>> >>>>>> ISTM that you are answering a different question than the one Mary >>>>>> asked. >>>>>> You seem to be saying that you disagree with the framework as it is = - >>>>>> that >>>>>> it can/should be simpler. >>>>>> >>>>>> That is a separate question. If such changes were made it might >>>>>> affect a >>>>>> lot. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> Roni Even >>>>>>> >>>>>>> *From:*clue-bounces@ietf.org [mailto= : >>>>>>> clue-bounces@ietf.org] *On Behalf >>>>>>> Of *Mary Barnes >>>>>>> *Sent:* 29 October, 2012 7:52 PM >>>>>>> *To:* CLUE >>>>>>> *Subject:* [clue] Data model - agreement on objective and basic >>>>>>> approach >>>>>>> >>>>>>> On the call earlier today, we also discussed the data model. The >>>>>>> general agreement on the call is that the data model as reflected i= n >>>>>>> draft-presta-clue-data-model-**schema describes the data needed by >>>>>>> the >>>>>>> CLUE application - i.e., it's the CLUE instance concept. It does no= t >>>>>>> directly reflect the contents of a CLUE message. The application >>>>>>> data >>>>>>> would be used to populate CLUE messages, as well as SDP and would >>>>>>> reflect updates based on both the CLUE and SDP signaling. >>>>>>> >>>>>>> If we can get agreement on that before the meeting, I believe our >>>>>>> discussions can be much more productive. If folks could please repl= y >>>>>>> "Yes" or "No" reflecting agreement with the above, that would be >>>>>>> helpful. If you reply "No", please explain why. >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Mary >>>>>>> >>>>>>> as CLUE WG co-chair >>>>>>> >>>>>>> >>>>>>> >>>>>>> ______________________________**_________________ >>>>>>> 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 >>>>> >>>>> >>>> _\\|//_ >>>> ( O-O ) >>>> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >>>> Simon Pietro Romano >>>> Universita' di Napoli Federico II >>>> Computer Engineering Department >>>> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >>>> e-mail: spromano@unina.it >>>> >>>> <>>> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >>>> oooO >>>> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> \ ( ( ) >>>> \_) ) / >>>> (_/ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ______________________________**_________________ >>>> 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 >>> >>> >> -- >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)**~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Science Department >> Phone: +39 081 7683823 -- Fax: +39 081 7684219 >> e-mail: spromano@unina.it >> http://www.comics.unina.it/**simonpietro.romano >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> \ ( ( ) >> \_) ) / >> (_/ >> >> ______________________________**_________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/**listinfo/clue >> > > --e89a8f2346658d686604cd4dc10f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think that would belong in the protocol document - that is where the SIPR= EC WG has described their usage of RTP. =A0 Any specific changes to the RTP= and SDP would of course be submitted as documents in the AVTCORE and MMUSI= C WGs.

However, it may be better to keep that document separate for= a while - that is also the model that SIPREC used/

= Mary. =A0=A0

On Tue, Oct 30, 2012 at 4:42= PM, Roni Even <roni.even@mail01.huawei.com> wrote= :

Hi Mary,

What about the mapping of RTP streams to Media Captures, where does it f= all

BTW: the mapping may require an identfier for the media capture

=A0

Roni

Fro= m: clue-boun= ces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes [mary.ietf.barnes@gmail.com]=
Sent: Tuesday, October 30, 2012 11:25 PM
To: CLUE

Subject: Re: [clue] Data model - agreement on objective and basic ap= proach

I think this is a reasonable split and I don't think it's that= much of a killer task to do so. =A0We have talked in the past about whethe= r we should split some material from the framework. =A0I think doing so wil= l make it easier for individuals to edit the various pieces. =A0We will of course have to ensure consistency. =A0Howeve= r, =A0this approach adds some good checks and balances, I believe. =A0 This= model is quite similar to what worked very well for the XCON work and it&#= 39;s quite similar to what other WGs are doing (e.g., SIPREC). =A0

The chairs have delayed updating our milestones since we had not decid= ed individual deliverables related to the solution. =A0

As chair I would like to gauge consensus on this approach. =A0So, if p= eople could please respond as to whether they support the general idea of s= plitting the work into the following documents/deliverables:
1) Framework
2) Data model
3) Protocol
4) Call Flows

If we can get consensus on the basic idea, then we can work out the de= tails starting with Simon's suggestion.

I do have one comment about the "orchestration document" as = I think that might be appropriate for the framework, but we could certainly= work on that separately and decide later.

Thanks,
Mary.=A0

On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Ro= mano <spromano@unina.i= t> wrote:
Hi Christian,

a rough estimation would be the following:

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the dat= a model, which provides 'one possible' example of how to formally d= escribe the things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protoc= ol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and enriched= ) in view of the proposed distribution of work inside the WG. I would like = it to represent an orchestration document, providing an overview of issues,= requirements, architecture and protocols.
=A0
A sort of summary reference for all of the related "drill-down" d= ocuments, each expanding on a specific WG item (data model, protocol, call = flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I noneth= eless believe that we already have most of the needed material at hand and = just need to better distribute it across the documents produced by the WG.<= br>
Cheers,

Simon




Il 30/10/2012 10:33, Christian Groves ha scritto:

Hello Simon,

When you say that you want to remove "all" the data model stuff f= rom the framework can you be a bit more specific as to what parts you want = removed?

Regards, Christian

On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
Hi all,

just to be clear on the current structure of the data model schema: all the= things you find there were 'extracted' (by Roberta and me) from in= formation currently contained inside the framework draft (as well as from s= ome side documents, associated with either the data model or the envisaged call flows). So, unless we have misinterpr= eted the above document(s) (which is obviously possible), we should first o= f all focus on the framework in order to try and converge on an agreed-upon= CLUE architecture. Once done with this, we can fine-tune the data model. As I already stated on this list, i= t is my personal opinion that we should remove from the framework document = all of the data-model stuff that it currently contains, and rather focus on= a clear definition of framework components and interfaces. I might look naif, but I would like to arrive a= t an 'ordinary' set of documents: (i) =A0general framework; (ii) da= ta model; (iii) clue protocol (with advertisement and configuration message= s); (iv) call flows (showing how SDP O/A and CLUE protocol messages concur in effectively setting up a CLUE session).
As to the 'UML vs XML' querelle, I would suggest that:

1. Both UML class diagrams and XML schema can be adopted for the descriptio= n of the data model, i.e., the STATIC part of the framework, associated wit= h the description of what some of you properly called a 'CLUE instance&= #39;;
2. UML sequence diagrams can be adopted to describe CLUE call flows, i.e. t= he DYNAMIC part of the framework, which clearly envisages the co-existence = of SDP and CLUE protocol messages. XML schemas are not suitable for this dy= namic part.

This said, it is clear that CLUE protocol messages =A0(in particular, CLUE = advertisements) will be constructed by leveraging information contained ins= ide a CLUE instance. Which parts of a CLUE instance should go into an adver= tisement and which should be carried inside SDP can be a matter of discussion.

My 2 cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto:

On 10/29/12 6:23 PM, Roni Even wrote:
Paul,
This was the statement I answered "no"
" The general agreement on the call is that the data model as reflecte= d in
draft-presta-clue-data-model-schema describes the data needed by the= CLUE
application"
I disagree that it reflects that data needed by a CLUE application and I explained why.

OK, fair enough.

Mary can comment, but my take was that the point of her question was to dis= tinguish between two alternatives:
- the data model represents all the data needed by the clue app.
=A0(which implies to me that it encompasses all the data in the
=A0framework.)
- the data model represents the data to be exchanged in
=A0clue messages.

It is a bigger deal if the framework includes things that are not needed by= the clue application. I was of the impression that, except for some fine t= uning, we were largely in agreement on the framework.

If we don't have consensus on *that* then resolving that is of higher p= riority that much of the other stuff we are discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounc= es@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] On Behalf Of Paul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: clue@ietf.org &l= t;mailto:clue@ietf.org>
Subject: Re: [clue] Data model - agreement on objective and basic approach<= br>
On 10/29/12 3:19 PM, Roni Even wrote:
Hi,

My view is 'no". I still fail to see the need for the encoding gro= ups
and individual encodes.

In the current definition of capture scene, I am not sure what is the
meaning of different individual encodes and eventually the receiver
can define what it can receive (Typically H.264 is symmetric in terms
of profile but does not need to be in the level) and can ask for
specific resolution with the SDP image attribute

ISTM that you are answering a different question than the one Mary asked. You seem to be saying that you disagree with the framework as it is - that<= br> it can/should be simpler.

That is a separate question. If such changes were made it might affect a lot.

Thanks,
Paul

Roni Even

*From:*clue-boun= ces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] *On Behalf
Of *Mary Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* [clue] Data model - agreement on objective and basic
approach

On the call earlier today, we also discussed the data model. =A0The
general agreement on the call is that the data model as reflected in
draft-presta-clue-data-model-schema describes the data needed by the=
CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. =A0The application data would be used to populate CLUE messages, as well as SDP and would
reflect updates based on both the CLUE and SDP signaling.

If we can get agreement on that before the meeting, I believe our
discussions can be much more productive. If folks could please reply
"Yes" or "No" reflecting agreement with the above, that= would be
helpful. =A0If you reply "No", please explain why.

Regards,

Mary

as CLUE WG co-chair



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue



_______________________________________________
clue mailing list
clue@ietf.org <ma= ilto:clue@ietf.org&g= t;
ht= tps://www.ietf.org/mailman/listinfo/clue


_\\|//_
=A0 =A0 =A0 ( O-O )
=A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
Simon Pietro Romano
Universita' di Napoli Federico II
=A0Computer Engineering Department
=A0 Phone: +39 081 7683823 -- Fax: +39 081 7683816
=A0e-mail: spromano@= unina.it <mailto:spromano@unina.it>

<<Molti mi dicono che lo scoraggiamento =CB l'alibi degli
=A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0\ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 =A0 =A0 =A0 =A0) /<= br> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(_/







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

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


--
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 _\\|//_
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ( O-O )
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Simon Pietro Romano
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Universita' di Napoli Federico II
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Computer Science Department
=A0 =A0 =A0 =A0 Phone: +39 081 7683823 -- Fax: +39 081 7684219
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 e-mail: spromano@unina.it
=A0 =A0 =A0 =A0 =A0 http://www.comics.unina.it/simonpietro.romano


=A0 =A0 <<Molti mi dicono che lo scoraggiamento =E8 l'alibi degli=
=A0 =A0idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
=A0 =A0~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \ ( =A0 =A0( =A0 )
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\_) =A0 =A0) /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(_/

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


--e89a8f2346658d686604cd4dc10f-- From ron.even.tlv@gmail.com Tue Oct 30 16:04:02 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D34E21F85F5 for ; Tue, 30 Oct 2012 16:04:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P8TFOvN2jwY7 for ; Tue, 30 Oct 2012 16:04:00 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id B259121F85ED for ; Tue, 30 Oct 2012 16:03:59 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so503636eek.31 for ; Tue, 30 Oct 2012 16:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:thread-index:content-language; bh=NdKzu9ngZD60QCZHY+SN1Ih8R5yn1CwsoyedOKwC8/8=; b=pjcByqiVc6IxNWjkEZ04SHumbq+TmilWi6bAo8ojqz1HB3pRSPA1hcA6hTZEQZyb0h F7LC3YYUq40PxGOxvdQpUVBieq/cbruPliNLpVaZUR6iI9QfTIel6jEhZsnI7snlvABd DQ6um4iGVi53xWXFdhbtFQXz+8yaDHj6YpqK+I8q4R/K1NEKlOxFl4VIBr1GrrFmn7rD kxafb9eR+uFbJJaGKfOew/8KVBRomm/et9cELTyGRi9dKZhaxuk1/Lv18Rnj3WO9y8+E YPs93Em8yOgEF1POV+AP1uBiEWTFZTgKyombJFYfITsnqJ58iCrVNtrYAuNBhW5HIXH8 J5BQ== Received: by 10.14.200.194 with SMTP id z42mr70190436een.13.1351638238714; Tue, 30 Oct 2012 16:03:58 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id b44sm4304115eep.12.2012.10.30.16.03.55 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 16:03:57 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'Roni Even'" References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> In-Reply-To: Date: Wed, 31 Oct 2012 01:01:44 +0200 Message-ID: <01a701cdb6f2$8a772f60$9f658e20$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01A8_01CDB703.4E029770" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1H205IYhCmcjSpxYAUxN6zg5tsgC/Cc7eAw1ugkYCVsjGeAJj9POrAiIDFmQCKr40BgIYU8RPAL7MWZgBdCoLEQHfqE8SluuuobA= Content-Language: en-us Cc: 'CLUE' Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 30 Oct 2012 23:04:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01A8_01CDB703.4E029770 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, Just as a point that CLUE does not work if you cannot say which SSRC is = a specific media capture in CLUE Roni =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: 30 October, 2012 11:49 PM To: Roni Even Cc: CLUE Subject: Re: [clue] Data model - agreement on objective and basic = approach =20 I think that would belong in the protocol document - that is where the SIPREC WG has described their usage of RTP. Any specific changes to = the RTP and SDP would of course be submitted as documents in the AVTCORE and MMUSIC WGs. =20 However, it may be better to keep that document separate for a while - = that is also the model that SIPREC used/ =20 Mary. =20 On Tue, Oct 30, 2012 at 4:42 PM, Roni Even wrote: Hi Mary, What about the mapping of RTP streams to Media Captures, where does it = fall=20 BTW: the mapping may require an identfier for the media capture =20 Roni _____ =20 From: clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary = Barnes [mary.ietf.barnes@gmail.com] Sent: Tuesday, October 30, 2012 11:25 PM To: CLUE Subject: Re: [clue] Data model - agreement on objective and basic = approach =20 I think this is a reasonable split and I don't think it's that much of a killer task to do so. We have talked in the past about whether we = should split some material from the framework. I think doing so will make it easier for individuals to edit the various pieces. We will of course = have to ensure consistency. However, this approach adds some good checks = and balances, I believe. This model is quite similar to what worked very = well for the XCON work and it's quite similar to what other WGs are doing = (e.g., SIPREC). =20 =20 The chairs have delayed updating our milestones since we had not decided individual deliverables related to the solution. =20 =20 As chair I would like to gauge consensus on this approach. So, if = people could please respond as to whether they support the general idea of splitting the work into the following documents/deliverables: 1) Framework 2) Data model 3) Protocol 4) Call Flows =20 If we can get consensus on the basic idea, then we can work out the = details starting with Simon's suggestion. =20 I do have one comment about the "orchestration document" as I think that might be appropriate for the framework, but we could certainly work on = that separately and decide later. =20 Thanks, Mary.=20 =20 On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano wrote: Hi Christian, a rough estimation would be the following: a) keep sections 1 through 4 inside the framework document; b) move sections 5 through 8 to the data model document c) move the XML schema to the data model document (final section of the = data model, which provides 'one possible' example of how to formally describe = the things in the document); d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protocol document; e) move subsection 9.4 to the call flows document; f) move section 10 to the data model document; g) move section 11 to the call flows document. Obviously, the resulting framework document should be revised (and = enriched) in view of the proposed distribution of work inside the WG. I would like = it to represent an orchestration document, providing an overview of issues, requirements, architecture and protocols. =20 A sort of summary reference for all of the related "drill-down" = documents, each expanding on a specific WG item (data model, protocol, call flows, etc.). I acknowledge the fact that this looks much like a revolution, but I nonetheless believe that we already have most of the needed material at = hand and just need to better distribute it across the documents produced by = the WG. Cheers, Simon Il 30/10/2012 10:33, Christian Groves ha scritto:=20 =20 Hello Simon, When you say that you want to remove "all" the data model stuff from the framework can you be a bit more specific as to what parts you want = removed? Regards, Christian On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: Hi all, just to be clear on the current structure of the data model schema: all = the things you find there were 'extracted' (by Roberta and me) from = information currently contained inside the framework draft (as well as from some = side documents, associated with either the data model or the envisaged call flows). So, unless we have misinterpreted the above document(s) (which = is obviously possible), we should first of all focus on the framework in = order to try and converge on an agreed-upon CLUE architecture. Once done with this, we can fine-tune the data model. As I already stated on this list, = it is my personal opinion that we should remove from the framework document = all of the data-model stuff that it currently contains, and rather focus on = a clear definition of framework components and interfaces. I might look = naif, but I would like to arrive at an 'ordinary' set of documents: (i) = general framework; (ii) data model; (iii) clue protocol (with advertisement and configuration messages); (iv) call flows (showing how SDP O/A and CLUE protocol messages concur in effectively setting up a CLUE session). As to the 'UML vs XML' querelle, I would suggest that: 1. Both UML class diagrams and XML schema can be adopted for the = description of the data model, i.e., the STATIC part of the framework, associated = with the description of what some of you properly called a 'CLUE instance'; 2. UML sequence diagrams can be adopted to describe CLUE call flows, = i.e. the DYNAMIC part of the framework, which clearly envisages the = co-existence of SDP and CLUE protocol messages. XML schemas are not suitable for this dynamic part. This said, it is clear that CLUE protocol messages (in particular, CLUE advertisements) will be constructed by leveraging information contained inside a CLUE instance. Which parts of a CLUE instance should go into an advertisement and which should be carried inside SDP can be a matter of discussion. My 2 cents, Simon Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: On 10/29/12 6:23 PM, Roni Even wrote: Paul, This was the statement I answered "no" " The general agreement on the call is that the data model as reflected = in draft-presta-clue-data-model-schema describes the data needed by the = CLUE application" I disagree that it reflects that data needed by a CLUE application and I explained why. OK, fair enough. Mary can comment, but my take was that the point of her question was to distinguish between two alternatives: - the data model represents all the data needed by the clue app. (which implies to me that it encompasses all the data in the framework.) - the data model represents the data to be exchanged in clue messages. It is a bigger deal if the framework includes things that are not needed = by the clue application. I was of the impression that, except for some fine tuning, we were largely in agreement on the framework. If we don't have consensus on *that* then resolving that is of higher priority that much of the other stuff we are discussing. Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29 October, 2012 9:46 PM To: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic = approach On 10/29/12 3:19 PM, Roni Even wrote: Hi, My view is 'no". I still fail to see the need for the encoding groups and individual encodes. In the current definition of capture scene, I am not sure what is the meaning of different individual encodes and eventually the receiver can define what it can receive (Typically H.264 is symmetric in terms of profile but does not need to be in the level) and can ask for specific resolution with the SDP image attribute ISTM that you are answering a different question than the one Mary = asked. You seem to be saying that you disagree with the framework as it is - = that it can/should be simpler. That is a separate question. If such changes were made it might affect a lot. Thanks, Paul Roni Even *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes *Sent:* 29 October, 2012 7:52 PM *To:* CLUE *Subject:* [clue] Data model - agreement on objective and basic approach On the call earlier today, we also discussed the data model. The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. The application data would be used to populate CLUE messages, as well as SDP and would reflect updates based on both the CLUE and SDP signaling. If we can get agreement on that before the meeting, I believe our discussions can be much more productive. If folks could please reply "Yes" or "No" reflecting agreement with the above, that would be helpful. If you reply "No", please explain why. Regards, Mary as CLUE WG co-chair _______________________________________________ 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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 =20 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ 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 --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 = 081 7684219 =20 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano=20 <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~=20 \ ( ( ) \_) ) / (_/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 =20 ------=_NextPart_000_01A8_01CDB703.4E029770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mary,

Just as a point that CLUE does not work if you cannot say which SSRC = is a specific media capture in CLUE

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 30 October, 2012 11:49 PM
To: = Roni Even
Cc: CLUE
Subject: Re: [clue] Data model - = agreement on objective and basic approach

 

I think that = would belong in the protocol document - that is where the SIPREC WG has = described their usage of RTP.   Any specific changes to the RTP and = SDP would of course be submitted as documents in the AVTCORE and MMUSIC = WGs.

 

However, it may be better to keep that document = separate for a while - that is also the model that SIPREC = used/

 

Mary.   

On Tue, Oct 30, 2012 at 4:42 PM, Roni Even <roni.even@mail01.huawei.com> = wrote:

Hi = Mary,

What about = the mapping of RTP streams to Media Captures, where does it fall =

BTW: the = mapping may require an identfier for the media = capture

 <= /o:p>

Roni

From:<= span style=3D'font-family:"Tahoma","sans-serif";color:black'> clue-bounces@ietf.org [clue-bounces@ietf.org] on behalf of Mary Barnes = [mary.ietf.barnes@gmail.com]
Sent: = Tuesday, October 30, 2012 11:25 PM
To: = CLUE


Subject: Re: [clue] Data model - agreement on objective and basic = approach

 

I think this is a reasonable split and I don't think = it's that much of a killer task to do so.  We have talked in the = past about whether we should split some material from the framework. =  I think doing so will make it easier for individuals to edit the = various pieces.  We will of course have to ensure consistency. =  However,  this approach adds some good checks and balances, I = believe.   This model is quite similar to what worked very well for = the XCON work and it's quite similar to what other WGs are doing (e.g., = SIPREC).  

 

The chairs have delayed updating our milestones since = we had not decided individual deliverables related to the solution. =  

 

As chair I would like to gauge consensus on this = approach.  So, if people could please respond as to whether they = support the general idea of splitting the work into the following = documents/deliverables:

1) = Framework

2) Data = model

3) = Protocol

4) Call = Flows

 

If we can get consensus on the basic idea, then we can = work out the details starting with Simon's = suggestion.

 

I = do have one comment about the "orchestration document" as I = think that might be appropriate for the framework, but we could = certainly work on that separately and decide = later.

 

Thanks,

Mary. 

 

On Tue, = Oct 30, 2012 at 5:23 AM, Simon Pietro Romano <spromano@unina.it> wrote:

Hi Christian,

a rough estimation would be the = following:

a) keep sections 1 through 4 inside the framework = document;
b) move sections 5 through 8 to the data model = document
c) move the XML schema to the data model document (final = section of the data model, which provides 'one possible' example of how = to formally describe the things in the document);
d) move section 9, = together with subsections 9.1, 9.2 and 9.3 to the protocol = document;
e) move subsection 9.4 to the call flows document;
f) = move section 10 to the data model document;
g) move section 11 to the = call flows document.

Obviously, the resulting framework document = should be revised (and enriched) in view of the proposed distribution of = work inside the WG. I would like it to represent an orchestration = document, providing an overview of issues, requirements, architecture = and protocols.

 

A sort of = summary reference for all of the related "drill-down" = documents, each expanding on a specific WG item (data model, protocol, = call flows, etc.).

I acknowledge the fact that this looks much = like a revolution, but I nonetheless believe that we already have most = of the needed material at hand and just need to better distribute it = across the documents produced by the = WG.

Cheers,

Simon




Il 30/10/2012 10:33, = Christian Groves ha scritto:

 

Hello = Simon,

When you say that you want to remove "all" the = data model stuff from the framework can you be a bit more specific as to = what parts you want removed?

Regards, Christian

On = 30/10/2012 7:03 PM, Simon Pietro Romano wrote:

Hi all,

just to = be clear on the current structure of the data model schema: all the = things you find there were 'extracted' (by Roberta and me) from = information currently contained inside the framework draft (as well as = from some side documents, associated with either the data model or the = envisaged call flows). So, unless we have misinterpreted the above = document(s) (which is obviously possible), we should first of all focus = on the framework in order to try and converge on an agreed-upon CLUE = architecture. Once done with this, we can fine-tune the data model. As I = already stated on this list, it is my personal opinion that we should = remove from the framework document all of the data-model stuff that it = currently contains, and rather focus on a clear definition of framework = components and interfaces. I might look naif, but I would like to arrive = at an 'ordinary' set of documents: (i)  general framework; (ii) = data model; (iii) clue protocol (with advertisement and configuration = messages); (iv) call flows (showing how SDP O/A and CLUE protocol = messages concur in effectively setting up a CLUE session).

As to = the 'UML vs XML' querelle, I would suggest that:

1. Both UML = class diagrams and XML schema can be adopted for the description of the = data model, i.e., the STATIC part of the framework, associated with the = description of what some of you properly called a 'CLUE instance';
2. = UML sequence diagrams can be adopted to describe CLUE call flows, i.e. = the DYNAMIC part of the framework, which clearly envisages the = co-existence of SDP and CLUE protocol messages. XML schemas are not = suitable for this dynamic part.

This said, it is clear that CLUE = protocol messages  (in particular, CLUE advertisements) will be = constructed by leveraging information contained inside a CLUE instance. = Which parts of a CLUE instance should go into an advertisement and which = should be carried inside SDP can be a matter of discussion.

My 2 = cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, = Paul Kyzivat ha scritto:

On 10/29/12 = 6:23 PM, Roni Even wrote:

Paul,
This was the statement I answered = "no"
" The general agreement on the call is that the = data model as reflected in
draft-presta-clue-data-model-schema = describes the data needed by the CLUE
application"
I disagree = that it reflects that data needed by a CLUE application and = I
explained why.


OK, fair enough.

Mary can = comment, but my take was that the point of her question was to = distinguish between two alternatives:
- the data model represents all = the data needed by the clue app.
 (which implies to me that it = encompasses all the data in the
 framework.)
- the data model = represents the data to be exchanged in
 clue messages.

It = is a bigger deal if the framework includes things that are not needed by = the clue application. I was of the impression that, except for some fine = tuning, we were largely in agreement on the framework.

If we = don't have consensus on *that* then resolving that is of higher priority = that much of the other stuff we are = discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] On Behalf Of = Paul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: clue@ietf.org = <mailto:clue@ietf.org>
Subject: Re: [clue] Data = model - agreement on objective and basic approach

On 10/29/12 = 3:19 PM, Roni Even wrote:

Hi,

My view is 'no". I still fail to see = the need for the encoding groups
and individual encodes.

In = the current definition of capture scene, I am not sure what is = the
meaning of different individual encodes and eventually the = receiver
can define what it can receive (Typically H.264 is symmetric = in terms
of profile but does not need to be in the level) and can ask = for
specific resolution with the SDP image attribute


ISTM that you are = answering a different question than the one Mary asked.
You seem to = be saying that you disagree with the framework as it is - that
it = can/should be simpler.

That is a separate question. If such = changes were made it might affect = a
lot.

Thanks,
Paul

Roni Even

*From:*clue-bounces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] *On Behalf
Of *Mary = Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* = [clue] Data model - agreement on objective and = basic
approach

On the call earlier today, we also discussed = the data model.  The
general agreement on the call is that the = data model as reflected in
draft-presta-clue-data-model-schema = describes the data needed by the
CLUE application - i.e., it's the = CLUE instance concept. It does not
directly reflect the contents of a = CLUE message.  The application data
would be used to populate = CLUE messages, as well as SDP and would
reflect updates based on both = the CLUE and SDP signaling.

If we can get agreement on that = before the meeting, I believe our
discussions can be much more = productive. If folks could please reply
"Yes" or = "No" reflecting agreement with the above, that would = be
helpful.  If you reply "No", please explain = why.

Regards,

Mary

as CLUE WG = co-chair



_______________________________________________clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue


______________________________________= _________
clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue

<= o:p>


______________________________________= _________
clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue


_\\|//_
      ( O-O = )
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~Simon Pietro Romano
Universita' di Napoli Federico = II
 Computer Engineering Department
  Phone: +39 081 7683823 = -- Fax: +39 081 = 7683816
 e-mail: spromano@unina.it <mailto:spromano@unina.it>

<<Molti mi = dicono che lo scoraggiamento =CB l'alibi degli
 idioti. Ci = rifletto un istante; e mi scoraggio>>. Magritte.
    =                 =  oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ = Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
       \ (   =          (   )
      =                   \_) =          ) /
        =                 =  (_/







________________________________= _______________
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

 

--

  =                     =       _\\|//_
          =                   ( O-O = )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
&nbs= p;                   Simon = Pietro Romano
              = Universita' di Napoli Federico II

              =    Computer Science Department
        = Phone: +39 081 = 7683823 -- Fax: +39 081 7684219
        =         e-mail: spromano@unina.it
        =   http://www.comics.unina.it/simonpietro.romano =



    = <<Molti mi dicono che lo scoraggiamento =E8 l'alibi = degli
   idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
          =               =  oooO

  =  ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ =


      =                     \ = (    (   )
            =                \_)   =  ) /
                =                 =  (_/

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

 

 

------=_NextPart_000_01A8_01CDB703.4E029770-- From ron.even.tlv@gmail.com Tue Oct 30 16:36:07 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5199721F84EB for ; Tue, 30 Oct 2012 16:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXziGmk9fj9k for ; Tue, 30 Oct 2012 16:36:06 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3E02A21F8503 for ; Tue, 30 Oct 2012 16:36:06 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so373601eaa.31 for ; Tue, 30 Oct 2012 16:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=81VBP1la6iMw3ceDMVQpSd78NuNKVlNxhK9TuluUcWI=; b=rL542JSYgF7zoAITG0ms+tVKrKnR2CvtDzuwhsw2NDd1Ztura2xhl3tS03xSm5qw5N D7Yh9ur9+enTdiI7kRx4Yt+1ESzBu4byQ7GvlzUdhAzmGWPQw20KaTIUQ4gkHcucnrQ+ JWU9W0Es8CxaEzqCWHWsyY2b/+lNZEjvlXahveqd0IDZgUlxJ9g6fsrrlT5GP7Gj1yF+ uRqTO4ZywkWZiLesVE/GLnRlTp+kILoAwi4bXTSqF42ylZbln4EDTjurXFbH4ihg8tI0 32zAcQlJthu615eR3LWp+kvzy1rbC9g28VI2P68MCRJ52xJxd7K51XU9UUuLFhzGu9j5 0a9A== Received: by 10.14.0.68 with SMTP id 44mr79334387eea.1.1351640162242; Tue, 30 Oct 2012 16:36:02 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id e1sm4469168eem.3.2012.10.30.16.35.59 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 16:36:01 -0700 (PDT) From: "Roni Even" To: Date: Wed, 31 Oct 2012 01:33:49 +0200 Message-ID: <01ac01cdb6f7$057e19e0$107a4da0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01AD_01CDB707.C9078620" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac229TH980zx5fLVTluhZadCLUJlUQ== Content-Language: en-us Subject: [clue] review of http://tools.ietf.org/id/draft-presta-clue-data-model-schema-01 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, 30 Oct 2012 23:36:07 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01AD_01CDB707.C9078620 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I looked at the updated version and have a couple of comments 1 I already said in the previous version that in the example VC0, VC1, and VC2 must have spatial information since otherwise it is not clear what they represent. 2 I noticed the new nativeAspectRatio attribute. I think we discussed it in IETF84 and it was not agreed to add any new information from draft-romanow-clue-data-model-01 to the framework. I suggest that before having it here we should see if it should be added to the framework as an attribute. The text in draft-romanow-clue-data-model-01 says it is helpful for rendering (not for advertise or config) and this information is available as part of the payload. 3 What is the purpose of the new clueinfoid. Is it to identify the version of the data?. Need some text to explain it. Thanks Roni Even ------=_NextPart_000_01AD_01CDB707.C9078620 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I looked at the = updated version and have a couple of comments

 

1 I already = said in the previous version that in the example VC0, VC1, and VC2 must = have spatial information since otherwise it is not clear what  they = represent.

 

2 I noticed the new nativeAsp= ectRatio attribute. I think we discussed it in IETF84 and it was not = agreed to add any new information from draft-romanow-clue-data-model-01 to the framework. I suggest = that before having it here we should see if it should be added to the = framework as an attribute. The text in draft-romanow-clue-data-model-01 = says it is helpful for rendering (not for advertise or config) and this = information is available as part of the payload.

 

3 What is the purpose of the new = clueinfoid. Is it to identify the version of the data?. Need some text = to explain it.

 

Thanks

Roni Even

 

 

 

 

 

 

------=_NextPart_000_01AD_01CDB707.C9078620-- From ron.even.tlv@gmail.com Tue Oct 30 16:51: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 0CDE421F855F for ; Tue, 30 Oct 2012 16:51:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1dp2lDkUmNvK for ; Tue, 30 Oct 2012 16:51:22 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4657021F8585 for ; Tue, 30 Oct 2012 16:51:22 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so377400eaa.31 for ; Tue, 30 Oct 2012 16:51:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=fAg+gg/8nHE3VlIiCzje9UutrfpAV6tN6JNXq12KqGg=; b=DnKlMpzYUpmC6LYtOq7bjg+FPL2szWdwCt9lk2gfk6cAtVbRVmjgAVl2yXBYPtXm58 OYwdTpmLKmzuEaX9HyokkuEMfouVZQEPOYxUJ0UoU4iDLtbSoyZB8OQzovDcWEDIorPL yJOj3xLmCiw6wYS3laySRIb41SBy8rkEBg8kdb3hrrhgm2Xgca/v1IsqwL7s1T8jZNku B9nJ57xnrHvq3dmPAw5/i2td25v4cyv+wROiNmCiTHF7ItdNIyZ4Sz+lHgzUAbMDOFUq oX0r5vSzh5UwUd3T21o8GFZZvlZSbTJRt9BhJs+y3pX1VhYYnMCYmRHXg3wkhGtk/Fed U1aw== Received: by 10.14.219.2 with SMTP id l2mr73892157eep.3.1351641081298; Tue, 30 Oct 2012 16:51:21 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id s1sm4502417eem.9.2012.10.30.16.51.19 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 16:51:20 -0700 (PDT) From: "Roni Even" To: Date: Wed, 31 Oct 2012 01:49:08 +0200 Message-ID: <01b101cdb6f9$297703f0$7c650bd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01B2_01CDB709.ED002210" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac22+IIitKdOHRuARbuI/QX4Wx/1pQ== Content-Language: en-us Subject: [clue] Encoding exmple in the data model 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, 30 Oct 2012 23:51:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01B2_01CDB709.ED002210 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, According to section 7.1 of the framework an individual encoding can be assigned to only one capture encoding at a time. In the example you have one encoding group with two individual encodes one for audio and one for video. This will allow only one video and one audio at the same time. I assume this is not what you wanted to convey which can have left, center, right and presentation video and two audio streams at the same time . this will require 4 individual video encodes and two audio encodes. Roni ------=_NextPart_000_01B2_01CDB709.ED002210 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

According to = section 7.1 of the framework an individual encoding can = be assigned to only one capture encoding at a time. In the example you = have one encoding group with two individual encodes one for audio and = one for video. This will allow only one video and one audio at the same = time.

I = assume this is not what you wanted to convey which can have left, = center, right and presentation video and two audio streams at the same = time . this will require 4 individual video encodes and two audio = encodes.

 

Roni

 

 

------=_NextPart_000_01B2_01CDB709.ED002210-- From pkyzivat@alum.mit.edu Tue Oct 30 17:21: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 4E21721F86C3 for ; Tue, 30 Oct 2012 17:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QGtchJDfd6D0 for ; Tue, 30 Oct 2012 17:21:39 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id E545D21F868F for ; Tue, 30 Oct 2012 17:21:35 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta05.westchester.pa.mail.comcast.net with comcast id HPSA1k0031ap0As55cMg9B; Wed, 31 Oct 2012 00:21:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id HcNA1k00Y3ZTu2S3icNApp; Wed, 31 Oct 2012 00:22:11 +0000 Message-ID: <50906F0D.1020004@alum.mit.edu> Date: Tue, 30 Oct 2012 20:21:33 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> <01a701cdb6f2$8a772f60$9f658e20$@gmail.com> In-Reply-To: <01a701cdb6f2$8a772f60$9f658e20$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 31 Oct 2012 00:21:40 -0000 On 10/30/12 7:01 PM, Roni Even wrote: > Mary, > > Just as a point that CLUE does not work if you cannot say which SSRC is > a specific media capture in CLUE I have now gotten lost in this thread. I don't understand what in the thread this comment was intended to respond to. But responding to just this statement, it sounds like a denial of the dynamic mapping, which explicitly separates the identification of a capture (actually capture encoding) from an SSRC. So are you saying thata CLUE does not work with the dynamic mapping? Thanks, Paul > Roni > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 30 October, 2012 11:49 PM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Data model - agreement on objective and basic approach > > I think that would belong in the protocol document - that is where the > SIPREC WG has described their usage of RTP. Any specific changes to > the RTP and SDP would of course be submitted as documents in the AVTCORE > and MMUSIC WGs. > > However, it may be better to keep that document separate for a while - > that is also the model that SIPREC used/ > > Mary. > > On Tue, Oct 30, 2012 at 4:42 PM, Roni Even > wrote: > > Hi Mary, > > What about the mapping of RTP streams to Media Captures, where does it fall > > BTW: the mapping may require an identfier for the media capture > > Roni > > ------------------------------------------------------------------------ > > *From:*clue-bounces@ietf.org > [clue-bounces@ietf.org ] on behalf of Mary > Barnes [mary.ietf.barnes@gmail.com ] > *Sent:* Tuesday, October 30, 2012 11:25 PM > *To:* CLUE > > > *Subject:* Re: [clue] Data model - agreement on objective and basic approach > > I think this is a reasonable split and I don't think it's that much of a > killer task to do so. We have talked in the past about whether we > should split some material from the framework. I think doing so will > make it easier for individuals to edit the various pieces. We will of > course have to ensure consistency. However, this approach adds some > good checks and balances, I believe. This model is quite similar to > what worked very well for the XCON work and it's quite similar to what > other WGs are doing (e.g., SIPREC). > > The chairs have delayed updating our milestones since we had not decided > individual deliverables related to the solution. > > As chair I would like to gauge consensus on this approach. So, if > people could please respond as to whether they support the general idea > of splitting the work into the following documents/deliverables: > > 1) Framework > > 2) Data model > > 3) Protocol > > 4) Call Flows > > If we can get consensus on the basic idea, then we can work out the > details starting with Simon's suggestion. > > I do have one comment about the "orchestration document" as I think that > might be appropriate for the framework, but we could certainly work on > that separately and decide later. > > Thanks, > > Mary. > > On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano > wrote: > > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final section of the > data model, which provides 'one possible' example of how to formally > describe the things in the document); > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the > protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. > > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside the WG. I > would like it to represent an orchestration document, providing an > overview of issues, requirements, architecture and protocols. > > A sort of summary reference for all of the related "drill-down" > documents, each expanding on a specific WG item (data model, > protocol, call flows, etc.). > > I acknowledge the fact that this looks much like a revolution, but I > nonetheless believe that we already have most of the needed material > at hand and just need to better distribute it across the documents > produced by the WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, > > When you say that you want to remove "all" the data model stuff > from the framework can you be a bit more specific as to what > parts you want removed? > > Regards, Christian > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > > Hi all, > > just to be clear on the current structure of the data model > schema: all the things you find there were 'extracted' (by > Roberta and me) from information currently contained inside the > framework draft (as well as from some side documents, associated > with either the data model or the envisaged call flows). So, > unless we have misinterpreted the above document(s) (which is > obviously possible), we should first of all focus on the > framework in order to try and converge on an agreed-upon CLUE > architecture. Once done with this, we can fine-tune the data > model. As I already stated on this list, it is my personal > opinion that we should remove from the framework document all of > the data-model stuff that it currently contains, and rather > focus on a clear definition of framework components and > interfaces. I might look naif, but I would like to arrive at an > 'ordinary' set of documents: (i) general framework; (ii) data > model; (iii) clue protocol (with advertisement and configuration > messages); (iv) call flows (showing how SDP O/A and CLUE > protocol messages concur in effectively setting up a CLUE session). > > As to the 'UML vs XML' querelle, I would suggest that: > > 1. Both UML class diagrams and XML schema can be adopted for the > description of the data model, i.e., the STATIC part of the > framework, associated with the description of what some of you > properly called a 'CLUE instance'; > 2. UML sequence diagrams can be adopted to describe CLUE call > flows, i.e. the DYNAMIC part of the framework, which clearly > envisages the co-existence of SDP and CLUE protocol messages. > XML schemas are not suitable for this dynamic part. > > This said, it is clear that CLUE protocol messages (in > particular, CLUE advertisements) will be constructed by > leveraging information contained inside a CLUE instance. Which > parts of a CLUE instance should go into an advertisement and > which should be carried inside SDP can be a matter of discussion. > > My 2 cents, > > Simon > > > Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: > > On 10/29/12 6:23 PM, Roni Even wrote: > > Paul, > This was the statement I answered "no" > " The general agreement on the call is that the data model as > reflected in > draft-presta-clue-data-model-schema describes the data needed by > the CLUE > application" > I disagree that it reflects that data needed by a CLUE > application and I > explained why. > > > OK, fair enough. > > Mary can comment, but my take was that the point of her question > was to distinguish between two alternatives: > - the data model represents all the data needed by the clue app. > (which implies to me that it encompasses all the data in the > framework.) > - the data model represents the data to be exchanged in > clue messages. > > It is a bigger deal if the framework includes things that are > not needed by the clue application. I was of the impression > that, except for some fine tuning, we were largely in agreement > on the framework. > > If we don't have consensus on *that* then resolving that is of > higher priority that much of the other stuff we are discussing. > > Thanks, > Paul > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org ] On > Behalf Of Paul > Kyzivat > Sent: 29 October, 2012 9:46 PM > To: clue@ietf.org > > Subject: Re: [clue] Data model - agreement on objective and > basic approach > > On 10/29/12 3:19 PM, Roni Even wrote: > > Hi, > > My view is 'no". I still fail to see the need for the encoding > groups > and individual encodes. > > In the current definition of capture scene, I am not sure what > is the > meaning of different individual encodes and eventually the receiver > can define what it can receive (Typically H.264 is symmetric in > terms > of profile but does not need to be in the level) and can ask for > specific resolution with the SDP image attribute > > > ISTM that you are answering a different question than the one > Mary asked. > You seem to be saying that you disagree with the framework as it > is - that > it can/should be simpler. > > That is a separate question. If such changes were made it might > affect a > lot. > > Thanks, > Paul > > Roni Even > > *From:*clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org ] > *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on objective and basic > approach > > On the call earlier today, we also discussed the data model. The > general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the > CLUE application - i.e., it's the CLUE instance concept. It does not > directly reflect the contents of a CLUE message. The > application data > would be used to populate CLUE messages, as well as SDP and would > reflect updates based on both the CLUE and SDP signaling. > > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would be > helpful. If you reply "No", please explain why. > > Regards, > > Mary > > as CLUE WG co-chair > > > > _______________________________________________ > 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 > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: > +39 081 7683816 > e-mail: spromano@unina.it > > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > _______________________________________________ > 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 > > -- > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > > Computer Science Department > Phone: +39 081 7683823 -- Fax: > +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/simonpietro.romano > > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > 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 ron.even.tlv@gmail.com Tue Oct 30 23:45:36 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DF7F21F86F9 for ; Tue, 30 Oct 2012 23:45:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kljS4C6ASK81 for ; Tue, 30 Oct 2012 23:45:35 -0700 (PDT) Received: from mail-ea0-f172.google.com (mail-ea0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id B105021F8435 for ; Tue, 30 Oct 2012 23:45:34 -0700 (PDT) Received: by mail-ea0-f172.google.com with SMTP id k13so467400eaa.31 for ; Tue, 30 Oct 2012 23:45:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; bh=eQ7djaDTQN1giqHxEpc3Qf1mbaEVHBSRWIR67DHfeE4=; b=CfLYCRaaWGjLpYzwU1kz4yVfaFoEm6MVrcxbI846C6k+iHofMrtAGVdjVJv0yOB3yC gcACRyU4y+OXY9dS9hdMUH4fuBPCoNipnxIOyQAnqjGBFogYzyKuUO+KkjsN9wC6GvHR bGHyOuFLNdaGEGQluSeyNfKwR9zxjInQPIsYnYpGm9DWpzpwyNODsNhngyxhThaVfyOV LyJqL1oG6HjTQJbr3fkOh8I+NCUqXhzmd68mOl1SrtV4MFTNtugUlRwc5hxT6KKe+c1e ykv2tJLbj961WAYiZlfJMEhm5HGGFdMDMT5lcBSi/AXtN1MqP/kFXmtWD88XXqjA1k/w 52jA== Received: by 10.14.179.136 with SMTP id h8mr70181823eem.7.1351665933710; Tue, 30 Oct 2012 23:45:33 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id t7sm6059737eel.14.2012.10.30.23.45.30 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 30 Oct 2012 23:45:32 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" , References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> <01a701cdb6f2$8a772f60$9f658e20$@gmail.com> <50906F0D.1020004@alum.mit.edu> In-Reply-To: <50906F0D.1020004@alum.mit.edu> Date: Wed, 31 Oct 2012 08:43:19 +0200 Message-ID: <01c401cdb733$062add60$12809820$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1H205IYhCmcjSpxYAUxN6zg5tsgC/Cc7eAw1ugkYCVsjGeAJj9POrAiIDFmQCKr40BgIYU8RPAL7MWZgBdCoLEQHfqE8SAfWEwnQCO2SgjZbKqA/w Content-Language: en-us Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 31 Oct 2012 06:45:36 -0000 Paul, I am saying that CLUE does not work without mapping of RTP streams (identified by SSRC) and Media Captures, it is true for static or = dynamic mapping.=20 Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Paul Kyzivat Sent: 31 October, 2012 2:22 AM To: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic = approach On 10/30/12 7:01 PM, Roni Even wrote: > Mary, > > Just as a point that CLUE does not work if you cannot say which SSRC=20 > is a specific media capture in CLUE I have now gotten lost in this thread. I don't understand what in the = thread this comment was intended to respond to. But responding to just this statement, it sounds like a denial of the dynamic mapping, which explicitly separates the identification of a = capture (actually capture encoding) from an SSRC. So are you saying thata CLUE does not work with the dynamic mapping? Thanks, Paul > Roni > > *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf = > Of *Mary Barnes > *Sent:* 30 October, 2012 11:49 PM > *To:* Roni Even > *Cc:* CLUE > *Subject:* Re: [clue] Data model - agreement on objective and basic=20 > approach > > I think that would belong in the protocol document - that is where the > SIPREC WG has described their usage of RTP. Any specific changes to > the RTP and SDP would of course be submitted as documents in the=20 > AVTCORE and MMUSIC WGs. > > However, it may be better to keep that document separate for a while - = > that is also the model that SIPREC used/ > > Mary. > > On Tue, Oct 30, 2012 at 4:42 PM, Roni Even=20 > > = wrote: > > Hi Mary, > > What about the mapping of RTP streams to Media Captures, where does it = > fall > > BTW: the mapping may require an identfier for the media capture > > Roni > > ---------------------------------------------------------------------- > -- > > *From:*clue-bounces@ietf.org =20 > [clue-bounces@ietf.org ] on behalf of=20 > Mary Barnes [mary.ietf.barnes@gmail.com=20 > ] > *Sent:* Tuesday, October 30, 2012 11:25 PM > *To:* CLUE > > > *Subject:* Re: [clue] Data model - agreement on objective and basic=20 > approach > > I think this is a reasonable split and I don't think it's that much of = > a killer task to do so. We have talked in the past about whether we=20 > should split some material from the framework. I think doing so will=20 > make it easier for individuals to edit the various pieces. We will of = > course have to ensure consistency. However, this approach adds some > good checks and balances, I believe. This model is quite similar to > what worked very well for the XCON work and it's quite similar to what = > other WGs are doing (e.g., SIPREC). > > The chairs have delayed updating our milestones since we had not=20 > decided individual deliverables related to the solution. > > As chair I would like to gauge consensus on this approach. So, if=20 > people could please respond as to whether they support the general=20 > idea of splitting the work into the following documents/deliverables: > > 1) Framework > > 2) Data model > > 3) Protocol > > 4) Call Flows > > If we can get consensus on the basic idea, then we can work out the=20 > details starting with Simon's suggestion. > > I do have one comment about the "orchestration document" as I think=20 > that might be appropriate for the framework, but we could certainly=20 > work on that separately and decide later. > > Thanks, > > Mary. > > On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano=20 > > wrote: > > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final section of=20 > the data model, which provides 'one possible' example of how to=20 > formally describe the things in the document); > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the=20 > protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. > > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside the WG.=20 > I would like it to represent an orchestration document, providing an=20 > overview of issues, requirements, architecture and protocols. > > A sort of summary reference for all of the related "drill-down" > documents, each expanding on a specific WG item (data model, > protocol, call flows, etc.). > > I acknowledge the fact that this looks much like a revolution, but = I > nonetheless believe that we already have most of the needed = material > at hand and just need to better distribute it across the documents > produced by the WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, > > When you say that you want to remove "all" the data model = stuff > from the framework can you be a bit more specific as to what > parts you want removed? > > Regards, Christian > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > > Hi all, > > just to be clear on the current structure of the data model > schema: all the things you find there were 'extracted' (by > Roberta and me) from information currently contained inside = the > framework draft (as well as from some side documents, = associated > with either the data model or the envisaged call flows). So, > unless we have misinterpreted the above document(s) (which is > obviously possible), we should first of all focus on the > framework in order to try and converge on an agreed-upon CLUE > architecture. Once done with this, we can fine-tune the data > model. As I already stated on this list, it is my personal > opinion that we should remove from the framework document all = of > the data-model stuff that it currently contains, and rather > focus on a clear definition of framework components and > interfaces. I might look naif, but I would like to arrive at = an > 'ordinary' set of documents: (i) general framework; (ii) data > model; (iii) clue protocol (with advertisement and = configuration > messages); (iv) call flows (showing how SDP O/A and CLUE > protocol messages concur in effectively setting up a CLUE session). > > As to the 'UML vs XML' querelle, I would suggest that: > > 1. Both UML class diagrams and XML schema can be adopted for = the > description of the data model, i.e., the STATIC part of the > framework, associated with the description of what some of you > properly called a 'CLUE instance'; > 2. UML sequence diagrams can be adopted to describe CLUE call > flows, i.e. the DYNAMIC part of the framework, which clearly > envisages the co-existence of SDP and CLUE protocol messages. > XML schemas are not suitable for this dynamic part. > > This said, it is clear that CLUE protocol messages (in > particular, CLUE advertisements) will be constructed by > leveraging information contained inside a CLUE instance. Which > parts of a CLUE instance should go into an advertisement and > which should be carried inside SDP can be a matter of = discussion. > > My 2 cents, > > Simon > > > Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha = scritto: > > On 10/29/12 6:23 PM, Roni Even wrote: > > Paul, > This was the statement I answered "no" > " The general agreement on the call is that the data model as > reflected in > draft-presta-clue-data-model-schema describes the data needed = by > the CLUE > application" > I disagree that it reflects that data needed by a CLUE > application and I > explained why. > > > OK, fair enough. > > Mary can comment, but my take was that the point of her = question > was to distinguish between two alternatives: > - the data model represents all the data needed by the clue = app. > (which implies to me that it encompasses all the data in the > framework.) > - the data model represents the data to be exchanged in > clue messages. > > It is a bigger deal if the framework includes things that are > not needed by the clue application. I was of the impression > that, except for some fine tuning, we were largely in = agreement > on the framework. > > If we don't have consensus on *that* then resolving that is of > higher priority that much of the other stuff we are = discussing. > > Thanks, > Paul > > Roni > > -----Original Message----- > From: clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org ] = On > Behalf Of Paul > Kyzivat > Sent: 29 October, 2012 9:46 PM > To: clue@ietf.org > > Subject: Re: [clue] Data model - agreement on objective and > basic approach > > On 10/29/12 3:19 PM, Roni Even wrote: > > Hi, > > My view is 'no". I still fail to see the need for the encoding > groups > and individual encodes. > > In the current definition of capture scene, I am not sure what > is the > meaning of different individual encodes and eventually the receiver > can define what it can receive (Typically H.264 is symmetric = in > terms > of profile but does not need to be in the level) and can ask = for > specific resolution with the SDP image attribute > > > ISTM that you are answering a different question than the one > Mary asked. > You seem to be saying that you disagree with the framework as = it > is - that > it can/should be simpler. > > That is a separate question. If such changes were made it = might > affect a > lot. > > Thanks, > Paul > > Roni Even > > *From:*clue-bounces@ietf.org > > > [mailto:clue-bounces@ietf.org ] > *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on objective and = basic > approach > > On the call earlier today, we also discussed the data model. = The > general agreement on the call is that the data model as = reflected in > draft-presta-clue-data-model-schema describes the data needed = by the > CLUE application - i.e., it's the CLUE instance concept. It = does not > directly reflect the contents of a CLUE message. The > application data > would be used to populate CLUE messages, as well as SDP and = would > reflect updates based on both the CLUE and SDP signaling. > > If we can get agreement on that before the meeting, I believe = our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would = be > helpful. If you reply "No", please explain why. > > Regards, > > Mary > > as CLUE WG co-chair > > > > _______________________________________________ > 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 > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: > +39 081 7683816 > e-mail: spromano@unina.it > > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > > > > > > > _______________________________________________ > 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 > > -- > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > > Computer Science Department > Phone: +39 081 7683823 -- = Fax: > +39 081 7684219 > e-mail: spromano@unina.it = > http://www.comics.unina.it/simonpietro.romano > > > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > > > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > 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 ron.even.tlv@gmail.com Wed Oct 31 02:52:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BE921F8765 for ; Wed, 31 Oct 2012 02:52:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3d6TtwxZ-yYk for ; Wed, 31 Oct 2012 02:51:59 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id ADB6621F89E3 for ; Wed, 31 Oct 2012 02:51:58 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so722517eek.31 for ; Wed, 31 Oct 2012 02:51:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; bh=O1gzzzwW/JblBols7wlCrBoWSXwxCiiOhUQ2zdhULiY=; b=nWMxF4bCcyaBgjYxtGXF1YQcsLhz8LErm7J4OOFI/RjGvgv2P4Gz8yL2GiSRR9x916 sSYTziQM89bm2MiTFNsR3hHfNq0UuPl3d29BTdYJUgG9d964ABDkiiOIi2T4MpWFiiw/ 7uR3ZsbTd00WsY/iaEfLa0ZPMeFud1PNxub+RqrlYnFlvrGarlXkeoeiaTWpcL80z3k5 13N3iCogVNmeSx2bXLc+/3GBe11QACNRcJuXpJztLzQB+qnPYo/3o0BOQ+NAmlkxGPRH zfpenE1MJTekht0SyezdXzAk462bTMxDc+7Fza8F+Wb7gEhTaC376AB90SGwlcSJ0ngB EFwg== Received: by 10.14.203.69 with SMTP id e45mr83429756eeo.38.1351677117685; Wed, 31 Oct 2012 02:51:57 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id o49sm6954769eep.5.2012.10.31.02.51.55 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 02:51:56 -0700 (PDT) From: "Roni Even" To: Date: Wed, 31 Oct 2012 11:49:45 +0200 Message-ID: <01d301cdb74d$10857940$31906bc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D4_01CDB75D.D40F81C0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac23TQ7DCbEHUqp8RgSGgqGYQWiE0w== Content-Language: en-us Subject: [clue] Do we need the encodings as secified in the framework document - proposal to remove them from the framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Oct 2012 09:52:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01D4_01CDB75D.D40F81C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, >From the email discussion it looks to me that the concept of the encoding as specified in the framework document is not clear. I will try to describe my understanding of sections 7 and 8 of the framework document and explain why I think that it is not important to CLUE as specified. I am looking for response if my understanding of the encoding based on the framework is correct and how it will work for the examples I will provide bellow The purpose of the Encodings is to provide INFORMATION about the provider abilities to send streams. This relates to the available resources (compute and BW) of the providers. The encodings are constructed from encoding groups and each encoding group is include individual encodes. The encoding group provide a value for the total maximum BW and compute H264Mbps (note that it is H.264 specific) of all the individual encodes in the group that the provider can use to send audio and video. Each encoding group include a list of individual encodes (audio and /or video). These provide maximum values that can be used to instantiate a media stream by the provider. Each video individual encodes identified by an encodeID provides maximum values for BW, compute, resolution and frame rate for H.264. (BTW: the maxH264Mbps can be computed from the resolution and frame rate as defined in table 2 making it redundant). Each audio encode has only a BW value (no identifier). A media capture is associated with an encoding group !!!!! not an individual encoding. The provider can use one of the individual encoding to instantiate a media capture, each individual encoding can be used by one media capture, the decision of which one to use according to the framework is by the provider. The consumer does not select an individual encode. The maximum number of streams that can result from a particular encoding group is equal to the number of individual encodings in the group (note that this is why the example in the current data model allows only for one video and one audio streams). Section 8 of the framework talk about having more than one individual encoding assigned to a media capture (simulcast) and also claims that it can be done by the consumer but there is no way to do it since the media capture is associated only with an encoding group. There is no way for a consumer even to assign a specific individual encoding to a group. My view is that this mechanism does not work and can be removed. The reasons are given bellow The encoding as currently specified is provided as information since there is no way to map one or more individual encoding to a specific media capture The video is H.264 specific and not general The relation between the individual encode and encoding group makes it difficult to achieve a reasonable set even if the consumer will be able to select the mapping. This is due to the fact the total defined by the group limits the usage for individual encoding. For example if we have a three camera system and we set a value in the group for maxGroupH264Mbps and want to allow for simulcast (two resolutions), we will need to define six individual encodes, three with high resolution ( also high maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the compute resource can do all six it will reflected in the value of maxGroupH264Mbps but I assume that there is a constrain (otherwise why have encodings) making it lower. So if the consumer will ask for all six what will happen. Since there is more than one degree of freedom he will not be able to predict if he will get all or part on lower frame rate , if he will get only a subset of the streams, if he will get different resolutions. On the other hand if the 6 individual encodes will include lower values to allow for the group limit it will mean that a consumer not doing simulcast is limited by the fact the simulcast and ask (if possible) for only three streams, the individual encodes limit will be low so he will not be able to use the full compute resources. Section 8 concludes that the number of individual encodes in a group must allow for all media capture in a capture scene entry to be used simultaneously. So it look like this system does not work well for simulcast. What about no simulcast, is it needed. For example a three camera system that also have one presentation. My view that the cameras will be one capture scene and the presentation will be a second one. The question is if they all belong to one encoding group, here my view is "no" since they have different priority and should not compete for compute resources. So we will have two encoding groups one for presentation and one for the three cameras. For the three cameras each sending one stream I assume that the resource allocation will be a third for each so we will have three individual encode with the same values, this is the basic one and if it is a third than no need for advertising or configuring. Now if we also want to have an individual encode that has higher compute if the consumer wants only one capture (of the whole room), the group will have fourth one with higher value. So if there is way for consumer to configure individual encode when using three media captures, he may select the higher capability one with two lower ones. The total will be limited by the encoding group value and again it is not clear how the actual streams will be encoded to address the group limit since there are multiple options. To summarize I do not see value in the encoding as currently specified since they only provide information and no option for configuration. The value of it as information does not justify specifying them and if the intention is to allow configurations of individual encoding it must be reflected and the explained how it works. My proposal is at the moment to remove the encoding until we get some text that defines how to use it for configuring encoding to media captures including for the simulcast case Thanks Roni Even ------=_NextPart_000_01D4_01CDB75D.D40F81C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

From the email = discussion it looks to me that the concept of the encoding as specified = in the framework document is not clear. I will try to describe my = understanding of sections 7 and 8 of the framework document and explain = why I think that it is not important to CLUE as specified. I am looking = for response if my understanding of the encoding based on the framework = is correct and how it will work for the examples I will provide = bellow

 

The purpose of the Encodings is to provide INFORMATION = about the provider abilities to send streams. This relates to the = available resources (compute and BW) of the providers.

 

The = encodings are constructed from encoding groups and each encoding group = is include individual encodes.

 

The encoding = group provide a value for the total maximum BW and compute H264Mbps = (note that it is H.264 specific) of all the individual encodes in the = group that the provider can use to send audio and = video.

 

Each encoding group include a list of individual = encodes  (audio and /or video). These provide maximum values that = can be used to instantiate a media stream by the = provider.

 

Each video individual encodes identified by an = encodeID provides maximum values  for BW, compute, resolution and = frame rate for H.264. (BTW: the maxH264Mbps can be computed from the = resolution and frame rate as defined in table 2 making it redundant). =

Each audio encode has only a BW = value (no identifier).

 

 

A media = capture is associated with an encoding group !!!!! not an individual = encoding.

 

The provider can use one of the individual encoding to = instantiate a media capture, each individual encoding can be used by one = media capture, the decision of which one to use according to the = framework is by the provider. The consumer does not select an individual = encode.

 

The maximum number of streams that can result from a = particular encoding group is equal to the number of individual encodings = in the group (note that this is why the example in the current data = model allows only for one video and one audio streams).

 

 

Section 8 of = the framework talk about having more than one individual encoding = assigned to a media capture (simulcast) and also claims that it can be = done by the consumer but there is no way to do it since the media = capture is associated only with an encoding group. There is no way for a = consumer even to assign a specific individual encoding to a = group.

 

 

My view is = that this mechanism does not work and can be removed. The reasons are = given bellow

 

The encoding as currently specified is provided as = information since there is no way to map one or more individual encoding = to a specific media capture

 

The video is = H.264 specific and not general

 

The relation = between the individual encode and encoding group makes it difficult to = achieve a reasonable set even if the consumer will be able to select the = mapping. This is due to the fact the total defined by the group limits = the usage for individual encoding. For example if  we have a three = camera system and we set a value in the  group for maxGroupH264Mbps = and want to allow for simulcast (two resolutions), we will need to = define six individual encodes, three with high resolution ( also high = maxH264Mbps) and three lower resolution with lower maxH264Mbps. If the = compute resource can do all six it will  reflected in the value of = maxGroupH264Mbps but I assume that there is a constrain (otherwise why = have encodings) making it lower. So if the consumer will ask for all six = what will happen. Since there is more than one degree of freedom he will = not be able to predict if he will get all or part on lower frame rate , = if he will get only a subset of the streams, if he will get different = resolutions.

On the other hand if = the 6 individual encodes will include lower values to allow for the = group limit it will mean that a consumer not doing simulcast is limited = by the fact the simulcast and ask (if possible) for only three streams, = the individual encodes limit will be low so he will not be able to use = the full compute resources.

 

Section 8 = concludes that the number of individual encodes in a group must allow = for all media capture in a capture scene entry to be used = simultaneously.

 

So it look = like this system does not work well for simulcast. What about no = simulcast, is it needed. For example a three camera system that also = have one presentation. My view that the cameras will be one capture = scene and the presentation will be a second one. The question is if they = all belong to one encoding group, here my view is “no” since = they have different priority and should not compete for compute = resources. So we will have two encoding groups one for presentation and = one for the three cameras. For the three cameras each sending one stream = I assume that the resource allocation will be a third for each so we = will have three individual encode with the same values, this is the = basic one and if it is a third than no need for advertising or = configuring. Now if we also want to have an individual encode that has = higher compute if the consumer wants only one capture (of the whole = room), the group will have fourth one with higher value. So if there is = way for consumer to configure individual encode when using three media = captures, he may select the higher capability one with two lower ones. = The total will be limited by the encoding group value and again it is = not clear how the actual streams will be encoded to address the group = limit since there are multiple options.

 

 

To summarize = I do not see value in the encoding as currently specified since they = only provide information and no option for configuration. The value of = it as information does not justify specifying them and if the intention = is to allow configurations of individual encoding it must be reflected = and the explained how it works.

 

My proposal = is at the moment to remove the encoding until we get some text that = defines how to use it for configuring encoding to media captures = including for the simulcast case

 

 

Thanks

 

Roni = Even

 

------=_NextPart_000_01D4_01CDB75D.D40F81C0-- From roberta.presta@unina.it Wed Oct 31 03:42:33 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 B2D4F21F8775 for ; Wed, 31 Oct 2012 03:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UDyTovatIlZ for ; Wed, 31 Oct 2012 03:42:33 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id BA6C221F873D for ; Wed, 31 Oct 2012 03:42:32 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.193]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q9VAgNqk002302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 11:42:24 +0100 Message-ID: <5091009C.8070805@unina.it> Date: Wed, 31 Oct 2012 11:42:36 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Paul Kyzivat References: <508A6242.80001@unina.it> In-Reply-To: <508A6242.80001@unina.it> Content-Type: multipart/alternative; boundary="------------070704010404030302070403" X-Antivirus: avast! (VPS 121031-0, 31/10/2012), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] again on 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, 31 Oct 2012 10:42:33 -0000 This is a multi-part message in MIME format. --------------070704010404030302070403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Paul, I don't see any problem in putting media captures inside capture scenes and delete the section under . The sceneIDREF attribute of does not need to exist anymore, since the coordinate space would be the one of the involving capture scene. The remaining point now is the new definition of the media capture type, which presents the section that allows to contain spatial information or, alternatively, to mark the media capture as "non spatially definible". What do you think about that proposal? I copy below the schema snapshot for convenience. Cheers, Roberta ---------------------- Roberta, I don't see how this addresses the problem. I think I see why. Comment inline On 10/26/12 6:13 AM, Roberta Presta wrote: [snip] * The element is referred to the coordinate space of the capture scene indicated in the "sceneIDREF" attribute. The framework doesn't seem to force a capture to be associated with only one scene (or, at least, I don't remember to have read such a constraint in the framework document). If a capture is involved in more than one scene, more than one should be provided, each one related to the coordinate space of the involving scene. Whether clear or not, IMO it is *intended* that each capture is associated (belongs to) a single scene. ISTM an obvious way to represent this would be to have an instance of mediaCapturesType within captureSceneType, rather than within clueInfoType. Thanks, Paul --------------070704010404030302070403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 
Hi Paul, 

I don't see any problem in putting media captures inside capture scenes and delete the <mediaCaptures> section under <clueInfo>.
The sceneIDREF attribute of <spatialInformation> does not need to exist anymore, since the coordinate space would be the one of the involving capture scene.
The remaining point now is the new definition of the media capture type, which presents the <choice> section that allows to contain spatial information or, 
alternatively, to mark the media capture as "non spatially definible".
What do you think about that proposal?
I copy below the schema snapshot for convenience.

Cheers,

Roberta


     <!-- MEDIA CAPTURE TYPE -->
     <xs:complexType name="mediaCaptureType" abstract="true">
        <xs:sequence>
         <xs:element name="description" type="xs:string" minOccurs="0"/>
         <xs:element name="capturedMedia" type="xs:string" minOccurs="0"/>             
         <xs:element name="encGroupIDREF" type="xs:IDREF"/>
         <xs:element name="content" type="xs:string" minOccurs="0"/>         
         <xs:element name="switched" type="xs:boolean" minOccurs="0"/>  
         <xs:element name="composed" type="xs:boolean" minOccurs="0"/>                                   	                  
         <xs:element name="maxCaptureEncodings" type="xs:unsignedInt" minOccurs="0"/>
         <xs:choice>
             <xs:sequence>
              <xs:element name="spatialInformation" type="tns:spatialInformationType" maxOccurs="unbounded"/>
            </xs:sequence>             	
         	<xs:element name="nonSpatiallyDefinible" type="xs:boolean" fixed="true"/>         		         
         </xs:choice>                                                                           
         <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>                  
        </xs:sequence>
        <xs:attribute name="captureID" type="xs:ID" use="required"/>
        <xs:anyAttribute namespace="##other" processContents="lax"/>
     </xs:complexType>
     
     <!-- SPATIAL INFORMATION TYPE -->
     <xs:complexType name="spatialInformationType">
     <xs:sequence>            
       <xs:element name="capturePoint" type="capturePointType"/>
       <xs:element name="captureArea" type="captureAreaType" minOccurs="0"/>
       <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>        
      </xs:sequence>            
       <xs:anyAttribute namespace="##other" processContents="lax"/>    
     </xs:complexType>









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

Roberta,
I don't see how this addresses the problem. I think I see why. Comment inline 
On 10/26/12 6:13 AM, Roberta Presta wrote:
[snip]

* The <spatialInformation> element is referred to the coordinate space
of the capture scene indicated in the "sceneIDREF" attribute.
The framework doesn't seem to force a capture to be associated with only
one scene (or, at least, I don't remember to have read such a constraint
in the framework document).
If a capture is involved in more than one scene, more than one
<spatialInformation> should be provided, each one related to the
coordinate space of the involving scene.


Whether clear or not, IMO it is *intended* that each capture is associated (belongs to) a single scene. ISTM an obvious way to represent this would be to have an instance of mediaCapturesType within captureSceneType, rather than within clueInfoType. 
Thanks,

Paul



--------------070704010404030302070403-- From roberta.presta@unina.it Wed Oct 31 04:06:33 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 43E0D21F8734 for ; Wed, 31 Oct 2012 04:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MHrUj74wxqh for ; Wed, 31 Oct 2012 04:06:32 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 02B5921F872C for ; Wed, 31 Oct 2012 04:06:31 -0700 (PDT) Received: from [127.0.0.1] ([143.225.229.193]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id q9VB6NSG005363 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Oct 2012 12:06:29 +0100 Message-ID: <5091063C.8030603@unina.it> Date: Wed, 31 Oct 2012 12:06:36 +0100 From: Roberta Presta User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Roni Even References: <01ac01cdb6f7$057e19e0$107a4da0$@gmail.com> In-Reply-To: <01ac01cdb6f7$057e19e0$107a4da0$@gmail.com> Content-Type: multipart/alternative; boundary="------------070103050404020505040005" X-Antivirus: avast! (VPS 121031-0, 31/10/2012), Outbound message X-Antivirus-Status: Clean Cc: clue@ietf.org Subject: Re: [clue] review of http://tools.ietf.org/id/draft-presta-clue-data-model-schema-01 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, 31 Oct 2012 11:06:33 -0000 This is a multi-part message in MIME format. --------------070103050404020505040005 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Roni, please see inline. Il 31/10/2012 00:33, Roni Even ha scritto: > > Hi, > > I looked at the updated version and have a couple of comments > > 1 I already said in the previous version that in the example VC0, VC1, > and VC2 must have spatial information since otherwise it is not clear > what they represent. > Of course you are right, the example is missing that spatial information. We are currently discussing a new XML Schema definition for media captures. We will upload the updated example in the new version of the draft, according to that definition modification. The new media capture definition would force captures to be spatially described or to be marked as non-spatially definible (the last case could be the one of registrations, DVDs, registered presentation, or external stream). According to that proposal, in the next version, VC0, VC1, and VC2 will be provided with a element containing information about capture points, capture axis points and capture areas. > 2 I noticed the new *nativeAspectRatio attribute. I think we discussed > it in IETF84 and it was not agreed to add any new information from > *draft-romanow-clue-data-model-01 to the framework. I suggest that > before having it here we should see if it should be added to the > framework as an attribute. The text in > draft-romanow-clue-data-model-01 says it is helpful for rendering (not > for advertise or config) and this information is available as part of > the payload. > Thanks for signaling it, I missed that discussion. I would just remark that, in the data model draft, we are trying to organize all information aiming at describing what are the media captures, spatial information and encoding capabilities of a telepresence room endpoint. Advertisement and configure messages are not aimed at carrying the document we are defining "as a whole" in their bodies (they are not formally defined anywhere, up to now, as far as I know). Native aspect ratio conveys further information about a video capture, that's why we placed it as an optional field in the formal description of a video capture. > 3 What is the purpose of the new clueinfoid. Is it to identify the > version of the data?. Need some text to explain it. > At this point of the work, we put it as a placeholder... It would be an identifier for the document describing the general capabilities of a CLUE telepresence room. I think versioning should be managed for this kind of documents, maybe we can discuss about the definition of an appropriate attribute aimed to that purpose. What are your feelings about that? Cheers, Roberta > Thanks > > Roni Even > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue --------------070103050404020505040005 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Roni,

please see inline.

Il 31/10/2012 00:33, Roni Even ha scritto:

Hi,

I looked at the updated version and have a couple of comments

 

1 I already said in the previous version that in the example VC0, VC1, and VC2 must have spatial information since otherwise it is not clear what  they represent.


Of course you are right, the example is missing that spatial information.
We are currently discussing a new XML Schema definition for media captures. We will upload the updated example in the new version of the draft,  according to that definition modification.
The new media capture definition would force captures to be spatially described or to be marked as non-spatially definible (the last case could be the one of registrations, DVDs, registered presentation, or external stream). According to that proposal, in the next version, VC0, VC1, and VC2 will be provided with a <spatialInformation> element containing information about capture points, capture axis points and capture areas.

 

2 I noticed the new nativeAspectRatio attribute. I think we discussed it in IETF84 and it was not agreed to add any new information from draft-romanow-clue-data-model-01 to the framework. I suggest that before having it here we should see if it should be added to the framework as an attribute. The text in draft-romanow-clue-data-model-01 says it is helpful for rendering (not for advertise or config) and this information is available as part of the payload.


Thanks for signaling it, I missed that discussion. I would just remark that, in the data model draft, we are trying to organize all information aiming at describing what are the media captures, spatial information and encoding capabilities of a telepresence room endpoint. Advertisement and configure messages are not aimed at carrying the document we are defining "as a whole" in their bodies (they are not formally defined anywhere, up to now, as far as I know).
Native aspect ratio conveys further information about a video capture, that's why we placed it as an optional field in the formal description of a video capture.


 

3 What is the purpose of the new clueinfoid. Is it to identify the version of the data?. Need some text to explain it.


At this point of the work, we put it as a placeholder... It would be an identifier for the document describing the general capabilities of a CLUE telepresence room.
I think versioning should be managed for this kind of documents, maybe we can discuss about the definition of an appropriate attribute aimed to that purpose.
What are your feelings about that?

Cheers,

Roberta

 

Thanks

Roni Even

 

 

 

 

 

 



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

--------------070103050404020505040005-- From ron.even.tlv@gmail.com Wed Oct 31 06:19: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 0150521F87C1 for ; Wed, 31 Oct 2012 06:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.491 X-Spam-Level: X-Spam-Status: No, score=-3.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8FMZt4VuHmQA for ; Wed, 31 Oct 2012 06:19:43 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6674C21F87B2 for ; Wed, 31 Oct 2012 06:19:43 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so853586eek.31 for ; Wed, 31 Oct 2012 06:19:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=2j7cionp+HqAF84yMbxfjfiM1FoWHds+H4KGs6glSWM=; b=JDBCWrbzH582SMoK2Vj7noxaNTvcn5sBmKQwIigCAK2oHcV1A1ILZE0Av4BlVu47Ez 39X+aQUyU6xBJGl471wobL6rQlqP0ypW6sFkE++ynpUHdedCSJJpQCm/KaCSHK1VLLVE 4Pn1GtdkwA3Yv/MoNEHTZ1soZjAuF7W1FdpbWgbc1N/2JfbUcQSPgiKo554cZSTWrYWB m2r7ZCz71FIel6lDeHxHaI4hoNGtv1Bv5nqw6v0+QDC4Ipy2Tmn1uMYTOUjsWvRHkHRg o0VJrRTynoT98WJA8tHt1tUF+8gDdl+g41V6ZsG07vf5ZDVWr2kAfLjk12kabB3aU8K2 5bNA== Received: by 10.14.179.136 with SMTP id h8mr73464569eem.7.1351689582408; Wed, 31 Oct 2012 06:19:42 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id c6sm7860001eep.17.2012.10.31.06.19.39 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 06:19:41 -0700 (PDT) From: "Roni Even" To: "'Simon Pietro Romano'" , "'Christian Groves'" References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> In-Reply-To: <508FAABC.2000404@unina.it> Date: Wed, 31 Oct 2012 15:17:29 +0200 Message-ID: <020401cdb76a$16131c60$42395520$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1H205IYhCmcjSpxYAUxN6zg5tsgC/Cc7eAw1ugkYCVsjGeAJj9POrAiIDFmQCKr40BgIYU8RPlw0yuGA= Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 31 Oct 2012 13:19:45 -0000 Hi Simon, This will make the framework empty, section 1-4 do not have any = information that merit a document. Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Simon Pietro Romano Sent: 30 October, 2012 12:24 PM To: Christian Groves Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic = approach Hi Christian, a rough estimation would be the following: a) keep sections 1 through 4 inside the framework document; b) move sections 5 through 8 to the data model document c) move the XML schema to the data model document (final section of the = data model, which provides 'one possible' example of how to formally describe = the things in the document); d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protocol document; e) move subsection 9.4 to the call flows document; f) move section 10 to the data model document; g) move section 11 to the call flows document. Obviously, the resulting framework document should be revised (and enriched) in view of the proposed distribution of work inside the WG. I would like it to represent an orchestration document, providing an = overview of issues, requirements, architecture and protocols. A sort of summary reference for all of the related "drill-down" documents, each expanding = on a specific WG item (data model, protocol, call flows, etc.). I acknowledge the fact that this looks much like a revolution, but I nonetheless believe that we already have most of the needed material at = hand and just need to better distribute it across the documents produced by = the WG. Cheers, Simon Il 30/10/2012 10:33, Christian Groves ha scritto: > Hello Simon, > > When you say that you want to remove "all" the data model stuff from=20 > the framework can you be a bit more specific as to what parts you want = > removed? > > Regards, Christian > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >> Hi all, >> >> just to be clear on the current structure of the data model schema:=20 >> all the things you find there were 'extracted' (by Roberta and me)=20 >> from information currently contained inside the framework draft (as=20 >> well as from some side documents, associated with either the data=20 >> model or the envisaged call flows). So, unless we have misinterpreted = >> the above document(s) (which is obviously possible), we should first=20 >> of all focus on the framework in order to try and converge on an=20 >> agreed-upon CLUE architecture. Once done with this, we can fine-tune=20 >> the data model. As I already stated on this list, it is my personal=20 >> opinion that we should remove from the framework document all of the=20 >> data-model stuff that it currently contains, and rather focus on a=20 >> clear definition of framework components and interfaces. I might look = >> naif, but I would like to arrive at an 'ordinary' set of documents: >> (i) general framework; (ii) data model; (iii) clue protocol (with=20 >> advertisement and configuration messages); (iv) call flows (showing=20 >> how SDP O/A and CLUE protocol messages concur in effectively setting=20 >> up a CLUE session). >> >> As to the 'UML vs XML' querelle, I would suggest that: >> >> 1. Both UML class diagrams and XML schema can be adopted for the=20 >> description of the data model, i.e., the STATIC part of the=20 >> framework, associated with the description of what some of you=20 >> properly called a 'CLUE instance'; 2. UML sequence diagrams can be=20 >> adopted to describe CLUE call flows, i.e. the DYNAMIC part of the=20 >> framework, which clearly envisages the co-existence of SDP and CLUE=20 >> protocol messages. XML schemas are not suitable for this dynamic=20 >> part. >> >> This said, it is clear that CLUE protocol messages (in particular,=20 >> CLUE advertisements) will be constructed by leveraging information=20 >> contained inside a CLUE instance. Which parts of a CLUE instance=20 >> should go into an advertisement and which should be carried inside=20 >> SDP can be a matter of discussion. >> >> My 2 cents, >> >> Simon >> >> >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >> >>> On 10/29/12 6:23 PM, Roni Even wrote: >>>> Paul, >>>> This was the statement I answered "no" >>>> " The general agreement on the call is that the data model as=20 >>>> reflected in draft-presta-clue-data-model-schema describes the data = >>>> needed by the CLUE application" >>>> I disagree that it reflects that data needed by a CLUE application=20 >>>> and I explained why. >>> >>> OK, fair enough. >>> >>> Mary can comment, but my take was that the point of her question was = >>> to distinguish between two alternatives: >>> - the data model represents all the data needed by the clue app. >>> (which implies to me that it encompasses all the data in the >>> framework.) >>> - the data model represents the data to be exchanged in clue=20 >>> messages. >>> >>> It is a bigger deal if the framework includes things that are not=20 >>> needed by the clue application. I was of the impression that, except = >>> for some fine tuning, we were largely in agreement on the framework. >>> >>> If we don't have consensus on *that* then resolving that is of=20 >>> higher priority that much of the other stuff we are discussing. >>> >>> Thanks, >>> Paul >>> >>>> Roni >>>> >>>> -----Original Message----- >>>> From: clue-bounces@ietf.org =20 >>>> [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: 29 October, 2012 9:46 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] Data model - agreement on objective and basic=20 >>>> approach >>>> >>>> On 10/29/12 3:19 PM, Roni Even wrote: >>>>> Hi, >>>>> >>>>> My view is 'no". I still fail to see the need for the encoding=20 >>>>> groups and individual encodes. >>>>> >>>>> In the current definition of capture scene, I am not sure what is=20 >>>>> the meaning of different individual encodes and eventually the=20 >>>>> receiver can define what it can receive (Typically H.264 is=20 >>>>> symmetric in terms of profile but does not need to be in the=20 >>>>> level) and can ask for specific resolution with the SDP image=20 >>>>> attribute >>>> >>>> ISTM that you are answering a different question than the one Mary=20 >>>> asked. >>>> You seem to be saying that you disagree with the framework as it is >>>> - that >>>> it can/should be simpler. >>>> >>>> That is a separate question. If such changes were made it might=20 >>>> affect a lot. >>>> >>>> Thanks, >>>> Paul >>>> >>>>> Roni Even >>>>> >>>>> *From:*clue-bounces@ietf.org =20 >>>>> [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes >>>>> *Sent:* 29 October, 2012 7:52 PM >>>>> *To:* CLUE >>>>> *Subject:* [clue] Data model - agreement on objective and basic=20 >>>>> approach >>>>> >>>>> On the call earlier today, we also discussed the data model. The=20 >>>>> general agreement on the call is that the data model as reflected=20 >>>>> in draft-presta-clue-data-model-schema describes the data needed=20 >>>>> by the CLUE application - i.e., it's the CLUE instance concept. It = >>>>> does not directly reflect the contents of a CLUE message. The=20 >>>>> application data would be used to populate CLUE messages, as well=20 >>>>> as SDP and would reflect updates based on both the CLUE and SDP=20 >>>>> signaling. >>>>> >>>>> If we can get agreement on that before the meeting, I believe our=20 >>>>> discussions can be much more productive. If folks could please=20 >>>>> reply "Yes" or "No" reflecting agreement with the above, that=20 >>>>> would be helpful. If you reply "No", please explain why. >>>>> >>>>> Regards, >>>>> >>>>> Mary >>>>> >>>>> as CLUE WG co-chair >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org =20 >>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org =20 >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org =20 >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 >> e-mail: spromano@unina.it >> >> <> rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> >> >> _______________________________________________ >> 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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 081 7684219 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From ron.even.tlv@gmail.com Wed Oct 31 06:22:09 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E59421F87DA for ; Wed, 31 Oct 2012 06:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.5 X-Spam-Level: X-Spam-Status: No, score=-3.5 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qd4c+0-sYhm1 for ; Wed, 31 Oct 2012 06:22:03 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 54D2021F87CB for ; Wed, 31 Oct 2012 06:22:02 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so855236eek.31 for ; Wed, 31 Oct 2012 06:22:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=wGaZXjbEWQuQqGCEPz77EpZiH76HlggxQFblzKNE8J4=; b=TtQDpqwEEBF1Yylg8QQWXetzSG1gp8q91h1a9CDRup82w2EtCPQxc3CGRLh8S8kAcf XowKJbz/t49LmYreE6XRFS6V8WWLMsxA5IFNsDk0ILl1rr5op7ywYvzR7x/fdkG6LZ7T Bjsy7RdLf7Ky6W5wvfqYYe0josIZl/rkT3/PASv/qx4JxZNCCVCkKWInWu8pHU1uOl8+ +Xr/d+BaY8nIOAaIIJoMLWED1Ol+yCtDhzqFK8F+wW9JoiZ1NeESwe12woPH9ggWhoXp ye/KVhyeEyzWLUIQWdkNHwkb4wpMwUJflbbpjhlLhFOOMhKzjIC5h5peP/ZS5QbHNZKo JYNw== Received: by 10.14.221.194 with SMTP id r42mr85617684eep.25.1351689721529; Wed, 31 Oct 2012 06:22:01 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id t7sm7868729eel.14.2012.10.31.06.21.59 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 06:22:00 -0700 (PDT) From: "Roni Even" To: "'Mary Barnes'" , "'CLUE'" References: In-Reply-To: Date: Wed, 31 Oct 2012 15:19:48 +0200 Message-ID: <020501cdb76a$69036920$3b0a3b60$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0206_01CDB77B.2C8EAA20" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGzGtd1PuiNvjkwHd3XOC7osNcmbpgInoxw Content-Language: en-us Subject: Re: [clue] Consensus Call: WG deliverables - splitting some material from framework document. 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, 31 Oct 2012 13:22:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0206_01CDB77B.2C8EAA20 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mary, I am OK with having these four documents as long as we are not stating = that these are the only documents that will be delivered by the WG as first priority. =20 As for the content, we will need to discuss since Simon=92s proposal = makes the framework an empty document. =20 Roni =20 From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes Sent: 30 October, 2012 11:42 PM To: CLUE Subject: [clue] Consensus Call: WG deliverables - splitting some = material from framework document. =20 I should have changed the title since this discussion has morphed into a more general discussion of WG deliverables. Please see the proposal = below and respond as to whether you agree with the discrete deliverables as listed. If you don't agree, please explain why. Please note we're not discussing details - we just want to know if folks agree with the = division of work.=20 =20 Thanks, Mary.=20 ---------- Forwarded message ---------- From: Mary Barnes Date: Tue, Oct 30, 2012 at 4:25 PM Subject: Re: [clue] Data model - agreement on objective and basic = approach To: CLUE Cc: Christian Groves , Simon Pietro = Romano , Paul Kyzivat I think this is a reasonable split and I don't think it's that much of a killer task to do so. We have talked in the past about whether we = should split some material from the framework. I think doing so will make it easier for individuals to edit the various pieces. We will of course = have to ensure consistency. However, this approach adds some good checks = and balances, I believe. This model is quite similar to what worked very = well for the XCON work and it's quite similar to what other WGs are doing = (e.g., SIPREC). =20 =20 The chairs have delayed updating our milestones since we had not decided individual deliverables related to the solution. =20 =20 As chair I would like to gauge consensus on this approach. So, if = people could please respond as to whether they support the general idea of splitting the work into the following documents/deliverables: 1) Framework 2) Data model 3) Protocol 4) Call Flows =20 If we can get consensus on the basic idea, then we can work out the = details starting with Simon's suggestion. =20 I do have one comment about the "orchestration document" as I think that might be appropriate for the framework, but we could certainly work on = that separately and decide later. =20 Thanks, Mary.=20 =20 On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano wrote: Hi Christian, a rough estimation would be the following: a) keep sections 1 through 4 inside the framework document; b) move sections 5 through 8 to the data model document c) move the XML schema to the data model document (final section of the = data model, which provides 'one possible' example of how to formally describe = the things in the document); d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the protocol document; e) move subsection 9.4 to the call flows document; f) move section 10 to the data model document; g) move section 11 to the call flows document. Obviously, the resulting framework document should be revised (and = enriched) in view of the proposed distribution of work inside the WG. I would like = it to represent an orchestration document, providing an overview of issues, requirements, architecture and protocols. =20 A sort of summary reference for all of the related "drill-down" = documents, each expanding on a specific WG item (data model, protocol, call flows, etc.). I acknowledge the fact that this looks much like a revolution, but I nonetheless believe that we already have most of the needed material at = hand and just need to better distribute it across the documents produced by = the WG. Cheers, Simon Il 30/10/2012 10:33, Christian Groves ha scritto: =20 Hello Simon, When you say that you want to remove "all" the data model stuff from the framework can you be a bit more specific as to what parts you want = removed? Regards, Christian On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: Hi all, just to be clear on the current structure of the data model schema: all = the things you find there were 'extracted' (by Roberta and me) from = information currently contained inside the framework draft (as well as from some = side documents, associated with either the data model or the envisaged call flows). So, unless we have misinterpreted the above document(s) (which = is obviously possible), we should first of all focus on the framework in = order to try and converge on an agreed-upon CLUE architecture. Once done with this, we can fine-tune the data model. As I already stated on this list, = it is my personal opinion that we should remove from the framework document = all of the data-model stuff that it currently contains, and rather focus on = a clear definition of framework components and interfaces. I might look = naif, but I would like to arrive at an 'ordinary' set of documents: (i) = general framework; (ii) data model; (iii) clue protocol (with advertisement and configuration messages); (iv) call flows (showing how SDP O/A and CLUE protocol messages concur in effectively setting up a CLUE session). As to the 'UML vs XML' querelle, I would suggest that: 1. Both UML class diagrams and XML schema can be adopted for the = description of the data model, i.e., the STATIC part of the framework, associated = with the description of what some of you properly called a 'CLUE instance'; 2. UML sequence diagrams can be adopted to describe CLUE call flows, = i.e. the DYNAMIC part of the framework, which clearly envisages the = co-existence of SDP and CLUE protocol messages. XML schemas are not suitable for this dynamic part. This said, it is clear that CLUE protocol messages (in particular, CLUE advertisements) will be constructed by leveraging information contained inside a CLUE instance. Which parts of a CLUE instance should go into an advertisement and which should be carried inside SDP can be a matter of discussion. My 2 cents, Simon Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: On 10/29/12 6:23 PM, Roni Even wrote: Paul, This was the statement I answered "no" " The general agreement on the call is that the data model as reflected = in draft-presta-clue-data-model-schema describes the data needed by the = CLUE application" I disagree that it reflects that data needed by a CLUE application and I explained why. OK, fair enough. Mary can comment, but my take was that the point of her question was to distinguish between two alternatives: - the data model represents all the data needed by the clue app. (which implies to me that it encompasses all the data in the framework.) - the data model represents the data to be exchanged in clue messages. It is a bigger deal if the framework includes things that are not needed = by the clue application. I was of the impression that, except for some fine tuning, we were largely in agreement on the framework. If we don't have consensus on *that* then resolving that is of higher priority that much of the other stuff we are discussing. Thanks, Paul Roni -----Original Message----- From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: 29 October, 2012 9:46 PM To: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic = approach On 10/29/12 3:19 PM, Roni Even wrote: Hi, My view is 'no". I still fail to see the need for the encoding groups and individual encodes. In the current definition of capture scene, I am not sure what is the meaning of different individual encodes and eventually the receiver can define what it can receive (Typically H.264 is symmetric in terms of profile but does not need to be in the level) and can ask for specific resolution with the SDP image attribute ISTM that you are answering a different question than the one Mary = asked. You seem to be saying that you disagree with the framework as it is - = that it can/should be simpler. That is a separate question. If such changes were made it might affect a lot. Thanks, Paul Roni Even *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes *Sent:* 29 October, 2012 7:52 PM *To:* CLUE *Subject:* [clue] Data model - agreement on objective and basic approach On the call earlier today, we also discussed the data model. The general agreement on the call is that the data model as reflected in draft-presta-clue-data-model-schema describes the data needed by the CLUE application - i.e., it's the CLUE instance concept. It does not directly reflect the contents of a CLUE message. The application data would be used to populate CLUE messages, as well as SDP and would reflect updates based on both the CLUE and SDP signaling. If we can get agreement on that before the meeting, I believe our discussions can be much more productive. If folks could please reply "Yes" or "No" reflecting agreement with the above, that would be helpful. If you reply "No", please explain why. Regards, Mary as CLUE WG co-chair _______________________________________________ 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 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Engineering Department Phone: +39 081 7683823 -- Fax: +39 081 7683816 =20 e-mail: spromano@unina.it <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ 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 --=20 _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico II Computer Science Department Phone: +39 081 7683823 -- Fax: +39 = 081 7684219 =20 e-mail: spromano@unina.it http://www.comics.unina.it/simonpietro.romano <>. Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue =20 =20 ------=_NextPart_000_0206_01CDB77B.2C8EAA20 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Mary,

I am OK with having these four documents as long as we are not = stating that these are the only documents that will be delivered by the = WG as first priority.

 

As for the content, we will need to discuss since Simon’s = proposal makes the framework an empty document.

 

Roni

 

From:= = clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of = Mary Barnes
Sent: 30 October, 2012 11:42 PM
To: = CLUE
Subject: [clue] Consensus Call: WG deliverables - = splitting some material from framework document.

 

I should = have changed the title since this discussion has morphed into a more = general discussion of WG deliverables.  Please see the proposal = below and respond as to whether you agree with the discrete deliverables = as listed.  If you don't agree, please explain why.  Please = note we're not discussing details - we just want to know if folks agree = with the division of work. 

 

Thanks,

Mary. 

---------- Forwarded message ----------
From: = Mary Barnes <mary.ietf.barnes@gmail.com= >
Date: Tue, Oct 30, 2012 at 4:25 PM
Subject: Re: [clue] Data = model - agreement on objective and basic approach
To: CLUE <clue@ietf.org>
Cc: Christian = Groves <Christian.Groves@nteczone.c= om>, Simon Pietro Romano <spromano@unina.it>, Paul = Kyzivat <pkyzivat@alum.mit.edu>

I think this is a reasonable split and I don't think it's that = much of a killer task to do so.  We have talked in the past about = whether we should split some material from the framework.  I think = doing so will make it easier for individuals to edit the various pieces. =  We will of course have to ensure consistency.  However, =  this approach adds some good checks and balances, I believe. =   This model is quite similar to what worked very well for the XCON = work and it's quite similar to what other WGs are doing (e.g., SIPREC). =  

 

The chairs have delayed updating our milestones since = we had not decided individual deliverables related to the solution. =  

 

As chair I would like to gauge consensus on this = approach.  So, if people could please respond as to whether they = support the general idea of splitting the work into the following = documents/deliverables:

1) = Framework

2) Data = model

3) = Protocol

4) Call = Flows

 

If we can get consensus on the basic idea, then we can = work out the details starting with Simon's = suggestion.

 

I = do have one comment about the "orchestration document" as I = think that might be appropriate for the framework, but we could = certainly work on that separately and decide = later.

 

Thanks,

Mary. 

 

On Tue, = Oct 30, 2012 at 5:23 AM, Simon Pietro Romano <spromano@unina.it> wrote:

Hi Christian,

a rough estimation would be the = following:

a) keep sections 1 through 4 inside the framework = document;
b) move sections 5 through 8 to the data model = document
c) move the XML schema to the data model document (final = section of the data model, which provides 'one possible' example of how = to formally describe the things in the document);
d) move section 9, = together with subsections 9.1, 9.2 and 9.3 to the protocol = document;
e) move subsection 9.4 to the call flows document;
f) = move section 10 to the data model document;
g) move section 11 to the = call flows document.

Obviously, the resulting framework document = should be revised (and enriched) in view of the proposed distribution of = work inside the WG. I would like it to represent an orchestration = document, providing an overview of issues, requirements, architecture = and protocols.

 

A sort of = summary reference for all of the related "drill-down" = documents, each expanding on a specific WG item (data model, protocol, = call flows, etc.).

I acknowledge the fact that this looks much = like a revolution, but I nonetheless believe that we already have most = of the needed material at hand and just need to better distribute it = across the documents produced by the = WG.

Cheers,

Simon




Il 30/10/2012 10:33, = Christian Groves ha scritto:

 

Hello = Simon,

When you say that you want to remove "all" the = data model stuff from the framework can you be a bit more specific as to = what parts you want removed?

Regards, Christian

On = 30/10/2012 7:03 PM, Simon Pietro Romano wrote:

Hi all,

just to = be clear on the current structure of the data model schema: all the = things you find there were 'extracted' (by Roberta and me) from = information currently contained inside the framework draft (as well as = from some side documents, associated with either the data model or the = envisaged call flows). So, unless we have misinterpreted the above = document(s) (which is obviously possible), we should first of all focus = on the framework in order to try and converge on an agreed-upon CLUE = architecture. Once done with this, we can fine-tune the data model. As I = already stated on this list, it is my personal opinion that we should = remove from the framework document all of the data-model stuff that it = currently contains, and rather focus on a clear definition of framework = components and interfaces. I might look naif, but I would like to arrive = at an 'ordinary' set of documents: (i)  general framework; (ii) = data model; (iii) clue protocol (with advertisement and configuration = messages); (iv) call flows (showing how SDP O/A and CLUE protocol = messages concur in effectively setting up a CLUE session).

As to = the 'UML vs XML' querelle, I would suggest that:

1. Both UML = class diagrams and XML schema can be adopted for the description of the = data model, i.e., the STATIC part of the framework, associated with the = description of what some of you properly called a 'CLUE instance';
2. = UML sequence diagrams can be adopted to describe CLUE call flows, i.e. = the DYNAMIC part of the framework, which clearly envisages the = co-existence of SDP and CLUE protocol messages. XML schemas are not = suitable for this dynamic part.

This said, it is clear that CLUE = protocol messages  (in particular, CLUE advertisements) will be = constructed by leveraging information contained inside a CLUE instance. = Which parts of a CLUE instance should go into an advertisement and which = should be carried inside SDP can be a matter of discussion.

My 2 = cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, = Paul Kyzivat ha scritto:

On 10/29/12 = 6:23 PM, Roni Even wrote:

Paul,
This was the statement I answered = "no"
" The general agreement on the call is that the = data model as reflected in
draft-presta-clue-data-model-schema = describes the data needed by the CLUE
application"
I disagree = that it reflects that data needed by a CLUE application and = I
explained why.


OK, fair enough.

Mary can = comment, but my take was that the point of her question was to = distinguish between two alternatives:
- the data model represents all = the data needed by the clue app.
 (which implies to me that it = encompasses all the data in the
 framework.)
- the data model = represents the data to be exchanged in
 clue messages.

It = is a bigger deal if the framework includes things that are not needed by = the clue application. I was of the impression that, except for some fine = tuning, we were largely in agreement on the framework.

If we = don't have consensus on *that* then resolving that is of higher priority = that much of the other stuff we are = discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] On Behalf Of = Paul
Kyzivat
Sent: 29 October, 2012 9:46 PM
To: clue@ietf.org = <mailto:clue@ietf.org>
Subject: Re: [clue] Data = model - agreement on objective and basic approach

On 10/29/12 = 3:19 PM, Roni Even wrote:

Hi,

My view is 'no". I still fail to see = the need for the encoding groups
and individual encodes.

In = the current definition of capture scene, I am not sure what is = the
meaning of different individual encodes and eventually the = receiver
can define what it can receive (Typically H.264 is symmetric = in terms
of profile but does not need to be in the level) and can ask = for
specific resolution with the SDP image attribute


ISTM that you are = answering a different question than the one Mary asked.
You seem to = be saying that you disagree with the framework as it is - that
it = can/should be simpler.

That is a separate question. If such = changes were made it might affect = a
lot.

Thanks,
Paul

Roni Even

*From:*clue-bounces@ietf.org <mailto:clue-bounces@ietf.org> [mailto:clue-bounces@ietf.org] *On Behalf
Of *Mary = Barnes
*Sent:* 29 October, 2012 7:52 PM
*To:* CLUE
*Subject:* = [clue] Data model - agreement on objective and = basic
approach

On the call earlier today, we also discussed = the data model.  The
general agreement on the call is that the = data model as reflected in
draft-presta-clue-data-model-schema = describes the data needed by the
CLUE application - i.e., it's the = CLUE instance concept. It does not
directly reflect the contents of a = CLUE message.  The application data
would be used to populate = CLUE messages, as well as SDP and would
reflect updates based on both = the CLUE and SDP signaling.

If we can get agreement on that = before the meeting, I believe our
discussions can be much more = productive. If folks could please reply
"Yes" or = "No" reflecting agreement with the above, that would = be
helpful.  If you reply "No", please explain = why.

Regards,

Mary

as CLUE WG = co-chair



_______________________________________________clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue


______________________________________= _________
clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue

<= o:p>


______________________________________= _________
clue mailing list
clue@ietf.org <mailto:clue@ietf.org>
https://www.ietf.org/mailman/listinfo/clue


_\\|//_
      ( O-O = )
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~Simon Pietro Romano
Universita' di Napoli Federico = II
 Computer Engineering Department
  Phone: +39 081 7683823 = -- Fax: +39 081 = 7683816
 e-mail: spromano@unina.it <mailto:spromano@unina.it>

<<Molti mi = dicono che lo scoraggiamento =CB l'alibi degli
 idioti. Ci = rifletto un istante; e mi scoraggio>>. Magritte.
    =                 =  oooO
  ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ = Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
       \ (   =          (   )
      =                   \_) =          ) /
        =                 =  (_/







________________________________= _______________
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

 

--

  =                     =       _\\|//_
          =                   ( O-O = )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
&nbs= p;                   Simon = Pietro Romano
              = Universita' di Napoli Federico II

              =    Computer Science Department
        = Phone: +39 081 = 7683823 -- Fax: +39 081 7684219
        =         e-mail: spromano@unina.it
        =   http://www.comics.unina.it/simonpietro.romano<= /o:p>



    <<Molti = mi dicono che lo scoraggiamento =E8 l'alibi degli
  =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
                =          oooO

   ~~~~~~~~~~~~~~~~~~~~~~(   )~~ = Oooo~~~~~~~~~~~~~~~~~~~~~~~~~


              =             \ (    (   = )
                  =          \_)    ) /
    =                     =         =  (_/

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

 

 

------=_NextPart_000_0206_01CDB77B.2C8EAA20-- From pkyzivat@alum.mit.edu Wed Oct 31 06:34:37 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3856D21F87C9 for ; Wed, 31 Oct 2012 06:34:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id URJvpiVGFdGC for ; Wed, 31 Oct 2012 06:34:36 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id A669521F8734 for ; Wed, 31 Oct 2012 06:34:34 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id HluE1k0090EZKEL53paeTn; Wed, 31 Oct 2012 13:34:38 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id Hpav1k00m3ZTu2S3Mpaw5e; Wed, 31 Oct 2012 13:34:56 +0000 Message-ID: <509128E7.3090202@alum.mit.edu> Date: Wed, 31 Oct 2012 09:34:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: Roni Even References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> <01a701cdb6f2$8a772f60$9f658e20$@gmail.com> <50906F0D.1020004@alum.mit.edu> <01c401cdb733$062add60$12809820$@gmail.com> In-Reply-To: <01c401cdb733$062add60$12809820$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 31 Oct 2012 13:34:37 -0000 On 10/31/12 2:43 AM, Roni Even wrote: > Paul, > I am saying that CLUE does not work without mapping of RTP streams > (identified by SSRC) and Media Captures, it is true for static or dynamic > mapping. Oh, ok. Yes, I thought that was clear. It is my understanding that the static mapping intends to associate a particular capture encoding with a particular *ssrc*, and so to the RTP stream with that ssrc. That only works when the capture encoding has a 1:1 association with a single ssrc. The point of the RTP extension for the dynamic mapping is to carry an identifier for the capture encoding, independent of ssrc. That way the capture encoding of an RTP stream can be identified even when the ssrc may change over time for that stream. Thanks, Paul > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 31 October, 2012 2:22 AM > To: clue@ietf.org > Subject: Re: [clue] Data model - agreement on objective and basic approach > > On 10/30/12 7:01 PM, Roni Even wrote: >> Mary, >> >> Just as a point that CLUE does not work if you cannot say which SSRC >> is a specific media capture in CLUE > > I have now gotten lost in this thread. I don't understand what in the thread > this comment was intended to respond to. > > But responding to just this statement, it sounds like a denial of the > dynamic mapping, which explicitly separates the identification of a capture > (actually capture encoding) from an SSRC. > > So are you saying thata CLUE does not work with the dynamic mapping? > > Thanks, > Paul > >> Roni >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On Behalf >> Of *Mary Barnes >> *Sent:* 30 October, 2012 11:49 PM >> *To:* Roni Even >> *Cc:* CLUE >> *Subject:* Re: [clue] Data model - agreement on objective and basic >> approach >> >> I think that would belong in the protocol document - that is where the >> SIPREC WG has described their usage of RTP. Any specific changes to >> the RTP and SDP would of course be submitted as documents in the >> AVTCORE and MMUSIC WGs. >> >> However, it may be better to keep that document separate for a while - >> that is also the model that SIPREC used/ >> >> Mary. >> >> On Tue, Oct 30, 2012 at 4:42 PM, Roni Even >> > wrote: >> >> Hi Mary, >> >> What about the mapping of RTP streams to Media Captures, where does it >> fall >> >> BTW: the mapping may require an identfier for the media capture >> >> Roni >> >> ---------------------------------------------------------------------- >> -- >> >> *From:*clue-bounces@ietf.org >> [clue-bounces@ietf.org ] on behalf of >> Mary Barnes [mary.ietf.barnes@gmail.com >> ] >> *Sent:* Tuesday, October 30, 2012 11:25 PM >> *To:* CLUE >> >> >> *Subject:* Re: [clue] Data model - agreement on objective and basic >> approach >> >> I think this is a reasonable split and I don't think it's that much of >> a killer task to do so. We have talked in the past about whether we >> should split some material from the framework. I think doing so will >> make it easier for individuals to edit the various pieces. We will of >> course have to ensure consistency. However, this approach adds some >> good checks and balances, I believe. This model is quite similar to >> what worked very well for the XCON work and it's quite similar to what >> other WGs are doing (e.g., SIPREC). >> >> The chairs have delayed updating our milestones since we had not >> decided individual deliverables related to the solution. >> >> As chair I would like to gauge consensus on this approach. So, if >> people could please respond as to whether they support the general >> idea of splitting the work into the following documents/deliverables: >> >> 1) Framework >> >> 2) Data model >> >> 3) Protocol >> >> 4) Call Flows >> >> If we can get consensus on the basic idea, then we can work out the >> details starting with Simon's suggestion. >> >> I do have one comment about the "orchestration document" as I think >> that might be appropriate for the framework, but we could certainly >> work on that separately and decide later. >> >> Thanks, >> >> Mary. >> >> On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano >> > wrote: >> >> Hi Christian, >> >> a rough estimation would be the following: >> >> a) keep sections 1 through 4 inside the framework document; >> b) move sections 5 through 8 to the data model document >> c) move the XML schema to the data model document (final section of >> the data model, which provides 'one possible' example of how to >> formally describe the things in the document); >> d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the >> protocol document; >> e) move subsection 9.4 to the call flows document; >> f) move section 10 to the data model document; >> g) move section 11 to the call flows document. >> >> Obviously, the resulting framework document should be revised (and >> enriched) in view of the proposed distribution of work inside the WG. >> I would like it to represent an orchestration document, providing an >> overview of issues, requirements, architecture and protocols. >> >> A sort of summary reference for all of the related "drill-down" >> documents, each expanding on a specific WG item (data model, >> protocol, call flows, etc.). >> >> I acknowledge the fact that this looks much like a revolution, but I >> nonetheless believe that we already have most of the needed material >> at hand and just need to better distribute it across the documents >> produced by the WG. >> >> Cheers, >> >> Simon >> >> >> >> >> Il 30/10/2012 10:33, Christian Groves ha scritto: >> >> Hello Simon, >> >> When you say that you want to remove "all" the data model stuff >> from the framework can you be a bit more specific as to what >> parts you want removed? >> >> Regards, Christian >> >> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >> >> Hi all, >> >> just to be clear on the current structure of the data model >> schema: all the things you find there were 'extracted' (by >> Roberta and me) from information currently contained inside the >> framework draft (as well as from some side documents, associated >> with either the data model or the envisaged call flows). So, >> unless we have misinterpreted the above document(s) (which is >> obviously possible), we should first of all focus on the >> framework in order to try and converge on an agreed-upon CLUE >> architecture. Once done with this, we can fine-tune the data >> model. As I already stated on this list, it is my personal >> opinion that we should remove from the framework document all of >> the data-model stuff that it currently contains, and rather >> focus on a clear definition of framework components and >> interfaces. I might look naif, but I would like to arrive at an >> 'ordinary' set of documents: (i) general framework; (ii) data >> model; (iii) clue protocol (with advertisement and configuration >> messages); (iv) call flows (showing how SDP O/A and CLUE >> protocol messages concur in effectively setting up a CLUE > session). >> >> As to the 'UML vs XML' querelle, I would suggest that: >> >> 1. Both UML class diagrams and XML schema can be adopted for the >> description of the data model, i.e., the STATIC part of the >> framework, associated with the description of what some of you >> properly called a 'CLUE instance'; >> 2. UML sequence diagrams can be adopted to describe CLUE call >> flows, i.e. the DYNAMIC part of the framework, which clearly >> envisages the co-existence of SDP and CLUE protocol messages. >> XML schemas are not suitable for this dynamic part. >> >> This said, it is clear that CLUE protocol messages (in >> particular, CLUE advertisements) will be constructed by >> leveraging information contained inside a CLUE instance. Which >> parts of a CLUE instance should go into an advertisement and >> which should be carried inside SDP can be a matter of discussion. >> >> My 2 cents, >> >> Simon >> >> >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >> >> On 10/29/12 6:23 PM, Roni Even wrote: >> >> Paul, >> This was the statement I answered "no" >> " The general agreement on the call is that the data model as >> reflected in >> draft-presta-clue-data-model-schema describes the data needed by >> the CLUE >> application" >> I disagree that it reflects that data needed by a CLUE >> application and I >> explained why. >> >> >> OK, fair enough. >> >> Mary can comment, but my take was that the point of her question >> was to distinguish between two alternatives: >> - the data model represents all the data needed by the clue app. >> (which implies to me that it encompasses all the data in the >> framework.) >> - the data model represents the data to be exchanged in >> clue messages. >> >> It is a bigger deal if the framework includes things that are >> not needed by the clue application. I was of the impression >> that, except for some fine tuning, we were largely in agreement >> on the framework. >> >> If we don't have consensus on *that* then resolving that is of >> higher priority that much of the other stuff we are discussing. >> >> Thanks, >> Paul >> >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> > >> [mailto:clue-bounces@ietf.org ] On >> Behalf Of Paul >> Kyzivat >> Sent: 29 October, 2012 9:46 PM >> To: clue@ietf.org > > >> Subject: Re: [clue] Data model - agreement on objective and >> basic approach >> >> On 10/29/12 3:19 PM, Roni Even wrote: >> >> Hi, >> >> My view is 'no". I still fail to see the need for the encoding >> groups >> and individual encodes. >> >> In the current definition of capture scene, I am not sure what >> is the >> meaning of different individual encodes and eventually the > receiver >> can define what it can receive (Typically H.264 is symmetric in >> terms >> of profile but does not need to be in the level) and can ask for >> specific resolution with the SDP image attribute >> >> >> ISTM that you are answering a different question than the one >> Mary asked. >> You seem to be saying that you disagree with the framework as it >> is - that >> it can/should be simpler. >> >> That is a separate question. If such changes were made it might >> affect a >> lot. >> >> Thanks, >> Paul >> >> Roni Even >> >> *From:*clue-bounces@ietf.org >> > >> [mailto:clue-bounces@ietf.org ] >> *On Behalf >> Of *Mary Barnes >> *Sent:* 29 October, 2012 7:52 PM >> *To:* CLUE >> *Subject:* [clue] Data model - agreement on objective and basic >> approach >> >> On the call earlier today, we also discussed the data model. The >> general agreement on the call is that the data model as reflected > in >> draft-presta-clue-data-model-schema describes the data needed by > the >> CLUE application - i.e., it's the CLUE instance concept. It does > not >> directly reflect the contents of a CLUE message. The >> application data >> would be used to populate CLUE messages, as well as SDP and would >> reflect updates based on both the CLUE and SDP signaling. >> >> If we can get agreement on that before the meeting, I believe our >> discussions can be much more productive. If folks could please > reply >> "Yes" or "No" reflecting agreement with the above, that would be >> helpful. If you reply "No", please explain why. >> >> Regards, >> >> Mary >> >> as CLUE WG co-chair >> >> >> >> _______________________________________________ >> 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 >> >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- Fax: >> +39 081 7683816 >> e-mail: spromano@unina.it >> > >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >> >> -- >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> >> Computer Science Department >> Phone: +39 081 7683823 -- Fax: >> +39 081 7684219 >> e-mail: spromano@unina.it >> http://www.comics.unina.it/simonpietro.romano >> >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> >> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> \ ( ( ) >> \_) ) / >> (_/ >> >> _______________________________________________ >> 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 spromano@unina.it Wed Oct 31 06:39:04 2012 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFF121F85BC for ; Wed, 31 Oct 2012 06:39:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXyvDBRncSo7 for ; Wed, 31 Oct 2012 06:39:02 -0700 (PDT) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id C875421F8510 for ; Wed, 31 Oct 2012 06:39:01 -0700 (PDT) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id q9VDcwlP005826 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 31 Oct 2012 14:38:58 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_AF6ECB49-D742-4FC2-8A79-009A869504E7" From: Simon Pietro Romano In-Reply-To: <020501cdb76a$69036920$3b0a3b60$@gmail.com> Date: Wed, 31 Oct 2012 14:38:57 +0100 Message-Id: References: <020501cdb76a$69036920$3b0a3b60$@gmail.com> To: "Roni Even" X-Mailer: Apple Mail (2.1283) Cc: 'CLUE' Subject: Re: [clue] Consensus Call: WG deliverables - splitting some material from framework document. 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, 31 Oct 2012 13:39:04 -0000 --Apple-Mail=_AF6ECB49-D742-4FC2-8A79-009A869504E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > As for the content, we will need to discuss since Simon=92s proposal = makes the framework an empty document. :-)...I didn't mean that I want the framework document to be an empty = one. I just pointed out that it should become the so-called = orchestration document, containing the high level view of the entire = work we're carrying out in CLUE. After reading the framework, people = should be supposed to have a clear idea of the overall architecture, = while being 'forwarded' to the other documents for the details. Under = this perspective, the framework deserves the most important role among = the WG items. I did not even aim at restricting the scope of the WG, obviously.=20 Simon > =20 > Roni > =20 > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf = Of Mary Barnes > Sent: 30 October, 2012 11:42 PM > To: CLUE > Subject: [clue] Consensus Call: WG deliverables - splitting some = material from framework document. > =20 > I should have changed the title since this discussion has morphed into = a more general discussion of WG deliverables. Please see the proposal = below and respond as to whether you agree with the discrete deliverables = as listed. If you don't agree, please explain why. Please note we're = not discussing details - we just want to know if folks agree with the = division of work.=20 > =20 > Thanks, > Mary.=20 >=20 > ---------- Forwarded message ---------- > From: Mary Barnes > Date: Tue, Oct 30, 2012 at 4:25 PM > Subject: Re: [clue] Data model - agreement on objective and basic = approach > To: CLUE > Cc: Christian Groves , Simon Pietro = Romano , Paul Kyzivat >=20 >=20 > I think this is a reasonable split and I don't think it's that much of = a killer task to do so. We have talked in the past about whether we = should split some material from the framework. I think doing so will = make it easier for individuals to edit the various pieces. We will of = course have to ensure consistency. However, this approach adds some = good checks and balances, I believe. This model is quite similar to = what worked very well for the XCON work and it's quite similar to what = other WGs are doing (e.g., SIPREC). =20 > =20 > The chairs have delayed updating our milestones since we had not = decided individual deliverables related to the solution. =20 > =20 > As chair I would like to gauge consensus on this approach. So, if = people could please respond as to whether they support the general idea = of splitting the work into the following documents/deliverables: > 1) Framework > 2) Data model > 3) Protocol > 4) Call Flows > =20 > If we can get consensus on the basic idea, then we can work out the = details starting with Simon's suggestion. > =20 > I do have one comment about the "orchestration document" as I think = that might be appropriate for the framework, but we could certainly work = on that separately and decide later. > =20 > Thanks, > Mary.=20 > =20 > On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano = wrote: > Hi Christian, >=20 > a rough estimation would be the following: >=20 > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final section of = the data model, which provides 'one possible' example of how to formally = describe the things in the document); > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the = protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. >=20 > Obviously, the resulting framework document should be revised (and = enriched) in view of the proposed distribution of work inside the WG. I = would like it to represent an orchestration document, providing an = overview of issues, requirements, architecture and protocols. > =20 > A sort of summary reference for all of the related "drill-down" = documents, each expanding on a specific WG item (data model, protocol, = call flows, etc.). >=20 > I acknowledge the fact that this looks much like a revolution, but I = nonetheless believe that we already have most of the needed material at = hand and just need to better distribute it across the documents produced = by the WG. >=20 > Cheers, >=20 > Simon >=20 >=20 >=20 >=20 > Il 30/10/2012 10:33, Christian Groves ha scritto: > =20 > Hello Simon, >=20 > When you say that you want to remove "all" the data model stuff from = the framework can you be a bit more specific as to what parts you want = removed? >=20 > Regards, Christian >=20 > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > Hi all, >=20 > just to be clear on the current structure of the data model schema: = all the things you find there were 'extracted' (by Roberta and me) from = information currently contained inside the framework draft (as well as = from some side documents, associated with either the data model or the = envisaged call flows). So, unless we have misinterpreted the above = document(s) (which is obviously possible), we should first of all focus = on the framework in order to try and converge on an agreed-upon CLUE = architecture. Once done with this, we can fine-tune the data model. As I = already stated on this list, it is my personal opinion that we should = remove from the framework document all of the data-model stuff that it = currently contains, and rather focus on a clear definition of framework = components and interfaces. I might look naif, but I would like to arrive = at an 'ordinary' set of documents: (i) general framework; (ii) data = model; (iii) clue protocol (with advertisement and configuration = messages); (iv) call flows (showing how SDP O/A and CLUE protocol = messages concur in effectively setting up a CLUE session). >=20 > As to the 'UML vs XML' querelle, I would suggest that: >=20 > 1. Both UML class diagrams and XML schema can be adopted for the = description of the data model, i.e., the STATIC part of the framework, = associated with the description of what some of you properly called a = 'CLUE instance'; > 2. UML sequence diagrams can be adopted to describe CLUE call flows, = i.e. the DYNAMIC part of the framework, which clearly envisages the = co-existence of SDP and CLUE protocol messages. XML schemas are not = suitable for this dynamic part. >=20 > This said, it is clear that CLUE protocol messages (in particular, = CLUE advertisements) will be constructed by leveraging information = contained inside a CLUE instance. Which parts of a CLUE instance should = go into an advertisement and which should be carried inside SDP can be a = matter of discussion. >=20 > My 2 cents, >=20 > Simon >=20 >=20 > Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >=20 > On 10/29/12 6:23 PM, Roni Even wrote: > Paul, > This was the statement I answered "no" > " The general agreement on the call is that the data model as = reflected in > draft-presta-clue-data-model-schema describes the data needed by the = CLUE > application" > I disagree that it reflects that data needed by a CLUE application and = I > explained why. >=20 > OK, fair enough. >=20 > Mary can comment, but my take was that the point of her question was = to distinguish between two alternatives: > - the data model represents all the data needed by the clue app. > (which implies to me that it encompasses all the data in the > framework.) > - the data model represents the data to be exchanged in > clue messages. >=20 > It is a bigger deal if the framework includes things that are not = needed by the clue application. I was of the impression that, except for = some fine tuning, we were largely in agreement on the framework. >=20 > If we don't have consensus on *that* then resolving that is of higher = priority that much of the other stuff we are discussing. >=20 > Thanks, > Paul >=20 > Roni >=20 > -----Original Message----- > From: clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf Of Paul > Kyzivat > Sent: 29 October, 2012 9:46 PM > To: clue@ietf.org > Subject: Re: [clue] Data model - agreement on objective and basic = approach >=20 > On 10/29/12 3:19 PM, Roni Even wrote: > Hi, >=20 > My view is 'no". I still fail to see the need for the encoding groups > and individual encodes. >=20 > In the current definition of capture scene, I am not sure what is the > meaning of different individual encodes and eventually the receiver > can define what it can receive (Typically H.264 is symmetric in terms > of profile but does not need to be in the level) and can ask for > specific resolution with the SDP image attribute >=20 > ISTM that you are answering a different question than the one Mary = asked. > You seem to be saying that you disagree with the framework as it is - = that > it can/should be simpler. >=20 > That is a separate question. If such changes were made it might affect = a > lot. >=20 > Thanks, > Paul >=20 > Roni Even >=20 > *From:*clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] *On Behalf > Of *Mary Barnes > *Sent:* 29 October, 2012 7:52 PM > *To:* CLUE > *Subject:* [clue] Data model - agreement on objective and basic > approach >=20 > On the call earlier today, we also discussed the data model. The > general agreement on the call is that the data model as reflected in > draft-presta-clue-data-model-schema describes the data needed by the > CLUE application - i.e., it's the CLUE instance concept. It does not > directly reflect the contents of a CLUE message. The application data > would be used to populate CLUE messages, as well as SDP and would > reflect updates based on both the CLUE and SDP signaling. >=20 > If we can get agreement on that before the meeting, I believe our > discussions can be much more productive. If folks could please reply > "Yes" or "No" reflecting agreement with the above, that would be > helpful. If you reply "No", please explain why. >=20 > Regards, >=20 > Mary >=20 > as CLUE WG co-chair >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > 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 >=20 > =20 > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/simonpietro.romano >=20 >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >=20 > \ ( ( ) > \_) ) / > (_/ >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > =20 > =20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_AF6ECB49-D742-4FC2-8A79-009A869504E7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

As for the content, we = will need to discuss since Simon=92s proposal makes the framework an = empty = document.

:-)..= .I didn't mean that I want the framework document to be an empty one. I = just pointed out that it should become the so-called orchestration = document, containing the high level view of the entire work we're = carrying out in CLUE. After reading the framework, people should be = supposed to have a clear idea of the overall architecture, while being = 'forwarded' to the other documents for the details. Under this = perspective, the framework deserves the most important role among the WG = items.
I did not even aim at restricting the scope of the WG, = obviously. 

Simon

<= br>

 clue-bounces@ietf.org = [mailto:clue-bounces@ietf.org] On Behalf Of Mary = Barnes
Sent: 30 October, 2012 11:42 = PM
To: CLUE
Subject: [clue] Consensus Call: WG = deliverables - splitting some material from framework = document.
I should have changed the title = since this discussion has morphed into a more general discussion of WG = deliverables.  Please see the proposal below and respond as to = whether you agree with the discrete deliverables as listed.  If you = don't agree, please explain why.  Please note we're not discussing = details - we just want to know if folks agree with the division of = work. 
 
Thanks,

Mary. 

---------- Forwarded = message ----------
From: Mary Barnes <clue@ietf.org>
Cc: = Christian Groves <spromano@unina.it>, Paul Kyzivat <pkyzivat@alum.mit.edu>


I = think this is a reasonable split and I don't think it's that much of a = killer task to do so.  We have talked in the past about whether we = should split some material from the framework.  I think doing so = will make it easier for individuals to edit the various pieces.  We = will of course have to ensure consistency.  However,  this = approach adds some good checks and balances, I believe.   This = model is quite similar to what worked very well for the XCON work and = it's quite similar to what other WGs are doing (e.g., SIPREC). =  
The chairs have delayed = updating our milestones since we had not decided individual deliverables = related to the solution.  
 
As chair I would like to gauge consensus on this = approach.  So, if people could please respond as to whether they = support the general idea of splitting the work into the following = documents/deliverables:
1) Framework
2) Data model
3) Protocol
4) Call Flows
 
If we can get consensus on the basic idea, then we can = work out the details starting with Simon's = suggestion.
I do have one comment = about the "orchestration document" as I think that might be appropriate = for the framework, but we could certainly work on that separately and = decide later.
 
On Tue, Oct = 30, 2012 at 5:23 AM, Simon Pietro Romano <spromano@unina.it> = wrote:
Hi Christian,

a rough estimation = would be the following:

a) keep sections 1 through 4 inside the = framework document;
b) move sections 5 through 8 to the data model = document
c) move the XML schema to the data model document (final = section of the data model, which provides 'one possible' example of how = to formally describe the things in the document);
d) move section 9, = together with subsections 9.1, 9.2 and 9.3 to the protocol = document;
e) move subsection 9.4 to the call flows document;
f) = move section 10 to the data model document;
g) move section 11 to the = call flows document.

Obviously, the resulting framework document = should be revised (and enriched) in view of the proposed distribution of = work inside the WG. I would like it to represent an orchestration = document, providing an overview of issues, requirements, architecture = and protocols.
A sort of = summary reference for all of the related "drill-down" documents, each = expanding on a specific WG item (data model, protocol, call flows, = etc.).

I acknowledge the fact that this looks much like a = revolution, but I nonetheless believe that we already have most of the = needed material at hand and just need to better distribute it across the = documents produced by the = WG.

Cheers,

Simon




Il 30/10/2012 10:33, = Christian Groves ha scritto:
 
Hello Simon,

When you say that you want to = remove "all" the data model stuff from the framework can you be a bit = more specific as to what parts you want removed?

Regards, = Christian

On 30/10/2012 7:03 PM, Simon Pietro Romano = wrote:

Hi all,

just to be = clear on the current structure of the data model schema: all the things = you find there were 'extracted' (by Roberta and me) from information = currently contained inside the framework draft (as well as from some = side documents, associated with either the data model or the envisaged = call flows). So, unless we have misinterpreted the above document(s) = (which is obviously possible), we should first of all focus on the = framework in order to try and converge on an agreed-upon CLUE = architecture. Once done with this, we can fine-tune the data model. As I = already stated on this list, it is my personal opinion that we should = remove from the framework document all of the data-model stuff that it = currently contains, and rather focus on a clear definition of framework = components and interfaces. I might look naif, but I would like to arrive = at an 'ordinary' set of documents: (i)  general framework; (ii) = data model; (iii) clue protocol (with advertisement and configuration = messages); (iv) call flows (showing how SDP O/A and CLUE protocol = messages concur in effectively setting up a CLUE session).

As to = the 'UML vs XML' querelle, I would suggest that:

1. Both UML = class diagrams and XML schema can be adopted for the description of the = data model, i.e., the STATIC part of the framework, associated with the = description of what some of you properly called a 'CLUE instance';
2. = UML sequence diagrams can be adopted to describe CLUE call flows, i.e. = the DYNAMIC part of the framework, which clearly envisages the = co-existence of SDP and CLUE protocol messages. XML schemas are not = suitable for this dynamic part.

This said, it is clear that CLUE = protocol messages  (in particular, CLUE advertisements) will be = constructed by leveraging information contained inside a CLUE instance. = Which parts of a CLUE instance should go into an advertisement and which = should be carried inside SDP can be a matter of discussion.

My 2 = cents,

Simon


Il giorno 30/ott/2012, alle ore 00:00, = Paul Kyzivat ha scritto:

On 10/29/12 6:23 PM, Roni = Even wrote:
Paul,
This was the statement = I answered "no"
" The general agreement on the call is that the data = model as reflected in
draft-presta-clue-data-model-schema describes = the data needed by the CLUE
application"
I disagree that it = reflects that data needed by a CLUE application and I
explained = why.


OK, fair = enough.

Mary can comment, but my take was that the point of her = question was to distinguish between two alternatives:
- the data = model represents all the data needed by the clue app.
 (which = implies to me that it encompasses all the data in = the
 framework.)
- the data model represents the data to be = exchanged in
 clue messages.

It is a bigger deal if the = framework includes things that are not needed by the clue application. I = was of the impression that, except for some fine tuning, we were largely = in agreement on the framework.

If we don't have consensus on = *that* then resolving that is of higher priority that much of the other = stuff we are discussing.

Thanks,
Paul

Roni

-----Original Message-----
From: clue-bounces@ietf.org <mailto:clue-bounces@ietf.org> = [mailto: clue@ietf.org <mailto:clue@ietf.org>
Subject: Re: = [clue] Data model - agreement on objective and basic approach

On = 10/29/12 3:19 PM, Roni Even wrote:
Hi,

My view is 'no". I still fail to see the = need for the encoding groups
and individual encodes.

In the = current definition of capture scene, I am not sure what is = the
meaning of different individual encodes and eventually the = receiver
can define what it can receive (Typically H.264 is symmetric = in terms
of profile but does not need to be in the level) and can ask = for
specific resolution with the SDP image = attribute


ISTM that = you are answering a different question than the one Mary asked.
You = seem to be saying that you disagree with the framework as it is - = that
it can/should be simpler.

That is a separate question. If = such changes were made it might affect = a
lot.

Thanks,
Paul

Roni Even

*From:* <mailto:clue-bounces@ietf.org> = [mailto:helpful.  If you reply "No", please explain = why.

Regards,

Mary

as CLUE WG = co-chair



_______________________________________________clue mailing list
 <mailto:clue@ietf.org>
clue@ietf.org <mailto:clue@ietf.org>
clue@ietf.org <mailto:clue@ietf.org>

_\\|//_
      ( O-O = )
 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
= Simon Pietro Romano
Universita' di Napoli Federico = II
 Computer Engineering Department
  Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
 e-mail: spromano@unina.it <mailto:clue@ietf.org
 


      =                 =    =     _\\|//_
          =                   =       ( O-O )
  =  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                  =    = Simon Pietro Romano
          =     Universita' di Napoli = Federico II
              =    =      Computer Engineering = Department 
         =     Phone: +39 081 7683823 -- Fax: +39 081 = 7683816
              =                     =          e-mail: spromano@unina.it

=     <<Molti mi dicono che lo scoraggiamento =CB = l'alibi degli 
   =  idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte.
             =    =                   =    oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=                 =  \ (            (   = )
=               =                     = \_)          ) /
      =                     =                     =                     =      (_/





= --Apple-Mail=_AF6ECB49-D742-4FC2-8A79-009A869504E7-- From mary.ietf.barnes@gmail.com Wed Oct 31 07:05: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 CD1A921F8812 for ; Wed, 31 Oct 2012 07:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xH1z5SppGayv for ; Wed, 31 Oct 2012 07:05:45 -0700 (PDT) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id CDBF821F87FD for ; Wed, 31 Oct 2012 07:05:44 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id b11so1166994lam.31 for ; Wed, 31 Oct 2012 07:05:43 -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=NYWhEUtG3lsorYEJ25ahxfCTSklN7GWWcLu4bzw4MSQ=; b=0SGWRc8W+knhpGkRJ2SzL+XmSTkHKPjaxSTyfgFwu2dnVTTRVTjjqV+KVZb2gLTHfi DQILp7i+cwGG1PZ2wjeoTBTUiRTu3es6Yz1RGphI/DrXR4+/26uV3YSaU5xijpFLW7uu an/MxTwrgmg2eAtTOvgqVat2INktuURKlkdfU9ZR74F7EPdU5PSrIOHHnBNpwg2eDIEm iRu7Ghf/MPtAthr/kS61wwhoLOaIb21lDs2+OCroMn5Vighmr/Dw/kQQV+99a49tgCNq +Akcb8GdCB4Di9XpAVGMvDqK5hb+gpeB7MJzs3ca5TtQpOn/GNKLgu5BZMB9fkxTtNmL F3sA== MIME-Version: 1.0 Received: by 10.152.105.135 with SMTP id gm7mr33932113lab.22.1351692343671; Wed, 31 Oct 2012 07:05:43 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Wed, 31 Oct 2012 07:05:43 -0700 (PDT) In-Reply-To: <020401cdb76a$16131c60$42395520$@gmail.com> References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <020401cdb76a$16131c60$42395520$@gmail.com> Date: Wed, 31 Oct 2012 09:05:43 -0500 Message-ID: From: Mary Barnes To: Roni Even Content-Type: multipart/alternative; boundary=f46d040711c5fd79cf04cd5b6515 Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 31 Oct 2012 14:05:47 -0000 --f46d040711c5fd79cf04cd5b6515 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Simon also suggested that we need to enrich the framework. We have gotten feedback in the past that it's difficult to read as I think there is a middle level of detail that is missing. We have had wonderful diagrams in .ppts at the meetings but we have very few diagrams in the FW. I think it could help a lot to add some. Mary. On Wed, Oct 31, 2012 at 8:17 AM, Roni Even wrote: > Hi Simon, > This will make the framework empty, section 1-4 do not have any informati= on > that merit a document. > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Simon Pietro Romano > Sent: 30 October, 2012 12:24 PM > To: Christian Groves > Cc: clue@ietf.org > Subject: Re: [clue] Data model - agreement on objective and basic approac= h > > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final section of the > data > model, which provides 'one possible' example of how to formally describe > the > things in the document); > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the > protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. > > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside the WG. I > would like it to represent an orchestration document, providing an overvi= ew > of issues, requirements, architecture and protocols. A sort of summary > reference for all of the related "drill-down" documents, each expanding o= n > a > specific WG item (data model, protocol, call flows, etc.). > > I acknowledge the fact that this looks much like a revolution, but I > nonetheless believe that we already have most of the needed material at > hand > and just need to better distribute it across the documents produced by th= e > WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, > > > > When you say that you want to remove "all" the data model stuff from > > the framework can you be a bit more specific as to what parts you want > > removed? > > > > Regards, Christian > > > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > >> Hi all, > >> > >> just to be clear on the current structure of the data model schema: > >> all the things you find there were 'extracted' (by Roberta and me) > >> from information currently contained inside the framework draft (as > >> well as from some side documents, associated with either the data > >> model or the envisaged call flows). So, unless we have misinterpreted > >> the above document(s) (which is obviously possible), we should first > >> of all focus on the framework in order to try and converge on an > >> agreed-upon CLUE architecture. Once done with this, we can fine-tune > >> the data model. As I already stated on this list, it is my personal > >> opinion that we should remove from the framework document all of the > >> data-model stuff that it currently contains, and rather focus on a > >> clear definition of framework components and interfaces. I might look > >> naif, but I would like to arrive at an 'ordinary' set of documents: > >> (i) general framework; (ii) data model; (iii) clue protocol (with > >> advertisement and configuration messages); (iv) call flows (showing > >> how SDP O/A and CLUE protocol messages concur in effectively setting > >> up a CLUE session). > >> > >> As to the 'UML vs XML' querelle, I would suggest that: > >> > >> 1. Both UML class diagrams and XML schema can be adopted for the > >> description of the data model, i.e., the STATIC part of the > >> framework, associated with the description of what some of you > >> properly called a 'CLUE instance'; 2. UML sequence diagrams can be > >> adopted to describe CLUE call flows, i.e. the DYNAMIC part of the > >> framework, which clearly envisages the co-existence of SDP and CLUE > >> protocol messages. XML schemas are not suitable for this dynamic > >> part. > >> > >> This said, it is clear that CLUE protocol messages (in particular, > >> CLUE advertisements) will be constructed by leveraging information > >> contained inside a CLUE instance. Which parts of a CLUE instance > >> should go into an advertisement and which should be carried inside > >> SDP can be a matter of discussion. > >> > >> My 2 cents, > >> > >> Simon > >> > >> > >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: > >> > >>> On 10/29/12 6:23 PM, Roni Even wrote: > >>>> Paul, > >>>> This was the statement I answered "no" > >>>> " The general agreement on the call is that the data model as > >>>> reflected in draft-presta-clue-data-model-schema describes the data > >>>> needed by the CLUE application" > >>>> I disagree that it reflects that data needed by a CLUE application > >>>> and I explained why. > >>> > >>> OK, fair enough. > >>> > >>> Mary can comment, but my take was that the point of her question was > >>> to distinguish between two alternatives: > >>> - the data model represents all the data needed by the clue app. > >>> (which implies to me that it encompasses all the data in the > >>> framework.) > >>> - the data model represents the data to be exchanged in clue > >>> messages. > >>> > >>> It is a bigger deal if the framework includes things that are not > >>> needed by the clue application. I was of the impression that, except > >>> for some fine tuning, we were largely in agreement on the framework. > >>> > >>> If we don't have consensus on *that* then resolving that is of > >>> higher priority that much of the other stuff we are discussing. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Roni > >>>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org > >>>> [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: 29 October, 2012 9:46 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] Data model - agreement on objective and basic > >>>> approach > >>>> > >>>> On 10/29/12 3:19 PM, Roni Even wrote: > >>>>> Hi, > >>>>> > >>>>> My view is 'no". I still fail to see the need for the encoding > >>>>> groups and individual encodes. > >>>>> > >>>>> In the current definition of capture scene, I am not sure what is > >>>>> the meaning of different individual encodes and eventually the > >>>>> receiver can define what it can receive (Typically H.264 is > >>>>> symmetric in terms of profile but does not need to be in the > >>>>> level) and can ask for specific resolution with the SDP image > >>>>> attribute > >>>> > >>>> ISTM that you are answering a different question than the one Mary > >>>> asked. > >>>> You seem to be saying that you disagree with the framework as it is > >>>> - that > >>>> it can/should be simpler. > >>>> > >>>> That is a separate question. If such changes were made it might > >>>> affect a lot. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Roni Even > >>>>> > >>>>> *From:*clue-bounces@ietf.org > >>>>> [mailto:clue-bounces@ietf.org] *On Behalf Of *Mary Barnes > >>>>> *Sent:* 29 October, 2012 7:52 PM > >>>>> *To:* CLUE > >>>>> *Subject:* [clue] Data model - agreement on objective and basic > >>>>> approach > >>>>> > >>>>> On the call earlier today, we also discussed the data model. The > >>>>> general agreement on the call is that the data model as reflected > >>>>> in draft-presta-clue-data-model-schema describes the data needed > >>>>> by the CLUE application - i.e., it's the CLUE instance concept. It > >>>>> does not directly reflect the contents of a CLUE message. The > >>>>> application data would be used to populate CLUE messages, as well > >>>>> as SDP and would reflect updates based on both the CLUE and SDP > >>>>> signaling. > >>>>> > >>>>> If we can get agreement on that before the meeting, I believe our > >>>>> discussions can be much more productive. If folks could please > >>>>> reply "Yes" or "No" reflecting agreement with the above, that > >>>>> would be helpful. If you reply "No", please explain why. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Mary > >>>>> > >>>>> as CLUE WG co-chair > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >> > >> _\\|//_ > >> ( O-O ) > >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > >> Simon Pietro Romano > >> Universita' di Napoli Federico II > >> Computer Engineering Department > >> Phone: +39 081 7683823 -- Fax: +39 081 7683816 > >> e-mail: spromano@unina.it > >> > >> < >> rifletto un istante; e mi scoraggio>>. Magritte. > >> oooO > >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > >> \ ( ( ) > >> \_) ) / > >> (_/ > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/simonpietro.romano > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > 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 > --f46d040711c5fd79cf04cd5b6515 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Simon also suggested that we need to enrich the framework. =A0We have gotte= n feedback in the past that it's difficult to read as I think there is = a middle level of detail that is missing. =A0We have had wonderful diagrams= in .ppts at the meetings but we have very few diagrams in the FW. =A0I thi= nk it could help a lot to add some.=A0

Mary.


= On Wed, Oct 31, 2012 at 8:17 AM, Roni Even <ron.even.tlv@gmail.com> wrote:
Hi Simon,
This will make the framework empty, section 1-4 do not have any information=
that merit a document.
Roni

-----Original Message-----
From: clue-bounces@ietf.org [m= ailto:clue-bounces@ietf.org] O= n Behalf Of
Simon Pietro Romano
Sent: 30 October, 2012 12:24 PM
To: Christian Groves
Cc: clue@ietf.org
Subject: Re: [clue] Data model - agreement on objective and basic approach<= br>
Hi Christian,

a rough estimation would be the following:

a) keep sections 1 through 4 inside the framework document;
b) move sections 5 through 8 to the data model document
c) move the XML schema to the data model document (final section of the dat= a
model, which provides 'one possible' example of how to formally des= cribe the
things in the document);
d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the
protocol document;
e) move subsection 9.4 to the call flows document;
f) move section 10 to the data model document;
g) move section 11 to the call flows document.

Obviously, the resulting framework document should be revised (and
enriched) in view of the proposed distribution of work inside the WG. I
would like it to represent an orchestration document, providing an overview=
of issues, requirements, architecture and protocols. A sort of summary
reference for all of the related "drill-down" documents, each exp= anding on a
specific WG item (data model, protocol, call flows, etc.).

I acknowledge the fact that this looks much like a revolution, but I
nonetheless believe that we already have most of the needed material at han= d
and just need to better distribute it across the documents produced by the<= br> WG.

Cheers,

Simon




Il 30/10/2012 10:33, Christian Groves ha scritto:
> Hello Simon,
>
> When you say that you want to remove "all" the data model st= uff from
> the framework can you be a bit more specific as to what parts you want=
> removed?
>
> Regards, Christian
>
> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote:
>> Hi all,
>>
>> just to be clear on the current structure of the data model schema= :
>> all the things you find there were 'extracted' (by Roberta= and me)
>> from information currently contained inside the framework draft (a= s
>> well as from some side documents, associated with either the data<= br> >> model or the envisaged call flows). So, unless we have misinterpre= ted
>> the above document(s) (which is obviously possible), we should fir= st
>> of all focus on the framework in order to try and converge on an >> agreed-upon CLUE architecture. Once done with this, we can fine-tu= ne
>> the data model. As I already stated on this list, it is my persona= l
>> opinion that we should remove from the framework document all of t= he
>> data-model stuff that it currently contains, and rather focus on a=
>> clear definition of framework components and interfaces. I might l= ook
>> naif, but I would like to arrive at an 'ordinary' set of d= ocuments:
>> (i) =A0general framework; (ii) data model; (iii) clue protocol (wi= th
>> advertisement and configuration messages); (iv) call flows (showin= g
>> how SDP O/A and CLUE protocol messages concur in effectively setti= ng
>> up a CLUE session).
>>
>> As to the 'UML vs XML' querelle, I would suggest that:
>>
>> 1. Both UML class diagrams and XML schema can be adopted for the >> description of the data model, i.e., the STATIC part of the
>> framework, associated with the description of what some of you
>> properly called a 'CLUE instance'; 2. UML sequence diagram= s can be
>> adopted to describe CLUE call flows, i.e. the DYNAMIC part of the<= br> >> framework, which clearly envisages the co-existence of SDP and CLU= E
>> protocol messages. XML schemas are not suitable for this dynamic >> part.
>>
>> This said, it is clear that CLUE protocol messages =A0(in particul= ar,
>> CLUE advertisements) will be constructed by leveraging information=
>> contained inside a CLUE instance. Which parts of a CLUE instance >> should go into an advertisement and which should be carried inside=
>> SDP can be a matter of discussion.
>>
>> My 2 cents,
>>
>> Simon
>>
>>
>> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: >>
>>> On 10/29/12 6:23 PM, Roni Even wrote:
>>>> Paul,
>>>> This was the statement I answered "no"
>>>> " The general agreement on the call is that the data = model as
>>>> reflected in draft-presta-clue-data-model-schema describes= the data
>>>> needed by the CLUE application"
>>>> I disagree that it reflects that data needed by a CLUE app= lication
>>>> and I explained why.
>>>
>>> OK, fair enough.
>>>
>>> Mary can comment, but my take was that the point of her questi= on was
>>> to distinguish between two alternatives:
>>> - the data model represents all the data needed by the clue ap= p.
>>> =A0(which implies to me that it encompasses all the data in th= e
>>> =A0framework.)
>>> - the data model represents the data to be exchanged in =A0clu= e
>>> messages.
>>>
>>> It is a bigger deal if the framework includes things that are = not
>>> needed by the clue application. I was of the impression that, = except
>>> for some fine tuning, we were largely in agreement on the fram= ework.
>>>
>>> If we don't have consensus on *that* then resolving that i= s of
>>> higher priority that much of the other stuff we are discussing= .
>>>
>>> Thanks,
>>> Paul
>>>
>>>> Roni
>>>>
>>>> -----Original Message-----
>>>> From: clue-bounce= s@ietf.org <mailto:clue-bou= nces@ietf.org>
>>>> [mailto:clue-boun= ces@ietf.org] On Behalf Of Paul Kyzivat
>>>> Sent: 29 October, 2012 9:46 PM
>>>> To: clue@ietf.org <= ;mailto:clue@ietf.org>
>>>> Subject: Re: [clue] Data model - agreement on objective an= d basic
>>>> approach
>>>>
>>>> On 10/29/12 3:19 PM, Roni Even wrote:
>>>>> Hi,
>>>>>
>>>>> My view is 'no". I still fail to see the need= for the encoding
>>>>> groups and individual encodes.
>>>>>
>>>>> In the current definition of capture scene, I am not s= ure what is
>>>>> the meaning of different individual encodes and eventu= ally the
>>>>> receiver can define what it can receive (Typically H.2= 64 is
>>>>> symmetric in terms of profile but does not need to be = in the
>>>>> level) and can ask for specific resolution with the SD= P image
>>>>> attribute
>>>>
>>>> ISTM that you are answering a different question than the = one Mary
>>>> asked.
>>>> You seem to be saying that you disagree with the framework= as it is
>>>> - that
>>>> it can/should be simpler.
>>>>
>>>> That is a separate question. If such changes were made it = might
>>>> affect a lot.
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>>> Roni Even
>>>>>
>>>>> *From:*clue-b= ounces@ietf.org <mailto:clu= e-bounces@ietf.org>
>>>>> [mailto:clue-= bounces@ietf.org] *On Behalf Of *Mary Barnes
>>>>> *Sent:* 29 October, 2012 7:52 PM
>>>>> *To:* CLUE
>>>>> *Subject:* [clue] Data model - agreement on objective = and basic
>>>>> approach
>>>>>
>>>>> On the call earlier today, we also discussed the data = model. =A0The
>>>>> general agreement on the call is that the data model a= s reflected
>>>>> in draft-presta-clue-data-model-schema describes the d= ata needed
>>>>> by the CLUE application - i.e., it's the CLUE inst= ance concept. It
>>>>> does not directly reflect the contents of a CLUE messa= ge. =A0The
>>>>> application data would be used to populate CLUE messag= es, as well
>>>>> as SDP and would reflect updates based on both the CLU= E and SDP
>>>>> signaling.
>>>>>
>>>>> If we can get agreement on that before the meeting, I = believe our
>>>>> discussions can be much more productive. If folks coul= d please
>>>>> reply "Yes" or "No" reflecting agr= eement with the above, that
>>>>> would be helpful. =A0If you reply "No", plea= se explain why.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Mary
>>>>>
>>>>> as CLUE WG co-chair
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> clue mailing list
>>>>> clue@ietf.org <= ;mailto:clue@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>>
>>>>
>>>> _______________________________________________
>>>> clue mailing list
>>>> clue@ietf.org <mai= lto:clue@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/clue
>>>>
>>>>
>>>
>>> _______________________________________________
>>> clue mailing list
>>> clue@ietf.org <mailto:= clue@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/clue
>>>
>>
>> _\\|//_
>> =A0 =A0 =A0 ( O-O )
>> =A0~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>> Simon Pietro Romano
>> Universita' di Napoli Federico II
>> =A0Computer Engineering Department
>> =A0 Phone: +39 081 7683823 -- Fax: +39 081 7683816
>> =A0e-mail: spromano@unina.it<= /a> <mailto:spromano@unina.it&g= t;
>>
>> <<Molti mi dicono che lo scoraggiamento =CB l'alibi degl= i =A0idioti. Ci
>> rifletto un istante; e mi scoraggio>>. Magritte.
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0oooO
>> =A0 ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> =A0 =A0 =A0 =A0\ ( =A0 =A0 =A0 =A0 =A0 =A0( =A0 )
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 =A0 =A0 = =A0 =A0) /
>> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(_/
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>

--
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0_\\|//_
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0( O-O )
=A0 =A0 ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Simon Pietro Romano
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Universita' di Napoli Federico II
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Computer Science Department
=A0 =A0 =A0 =A0 =A0Phone: +39 081 7683823 -- Fax: +39 081 7684219
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0e-mail: spromano@unina.it
=A0 =A0 =A0 =A0 =A0 =A0http://www.comics.unina.it/simonpietro.romano
=A0 =A0 =A0<<Molti mi dicono che lo scoraggiamento =E8 l'alibi de= gli
=A0 =A0 idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 oooO
=A0 =A0 ~~~~~~~~~~~~~~~~~~~~~~( =A0 )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\ ( =A0 =A0( =A0 ) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 \_) =A0 =A0) /
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (_/

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

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

--f46d040711c5fd79cf04cd5b6515-- From ron.even.tlv@gmail.com Wed Oct 31 07:05: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 9065821F8818 for ; Wed, 31 Oct 2012 07:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.509 X-Spam-Level: X-Spam-Status: No, score=-3.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dnX1grOKC0J9 for ; Wed, 31 Oct 2012 07:05:48 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9477F21F84D6 for ; Wed, 31 Oct 2012 07:05:47 -0700 (PDT) Received: by mail-ee0-f44.google.com with SMTP id d4so884403eek.31 for ; Wed, 31 Oct 2012 07:05:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=lA1divG++9Psc+78pGpKRBz8ZKMswgkdEdQLeaONrkQ=; b=x3whO+RhUW2Fib0M4fn4gJ5i9OV2q/2D/n8uWqL4oWtv6BcFJjMLFI3rfxRy8W9yjo T87OkwiA90KOQqfuYSneqRhELOoa4Gh1H/o1O4L3/c9Fhw215vRWTxrhNNQvMlfxsvL8 PmCahm0cCzoyZ4mlY5hx2jP+Cc0BgauEoB+JQIfQaAb9MVGjlmrgvB9sTYsvA+xFgXOM OFdVL72WfGNdDZHLbsu9Qb8T7zqW8XlveDYKgEU9JcCM0HxKPDOjuRx3/IgDPNRHdbU/ gAvzGpdN8y/CgfyX+y+GSYMyLLOe0cu0gyBhi/DxWBuLm1SQZGDsDfXqgETiQOWsCi+N dLXQ== Received: by 10.14.0.68 with SMTP id 44mr86478728eea.1.1351692346520; Wed, 31 Oct 2012 07:05:46 -0700 (PDT) Received: from RoniE (bzq-79-182-208-105.red.bezeqint.net. [79.182.208.105]) by mx.google.com with ESMTPS id o47sm8080307eem.11.2012.10.31.07.05.43 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 31 Oct 2012 07:05:45 -0700 (PDT) From: "Roni Even" To: "'Paul Kyzivat'" References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <760B7D45D1EFF74988DBF5C2122830C205B6195B@szxpml504-mbs.exmail.huawei.com> <01a701cdb6f2$8a772f60$9f658e20$@gmail.com> <50906F0D.1020004@alum.mit.edu> <01c401cdb733$062add60$12809820$@gmail.com> <509128E7.3090202@alum.mit.edu> In-Reply-To: <509128E7.3090202@alum.mit.edu> Date: Wed, 31 Oct 2012 16:03:33 +0200 Message-ID: <021301cdb770$85495c10$8fdc1430$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQH1H205IYhCmcjSpxYAUxN6zg5tsgC/Cc7eAw1ugkYCVsjGeAJj9POrAiIDFmQCKr40BgIYU8RPAL7MWZgBdCoLEQHfqE8SAfWEwnQCO2SgjQJeYGOCAl4F4PiWpT+ioA== Content-Language: en-us Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach 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, 31 Oct 2012 14:05:49 -0000 Hi Paul, See inline I am not sure What we are arguing, the mapping is always needed. I do no understand why you mention static and dynamic mapping. Roni -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]=20 Sent: 31 October, 2012 3:35 PM To: Roni Even Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic = approach On 10/31/12 2:43 AM, Roni Even wrote: > Paul, > I am saying that CLUE does not work without mapping of RTP streams=20 > (identified by SSRC) and Media Captures, it is true for static or=20 > dynamic mapping. Oh, ok. Yes, I thought that was clear. It is my understanding that the static mapping intends to associate a particular capture encoding with a particular *ssrc*, and so to the RTP stream with that ssrc. That only = works when the capture encoding has a 1:1 association with a single ssrc. Roni: the last sentence is the common usage today where the SSRC is = fixed by the sending EP or by the MCU who terminates the RTCP. The point of the RTP extension for the dynamic mapping is to carry an identifier for the capture encoding, independent of ssrc. That way the capture encoding of an RTP stream can be identified even when the ssrc = may change over time for that stream. Roni: The change may be signaled with the CSRC for the static use case. Thanks, Paul > Roni > > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf=20 > Of Paul Kyzivat > Sent: 31 October, 2012 2:22 AM > To: clue@ietf.org > Subject: Re: [clue] Data model - agreement on objective and basic=20 > approach > > On 10/30/12 7:01 PM, Roni Even wrote: >> Mary, >> >> Just as a point that CLUE does not work if you cannot say which SSRC=20 >> is a specific media capture in CLUE > > I have now gotten lost in this thread. I don't understand what in the=20 > thread this comment was intended to respond to. > > But responding to just this statement, it sounds like a denial of the=20 > dynamic mapping, which explicitly separates the identification of a=20 > capture (actually capture encoding) from an SSRC. > > So are you saying thata CLUE does not work with the dynamic mapping? > > Thanks, > Paul > >> Roni >> >> *From:*clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] *On=20 >> Behalf Of *Mary Barnes >> *Sent:* 30 October, 2012 11:49 PM >> *To:* Roni Even >> *Cc:* CLUE >> *Subject:* Re: [clue] Data model - agreement on objective and basic=20 >> approach >> >> I think that would belong in the protocol document - that is where = the >> SIPREC WG has described their usage of RTP. Any specific changes to >> the RTP and SDP would of course be submitted as documents in the=20 >> AVTCORE and MMUSIC WGs. >> >> However, it may be better to keep that document separate for a while=20 >> - that is also the model that SIPREC used/ >> >> Mary. >> >> On Tue, Oct 30, 2012 at 4:42 PM, Roni Even=20 >> > = wrote: >> >> Hi Mary, >> >> What about the mapping of RTP streams to Media Captures, where does=20 >> it fall >> >> BTW: the mapping may require an identfier for the media capture >> >> Roni >> >> --------------------------------------------------------------------- >> - >> -- >> >> *From:*clue-bounces@ietf.org =20 >> [clue-bounces@ietf.org ] on behalf of=20 >> Mary Barnes [mary.ietf.barnes@gmail.com=20 >> ] >> *Sent:* Tuesday, October 30, 2012 11:25 PM >> *To:* CLUE >> >> >> *Subject:* Re: [clue] Data model - agreement on objective and basic=20 >> approach >> >> I think this is a reasonable split and I don't think it's that much=20 >> of a killer task to do so. We have talked in the past about whether=20 >> we should split some material from the framework. I think doing so=20 >> will make it easier for individuals to edit the various pieces. We=20 >> will of course have to ensure consistency. However, this approach = adds some >> good checks and balances, I believe. This model is quite similar to >> what worked very well for the XCON work and it's quite similar to=20 >> what other WGs are doing (e.g., SIPREC). >> >> The chairs have delayed updating our milestones since we had not=20 >> decided individual deliverables related to the solution. >> >> As chair I would like to gauge consensus on this approach. So, if=20 >> people could please respond as to whether they support the general=20 >> idea of splitting the work into the following documents/deliverables: >> >> 1) Framework >> >> 2) Data model >> >> 3) Protocol >> >> 4) Call Flows >> >> If we can get consensus on the basic idea, then we can work out the=20 >> details starting with Simon's suggestion. >> >> I do have one comment about the "orchestration document" as I think=20 >> that might be appropriate for the framework, but we could certainly=20 >> work on that separately and decide later. >> >> Thanks, >> >> Mary. >> >> On Tue, Oct 30, 2012 at 5:23 AM, Simon Pietro Romano=20 >> > wrote: >> >> Hi Christian, >> >> a rough estimation would be the following: >> >> a) keep sections 1 through 4 inside the framework document; >> b) move sections 5 through 8 to the data model document >> c) move the XML schema to the data model document (final section of=20 >> the data model, which provides 'one possible' example of how to=20 >> formally describe the things in the document); >> d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the=20 >> protocol document; >> e) move subsection 9.4 to the call flows document; >> f) move section 10 to the data model document; >> g) move section 11 to the call flows document. >> >> Obviously, the resulting framework document should be revised (and >> enriched) in view of the proposed distribution of work inside the WG. >> I would like it to represent an orchestration document, providing an=20 >> overview of issues, requirements, architecture and protocols. >> >> A sort of summary reference for all of the related "drill-down" >> documents, each expanding on a specific WG item (data model, >> protocol, call flows, etc.). >> >> I acknowledge the fact that this looks much like a revolution, = but I >> nonetheless believe that we already have most of the needed = material >> at hand and just need to better distribute it across the = documents >> produced by the WG. >> >> Cheers, >> >> Simon >> >> >> >> >> Il 30/10/2012 10:33, Christian Groves ha scritto: >> >> Hello Simon, >> >> When you say that you want to remove "all" the data model = stuff >> from the framework can you be a bit more specific as to what >> parts you want removed? >> >> Regards, Christian >> >> On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: >> >> Hi all, >> >> just to be clear on the current structure of the data model >> schema: all the things you find there were 'extracted' (by >> Roberta and me) from information currently contained inside = the >> framework draft (as well as from some side documents, = associated >> with either the data model or the envisaged call flows). So, >> unless we have misinterpreted the above document(s) (which = is >> obviously possible), we should first of all focus on the >> framework in order to try and converge on an agreed-upon = CLUE >> architecture. Once done with this, we can fine-tune the data >> model. As I already stated on this list, it is my personal >> opinion that we should remove from the framework document = all of >> the data-model stuff that it currently contains, and rather >> focus on a clear definition of framework components and >> interfaces. I might look naif, but I would like to arrive at = an >> 'ordinary' set of documents: (i) general framework; (ii) = data >> model; (iii) clue protocol (with advertisement and = configuration >> messages); (iv) call flows (showing how SDP O/A and CLUE >> protocol messages concur in effectively setting up a CLUE > session). >> >> As to the 'UML vs XML' querelle, I would suggest that: >> >> 1. Both UML class diagrams and XML schema can be adopted for = the >> description of the data model, i.e., the STATIC part of the >> framework, associated with the description of what some of = you >> properly called a 'CLUE instance'; >> 2. UML sequence diagrams can be adopted to describe CLUE = call >> flows, i.e. the DYNAMIC part of the framework, which clearly >> envisages the co-existence of SDP and CLUE protocol = messages. >> XML schemas are not suitable for this dynamic part. >> >> This said, it is clear that CLUE protocol messages (in >> particular, CLUE advertisements) will be constructed by >> leveraging information contained inside a CLUE instance. = Which >> parts of a CLUE instance should go into an advertisement and >> which should be carried inside SDP can be a matter of discussion. >> >> My 2 cents, >> >> Simon >> >> >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha = scritto: >> >> On 10/29/12 6:23 PM, Roni Even wrote: >> >> Paul, >> This was the statement I answered "no" >> " The general agreement on the call is that the data model = as >> reflected in >> draft-presta-clue-data-model-schema describes the data = needed by >> the CLUE >> application" >> I disagree that it reflects that data needed by a CLUE >> application and I >> explained why. >> >> >> OK, fair enough. >> >> Mary can comment, but my take was that the point of her = question >> was to distinguish between two alternatives: >> - the data model represents all the data needed by the clue = app. >> (which implies to me that it encompasses all the data in = the >> framework.) >> - the data model represents the data to be exchanged in >> clue messages. >> >> It is a bigger deal if the framework includes things that = are >> not needed by the clue application. I was of the impression >> that, except for some fine tuning, we were largely in = agreement >> on the framework. >> >> If we don't have consensus on *that* then resolving that is = of >> higher priority that much of the other stuff we are = discussing. >> >> Thanks, >> Paul >> >> Roni >> >> -----Original Message----- >> From: clue-bounces@ietf.org >> > >> [mailto:clue-bounces@ietf.org = ] On >> Behalf Of Paul >> Kyzivat >> Sent: 29 October, 2012 9:46 PM >> To: clue@ietf.org = > > >> Subject: Re: [clue] Data model - agreement on objective and >> basic approach >> >> On 10/29/12 3:19 PM, Roni Even wrote: >> >> Hi, >> >> My view is 'no". I still fail to see the need for the = encoding >> groups >> and individual encodes. >> >> In the current definition of capture scene, I am not sure = what >> is the >> meaning of different individual encodes and eventually the > receiver >> can define what it can receive (Typically H.264 is symmetric = in >> terms >> of profile but does not need to be in the level) and can ask = for >> specific resolution with the SDP image attribute >> >> >> ISTM that you are answering a different question than the = one >> Mary asked. >> You seem to be saying that you disagree with the framework = as it >> is - that >> it can/should be simpler. >> >> That is a separate question. If such changes were made it = might >> affect a >> lot. >> >> Thanks, >> Paul >> >> Roni Even >> >> *From:*clue-bounces@ietf.org >> > >> [mailto:clue-bounces@ietf.org = ] >> *On Behalf >> Of *Mary Barnes >> *Sent:* 29 October, 2012 7:52 PM >> *To:* CLUE >> *Subject:* [clue] Data model - agreement on objective and = basic >> approach >> >> On the call earlier today, we also discussed the data model. The >> general agreement on the call is that the data model as=20 >> reflected > in >> draft-presta-clue-data-model-schema describes the data=20 >> needed by > the >> CLUE application - i.e., it's the CLUE instance concept. It=20 >> does > not >> directly reflect the contents of a CLUE message. The >> application data >> would be used to populate CLUE messages, as well as SDP and would >> reflect updates based on both the CLUE and SDP signaling. >> >> If we can get agreement on that before the meeting, I = believe our >> discussions can be much more productive. If folks could=20 >> please > reply >> "Yes" or "No" reflecting agreement with the above, that = would be >> helpful. If you reply "No", please explain why. >> >> Regards, >> >> Mary >> >> as CLUE WG co-chair >> >> >> >> _______________________________________________ >> 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 >> >> >> _\\|//_ >> ( O-O ) >> = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> Computer Engineering Department >> Phone: +39 081 7683823 -- = Fax: >> +39 081 7683816 >> e-mail: spromano@unina.it >> > >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. >> oooO >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ = Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> \ ( ( ) >> \_) ) / >> (_/ >> >> >> >> >> >> >> >> _______________________________________________ >> 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 >> >> -- >> >> _\\|//_ >> ( O-O ) >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ >> Simon Pietro Romano >> Universita' di Napoli Federico II >> >> Computer Science Department >> Phone: +39 081 7683823 -- = Fax: >> +39 081 7684219 >> e-mail: spromano@unina.it >> http://www.comics.unina.it/simonpietro.romano >> >> >> >> <> idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. >> oooO >> >> ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ >> >> >> \ ( ( ) >> \_) ) / >> (_/ >> >> _______________________________________________ >> 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 Wed Oct 31 09:01:59 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 0340B21F87C7 for ; Wed, 31 Oct 2012 09:01:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.287 X-Spam-Level: X-Spam-Status: No, score=-103.287 tagged_above=-999 required=5 tests=[AWL=0.311, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9z41nrJuHam for ; Wed, 31 Oct 2012 09:01:57 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8ED9B21F854A for ; Wed, 31 Oct 2012 09:01:57 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1297085lbo.31 for ; Wed, 31 Oct 2012 09:01:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=G+cDsZgpVL69epP6wfedXwgf2zdNzbZOulgyO3GkjYk=; b=KhGKDbxqhX7PLcN+EE5i6YHEmEBZP9a7p0LOs08Aht0UuqAfe/yA4/JUlVR8xVYwd5 ZgFr0HaZDe3HnTMGEUufNwuwlUcTEJ6d68eiPbON/AMP7tNdxayUYRA7uZxdobWSGz0n xfYzGg1g55pvMrFETIDhAR18g6ECYcHCcW0zZ0QljOoS6/KkLlwjudbnuzj3IQan6fIv 1WxiqC3OFjeu5sLUNKvBne626tI/owICsZRK0I+f4sqsfFw2s9BcpW8lgP+I0GEFvfJC 5cmErxvGtUBGj0fhhm5M35pK3K0dZgRpvh/8LIEvLVe3vsdZS0FNuJsf7M5tRo3r1+Lp v2Eg== MIME-Version: 1.0 Received: by 10.112.99.37 with SMTP id en5mr14882303lbb.1.1351699316498; Wed, 31 Oct 2012 09:01:56 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Wed, 31 Oct 2012 09:01:56 -0700 (PDT) In-Reply-To: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> Date: Wed, 31 Oct 2012 11:01:56 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=f46d0401f9ff9a625404cd5d05fe Subject: [clue] Doodle: Link for poll "CLUE WG dinner" 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, 31 Oct 2012 16:01:59 -0000 --f46d0401f9ff9a625404cd5d05fe Content-Type: text/plain; charset=ISO-8859-1 Hi all, I thought it would be good as usual for us to have a CLUE informal dinner at this IETF meeting. Right now, Wednesday evening is the only evening I have open. I know that conflicts with a certain company's regular mafia dinner, but I don't think that eliminates too many people. If folks could please respond no later than 5pm on Nov 4th, so I can get an appropriate reservation. Unless I find another restaurant or someone has a suggestion that is more exciting, I will plan on Legal Seafoods (I'm sure I can tolerate 3 meals in one week there ;) Mary. ---------- Forwarded message ---------- From: Doodle Date: Wed, Oct 31, 2012 at 10:56 AM Subject: Doodle: Link for poll "CLUE WG dinner" To: mary.ietf.barnes@gmail.com You have initiated a poll "CLUE WG dinner" at Doodle. The link to your poll is: http://www.doodle.com/7q2ipk6nvkezk8y3 Share this link with all those who should cast their votes. Do not forget to cast your vote, too. (If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.) --f46d0401f9ff9a625404cd5d05fe Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

I thought it would be good as usual for us to ha= ve a CLUE informal dinner at this IETF meeting. =A0Right now, Wednesday eve= ning is the only evening I have open. =A0I know that conflicts with a certa= in company's regular mafia dinner, but I don't think that eliminate= s too many people.=A0

If folks could please respond no later than 5pm on Nov = 4th, so I can get an appropriate reservation. =A0Unless I find another rest= aurant or someone has a suggestion that is more exciting, I will plan on Le= gal Seafoods (I'm sure I can tolerate 3 meals in one week there ;)=A0

Mary.=A0

---------- F= orwarded message ----------
From: Doodle <mailer@doodle= .com>
Date: Wed, Oct 31, 2012 at 10:56 AM
Subject: Doodle: Link for poll "= ;CLUE WG dinner"
To: = mary.ietf.barnes@gmail.com


You have initiated a poll "C= LUE WG dinner" at Doodle. The link to your poll is:

http:/= /www.doodle.com/7q2ipk6nvkezk8y3

Share this link with all those who should cast their votes. Do not forget t= o cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used yo= ur e-mail address; simply ignore this e-mail, please.)

--f46d0401f9ff9a625404cd5d05fe-- From pkyzivat@alum.mit.edu Wed Oct 31 11:25:34 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 2E3D321F8845 for ; Wed, 31 Oct 2012 11:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.437 X-Spam-Level: X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG5vUBAj61dW for ; Wed, 31 Oct 2012 11:25:33 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 16EF921F8856 for ; Wed, 31 Oct 2012 11:25:32 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id HqUt1k00317dt5G5DuRdu9; Wed, 31 Oct 2012 18:25:37 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id HuSX1k00M3ZTu2S3ZuSXQ0; Wed, 31 Oct 2012 18:26:31 +0000 Message-ID: <50916D1A.3040402@alum.mit.edu> Date: Wed, 31 Oct 2012 14:25:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1 MIME-Version: 1.0 To: clue@ietf.org References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" 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, 31 Oct 2012 18:25:34 -0000 On 10/31/12 12:01 PM, Mary Barnes wrote: > Hi all, > > I thought it would be good as usual for us to have a CLUE informal > dinner at this IETF meeting. Right now, Wednesday evening is the only > evening I have open. I know that conflicts with a certain company's > regular mafia dinner, but I don't think that eliminates too many people. I can do that. > If folks could please respond no later than 5pm on Nov 4th, so I can get > an appropriate reservation. Unless I find another restaurant or someone > has a suggestion that is more exciting, I will plan on Legal Seafoods > (I'm sure I can tolerate 3 meals in one week there ;) I guess I can tolerate fish once. :-) BBQ? Thanks, Paul > Mary. > > ---------- Forwarded message ---------- > From: *Doodle* > > Date: Wed, Oct 31, 2012 at 10:56 AM > Subject: Doodle: Link for poll "CLUE WG dinner" > To: mary.ietf.barnes@gmail.com > > > You have initiated a poll "CLUE WG dinner" at Doodle. The link to your > poll is: > > http://www.doodle.com/7q2ipk6nvkezk8y3 > > Share this link with all those who should cast their votes. Do not > forget to cast your vote, too. > (If you did not initiate this poll, somebody must accidentally have used > your e-mail address; simply ignore this e-mail, please.) > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From mary.ietf.barnes@gmail.com Wed Oct 31 11:34:42 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 3BAA321F8865 for ; Wed, 31 Oct 2012 11:34:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=-0.553, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egi+G03vM2Yp for ; Wed, 31 Oct 2012 11:34:41 -0700 (PDT) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id C39E921F8860 for ; Wed, 31 Oct 2012 11:34:40 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id k13so1425402lbo.31 for ; Wed, 31 Oct 2012 11:34:39 -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=5uNVp5oyiIJQ1+xyMmT+RUYl9HIPevzOK+Uq0+KePAg=; b=SFan2rPDJQW652h3fdyjOv6HvUcOmAsT+Ey0iPWqvsNHp6/wpiWo8ENOd1+NlI+X3a Yusw+p/rn4TThLUPbEqgm1E6I+aqAx243zVLIKt9v0qe/66343apocsCQyCU/qiivbaD EOkdMA10oFWeyBNXpi2Vi/GCypUyH7FRfGe3g2Gp+ANTIqy+D0ueDlOd0cMy7egpNZ7p g/y5tja2sYytbvPUdAxx6L2STuBeEGvGhuB0t5Q6L45D+34xwX14wHhdKK9+Ab+HLyL6 ci/Nb+uJuLBQvkMkH4OMx27vjHfJ820FfeLHD2jR0XxMKwuvwedYvZbpQWIYHxu8BKqB Hjcg== MIME-Version: 1.0 Received: by 10.112.24.6 with SMTP id q6mr15347078lbf.24.1351708479569; Wed, 31 Oct 2012 11:34:39 -0700 (PDT) Received: by 10.114.69.139 with HTTP; Wed, 31 Oct 2012 11:34:39 -0700 (PDT) In-Reply-To: <50916D1A.3040402@alum.mit.edu> References: <1784642497.12892.1351698965567.POLL_ADMIN_PARTICIPATELINK.doodle@worker1> <50916D1A.3040402@alum.mit.edu> Date: Wed, 31 Oct 2012 13:34:39 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=e0cb4efe2a0ac3c00404cd5f27f7 Cc: clue@ietf.org Subject: Re: [clue] Doodle: Link for poll "CLUE WG dinner" 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, 31 Oct 2012 18:34:42 -0000 --e0cb4efe2a0ac3c00404cd5f27f7 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Oct 31, 2012 at 1:25 PM, Paul Kyzivat wrote: > On 10/31/12 12:01 PM, Mary Barnes wrote: > >> Hi all, >> >> I thought it would be good as usual for us to have a CLUE informal >> dinner at this IETF meeting. Right now, Wednesday evening is the only >> evening I have open. I know that conflicts with a certain company's >> regular mafia dinner, but I don't think that eliminates too many people. >> > > I can do that. > > > If folks could please respond no later than 5pm on Nov 4th, so I can get >> an appropriate reservation. Unless I find another restaurant or someone >> has a suggestion that is more exciting, I will plan on Legal Seafoods >> (I'm sure I can tolerate 3 meals in one week there ;) >> > > I guess I can tolerate fish once. :-) > [MB] They do have menu items other than fish including steak and chicken and I think they have a pasta dish. [/MB] > > BBQ? > [MB] My son likes BBQ sauce on his salmon so maybe you get that at LS as well. I don't do BBQ - I don't eat sauces for the most part as they can have suspicious ingredients. [/MB] > > Thanks, > Paul > > Mary. >> >> ---------- Forwarded message ---------- >> From: *Doodle* > >> Date: Wed, Oct 31, 2012 at 10:56 AM >> Subject: Doodle: Link for poll "CLUE WG dinner" >> To: mary.ietf.barnes@gmail.com >> > >> >> >> You have initiated a poll "CLUE WG dinner" at Doodle. The link to your >> poll is: >> >> http://www.doodle.com/**7q2ipk6nvkezk8y3 >> >> Share this link with all those who should cast their votes. Do not >> forget to cast your vote, too. >> (If you did not initiate this poll, somebody must accidentally have used >> your e-mail address; simply ignore this e-mail, please.) >> >> >> >> ______________________________**_________________ >> 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 > --e0cb4efe2a0ac3c00404cd5f27f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Oct 31, 2012 at 1:25 PM, Paul Ky= zivat <pkyzivat@alum.mit.edu> wrote:
On 10/31/12 12:01 PM, Mary Barnes wrote:
Hi all,

I thought it would be good as usual for us to have a CLUE informal
dinner at this IETF meeting. =A0Right now, Wednesday evening is the only evening I have open. =A0I know that conflicts with a certain company's<= br> regular mafia dinner, but I don't think that eliminates too many people= .

I can do that.


If folks could please respond no later than 5pm on Nov 4th, so I can get an appropriate reservation. =A0Unless I find another restaurant or someone<= br> has a suggestion that is more exciting, I will plan on Legal Seafoods
(I'm sure I can tolerate 3 meals in one week there ;)

I guess I can tolerate fish once. :-)

[= MB] They do have menu items other than fish including steak and chicken and= I think they have a pasta dish. [/MB]=A0

BBQ?
[MB] My son likes BBQ sauce on his salmon so mayb= e you get that at LS as well. =A0 I don't do BBQ - I don't eat sauc= es for the most part as they can have suspicious ingredients. [/MB] =A0

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

Mary.

---------- Forwarded message ----------
From: *Doodle* <m= ailer@doodle.com <mailto:mailer@doodle.com>>
Date: Wed, Oct 31, 2012 at 10:56 AM
Subject: Doodle: Link for poll "CLUE WG dinner"
To: mary.ie= tf.barnes@gmail.com <mailto:mary.ietf.barnes@gmail.com>


You have initiated a poll "CLUE WG dinner" at Doodle. The link to= your
poll is:

http:/= /www.doodle.com/7q2ipk6nvkezk8y3

Share this link with all those who should cast their votes. Do not
forget to cast your vote, too.
(If you did not initiate this poll, somebody must accidentally have used your e-mail address; simply ignore this e-mail, please.)



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


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

--e0cb4efe2a0ac3c00404cd5f27f7-- From Christian.Groves@nteczone.com Wed Oct 31 17:46: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 94C7321F870E for ; Wed, 31 Oct 2012 17:46:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.374 X-Spam-Level: X-Spam-Status: No, score=-2.374 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJ57t6eZrdyJ for ; Wed, 31 Oct 2012 17:46:05 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id E572D21F86DD for ; Wed, 31 Oct 2012 17:46:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACrFkVB20ZE5/2dsb2JhbAANN8cIAQEBBAEBAS8BBRsUBwoBDAICCxEBAwEBAQkWCAcJAwIBAgEJBgYfAwYIBg0BBQIBAYdwAxqnTIoQDYlUBIsNZxqGIQOLR4Z9gV2IMIRWiBSBUA Received: from ppp118-209-145-57.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.145.57]) by ipmail07.adl2.internode.on.net with ESMTP; 01 Nov 2012 11:16:01 +1030 Message-ID: <5091C644.5070401@nteczone.com> Date: Thu, 01 Nov 2012 11:45:56 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: Mary Barnes References: <00ed01cdb60a$48ad7d70$da087850$@gmail.com> <508EDCE7.6090204@alum.mit.edu> <00fc01cdb623$fed20620$fc761260$@gmail.com> <508F0AA1.2010006@alum.mit.edu> <508F9F00.8040709@nteczone.com> <508FAABC.2000404@unina.it> <020401cdb76a$16131c60$42395520$@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: clue@ietf.org Subject: Re: [clue] Data model - agreement on objective and basic approach X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 00:46:06 -0000 I agree the framework document in its current state isn't the easiest or most precise document so we need to do something to make it easier to understand. However I agree with Roni that removing sections 1-4 doesn't leave much. I still am not convinced about having a data model document related to a CLUE instance. What I'm trying to see is the actual benefit for this approach? Is it to help implementers? Is it to help us as specifiers? I know XCON and SIPREC followed this approach but from my view as a casual observer of the process is that these activities took a long time to completion. My fear is that Simon will be the only one who actually understands the data model well. Others will just be put off from looking closely at it because of the syntax. Regards, Christian On 1/11/2012 1:05 AM, Mary Barnes wrote: > Simon also suggested that we need to enrich the framework. We have > gotten feedback in the past that it's difficult to read as I think > there is a middle level of detail that is missing. We have had > wonderful diagrams in .ppts at the meetings but we have very few > diagrams in the FW. I think it could help a lot to add some. > > Mary. > > > On Wed, Oct 31, 2012 at 8:17 AM, Roni Even > wrote: > > Hi Simon, > This will make the framework empty, section 1-4 do not have any > information > that merit a document. > Roni > > -----Original Message----- > From: clue-bounces@ietf.org > [mailto:clue-bounces@ietf.org ] On > Behalf Of > Simon Pietro Romano > Sent: 30 October, 2012 12:24 PM > To: Christian Groves > Cc: clue@ietf.org > Subject: Re: [clue] Data model - agreement on objective and basic > approach > > Hi Christian, > > a rough estimation would be the following: > > a) keep sections 1 through 4 inside the framework document; > b) move sections 5 through 8 to the data model document > c) move the XML schema to the data model document (final section > of the data > model, which provides 'one possible' example of how to formally > describe the > things in the document); > d) move section 9, together with subsections 9.1, 9.2 and 9.3 to the > protocol document; > e) move subsection 9.4 to the call flows document; > f) move section 10 to the data model document; > g) move section 11 to the call flows document. > > Obviously, the resulting framework document should be revised (and > enriched) in view of the proposed distribution of work inside the > WG. I > would like it to represent an orchestration document, providing an > overview > of issues, requirements, architecture and protocols. A sort of summary > reference for all of the related "drill-down" documents, each > expanding on a > specific WG item (data model, protocol, call flows, etc.). > > I acknowledge the fact that this looks much like a revolution, but I > nonetheless believe that we already have most of the needed > material at hand > and just need to better distribute it across the documents > produced by the > WG. > > Cheers, > > Simon > > > > > Il 30/10/2012 10:33, Christian Groves ha scritto: > > Hello Simon, > > > > When you say that you want to remove "all" the data model stuff from > > the framework can you be a bit more specific as to what parts > you want > > removed? > > > > Regards, Christian > > > > On 30/10/2012 7:03 PM, Simon Pietro Romano wrote: > >> Hi all, > >> > >> just to be clear on the current structure of the data model schema: > >> all the things you find there were 'extracted' (by Roberta and me) > >> from information currently contained inside the framework draft (as > >> well as from some side documents, associated with either the data > >> model or the envisaged call flows). So, unless we have > misinterpreted > >> the above document(s) (which is obviously possible), we should > first > >> of all focus on the framework in order to try and converge on an > >> agreed-upon CLUE architecture. Once done with this, we can > fine-tune > >> the data model. As I already stated on this list, it is my personal > >> opinion that we should remove from the framework document all > of the > >> data-model stuff that it currently contains, and rather focus on a > >> clear definition of framework components and interfaces. I > might look > >> naif, but I would like to arrive at an 'ordinary' set of documents: > >> (i) general framework; (ii) data model; (iii) clue protocol (with > >> advertisement and configuration messages); (iv) call flows (showing > >> how SDP O/A and CLUE protocol messages concur in effectively > setting > >> up a CLUE session). > >> > >> As to the 'UML vs XML' querelle, I would suggest that: > >> > >> 1. Both UML class diagrams and XML schema can be adopted for the > >> description of the data model, i.e., the STATIC part of the > >> framework, associated with the description of what some of you > >> properly called a 'CLUE instance'; 2. UML sequence diagrams can be > >> adopted to describe CLUE call flows, i.e. the DYNAMIC part of the > >> framework, which clearly envisages the co-existence of SDP and CLUE > >> protocol messages. XML schemas are not suitable for this dynamic > >> part. > >> > >> This said, it is clear that CLUE protocol messages (in particular, > >> CLUE advertisements) will be constructed by leveraging information > >> contained inside a CLUE instance. Which parts of a CLUE instance > >> should go into an advertisement and which should be carried inside > >> SDP can be a matter of discussion. > >> > >> My 2 cents, > >> > >> Simon > >> > >> > >> Il giorno 30/ott/2012, alle ore 00:00, Paul Kyzivat ha scritto: > >> > >>> On 10/29/12 6:23 PM, Roni Even wrote: > >>>> Paul, > >>>> This was the statement I answered "no" > >>>> " The general agreement on the call is that the data model as > >>>> reflected in draft-presta-clue-data-model-schema describes > the data > >>>> needed by the CLUE application" > >>>> I disagree that it reflects that data needed by a CLUE > application > >>>> and I explained why. > >>> > >>> OK, fair enough. > >>> > >>> Mary can comment, but my take was that the point of her > question was > >>> to distinguish between two alternatives: > >>> - the data model represents all the data needed by the clue app. > >>> (which implies to me that it encompasses all the data in the > >>> framework.) > >>> - the data model represents the data to be exchanged in clue > >>> messages. > >>> > >>> It is a bigger deal if the framework includes things that are not > >>> needed by the clue application. I was of the impression that, > except > >>> for some fine tuning, we were largely in agreement on the > framework. > >>> > >>> If we don't have consensus on *that* then resolving that is of > >>> higher priority that much of the other stuff we are discussing. > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Roni > >>>> > >>>> -----Original Message----- > >>>> From: clue-bounces@ietf.org > > > >>>> [mailto:clue-bounces@ietf.org ] > On Behalf Of Paul Kyzivat > >>>> Sent: 29 October, 2012 9:46 PM > >>>> To: clue@ietf.org > > > >>>> Subject: Re: [clue] Data model - agreement on objective and basic > >>>> approach > >>>> > >>>> On 10/29/12 3:19 PM, Roni Even wrote: > >>>>> Hi, > >>>>> > >>>>> My view is 'no". I still fail to see the need for the encoding > >>>>> groups and individual encodes. > >>>>> > >>>>> In the current definition of capture scene, I am not sure > what is > >>>>> the meaning of different individual encodes and eventually the > >>>>> receiver can define what it can receive (Typically H.264 is > >>>>> symmetric in terms of profile but does not need to be in the > >>>>> level) and can ask for specific resolution with the SDP image > >>>>> attribute > >>>> > >>>> ISTM that you are answering a different question than the one > Mary > >>>> asked. > >>>> You seem to be saying that you disagree with the framework as > it is > >>>> - that > >>>> it can/should be simpler. > >>>> > >>>> That is a separate question. If such changes were made it might > >>>> affect a lot. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>>> Roni Even > >>>>> > >>>>> *From:*clue-bounces@ietf.org > > > >>>>> [mailto:clue-bounces@ietf.org > ] *On Behalf Of *Mary Barnes > >>>>> *Sent:* 29 October, 2012 7:52 PM > >>>>> *To:* CLUE > >>>>> *Subject:* [clue] Data model - agreement on objective and basic > >>>>> approach > >>>>> > >>>>> On the call earlier today, we also discussed the data model. > The > >>>>> general agreement on the call is that the data model as > reflected > >>>>> in draft-presta-clue-data-model-schema describes the data needed > >>>>> by the CLUE application - i.e., it's the CLUE instance > concept. It > >>>>> does not directly reflect the contents of a CLUE message. The > >>>>> application data would be used to populate CLUE messages, as > well > >>>>> as SDP and would reflect updates based on both the CLUE and SDP > >>>>> signaling. > >>>>> > >>>>> If we can get agreement on that before the meeting, I > believe our > >>>>> discussions can be much more productive. If folks could please > >>>>> reply "Yes" or "No" reflecting agreement with the above, that > >>>>> would be helpful. If you reply "No", please explain why. > >>>>> > >>>>> Regards, > >>>>> > >>>>> Mary > >>>>> > >>>>> as CLUE WG co-chair > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> 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 > >>> > >> > >> _\\|//_ > >> ( O-O ) > >> ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > >> Simon Pietro Romano > >> Universita' di Napoli Federico II > >> Computer Engineering Department > >> Phone: +39 081 7683823 -- Fax: > +39 081 7683816 > >> e-mail: spromano@unina.it > > > >> > >> < >> rifletto un istante; e mi scoraggio>>. Magritte. > >> oooO > >> ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > >> \ ( ( ) > >> \_) ) / > >> (_/ > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > -- > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Science Department > Phone: +39 081 7683823 -- > Fax: +39 081 7684219 > e-mail: spromano@unina.it > http://www.comics.unina.it/simonpietro.romano > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~( )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_/ > > _______________________________________________ > 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 Christian.Groves@nteczone.com Wed Oct 31 19:31:38 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 5606221F8620 for ; Wed, 31 Oct 2012 19:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HG6EPGciEh7r for ; Wed, 31 Oct 2012 19:31:23 -0700 (PDT) Received: from ipmail07.adl2.internode.on.net (ipmail07.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:7]) by ietfa.amsl.com (Postfix) with ESMTP id 6C27421F8526 for ; Wed, 31 Oct 2012 19:31:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApIBAFvdkVB20ZE5/2dsb2JhbAANN8dHGxUQPRYYAwIBAgFLDQgBAYgNp0qTapIzA5cQkis Received: from ppp118-209-145-57.lns20.mel6.internode.on.net (HELO [127.0.0.1]) ([118.209.145.57]) by ipmail07.adl2.internode.on.net with ESMTP; 01 Nov 2012 13:01:21 +1030 Message-ID: <5091DEF5.6010608@nteczone.com> Date: Thu, 01 Nov 2012 13:31:17 +1100 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [clue] CLUE media capture description X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Nov 2012 02:31:38 -0000 CLUE media capture description draft-groves-clue-capture-attr-00 I won't be attending the IETF next week so as a pre-cursor to next weeks CLUE WG meeting I thought i'd put a few words together about draft-groves-clue-capture-attr-0 http://datatracker.ietf.org/doc/draft-groves-clue-capture-attr/ The main idea behind the draft is that a CLUE advertisement should include enough information for the receiver to make an educated decision about what captures it chooses. Having a had a close look at the content attribute I think (for the reasons outlined in the draft) it is insufficient to fully describe the multi-stream conferencing environments that CLUE is addressing/enabling. A contribution with essentially the same text as the draft was submitted to the recent Q.5/16 meeting to solicit feedback from the people at the meeting about the different parameters presented in the draft. In general I think people were in agreement that the current Content attribute was not sufficient. However it was noted that it needs to be considered how CLUE maps to the existing usages of the content attribute and mapping to H.239. Below is a list of attributes and comments. If I've left out anything or mispoken hopefully Steve Botzko can correct me. Presentation ------------ People thought it was worthwhile to know if a capture related to a presentation. There was some questioning if it was worthwhile to know if the capture was slides, images etc. It was thought it may help where multiple presentation streams were used. View ---- It was clarified that the aim of the attribute is to allow a remote end to make an automatic decision on what region of the scene it wants to see. The idea is that there is a standard keyword that the remote end could scan for e.g. lectern. This is a way of providing meaning to a particular spatial area. Language -------- There seemed to be general support for a language parameter. Role ---- It was thought that role could be related to "participants" or "material". Currently the attribute only discusses role from the aspect of a participant. It was also noted that the role may change based on meeting type. For example: in the medical use case there could be "Surgeon", "Professor", in an accessible conference there could be an "Interpreter" or "signer". With respect to Materials it was thought presentation could show something like "Agenda", "Contribution". Priority -------- There was some discussion as to whether this was needed. It was thought that if captures were properly described then priority wouldn't be needed as the remote end could make an educated decision about what it wants. At the moment with the minimal set of attributes it was thought that priority at least helped the remote end make a decision. Dynamic ------- I think people were OK with this being optional. Embedded Text ------------- Again I think people thought it was reasonable. It was clarified this could also be used to indicate captioning was being used with the capture. Supplementary description ------------------------- There was some question about how this related to side bar conferences. It was clarified this was mainly about the case where information (captures) were provided by people (or devices) who were not captured by the conference video. Telepresence ------------ This parameter probably had the least support/understanding. I was noted that CLUE was to allow multi-stream operation it didn't necessarily indicate/mandate a telepresence experience. Hopefully this provides some further background for the CLUE discussions. If the group could come to some general agreement about each of the parameters then I could work on some specific text for the framework (or whatever document we decide). Regards, Christian