From nobody Mon Dec 1 07:18:29 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 272FC1A1BF8 for ; Mon, 1 Dec 2014 07:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.664 X-Spam-Level: X-Spam-Status: No, score=0.664 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Rz9R15hIRqO for ; Mon, 1 Dec 2014 07:18:25 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [96.114.154.164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90FB91A1BFF for ; Mon, 1 Dec 2014 07:18:21 -0800 (PST) Received: from resomta-po-12v.sys.comcast.net ([96.114.154.236]) by resqmta-po-05v.sys.comcast.net with comcast id NFJ81p00A56HXL001FJK4x; Mon, 01 Dec 2014 15:18:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-12v.sys.comcast.net with comcast id NFJK1p0053Ge9ey01FJK8F; Mon, 01 Dec 2014 15:18:19 +0000 Message-ID: <547C86D9.2020309@alum.mit.edu> Date: Mon, 01 Dec 2014 10:18:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5477CEDE.30907@nteczone.com> In-Reply-To: <5477CEDE.30907@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417447099; bh=KsPLK2aP9uesA/Nfl9vlwv+3zA8BbUUOAx1117OnwO0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=njCdIsvu2kkiXGioXCsIcSmAu+kI7H3ge+k08NLkaFtqoRkZfeii6b/7x94urDodF 3aFjqcSgZqa1h5m66/nWHKY0DyqJ2Ztbhu/NIjZAknsxZvcYRTt2Bp2niXvFrSJzO8 7MiaJ3w3dYm/r5moCDGNvdO7jqoXxl/pUYwcYTeU9bk0RZFHJuPZfs+GYqT0VX7hiY rLk0JXZKPm757Ra51zDQ5vYeiauIw94P0L+INfifH2DzapjnMio3Mgxc3mBRrs6InS LHdUginrl4VmRzMc9KKmz9Scobv0UxdM+QXseRuYxChxbeX7+pmBfh7Ahre1HDJe3e wss9cHqSRXLOA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bfRJMOQgneICknlOaKfjeai6v9M Subject: Re: [clue] Diff mechanism X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Dec 2014 15:18:27 -0000 On 11/27/14 8:24 PM, Christian Groves wrote: > Hello, > > Another issue that seemed to come up in the Hawaii meeting was whether > the diff mechanism should be kept? > > I'm for keeping it in the protocol draft. If people don't want it to be > mandatory then its use could be signalled through the OPTIONS message. If it is to be optional, then there are two levels of optionality: - optional to send - optional to receive ISTM that it would *always* be optional to send. (Certainly there are cases when it should not be used. And there are other cases where it would not be advantageous. The sender is really in the driver's seat on this, and could decide never to use it.) So the key question would be whether it should be optional to receive. If so, then when a receiver indicates it doesn't want to receive it then the sender *couldn't* use it. If it is optional to receive, then it is effectively optional to implement. That would relieve the implementation cost of including it in the spec. But it might also reduce the level of scrutiny it gets as the spec is reviewed, and might end up being published with errors. Thanks, Paul From nobody Tue Dec 2 02:49:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089551A1A7F for ; Tue, 2 Dec 2014 02:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GdjVHpciL9ix for ; Tue, 2 Dec 2014 02:49:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4431A1A7E for ; Tue, 2 Dec 2014 02:49:21 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml403-hub.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BMG84416; Tue, 02 Dec 2014 10:49:20 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 2 Dec 2014 10:49:19 +0000 Received: from SZXEMA511-MBS.china.huawei.com ([169.254.6.253]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Tue, 2 Dec 2014 18:49:15 +0800 From: "Xiaojing (Lennard)" To: "rohanse2@cisco.com" Thread-Topic: [clue] I-D Action: draft-ietf-clue-signaling-04.txt Thread-Index: AQHP8iNvcT4nPulOr0KTQn4dp3k0tpx8JEqg Date: Tue, 2 Dec 2014 10:49:14 +0000 Message-ID: <8A527E21B95EF842BC0E952D6E82297754CD94B1@SZXEMA511-MBS.china.huawei.com> References: <20141027201949.2326.26942.idtracker@ietfa.amsl.com> In-Reply-To: <20141027201949.2326.26942.idtracker@ietfa.amsl.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.133.28] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/clue/yYuP1iw46tJcPvqefbv_gOOeCgM Cc: "clue@ietf.org" Subject: Re: [clue] I-D Action: draft-ietf-clue-signaling-04.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Dec 2014 10:49:26 -0000 Hi Rob, I've got a few comments on the signaling draft: 1. Section 4.2, last sentence of paragraph 2, "and the "mid" of the "m" lin= e of a data channel "mid" MUST NOT be included in more than one CLUE group"= , the "mid" before MUST NOT seems like a replication. 2. Section 4.3, second paragraph, "If negotiation of the data channel in SD= P failed due to lack of CLUE support by the remote device or for any other = reason the other "m" lines in the group are still considered CLUE-controlle= d and under all the restrictions of CLUE-controlled media specified in this= document."=20 I think some clarification is needed here.IMHO, if CLUE is not supported by= A, there isn't any media from A that is CLUE-controlled. I also have confusion when I read the last paragraph of section 4.3. I don'= t quite understand a media is CLUE-controlled from the sender and at the sa= me time not CLUE-controlled from the reciever. 3. Section 4.5.2.1 talks about "negotiation use of CLUE and CLUE data chann= el". But the last sentence of this section suggest "A CLUE-capable recipien= t that receives an "m" line for a data channel but no corresponding CLUE gr= oup containing the "mid" of that "m" line SHOULD include a corresponding da= ta channel "m" line if there are any other non-CLUE protocols it can convey= over that channel, otherwise it SHOULD NOT negotiate the data channel."=20 IMHO, to focus on CLUE, it would be more specific to say that the data chan= nel cannot be used for CLUE, but can be used for other protocols. 4. Section 4.5.4.2, "one or both sides of the call add the CLUE data channe= l "m" line to their SDP and places the "mid" for that channel in correspond= ing CLUE groups then the call is now CLUE-enabled". My confusion here is, h= ow can a call be CLUE-enabled if only one side is CLUE-enabled and he did w= hat is described in the above while the other is not or didn't do. And from= my understanding, a call is CLUE-enabled after successfull negotiation for= the CLUE data channel, not after indication of CLUE support. 5. Section 4.5.4.3, "If the SCTP channel is still present but not included = in the CLUE group semantic the CLUE protocol MUST be closed." By SCTP chann= el, do you mean data channel? And "CLUE protocol be closed" looks a little = bit odd. CLUE message transport be stopped? CLUE protocol disabled? 6. Section 7.2.2, the first sentence, just a little strange to read "may be= mandated". 7. Page 20 last paragraph, a minor editorial: "maximum three encodings" mea= ns a maximum of three encodings or three encodings of maximum capability or= else?=20 Best regards, Lennard > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Tuesday, October 28, 2014 4:20 AM > To: i-d-announce@ietf.org > Cc: clue@ietf.org > Subject: [clue] I-D Action: draft-ietf-clue-signaling-04.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the ControLling mUltiple streams for > tElepresence Working Group of the IETF. >=20 > Title : CLUE Signaling > Authors : Paul Kyzivat > Lennard Xiao > Christian Groves > Robert Hansen > Filename : draft-ietf-clue-signaling-04.txt > Pages : 34 > Date : 2014-10-27 >=20 > Abstract: > This document specifies how CLUE-specific signaling such as the CLUE > protocol [I-D.ietf-clue-protocol] and the CLUE data channel > [I-D.ietf-clue-datachannel] are used with each other and with > existing signaling mechanisms such as SIP and SDP to produce a > telepresence call. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-clue-signaling-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-signaling-04 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Dec 3 02:27:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8B491A0461 for ; Wed, 3 Dec 2014 02:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zhHUEb5JfNCJ for ; Wed, 3 Dec 2014 02:27:21 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1C61A1A06 for ; Wed, 3 Dec 2014 02:27:20 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id 94E98FFCAB291 for ; Wed, 3 Dec 2014 10:27:14 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB3ARIk5022534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Wed, 3 Dec 2014 11:27:18 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 11:27:18 +0100 From: "Schwarz, Albrecht (Albrecht)" To: "clue@ietf.org" Thread-Topic: to SCTPoDTLS association; Re: [clue] Draft new version: draft-ietf-clue-datachannel-05 Thread-Index: AdAO47UruI34eeyuTvKeLSeM/I44jg== Date: Wed, 3 Dec 2014 10:27:17 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC36DC53@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/j0U768e0a4M0BJGSNwDIyNsEY0o Subject: [clue] to SCTPoDTLS association; Re: Draft new version: draft-ietf-clue-datachannel-05 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 10:27:23 -0000 Dear All, the concept of a "SCTPoDTLS association" seems to be cause of some confusio= ns in other related threads. The draft itself is refering to ietf-tsvwg-sctp-dtls-encaps: "The document defines how to describe the SCTPoDTLS association [I-D.ietf-t= svwg-sctp-dtls-encaps] ..." However, draft ietf-tsvwg-sctp-dtls-encaps correctly just uses the notion o= f an "SCTP association" (as well as other drafts such as draft-ietf-mmusic-= sctp-sdp-08). Hence, it looks like that this draft is the root of the "SCTP= oDTLS association" concept, right? The issue might be fixed by adding a convention (or definition) to clause 2= , such as The notion of "SCTPoDTLS association" relates to an abstracted connection c= oncept concerning the protocol layering of a SCTP association over a DTLS a= ssociation. The DTLS association is synonym to a DTLS connection (see claus= e 3 in [RFC5764]). Any comments? The rationale behind that clarification is the aspect of controlling the SC= TP association and DTLS connection (or even DTLS session) separately. Both = protocols are of type connection-oriented, i.e., constituted by state machi= nes. I.e., there are separated, decoupled state machines behind the (SCTP)-= association-endpoint and the (DTLS)-connection-endpoint. Albrecht ____ [clue] Draft new version: draft-ietf-clue-datachannel-05 From: Christer Holmberg To: "clue at ietf.org" Date: Thu, 27 Nov 2014 09:07:17 +0000 List-id: CLUE - ControLling mUltiple streams for TElepresence Hi, I've submitted a new version of the CLUE data channel draft. I have now described DCEP and Keith Richard as two separate mechanisms for = establishing a CLUE Data Channel. Both mechanisms are based on usage of SDP Offer/Answer (e.g. how the m- lin= e is created, which endpoints sends the DCEP open message etc), but there a= re notes indicating that other protocols might also be used. =20 Regards,=20 Christer From nobody Wed Dec 3 03:18:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5402A1A0461 for ; Wed, 3 Dec 2014 03:18:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvwE9zvAmCvU for ; Wed, 3 Dec 2014 03:18:00 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1CF91A1A4A for ; Wed, 3 Dec 2014 03:17:46 -0800 (PST) X-AuditID: c1b4fb30-f79d66d00000744c-89-547ef1586286 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 6E.CB.29772.851FE745; Wed, 3 Dec 2014 12:17:44 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 12:17:44 +0100 From: Christer Holmberg To: "Schwarz, Albrecht (Albrecht)" , "clue@ietf.org" Thread-Topic: [clue] to SCTPoDTLS association; Re: Draft new version: draft-ietf-clue-datachannel-05 Thread-Index: AdAO47UruI34eeyuTvKeLSeM/I44jgABlJVA Date: Wed, 3 Dec 2014 11:17:43 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D572E9F@ESESSMB209.ericsson.se> References: <786615F3A85DF44AA2A76164A71FE1AC36DC53@FR711WXCHMBA03.zeu.alcatel-lucent.com> In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC36DC53@FR711WXCHMBA03.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+JvjW7Ex7oQg4uzLSz+tP5itNh/6jKz A5NH67O9rB5LlvxkCmCK4rJJSc3JLEst0rdL4Mq4u7SNvWAud8XjFzNZGhhnc3YxcnJICJhI HH5zixHCFpO4cG89WxcjF4eQwBFGiR0bG5ghnMWMEttP/WPvYuTgYBOwkOj+pw3SICKQLXHo 8CRWEFtYIE2i9cBpFoh4usTdy/MZIWwjiUsdn8FqWARUJHYebQKL8wr4Ssx494QZZKSQQJTE nTXGICanQLTE9XmZIBWMQOd8P7WGCcRmFhCXuPVkPhPEmQISS/acZ4awRSVePv7HCmErSrQ/ bWCEqNeRWLD7ExuErS2xbOFrZoitghInZz5hmcAoOgvJ2FlIWmYhaZmFpGUBI8sqRtHi1OKk 3HQjI73Uoszk4uL8PL281JJNjMAYObjlt8EOxpfPHQ8xCnAwKvHwbqipCxFiTSwrrsw9xCjN waIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYyR+/OEts45nTDFV895J5tRzb8i +ZiPK1WdbvC51/B8KxWK4XB96lag8s/u4a0L6wIz/t/eLMQf/PVMiUNdSUCVxyELvUP/rYQf e0w08ue8J3L2h+NN7ltXTO8KHZVKeadxpD2t9mOAvMwJt7oXm9Wf/Nh0LdJ80t7V19KLZ6b+ 3xz4xLtVrkuJpTgj0VCLuag4EQAX31vFcgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/B9UfU106NlnjSWvLDvVIYAJZGi0 Subject: Re: [clue] to SCTPoDTLS association; Re: Draft new version: draft-ietf-clue-datachannel-05 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 11:18:10 -0000 Hi Albrecht, > the concept of a "SCTPoDTLS association" seems to be cause of some confus= ions in other related threads. > The draft itself is refering to ietf-tsvwg-sctp-dtls-encaps: > "The document defines how to describe the SCTPoDTLS association [I-D.ietf= -tsvwg-sctp-dtls-encaps] ..." > > However, draft ietf-tsvwg-sctp-dtls-encaps correctly just uses the notion= of an "SCTP association" (as well as other drafts such as draft-ietf-mmusi= c-sctp-sdp-08). Hence, it looks like that this draft is the root of the "SC= TPoDTLS association" concept, right? > > The issue might be fixed by adding a convention (or definition) to clause= 2, such as > > The notion of "SCTPoDTLS association" relates to an abstracted connection= concept concerning the protocol layering of a SCTP association over a DTLS= association. The DTLS association is synonym to a DTLS connection (see cla= use 3 in [RFC5764]). > > Any comments? > The rationale behind that clarification is the aspect of controlling the = SCTP association and DTLS connection (or even DTLS session) separately. Bot= h protocols are of type=20 > connection-oriented, i.e., constituted by state machines. I.e., there are= separated, decoupled state machines behind the (SCTP)-association-endpoint= and the (DTLS)-connection-endpoint. I agree that we should either add a convention, or use different terminolog= y. Regards, Christer From nobody Wed Dec 3 05:10:20 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1910C1A1AF5 for ; Wed, 3 Dec 2014 05:09:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryzKCnLrG5XZ for ; Wed, 3 Dec 2014 05:09:35 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F2C61A0174 for ; Wed, 3 Dec 2014 05:09:34 -0800 (PST) X-AuditID: c1b4fb25-f791c6d00000617b-f5-547f0b8d8771 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id A8.81.24955.D8B0F745; Wed, 3 Dec 2014 14:09:33 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.189]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 14:09:33 +0100 From: Christer Holmberg To: Christer Holmberg , "Schwarz, Albrecht (Albrecht)" , "clue@ietf.org" Thread-Topic: [clue] to SCTPoDTLS association; Re: Draft new version: draft-ietf-clue-datachannel-05 Thread-Index: AdAO47UruI34eeyuTvKeLSeM/I44jgABlJVAAAQIvQA= Date: Wed, 3 Dec 2014 13:09:31 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D5733E9@ESESSMB209.ericsson.se> References: <786615F3A85DF44AA2A76164A71FE1AC36DC53@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D572E9F@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D572E9F@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrMLMWRmVeSWpSXmKPExsUyM+JvjW4vd32Iwe1p8hZ/Wn8xWuw/dZnZ gcmj9dleVo8lS34yBTBFcdmkpOZklqUW6dslcGW8mfeWseCyYMXah2uZGxgv8HUxcnJICJhI fP+wih3CFpO4cG89WxcjF4eQwBFGieNrOtkhnMWMEt/v/mbpYuTgYBOwkOj+pw0SFxFYyChx rvU1I0i3sECaROuB0ywgtohAusTdy/MZIWwriQPvZrCC2CwCKhLnFp4Hq+EV8JV49GgO1LZ5 jBL9126AncEp4CcxZcMysAZGoJO+n1rDBGIzC4hL3HoynwniVAGJJXvOM0PYohIvH/9jhbAV JdqfNjBC1OtILNj9iQ3C1pZYtvA1M8RiQYmTM5+wTGAUnYVk7CwkLbOQtMxC0rKAkWUVo2hx anFSbrqRsV5qUWZycXF+nl5easkmRmCsHNzyW3UH4+U3jocYBTgYlXh4N9TUhQixJpYVV+Ye YpTmYFES5114bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBsbJmyquRnGZ5p/j+1etO//C aYe+39NfeIScVZn1lX3tiQ0zDRyy3kr22zvs9O+QCVUJ4TlYz164jXfe+hTtuhctSt7R/rvm RGS/nlX2WO7jn7zyhVWzXt6I/yjcIH/pv96qdN5VZ7osfuperLXutN340tHxhJF7eeN378uL GKXFbpqH37Pnv67EUpyRaKjFXFScCACyW5FKdgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/2lBUZ-68rmOvBhSZN1S0wuU8juQ Subject: Re: [clue] to SCTPoDTLS association; Re: Draft new version: draft-ietf-clue-datachannel-05 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 13:09:59 -0000 Hi Albrecht,=20 What about adding the following to the Conventions section: "SCTPoDTLS association refers to an SCTP association carried over an DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps"]." Then we can use "SCTPoDTLS association" throughout the document, rather tha= n having to say "SCTP association carried over a DTLS connection" everywher= e... Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 3. joulukuuta 2014 13:18 To: Schwarz, Albrecht (Albrecht); clue@ietf.org Subject: Re: [clue] to SCTPoDTLS association; Re: Draft new version: draft-= ietf-clue-datachannel-05 Hi Albrecht, > the concept of a "SCTPoDTLS association" seems to be cause of some confus= ions in other related threads. > The draft itself is refering to ietf-tsvwg-sctp-dtls-encaps: > "The document defines how to describe the SCTPoDTLS association [I-D.ietf= -tsvwg-sctp-dtls-encaps] ..." > > However, draft ietf-tsvwg-sctp-dtls-encaps correctly just uses the notion= of an "SCTP association" (as well as other drafts such as draft-ietf-mmusi= c-sctp-sdp-08). Hence, it looks like that this draft is the root of the "SC= TPoDTLS association" concept, right? > > The issue might be fixed by adding a convention (or definition) to=20 > clause 2, such as > > The notion of "SCTPoDTLS association" relates to an abstracted connection= concept concerning the protocol layering of a SCTP association over a DTLS= association. The DTLS association is synonym to a DTLS connection (see cla= use 3 in [RFC5764]). > > Any comments? > The rationale behind that clarification is the aspect of controlling=20 > the SCTP association and DTLS connection (or even DTLS session) separatel= y. Both protocols are of type connection-oriented, i.e., constituted by sta= te machines. I.e., there are separated, decoupled state machines behind the= (SCTP)-association-endpoint and the (DTLS)-connection-endpoint. I agree that we should either add a convention, or use different terminolog= y. Regards, Christer _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Wed Dec 3 06:54:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E012A1A011D for ; Wed, 3 Dec 2014 06:54:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkHnjtweVBQF for ; Wed, 3 Dec 2014 06:54:53 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA421A1B5C for ; Wed, 3 Dec 2014 06:54:33 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-09v.sys.comcast.net with comcast id P2u11p0052Udklx012uYVW; Wed, 03 Dec 2014 14:54:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id P2uY1p00W3Ge9ey012uYKb; Wed, 03 Dec 2014 14:54:32 +0000 Message-ID: <547F2427.1090304@alum.mit.edu> Date: Wed, 03 Dec 2014 09:54:31 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1417618472; bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=FQffDPdJ8cq8PSPFa3M4VeluwPNpKT6IWfMibcEQ1vOLRSw5zTb/RD6sEzDFeggYc D5sHquDCXl0qp3mRux8v+1kxaEz6q0YTPwXHlIr7NpoVaN/XwJ8KJx+FWUqdnwcI0V LuG6l6pY3MWkF4xoF0bOJNFnQ3MtD/eMZqy75cEflDhVT9dtfXksrYQVRrOuPHzWBS frIZf2nLFGi3CDYAWEv8j2UtUS8vY917nMsOycSphfWqH6qpkjK2OWaYIJM2fF2oG2 eNWOEEbxt/sEZeHyjNo1BWkbHJSB4anmIzjBoYCQTqLDVFxcktshoz3GB4aas6OL/J nnnYKeTWBGOyg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YwT2AX58Fdmh1ZRRSmo1iu5pT5s Subject: [clue] reminder: two weeks left for WGLC of framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Dec 2014 14:54:54 -0000 From nobody Fri Dec 5 07:54:57 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F33551ACECE for ; Fri, 5 Dec 2014 07:54:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.91 X-Spam-Level: X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OYxkAD_yjdSl for ; Fri, 5 Dec 2014 07:54:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 238101ACEC3 for ; Fri, 5 Dec 2014 07:54:52 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id B44EE9F49E652; Fri, 5 Dec 2014 15:54:47 +0000 (GMT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id sB5FsoSF006269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 16:54:50 +0100 Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.75]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 16:54:49 +0100 From: "Schwarz, Albrecht (Albrecht)" To: Christer Holmberg , "clue@ietf.org" Thread-Topic: [clue] to SCTPoDTLS association; Re: Draft new version: draft-ietf-clue-datachannel-05 Thread-Index: AQHQDurF+aQwKmZljU2CTE5oigCrBJx9xieAgANi5zA= Date: Fri, 5 Dec 2014 15:54:49 +0000 Message-ID: <786615F3A85DF44AA2A76164A71FE1AC36FA12@FR711WXCHMBA03.zeu.alcatel-lucent.com> References: <786615F3A85DF44AA2A76164A71FE1AC36DC53@FR711WXCHMBA03.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D572E9F@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1D5733E9@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D5733E9@ESESSMB209.ericsson.se> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/MIki_0pQNf6FKF9-G6GTNoXLEY0 Subject: Re: [clue] to SCTPoDTLS association; Re: Draft new version: draft-ietf-clue-datachannel-05 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Dec 2014 15:54:55 -0000 Right, would be OK for me. -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Mittwoch, 3. Dezember 2014 14:10 To: Christer Holmberg; Schwarz, Albrecht (Albrecht); clue@ietf.org Subject: RE: [clue] to SCTPoDTLS association; Re: Draft new version: draft-= ietf-clue-datachannel-05 Hi Albrecht,=20 What about adding the following to the Conventions section: "SCTPoDTLS association refers to an SCTP association carried over an DTLS connection [I-D.ietf-tsvwg-sctp-dtls-encaps"]." Then we can use "SCTPoDTLS association" throughout the document, rather tha= n having to say "SCTP association carried over a DTLS connection" everywher= e... Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 3. joulukuuta 2014 13:18 To: Schwarz, Albrecht (Albrecht); clue@ietf.org Subject: Re: [clue] to SCTPoDTLS association; Re: Draft new version: draft-= ietf-clue-datachannel-05 Hi Albrecht, > the concept of a "SCTPoDTLS association" seems to be cause of some confus= ions in other related threads. > The draft itself is refering to ietf-tsvwg-sctp-dtls-encaps: > "The document defines how to describe the SCTPoDTLS association [I-D.ietf= -tsvwg-sctp-dtls-encaps] ..." > > However, draft ietf-tsvwg-sctp-dtls-encaps correctly just uses the notion= of an "SCTP association" (as well as other drafts such as draft-ietf-mmusi= c-sctp-sdp-08). Hence, it looks like that this draft is the root of the "SC= TPoDTLS association" concept, right? > > The issue might be fixed by adding a convention (or definition) to=20 > clause 2, such as > > The notion of "SCTPoDTLS association" relates to an abstracted connection= concept concerning the protocol layering of a SCTP association over a DTLS= association. The DTLS association is synonym to a DTLS connection (see cla= use 3 in [RFC5764]). > > Any comments? > The rationale behind that clarification is the aspect of controlling=20 > the SCTP association and DTLS connection (or even DTLS session) separatel= y. Both protocols are of type connection-oriented, i.e., constituted by sta= te machines. I.e., there are separated, decoupled state machines behind the= (SCTP)-association-endpoint and the (DTLS)-connection-endpoint. I agree that we should either add a convention, or use different terminolog= y. Regards, Christer _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Thu Dec 11 10:26:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC31A87C8; Thu, 11 Dec 2014 10:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mp5BZrSoPIdY; Thu, 11 Dec 2014 10:26:20 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6134E1A87B1; Thu, 11 Dec 2014 10:26:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.7.4 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20141211182620.21412.64099.idtracker@ietfa.amsl.com> Date: Thu, 11 Dec 2014 10:26:20 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/BBMMI9wl5_V3cIQQCklhOiF-T-A Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-framework-19.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:26:22 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Framework for Telepresence Multi-Streams Authors : Mark Duckworth Andrew Pepperell Stephan Wenger Filename : draft-ietf-clue-framework-19.txt Pages : 79 Date : 2014-12-11 Abstract: This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling for setting up a telepresence session. 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-19 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-framework-19 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Dec 11 10:30:31 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5731A8769 for ; Thu, 11 Dec 2014 10:30:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HvAbqShGvI9e for ; Thu, 11 Dec 2014 10:30:17 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:123a::1:2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7167E1A1A64 for ; Thu, 11 Dec 2014 10:30:17 -0800 (PST) Received: from localhost ([::1]:60278 helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1Xz8VC-0000qW-5I; Thu, 11 Dec 2014 10:30:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "clue issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com X-Trac-Project: clue Date: Thu, 11 Dec 2014 18:30:14 -0000 X-URL: http://tools.ietf.org/wg/clue/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/clue/trac/ticket/64#comment:1 Message-ID: <083.85e7221102ccf92fbb13fc75e44ccfcf@trac.tools.ietf.org> References: <068.900b073e446e3451e11d30245ca663b6@trac.tools.ietf.org> X-Trac-Ticket-ID: 64 In-Reply-To: <068.900b073e446e3451e11d30245ca663b6@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-clue-framework@tools.ietf.org, mark.duckworth@polycom.com, clue@ietf.org X-SA-Exim-Mail-From: trac+clue@trac.tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Resent-To: apeppere@gmail.com, mark.duckworth@polycom.com, stewe@stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/clue/b-WyTRVvnlF-SaGKToOjeAUhAto Cc: clue@ietf.org Subject: Re: [clue] #64 (framework): Framework should refer to mechanism for determining capture ID from incoming RTP X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:30:22 -0000 #64: Framework should refer to mechanism for determining capture ID from incoming RTP Changes (by mark.duckworth@polycom.com): * status: new => closed * resolution: => fixed Comment: Fixed in framework-19. Refer to RTP mapping draft. -- -------------------------------------+------------------------------------- Reporter: | Owner: draft-ietf-clue- mark.duckworth@polycom.com | framework@tools.ietf.org Type: task | Status: closed Priority: minor | Milestone: Component: framework | Version: Severity: - | Resolution: fixed Keywords: | -------------------------------------+------------------------------------- Ticket URL: clue From nobody Thu Dec 11 10:32:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D2681A87E2 for ; Thu, 11 Dec 2014 10:32:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DlR5LggIFM7R for ; Thu, 11 Dec 2014 10:32:46 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.99]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6791A1A64 for ; Thu, 11 Dec 2014 10:32:46 -0800 (PST) Received: from [216.82.254.19] by server-3.bemta-7.messagelabs.com id A9/59-03006-D43E9845; Thu, 11 Dec 2014 18:32:45 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-96.messagelabs.com!1418322738!15257566!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 13274 invoked from network); 11 Dec 2014 18:32:19 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-6.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 11 Dec 2014 18:32:19 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Thu, 11 Dec 2014 10:32:18 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Thu, 11 Dec 2014 10:32:18 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Thu, 11 Dec 2014 10:32:16 -0800 Thread-Topic: Changes in framework-19 Thread-Index: AdAVcDTn7kBx8XuSTIGw7pkztg38Pw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC017B7@CRPMBOXPRD08.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_5C4AC54BFF7A0842A6A11F554D6FB52F968DC017B7CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/vVc336esfK7K7uHD9iv7oUO4ZlM Subject: [clue] Changes in framework-19 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Dec 2014 18:32:47 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC017B7CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 1. Remove the Max Capture Encodings media capture attribute. 2. Ticket #64 - Refer to RTP mapping document in the MCC example section. 3. Update references to current versions of drafts in progress. Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC017B7CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

<= ![if !supportLists]>1. Remove the Max Capture Enc= odings media capture attribute.

 

2= . Tick= et #64 - Refer to RTP mapping document in the MCC example section.

 <= /p>

3. Update references to current versions of drafts in progress.

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC017B7CRPMBOXPRD08p_-- From nobody Sun Dec 14 07:18:42 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAA5F1A6FC4 for ; Sun, 14 Dec 2014 07:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1syvP-M9V2Nj for ; Sun, 14 Dec 2014 07:18:38 -0800 (PST) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A0AB1A6FBA for ; Sun, 14 Dec 2014 07:18:38 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so6769266wiv.1 for ; Sun, 14 Dec 2014 07:18:36 -0800 (PST) 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 :thread-index:content-language; bh=xGhet2IntK6Eko2OwKVAAfYrOxLAI1IA/jh2fpXMyLY=; b=PVUzzPR1gsUuelfgLL+fMfT9gIG7wvtsVXHXTJ01w5+glqYRQD8z9I+bvJ054fu3Gg F7PXpcKNSesNENpnzlo30ltbLUah0ySgHGNWBN5KrCoAFJDlY/mlvrua34GC61frp8VH ugfwSd5yNvnxMbzXqwx+k9i0PnBtJjM+j3bFmJ5bMPogRsGJmtlQOYBoeJOW3N59Wxwx 0zYJTwPyqCP3BIyGWipKN0vDjhFjNNAZbcexLyAjdTc1+wzM69g1mlEwXFrU3TraDH4l 9HP4hLcqH/YgkIODmfu19IT0k+hd2zxQ1yc1rXNNKyTYnmrRQZiP42T8QH82GOzFjf5c yJ5A== X-Received: by 10.194.52.37 with SMTP id q5mr43614307wjo.39.1418570316654; Sun, 14 Dec 2014 07:18:36 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id t6sm9459940wjf.49.2014.12.14.07.18.35 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Dec 2014 07:18:35 -0800 (PST) From: "Roni Even" To: Date: Sun, 14 Dec 2014 17:18:29 +0200 Message-ID: <008a01d017b1$38777ef0$a9667cd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_008B_01D017C1.FC011240" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAXsJ0t8srZW4TZRPOZGk8B87mBfg== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LN6BAt8XRgQVV6garbkf1Oq-MPo Subject: [clue] Design team meeting this week - Framework X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 15:18:40 -0000 This is a multipart message in MIME format. ------=_NextPart_000_008B_01D017C1.FC011240 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, We would like to resume the weekly design team meetings. The Framework WGLC will end on the 17th but since this will be before the Holidays it will be good to hold a conference call the Tuesday December 16th at the usual time see http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Since we did not meet for some time please let us know If there are any time issues Regards Roni Even CLUE WG Co-chair ------=_NextPart_000_008B_01D017C1.FC011240 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

We would like = to resume the weekly design team meetings.

 

The = Framework WGLC will end on the 17th but since this will be = before the Holidays  it will be good to hold a conference call the = Tuesday December 16th at the usual time see http://= trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team

 

Since we did = not meet for some time please let us know If there are any time = issues

 

Regards

Roni = Even

CLUE WG = Co-chair

------=_NextPart_000_008B_01D017C1.FC011240-- From nobody Sun Dec 14 07:21:01 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A32A81A6FC6 for ; Sun, 14 Dec 2014 07:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElVFYs8PKqy3 for ; Sun, 14 Dec 2014 07:20:58 -0800 (PST) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFA961A6FC4 for ; Sun, 14 Dec 2014 07:20:57 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id x13so12841319wgg.33 for ; Sun, 14 Dec 2014 07:20:56 -0800 (PST) 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 :thread-index:content-language; bh=vF4vKdyh359YPneehAA7jVadJ0Je/Kjtea7UCX71gHA=; b=rK8iuB0rvaRhGVCi2bN9HOr0dFNzDoH0do/z6fqyseAsk8u1/OeCF6jXrJ3QS9saIb mahk71iIorOC6xzSa1Q5OMhTKH4uZ7QQecwfSMHmItbnmgCXhlUDVGffO9XegaTFGTGO fYCo9iZdxQ2j9ZAb0ZgPapEYPf5KB0nSvBrdRqwRPoMzX7upw4kkum3kdWYq2JqQt/pn njz+RIj7u//7RSkXtVW/H2co2GVu+0lERdp/gSrRQJZkx8846LeiIVO+7zla3mRTgYSf GZy028yNojVq41TajKcAGN/DVvJEqf/2WwNHZxdUpjnF0W3Da0u2R8h0VBg5kuryjKAG yxfQ== X-Received: by 10.180.160.144 with SMTP id xk16mr24721493wib.12.1418570456668; Sun, 14 Dec 2014 07:20:56 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id ec2sm9706356wib.23.2014.12.14.07.20.54 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Dec 2014 07:20:55 -0800 (PST) From: "Roni Even" To: Date: Sun, 14 Dec 2014 17:20:48 +0200 Message-ID: <008f01d017b1$8bb2de70$a3189b50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0090_01D017C2.4F3BAE70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAXsUTCJkj7I/rcRjysKEFl8ALGjQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/1JMmiXi-Mz2xyYa8BlA3FZ8Orok Subject: [clue] Framework WGLC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 15:20:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0090_01D017C2.4F3BAE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The WGLC is almost ending and there are no comments on the list. Please review and respond even if it is just to say that you have read the document and have no comments. Thanks Roni Even CLUE co-chair ------=_NextPart_000_0090_01D017C2.4F3BAE70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The WGLC is = almost ending and there are no comments on the list.

Please review and respond even if it is just to say = that you have read the document and have no comments.

 

Thanks

Roni = Even

CLUE = co-chair

------=_NextPart_000_0090_01D017C2.4F3BAE70-- From nobody Sun Dec 14 08:21:00 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 330911A6F13 for ; Sun, 14 Dec 2014 08:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8d0B-byM0FnB for ; Sun, 14 Dec 2014 08:20:55 -0800 (PST) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 929951A00F1 for ; Sun, 14 Dec 2014 08:20:55 -0800 (PST) Received: by mail-wg0-f48.google.com with SMTP id y19so12796757wgg.35 for ; Sun, 14 Dec 2014 08:20:54 -0800 (PST) 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 :content-transfer-encoding:thread-index:content-language; bh=59Xp+kBG3yQfdKxAaDaZcnW4jLh4goe/qx4ULlQGX+M=; b=BvCLMTNIfB1xD+wZNUV3QqSYFvI7naguowLVjCEDoEXhVxG9zdt5gHEOl1F9hap4p1 FHaFVGXOEZehhW+4xBuKv9zljDrKaGxnUkwy32athW5pWVmf9MdGZmVt9ZkvM+tV53Es xL9/AtNm+TS9ny6AFdH/v50X0eaQlfLsZXBUCJXxSrNXR0abvy2DTMamusBLRSNvGk7s U74JOiOsjeJdmur6STZiBz8IKnItYN8gJb+2HfS/qWsz7jgKpmH9XRt4mq6uoFxhryhD pX9/5nmzUupLjMVDXyPteJbOezNtFY0U/Je9H2Oj+ppqqCwYCqC/cxixxKZoL1zUHel1 hq0A== X-Received: by 10.194.95.196 with SMTP id dm4mr45466403wjb.41.1418574054371; Sun, 14 Dec 2014 08:20:54 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id je12sm9882665wic.22.2014.12.14.08.20.52 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 14 Dec 2014 08:20:53 -0800 (PST) From: "Roni Even" To: "'CLUE'" Date: Sun, 14 Dec 2014 18:20:46 +0200 Message-ID: <009401d017b9$ec33f100$c49bd300$@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: AdAXtbr9mHCXJk2MR+iY36HeJpeBiA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HeftY1r93VrubOTSEEDxCD7zv54 Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Dec 2014 16:20:58 -0000 Hi, I read the document (also the 19 version) and have no technical issues. Some editorial comments 1. I think it may be good to add a reference in section 3 to the taxonomy draft mostly since section 4.1 of the taxonomy also discuss the terminology of CLUE. 2. In section 3 "Global View" the term scene is mentioned, I assume it should be capture scene or maybe add to capture scene that when scene is mentioned it refers to capture scene 3. In section 4 bullet (5) "RTP media flows" and "RTP flows" probably "RTP streams" according to taxonomy. Also in section 9 "The maximum number of streams that can result .." "RTP streams"? 4. In section 4 "While the actual mapping of those RTP flows to the header fields of the RTP packets is not subject of this specification, the large number of possible permutations of sensible options a Media Provider can make available to a Media Consumer makes a mechanism desirable that allows to narrow down the number of possible options that a SIP offer-answer exchange has to consider." This all text is not clear to me , why header fields .... 5. SDP is mentioned in section 3 and in other sections without reference that appears only in section 9.1 6. Section 5 discuss the model and from the following text "First, it MUST construct and send a CLUE Configure message to tell the Provider what the Consumer wishes to receive. Second, it MAY, but is not necessarily REQUIRED to, use the information provided to tailor the SDP it is going to send during the following SIP offer/answer exchange, and its reaction to SDP it receives in that step." It may seem that the offer/answer is initiated by the Consumer after the Advertisement, yet later in the document it says that the consumer needs the offer in order to have the individual encodes before sending the Configure. In this section the issue of who will send the first offer is not mentioned. 7. In section 5 " A CLUE-implementing device interoperates with a device that does not support CLUE, because the non-CLUE device does, by definition , not understand the offer of a CLUE channel in the initial offer/answer exchange and, therefore, will reject it. This rejection MUST be used as the indication to the CLUE-implementing device that the other side of the communication is not compliant with CLUE, and to fall back to behavior that does not require CLUE ." What about the feature tag, I thought that this is how you know if CLUE is supported. 8. In section 7.3.3 you repeat the definition of "global View" from section 3. 9. At the end of section 1 maybe need to reference also the protocol document. 10. A nit in section 10 "Therefore it can choose to receive a sub-set ofCaptures indicated by the MCC." "of Captures" Thanks Roni Even As individual > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 25 November, 2014 9:22 PM > To: CLUE > Subject: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec > 17. > > During IETF91 we agreed to start the WGLC of the Framework immediately > after the meeting. So I am calling the start of that WGLC today. At least here in > the US people are pretty distracted around the holidays (starting this week), so > we will allow extra calendar time to complete this. The end of this WGLC will > be end of the day (wherever you are) on Wednesday December 17. That gives > three weeks plus roundoff for today. > > If all is in order this will be the last review of this document by the WG before it > goes to the ADs and the IESG. So we need careful, thorough reviews of the full > document, not just diffs from a prior version. > > To ensure that you are all paying attention, please respond to this message > with your indication that you indeed plan to submit a review. > > (To get the ball rolling, *I* plan to do a WGLC reviewe of this draft.) > > Thanks, > Paul (for all the chairs) > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Dec 15 02:59:27 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103501A1AFE for ; Mon, 15 Dec 2014 02:59:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.211 X-Spam-Level: X-Spam-Status: No, score=-11.211 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21fGvwwuHBdX for ; Mon, 15 Dec 2014 02:59:24 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AAEE1A1AEC for ; Mon, 15 Dec 2014 02:59:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17523; q=dns/txt; s=iport; t=1418641163; x=1419850763; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=c0o4W2Th6x28DEBoLzBXKXweCdN9MFOCs6U/czoB898=; b=Bz0KNfMGCfBdy1po6GW4doqhqDUPGhYQNAplDv5rvg8GvAAjAMS8KS/i wfgGWbr0C3xCmMpItL2OQ6dTafVZg4yOd6qEYWK6kKH1zdTUuDFADT2rj CB298CXjnE7ReLn5P/elQC6UHoatnzZ3aj5MDcqE7I14A+iUoL7qgUDN+ U=; X-Files: framework_wglc_robh_review.txt : 14155 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8JAN29jlStJssW/2dsb2JhbABRCYc2sBABAQEBAQEFAXeXOQKBLwEBAQEBfYQNAQEEI0QREQshFgsCAgkDAgECAUUTCAEBiCi8IpYLAQEIAQEBAR6GAIkXYoJogUEBBIwsgyCBJ4V+hXmDf4c/IoNsPoEzBYE7AQEB X-IronPort-AV: E=Sophos;i="5.07,579,1413244800"; d="txt'?scan'208";a="275439699" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 15 Dec 2014 10:59:21 +0000 Received: from [10.47.200.30] ([10.47.200.30]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id sBFAxK0W010344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 15 Dec 2014 10:59:20 GMT Message-ID: <548EBF08.8090900@cisco.com> Date: Mon, 15 Dec 2014 10:59:20 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <008f01d017b1$8bb2de70$a3189b50$@gmail.com> In-Reply-To: <008f01d017b1$8bb2de70$a3189b50$@gmail.com> Content-Type: multipart/mixed; boundary="------------090101040400070104050100" X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/VNTEh2oCk36tm6EznPBO3w5NLTA Subject: Re: [clue] Framework WGLC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 10:59:27 -0000 This is a multi-part message in MIME format. --------------090101040400070104050100 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Find my review attached. Most of the time the document capitalises terms from the terminology, but not always; at first I flagged these up whenever I noticed them but I'm sure I missed some and by the end I realised that going through with grep and 'find next' was going to be much quicker than correcting based on my review anyway so I stopped. Almost all of the issues are just nits with the language or requests for clarifications; I'll repeat the two that I thought were contentious: Section 7.2. page 22: "A MCC MAY contain no references to other Captures to indicate that the MCC contains content from multiple sources but no information regarding those sources is given." - We don't specify if an MCC containing 1 or more defined captures may also contain undefined captures. My personal choice would be no - advertised MCCs either contain the defined captures and no others, or have no defined captures and contain only undefined ones. If there are good reasons that any MCC with defined captures also needs to contain potentially undefined ones that's fine too but we should spell it out. Section 10. page 39: "The Consumer may or may not choose to receive all the indicated captures. Therefore it can choose to receive a sub-set ofCaptures indicated by the MCC." - this allowance means that any device that provides an MCC and defines the captures it contains is required to allow any subset of those captures to be chosen bv the consumer. Often the reason the provider is providing an MCC initially is because it cannot supply all the captures directly; unless it has the resources to provide a unique subset of each capture (eg, switched view or custom composition) it will be forced to ot include the contained captures in the MCC, removing the value of having an MCC in the first place. Depending on the clarification to the question on page 22 (whether an MCC with defined captures can also contain undefined captures) the consumer may still be receiving captures it hasn't specified. My preference would be to remove this degree of freedom on the consumer side, or at least make it a suggestion to the provider rather than a mandatory restriction. There should also be a space in "ofCaptures". Rob --------------090101040400070104050100 Content-Type: text/plain; charset=UTF-8; name="framework_wglc_robh_review.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="framework_wglc_robh_review.txt" Abstract: "in addition to SIP signaling" could be "in addition to SIP signaling and= SDP negotiation" Section 3. page 3: "Capture Scene MAY or may not correspond" - either 'MAY' and 'may not' sh= ould both be normative or both should not be (probably the latter) Section 3. page 4: "specifying which content and media streams" - "media" and "stream" are d= efined in this section and so should be capitalised "Encoding or Individual Encoding" - in all other cases with multiple defi= nitions each definition has its own line (Eg, "Encoding - short for Indiv= idual Encoding") "a CLUE-capable device that intends to receive Capture Encodings" - shoul= d end in a full stop "a CLUE-capable device that intends to send Capture Encodings" - should e= nd in a full stop "Endpoint: A CLUE capable-device which is" - in the definitions this is w= ritten as "CLUE-capable device" "within scenes of the same advertisement" - should be "within Capture Sce= nes of the same Advertisement" Section 3. page 5: "a CLUE-capable device that intends to receive Capture Encodings" - shoul= d end in a full stop "a CLUE-capable device that intends to send Capture Encodings" - should e= nd in a full stop "Single Media Capture: A capture which contains" - as a defined term "cap= ture" should be capitalised Section 4. page 7: "description, and discussed in section" - should probably have "are" afte= r "and" Section 4. page 8: "that allows to narrow down the" - should probably have "it" after "allow= s" Section 5. page 9: "A Media Capture (MC), such as audio or video" - "such as of type audio o= r video"? Section 5. page 12: "This CLUE exchange MUST be followed by an SDP offer answer exchange" - w= hile this will normally be the case, should it be made mandatory in the f= ramework? Also, "offer answer" is generally "offer/answer" elsewhere in t= he document Section 5. page 13: "For example, voice-activated screen switching, signaled over the CLUE ch= annel, ought not to" - was a bit confused by this; does this mean an MCC = noted as voice-switched, or actually somehow signalling which participant= is currentl the active speaker via CLUE (and if the latter, how do we do= that)? My guess is that this relates to behaviour that is now available = at the RTP level instead. "compared to what was previously negotiated using offer/answer, a new O/A= exchange is REQUIRED." - while true, using normative language here seems= strange "as the indication to the CLUE-implementing device" - Since the terminolo= gy section includes "CLUE-capable" devices, which are defined as capable = and using, seems like this could be used here rather than "CLUE-implement= ing" Section 6. page 14: "Simple systems which do not have multiple Media Captures to associate sp= atially need not use the coordinate model." - there are circumstances whe= re the Media Consumer may still find the spatial information from a singl= e video capture useful, such as scaling the received image to ensure the = subject is no larger than a real individual (that was a use-case that was= previously discussed, at any rate), so we may not want to discourage peo= ple from including spatial information in this case. "alongside one another (e.g. in the case of an MCU)." - elsewhere in the = text full stops are usually placed inside parentheses Section 7.1. page 15: "or 'synthetic' source (e.g. laptop computer, DVD player)." - other bulle= t-pointed items, here and elsewhere, don't have a terminating full stop "is given an advertisement unique identity." - "advertisement" is defined= in the terminology section and so should be capitalised "A Media Capture may be associated with one or more Capture Scene Views" = - should also be clear that a Media Capture may also not be associated wi= th any CSV (eg, if it's just used to say what's inside an MCC) Section 7.1.1 page 16: Some attributes in this section explicitely say that they are optional, o= thers do not but are still optional Section 7.1.1.9. page 19: "The language attribute" - other attributes are capitalised Section 7.1.1.10. page 19: "The person information attribute" - other attributes are capitalised Section 7.1.1.11. page 20: "The person type attribute" - other attributes are capitalised "values shall not be repeated within the attribute" - should "shall not" = be normative? "The types of Captured people include:" - inconsistent full stops in the = bullet-pointed list Section 7.1.1.12. page 21: "help decide which captures it wishes to receive." - "capture" is defined= in the terminology and should be capitalised "that would allow a remote endpoint to determine" - "endpoint" is defined= in the terminology and should be capitalised "at the individual capture level" - "capture" is defined in the terminolo= gy and should be capitalised Section 7.2. page 22: "A MCC MAY contain no references to other Captures to indicate that the M= CC contains content from multiple sources but no information regarding th= ose sources is given." - We don't specify if an MCC containing 1 or more = defined captures may also contain undefined captures. My personal belief = would be no - advertised MCCs either contain the defined captures and no = others, or have no defined captures. Section 7.2.1. page 22: "that may be present in the individual captures." - "capture" is defined = in the terminology and should be capitalised Section 7.2.1.1. page 24: "number of captures in the MCC affects how sources appear in a capture en= coding" - "capture" and "capture encoding" are defined in the terminology= and should be capitalised Section 7.2.1.1. page 25: "the Advertiser in the capture encoding would switch between VC1, VC2 or= VC3" - "capture encoding" is defined in the terminology and should be ca= pitalised. There is also a double space between "switch" and "between". Section 7.2.1.2. page 25: "The attribute is in the form of a token that indicates the policy and in= dex representing" - "an" before "index"? "policy setting. A index of 0 represents the most current instance - shou= ld be "An" not "A" In this section it may be worth clarifying that priority indices may be e= qual. Section 7.2.1.3. page 26, table 4: While it's only a textual description, "room" is uncapitalised while all = other descriptions are capitalised There are two "Capture Scene #3"s in this table; the latter should presum= ably be "Capture Scene #5" Section 7.2.1.3. page 27: "There would be four capture encodings (one for each MCC)." - "capture en= coding" is defined in the terminology and should be capitalised.=20 multiple instances of "encoding" - "encoding" is defined in the terminolo= gy and should be capitalised. Section 7.3. page 30: "(VC3) - Video Capture associated with loudest room segment" - would it m= ake sense for this and VC4 in the example to now be MCCs? Section 7.3.3. page 31: "7.3.3. Global View List" - this is a seperate element of the Advertiseme= nt - would it make sense for it to be a seperate subsection (7.4. rather = than 7.3.3.) Section 7.3.3. page 33: "Figure 3: Global View List Structure" - contains many instances of "cs= v", eslewhere capitalised as "CSV" Section 8. page 33: "such as bandwidth or video encoding throughput (macroblocks/second). Th= is type of constraint is captured by encoding groups, discussed below." -= encoding groups only capture bandwidth constraints directly, mb/s is cap= tured by encodings. Section 8. page 34: "A Provider OPTIONALLY can include the simultaneous sets in its Advertise= ment." - "simultaneous sets" is else used in its official term, "Simultan= eous Transmission Sets" "These simultaneous set constraints apply across all the Capture Scenes i= n the Advertisement." - "simultaneous sets" is else used in its official = term, "Simultaneous Transmission Sets" Section 8. page 35: "Similarly, the simultaneous transmission sets MUST reflect" - "simultane= ous transmission sets" should be capitalised as elsewhere "simultaneously provide all the captures from any one CSV of each media t= ype from each capture scene" - "capture" and "capture scene" are defined = in the terminology and should be capitalised "If an Advertisement includes multiple Capture Scene Views in a Capture S= cene then the Consumer MAY choose one Capture Scene View for each media t= ype, or MAY choose individual Captures based on the Simultaneous Transmis= sion Sets." - seems to imply the pick and choose behaviour is only possib= le if more than one CSV is included in a scene. We should be clear that r= eceivers are free to choose any captures allowed by the simultenaity cons= traints, but that generally they will want to choose those defined in one= of the CSVs Section 9. page 35: "onto the Encodings, with encoding parameters they want." - should includ= e "the" after "with" Section 9.2. page 36: "the particular individual encoding." - "individual encoding" is defined = in the terminology and should be capitalised "the individual capture encoding bitrates MUST be" - "capture encoding" i= s defined in the terminology and should be capitalised Section 10. page 39: "(i.e. in a n MCU-less multiparty call)" - no space between "a" and "n" "On receipt of an Advertisement with an MCC the Consumer treats the MCC a= s per other non-MCC Captures with the following differences:" - the follo= wing differences only cover the cases where the MCC contains defined capt= ures, not the case where the captures it contains haven't been defined "The Consumer may or may not choose to receive all the indicated captures= =2E Therefore it can choose to receive a sub-set ofCaptures indicated by= the MCC." - this allowance means that any device that provides an MCC an= d defines the captures it contains is required to allow any subset of tho= se captures to be chosen bv the consumer. Often the reason the provider i= s providing an MCC initially is because it cannot supply all the captures= directly; unless it has the resources to provide a unique subset of each= capture (eg, switched view or custom composition) it will be forced to o= t include the contained captures in the MCC, removing the value of having= an MCC in the first place. Depending on the clarification to the questio= n on page 22 (whether an MCC with defined captures can also contain undef= ined captures) the consumer may still be receiving captures it hasn't spe= cified. My preference would be to remove this degree of freedom on the co= nsumer side, or at least make it a suggestion to the provider rather than= a mandatory restriction. There should also be a space in "ofCaptures". Section 10. page 40: Contains various instances of "offer-answer", which elsewhere in the docu= ment is "offer/answer" Section 11. page 42: "Adding new functionalities, such as 3-D, say, may require additional att= ributes describing the Captures." - probably need more detail on what the= "3D" extension would be here, as we already define the capture in 3D spa= ce. Section 12.1.1 page 43: "The audio and video Captures for this Endpoint can be described as follo= ws." - the video captures are described before the audio captures; might = be helpful to reverse that, or reverse "audio and video" here "MCC3- (the loudest panel stream), encoding group=3DEG1, view=3Dtable, Ma= xCaptures=3D1" - I knpw there's a latter example devoted to MCCs, but sho= uld this and the next MCC have more attributes to show the captures they = contain Section 12.1.1. page 46: "(In addition, there are encoding constraints ... the simultaneous transm= ission sets.)" - I'm not sure if there's a need for this final section al= l be in parentheses Section 12.1.1. page 47: "Encoding Groups:" - in this section EG0, EG1 and EG2 all contain three e= ncodings each, even though EG0 and EG2 only contain a single captures. Wi= th the removal of the ability to map a capture to more than one encoding = the smaller encodings in EG0 and EG2 no longer serve a purpose. This section also makes references to specific capture scenes and sapture= scene views; might make sense to move it after that section of the examp= le. Probably worth mentioning that encodings are not carried directly in the = Advertisement but are instead the example is summarising information carr= ied in SDP. Section 12.1.1. page 48: "Different capture scenes are unique to each other, non-overlapping." - I= had some trouble parsing this; consider instead something like "Differen= t capture scenes are distinct from each other, and are non-overlapping."?= Also, "capture scene" here and in the next sentence should be capitalise= d. Section 12.1.1. page 49: "the 3 audio captures (AC0, AC1, AC2)" - "audio capture" is defined in th= e terminology and should be capitalised "the media capture attributes" - "media capture" is defined in the termin= ology and should be capitalised "choose a capture scene view" - "capture scene view" is defined in the t= erminology and should be capitalised "A consumer that can receive three people streams would" - "people stream= s" seems a bit odd here - "video streams"? "A consumer that can receive only one people stream would probably" - as = above Section 12.1.3. page 50: "12.1.3. The MCU Case": the example contains VCs and ACs; would these not= be more appropriate as MCCs with undefined contents? Section 12.2.2. page 53: "for the correct video capture to be shown" - "video capture" is defined = in the terminology and should be capitalised "configure the individual video captures' encoding groups with what makes= most sense" - "video captures" and "encoding groups" are defined in the= terminology and should be capitalised Section 12.3. page 53: "describing complex and media switching and composition scenarios." - sho= uld not contain an "and" Section 12.3.3. page 64: "containing all of the 9 captures it could Advertise in addition" - "Adve= rtise" is not defined in the terminology section and so shouldn't be capi= talised. Section 15. page 68: "the media is based on RTP and thus existing RTP security mechanisms, suc= h as DTLS/SRTP, MUST be supported." - not aure what this MUST is actually= making mandatory. We decided in Honolulu that DTLS/SRTP would be mandato= ry on CLUE-controlled "m" lines but not on "m" lines that aren't under CL= UE control; will cover that in the signalling document. "an XML schema for this information defined in the CLUE data model [ref]"= - "[ref]" should reference the data model. --------------090101040400070104050100-- From nobody Mon Dec 15 12:22:37 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B751A88AE for ; Mon, 15 Dec 2014 12:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fqFYlWy7zAxa for ; Mon, 15 Dec 2014 12:22:32 -0800 (PST) Received: from resqmta-ch2-06v.sys.comcast.net (resqmta-ch2-06v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:38]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915B91A88A8 for ; Mon, 15 Dec 2014 12:22:32 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-06v.sys.comcast.net with comcast id TwNE1p0032EPM3101wNXBG; Mon, 15 Dec 2014 20:22:31 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-07v.sys.comcast.net with comcast id TwNX1p0063Ge9ey01wNXqC; Mon, 15 Dec 2014 20:22:31 +0000 Message-ID: <548F4306.2050301@alum.mit.edu> Date: Mon, 15 Dec 2014 15:22:30 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5474D6BA.2000301@alum.mit.edu> In-Reply-To: <5474D6BA.2000301@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418674951; bh=pA+tbEM3E9Z2atxhy4rpGoxpoFA1baYnxFuUS5KBWl0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=goodGzXRszlpfreKUFUNA9YFHUhi1Al5gPeZh+bKQywGTqtnUrAk8Woi+UQU9Hjdv 6SOapc+pcKt9Yr7lAC2lTVW8vXr87KFxdbC6zfYM3mkYe7vXrNdx8L+oDrm/nhRqRh +Mr4LZLB+QB+5JPZ2BPPZWciSwEgZpzaKTtwZrDaM8RuEXUh+lVGfMZyOugGnBDdoS ptR+NQIs7EBUEZpMgXaI0PgGiTkdBrBrn/bRv2rt/5M8XHquT0J/shCWQEECAdDGDK jpefbHgjqzP2H/ZPdHAvYR5v3wGT68/vD6zSfk/KL8AZO3aDX84jKBaB/mI/uz4miF IXsTCd53o430w== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/60R-PJmWLlzC4QbZNrnE586Jg3c Subject: Re: [clue] WGLC of CLUE Framework now started - my comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 20:22:34 -0000 I reviewed the -19 version front to back, with the exception of the examples in section 12. Here are the things I noted along the way: Nit: Section 4 is "Overview & Motivation", and section 5 is "Overview of the Framework/Model". It seems odd to have two overviews. Perhaps section 5 could be "Description of the Framework/Model". Section 3: The terms defined below are used throughout this document and companion documents and they are normative. What does it mean for this terminology to be normative? We do have normative language that uses these terms, but then it is that language that is normative, not the term definitions. CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- protocol] and the principles of CLUE negotiation, and wishes to upgrade the call to CLUE-enabled status. I'm slightly bothered by "wishes to upgrade". That doesn't seem to include the case where the call is already CLUE-enabled. How about: CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- protocol] and the principles of CLUE negotiation, and seeks CLUE-enabled calls. In the def of Global View: Global View: A set of references to one or more Capture Scene Views of the same media type that are defined within scenes of the same advertisement. A Global View is a suggestion from the Provider to the Consumer for which CSVs provide a complete representation of the simultaneous captures provided by the Provider, across multiple scenes. I think a tweak to this might be clearer: Global View: A set of references to one or more Capture Scene Views of the same media type that are defined within scenes of the same advertisement. A Global View is a suggestion from the Provider to the Consumer for one set of CSVs that provide a useful representation of all the scenes in the advertisement. I think Plane of Interest: Plane of Interest: The spatial plane containing the most relevant subject matter. can be further clarified. s/plane/plane within a scene/ Section 5: I'm struggling to understand the following paragraph: Second, it MAY, but is not necessarily REQUIRED to, use the information provided to tailor the SDP it is going to send during the following SIP offer/answer exchange, and its reaction to SDP it receives in that step. It is often a sensible implementation choice to do so, as the representation of the media information conveyed over the CLUE channel can dramatically cut down on the size of SDP messages used in the O/A exchange that follows. Spatial relationships associated with the Media can be included in the Advertisement, and it is often sensible for the Media Consumer to take those spatial relationships into account when tailoring the SDP. This seems to me to say that the consumer can use the advertisement to reduce the size of the sdp, which isn't really true. I think the problem is that this text doesn't distinguish between what is done by providers and consumers. For a provider, it may well be infeasible to send SDP covering every encoding in the advertisement. It could potentially reduce the size of SDP to a more manageable size by only offering those encodings that are configured. BUT, as we have things structured now a consumer needs to see the encodings in the SDP to decide what to configure. So this potential can't be realized. For a consumer the potential is not to reduce the size of SDP, but rather to reduce the number of encodings it must set up resources to receive. It probably doesn't want to receive encodings that it doesn't intend to use. I think this is the key point to make in this paragraph. (These comments also apply the the following paragraph.) Section 6: I think another bullet should be added to the beginning of the list: o Each scene has a distinct coordinate system, unrelated to the coordinate systems of other scenes. Section 7.1.1.3: It might be helpful to point out that typically a video capture represents a capture volume that is defined by a pyramid connecting the point of capture to the area of capture. Section 7.2: I find the following slightly confusing: The MCC indicates that one or more Single Media Captures are contained in one Media Capture. I find "contained" a little vague. How about: The MCC indicates that one or more Single Media Captures are multiplexed (temporally and/or spatially) in one Media Capture. Section 7.2.1.2: SoundLevel - This indicates that the content of the MCC is determined by a sound level detection algorithm. For example: the loudest (active) speaker is contained in the MCC. I'm bothered by "For example". Does that mean some other algorithm might be used, for example the quietest capture? I don't think it is an example - it is part of the definition. Section 7.2.1.3: In Table 4 there are two Capture Scene #3s. I presume the latter one should be #5. Section 9.3 says: Each Media Capture, including MCCs, MAY be associated with one or more Encoding Groups. To be eligible for configuration, a Media Capture MUST be associated with at least one Encoding Group, ... Why does this say "or more"..."at least"??? IIUC it should say: Each Media Capture, including MCCs, MAY be associated with one Encoding Group. To be eligible for configuration, a Media Capture MUST be associated with an Encoding Group, ... Section 10: The following: A Configure Message does not include references to Capture Scenes or Capture Scene Views. is *mostly* right. When configuring an MCC you can reference Capture Scenes and Scene Views as part of specifying a subset of the MCC captures. Section 15: In addition, the media is based on RTP and thus existing RTP security mechanisms, such as DTLS/SRTP, MUST be supported. I'm troubled by "such as ... MUST". I suggest: In addition, the media is based on RTP and thus existing RTP security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported. Then: defined in the CLUE data model [ref]. needs the reference filled in. Also, in: Thus, this information SHOULD not be used to should s/SHOULD not/SHOULD NOT/ Thanks, Paul From nobody Mon Dec 15 12:26:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5ABF1A88E9 for ; Mon, 15 Dec 2014 12:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RvmmqBohoHtq for ; Mon, 15 Dec 2014 12:26:02 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.11]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0F171A88A8 for ; Mon, 15 Dec 2014 12:26:02 -0800 (PST) Received: from [216.82.249.212] by server-11.bemta-12.messagelabs.com id 1F/57-02696-AD34F845; Mon, 15 Dec 2014 20:26:02 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-2.tower-219.messagelabs.com!1418675161!3736228!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 31993 invoked from network); 15 Dec 2014 20:26:01 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-2.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 15 Dec 2014 20:26:01 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 15 Dec 2014 12:26:01 -0800 From: "Duckworth, Mark" To: Roni Even , 'CLUE' Date: Mon, 15 Dec 2014 12:25:56 -0800 Thread-Topic: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review Thread-Index: AdAXtbr9mHCXJk2MR+iY36HeJpeBiAA6JOQA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01A00@CRPMBOXPRD08.polycom.com> References: <009401d017b9$ec33f100$c49bd300$@gmail.com> In-Reply-To: <009401d017b9$ec33f100$c49bd300$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/BJD_UP4Dk4_sVOQMV1a7S5GPoAE Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 20:26:04 -0000 Hi Roni, Thanks for the comments. My responses below. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > Sent: Sunday, December 14, 2014 11:21 AM > To: 'CLUE' > Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday > Dec 17. - my review >=20 > Hi, > I read the document (also the 19 version) and have no technical issues. > Some editorial comments >=20 >=20 > 1. I think it may be good to add a reference in section 3 to the taxonom= y > draft mostly since section 4.1 of the taxonomy also discuss the terminolo= gy > of CLUE. [Duckworth, Mark] I thought we already agreed not to. From the IETF90 minu= tes: Action (chairs): Post an email to the list around whether the C=10LUE WG documents should have a dependency (and align with) the AVTEXT ta= xonomy document. Status: CLOSED. There were no responses at all to the= email: http://www.ietf.org/mail-archive/web/clue/current/msg03999.html > 2. In section 3 "Global View" the term scene is mentioned, I assume it > should be capture scene or maybe add to capture scene that when scene is > mentioned it refers to capture scene [Duckworth, Mark] How about add definition for Scene: short for Capture Sce= ne. Similar to Consumer definition > 3. In section 4 bullet (5) "RTP media flows" and "RTP flows" probably "R= TP > streams" according to taxonomy. Also in section 9 "The maximum number of > streams that can result .." "RTP streams"? [Duckworth, Mark] changing flow to stream in section 4 is okay with me. Section 9 - we already define stream to mean RTP, but adding "RTP" here is okay with me. =20 > 4. In section 4 "While the actual mapping of those RTP flows to the head= er > fields of the RTP packets is not subject of > this specification, the large number of possible permutations of > sensible options a Media Provider can make available to a Media > Consumer makes a mechanism desirable that allows to narrow down the > number of possible options that a SIP offer-answer exchange has to > consider." This all text is not clear to me , why header fields .... [Duckworth, Mark] It is referring to the multiplexing as mentioned in previ= ous sentence. > 5. SDP is mentioned in section 3 and in other sections without reference > that appears only in section 9.1 [Duckworth, Mark] SDP offer/answer [RFC3264] is referenced in section 1, wh= ich=20 is what section 3 is referring to. Do you think we need to add more refere= nces to SDP RFC? > 6. Section 5 discuss the model and from the following text "First, it MUS= T > construct and send a CLUE Configure > message to tell the Provider what the Consumer wishes to receive. > Second, it MAY, but is not necessarily REQUIRED to, use the > information provided to tailor the SDP it is going to send during t= he > following SIP offer/answer exchange, and its reaction to SDP it > receives in that step." It may seem that the offer/answer is initiated= by > the Consumer after the Advertisement, yet later in the document it says t= hat > the consumer needs the offer in order to have the individual encodes befo= re > sending the Configure. In this section the issue of who will send the fir= st > offer is not mentioned. [Duckworth, Mark] An o/a could be initiated by the consumer, but doesn't ha= ve to be. This is really defined in the signaling document. I think we don't need to= get into any more detail in the framework. Also I suggest removing "but is not necessarily REQUIRED to" because it is redundant with the previous MAY. > 7. In section 5 " A CLUE-implementing device interoperates with a devic= e > that does not support CLUE, because the non-CLUE device does, by > definition > , not understand the offer of a CLUE channel in the initial offer/answe= r > exchange and, therefore, will reject it. This rejection MUST be used as = the > indication to the CLUE-implementing device that the other side of the > communication is not compliant with CLUE, and to fall back to behavior t= hat > does not require CLUE ." What about the feature tag, I thought that this= is > how you know if CLUE is supported. [Duckworth, Mark] Good point. The signaling document says "Presence of the data channel in a CLUE group in an SDP offer or answer also serves, along with the "sip.clue" media feature tag, as an indication that the devi= ce supports CLUE" I think the text here in the framework is okay, and accurate, because the n= on-CLUE device will reject the CLUE channel, right? Or should the framework be les= s specific and just say the CLUE device knows the other device is non-CLUE by= the mechanisms described in the signaling doc? > 8. In section 7.3.3 you repeat the definition of "global View" from secti= on > 3. [Duckworth, Mark] Yes, is it a problem? Should we remove some of this text from section 7.3.3? > 9. At the end of section 1 maybe need to reference also the protocol > document. [Duckworth, Mark] I agree. > 10. A nit in section 10 "Therefore it can choose to receive a sub-set > ofCaptures indicated by the MCC." "of Captures" [Duckworth, Mark] Thanks > Thanks > Roni Even > As individual From nobody Mon Dec 15 14:14:01 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B78871A0141 for ; Mon, 15 Dec 2014 14:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BjHrpsLAGFU for ; Mon, 15 Dec 2014 14:13:57 -0800 (PST) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC0A31A00DF for ; Mon, 15 Dec 2014 14:13:56 -0800 (PST) Received: by mail-wg0-f52.google.com with SMTP id x12so15850716wgg.39 for ; Mon, 15 Dec 2014 14:13:55 -0800 (PST) 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:thread-index :content-language; bh=DcEmjzAKcN+9VSL6WJd1W7OZUZ7iWPehCPhO6djIs4Y=; b=qDWQD67A6QqFBSfjs2mkp3VWv5ndrOZUrjI0BtLA2C7d93k67uA7YhKw5ptVUlXGFl jTllJ7UJXNL2dQRCPdCPH8gZH3snTo++jzd4p9DGNKBMcZxr73l4NYtEpLsTkYOTooFg pQVOWkjYPVfzM3EvhUTiGQX5Ky/8gPOXylzBo/5lPXQ0r2JslH1idvUFzuz+0pmWVZoa 5tuOzIYqd9t3FgTvnLDkAS6Lyb03wG9UeDjut/24IvA4kS8jfCZQP3F0wTBs1WSEfZla x4kRm2n8D8W+APOnaYelAvs2e5dyrN6LBMl66xqDJDwsvTOx4qgJrGDyarsAumKw5X/e Rnjg== X-Received: by 10.194.78.3 with SMTP id x3mr54677117wjw.127.1418681635537; Mon, 15 Dec 2014 14:13:55 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id k5sm14597563wjn.1.2014.12.15.14.13.53 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Dec 2014 14:13:54 -0800 (PST) From: "Roni Even" To: "'Duckworth, Mark'" , "'CLUE'" References: <009401d017b9$ec33f100$c49bd300$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01A00@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01A00@CRPMBOXPRD08.polycom.com> Date: Tue, 16 Dec 2014 00:13:46 +0200 Message-ID: <018001d018b4$676b0070$36410150$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHwYEQPqR7sOdj+bjEDwINQ1b6LiAI6rr1LnD7NGDA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/rCtrXPGraitkcMY13pZ-Nm85l_Y Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:13:59 -0000 Hi Mark, Inline, I removed the comments that I agree with your response Roni >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Sunday, December 14, 2014 11:21 AM > > To: 'CLUE' > > Subject: Re: [clue] WGLC of CLUE Framework now started. Ends = Wednesday > > Dec 17. - my review > > > > Hi, > > I read the document (also the 19 version) and have no technical = issues. > > Some editorial comments > > > > > > 1. I think it may be good to add a reference in section 3 to the > > taxonomy draft mostly since section 4.1 of the taxonomy also discuss > > the terminology of CLUE. > [Duckworth, Mark] I thought we already agreed not to. From the IETF90 > minutes: > Action (chairs): Post an email to the list around whether the C=10LUE = WG > documents should have a dependency (and align with) the = AVTEXT > taxonomy > document. Status: CLOSED. There were no responses at all = to the email: > = http://www.ietf.org/mail-archive/web/clue/current/msg03999.html >=20 [Roni Even] The Taxonomy refers to CLUE >=20 > > 3. In section 4 bullet (5) "RTP media flows" and "RTP flows" = probably > > "RTP streams" according to taxonomy. Also in section 9 "The maximum > > number of streams that can result .." "RTP streams"? > [Duckworth, Mark] changing flow to stream in section 4 is okay with = me. > Section 9 - we already define stream to mean RTP, but adding "RTP" = here is > okay with me. [Roni Even] I think that throughout the document it should be consistent with the correct term which is RTP stream, not stream or flow. >=20 > > 4. In section 4 "While the actual mapping of those RTP flows to the > > header fields of the RTP packets is not subject of > > this specification, the large number of possible permutations of > > sensible options a Media Provider can make available to a Media > > Consumer makes a mechanism desirable that allows to narrow down = the > > number of possible options that a SIP offer-answer exchange has to > > consider." This all text is not clear to me , why header fields = .... > [Duckworth, Mark] It is referring to the multiplexing as mentioned in previous > sentence. [Roni Even] I do not understand what you it means the mapping of RTP = flows to the header fields of the RTP packets and how it relates to = multiplexing?. >=20 > > 5. SDP is mentioned in section 3 and in other sections without > > reference that appears only in section 9.1 > [Duckworth, Mark] SDP offer/answer [RFC3264] is referenced in section = 1, > which is what section 3 is referring to. Do you think we need to add = more > references to SDP RFC? [Roni Even] Yes >=20 =20 > > 6. Section 5 discuss the model and from the following text "First, = it > > MUST construct and send a CLUE Configure > > message to tell the Provider what the Consumer wishes to receive. > > Second, it MAY, but is not necessarily REQUIRED to, use the > > information provided to tailor the SDP it is going to send = during the > > following SIP offer/answer exchange, and its reaction to SDP it > > receives in that step." It may seem that the offer/answer is > > initiated by the Consumer after the Advertisement, yet later in the > > document it says that the consumer needs the offer in order to have > > the individual encodes before sending the Configure. In this section > > the issue of who will send the first offer is not mentioned. > [Duckworth, Mark] An o/a could be initiated by the consumer, but = doesn't have > to be. [Roni Even] My understanding from the framework is that the consumer = cannot send a configure without having an offer from the provider since it will = not know the individual encoding to compose the configure, so if the = consumer wants to send a configure first as stated it will need the offer from = the provider >From section 10 "In order to meaningfully create and send an initial Configure, the Consumer needs to have received at least one Advertisement, and an SDP offer defining the Individual Encodings, from the Provider." > This is really defined in the signaling document. I think we don't = need to get > into any more detail in the framework. > Also I suggest removing "but is not necessarily REQUIRED to" because = it is > redundant with the previous MAY. >=20 > > 7. In section 5 " A CLUE-implementing device interoperates with a device > > that does not support CLUE, because the non-CLUE device does, by > > definition , not understand the offer of a CLUE channel in the > > initial offer/answer exchange and, therefore, will reject it. This > > rejection MUST be used as the indication to the CLUE-implementing > > device that the other side of the communication is not compliant = with > > CLUE, and to fall back to behavior that does not require CLUE ." = What > > about the feature tag, I thought that this is how you know if CLUE = is > > supported. > [Duckworth, Mark] Good point. The signaling document says "Presence = of the > data channel in a CLUE group in an SDP offer or answer also serves, = along with > the "sip.clue" media feature tag, as an indication that the device supports > CLUE" > I think the text here in the framework is okay, and accurate, because = the non- > CLUE device will reject the CLUE channel, right? Or should the = framework be > less specific and just say the CLUE device knows the other device is non-CLUE > by the mechanisms described in the signaling doc? [Roni Even] The question is if an endpoint sends an offer with the = sip.clue feature tag but do not offer a data channel currently, what does it mean = or is it require to send both? >=20 > > 8. In section 7.3.3 you repeat the definition of "global View" from > > section 3. > [Duckworth, Mark] Yes, is it a problem? Should we remove some of this text > from section 7.3.3? [Roni Even] Yes >=20 >=20 > > Thanks > > Roni Even > > As individual From nobody Mon Dec 15 14:20:57 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F6791A0252 for ; Mon, 15 Dec 2014 14:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iahJpKzD8HOB for ; Mon, 15 Dec 2014 14:20:53 -0800 (PST) Received: from mail-wg0-x22a.google.com (mail-wg0-x22a.google.com [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508D51A020B for ; Mon, 15 Dec 2014 14:20:53 -0800 (PST) Received: by mail-wg0-f42.google.com with SMTP id z12so16004077wgg.15 for ; Mon, 15 Dec 2014 14:20:52 -0800 (PST) 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:thread-index :content-language; bh=KRmM5xi1blCT8GR4UOChpKzvg/GEQgD37PzooyG7PHU=; b=cuX8BZ0ygyz2VOkhrPZh6sco46DVBlKwf07UTL4bYRLBcanSfU9Sa4vkLNhgYafVPc 6+52rGNmqWg4Zic32mBcCHSSM7i0H46xUOfT9coUz0FvIJ5gDA3rk2sxrGm9ZY/LUsP9 xfZQTe4oj8uniRiQcNEdbfSUMYek4AV1ZVt/IuCAXHBMyG0w1HQGWrUNBun+xfo73Ehx YHIXl9hEJlV/mkNN/3KtazehpJ1lRrdX6BTPm/ZVhsR2Trp5z0jONJ05V221lI53FkUK xkEq9PGd8cRBnN8gAM+tlx5QKxavrHsfAHS6xhenpRkuBPEdTrllcrM89Zfk+nz1l88W GCUw== X-Received: by 10.180.85.6 with SMTP id d6mr35539147wiz.82.1418682052112; Mon, 15 Dec 2014 14:20:52 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id h14sm14814803wic.8.2014.12.15.14.20.48 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Dec 2014 14:20:51 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , References: <5474D6BA.2000301@alum.mit.edu> <548F4306.2050301@alum.mit.edu> In-Reply-To: <548F4306.2050301@alum.mit.edu> Date: Tue, 16 Dec 2014 00:20:42 +0200 Message-ID: <018101d018b5$5f771010$1e653030$@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: AQF+Jv0zU8sw2B30DXWe75Tyyb5RKgLSe/CHnR6H4FA= Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/8A_Vm629uj57qgDlQgw_FSuA_Go Subject: Re: [clue] WGLC of CLUE Framework now started - my comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:20:56 -0000 Hi Paul, On your proposal "Section 15: In addition, the media is based on RTP and thus existing RTP security mechanisms, such as DTLS/SRTP, MUST be supported. I'm troubled by "such as ... MUST". I suggest: In addition, the media is based on RTP and thus existing RTP security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported" I think that the current text is OK, we do not mandate a specific RTP security mechanism maybe In addition, the media is based on RTP and thus existing RTP security Mechanisms see RFC7201 MUST be supported. Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 15 December, 2014 10:23 PM > To: clue@ietf.org > Subject: Re: [clue] WGLC of CLUE Framework now started - my comments > > I reviewed the -19 version front to back, with the exception of the examples in > section 12. Here are the things I noted along the way: > > Nit: Section 4 is "Overview & Motivation", and section 5 is "Overview of the > Framework/Model". It seems odd to have two overviews. Perhaps section 5 > could be "Description of the Framework/Model". > > Section 3: > > The terms defined below are used throughout this document and > companion documents and they are normative. > > What does it mean for this terminology to be normative? We do have > normative language that uses these terms, but then it is that language that is > normative, not the term definitions. > > CLUE-capable device: A device that supports the CLUE data channel > [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- > protocol] and the principles of CLUE negotiation, and wishes to > upgrade the call to CLUE-enabled status. > > I'm slightly bothered by "wishes to upgrade". That doesn't seem to include the > case where the call is already CLUE-enabled. How about: > > CLUE-capable device: A device that supports the CLUE data channel > [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- > protocol] and the principles of CLUE negotiation, and seeks > CLUE-enabled calls. > > In the def of Global View: > > Global View: A set of references to one or more Capture Scene Views > of the same media type that are defined within scenes of the same > advertisement. A Global View is a suggestion from the Provider to > the Consumer for which CSVs provide a complete representation of > the simultaneous captures provided by the Provider, across multiple > scenes. > > I think a tweak to this might be clearer: > > Global View: A set of references to one or more Capture Scene Views > of the same media type that are defined within scenes of the same > advertisement. A Global View is a suggestion from the Provider to > the Consumer for one set of CSVs that provide a useful > representation of all the scenes in the advertisement. > > I think Plane of Interest: > > Plane of Interest: The spatial plane containing the most relevant > subject matter. > > can be further clarified. s/plane/plane within a scene/ > > Section 5: > > I'm struggling to understand the following paragraph: > > Second, it MAY, but is not necessarily REQUIRED to, use the > information provided to tailor the SDP it is going to send during > the following SIP offer/answer exchange, and its reaction to SDP it > receives in that step. It is often a sensible implementation > choice to do so, as the representation of the media information > conveyed over the CLUE channel can dramatically cut down on the > size of SDP messages used in the O/A exchange that follows. > Spatial relationships associated with the Media can be included in > the Advertisement, and it is often sensible for the Media Consumer > to take those spatial relationships into account when tailoring the > SDP. > > This seems to me to say that the consumer can use the advertisement to > reduce the size of the sdp, which isn't really true. I think the problem is that this > text doesn't distinguish between what is done by providers and consumers. > > For a provider, it may well be infeasible to send SDP covering every encoding in > the advertisement. It could potentially reduce the size of SDP to a more > manageable size by only offering those encodings that are configured. BUT, as > we have things structured now a consumer needs to see the encodings in the > SDP to decide what to configure. So this potential can't be realized. > > For a consumer the potential is not to reduce the size of SDP, but rather to > reduce the number of encodings it must set up resources to receive. It probably > doesn't want to receive encodings that it doesn't intend to use. I think this is the > key point to make in this paragraph. > > (These comments also apply the the following paragraph.) > > Section 6: > > I think another bullet should be added to the beginning of the list: > > o Each scene has a distinct coordinate system, unrelated to the > coordinate systems of other scenes. > > Section 7.1.1.3: > > It might be helpful to point out that typically a video capture represents a > capture volume that is defined by a pyramid connecting the point of capture to > the area of capture. > > Section 7.2: > > I find the following slightly confusing: > > The MCC indicates that one or more Single Media Captures are > contained in one Media Capture. > > I find "contained" a little vague. How about: > > The MCC indicates that one or more Single Media Captures are > multiplexed (temporally and/or spatially) in one Media Capture. > > Section 7.2.1.2: > > SoundLevel - This indicates that the content of the MCC is > determined by a sound level detection algorithm. For example: the > loudest (active) speaker is contained in the MCC. > > I'm bothered by "For example". Does that mean some other algorithm might be > used, for example the quietest capture? I don't think it is an example - it is part > of the definition. > > Section 7.2.1.3: > > In Table 4 there are two Capture Scene #3s. I presume the latter one should be > #5. > > Section 9.3 says: > > Each Media Capture, including MCCs, MAY be associated with one or > more Encoding Groups. To be eligible for configuration, a Media > Capture MUST be associated with at least one Encoding Group, ... > > Why does this say "or more"..."at least"??? > IIUC it should say: > > Each Media Capture, including MCCs, MAY be associated with one > Encoding Group. To be eligible for configuration, a Media > Capture MUST be associated with an Encoding Group, ... > > Section 10: > > The following: > > A Configure Message does not include > references to Capture Scenes or Capture Scene Views. > > is *mostly* right. When configuring an MCC you can reference Capture Scenes > and Scene Views as part of specifying a subset of the MCC captures. > > Section 15: > > In > addition, the media is based on RTP and thus existing RTP security > mechanisms, such as DTLS/SRTP, MUST be supported. > > I'm troubled by "such as ... MUST". I suggest: > > In > addition, the media is based on RTP and thus existing RTP security > mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported. > > Then: > > defined in the > CLUE data model [ref]. > > needs the reference filled in. > > Also, in: > > Thus, this information SHOULD not be used to > > should s/SHOULD not/SHOULD NOT/ > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Dec 15 14:32:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A06011A1B6A for ; Mon, 15 Dec 2014 14:32:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zvc-G0t47EmV for ; Mon, 15 Dec 2014 14:32:53 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B31F21A1B29 for ; Mon, 15 Dec 2014 14:32:53 -0800 (PST) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-09v.sys.comcast.net with comcast id TyYW1p0032GyhjZ01yYsoU; Mon, 15 Dec 2014 22:32:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-09v.sys.comcast.net with comcast id TyYs1p00Q3Ge9ey01yYsH4; Mon, 15 Dec 2014 22:32:52 +0000 Message-ID: <548F6194.20001@alum.mit.edu> Date: Mon, 15 Dec 2014 17:32:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <009401d017b9$ec33f100$c49bd300$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01A00@CRPMBOXPRD08.polycom.com> <018001d018b4$676b0070$36410150$@gmail.com> In-Reply-To: <018001d018b4$676b0070$36410150$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418682772; bh=I7nzR1PnA1CMfwGEWU5yeVXXQxQmn4xjyvgaaYtLx2E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uKLuBqKaJVULdc/eY31iA8jtDBMtrArD9dgaMDOa2xVe1G8npUt8LOYNzSxVUgSo3 vsWyGPr1d07UJncxWN0Yz7X47h2Pqt6tDcOoD6Py0DbSTU1iodS/jYeP5PVsnPWoZ8 wKjIfkutohjCPrtbj6Iv7r8f8V98jNNSq0qPdYfT/DDNIaNDGqa/Mw6vSfHDMmNLNd ecySlfX2sQ4WrfQN1lVP24mHZRdfHm+54XCsZjOh+mgV1EmL8CAAGtn1RnGnhVU6A8 F3WvpCeWfdry6zk5GMFhKSH2BJSRZqx0zg2mUNulGLxcP3cdRF1i/w1YkPEceBZKYC 0IQq5ojSxIglQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/HRvAgH7W4PPpR7AmeKfnumt15oc Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:32:55 -0000 On 12/15/14 5:13 PM, Roni Even wrote: > [Roni Even] The question is if an endpoint sends an offer with the sip.clue > feature tag but do not offer a data channel currently, what does it mean or > is it require to send both? The feature tag indicates a *capability*, but doesn't indicate if the endpoint wants to use that capability. The data channel in the o/a indicates a desire to use it. Thanks, Paul From nobody Mon Dec 15 14:41:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D309E1A1E0B for ; Mon, 15 Dec 2014 14:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMIQ4RLp-xsM for ; Mon, 15 Dec 2014 14:41:55 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABE0A1A1DE1 for ; Mon, 15 Dec 2014 14:41:55 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-11v.sys.comcast.net with comcast id Tyh31p00F2TL4Rh01yhuxe; Mon, 15 Dec 2014 22:41:54 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id Tyhu1p0063Ge9ey01yhuyK; Mon, 15 Dec 2014 22:41:54 +0000 Message-ID: <548F63B2.8040908@alum.mit.edu> Date: Mon, 15 Dec 2014 17:41:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Roni Even , clue@ietf.org References: <5474D6BA.2000301@alum.mit.edu> <548F4306.2050301@alum.mit.edu> <018101d018b5$5f771010$1e653030$@gmail.com> In-Reply-To: <018101d018b5$5f771010$1e653030$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418683314; bh=fFJ2OU0j7tywG3Dam+6IF4sHfr+cAP4IqHnoJQ0oiU4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=M9qTTnYYP6+eHDfEAfva3skQt8ABT4vGyl0gjq9S6ViuBQdzLoX7Qq5j+eiW9gnZQ kYYK85/vnqm81sTMKwr6rifksBCz4Z2j+4sgWPFq1ZqepBPcu3nxGzk/YycJrZX+ZN B1+uCvitt10pfzXLrf9WXgA/K+YUYziK4M/nBKEas46pVb0BYA2m4GAnkytoffddJb iqlo2EovKqbxv2Tdv5ICvM05uIQ076Dw5gSA0xwRuytyxGQRNXfTW81W9IqZJnc64r Q7xSSIdrbOebABNXaQjYYJtZNL5CW0QHsKN5zjHnrKPZbo+5sbUGL5llxVxYZVi0ZZ Na1gVuxsor/fw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/DT_EXJYiuiKM1PWR6lmhmweQ_yk Subject: Re: [clue] WGLC of CLUE Framework now started - my comments X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:41:58 -0000 On 12/15/14 5:20 PM, Roni Even wrote: > Hi Paul, > > On your proposal > "Section 15: > > In addition, the media is based on RTP and thus existing RTP security > mechanisms, such as DTLS/SRTP, MUST be supported. > > I'm troubled by "such as ... MUST". I suggest: > > In addition, the media is based on RTP and thus existing RTP security > mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported" > > I think that the current text is OK, we do not mandate a specific RTP > security mechanism maybe > In addition, the media is based on RTP and thus existing RTP security > Mechanisms see RFC7201 MUST be supported. RFC7201 is informational. I don't know what a requirement to support it means. ISTM that we will have serious trouble in a security review if we don't make some specific mechanism MTI. That doesn't mean it is mandatory to use, but at least it will ensure an interoperable secure solution. Thanks, Paul > Roni > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 15 December, 2014 10:23 PM >> To: clue@ietf.org >> Subject: Re: [clue] WGLC of CLUE Framework now started - my comments >> >> I reviewed the -19 version front to back, with the exception of the > examples in >> section 12. Here are the things I noted along the way: >> >> Nit: Section 4 is "Overview & Motivation", and section 5 is "Overview of > the >> Framework/Model". It seems odd to have two overviews. Perhaps section 5 >> could be "Description of the Framework/Model". >> >> Section 3: >> >> The terms defined below are used throughout this document and >> companion documents and they are normative. >> >> What does it mean for this terminology to be normative? We do have >> normative language that uses these terms, but then it is that language > that is >> normative, not the term definitions. >> >> CLUE-capable device: A device that supports the CLUE data channel >> [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- >> protocol] and the principles of CLUE negotiation, and wishes to >> upgrade the call to CLUE-enabled status. >> >> I'm slightly bothered by "wishes to upgrade". That doesn't seem to include > the >> case where the call is already CLUE-enabled. How about: >> >> CLUE-capable device: A device that supports the CLUE data channel >> [I-D.ietf-clue-datachannel], the CLUE protocol [I-D.ietf-clue- >> protocol] and the principles of CLUE negotiation, and seeks >> CLUE-enabled calls. >> >> In the def of Global View: >> >> Global View: A set of references to one or more Capture Scene Views >> of the same media type that are defined within scenes of the same >> advertisement. A Global View is a suggestion from the Provider to >> the Consumer for which CSVs provide a complete representation of >> the simultaneous captures provided by the Provider, across multiple >> scenes. >> >> I think a tweak to this might be clearer: >> >> Global View: A set of references to one or more Capture Scene Views >> of the same media type that are defined within scenes of the same >> advertisement. A Global View is a suggestion from the Provider to >> the Consumer for one set of CSVs that provide a useful >> representation of all the scenes in the advertisement. >> >> I think Plane of Interest: >> >> Plane of Interest: The spatial plane containing the most relevant >> subject matter. >> >> can be further clarified. s/plane/plane within a scene/ >> >> Section 5: >> >> I'm struggling to understand the following paragraph: >> >> Second, it MAY, but is not necessarily REQUIRED to, use the >> information provided to tailor the SDP it is going to send during >> the following SIP offer/answer exchange, and its reaction to SDP it >> receives in that step. It is often a sensible implementation >> choice to do so, as the representation of the media information >> conveyed over the CLUE channel can dramatically cut down on the >> size of SDP messages used in the O/A exchange that follows. >> Spatial relationships associated with the Media can be included in >> the Advertisement, and it is often sensible for the Media Consumer >> to take those spatial relationships into account when tailoring the >> SDP. >> >> This seems to me to say that the consumer can use the advertisement to >> reduce the size of the sdp, which isn't really true. I think the problem > is that this >> text doesn't distinguish between what is done by providers and consumers. >> >> For a provider, it may well be infeasible to send SDP covering every > encoding in >> the advertisement. It could potentially reduce the size of SDP to a more >> manageable size by only offering those encodings that are configured. BUT, > as >> we have things structured now a consumer needs to see the encodings in the >> SDP to decide what to configure. So this potential can't be realized. >> >> For a consumer the potential is not to reduce the size of SDP, but rather > to >> reduce the number of encodings it must set up resources to receive. It > probably >> doesn't want to receive encodings that it doesn't intend to use. I think > this is the >> key point to make in this paragraph. >> >> (These comments also apply the the following paragraph.) >> >> Section 6: >> >> I think another bullet should be added to the beginning of the list: >> >> o Each scene has a distinct coordinate system, unrelated to the >> coordinate systems of other scenes. >> >> Section 7.1.1.3: >> >> It might be helpful to point out that typically a video capture represents > a >> capture volume that is defined by a pyramid connecting the point of > capture to >> the area of capture. >> >> Section 7.2: >> >> I find the following slightly confusing: >> >> The MCC indicates that one or more Single Media Captures are >> contained in one Media Capture. >> >> I find "contained" a little vague. How about: >> >> The MCC indicates that one or more Single Media Captures are >> multiplexed (temporally and/or spatially) in one Media Capture. >> >> Section 7.2.1.2: >> >> SoundLevel - This indicates that the content of the MCC is >> determined by a sound level detection algorithm. For example: the >> loudest (active) speaker is contained in the MCC. >> >> I'm bothered by "For example". Does that mean some other algorithm might > be >> used, for example the quietest capture? I don't think it is an example - > it is part >> of the definition. >> >> Section 7.2.1.3: >> >> In Table 4 there are two Capture Scene #3s. I presume the latter one > should be >> #5. >> >> Section 9.3 says: >> >> Each Media Capture, including MCCs, MAY be associated with one or >> more Encoding Groups. To be eligible for configuration, a Media >> Capture MUST be associated with at least one Encoding Group, ... >> >> Why does this say "or more"..."at least"??? >> IIUC it should say: >> >> Each Media Capture, including MCCs, MAY be associated with one >> Encoding Group. To be eligible for configuration, a Media >> Capture MUST be associated with an Encoding Group, ... >> >> Section 10: >> >> The following: >> >> A Configure Message does not include >> references to Capture Scenes or Capture Scene Views. >> >> is *mostly* right. When configuring an MCC you can reference Capture > Scenes >> and Scene Views as part of specifying a subset of the MCC captures. >> >> Section 15: >> >> In >> addition, the media is based on RTP and thus existing RTP security >> mechanisms, such as DTLS/SRTP, MUST be supported. >> >> I'm troubled by "such as ... MUST". I suggest: >> >> In >> addition, the media is based on RTP and thus existing RTP security >> mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported. >> >> Then: >> >> defined in the >> CLUE data model [ref]. >> >> needs the reference filled in. >> >> Also, in: >> >> Thus, this information SHOULD not be used to >> >> should s/SHOULD not/SHOULD NOT/ >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Dec 15 14:46:22 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4E11A01CB for ; Mon, 15 Dec 2014 14:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GHy1wN3JpMM4 for ; Mon, 15 Dec 2014 14:46:19 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282171A0078 for ; Mon, 15 Dec 2014 14:46:19 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id l15so10504984wiw.2 for ; Mon, 15 Dec 2014 14:46:18 -0800 (PST) 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:thread-index :content-language; bh=idClAZTh5kLe++kFLezUqYk7p4TWSraXQ7rR6jVlcH8=; b=yq3Y9Gj13ZWDo1q7NoChtdb+qxKuYcPP+ELkrSDl2uBSSx6EKu0kzqwzyXjaT4afAt Xfr7TFc52kqe2iitGNK83tUSdezGSwdfox1iIbr4/eb9BQXZd9usS6VJinOKRZRqMLXd R7mBtuHqIiS0xZGcrIyLRlxJjBjgo7pq2dfi3xSZOPI16Bfs2aHWoh95Suew/j8NQrNY x4YYzIyChJH3M5aSNbT+UPqIzYl3E/lHhljSqNPySirMKTnBV03vfTGct7a9oNgG5pQl t8weAvQ/k17x//q5bWBQIP0XAGJu/M3iQaNpJ3hsFSeMQpTt4m7RfRzKiTpsCfGsgW30 62IA== X-Received: by 10.194.83.42 with SMTP id n10mr54868342wjy.133.1418683577957; Mon, 15 Dec 2014 14:46:17 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id kn5sm14622279wjb.48.2014.12.15.14.46.16 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 15 Dec 2014 14:46:17 -0800 (PST) From: "Roni Even" To: "'Paul Kyzivat'" , References: <009401d017b9$ec33f100$c49bd300$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01A00@CRPMBOXPRD08.polycom.com> <018001d018b4$676b0070$36410150$@gmail.com> <548F6194.20001@alum.mit.edu> In-Reply-To: <548F6194.20001@alum.mit.edu> Date: Tue, 16 Dec 2014 00:46:10 +0200 Message-ID: <018e01d018b8$ed5e3e50$c81abaf0$@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: AQHwYEQPqR7sOdj+bjEDwINQ1b6LiAI6rr1LAi5fCdcC3T6uDJwWfbUw Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/dOIpDWTjQZH9Uls9aNi55jKiU_M Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Dec 2014 22:46:20 -0000 Hi Paul, The text ia was referring to is > 7. In section 5 " A CLUE-implementing device interoperates with a device > that does not support CLUE, because the non-CLUE device does, by > definition , not understand the offer of a CLUE channel in the > initial offer/answer exchange and, therefore, will reject it. This > rejection MUST be used as the indication to the CLUE-implementing > device that the other side of the communication is not compliant with > CLUE, and to fall back to behavior that does not require CLUE ." What > about the feature tag, I thought that this is how you know if CLUE is > supported. So to be more precise, if the answer rejects the data channel, can it still send the clue feature tag? In this case is the answerer CLUE compliant? My understanding is that the other side is CLUE compliant if it sends the feature tag but do not want to do CLUE now but may do it later Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 16 December, 2014 12:33 AM > To: clue@ietf.org > Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday > Dec 17. - my review > > On 12/15/14 5:13 PM, Roni Even wrote: > > > [Roni Even] The question is if an endpoint sends an offer with the > > sip.clue feature tag but do not offer a data channel currently, what > > does it mean or is it require to send both? > > The feature tag indicates a *capability*, but doesn't indicate if the endpoint > wants to use that capability. The data channel in the o/a indicates a desire to > use it. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Dec 16 05:10:10 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE761ACD5D for ; Tue, 16 Dec 2014 05:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10S5vySyzxjY for ; Tue, 16 Dec 2014 05:09:48 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.106]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E41F1A1AA4 for ; Tue, 16 Dec 2014 05:09:46 -0800 (PST) Received: from [216.82.254.20] by server-10.bemta-7.messagelabs.com id 2D/06-02700-81F20945; Tue, 16 Dec 2014 13:09:44 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-47.messagelabs.com!1418735380!14384843!6 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 9986 invoked from network); 16 Dec 2014 13:09:44 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-9.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 16 Dec 2014 13:09:44 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Tue, 16 Dec 2014 04:55:46 -0800 From: "Duckworth, Mark" To: Roni Even , 'CLUE' Date: Tue, 16 Dec 2014 04:55:43 -0800 Thread-Topic: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review Thread-Index: AQHwYEQPqR7sOdj+bjEDwINQ1b6LiAI6rr1LnD7NGDCAAPis0A== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01A5F@CRPMBOXPRD08.polycom.com> References: <009401d017b9$ec33f100$c49bd300$@gmail.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01A00@CRPMBOXPRD08.polycom.com> <018001d018b4$676b0070$36410150$@gmail.com> In-Reply-To: <018001d018b4$676b0070$36410150$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ksS_Kfs6_MSLHj5xcNg9gDXyELo Subject: Re: [clue] WGLC of CLUE Framework now started. Ends Wednesday Dec 17. - my review X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 13:09:58 -0000 Hi Roni, I removed some of the comments in the discussion, and have a couple more co= mments below. Mark > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Monday, December 15, 2014 5:14 PM > To: Duckworth, Mark; 'CLUE' > Subject: RE: [clue] WGLC of CLUE Framework now started. Ends Wednesday > Dec 17. - my review >=20 > Hi Mark, > Inline, I removed the comments that I agree with your response > Roni >=20 > > > > > -----Original Message----- > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roni Even > > > Sent: Sunday, December 14, 2014 11:21 AM > > > To: 'CLUE' > > > Subject: Re: [clue] WGLC of CLUE Framework now started. Ends > Wednesday > > > Dec 17. - my review > > > > > > 4. In section 4 "While the actual mapping of those RTP flows to the > > > header fields of the RTP packets is not subject of > > > this specification, the large number of possible permutations of > > > sensible options a Media Provider can make available to a Media > > > Consumer makes a mechanism desirable that allows to narrow down > the > > > number of possible options that a SIP offer-answer exchange has to > > > consider." This all text is not clear to me , why header fields .= ... > > [Duckworth, Mark] It is referring to the multiplexing as mentioned in > previous > > sentence. >=20 > [Roni Even] I do not understand what you it means the mapping of RTP > flows > to the header fields of the RTP packets and how it relates to multiplexin= g?. [Duckworth, Mark] If it isn't clear, how about if we just remove it? I don= 't think it adds anything important. So I suggest removing " While the actual mappi= ng of those RTP flows to the header fields of the RTP packets is not subject of this specification" > > > 6. Section 5 discuss the model and from the following text "First, it > > > MUST construct and send a CLUE Configure > > > message to tell the Provider what the Consumer wishes to receive. > > > Second, it MAY, but is not necessarily REQUIRED to, use the > > > information provided to tailor the SDP it is going to send during > the > > > following SIP offer/answer exchange, and its reaction to SDP it > > > receives in that step." It may seem that the offer/answer is > > > initiated by the Consumer after the Advertisement, yet later in the > > > document it says that the consumer needs the offer in order to have > > > the individual encodes before sending the Configure. In this section > > > the issue of who will send the first offer is not mentioned. > > [Duckworth, Mark] An o/a could be initiated by the consumer, but doesn'= t > have > > to be. > [Roni Even] My understanding from the framework is that the consumer > cannot > send a configure without having an offer from the provider since it will = not > know the individual encoding to compose the configure, so if the consume= r > wants to send a configure first as stated it will need the offer from the > provider > From section 10 > "In order to meaningfully create and send an initial Configure, the > Consumer needs to have received at least one Advertisement, and an > SDP offer defining the Individual Encodings, from the Provider." [Duckworth, Mark] I think that really should be "SDP offer or answer". It= =20 doesn't matter which one does offer and which one does answer. Remember, typically an offer or an answer comes from both a provider and a consumer b= ecause they are colocated. Maybe the source of confusion is the words "first" and "second" in the fram= ework text. I think it should not be specifying an order here. If reword it to = not specify an order, would that be clear? > > This is really defined in the signaling document. I think we don't nee= d > to get > > into any more detail in the framework. > > Also I suggest removing "but is not necessarily REQUIRED to" because it= is > > redundant with the previous MAY. > > > 7. In section 5 " A CLUE-implementing device interoperates with a > device > > > that does not support CLUE, because the non-CLUE device does, by > > > definition , not understand the offer of a CLUE channel in the > > > initial offer/answer exchange and, therefore, will reject it. This > > > rejection MUST be used as the indication to the CLUE-implementing > > > device that the other side of the communication is not compliant wit= h > > > CLUE, and to fall back to behavior that does not require CLUE ." Wha= t > > > about the feature tag, I thought that this is how you know if CLUE is > > > supported. > > [Duckworth, Mark] Good point. The signaling document says "Presence of > the > > data channel in a CLUE group in an SDP offer or answer also serves, alo= ng > with > > the "sip.clue" media feature tag, as an indication that the device > supports > > CLUE" > > I think the text here in the framework is okay, and accurate, because t= he > non- > > CLUE device will reject the CLUE channel, right? Or should the framewo= rk > be > > less specific and just say the CLUE device knows the other device is > non-CLUE > > by the mechanisms described in the signaling doc? > [Roni Even] The question is if an endpoint sends an offer with the sip.cl= ue > feature tag but do not offer a data channel currently, what does it mean = or > is it require to send both? [Duckworth, Mark] I suggest the framework doc should be less specific about= this, and refer to the signaling document. You have a good question that should be answered in the signaling document. Mark From nobody Tue Dec 16 07:31:00 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6080C1A1B44 for ; Tue, 16 Dec 2014 07:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.901 X-Spam-Level: X-Spam-Status: No, score=0.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, MANGLED_LOAN=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNBGcgeuFPTP for ; Tue, 16 Dec 2014 07:30:50 -0800 (PST) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215F61A1B75 for ; Tue, 16 Dec 2014 07:30:49 -0800 (PST) Received: by mail-wi0-f176.google.com with SMTP id ex7so12660558wid.3 for ; Tue, 16 Dec 2014 07:30:48 -0800 (PST) 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 :thread-index:content-language; bh=xlAO9RbxuqLZhK/AjO0ezGVRW1AWFtR+fPcE4tYHzoA=; b=srePkObqyGRQ+Yxz9aI8cMJXMEnU1KTMEYzkuQitkSq6PS6xH4BWZv8++A2j7j3UCj ebKFDTDT8AMtNwH3iiCmXUZdRRn0kZ4RX0aK/52jR301AhkgXgVw+02WlDlRIXMwGXq4 qDr6HTAY/JntX+Tp5praDqsRgl9qhVJAcR8LcKMHfpLffIw814qqelnsuuk6/ZUY+1FA EYT2TgrhnWWP5tXuDt9+2WSl5QXiWq1bPpgcwoMoLjbo07OtSMqGSQ3gSGhMhGeK2SLi RAH9rlPG55p9TSKKGQa7iZeNxPjSXS5zkikjGBMfjxRfiQ9/UgoPfg5du05ujpQO8k16 PXSA== X-Received: by 10.180.208.112 with SMTP id md16mr5610386wic.37.1418743847604; Tue, 16 Dec 2014 07:30:47 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id qd2sm2519311wic.19.2014.12.16.07.30.44 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Dec 2014 07:30:46 -0800 (PST) From: "Roni Even" To: Date: Tue, 16 Dec 2014 17:30:43 +0200 Message-ID: <020001d01945$42d50940$c87f1bc0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0201_01D01956.065E9C90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAZRUETF/BKXjYGQzS1N8iVq4cj1Q== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LkB-b7TOabs_2HnitSyuoTuA3nE Subject: Re: [clue] Design team meeting this week - Framework - meeting notes December 16th X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 15:30:54 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0201_01D01956.065E9C90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Participants : Mark, Rob, Paul K., Roni Went through the major comments on the framework WGLC Roni's comments conclusions In section 4 remove "" While the actual mapping of those RTP flows to the header fields of the RTP packets is not subject of this specification"" The text in section 5 on discuss the model and from the following text "First, it MUST construct and send a CLUE Configure message to tell the Provider what the Consumer wishes to receive. Second, it MAY, but is not necessarily REQUIRED to, use the information provided to tailor the SDP it is going to send during the following SIP offer/answer exchange, and its reaction to SDP it receives in that step." There were a couple of points raised. The Consumer needs a previous offer in order to send a configure (discussed in section 10). An SDP answer cannot be used to add to the SDP. The order of the offer/answer in relation to the configure is not needed (remove the First and Second that may hint on order). Mark will look at the text and fix it to address those points. In section 5 " A CLUE-implementing device interoperates with a device that does not support CLUE, because the non-CLUE device does, by definition , not understand the offer of a CLUE channel in the initial offer/answer exchange and, therefore, will reject it. This rejection MUST be used as the indication to the CLUE-implementing device that the other side of the communication is not compliant with CLUE, and to fall back to behavior that does not require CLUE ." The question was if an endpoint sends an offer with the sip.clue feature tag but do not offer a data channel currently, what does it mean in terms of CLUE support or is it require to send both. The conclusion was that the question is for the signaling document and the text her is general but the framework should be consistent? Paul comment discussed: In section 15: " In addition, the media is based on RTP and thus existing RTP security mechanisms, such as DTLS/SRTP, MUST be supported." Suggested " In addition, the media is based on RTP and thus existing RTP security mechanisms SHOULD be supported, and DTLS/SRTP MUST be supported." Conclusion: We agreed to take this suggestion but also mention that the Media security is discussed in the signaling and RTP mapping documents. Rob comments discussed Section 7.2. page 22: "A MCC MAY contain no references to other Captures to indicate that the MCC contains content from multiple sources but no information regarding those sources is given." - We don't specify if an MCC containing 1 or more defined captures may also contain undefined captures. My personal choice would be no - advertised MCCs either contain the defined captures and no others, or have no defined captures and contain only undefined ones. If there are good reasons that any MCC with defined captures also needs to contain potentially undefined ones that's fine too but we should spell it out. Conclusion: agreed to Rob's proposal " advertised MCCs either contain the defined captures and no others, or have no defined captures and contain only undefined ones." Section 10. page 39: "The Consumer may or may not choose to receive all the indicated captures. Therefore it can choose to receive a sub-set ofCaptures indicated by the MCC." - this allowance means that any device that provides an MCC and defines the captures it contains is required to allow any subset of those captures to be chosen bv the consumer. Often the reason the provider is providing an MCC initially is because it cannot supply all the captures directly; unless it has the resources to provide a unique subset of each capture (eg, switched view or custom composition) it will be forced to ot include the contained captures in the MCC, removing the value of having an MCC in the first place. Depending on the clarification to the question on page 22 (whether an MCC with defined captures can also contain undefined captures) the consumer may still be receiving captures it hasn't specified. My preference would be to remove this degree of freedom on the consumer side, or at least make it a suggestion to the provider rather than a mandatory restriction. Conclusion: recommend that the provider may ignore an MCC from a configure that includes a subset of the MCs from the advertise if cannot support it. This is the case when an MCU may not be able to support personal layouts for example. Mark will verify on the list (the other option was to have an attribute in the MCC that explicitly specify support for subset of the MCs in the configure. Note that this is for the defined capture case based on the previous comment) Roni Even From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 14 December, 2014 5:18 PM To: clue@ietf.org Cc: Paul Kyzivat (pkyzivat@alum.mit.edu); danielcburnett@gmail.com Subject: Design team meeting this week - Framework Hi, We would like to resume the weekly design team meetings. The Framework WGLC will end on the 17th but since this will be before the Holidays it will be good to hold a conference call the Tuesday December 16th at the usual time see http://trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team Since we did not meet for some time please let us know If there are any time issues Regards Roni Even CLUE WG Co-chair ------=_NextPart_000_0201_01D01956.065E9C90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Participants : Mark, = Rob, Paul K., Roni

 

Went through the major = comments on the framework WGLC

 

Roni’s comments = conclusions

 

In section 4 = remove “" While the actual mapping of those RTP = flows  to the header fields of the RTP packets is not subject of = this specification"”

 

The text in = section 5 on  discuss the model and from the following text = "First,  it MUST construct and send a CLUE Configure message = to tell the Provider what the Consumer wishes to receive. Second, it = MAY, but is not necessarily REQUIRED to, use the  information = provided to tailor the SDP  it is going to send  during the = following SIP offer/answer exchange, and its reaction to SDP it receives = in that step."  There were a couple of points raised. The = Consumer needs a previous offer in order to send a configure (discussed = in section 10). An SDP answer cannot be used to add to the SDP. The = order of the offer/answer in relation to the configure is not needed = (remove the First and Second that may hint on order).

Mark will look at the text = and fix it to address those points.

 

In section 5 "   A = CLUE-implementing device interoperates with a device that does  not = support CLUE, because the non-CLUE device does, by definition ,  = not understand the offer of a CLUE channel in the initial  = offer/answer exchange and, therefore, will reject it. This  = rejection MUST be used as the indication to the CLUE-implementing  = device that the other side of the communication is not compliant  = with CLUE, and to fall back to behavior that does not require CLUE = ." The question was if an endpoint sends an offer with the sip.clue = feature tag but do not offer a data channel currently, what does it mean = in terms of CLUE support or is it require to send both. =

The = conclusion was that the question is for the signaling document and the = text her is general but the framework should be consistent?

 

Paul comment = discussed:

In section 15: = “ In addition, the media is based on RTP and thus existing RTP = security  mechanisms, such as DTLS/SRTP, MUST be = supported.”

Suggested = “ In addition, the media is based on RTP and thus existing RTP = security  mechanisms SHOULD be supported, and DTLS/SRTP MUST be = supported.”

Conclusion: We = agreed to take this suggestion but also mention that the Media security = is discussed in the signaling and RTP mapping = documents.

 

 

Rob = comments discussed

 

 

Section 7.2. page 22:

"A MCC MAY contain no references to other = Captures to indicate that the MCC contains content from multiple sources = but no information regarding those sources is given." - We don't = specify if an MCC containing 1 or more defined captures may also contain = undefined captures. My personal choice would be no - advertised MCCs = either contain the defined captures and no others, or have no defined = captures and contain only undefined ones. If there are good reasons that = any MCC with defined captures also needs to contain potentially = undefined ones that's fine too but we should spell it = out.

 

Conclusion: agreed to Rob’s proposal “ = advertised MCCs either contain the defined captures and no others, or = have no defined captures and contain only undefined = ones.”

 

Section 10. page 39:

"The Consumer may or may not choose to receive = all the indicated captures.  Therefore it can choose to receive a = sub-set ofCaptures indicated by the MCC." - this allowance means = that any device that provides an MCC and defines the captures it = contains is required to allow any subset of those captures to be chosen = bv the consumer. Often the reason the provider is providing an MCC = initially is because it cannot supply all the captures directly; unless = it has the resources to provide a unique subset of each capture (eg, = switched view or custom

composition) it will be forced to ot include the = contained captures in the MCC, removing the value of having an MCC in = the first place.

Depending on the = clarification to the question on page 22 (whether an MCC with defined = captures can also contain undefined captures) the consumer may still be = receiving captures it hasn't specified. My preference would be to remove = this degree of freedom on the consumer side, or at least make it a = suggestion to the provider rather than a mandatory = restriction.

 

Conclusion: recommend that the provider may ignore = an MCC from a configure that includes a subset of the MCs from the = advertise if cannot support it. This is the case when an MCU may not be = able to support personal layouts for example. Mark will verify on the = list (the other option was to have an attribute in the MCC that = explicitly specify support for subset of the MCs in the configure. Note = that this is for the defined capture case based on the previous comment) =

 

Roni = Even

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 14 December, = 2014 5:18 PM
To: clue@ietf.org
Cc: Paul Kyzivat = (pkyzivat@alum.mit.edu); danielcburnett@gmail.com
Subject: = Design team meeting this week - Framework =

 

Hi,

We would like = to resume the weekly design team meetings.

 

The = Framework WGLC will end on the 17th but since this will be = before the Holidays  it will be good to hold a conference call the = Tuesday December 16th at the usual time see http://= trac.tools.ietf.org/wg/clue/trac/wiki/Design-Team

 

Since we did = not meet for some time please let us know If there are any time = issues

 

Regards

Roni = Even

CLUE WG = Co-chair

------=_NextPart_000_0201_01D01956.065E9C90-- From nobody Tue Dec 16 11:12:55 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 795241ACDF0 for ; Tue, 16 Dec 2014 11:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNOG1AYlEd6C for ; Tue, 16 Dec 2014 11:12:46 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 636951ACDB0 for ; Tue, 16 Dec 2014 11:12:46 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so13637472wiv.2 for ; Tue, 16 Dec 2014 11:12:45 -0800 (PST) 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 :thread-index:content-language; bh=V2OTmW0KSSlGs63JsK86pPhdTgPZPWCTEH3xUJQi5U8=; b=f6KD7K8wl06qeeAmTRd53tW99kMBRGMgSy12/MYPh0eWiWwImAALiY9+HifpHuaYI0 wbR6h7/NnG6OgLmXgGRpd97hACKYjASXYkTbXcCJXZvOZJT05rttz6TBuUJqyF3owdR5 5TRV62o9X2fOw8/hw1CYTbQeJHMJqN/78Hj7qtpr+QI1t/8ROo6RchGCWszzr1ev7+v5 xhOivA3IuWBuGDPGTDfQ1EHMgAJ2zoc0lm6oWkQ8YVaVO4+7OfEMzQO5NDb0G9UyY4PJ 2CRcK+ZKTPo/gvIVpvAkBGY8rDxluGpbY2WwHRFLxm578LzLMLsjwSrtZ0qEbZrc6QId CHyg== X-Received: by 10.194.200.1 with SMTP id jo1mr66178651wjc.64.1418757165120; Tue, 16 Dec 2014 11:12:45 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id pf4sm2164006wjb.36.2014.12.16.11.12.43 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 16 Dec 2014 11:12:44 -0800 (PST) From: "Roni Even" To: Date: Tue, 16 Dec 2014 21:12:40 +0200 Message-ID: <025801d01964$45042d30$cf0c8790$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0259_01D01975.088DC080" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdAZYxQiwhGcL/eSQ/GI/y7k226w/Q== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/BKvatjVR7Y22CMWSwQPiw6MbBKw Subject: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2014 19:12:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0259_01D01975.088DC080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, During the framework WGLC we had a discussion about what is an endpoint that supports CLUE. The conclusion was to defer it to the signaling document. Both the framework and the signaling have the following term CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel ], the CLUE protocol [I-D.ietf-clue-protocol] and the principles of CLUE negotiation, and wishes to upgrade the call to CLUE-enabled status. Yet we also have the media feature tag - sip.clue that according to section 3 of the signaling draft indicates support for CLUE. It also says "Presence of the media feature tag in the contact field of a request or response can be used to determine that the far end supports CLUE." So if an endpoint gets an invite with the feature tag and no CLUE data channel is this a CLUE capable endpoint. The interesting case is if the INVITE included the feature tag and the CLUE data channel and the response rejected the channel but had the feature tag, is the remote end point CLUE capable, is it allowed to reject the data channel but have the feature tag? My view is that it is enough to have the feature tag to call an endpoint CLUE capable, other views? Thanks Roni ------=_NextPart_000_0259_01D01975.088DC080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

During the = framework WGLC we had a discussion about what is an endpoint that = supports CLUE. The conclusion was to defer it to the signaling = document.

 

Both the framework and the signaling have the = following term

 

CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel], the CLUE protocol =
[I-D.ietf-clue-protocol] and the principles of CLUE negotiation, and =
wishes to  upgrade the call to CLUE-enabled =
status.

 

 

Yet we =
also have the media feature tag – sip.clue that according to =
section 3 of the signaling draft indicates support for CLUE. It also =
says “Presence of the media feature =
tag in the contact field of a request or response can be used to =
determine that the far end supports =
CLUE.”

 

So if an = endpoint gets an invite with the feature tag and no CLUE data channel is = this a CLUE capable endpoint.

The = interesting case is if the INVITE included the feature tag and the CLUE = data channel and the response rejected the channel but had the feature = tag, is the remote end point CLUE capable, is it allowed to reject the = data channel but have the feature tag?

 

My view is = that it is enough to have the feature tag to call an endpoint CLUE = capable, other views?

 

Thanks

Roni

------=_NextPart_000_0259_01D01975.088DC080-- From nobody Tue Dec 16 18:23:11 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 284DB1A0242 for ; Tue, 16 Dec 2014 18:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6uiv3yiZflJ for ; Tue, 16 Dec 2014 18:23:06 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3D911A0203 for ; Tue, 16 Dec 2014 18:23:05 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) with Microsoft SMTP Server (TLS) id 15.1.31.17; Wed, 17 Dec 2014 02:22:42 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0031.000; Wed, 17 Dec 2014 02:22:42 +0000 From: Stephan Wenger To: CLUE Thread-Topic: Review of framework-19 Thread-Index: AQHQGaBVCHXmU18pr0KjqNcKWRxPhw== Date: Wed, 17 Dec 2014 02:22:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: ietf.org; dkim=none (message not signed) header.d=none; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1276; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1276; x-forefront-prvs: 042857DBB5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(53754006)(51444003)(120916001)(68736005)(40100003)(122556002)(102836002)(450100001)(99286002)(31966008)(229853001)(99396003)(2900100001)(77156002)(62966003)(110136001)(16236675004)(97736003)(101416001)(21056001)(105586002)(106356001)(54356999)(66066001)(50986999)(107886001)(92566001)(86362001)(87936001)(36756003)(106116001)(20776003)(2656002)(4396001)(107046002)(64706001)(46102003)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1276; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Content-Type: multipart/alternative; boundary="_000_D0B5C3064D6C5stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/clue/uhCQmjMWbnMobMOZzho62I9Pw4I Subject: [clue] Review of framework-19 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 02:23:10 -0000 --_000_D0B5C3064D6C5stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I'm one of the authors, but (as many of you know) have not actively contrib= uted in a year or so. Insofar, I think this review qualifies as a set of f= resh eyes, though not one that is impartial. I have no major technical comments, and I'm generally happy with the docume= nt. I have, however, a minor non-editorial comments and a few nits. As fa= r as I am concerned, none are showstoppers. Major issues: None Minor issues: 1. Page 3, last para "CLUE specific signaling". At this point in the te= xt, the term "CLUE" is undefined. I don't think it is defined anywhere. S= ince "CLUE signalling", "CLUE channel", ... are used elsewhere in the text,= I think page 3 would be the right place to define "CLUE", probably as some= thing like "a set of protocols described in this memo and accompanying docu= ments (the term "CLUE stems from the IETF working group ." = As an alternative, CLUE could also defined as a stand-alone term in sectio= n 3 (around page 4). 2. Page 8.motivation (1): I think that this motivation is generally corr= ect when adding "in a cross-vendor interoperable way". I know from a number= of systems that allowed a mix-and-match, some of them designed as early as= 2003. 3. Page 10, second para, add reference to data model doc? 4. Page 15, MUST strength for providing physical dimensions of known to = the system. I like this philosophically, but I think it's meaningless in p= ractice, as the knowledge of coordinates of a pProvider is known to the con= sumer only as a side effect of sending the measurements, right? Perhaps l= ess draconian language is more appropriate? Sounds to me like a good place= for a "SHOULD"? 5. Page 20, Languages: is this coded using a universal language tag? If= yes, should that be mentioned here, with reference? 6. Page 69, second para, is SIP the *default* conferencing protocol or j= ust simply "the conferencing protocol"? As the following MUST is unqualifi= ed, the "default" is probably incorrect. 7. Page 69 DTLS/SRTP "MUST" level support. I think that was our agreeme= nt in Hawaii-pacify the security people, knowing that industry practice may= well look different. In this light, I think the mandatory to implement, o= ptional to use formulation here is about right. Is my recollection correct= ? 8. Page 69, fifth para, reference to data model doc is missing. Also, m= y understanding of XML is such that a schema is the grammar of an XML docum= ent, but not the content. Insofar, the info is NOT represented by a schema= , it just is in XML format following a schema that is defined in the data m= odel, right? 9. Page 70, first paragraphs. There are two unqualified "SHOULD" statem= ents. In the spirit of fast doc approval, I wouldn't object if those were = changed to "MUST". I don't recall that we discussed these points before, b= ut I could easily have missed that discussion. Possible editorial improvements 1. Throughout the doc, the spacing after a full stop is inconsistent bet= ween a single and double space. (My personal preference is double space). 2. Hyphens are sometimes represented with double minus and no spaces, an= d sometimes single minus with spaces. (My personal preference is double mi= nus without spaces.) 3. In-doc cross-references are not hyperlinks in PDF version 4. In some cases, references to I-Ds are not hyperlinks. In other cases= , they are. 5. Bullets are sometimes shown as "o", sometimes as "." 6. Page 6, MCU, suggest to remove the acronym at the begin of the line. 7. Page 7, ampersand in headline of section 4: suggest to replace it wit= h "and" 8. Page 13, second para, middle, "it MAY, but is not necessarily REQUIRE= D to, " The "REQUIRED" part is redundant. 9. Page 21, types of Captured people: shouldn't there be an additional "= Observer"? "Members" have the right to speak up, "Observers" have not? Or= are these people types coming from some other doc? 10. Page 26, Table 3 should not be split over two pages 11. Page 27, Table 4 should not be split 12. Page 30, third para, "In some cases, these multiple views would typic= ally be used simultaneously" sounds awkward. Can we do away with the "typi= cally", as this does not appear a typical case, just one of many? 13. Page 30, example should be on one page 14. Page 33, rules, s/not important/insignificant/ 15. Page 40, first line, s/a n/an/ 16. Pages 54, 55, 60 one of the tables contains a page break 17. Page 61 62, ditto, but that one is probably unavoidable due to the si= ze of the tables END --_000_D0B5C3064D6C5stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,
I’m one of the authors, but (as many of you know) have not actively c= ontributed in a year or so.  Insofar, I think this review qualifies as= a set of fresh eyes, though not one that is impartial. 

I have no major technical comments, and I’m generally happy with the = document.  I have, however, a minor non-editorial comments and a few n= its.  As far as I am concerned, none are showstoppers.

Major issues:
None

Minor issues:
  1. Page 3, last para “CL= UE specific signaling”.  At this point in the text, the term = 220;CLUE" is undefined.  I don’t think it is defined anywhe= re.  Since “CLUE signalling”, "CLUE channel”, &= #8230; are used elsewhere in the text, I think page 3 would be the right place to define “CLUE”= , probably as something like “a set of protocols described in this me= mo and accompanying documents (the term “CLUE stems from the IETF wor= king group <clue deacronym>.”  As an alternative, CLUE cou= ld also defined as a stand-alone term in section 3 (around page 4).
  2. Page 8.motivation (1): I think t= hat this motivation is generally correct when adding “in a cross-vend= or interoperable way”. I know from a number of systems that allowed a= mix-and-match, some of them designed as early as 2003.
  3. Page 10, second para, add reference to data model d= oc?
  4. Page 15, MUST stren= gth for providing physical dimensions of known to the system.  I like = this philosophically, but I think it’s meaningless in practice, as th= e knowledge of coordinates of a pProvider is known to the consumer only as a side effect of sending  the measurements, righ= t?  Perhaps less draconian language is more appropriate?  Sounds = to me like a good place for a “SHOULD”?
  5. Page 20, Langua= ges: is this coded using a universal language tag?  If yes, should tha= t be mentioned here, with reference?
  6. Page 69, second para, is SIP t= he *default* conferencing protocol or just simply “the conferencing p= rotocol”?  As the following MUST is unqualified, the “defa= ult” is probably incorrect.
  7. Page 69 DTLS/SRTP “MUSTR= 21; level support.  I think that was our agreement in Hawaii—pac= ify the security people, knowing that industry practice may well look diffe= rent.  In this light, I think the mandatory to implement, optional to = use formulation here is about right.  Is my recollection correct?
  8. Page 69, fifth para= , reference to data model doc is missing.  Also, my understanding of X= ML is such that a schema is the grammar of an XML document, but not the con= tent.  Insofar, the info is NOT represented by a schema, it just is in= XML format following a schema that is defined in the data model, right?
  9. Page 70, first = paragraphs.  There are two unqualified “SHOULD” statements= .  In the spirit of fast doc approval, I wouldn’t object if thos= e were changed to “MUST”.  I don’t recall that we di= scussed these points before, but I could easily have missed that discussion.
Possible editorial improvements 
  1. Throughout the doc, the spacing after a full stop is inconsistent between a= single and double space.  (My personal preference is double space). &= nbsp;
  2. Hyphens are sometimes represented with double minus and no spaces, and some= times single minus with spaces.  (My personal preference is double min= us without spaces.)
  3. In-doc cross-references are not hyperlinks in PDF version
  4. In some cases, references to I-Ds are not hyperlinks.  In other cases,= they are.
  5. Bullets are sometimes shown as “o”, sometimes as “."=
  6. Page 6, MCU, suggest to remove the acronym at the begin of the line.
    7. Page 7, ampersand in headline of section 4: suggest to replace it with R= 20;and”
  7. Page 13, second para, middle, “it MAY, but is not necessarily REQUIRE= D to, “  The “REQUIRED” part is redundant.
  8. Page 21, types of Captured people: shouldn’t there be an additional &= #8220;Observer”?  “Members” have the right to speak = up, “Observers" have not?  Or are these people types coming= from some other doc?
  9. Page 26, Table 3 should not be split over two pages
  10. Page 27, Table 4 should not be split
  11. Page 30, third para, “In some c= ases, these multiple views wo= uld typically be used simultaneously” sounds awkward.  Can we do= away with the “typically”, as this does not appear a typical case, just one of many?
  12. Page 30, example should be on one p= age
  13. Page 33, rules, s/not = important/insignificant/
  14. P= age 40, first line, s/a n/an/
  15. Pages 54, 55, 60 one of the tables contains a page break
    16. Page 61 62, ditto, but that one is proba= bly unavoidable due to the size of the tables
END
--_000_D0B5C3064D6C5stewesteweorg_-- From nobody Tue Dec 16 21:15:07 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3C221A1BCF for ; Tue, 16 Dec 2014 21:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30KzdpCacqVi for ; Tue, 16 Dec 2014 21:15:02 -0800 (PST) Received: from resqmta-ch2-02v.sys.comcast.net (resqmta-ch2-02v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37BC21A0394 for ; Tue, 16 Dec 2014 21:15:01 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-02v.sys.comcast.net with comcast id UVEy1p0032VvR6D01VF1Wq; Wed, 17 Dec 2014 05:15:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-19v.sys.comcast.net with comcast id UVF01p00C3Ge9ey01VF0Fs; Wed, 17 Dec 2014 05:15:01 +0000 Message-ID: <54911154.5040107@alum.mit.edu> Date: Wed, 17 Dec 2014 00:15:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <025801d01964$45042d30$cf0c8790$@gmail.com> In-Reply-To: <025801d01964$45042d30$cf0c8790$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418793301; bh=QfgZZ/x2nCQyhOAoxSf78+FJEQ33wkJpKFKP/m+/5Gw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=wkAgPLig5bvs/fmA760BaohfYpAsiDOS+06gmMQQNdDFNh9+Rt8NcyeeBw7ZYzE6z LqzVxJgOeb+nZ/7o4u4A4Wsqe9zrrsL27iTrHdDBgKl+17tPOV0ySQXJjlbEeTPfyj LDyMhr6yHk/qq4aIROZUWu06tjo5/u1HFP0vfxuoJfvcp9m3oQ/eth0tlbCJ8XxMey EUQOvY3eRu3gb40tpLUTPaLIOrMqnXmvwC9SkS3ZrbiHuBqQARUqqtFniUU27tanMt IzWysWOcgY2Kd+XXx8cq8a05/FkjjJOyRXLcicA2Yx/rch1weNjFyU99d8pY2wv89H T8lRXI5zHTCbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bjZVxsh63hzY7rQfBY1yE65Xh4Q Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 05:15:04 -0000 On 12/16/14 2:12 PM, Roni Even wrote: > Hi, > > During the framework WGLC we had a discussion about what is an endpoint > that supports CLUE. The conclusion was to defer it to the signaling > document. > > Both the framework and the signaling have the following term > > CLUE-capable device: A device that supports the CLUE data channel [I-D.ietf-clue-datachannel ], the CLUE protocol [I-D.ietf-clue-protocol] and the principles of CLUE negotiation, and wishes to upgrade the call to CLUE-enabled status. > > Yet we also have the media feature tag – sip.clue that according to section 3 of the signaling draft indicates support for CLUE. It also says “Presence of the media feature tag in the contact field of a request or response can be used to determine that the far end supports CLUE.” > > So if an endpoint gets an invite with the feature tag and no CLUE data > channel is this a CLUE capable endpoint. > > The interesting case is if the INVITE included the feature tag and the > CLUE data channel and the response rejected the channel but had the > feature tag, is the remote end point CLUE capable, is it allowed to > reject the data channel but have the feature tag? > > My view is that it is enough to have the feature tag to call an endpoint > CLUE capable, other views? My take is that that the feature tag indicates that the endpoint *understands* CLUE, and is capable of using CLUE if it wishes. But it doesn't necessarily mean that it always wants to use CLUE - it may choose not to in some cases. For instance a mobile endpoint might choose not to use CLUE when it has a poor wireless connection. Thanks, Paul From nobody Wed Dec 17 01:19:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5074F1A1A5B for ; Wed, 17 Dec 2014 01:19:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.611 X-Spam-Level: X-Spam-Status: No, score=-3.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE1E415lWwJX for ; Wed, 17 Dec 2014 01:19:25 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2573E1A079A for ; Wed, 17 Dec 2014 01:19:25 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BQE12556; Wed, 17 Dec 2014 09:19:23 +0000 (GMT) Received: from SZXEMA411-HUB.china.huawei.com (10.82.72.70) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 17 Dec 2014 09:19:22 +0000 Received: from SZXEMA511-MBS.china.huawei.com ([169.254.6.161]) by szxema411-hub.china.huawei.com ([10.82.72.70]) with mapi id 14.03.0158.001; Wed, 17 Dec 2014 17:19:19 +0800 From: "Xiaojing (Lennard)" To: Paul Kyzivat , "clue@ietf.org" , Roni Even Thread-Topic: [clue] CLUE signaling document queation Thread-Index: AdAZYxQiwhGcL/eSQ/GI/y7k226w/QAEkWIAABj2BPA= Date: Wed, 17 Dec 2014 09:19:19 +0000 Message-ID: <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> In-Reply-To: <54911154.5040107@alum.mit.edu> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.75.133.25] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/clue/fW7fAyd5ksnyaq1swiCCsSwgMoQ Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 09:19:27 -0000 Hi Roni, I agree with you and Paul. CLUE-capable doesn't necessarily mean CLUE-preferable.=20 Best regards, Lennard > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, December 17, 2014 1:15 PM > To: clue@ietf.org > Subject: Re: [clue] CLUE signaling document queation >=20 > On 12/16/14 2:12 PM, Roni Even wrote: > > Hi, > > > > During the framework WGLC we had a discussion about what is an > endpoint > > that supports CLUE. The conclusion was to defer it to the signaling > > document. > > > > Both the framework and the signaling have the following term > > > > CLUE-capable device: A device that supports the CLUE data channel [I- > D.ietf-clue-datachannel framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I- > D.ietf-clue-protocol] and the principles of CLUE negotiation, and > wishes to upgrade the call to CLUE-enabled status. > > > > Yet we also have the media feature tag - sip.clue that according to > section 3 of the signaling draft indicates support for CLUE. It also > says "Presence of the media feature tag in the contact field of a > request or response can be used to determine that the far end supports > CLUE." > > > > So if an endpoint gets an invite with the feature tag and no CLUE > data > > channel is this a CLUE capable endpoint. > > > > The interesting case is if the INVITE included the feature tag and > the > > CLUE data channel and the response rejected the channel but had the > > feature tag, is the remote end point CLUE capable, is it allowed to > > reject the data channel but have the feature tag? > > > > My view is that it is enough to have the feature tag to call an > endpoint > > CLUE capable, other views? >=20 > My take is that that the feature tag indicates that the endpoint > *understands* CLUE, and is capable of using CLUE if it wishes. But it > doesn't necessarily mean that it always wants to use CLUE - it may > choose not to in some cases. For instance a mobile endpoint might > choose > not to use CLUE when it has a poor wireless connection. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Dec 17 07:05:51 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 018011A88CF for ; Wed, 17 Dec 2014 07:05:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hrH_q-N15rUk for ; Wed, 17 Dec 2014 07:05:39 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 659B71A8AA6 for ; Wed, 17 Dec 2014 07:05:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2879; q=dns/txt; s=iport; t=1418828739; x=1420038339; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=lIeYddncfIDrDV69X40onMQk5yElkM+bnPFbp3sCKP8=; b=UJhEJrlrrCcXQXRWRHqLMHRCDUfxCe7CbZNaaJztYum7wH0QNoaYFjDT ZPD/KVt3epDOnQYPntFOwoVfeZhSiEwU7VCk3vuDvudrkVqoj0KlZv7mg pWKQskTwgVH4S9GVnRFsKFbIkvDHPxhOqBGmpqqIsy8fOJnueLBYD+aL+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4MAMCakVStJssW/2dsb2JhbABag1hYszcBAQEBAQEFAXeRNAqFcgKBNQEBAQEBfYQMAQEBBAEBATU2Cg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYgoDdRlAQEBAQEBAQMBAQEBAQEBFwSGAIl5BhCEEwEEkUaFMoV8i0Qig2w+MYJDAQEB X-IronPort-AV: E=Sophos;i="5.07,594,1413244800"; d="scan'208";a="278362834" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 17 Dec 2014 15:05:37 +0000 Received: from [10.47.200.30] ([10.47.200.30]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBHF5bEt010057 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 17 Dec 2014 15:05:37 GMT Message-ID: <54919BC4.4050500@cisco.com> Date: Wed, 17 Dec 2014 15:05:40 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> In-Reply-To: <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KKQS50hdFZfL0EqAmiT3d-6trEw Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 15:05:46 -0000 My understanding is that the two views aren't entirely compatible, unless there's something I've not understood. I agree with Paul, that the feature tag should indicate that an understanding of CLUE, but not necessarily a desire to do it, and hence isn't sufficient to define a device as CLUE-capable. Rob On 17/12/14 09:19, Xiaojing (Lennard) wrote: > Hi Roni, > > I agree with you and Paul. > CLUE-capable doesn't necessarily mean CLUE-preferable. > > Best regards, > Lennard > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Wednesday, December 17, 2014 1:15 PM >> To: clue@ietf.org >> Subject: Re: [clue] CLUE signaling document queation >> >> On 12/16/14 2:12 PM, Roni Even wrote: >>> Hi, >>> >>> During the framework WGLC we had a discussion about what is an >> endpoint >>> that supports CLUE. The conclusion was to defer it to the signaling >>> document. >>> >>> Both the framework and the signaling have the following term >>> >>> CLUE-capable device: A device that supports the CLUE data channel [I- >> D.ietf-clue-datachannel > framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I- >> D.ietf-clue-protocol] and the principles of CLUE negotiation, and >> wishes to upgrade the call to CLUE-enabled status. >>> Yet we also have the media feature tag - sip.clue that according to >> section 3 of the signaling draft indicates support for CLUE. It also >> says "Presence of the media feature tag in the contact field of a >> request or response can be used to determine that the far end supports >> CLUE." >>> So if an endpoint gets an invite with the feature tag and no CLUE >> data >>> channel is this a CLUE capable endpoint. >>> >>> The interesting case is if the INVITE included the feature tag and >> the >>> CLUE data channel and the response rejected the channel but had the >>> feature tag, is the remote end point CLUE capable, is it allowed to >>> reject the data channel but have the feature tag? >>> >>> My view is that it is enough to have the feature tag to call an >> endpoint >>> CLUE capable, other views? >> My take is that that the feature tag indicates that the endpoint >> *understands* CLUE, and is capable of using CLUE if it wishes. But it >> doesn't necessarily mean that it always wants to use CLUE - it may >> choose not to in some cases. For instance a mobile endpoint might >> choose >> not to use CLUE when it has a poor wireless connection. >> >> 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 nobody Wed Dec 17 09:17:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301B91A1EF6 for ; Wed, 17 Dec 2014 09:17:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7pobp6LWd30 for ; Wed, 17 Dec 2014 09:17:37 -0800 (PST) Received: from resqmta-ch2-09v.sys.comcast.net (resqmta-ch2-09v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB03F1A1BD9 for ; Wed, 17 Dec 2014 09:17:36 -0800 (PST) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-09v.sys.comcast.net with comcast id UhHW1p0032TL4Rh01hHcH8; Wed, 17 Dec 2014 17:17:36 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-17v.sys.comcast.net with comcast id UhHb1p0043Ge9ey01hHb7S; Wed, 17 Dec 2014 17:17:36 +0000 Message-ID: <5491BAAF.7080809@alum.mit.edu> Date: Wed, 17 Dec 2014 12:17:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> <54919BC4.4050500@cisco.com> In-Reply-To: <54919BC4.4050500@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1418836656; bh=z5CEm/ZRxt6YVaJzHCAHeHmmlqO3CSs+nuZ6fDrhk04=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Pp598Nm9L2DoHqvON8UW+Fyj7jjV8X6VB8UpWODhVOTsK4bdawU23WzF4dh/loD4X N5ctds9dloI9pY9gO22E6sgEgIIknBlYZk3JE5RWZxQZjj392R6LUQMSGTND6SomN7 24DQrw6NIyJWMzZocIlSg3bkv/B7DUKRatUDjfXSeBGoZwV0VPNRQylqnqu+/ywXj/ lCVAFj5+AAkxv6vJBciTvc1nq9WYuAQTN5X3d4Nzk1t7IMt9sA6W9zx48YIDcZwRr6 rujysxMxzmQFfyFPaOldF8h0VitIUf+srVlAsAO4eXpO/vHxwOddBv/MatH35WZHc8 7+bd7/l4vne7g== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/TBHdb9J0Cj70enBXqNJIchBAqJw Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 17:17:46 -0000 On 12/17/14 10:05 AM, Robert Hansen wrote: > My understanding is that the two views aren't entirely compatible, > unless there's something I've not understood. > > I agree with Paul, that the feature tag should indicate that an > understanding of CLUE, but not necessarily a desire to do it, and hence > isn't sufficient to define a device as CLUE-capable. This highlights the terminology issues. We have described 'sip.clue' as a feature tag, which is indeed one name for it. But in RFC3840/3841 is called a callee *capability* (in contrast to a caller preference). Using that terminology something that includes sip.clue is clearly *capable* of clue, though it may not always be willing. Offering to negotiate the clue channel indicates that it is also *willing* to use clue. Thanks, Paul > Rob > > On 17/12/14 09:19, Xiaojing (Lennard) wrote: >> Hi Roni, >> >> I agree with you and Paul. >> CLUE-capable doesn't necessarily mean CLUE-preferable. >> >> Best regards, >> Lennard >> >>> -----Original Message----- >>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Wednesday, December 17, 2014 1:15 PM >>> To: clue@ietf.org >>> Subject: Re: [clue] CLUE signaling document queation >>> >>> On 12/16/14 2:12 PM, Roni Even wrote: >>>> Hi, >>>> >>>> During the framework WGLC we had a discussion about what is an >>> endpoint >>>> that supports CLUE. The conclusion was to defer it to the signaling >>>> document. >>>> >>>> Both the framework and the signaling have the following term >>>> >>>> CLUE-capable device: A device that supports the CLUE data channel [I- >>> D.ietf-clue-datachannel >> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I- >>> D.ietf-clue-protocol] and the principles of CLUE negotiation, and >>> wishes to upgrade the call to CLUE-enabled status. >>>> Yet we also have the media feature tag - sip.clue that according to >>> section 3 of the signaling draft indicates support for CLUE. It also >>> says "Presence of the media feature tag in the contact field of a >>> request or response can be used to determine that the far end supports >>> CLUE." >>>> So if an endpoint gets an invite with the feature tag and no CLUE >>> data >>>> channel is this a CLUE capable endpoint. >>>> >>>> The interesting case is if the INVITE included the feature tag and >>> the >>>> CLUE data channel and the response rejected the channel but had the >>>> feature tag, is the remote end point CLUE capable, is it allowed to >>>> reject the data channel but have the feature tag? >>>> >>>> My view is that it is enough to have the feature tag to call an >>> endpoint >>>> CLUE capable, other views? >>> My take is that that the feature tag indicates that the endpoint >>> *understands* CLUE, and is capable of using CLUE if it wishes. But it >>> doesn't necessarily mean that it always wants to use CLUE - it may >>> choose not to in some cases. For instance a mobile endpoint might >>> choose >>> not to use CLUE when it has a poor wireless connection. >>> >>> Thanks, >>> Paul >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Dec 17 10:12:39 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 938791A1B98 for ; Wed, 17 Dec 2014 10:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.911 X-Spam-Level: X-Spam-Status: No, score=-13.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UhXR87u7CVP1 for ; Wed, 17 Dec 2014 10:12:34 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5C0C1A1BC4 for ; Wed, 17 Dec 2014 10:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4084; q=dns/txt; s=iport; t=1418839954; x=1420049554; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=gei6WH6ONSdtsEwPr3qG/kZCPHerm6PeN5T6eU8G7QI=; b=SEb8KEYhzFlG8rODB/hEa3R4Pz5q6Z47ICH6Y6+4/ltLReVQHxVtSRVs 3RiGgi75Jp86KGFATiKwPer9E8iVnf/zjZUfySkQo1lJNTOo22Hrqkh6c lajqgBhlai8YJvSyppF6vU8BIF+JbpRpsDDBkVAuwg19vn11MB+p3ZC8v M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak4MAEPHkVStJssW/2dsb2JhbABag1hYszgBAQEBAQEFAXeRNAqFcgKBNgEBAQEBfYQMAQEBBAEBATU2Cg0ECxEEAQEBCRYIBwkDAgECARUfCQgTBgIBAYgoDdUyAQEBAQEBAQMBAQEBAQEBFwSGAIl5BoQjAQSRRoUyhXyLRCKDbD4xgkMBAQE X-IronPort-AV: E=Sophos;i="5.07,595,1413244800"; d="scan'208";a="273800106" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 17 Dec 2014 18:12:13 +0000 Received: from [10.47.200.30] ([10.47.200.30]) (authenticated bits=0) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sBHICCv5030297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 17 Dec 2014 18:12:12 GMT Message-ID: <5491C77F.5090904@cisco.com> Date: Wed, 17 Dec 2014 18:12:15 +0000 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: clue@ietf.org References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> <54919BC4.4050500@cisco.com> <5491BAAF.7080809@alum.mit.edu> In-Reply-To: <5491BAAF.7080809@alum.mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/fnauoTCJhCWjjf0VifQLOver_qI Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 18:12:36 -0000 So maybe what we need to change is the "CLUE-capable" definition (which currently means "capable and willing", which I agree isn't intuitive) to something like "CLUE-supporting"? Rob On 17/12/14 17:17, Paul Kyzivat wrote: > On 12/17/14 10:05 AM, Robert Hansen wrote: >> My understanding is that the two views aren't entirely compatible, >> unless there's something I've not understood. >> >> I agree with Paul, that the feature tag should indicate that an >> understanding of CLUE, but not necessarily a desire to do it, and hence >> isn't sufficient to define a device as CLUE-capable. > > This highlights the terminology issues. We have described 'sip.clue' > as a feature tag, which is indeed one name for it. But in RFC3840/3841 > is called a callee *capability* (in contrast to a caller preference). > Using that terminology something that includes sip.clue is clearly > *capable* of clue, though it may not always be willing. > > Offering to negotiate the clue channel indicates that it is also > *willing* to use clue. > > Thanks, > Paul > >> Rob >> >> On 17/12/14 09:19, Xiaojing (Lennard) wrote: >>> Hi Roni, >>> >>> I agree with you and Paul. >>> CLUE-capable doesn't necessarily mean CLUE-preferable. >>> >>> Best regards, >>> Lennard >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Wednesday, December 17, 2014 1:15 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] CLUE signaling document queation >>>> >>>> On 12/16/14 2:12 PM, Roni Even wrote: >>>>> Hi, >>>>> >>>>> During the framework WGLC we had a discussion about what is an >>>> endpoint >>>>> that supports CLUE. The conclusion was to defer it to the signaling >>>>> document. >>>>> >>>>> Both the framework and the signaling have the following term >>>>> >>>>> CLUE-capable device: A device that supports the CLUE data channel [I- >>>> D.ietf-clue-datachannel >>> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I- >>>> D.ietf-clue-protocol] and the principles of CLUE negotiation, and >>>> wishes to upgrade the call to CLUE-enabled status. >>>>> Yet we also have the media feature tag - sip.clue that according to >>>> section 3 of the signaling draft indicates support for CLUE. It also >>>> says "Presence of the media feature tag in the contact field of a >>>> request or response can be used to determine that the far end supports >>>> CLUE." >>>>> So if an endpoint gets an invite with the feature tag and no CLUE >>>> data >>>>> channel is this a CLUE capable endpoint. >>>>> >>>>> The interesting case is if the INVITE included the feature tag and >>>> the >>>>> CLUE data channel and the response rejected the channel but had the >>>>> feature tag, is the remote end point CLUE capable, is it allowed to >>>>> reject the data channel but have the feature tag? >>>>> >>>>> My view is that it is enough to have the feature tag to call an >>>> endpoint >>>>> CLUE capable, other views? >>>> My take is that that the feature tag indicates that the endpoint >>>> *understands* CLUE, and is capable of using CLUE if it wishes. But it >>>> doesn't necessarily mean that it always wants to use CLUE - it may >>>> choose not to in some cases. For instance a mobile endpoint might >>>> choose >>>> not to use CLUE when it has a poor wireless connection. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Dec 18 11:31:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 915CF1A1B16 for ; Thu, 18 Dec 2014 11:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z32JTDmssXJa for ; Thu, 18 Dec 2014 11:31:41 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3BF91A1BD1 for ; Thu, 18 Dec 2014 11:31:40 -0800 (PST) X-AuditID: c1b4fb2d-f79fc6d000001087-40-54932b9a5064 Received: from ESESSHC016.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 3F.80.04231.A9B23945; Thu, 18 Dec 2014 20:31:38 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC016.ericsson.se ([153.88.183.66]) with mapi id 14.03.0195.001; Thu, 18 Dec 2014 20:31:38 +0100 From: Christer Holmberg To: Robert Hansen , "clue@ietf.org" Thread-Topic: [clue] CLUE signaling document queation Thread-Index: AdAZYxQiwhGcL/eSQ/GI/y7k226w/QATPHkAAAiIXYAADBicAAAEm22AAAHow4AANvrGAA== Date: Thu, 18 Dec 2014 19:31:37 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D607295@ESESSMB209.ericsson.se> References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> <54919BC4.4050500@cisco.com> <5491BAAF.7080809@alum.mit.edu> <5491C77F.5090904@cisco.com> In-Reply-To: <5491C77F.5090904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPLMWRmVeSWpSXmKPExsUyM+Jvje4s7ckhBmv+21jsP3WZ2eLT/w/s DkweU35vZPVYsuQnUwBTFJdNSmpOZllqkb5dAldG2+e1rAVPNCseH9nE1MA4SamLkYNDQsBE 4uwxny5GTiBTTOLCvfVsILaQwBFGiS/PcrsYuYDsJYwSz9rPsIDUswlYSHT/0wapERFwl1h8 8CoziC0MNGblnkesEHFTias7upkg7DCJ841NbCCtLAKqEj8PC4OEeQV8JXoeH2eFGN/MJPFj /iawOZwCmhI3e74ygtiMQPd8P7UGbA6zgLjErSfzmSDuFJBYsuc8M4QtKvHy8T9WCFtJonHJ E1aIeh2JBbs/sUHY2hLLFr5mhlgsKHFy5hOWCYyis5CMnYWkZRaSlllIWhYwsqxiFC1OLS7O TTcy1kstykwuLs7P08tLLdnECIyRg1t+6+5gXP3a8RCjAAejEg+vofOkECHWxLLiytxDjNIc LErivIvOzQsWEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwBjUenHqJPOOBVKm2QvvlK2eYhOx IfWIGUv7WfUv+fWqycWbEotTYnsWzV+rv1PiRerfOPb6gwVJ+vI1892OVLBsMVqxt9Rro2ec otpbi7ypE5ZvVP4v2HwiQuKESr6JVrIuA+dZZZOThj/6w+1cnecu4VL1d/8YcN771xej0tY+ NUvzs3I/lFiKMxINtZiLihMBfBfli3ICAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/clue/akOfl08mPEeMOKM_YCaEXMSXbnA Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Dec 2014 19:31:43 -0000 Hi, First, it depends on what the scope of the media feature tag is. If a device indicates support for a feature in an INVITE request/response, = my understanding is that it applies to that given session (at least that is= what it means for feature capability indicators). But, still, even if the answerer e.g. rejects the data channel, it may stil= l indicate support for CLUE. Because, it may be willing to do CLUE later in= the session, e.g. if the coverage gets better. So, I think it's perfectly ok to indicate support of CLUE, even if you don'= t accept the data channel at a given point - as long as you MAY be willing = to do CLUE later during the session. If you KNOW that you won't do CLUE during the session, then I don't think y= ou should indicate support of CLUE for that session either. Regards, Christer -----Original Message----- From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen Sent: 17 December 2014 20:12 To: clue@ietf.org Subject: Re: [clue] CLUE signaling document queation So maybe what we need to change is the "CLUE-capable" definition (which cur= rently means "capable and willing", which I agree isn't intuitive) to somet= hing like "CLUE-supporting"? Rob On 17/12/14 17:17, Paul Kyzivat wrote: > On 12/17/14 10:05 AM, Robert Hansen wrote: >> My understanding is that the two views aren't entirely compatible,=20 >> unless there's something I've not understood. >> >> I agree with Paul, that the feature tag should indicate that an=20 >> understanding of CLUE, but not necessarily a desire to do it, and=20 >> hence isn't sufficient to define a device as CLUE-capable. > > This highlights the terminology issues. We have described 'sip.clue'=20 > as a feature tag, which is indeed one name for it. But in RFC3840/3841=20 > is called a callee *capability* (in contrast to a caller preference). > Using that terminology something that includes sip.clue is clearly > *capable* of clue, though it may not always be willing. > > Offering to negotiate the clue channel indicates that it is also > *willing* to use clue. > > Thanks, > Paul > >> Rob >> >> On 17/12/14 09:19, Xiaojing (Lennard) wrote: >>> Hi Roni, >>> >>> I agree with you and Paul. >>> CLUE-capable doesn't necessarily mean CLUE-preferable. >>> >>> Best regards, >>> Lennard >>> >>>> -----Original Message----- >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Wednesday, December 17, 2014 1:15 PM >>>> To: clue@ietf.org >>>> Subject: Re: [clue] CLUE signaling document queation >>>> >>>> On 12/16/14 2:12 PM, Roni Even wrote: >>>>> Hi, >>>>> >>>>> During the framework WGLC we had a discussion about what is an >>>> endpoint >>>>> that supports CLUE. The conclusion was to defer it to the=20 >>>>> signaling document. >>>>> >>>>> Both the framework and the signaling have the following term >>>>> >>>>> CLUE-capable device: A device that supports the CLUE data channel=20 >>>>> [I- >>>> D.ietf-clue-datachannel=20 >>>> >>> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I-=20 >>>> D.ietf-clue-protocol] and the principles of CLUE negotiation, and=20 >>>> wishes to upgrade the call to CLUE-enabled status. >>>>> Yet we also have the media feature tag - sip.clue that according=20 >>>>> to >>>> section 3 of the signaling draft indicates support for CLUE. It=20 >>>> also says "Presence of the media feature tag in the contact field=20 >>>> of a request or response can be used to determine that the far end=20 >>>> supports CLUE." >>>>> So if an endpoint gets an invite with the feature tag and no CLUE >>>> data >>>>> channel is this a CLUE capable endpoint. >>>>> >>>>> The interesting case is if the INVITE included the feature tag and >>>> the >>>>> CLUE data channel and the response rejected the channel but had=20 >>>>> the feature tag, is the remote end point CLUE capable, is it=20 >>>>> allowed to reject the data channel but have the feature tag? >>>>> >>>>> My view is that it is enough to have the feature tag to call an >>>> endpoint >>>>> CLUE capable, other views? >>>> My take is that that the feature tag indicates that the endpoint >>>> *understands* CLUE, and is capable of using CLUE if it wishes. But=20 >>>> it doesn't necessarily mean that it always wants to use CLUE - it=20 >>>> may choose not to in some cases. For instance a mobile endpoint=20 >>>> might choose not to use CLUE when it has a poor wireless=20 >>>> connection. >>>> >>>> Thanks, >>>> Paul >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From nobody Thu Dec 18 22:52:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48101A9132 for ; Thu, 18 Dec 2014 22:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLJIIz1OHcA9 for ; Thu, 18 Dec 2014 22:52:54 -0800 (PST) Received: from mail-wg0-x231.google.com (mail-wg0-x231.google.com [IPv6:2a00:1450:400c:c00::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69C1C1AC3FD for ; Thu, 18 Dec 2014 22:52:52 -0800 (PST) Received: by mail-wg0-f49.google.com with SMTP id n12so492817wgh.8 for ; Thu, 18 Dec 2014 22:52:51 -0800 (PST) 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:thread-index :content-language; bh=yrnG4ckW3pQFCl4upBMzQdMqVvbxHPDrsIBAOuhBQmU=; b=JDNBnaSFtpFarIHINvNo24Nb2pDw9b3H+sRIuKsJyWDpw0wsMtF6l6HhuBNKmSGxz0 Po/mfsKo1O5dXPvKVliw9M3cMIKI2+O3v7FpDfG0QfNf/Ut3RlLbkj9iyJMlHppaw2cl L3fbKyTS5Ez3pD7NaBcq4XJ1Xnhd5wxPiSnMNnB8o7An4SwlJvA30/hnQNa8ExkYB2C6 k7weMQusrS0pLbKa+zJ/xdHjDL3VQS3J/n5pTD/Ry4O2GsCP0QltbZ3sKXuCaGHwcKhm 9SSJVtg83Wu9YgoeWkRcq5+U5FvQJ2AO5krF+eQyIEfHVfMqwTNIFRCCxbF0ZnS3Ps32 1FLA== X-Received: by 10.180.96.67 with SMTP id dq3mr2692126wib.51.1418971971245; Thu, 18 Dec 2014 22:52:51 -0800 (PST) Received: from RoniE (bzq-79-182-183-87.red.bezeqint.net. [79.182.183.87]) by mx.google.com with ESMTPSA id cs8sm1228754wib.1.2014.12.18.22.52.49 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Dec 2014 22:52:50 -0800 (PST) From: "Roni Even" To: "'Christer Holmberg'" , "'Robert Hansen'" , References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> <54919BC4.4050500@cisco.com> <5491BAAF.7080809@alum.mit.edu> <5491C77F.5090904@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D607295@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D607295@ESESSMB209.ericsson.se> Date: Fri, 19 Dec 2014 08:52:45 +0200 Message-ID: <051001d01b58$670de420$3529ac60$@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: AQFvwXqGnuoR7H7WNxWsEoAzGNdBZgHTazDHAol+/V0BkkbFpwF17os5AqU6rHoCJK4gw5z1tIbg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/GAVJ12bk2IwZWlRjQQTMCLlSWyE Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 06:52:56 -0000 Hi, I started this discussion based on a comment I made on the framework draft. So it seems like we need to update the definition of CLUE capable device in the framework and the signaling document (they should be the same). There is also some text in the framework at the end of section 5 about discovering if the remote endpoint is CLUE capable that will need to be fixed Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 18 December, 2014 9:32 PM > To: Robert Hansen; clue@ietf.org > Subject: Re: [clue] CLUE signaling document queation > > Hi, > > First, it depends on what the scope of the media feature tag is. > > If a device indicates support for a feature in an INVITE request/response, my > understanding is that it applies to that given session (at least that is what it > means for feature capability indicators). > > But, still, even if the answerer e.g. rejects the data channel, it may still indicate > support for CLUE. Because, it may be willing to do CLUE later in the session, > e.g. if the coverage gets better. > > So, I think it's perfectly ok to indicate support of CLUE, even if you don't accept > the data channel at a given point - as long as you MAY be willing to do CLUE > later during the session. > > If you KNOW that you won't do CLUE during the session, then I don't think you > should indicate support of CLUE for that session either. > > Regards, > > Christer > > > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen > Sent: 17 December 2014 20:12 > To: clue@ietf.org > Subject: Re: [clue] CLUE signaling document queation > > So maybe what we need to change is the "CLUE-capable" definition (which > currently means "capable and willing", which I agree isn't intuitive) to > something like "CLUE-supporting"? > > Rob > > On 17/12/14 17:17, Paul Kyzivat wrote: > > On 12/17/14 10:05 AM, Robert Hansen wrote: > >> My understanding is that the two views aren't entirely compatible, > >> unless there's something I've not understood. > >> > >> I agree with Paul, that the feature tag should indicate that an > >> understanding of CLUE, but not necessarily a desire to do it, and > >> hence isn't sufficient to define a device as CLUE-capable. > > > > This highlights the terminology issues. We have described 'sip.clue' > > as a feature tag, which is indeed one name for it. But in RFC3840/3841 > > is called a callee *capability* (in contrast to a caller preference). > > Using that terminology something that includes sip.clue is clearly > > *capable* of clue, though it may not always be willing. > > > > Offering to negotiate the clue channel indicates that it is also > > *willing* to use clue. > > > > Thanks, > > Paul > > > >> Rob > >> > >> On 17/12/14 09:19, Xiaojing (Lennard) wrote: > >>> Hi Roni, > >>> > >>> I agree with you and Paul. > >>> CLUE-capable doesn't necessarily mean CLUE-preferable. > >>> > >>> Best regards, > >>> Lennard > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, December 17, 2014 1:15 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] CLUE signaling document queation > >>>> > >>>> On 12/16/14 2:12 PM, Roni Even wrote: > >>>>> Hi, > >>>>> > >>>>> During the framework WGLC we had a discussion about what is an > >>>> endpoint > >>>>> that supports CLUE. The conclusion was to defer it to the > >>>>> signaling document. > >>>>> > >>>>> Both the framework and the signaling have the following term > >>>>> > >>>>> CLUE-capable device: A device that supports the CLUE data channel > >>>>> [I- > >>>> D.ietf-clue-datachannel > >>>> >>>> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I- > >>>> D.ietf-clue-protocol] and the principles of CLUE negotiation, and > >>>> wishes to upgrade the call to CLUE-enabled status. > >>>>> Yet we also have the media feature tag - sip.clue that according > >>>>> to > >>>> section 3 of the signaling draft indicates support for CLUE. It > >>>> also says "Presence of the media feature tag in the contact field > >>>> of a request or response can be used to determine that the far end > >>>> supports CLUE." > >>>>> So if an endpoint gets an invite with the feature tag and no CLUE > >>>> data > >>>>> channel is this a CLUE capable endpoint. > >>>>> > >>>>> The interesting case is if the INVITE included the feature tag and > >>>> the > >>>>> CLUE data channel and the response rejected the channel but had > >>>>> the feature tag, is the remote end point CLUE capable, is it > >>>>> allowed to reject the data channel but have the feature tag? > >>>>> > >>>>> My view is that it is enough to have the feature tag to call an > >>>> endpoint > >>>>> CLUE capable, other views? > >>>> My take is that that the feature tag indicates that the endpoint > >>>> *understands* CLUE, and is capable of using CLUE if it wishes. But > >>>> it doesn't necessarily mean that it always wants to use CLUE - it > >>>> may choose not to in some cases. For instance a mobile endpoint > >>>> might choose not to use CLUE when it has a poor wireless > >>>> connection. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Dec 19 05:19:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B0E1A889B for ; Fri, 19 Dec 2014 05:19:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.601 X-Spam-Level: X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWFcVvqUzvRm for ; Fri, 19 Dec 2014 05:19:49 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E984A1A8840 for ; Fri, 19 Dec 2014 05:19:48 -0800 (PST) X-AuditID: c1b4fb3a-f79116d000000fec-13-549425f2cd39 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 0C.17.04076.2F524945; Fri, 19 Dec 2014 14:19:46 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.175]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0195.001; Fri, 19 Dec 2014 14:19:46 +0100 From: Christer Holmberg To: Roni Even , 'Robert Hansen' , "clue@ietf.org" Thread-Topic: [clue] CLUE signaling document queation Thread-Index: AdAZYxQiwhGcL/eSQ/GI/y7k226w/QATPHkAAAiIXYAADBicAAAEm22AAAHow4AANvrGAAAV3zqAAA+XGdA= Date: Fri, 19 Dec 2014 13:19:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D60C3C9@ESESSMB209.ericsson.se> References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> <54919BC4.4050500@cisco.com> <5491BAAF.7080809@alum.mit.edu> <5491C77F.5090904@cisco.com> <7594FB04B1934943A5C02806D1A2204B1D607295@ESESSMB209.ericsson.se> <051001d01b58$670de420$3529ac60$@gmail.com> In-Reply-To: <051001d01b58$670de420$3529ac60$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyM+Jvje4n1SkhBht+mlvsP3WZ2eLT/w/s Fn/bmR2YPab83sjqsXPWXXaPJUt+MgUwR3HZpKTmZJalFunbJXBl7N15hq3gl2lFx4aP7A2M O7W7GDk5JARMJLqXrWeBsMUkLtxbzwZiCwkcYZR4vjuki5ELyF7CKNHTcR+oiIODTcBCovsf WK+IQL7E9Za7rCC2MNCclXsesULETSWu7uhmgrCTJA53rANrZRFQlZj5ShgkzCvgKzHl5kxm iPFfmSS+nGpmBanhBBrfejMEpIYR6Jzvp9aAjWEWEJe49WQ+E8SZAhJL9pxnhrBFJV4+/scK YStKXJ2+HKpeR2LB7k9sELa2xLKFr5kh9gpKnJz5hGUCo+gsJGNnIWmZhaRlFpKWBYwsqxhF i1OLi3PTjYz0Uosyk4uL8/P08lJLNjECo+bglt9WOxgPPnc8xCjAwajEw7thyuQQIdbEsuLK 3EOM0hwsSuK8C8/NCxYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAmLOOU0RsTlzI/TcvFimn 9h3tuxVfe9Th143S55N+vJvjbNq9gMnKO3/1O8OkNfG73374JB8zd+6VSpbQUL7EF9d+bzwY +S2YT6ZcLMD/zqZPdrys7WwK1Zua1s48+ENvqz3PzhOaLzNS1mo7VzJFzu6q+2kkrFkVtMzM i0NaYWL2U/4PLpOfKrEUZyQaajEXFScCAIHTRXd7AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LJnKutLahBtknHuMFDDiBucN_mw Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 13:19:51 -0000 Hi, In general, I don't think we should have the same definition in two places.= Put it in the framework draft, and reference it from other drafts. Regards, Christer -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: 19. joulukuuta 2014 8:53 To: Christer Holmberg; 'Robert Hansen'; clue@ietf.org Subject: RE: [clue] CLUE signaling document queation Hi, I started this discussion based on a comment I made on the framework draft. So it seems like we need to update the definition of CLUE capable device in= the framework and the signaling document (they should be the same). There = is also some text in the framework at the end of section 5 about discoveri= ng if the remote endpoint is CLUE capable that will need to be fixed Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christer=20 > Holmberg > Sent: 18 December, 2014 9:32 PM > To: Robert Hansen; clue@ietf.org > Subject: Re: [clue] CLUE signaling document queation >=20 > Hi, >=20 > First, it depends on what the scope of the media feature tag is. >=20 > If a device indicates support for a feature in an INVITE=20 > request/response, my > understanding is that it applies to that given session (at least that=20 > is what it > means for feature capability indicators). >=20 > But, still, even if the answerer e.g. rejects the data channel, it may still indicate > support for CLUE. Because, it may be willing to do CLUE later in the session, > e.g. if the coverage gets better. >=20 > So, I think it's perfectly ok to indicate support of CLUE, even if you don't accept > the data channel at a given point - as long as you MAY be willing to=20 > do CLUE > later during the session. >=20 > If you KNOW that you won't do CLUE during the session, then I don't=20 > think you > should indicate support of CLUE for that session either. >=20 > Regards, >=20 > Christer >=20 >=20 > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen > Sent: 17 December 2014 20:12 > To: clue@ietf.org > Subject: Re: [clue] CLUE signaling document queation >=20 > So maybe what we need to change is the "CLUE-capable" definition=20 > (which currently means "capable and willing", which I agree isn't=20 > intuitive) to something like "CLUE-supporting"? >=20 > Rob >=20 > On 17/12/14 17:17, Paul Kyzivat wrote: > > On 12/17/14 10:05 AM, Robert Hansen wrote: > >> My understanding is that the two views aren't entirely compatible,=20 > >> unless there's something I've not understood. > >> > >> I agree with Paul, that the feature tag should indicate that an=20 > >> understanding of CLUE, but not necessarily a desire to do it, and=20 > >> hence isn't sufficient to define a device as CLUE-capable. > > > > This highlights the terminology issues. We have described 'sip.clue' > > as a feature tag, which is indeed one name for it. But in=20 > > RFC3840/3841 is called a callee *capability* (in contrast to a caller p= reference). > > Using that terminology something that includes sip.clue is clearly > > *capable* of clue, though it may not always be willing. > > > > Offering to negotiate the clue channel indicates that it is also > > *willing* to use clue. > > > > Thanks, > > Paul > > > >> Rob > >> > >> On 17/12/14 09:19, Xiaojing (Lennard) wrote: > >>> Hi Roni, > >>> > >>> I agree with you and Paul. > >>> CLUE-capable doesn't necessarily mean CLUE-preferable. > >>> > >>> Best regards, > >>> Lennard > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul=20 > >>>> Kyzivat > >>>> Sent: Wednesday, December 17, 2014 1:15 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] CLUE signaling document queation > >>>> > >>>> On 12/16/14 2:12 PM, Roni Even wrote: > >>>>> Hi, > >>>>> > >>>>> During the framework WGLC we had a discussion about what is an > >>>> endpoint > >>>>> that supports CLUE. The conclusion was to defer it to the=20 > >>>>> signaling document. > >>>>> > >>>>> Both the framework and the signaling have the following term > >>>>> > >>>>> CLUE-capable device: A device that supports the CLUE data=20 > >>>>> channel > >>>>> [I- > >>>> D.ietf-clue-datachannel > >>>> >>>> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol=20 > >>>> [I- D.ietf-clue-protocol] and the principles of CLUE negotiation,=20 > >>>> and wishes to upgrade the call to CLUE-enabled status. > >>>>> Yet we also have the media feature tag - sip.clue that according=20 > >>>>> to > >>>> section 3 of the signaling draft indicates support for CLUE. It=20 > >>>> also says "Presence of the media feature tag in the contact field=20 > >>>> of a request or response can be used to determine that the far=20 > >>>> end supports CLUE." > >>>>> So if an endpoint gets an invite with the feature tag and no=20 > >>>>> CLUE > >>>> data > >>>>> channel is this a CLUE capable endpoint. > >>>>> > >>>>> The interesting case is if the INVITE included the feature tag=20 > >>>>> and > >>>> the > >>>>> CLUE data channel and the response rejected the channel but had=20 > >>>>> the feature tag, is the remote end point CLUE capable, is it=20 > >>>>> allowed to reject the data channel but have the feature tag? > >>>>> > >>>>> My view is that it is enough to have the feature tag to call an > >>>> endpoint > >>>>> CLUE capable, other views? > >>>> My take is that that the feature tag indicates that the endpoint > >>>> *understands* CLUE, and is capable of using CLUE if it wishes.=20 > >>>> But it doesn't necessarily mean that it always wants to use CLUE=20 > >>>> - it may choose not to in some cases. For instance a mobile=20 > >>>> endpoint might choose not to use CLUE when it has a poor wireless=20 > >>>> connection. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=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 From nobody Fri Dec 19 06:40:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49FC31A1AC7 for ; Fri, 19 Dec 2014 06:40:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaUXM14MEhX2 for ; Fri, 19 Dec 2014 06:40:38 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3468A1A88CA for ; Fri, 19 Dec 2014 06:40:38 -0800 (PST) Received: from [216.82.254.19] by server-14.bemta-7.messagelabs.com id 77/4E-02703-5E834945; Fri, 19 Dec 2014 14:40:37 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-5.tower-96.messagelabs.com!1419000032!14129171!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 25201 invoked from network); 19 Dec 2014 14:40:34 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-5.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 19 Dec 2014 14:40:34 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Fri, 19 Dec 2014 06:40:31 -0800 From: "Duckworth, Mark" To: Robert Hansen , "clue@ietf.org" Date: Fri, 19 Dec 2014 06:40:28 -0800 Thread-Topic: [clue] CLUE signaling document queation Thread-Index: AdAaJQ2uFRVnDRMpRoGZbrJq6s9YMABc5xqA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01E06@CRPMBOXPRD08.polycom.com> References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> <54919BC4.4050500@cisco.com> <5491BAAF.7080809@alum.mit.edu> <5491C77F.5090904@cisco.com> In-Reply-To: <5491C77F.5090904@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/8wKM2W99fBW07H362V3smxM_9sA Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 14:40:45 -0000 Is there a need for two definitions, then? CLUE-capable - understands CLUE, uses the feature tag, but not necessarily = wanting to use CLUE at the moment. CLUE-supporting - CLUE-capable and currently desiring to use CLUE (this is = the current definition of CLUE-capable in the signaling draft) Or did I get them backwards from Rob's suggestion? I agree with Christer's suggestion to put the definition in just one docume= nt, and reference it from others. Keeping these in the framework is okay w= ith me. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen > Sent: Wednesday, December 17, 2014 1:12 PM > To: clue@ietf.org > Subject: Re: [clue] CLUE signaling document queation >=20 > So maybe what we need to change is the "CLUE-capable" definition (which > currently means "capable and willing", which I agree isn't intuitive) to > something like "CLUE-supporting"? >=20 > Rob >=20 > On 17/12/14 17:17, Paul Kyzivat wrote: > > On 12/17/14 10:05 AM, Robert Hansen wrote: > >> My understanding is that the two views aren't entirely compatible, > >> unless there's something I've not understood. > >> > >> I agree with Paul, that the feature tag should indicate that an > >> understanding of CLUE, but not necessarily a desire to do it, and henc= e > >> isn't sufficient to define a device as CLUE-capable. > > > > This highlights the terminology issues. We have described 'sip.clue' > > as a feature tag, which is indeed one name for it. But in RFC3840/3841 > > is called a callee *capability* (in contrast to a caller preference). > > Using that terminology something that includes sip.clue is clearly > > *capable* of clue, though it may not always be willing. > > > > Offering to negotiate the clue channel indicates that it is also > > *willing* to use clue. > > > > Thanks, > > Paul > > > >> Rob > >> > >> On 17/12/14 09:19, Xiaojing (Lennard) wrote: > >>> Hi Roni, > >>> > >>> I agree with you and Paul. > >>> CLUE-capable doesn't necessarily mean CLUE-preferable. > >>> > >>> Best regards, > >>> Lennard > >>> > >>>> -----Original Message----- > >>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > >>>> Sent: Wednesday, December 17, 2014 1:15 PM > >>>> To: clue@ietf.org > >>>> Subject: Re: [clue] CLUE signaling document queation > >>>> > >>>> On 12/16/14 2:12 PM, Roni Even wrote: > >>>>> Hi, > >>>>> > >>>>> During the framework WGLC we had a discussion about what is an > >>>> endpoint > >>>>> that supports CLUE. The conclusion was to defer it to the signaling > >>>>> document. > >>>>> > >>>>> Both the framework and the signaling have the following term > >>>>> > >>>>> CLUE-capable device: A device that supports the CLUE data channel [= I- > >>>> D.ietf-clue-datachannel >>>> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I- > >>>> D.ietf-clue-protocol] and the principles of CLUE negotiation, and > >>>> wishes to upgrade the call to CLUE-enabled status. > >>>>> Yet we also have the media feature tag - sip.clue that according to > >>>> section 3 of the signaling draft indicates support for CLUE. It also > >>>> says "Presence of the media feature tag in the contact field of a > >>>> request or response can be used to determine that the far end > supports > >>>> CLUE." > >>>>> So if an endpoint gets an invite with the feature tag and no CLUE > >>>> data > >>>>> channel is this a CLUE capable endpoint. > >>>>> > >>>>> The interesting case is if the INVITE included the feature tag and > >>>> the > >>>>> CLUE data channel and the response rejected the channel but had the > >>>>> feature tag, is the remote end point CLUE capable, is it allowed to > >>>>> reject the data channel but have the feature tag? > >>>>> > >>>>> My view is that it is enough to have the feature tag to call an > >>>> endpoint > >>>>> CLUE capable, other views? > >>>> My take is that that the feature tag indicates that the endpoint > >>>> *understands* CLUE, and is capable of using CLUE if it wishes. But i= t > >>>> doesn't necessarily mean that it always wants to use CLUE - it may > >>>> choose not to in some cases. For instance a mobile endpoint might > >>>> choose > >>>> not to use CLUE when it has a poor wireless connection. > >>>> > >>>> Thanks, > >>>> Paul > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> _______________________________________________ > >> clue mailing list > >> clue@ietf.org > >> https://www.ietf.org/mailman/listinfo/clue > >> > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Dec 19 08:32:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE3031A8972 for ; Fri, 19 Dec 2014 08:31:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_34=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-jzDirb7F84 for ; Fri, 19 Dec 2014 08:31:56 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 410AB1A8932 for ; Fri, 19 Dec 2014 08:31:56 -0800 (PST) Received: from resomta-ch2-07v.sys.comcast.net ([69.252.207.103]) by resqmta-ch2-05v.sys.comcast.net with comcast id VUX01p00A2EPM3101UXvFX; Fri, 19 Dec 2014 16:31:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-07v.sys.comcast.net with comcast id VUXu1p00f3Ge9ey01UXvRh; Fri, 19 Dec 2014 16:31:55 +0000 Message-ID: <549452FA.1030604@alum.mit.edu> Date: Fri, 19 Dec 2014 11:31:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <025801d01964$45042d30$cf0c8790$@gmail.com> <54911154.5040107@alum.mit.edu> <8A527E21B95EF842BC0E952D6E82297754CEC4C0@SZXEMA511-MBS.china.huawei.com> <54919BC4.4050500@cisco.com> <5491BAAF.7080809@alum.mit.edu> <5491C77F.5090904@cisco.com> <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01E06@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01E06@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419006715; bh=O9bAb9aAjhg4nz1QgahZUzgITSwVRux5V1mCsHZ1iu4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JzdNcOAMPB5Ssmt62lFIlbALQ00suBmgZubDluRfUg6bpP7JajPZ06I2123q14E04 vWqty7Q7aeHMgmMzK3BYZzS5qn7MtPqcQu3ZgIlve+XXdPvQmLyFVcdVnbsyFaz0Qq ZBAXyrpHaceaccY+SfYdLfTdXM+AYxrT9PBCfwwaX4RH/4UytCMMxY6Smg1r6e4CpI jarKgkjZI15umAOk+JDmkFJ0fAX8ruTXjn7pMB72Vgl2SlBMQWnVjX+qeTL4sQohPV KmxsOPaXmVsOmoGyMsjuE6MMitJj5sF1ZvDdpZMHbN0OoGOTrKB9Q0vyXL7HAYKtTE iAQvJtMEIduMQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/AnKa0GDNrSLCCg2JSk1b7Lh1W_Q Subject: Re: [clue] CLUE signaling document queation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Dec 2014 16:31:58 -0000 On 12/19/14 9:40 AM, Duckworth, Mark wrote: > Is there a need for two definitions, then? > CLUE-capable - understands CLUE, uses the feature tag, but not necessarily wanting to use CLUE at the moment. > CLUE-supporting - CLUE-capable and currently desiring to use CLUE (this is the current definition of CLUE-capable in the signaling draft) > > Or did I get them backwards from Rob's suggestion? We had a discussion about this a couple of months ago. Here is a link to it: http://mailarchive.ietf.org/arch/msg/clue/5NAMhg2HUfISUvGpBQogRtpAiR8 I made the following proposal there: > ISTM the following are different states a *device* may be in: > > - is entirely clueless. It hasn't included the clue feature tag or > the clue group. This is already defined as a Non-CLUE device. > > - it is aware of clue, but is unable or unwilling to use CLUE right now. > It has included the clue feature tag, but not the clue group. Or else > it has included the clue group but not included any SCTP m-line in > the clue group. Perhaps this could be called CLUE-aware but > CLUE-disabled. > > - it is aware of clue, and wishes to use it. It has included the clue > feature tag, and the clue group, and has included an SCTP m-line > in the clue group. Perhaps we can call this a CLUE-enabled device. > (This doesn't mean the *call* is CLUE-enabled.) > > Note that this is distinct from the state of the call. You can have a clue-enabled *device* yet not have a clue-enabled *call* - both ends must be clue-enabled before the call is. Thanks, Paul > I agree with Christer's suggestion to put the definition in just one document, and reference it from others. Keeping these in the framework is okay with me. > > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen >> Sent: Wednesday, December 17, 2014 1:12 PM >> To: clue@ietf.org >> Subject: Re: [clue] CLUE signaling document queation >> >> So maybe what we need to change is the "CLUE-capable" definition (which >> currently means "capable and willing", which I agree isn't intuitive) to >> something like "CLUE-supporting"? >> >> Rob >> >> On 17/12/14 17:17, Paul Kyzivat wrote: >>> On 12/17/14 10:05 AM, Robert Hansen wrote: >>>> My understanding is that the two views aren't entirely compatible, >>>> unless there's something I've not understood. >>>> >>>> I agree with Paul, that the feature tag should indicate that an >>>> understanding of CLUE, but not necessarily a desire to do it, and hence >>>> isn't sufficient to define a device as CLUE-capable. >>> >>> This highlights the terminology issues. We have described 'sip.clue' >>> as a feature tag, which is indeed one name for it. But in RFC3840/3841 >>> is called a callee *capability* (in contrast to a caller preference). >>> Using that terminology something that includes sip.clue is clearly >>> *capable* of clue, though it may not always be willing. >>> >>> Offering to negotiate the clue channel indicates that it is also >>> *willing* to use clue. >>> >>> Thanks, >>> Paul >>> >>>> Rob >>>> >>>> On 17/12/14 09:19, Xiaojing (Lennard) wrote: >>>>> Hi Roni, >>>>> >>>>> I agree with you and Paul. >>>>> CLUE-capable doesn't necessarily mean CLUE-preferable. >>>>> >>>>> Best regards, >>>>> Lennard >>>>> >>>>>> -----Original Message----- >>>>>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>>>> Sent: Wednesday, December 17, 2014 1:15 PM >>>>>> To: clue@ietf.org >>>>>> Subject: Re: [clue] CLUE signaling document queation >>>>>> >>>>>> On 12/16/14 2:12 PM, Roni Even wrote: >>>>>>> Hi, >>>>>>> >>>>>>> During the framework WGLC we had a discussion about what is an >>>>>> endpoint >>>>>>> that supports CLUE. The conclusion was to defer it to the signaling >>>>>>> document. >>>>>>> >>>>>>> Both the framework and the signaling have the following term >>>>>>> >>>>>>> CLUE-capable device: A device that supports the CLUE data channel [I- >>>>>> D.ietf-clue-datachannel >>>>> framework-19#ref-I-D.ietf-clue-datachannel>], the CLUE protocol [I- >>>>>> D.ietf-clue-protocol] and the principles of CLUE negotiation, and >>>>>> wishes to upgrade the call to CLUE-enabled status. >>>>>>> Yet we also have the media feature tag - sip.clue that according to >>>>>> section 3 of the signaling draft indicates support for CLUE. It also >>>>>> says "Presence of the media feature tag in the contact field of a >>>>>> request or response can be used to determine that the far end >> supports >>>>>> CLUE." >>>>>>> So if an endpoint gets an invite with the feature tag and no CLUE >>>>>> data >>>>>>> channel is this a CLUE capable endpoint. >>>>>>> >>>>>>> The interesting case is if the INVITE included the feature tag and >>>>>> the >>>>>>> CLUE data channel and the response rejected the channel but had the >>>>>>> feature tag, is the remote end point CLUE capable, is it allowed to >>>>>>> reject the data channel but have the feature tag? >>>>>>> >>>>>>> My view is that it is enough to have the feature tag to call an >>>>>> endpoint >>>>>>> CLUE capable, other views? >>>>>> My take is that that the feature tag indicates that the endpoint >>>>>> *understands* CLUE, and is capable of using CLUE if it wishes. But it >>>>>> doesn't necessarily mean that it always wants to use CLUE - it may >>>>>> choose not to in some cases. For instance a mobile endpoint might >>>>>> choose >>>>>> not to use CLUE when it has a poor wireless connection. >>>>>> >>>>>> Thanks, >>>>>> Paul >>>>>> >>>>>> _______________________________________________ >>>>>> clue mailing list >>>>>> clue@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/clue >>>>> _______________________________________________ >>>>> clue mailing list >>>>> clue@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>>> _______________________________________________ >>>> clue mailing list >>>> clue@ietf.org >>>> https://www.ietf.org/mailman/listinfo/clue >>>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Dec 22 07:23:41 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBBF1A90D1 for ; Mon, 22 Dec 2014 07:23:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BF-G84RZwjRz for ; Mon, 22 Dec 2014 07:23:37 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.209]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63911A90FD for ; Mon, 22 Dec 2014 07:23:37 -0800 (PST) Received: from [216.82.241.100] by server-17.bemta-8.messagelabs.com id EA/50-13532-87738945; Mon, 22 Dec 2014 15:23:36 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-220.messagelabs.com!1419261599!17048664!3 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21458 invoked from network); 22 Dec 2014 15:20:11 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-10.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2014 15:20:11 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 22 Dec 2014 07:20:03 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 22 Dec 2014 07:20:01 -0800 Thread-Topic: example of CLUE exchange without SDP offer/answer Thread-Index: AdAd+SGu4HUumDK4QpmHFSTalhNjgQ== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9@CRPMBOXPRD08.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_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-wyAoLzk5kZoNpAR0DFHwIObywA Subject: [clue] example of CLUE exchange without SDP offer/answer X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 15:23:40 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comment from Rob about this passage in framework section 5: "During the lifetime of a call, further exchanges MAY occur over the CLUE c= hannel. In some cases, those further exchanges lead to a modified system b= ehavior of Provider or Consumer (or both) without any other protocol activi= ty such as further offer/answer exchanges. For example, voice-activated sc= reen switching, signaled over the CLUE channel, ought not to lead to heavy-= handed mechanisms like SIP re-invites." >From Rob's WGLC comments: >Section 5. page 13: >"For example, voice-activated screen switching, signaled over the CLUE cha= nnel, ought not to" >- was a bit confused by this; does this mean an MCC noted as voice-switche= d, or actually >somehow signalling which participant is currentl the active speaker via CL= UE (and if the latter, >how do we do that)? My guess is that this relates to behaviour that is now= available at the RTP >level instead. This is intended to be an example of something that could be done using CLU= E signaling, which then affects the RTP streams, but does not require SDP c= hanges. I agree with Rob it is not a good example, because I can't think o= f anything about "voice activated screen switching" that fits this scenario= . I suggest replacing this with a different example. Proposed new text: "For example, a Configure Message requesting the Provider to place a differ= ent Capture source into a Capture Encoding, signaled over the CLUE channel,= ought not to ..." Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comment from Rob= about this passage in framework section 5:

 

“During the lifetime of= a call, further exchanges MAY occur over the CLUE channel.  In some c= ases, those further exchanges lead to a modified system behavior of Provide= r or Consumer (or both) without any other protocol activity such as further= offer/answer exchanges.  For example, voice-activated screen switchin= g, signaled over the CLUE channel, ought not to lead to heavy-handed mechan= isms like SIP re-invites.”

&n= bsp;

From Rob’s WGLC comments:

 

>Se= ction 5. page 13:

>"For example,= voice-activated screen switching, signaled over the CLUE channel, ought no= t to"

>- was a bit confused by = this; does this mean an MCC noted as voice-switched, or actually

>somehow signalling which participant is curre= ntl the active speaker via CLUE (and if the latter,

>how do we do that)? My guess is that this relates to behav= iour that is now available at the RTP

&= gt;level instead.

 

<= p class=3DMsoNormal>This is intended to be an example of something that cou= ld be done using CLUE signaling, which then affects the RTP streams, but do= es not require SDP changes.  I agree with Rob it is not a good example= , because I can’t think of anything about “voice activated scre= en switching” that fits this scenario.

 

I suggest replacing this wit= h a different example.  Proposed new text:

“For example, a Configure Message requesting the Provider to = place a different Capture source into a Capture Encoding, signaled over the= CLUE channel, ought not to ...”

=  

Mark

<= /html>= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01EE9CRPMBOXPRD08p_-- From nobody Mon Dec 22 09:27:09 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A351A1B7E for ; Mon, 22 Dec 2014 09:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0tvM1vepwEN for ; Mon, 22 Dec 2014 09:27:05 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.109]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44A41A1B48 for ; Mon, 22 Dec 2014 09:27:04 -0800 (PST) Received: from [216.82.254.19] by server-13.bemta-7.messagelabs.com id F0/00-02788-86458945; Mon, 22 Dec 2014 17:27:04 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-4.tower-96.messagelabs.com!1419269223!18264846!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8394 invoked from network); 22 Dec 2014 17:27:03 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-4.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2014 17:27:03 -0000 Received: from PWEHUB01.polycom.com (10.236.2.221) by Crpehubprd01.polycom.com (10.236.0.158) with Microsoft SMTP Server (TLS) id 8.3.192.1; Mon, 22 Dec 2014 09:27:02 -0800 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by PWEHUB01.polycom.com ([fe80::99a8:f785:3f0c:2bb6%17]) with mapi; Mon, 22 Dec 2014 09:27:02 -0800 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 22 Dec 2014 09:23:44 -0800 Thread-Topic: Consumer choosing subset of Captures from MCC Thread-Index: AdAeCkbfS54buis8QqCHMRr6XUgotA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.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_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xS5alRWTsC6y6P8N6zOwwd3WIis Subject: [clue] Consumer choosing subset of Captures from MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 17:27:08 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We discussed this at the design team meeting last week. See Rob's email fr= om December 15. The issue is we think the Provider should not be required = to honor a request in a Configure message to use only specific Captures in = an MCC. Does the group agree with this proposed change? Current text in the framework: - The Consumer may or may not choose to receive all the indicated Captures.= Therefore it can choose to receive a sub-set of Captures indicated by the= MCC. For example if the Consumer receives: MCC1(VC1,VC2,VC3){attributes} A Consumer could choose all the Captures within a MCCs however if the Consu= mer determines that it doesn't want VC3 it can return MCC1(VC1,VC2). If it= wants all the individual Captures then it returns only the MCC identity (i= .e. MCC1). If the MCC in the advertisement does not reference any individu= al captures, then the Consumer cannot choose what is included in the MCC, i= t is up to the Provider to decide. Proposed new text in the framework: - The Consumer may or may not request to receive all the indicated Captures= . Therefore it can request to receive a sub-set of Captures indicated by t= he MCC. For example if the Consumer receives an Advertisement with: MCC1(VC1,VC2,VC3){attributes} A Consumer could choose all the Captures within the MCC, however if the Con= sumer determines that it doesn't want VC3 it can return MCC1(VC1,VC2) in th= e Configure message. This is just a suggestion to the Provider. The Provid= er MAY consider this suggestion when deciding which Captures to include in = the MCC Capture Encoding it sends to the Consumer. If the Consumer wants al= l the individual Captures then it returns only the MCC identity (i.e. MCC1)= . If the MCC in the advertisement does not reference any individual captur= es, then the Consumer cannot choose what is included in the MCC, it is up t= o the Provider to decide. Another possibility is to add a new MCC attribute in the advertisement, so = the Provider can indicate whether or not it will accept requests asking for= only a subset of captures in an MCC. Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

We discussed this at the design team meeting last week.  See Rob= 217;s email from December 15.  The issue is we think the Provider shou= ld not be required to honor a request in a Configure message to use only sp= ecific Captures in an MCC.  Does the group agree with this proposed ch= ange?

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"'>Current = text in the framework:

- The Consumer may or may not= choose to receive all the indicated Captures.  Therefore it can choos= e to receive a sub-set of Captures indicated by the MCC.<= /p>

For example if the Consumer receives:

 &nb= sp;      MCC1(VC1,VC2,VC3){attributes}<= /span>

A Consumer could choose all the Captures within a MCCs however = if the Consumer determines that it doesn't want VC3 it can return MCC1(VC1,= VC2).  If it wants all the individual Captures then it returns only th= e MCC identity (i.e. MCC1).  If the MCC in the advertisement does not = reference any individual captures, then the Consumer cannot choose what is = included in the MCC, it is up to the Provider to decide.<= /p>

Proposed new text in the framewo= rk:

- The Consumer may or may not request to receive= all the indicated Captures.  Therefore it can request to receive a su= b-set of Captures indicated by the MCC.

For example = if the Consumer receives an Advertisement with:

&nbs= p;       MCC1(VC1,VC2,VC3){attributes}

A Consumer could choose all the Captures within the MCC, h= owever if the Consumer determines that it doesn't want VC3 it can return MC= C1(VC1,VC2) in the Configure message. This is just a suggestion to the Prov= ider.  The Provider MAY consider this suggestion when deciding which C= aptures to include in the MCC Capture Encoding it sends to the Consumer. If= the Consumer wants all the individual Captures then it returns only the MC= C identity (i.e. MCC1).  If the MCC in the advertisement does not refe= rence any individual captures, then the Consumer cannot choose what is incl= uded in the MCC, it is up to the Provider to decide.

<= p class=3DMsoNormal style=3D'margin-left:0in'>Another possibility is to add a new = MCC attribute in the advertisement, so the Provider can indicate whether or= not it will accept requests asking for only a subset of captures in an MCC= .

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

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36CRPMBOXPRD08p_-- From nobody Mon Dec 22 12:41:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E2F1A6F8D for ; Mon, 22 Dec 2014 12:41:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gds_9LkUtcSt for ; Mon, 22 Dec 2014 12:40:59 -0800 (PST) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B6BC1A6F45 for ; Mon, 22 Dec 2014 12:40:59 -0800 (PST) Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-08v.sys.comcast.net with comcast id WkfN1p0022Ka2Q501kgyPP; Mon, 22 Dec 2014 20:40:58 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-11v.sys.comcast.net with comcast id Wkgy1p0033Ge9ey01kgybj; Mon, 22 Dec 2014 20:40:58 +0000 Message-ID: <5498820A.6000807@alum.mit.edu> Date: Mon, 22 Dec 2014 15:41:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01F36@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419280858; bh=fRJzFuC3luocaulPuFxq5rBVua0ANUepM45y2uBuPcQ=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=YNy5WDCKSq/c2qb+WKka2k36YBdlaiowYG4bIW7M9sYimwrw7U2rf8cghEAmP4Ta/ uQAvk52DncmdfPOQ8Vk/NyUJ2SNCGopD1LykTHp0qrwNdL62ZmGj3PnVNerDDTWcp5 IpLkfh48lmY8QZR02cQoy6sqT3DPC1cfT+fxDXUgs+8zkdMVk6W5jKKdry7XKQ3dPv EWKabiu7WJ8Pa4maJBX3HZ0INLMRtPPZQc76V/d35SLw25oecO/4TJ30Hfc896uO6r gFVOCNw1Ded4ROwXkszKhRkYxb03opxEk5YksnLxMQyUU4w3w8RJfLz00eRvlZNBET y+eHIQqSMKnZg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/qQihpb-XQPe8gTJboe0I2mAulxM Subject: Re: [clue] Consumer choosing subset of Captures from MCC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 20:41:01 -0000 (As individual) I support the proposed change. Thanks, Paul On 12/22/14 12:23 PM, Duckworth, Mark wrote: > We discussed this at the design team meeting last week. See Rob’s email > from December 15. The issue is we think the Provider should not be > required to honor a request in a Configure message to use only specific > Captures in an MCC. Does the group agree with this proposed change? > > Current text in the framework: > > - The Consumer may or may not choose to receive all the indicated > Captures. Therefore it can choose to receive a sub-set of Captures > indicated by the MCC. > > For example if the Consumer receives: > > MCC1(VC1,VC2,VC3){attributes} > > A Consumer could choose all the Captures within a MCCs however if the > Consumer determines that it doesn't want VC3 it can return > MCC1(VC1,VC2). If it wants all the individual Captures then it returns > only the MCC identity (i.e. MCC1). If the MCC in the advertisement does > not reference any individual captures, then the Consumer cannot choose > what is included in the MCC, it is up to the Provider to decide. > > Proposed new text in the framework: > > - The Consumer may or may not request to receive all the indicated > Captures. Therefore it can request to receive a sub-set of Captures > indicated by the MCC. > > For example if the Consumer receives an Advertisement with: > > MCC1(VC1,VC2,VC3){attributes} > > A Consumer could choose all the Captures within the MCC, however if the > Consumer determines that it doesn't want VC3 it can return MCC1(VC1,VC2) > in the Configure message. This is just a suggestion to the Provider. > The Provider MAY consider this suggestion when deciding which Captures > to include in the MCC Capture Encoding it sends to the Consumer. If the > Consumer wants all the individual Captures then it returns only the MCC > identity (i.e. MCC1). If the MCC in the advertisement does not > reference any individual captures, then the Consumer cannot choose what > is included in the MCC, it is up to the Provider to decide. > > Another possibility is to add a new MCC attribute in the advertisement, > so the Provider can indicate whether or not it will accept requests > asking for only a subset of captures in an MCC. > > Mark > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Dec 22 13:59:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C251C1A87D0 for ; Mon, 22 Dec 2014 13:59:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GN5eoh5h93pm for ; Mon, 22 Dec 2014 13:59:11 -0800 (PST) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34CB1A87D1 for ; Mon, 22 Dec 2014 13:59:11 -0800 (PST) Received: from [216.82.249.212] by server-1.bemta-12.messagelabs.com id 5E/23-02950-F2498945; Mon, 22 Dec 2014 21:59:11 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-9.tower-219.messagelabs.com!1419285550!14206273!1 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21126 invoked from network); 22 Dec 2014 21:59:10 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-9.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2014 21:59:10 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 22 Dec 2014 13:57:02 -0800 From: "Duckworth, Mark" To: Robert Hansen , "clue@ietf.org" Date: Mon, 22 Dec 2014 13:57:00 -0800 Thread-Topic: [clue] Framework WGLC Thread-Index: AdAYVjW4EZMqXoo3QEqbbd4XiLl3KAF20kYg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC0@CRPMBOXPRD08.polycom.com> References: <008f01d017b1$8bb2de70$a3189b50$@gmail.com> <548EBF08.8090900@cisco.com> In-Reply-To: <548EBF08.8090900@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/jEC8urV2F2prDJKyeV4erxhp4II Subject: Re: [clue] Framework WGLC X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 21:59:13 -0000 Hi Rob, I implemented most of your suggestions, and started new email threads for a= couple of them. You had one comment about being more clear the consumer can pick and choose= captures regardless of CSVs. I didn't change anything because section 7.3= Capture Scene already says "it can pick and choose Media Captures regardle= ss of how the Provider arranges them in Capture Scene Views." I left the multiple encodings in the encoding group example because there a= re still multiple captures that refer to the same encoding group, so it is = still possible to use more than one encoding from a group. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Robert Hansen > Sent: Monday, December 15, 2014 5:59 AM > To: clue@ietf.org > Subject: Re: [clue] Framework WGLC >=20 > Find my review attached. >=20 > Most of the time the document capitalises terms from the terminology, > but not always; at first I flagged these up whenever I noticed them but > I'm sure I missed some and by the end I realised that going through with > grep and 'find next' was going to be much quicker than correcting based > on my review anyway so I stopped. >=20 > Almost all of the issues are just nits with the language or requests for > clarifications; I'll repeat the two that I thought were contentious: >=20 > Section 7.2. page 22: > "A MCC MAY contain no references to other Captures to indicate that the > MCC contains content from multiple sources but no information regarding > those sources is given." - We don't specify if an MCC containing 1 or > more defined captures may also contain undefined captures. My personal > choice would be no - advertised MCCs either contain the defined captures > and no others, or have no defined captures and contain only undefined > ones. If there are good reasons that any MCC with defined captures also > needs to contain potentially undefined ones that's fine too but we > should spell it out. >=20 > Section 10. page 39: > "The Consumer may or may not choose to receive all the indicated > captures. Therefore it can choose to receive a sub-set ofCaptures > indicated by the MCC." - this allowance means that any device that > provides an MCC and defines the captures it contains is required to > allow any subset of those captures to be chosen bv the consumer. Often > the reason the provider is providing an MCC initially is because it > cannot supply all the captures directly; unless it has the resources to > provide a unique subset of each capture (eg, switched view or custom > composition) it will be forced to ot include the contained captures in > the MCC, removing the value of having an MCC in the first place. > Depending on the clarification to the question on page 22 (whether an > MCC with defined captures can also contain undefined captures) the > consumer may still be receiving captures it hasn't specified. My > preference would be to remove this degree of freedom on the consumer > side, or at least make it a suggestion to the provider rather than a > mandatory restriction. There should also be a space in "ofCaptures". >=20 > Rob From nobody Mon Dec 22 14:13:34 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 831FF1AC410 for ; Mon, 22 Dec 2014 14:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QgIMcSWeHRRv for ; Mon, 22 Dec 2014 14:13:29 -0800 (PST) Received: from mail1.bemta8.messagelabs.com (mail1.bemta8.messagelabs.com [216.82.243.203]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBA31AC40F for ; Mon, 22 Dec 2014 14:13:29 -0800 (PST) Received: from [216.82.241.100] by server-11.bemta-8.messagelabs.com id 36/E8-15135-88798945; Mon, 22 Dec 2014 22:13:28 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-8.tower-220.messagelabs.com!1419286405!15065691!3 X-Originating-IP: [140.242.64.154] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 16932 invoked from network); 22 Dec 2014 22:13:27 -0000 Received: from crpehubprd02.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.154) by server-8.tower-220.messagelabs.com with AES128-SHA encrypted SMTP; 22 Dec 2014 22:13:27 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Mon, 22 Dec 2014 14:10:55 -0800 From: "Duckworth, Mark" To: "pkyzivat@alum.mit.edu" , "clue@ietf.org" , "Stephan Wenger (stewe@stewe.org)" Date: Mon, 22 Dec 2014 14:10:54 -0800 Thread-Topic: Can CLUE signaling help reduce size of SDP? Thread-Index: AdAeM+bVvJCWUiiPTsKFlo1aqiqeAQ== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4@CRPMBOXPRD08.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_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/YnTw0zN3gFwZDuwRS_EVrI-ApAY Subject: [clue] Can CLUE signaling help reduce size of SDP? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Dec 2014 22:13:32 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable >From Paul's comments on the framework: > Section 5: > > I'm struggling to understand the following paragraph: > > Second, it MAY, but is not necessarily REQUIRED to, use the > information provided to tailor the SDP it is going to send during > the following SIP offer/answer exchange, and its reaction to SDP it > receives in that step. It is often a sensible implementation > choice to do so, as the representation of the media information > conveyed over the CLUE channel can dramatically cut down on the > size of SDP messages used in the O/A exchange that follows. > Spatial relationships associated with the Media can be included in > the Advertisement, and it is often sensible for the Media Consumer > to take those spatial relationships into account when tailoring the > SDP. > > This seems to me to say that the consumer can use the advertisement to > reduce the size of the sdp, which isn't really true. I think the problem > is that this text doesn't distinguish between what is done by providers > and consumers. > > For a provider, it may well be infeasible to send SDP covering every > encoding in the advertisement. It could potentially reduce the size of > SDP to a more manageable size by only offering those encodings that are > configured. BUT, as we have things structured now a consumer needs to > see the encodings in the SDP to decide what to configure. So this > potential can't be realized. > > For a consumer the potential is not to reduce the size of SDP, but > rather to reduce the number of encodings it must set up resources to > receive. It probably doesn't want to receive encodings that it doesn't > intend to use. I think this is the key point to make in this paragraph. > > (These comments also apply the the following paragraph.) I thought I understood this idea of reducing the SDP size, but now I can't recall the details of that. I think Stephan wrote these paragraphs. Stephan, can you explain what the intent was here? Thanks, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

From Paul’= s comments on the framework:

 =

> Section 5:

>

> I'm strugglin= g to understand the following paragraph:

>

>    &nbs= p;Second, it MAY, but is not necessarily REQUIRED to, use the

>     information provided = to tailor the SDP it is going to send during

>     the following SIP offer/answer exchang= e, and its reaction to SDP it

> &n= bsp;   receives in that step.  It is often a sensible i= mplementation

>    =  choice to do so, as the representation of the media information<= /o:p>

>     conveyed over= the CLUE channel can dramatically cut down on the

>     size of SDP messages used in t= he O/A exchange that follows.

> &n= bsp;   Spatial relationships associated with the Media can b= e included in

>    =  the Advertisement, and it is often sensible for the Media Consumer

>     to take th= ose spatial relationships into account when tailoring the

>     SDP.

>

> This see= ms to me to say that the consumer can use the advertisement to

> reduce the size of the sdp, which isn't real= ly true. I think the problem

> is = that this text doesn't distinguish between what is done by providers

> and consumers.

>

> For a prov= ider, it may well be infeasible to send SDP covering every

> encoding in the advertisement. It could potentia= lly reduce the size of

> SDP to a = more manageable size by only offering those encodings that are

> configured. BUT, as we have things structure= d now a consumer needs to

> see th= e encodings in the SDP to decide what to configure. So this

<= p class=3DMsoPlainText>> potential can't be realized.

>

> For a = consumer the potential is not to reduce the size of SDP, but

=

> rather to reduce the number of encodings it mu= st set up resources to

> receive. = It probably doesn't want to receive encodings that it doesn't

> intend to use. I think this is the key point = to make in this paragraph.

> =

> (These comments also apply the the f= ollowing paragraph.)

 

I thought I understood this idea of reducing the SDP= size, but now I

can’t recall the= details of that.  I think Stephan wrote these paragraphs.<= /p>

 

Stephan, = can you explain what the intent was here?

 

Thanks,
Mark

<= p class=3DMsoNormal> 

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FC4CRPMBOXPRD08p_-- From nobody Mon Dec 22 16:10:53 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34D111A88A3 for ; Mon, 22 Dec 2014 16:10:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rmHcP_wN924V for ; Mon, 22 Dec 2014 16:10:51 -0800 (PST) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.104]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2826F1A8931 for ; Mon, 22 Dec 2014 16:10:51 -0800 (PST) Received: from [216.82.254.20] by server-8.bemta-7.messagelabs.com id AE/D8-03121-A03B8945; Tue, 23 Dec 2014 00:10:50 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-14.tower-47.messagelabs.com!1419293449!15947974!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.12.5; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29404 invoked from network); 23 Dec 2014 00:10:50 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-14.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 23 Dec 2014 00:10:50 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([::1]) with mapi; Mon, 22 Dec 2014 16:10:50 -0800 From: "Duckworth, Mark" To: Paul Kyzivat Date: Mon, 22 Dec 2014 16:10:48 -0800 Thread-Topic: video capture volume? Thread-Index: AdAeRJx1JRwoflM9S0SXAQ057MCxbA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FDE@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bZsgnzYVV_ailzBnzUQR6jxNFBo Cc: "clue@ietf.org" Subject: [clue] video capture volume? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 00:10:52 -0000 Hi Paul, >From your WGLC comments: > Section 7.1.1.3: >=20 > It might be helpful to point out that typically a video capture > represents a capture volume that is defined by a pyramid connecting the > point of capture to the area of capture. Not really, because it can extend further back than the plane of interest, potentially to infinity. Can we just leave the text as is, or do you think= a different clarification is necessary? Mark From nobody Tue Dec 23 07:28:32 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91F0B1ACF54 for ; Tue, 23 Dec 2014 07:28:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PTtjUNWgn83m for ; Tue, 23 Dec 2014 07:28:27 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD3F1ACF1A for ; Tue, 23 Dec 2014 07:28:27 -0800 (PST) Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-11v.sys.comcast.net with comcast id X3Tp1p00327uzMh013USAs; Tue, 23 Dec 2014 15:28:26 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-02v.sys.comcast.net with comcast id X3UR1p00H3Ge9ey013URju; Tue, 23 Dec 2014 15:28:26 +0000 Message-ID: <54998A19.2090306@alum.mit.edu> Date: Tue, 23 Dec 2014 10:28:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" References: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FDE@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F968DC01FDE@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419348506; bh=hxecDp8RcXXISLNrcmxuVaUGHk1aJjpdC9tC2UUe5eM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=TmOgAzGhPiQe39GTjIBoBiUWkbK30qbzKLv0xCJpM+19K3LZA04v/r1QtYPR42Wr7 eo9OahlTR9O6yc9Jn2PqEJb/Tlf1TRy/kqX7jOiVwWBxcAc0uqKiF33UagRM0ix8Oi KgoxjUCDNy8nxCZRvgKv2Py2qeDbNxXEAU5TrcETOHWYVOfuSEGAkEj0bIfGskN3w8 IszVxcpCB/UpZOX0qih4dUWum7xXPElTsErfqy5kTJs5He/iBgzUyQ4/R2bOl0EL9t X5a7iYrY2njjrkzs5gDLgnC4XgqDeh8ToxYtNKFq+MUsTnifqoFZpAVtkdry97y8Xb 9ZZv6hH0uObCw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/o3MQKIuKnEw8B19kbSpzUz-fDMI Cc: "clue@ietf.org" Subject: Re: [clue] video capture volume? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Dec 2014 15:28:28 -0000 On 12/22/14 7:10 PM, Duckworth, Mark wrote: > Hi Paul, > >>From your WGLC comments: > >> Section 7.1.1.3: >> >> It might be helpful to point out that typically a video capture >> represents a capture volume that is defined by a pyramid connecting the >> point of capture to the area of capture. > > Not really, because it can extend further back than the plane of interest, > potentially to infinity. Can we just leave the text as is, or do you think a > different clarification is necessary? I thought that since you talk about the volume of capture for audio, it would be appropriate to also talk about volume of capture for video. Yes, the volume extends beyond the area of capture, not to infinity, but to the boundary of scene, whatever that is. Right now, section 7.1.1.2 talks about intersecting the area of capture for a video capture with the volume of capture for an audio capture. But is that really the right algorithm? Or should the the intersection be with the volume of capture of the video capture? Thanks, Paul From nobody Sun Dec 28 18:35:25 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A09C41ACCE2 for ; Sun, 28 Dec 2014 18:35:23 -0800 (PST) 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_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGHabBFUpnNJ for ; Sun, 28 Dec 2014 18:35:21 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0108.outbound.protection.outlook.com [65.55.169.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58C01ACC88 for ; Sun, 28 Dec 2014 18:35:20 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1274.namprd07.prod.outlook.com (25.160.149.17) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 02:35:19 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 02:35:19 +0000 From: Stephan Wenger To: CLUE Thread-Topic: Framework, level of mandation for providing dimensions Thread-Index: AQHQIxAV+8GIBcejdUedMqVY6uAHpg== Date: Mon, 29 Dec 2014 02:35:18 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1274; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(199003)(479174004)(189002)(99286002)(54356999)(50986999)(62966003)(77156002)(40100003)(122556002)(20776003)(102836002)(101416001)(36756003)(2900100001)(64706001)(68736005)(97736003)(450100001)(120916001)(106116001)(46102003)(66066001)(107046002)(21056001)(87936001)(16236675004)(107886001)(4396001)(2656002)(99396003)(110136001)(106356001)(105586002)(229853001)(86362001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0C5FDE14DE68stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 02:35:18.7261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1274 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/fkKsfJlJmnZWWvOFODEzZNXlnjI Subject: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 02:35:23 -0000 --_000_D0C5FDE14DE68stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Mark and I are editing the framework document to address comments. This is with reference to my review, dated 12/16/2014, and specifically poi= nt 4 therein, reproduced as follows: 4. Page 15, MUST strength for providing physical dimensions of known to the= system. I like this philosophically, but I think it's meaningless in prac= tice, as the knowledge of coordinates of a pProvider is known to the consum= er only as a side effect of sending the measurements, right? Perhaps less= draconian language is more appropriate? Sounds to me like a good place fo= r a "SHOULD"? Unless someone objects the two MUST statements in section 6, second bullet = (page 15) will be replaced with less draconian SHOULD. The modified bullet= in markup is shown below. I suggest a deadline of January 9, 2015, but do so without checking with th= e chairs-who are of course free to set a different date if they choose so. Regards, Stephan o Coordinates can be either in real, physical units (millimeters), have an unknown scale or have no physical scale. Systems which know their physical dimensions (for example professionally installed Telepresence room systems) MUST SHOULD always provide those real-world measurements. Systems which don't know specific physical dimensions but still know relative distances MUST SHOULD use 'unknown scale'. 'No scale' is intended to be used where Media Captures from different devices (with potentially different scales) will be forwarded alongside one another (e.g. in the case of an MCU). --_000_D0C5FDE14DE68stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <268140086CAAE14F97CD351604CCD55D@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,

Mark and I are editing the framework document to address comments.
This is with reference to my review, dated 12/16/2014, and specifically poi= nt 4 therein, reproduced as follows:

4. Page 15, MUST strength for provid= ing physical dimensions of known to the system.  I like this philosoph= ically, but I think it’s meaningless in practice, as the knowledge of= coordinates of a pProvider is known to the consumer only as a side effect of sending  the measurements, right?  Perh= aps less draconian language is more appropriate?  Sounds to me like a = good place for a “SHOULD”?

Unless someone objects the two MUST = statements in section 6, second bullet (page 15) will be replaced with less= draconian SHOULD.  The modified bullet in markup is shown below.

I suggest a deadline of January 9, 2015, but do so without checki= ng with the chairs—who are of course free to set a different date if = they choose so.
 
Regards,
Stephan

 o  Coordinate=
s can be either in real, physical units (millimeters),
      have an unknown scale or have no physical scale.  Systems which
      know their physical dimensions (for example professionally
      installed Telepresence room systems) MUST SHOULD<=
/u> always provide those
      real-world measurements.  Systems which don't know specific
      physical dimensions but still know relative distances MUST SHOULD use
      'unknown scale'.  'No scale' is intended to be used where Media
      Captures from different devices (with potentially different
      scales) will be forwarded alongside one another (e.g. in the
      case of an MCU).
--_000_D0C5FDE14DE68stewesteweorg_-- From nobody Sun Dec 28 18:41:35 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A31E1AC3C2 for ; Sun, 28 Dec 2014 18:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KiSpIIYcnp9x for ; Sun, 28 Dec 2014 18:41:29 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0719.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:719]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 577701A1B1B for ; Sun, 28 Dec 2014 18:41:29 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1275.namprd07.prod.outlook.com (25.160.149.18) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 02:41:05 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 02:41:05 +0000 From: Stephan Wenger To: CLUE Thread-Topic: CLUE framework, section 7.1.1.9, "Languages" Thread-Index: AQHQIxDkFwkb3UMYnU+QJuLRgzXsmg== Date: Mon, 29 Dec 2014 02:41:04 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1275; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1275; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(164054003)(199003)(189002)(479174004)(66066001)(97736003)(561944003)(50986999)(122556002)(16236675004)(46102003)(15187005004)(120916001)(19580395003)(54356999)(86362001)(64706001)(110136001)(99396003)(40100003)(4396001)(101416001)(87936001)(19625215002)(21056001)(450100001)(62966003)(105586002)(77156002)(102836002)(106116001)(2656002)(229853001)(20776003)(107046002)(107886001)(99286002)(36756003)(2900100001)(106356001)(68736005)(42262002)(579004)(559001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1275; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0C5FF364DE75stewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 02:41:04.9764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1275 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/WioJYAGPzM_YYci6Ko5uIQpfBUk Subject: [clue] CLUE framework, section 7.1.1.9, "Languages" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 02:41:33 -0000 --_000_D0C5FF364DE75stewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Mark and I are editing the framework document to address comments. This is with reference to my review, dated 12/16/2014, and specifically poi= nt 5 therein, reproduced as follows: 5. Page 20, Languages: is this coded using a universal language tag? If ye= s, should that be mentioned here, with reference? The proposal is to indicate that an RFC 5646 language tag is used here. Is= this ok? Is it aligned with the current data model and, if not, should t= he data model implement that? Proposed language below. Plus a normative reference to RFC 5646, of course= . I suggest a deadline of January 9, 2015, but do so without checking with th= e chairs-who are of course free to set a different date if they choose so. Thanks, Stephan 7.1.1.9 Language The Language attribute indicates one or more languages used in the content = of the Media Capture. Captures MAY be offered in different languages in ca= se of multilingual and/or accessible conferences. A Consumer can use this = attribute to differentiate between them and pick the appropriate one. Note that the Language attribute is defined and meaningful both for audio a= nd video captures. In case of audio captures, the meaning is obvious. For= a video capture, "Language" could, for example, be sign interpretation or = text. The Language attribute is coded per [RFC5646]. --_000_D0C5FF364DE75stewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

Mark and I are editing the framework document to address comments.
This is with reference to my review, dated 12/16/2014, and specificall= y point 5 therein, reproduced as follows:

5. Page 20, Languages: is this coded= using a universal language tag?  If yes, should that be mentioned her= e, with reference?

The proposal is to indicate that an = RFC 5646 language tag is used here.  Is this ok?   Is it aligned = with the current data model and, if not, should the data model implement th= at?

Proposed language below. &= nbsp;Plus a normative reference to RFC 5646, of course.  

I suggest a deadline of January 9, 2015, but do so without checki= ng with the chairs—who are of course free to set a different date if = they choose so.

Thanks,
Stephan

7.1.1.9 Language

The Language attribute= indicates one or more languages used in the content of the Media Capture.&= nbsp; Captures MAY be offered in different languages in case of multilingua= l and/or accessible conferences.  A Consumer can use this attribute to differentiate between them and pick the appropri= ate one.

Note that the Language= attribute is defined and meaningful both for audio and video captures.&nbs= p; In case of audio captures, the meaning is obvious.  For a video cap= ture, "Language" could, for example, be sign interpretation or text.

The Language attrib= ute is coded per [RFC5646].

--_000_D0C5FF364DE75stewesteweorg_-- From nobody Sun Dec 28 18:51:52 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 719041ACC88 for ; Sun, 28 Dec 2014 18:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Y3I47DNC7sr for ; Sun, 28 Dec 2014 18:51:47 -0800 (PST) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0148.outbound.protection.outlook.com [207.46.100.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 750971ACC86 for ; Sun, 28 Dec 2014 18:51:47 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1274.namprd07.prod.outlook.com (25.160.149.17) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 02:51:46 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 02:51:46 +0000 From: Stephan Wenger To: CLUE Thread-Topic: CLUE framework, security consideration section, level of mandation Thread-Index: AQHQIxJis4e/EPHw4E6XfSjfzoJvOQ== Date: Mon, 29 Dec 2014 02:51:46 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1274; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(479174004)(107046002)(107886001)(87936001)(21056001)(16236675004)(106116001)(66066001)(46102003)(86362001)(105586002)(229853001)(99396003)(2656002)(4396001)(106356001)(110136001)(122556002)(40100003)(54356999)(50986999)(99286002)(77156002)(62966003)(97736003)(68736005)(64706001)(120916001)(450100001)(101416001)(102836002)(20776003)(36756003)(2900100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: multipart/alternative; boundary="_000_D0C601BA4DE8Dstewesteweorg_" MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 02:51:46.0866 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1274 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/lWPfeKUysmXkh7wGEFN5hJHZ7GU Subject: [clue] CLUE framework, security consideration section, level of mandation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 02:51:50 -0000 --_000_D0C601BA4DE8Dstewesteweorg_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Mark and I are editing the framework document to address comments. This is with reference to my review, dated 12/16/2014, and specifically poi= nt 9 therein, reproduced as follows: 9. Page 70, first paragraphs. There are two unqualified "SHOULD" statement= s. In the spirit of fast doc approval, I wouldn't object if those were cha= nged to "MUST". I don't recall that we discussed these points before, but = I could easily have missed that discussion. Unless someone objects the two SHOULD statements will be replaced with MUST= . The modified paragraph in markup is shown below (also addressing comment= 8 of my review, but that's an editorial change and should be uncontroversi= al). Sorry for the messy formatting. I suggest a deadline of January 9, 2015, but do so without checking with th= e chairs-who are of course free to set a different date if they choose so. Regards, Stephan A separate data channel is established to transport the CLUE protocol messages. The contents of the CLUE protocol messages are based on information introduced in this document, which is represented by an XML schema for this information defined in the CLUE data model [ref]. The CLUE data model [I-D.ietf-clue-data-model-sc= hema] defines through an XML schema the syntax to be used. Some of the inf= ormation which could possibly introduce privacy concerns is the xCard infor= mation as described in section 7.1.1.11. In addition, the (text) description field in the Media Capture attribute (section 7.1.1.7) could possibly reveal sensitive information or specific identities. The same would be true for the descriptions in the Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) attributes. One other important consideration for the information in the xCard as well as the description field in the Media Capture and Capture Scene View attributes is that while the endpoints involved in the session have been authenticated, there is no assurance that the information in the xCard or description fields is authentic. Thus, this information SHOULD MUST not be used to make any authorization decisions and the participants in the sessions SHOULD MUST be made aware of this. --_000_D0C601BA4DE8Dstewesteweorg_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <7223E1C4D2B7874A9A55D6025BC375C9@namprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi,

Mark and I are editing the framework document to address comments.
This is with reference to my review, dated 12/16/2014, and specificall= y point 9 therein, reproduced as follows:

9. Page 70, first paragraphs.  There are two unqualified “S= HOULD” statements.  In the spirit of fast doc approval, I wouldn= ’t object if those were changed to “MUST”.  I don= 217;t recall that we discussed these points before, but I could easily have= missed that discussion.

Unl= ess someone objects the two SHOULD statements will be replaced with MUST. &= nbsp;The modified paragraph in markup is shown below (also addressing comme= nt 8 of my review, but that’= s an editorial change and should be uncontroversial).  Sorry for the messy formatting.=

I suggest a deadline of January 9= , 2015, but do so without checking with the chairs—who are of course = free to set a different date if they choose so.

Rega= rds,
Step= han


   A separate data channel is established to transport the CLUE
   protocol messages. The contents of the CLUE protocol messages are
   based on information introduced in this document, which is
   represented by an XML schema for this information defined in the
   CLUE data model [ref].  The CLUE data model =
[I-D.ietf-clue-data-model-schema] defines through=
 an XML schema the syntax to be used.  Some of the information which co=
uld possibly introduce privacy=
 concerns is the xCard information as described in section 7.1.1.11.  In addition, the (text)

   description field in the Media Capture attribute (section 7.1.1=
.7)
   could possibly reveal sensitive information or specific
   identities. The same would be true for the descriptions in the
   Capture Scene (section 7.3.1) and Capture Scene View (7.3.2)
   attributes.   One other important consideration for the
   information in the xCard as well as the description field in the
   Media Capture and Capture Scene View attributes is that while the
   endpoints involved in the session have been authenticated, there
   is no assurance that the information in the xCard or description
   fields is authentic.  Thus, this information SHOULD =
MUST not be used to
   make any authorization decisions and the participants in the
   sessions SHOULD MUST be made aware of this.
--_000_D0C601BA4DE8Dstewesteweorg_-- From nobody Mon Dec 29 02:46:23 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6FA1A00C5 for ; Mon, 29 Dec 2014 02:46:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hk6cm3HfT0r9 for ; Mon, 29 Dec 2014 02:46:17 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 154A51A00BB for ; Mon, 29 Dec 2014 02:46:17 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so21638654wib.10 for ; Mon, 29 Dec 2014 02:46:15 -0800 (PST) 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:thread-index:content-language; bh=9e6+de+cWVviq+Im7jTiUwKKCJ78LocEQ2qizg3sEMw=; b=A4mq+r61suxj1Tcjd54aMktn51bMH/TAYHIKIjG29Ri/5M2fKgw+B3+ZFOqwRL9H6r FBTzm5G6hAl2LVnE02U2WjuEy8rY6FcZXslEeB2gGilvwBmUDYT4kURq/0xxCNOt4nc8 m0NO9CTrylDYorwdQy0oonuhE1XQdN3F8q+gVxWXQEYIIJJ2dhlz/GmfDHnweRTPoUzp 5Ku5WzXtf4dNe1RXxg0Shszx3HIURx5qvHtdTWCSBfp0KdDY7otzBjfzb+6epXUmZQwv XQqwxhi1wUameQ+o0I9SvRNEEt2wS5u1B5iNbSEgxYguJJVLkY3RG8FDItBf+rk+LTVu EEyw== X-Received: by 10.194.86.135 with SMTP id p7mr109060281wjz.89.1419849975789; Mon, 29 Dec 2014 02:46:15 -0800 (PST) Received: from RoniE ([109.67.162.214]) by mx.google.com with ESMTPSA id u3sm38771367wiw.24.2014.12.29.02.46.13 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Dec 2014 02:46:15 -0800 (PST) From: "Roni Even" To: "'Stephan Wenger'" , "'CLUE'" References: In-Reply-To: Date: Mon, 29 Dec 2014 12:46:11 +0200 Message-ID: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B70_01D02365.6E6905F0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJoaKwpMXOVzCePmsyH4w3dRwsbv5t11nbg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/5AZAM8T22yaG393huCeB7Ru-l6g Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 10:46:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B70_01D02365.6E6905F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Stephan, I am not sure what is the difference here between a MUST and a SHOULD. Since it is required to send the scale value in the data model (https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section-15 .4 ), what is the SHOULD here? Roni Even As individual From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: 29 December, 2014 4:35 AM To: CLUE Subject: [clue] Framework, level of mandation for providing dimensions Hi, Mark and I are editing the framework document to address comments. This is with reference to my review, dated 12/16/2014, and specifically point 4 therein, reproduced as follows: 4. Page 15, MUST strength for providing physical dimensions of known to the system. I like this philosophically, but I think it's meaningless in practice, as the knowledge of coordinates of a pProvider is known to the consumer only as a side effect of sending the measurements, right? Perhaps less draconian language is more appropriate? Sounds to me like a good place for a "SHOULD"? Unless someone objects the two MUST statements in section 6, second bullet (page 15) will be replaced with less draconian SHOULD. The modified bullet in markup is shown below. I suggest a deadline of January 9, 2015, but do so without checking with the chairs-who are of course free to set a different date if they choose so. Regards, Stephan o Coordinates can be either in real, physical units (millimeters), have an unknown scale or have no physical scale. Systems which know their physical dimensions (for example professionally installed Telepresence room systems) MUST SHOULD always provide those real-world measurements. Systems which don't know specific physical dimensions but still know relative distances MUST SHOULD use 'unknown scale'. 'No scale' is intended to be used where Media Captures from different devices (with potentially different scales) will be forwarded alongside one another (e.g. in the case of an MCU). ------=_NextPart_000_0B70_01D02365.6E6905F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Stephan,

I am not sure what is the difference here between a MUST and a = SHOULD. Since it is required to send the scale value in the data model = (https://tools.ietf.org/html/draft-ietf-clue-data-model-sche= ma-07#section-15.4 ), what is the SHOULD here? =

 

Roni Even

As individual

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan = Wenger
Sent: 29 December, 2014 4:35 AM
To: = CLUE
Subject: [clue] Framework, level of mandation for = providing dimensions

 

Hi,

 

Mark and I are editing the framework document to address = comments.

This is with reference to my review, dated 12/16/2014, and specifically = point 4 therein, reproduced as = follows:

 

4. Page 15, MUST strength = for providing physical dimensions of known to the system.  I like = this philosophically, but I think it’s meaningless in practice, as = the knowledge of coordinates of a pProvider is known to the consumer = only as a side effect of sending  the measurements, right? =  Perhaps less draconian language is more appropriate?  Sounds = to me like a good place for a = “SHOULD”?

 

Unless someone objects the = two MUST statements in section 6, second bullet (page 15) will be = replaced with less draconian SHOULD.  The modified bullet in markup = is shown below.

 

I suggest a deadline = of January 9, 2015, but do so without checking with the chairs—who = are of course free to set a different date if they choose = so.

 

=

Regards,

Stephan

 

 o  =
Coordinates can be either in real, physical units =
(millimeters),
      have =
an unknown scale or have no physical scale.  Systems =
which
      know their =
physical dimensions (for example =
professionally
      =
installed Telepresence room systems) MUST SHOULD always =
provide those
   =
   real-world measurements.  Systems which don't =
know specific
      =
physical dimensions but still know relative distances MUST =
SHOULD use
      =
'unknown scale'.  'No scale' is intended to be used where =
Media
      Captures from =
different devices (with potentially =
different
      scales) =
will be forwarded alongside one another (e.g. in =
the
      case of an =
MCU).
------=_NextPart_000_0B70_01D02365.6E6905F0-- From nobody Mon Dec 29 03:02:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAE41A00E9 for ; Mon, 29 Dec 2014 03:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsCqDAq3e1Wd for ; Mon, 29 Dec 2014 03:01:58 -0800 (PST) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 297B71A00E8 for ; Mon, 29 Dec 2014 03:01:58 -0800 (PST) Received: by mail-wi0-f171.google.com with SMTP id bs8so21688072wib.4 for ; Mon, 29 Dec 2014 03:01:57 -0800 (PST) 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:thread-index:content-language; bh=TbR7l6L+kS6JE5aet+z85v158N3PppFsGlhCuigpnxc=; b=BGuZX6IbmhrxFDyFGOPV2utcXV3s0HFbuxykUEChCgZ0a9cJwPPzHyNFYAeTNk2vD7 185C9DOXfByJcycziHUAw/E+03+pNzVPquINK1hhStlslqqQ7MOLwhYCWI5jPvQ7iEkb Og/Tu1e6aqd29FcXXolRqyhLwjAexmMqJnKWJiXvHQeV9z9mN80LqtLdN5mfcGiiMq/E IwSohTMD9mwhAEL7FOvNRtoRZzX3m/2HcDKfuauozNwklNWYtQ1KW7icxab8FQexEgcl MnPwGU27TDvWN/YQeef/5CCflzqkJ4JgfR0DPmKBkfqVlykwwcnE9WI3CV3eWub3LY2Q kFVQ== X-Received: by 10.194.104.137 with SMTP id ge9mr105079823wjb.135.1419850916947; Mon, 29 Dec 2014 03:01:56 -0800 (PST) Received: from RoniE ([109.67.162.214]) by mx.google.com with ESMTPSA id b10sm39072033wiw.9.2014.12.29.03.01.54 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Dec 2014 03:01:56 -0800 (PST) From: "Roni Even" To: "'Stephan Wenger'" , "'CLUE'" References: In-Reply-To: Date: Mon, 29 Dec 2014 13:01:51 +0200 Message-ID: <0b7401d02356$db9418e0$92bc4aa0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B75_01D02367.9F1E6F80" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGQ294zykccPsZtERG1zRNx0y1vRJ0k9Zqg Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/aygPy9yP04T72hWdcipKNibrSVA Subject: Re: [clue] CLUE framework, section 7.1.1.9, "Languages" X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 11:02:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B75_01D02367.9F1E6F80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, This looks OK and the data model is using the XML language data type http://www.w3.org/TR/xmlschema11-2/#language which reference this RFC Roni Even As Individula From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: 29 December, 2014 4:41 AM To: CLUE Subject: [clue] CLUE framework, section 7.1.1.9, "Languages" Hi, Mark and I are editing the framework document to address comments. This is with reference to my review, dated 12/16/2014, and specifically point 5 therein, reproduced as follows: 5. Page 20, Languages: is this coded using a universal language tag? If yes, should that be mentioned here, with reference? The proposal is to indicate that an RFC 5646 language tag is used here. Is this ok? Is it aligned with the current data model and, if not, should the data model implement that? Proposed language below. Plus a normative reference to RFC 5646, of course. I suggest a deadline of January 9, 2015, but do so without checking with the chairs-who are of course free to set a different date if they choose so. Thanks, Stephan 1.1.1.1. 7.1.1.9 Language The Language attribute indicates one or more languages used in the content of the Media Capture. Captures MAY be offered in different languages in case of multilingual and/or accessible conferences. A Consumer can use this attribute to differentiate between them and pick the appropriate one. Note that the Language attribute is defined and meaningful both for audio and video captures. In case of audio captures, the meaning is obvious. For a video capture, "Language" could, for example, be sign interpretation or text. The Language attribute is coded per [RFC5646]. ------=_NextPart_000_0B75_01D02367.9F1E6F80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

This looks OK and the data model is using the XML language data type = http://www.w3.org/T= R/xmlschema11-2/#language which reference this = RFC

 

Roni Even

As Individula

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan = Wenger
Sent: 29 December, 2014 4:41 AM
To: = CLUE
Subject: [clue] CLUE framework, section 7.1.1.9, = "Languages"

 

Hi,

 

Mark and I are editing the framework document to address = comments.

This is with reference to my review, dated 12/16/2014, and specifically = point 5 therein, reproduced as = follows:

 

5. Page 20, Languages: is = this coded using a universal language tag?  If yes, should that be = mentioned here, with reference?

 

The proposal is to indicate = that an RFC 5646 language tag is used here.  Is this ok?   Is = it aligned with the current data model and, if not, should the data = model implement that?

 

Proposed language = below.  Plus a normative reference to RFC 5646, of course. =  

 

I suggest a deadline = of January 9, 2015, but do so without checking with the chairs—who = are of course free to set a different date if they choose = so.

 

Thanks,

Stephan

 

1.1.1.1. 7.1.1.9 Language

The Language attribute indicates one or more languages = used in the content of the Media Capture.  Captures MAY be offered = in different languages in case of multilingual and/or accessible = conferences.  A Consumer can use this attribute to differentiate = between them and pick the appropriate one.

Note that the Language attribute is defined and = meaningful both for audio and video captures.  In case of audio = captures, the meaning is obvious.  For a video capture, = "Language" could, for example, be sign interpretation or = text.

The Language attribute is = coded per [RFC5646].

------=_NextPart_000_0B75_01D02367.9F1E6F80-- From nobody Mon Dec 29 03:04:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13E4A1A00CA for ; Mon, 29 Dec 2014 03:03:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4y1VyW4UgUtk for ; Mon, 29 Dec 2014 03:03:52 -0800 (PST) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5C91A008A for ; Mon, 29 Dec 2014 03:03:51 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id r20so21643463wiv.0 for ; Mon, 29 Dec 2014 03:03:50 -0800 (PST) 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:thread-index:content-language; bh=Ik82xmANJSez3kQmbDuQv3bPMrauAcXWIXCZcewaiOc=; b=ZOZAJ7Mz5qpehrQBQnoqpJYlnkVF1UXF4+7Rbd9IpGqws8OM1FYgB/+ViYkv8ykrOo Vw9WoJVVlri5R8iTdgrHj6UOmYMCFDKGYQe2LPxJRf6cN5Np1WypZ8TOyGMVoUJcLohf F1uJa5mG9LLPDFusfuvc50FhTDJj+B4Ir1nvcBEuKyM+DSwc3llk7n46jya5r03XXL1W hAfIBiGKZlilVfydE2kDNWV6tzWUPKW9cuJfxzb+8TzmMR8zwAJrnBkOV6dndbAMGsxR BWpMxtwJcsD0xLFABPdWIrSlFjMLGOEzREdwIzhgVldy8/b+KOi5FJoAGCib6U+bnQte xXEw== X-Received: by 10.180.108.143 with SMTP id hk15mr96635045wib.6.1419851030427; Mon, 29 Dec 2014 03:03:50 -0800 (PST) Received: from RoniE ([109.67.162.214]) by mx.google.com with ESMTPSA id cp4sm49532549wjb.16.2014.12.29.03.03.48 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Dec 2014 03:03:49 -0800 (PST) From: "Roni Even" To: "'Stephan Wenger'" , "'CLUE'" References: In-Reply-To: Date: Mon, 29 Dec 2014 13:03:46 +0200 Message-ID: <0b7901d02357$1f819fa0$5e84dee0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0B7A_01D02367.E30BF640" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJhogQCXFicXjNGzE/ZQDR8hfPFvJuDahlQ Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/L92oHqComEbYP-SQ8b2EyIcLu48 Subject: Re: [clue] CLUE framework, security consideration section, level of mandation X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 11:03:59 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0B7A_01D02367.E30BF640 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, OK with this change Roni Even As individual From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger Sent: 29 December, 2014 4:52 AM To: CLUE Subject: [clue] CLUE framework, security consideration section, level of mandation Hi, Mark and I are editing the framework document to address comments. This is with reference to my review, dated 12/16/2014, and specifically point 9 therein, reproduced as follows: 9. Page 70, first paragraphs. There are two unqualified "SHOULD" statements. In the spirit of fast doc approval, I wouldn't object if those were changed to "MUST". I don't recall that we discussed these points before, but I could easily have missed that discussion. Unless someone objects the two SHOULD statements will be replaced with MUST. The modified paragraph in markup is shown below (also addressing comment 8 of my review, but that's an editorial change and should be uncontroversial). Sorry for the messy formatting. I suggest a deadline of January 9, 2015, but do so without checking with the chairs-who are of course free to set a different date if they choose so. Regards, Stephan A separate data channel is established to transport the CLUE protocol messages. The contents of the CLUE protocol messages are based on information introduced in this document, which is represented by an XML schema for this information defined in the CLUE data model [ref]. The CLUE data model [I-D.ietf-clue-data-model-schema] defines through an XML schema the syntax to be used. Some of the information which could possibly introduce privacy concerns is the xCard information as described in section 7.1.1.11. In addition, the (text) description field in the Media Capture attribute (section 7.1.1.7) could possibly reveal sensitive information or specific identities. The same would be true for the descriptions in the Capture Scene (section 7.3.1) and Capture Scene View (7.3.2) attributes. One other important consideration for the information in the xCard as well as the description field in the Media Capture and Capture Scene View attributes is that while the endpoints involved in the session have been authenticated, there is no assurance that the information in the xCard or description fields is authentic. Thus, this information SHOULD MUST not be used to make any authorization decisions and the participants in the sessions SHOULD MUST be made aware of this. ------=_NextPart_000_0B7A_01D02367.E30BF640 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

OK with this change

Roni Even

As individual

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan = Wenger
Sent: 29 December, 2014 4:52 AM
To: = CLUE
Subject: [clue] CLUE framework, security consideration = section, level of mandation

 

Hi,

 

Mark and I are editing the framework document to address = comments.

This is with reference to my review, dated 12/16/2014, and specifically = point 9 therein, reproduced as = follows:

 

9. Page 70, first paragraphs.  There are two unqualified = “SHOULD” statements.  In the spirit of fast doc = approval, I wouldn’t object if those were changed to = “MUST”.  I don’t recall that we discussed these = points before, but I could easily have missed that = discussion.

 

Unless someone objects the = two SHOULD statements will be replaced with MUST.  The modified = paragraph in markup is shown below (also addressing comment 8 of my = review, but that’s an editorial change and should be = uncontroversial).  Sorry for the messy = formatting.

 

I suggest a deadline of January 9, 2015, but do so without = checking with the chairs—who are of course free to set a different = date if they choose so.

 

Regards,

Stephan

 

 

   A separate data =
channel is established to transport the =
CLUE
   protocol =
messages. The contents of the CLUE protocol messages =
are
   based on =
information introduced in this document, which =
is
   represented by an =
XML schema for this information defined in =
the
   CLUE data model =
[ref].  =
The CLUE data model [I-D.ietf-clue-data-model-schema] defines =
through an XML schema the syntax to be used.  Some of the =
information which could possibly introduce privacy concerns is the xCard =
information as described in section 7.1.1.11.  In addition, the =
(text)
   description field =
in the Media Capture attribute (section =
7.1.1.7)
   could possibly =
reveal sensitive information or =
specific
   identities. The =
same would be true for the descriptions in =
the
   Capture Scene =
(section 7.3.1) and Capture Scene View =
(7.3.2)
   =
attributes.   One other important consideration for =
the
   information in =
the xCard as well as the description field in =
the
   Media Capture and =
Capture Scene View attributes is that while =
the
   endpoints =
involved in the session have been authenticated, =
there
   is no assurance =
that the information in the xCard or =
description
   fields is =
authentic.  Thus, this information SHOULD MUST not be =
used to
   make any =
authorization decisions and the participants in =
the
   sessions =
SHOULD MUST be made aware of this.
------=_NextPart_000_0B7A_01D02367.E30BF640-- From nobody Mon Dec 29 07:05:08 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED54B1A7011 for ; Mon, 29 Dec 2014 07:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_74=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ms9ONSh5CEeH for ; Mon, 29 Dec 2014 07:05:04 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75CDC1A7009 for ; Mon, 29 Dec 2014 07:05:02 -0800 (PST) Received: from resomta-ch2-06v.sys.comcast.net ([69.252.207.102]) by resqmta-ch2-10v.sys.comcast.net with comcast id ZT4v1p0072D5gil01T51HJ; Mon, 29 Dec 2014 15:05:01 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-06v.sys.comcast.net with comcast id ZT501p00V3Ge9ey01T50e7; Mon, 29 Dec 2014 15:05:01 +0000 Message-ID: <54A16D9C.80400@alum.mit.edu> Date: Mon, 29 Dec 2014 10:05:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 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 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419865501; bh=QHXTXxZ0pdGWWhcUdConPLAkZS7wZ0mdgb0YV63z05Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SZjhdQSUwOAzc9oHiSPSPA1MczdEyPQuDFC8SZNw7fqnwPb58xrOs0fWiKoNxOCWc znXuDD9kViWwtfae3EWNoaAJl6xBBczQWPhInJf3Y67csFO6y2wFKhkMtbcU7eZB2A pr36DEr015pTR8O3c0acOz9Lws/77kawIwsG9TiQWw0kqSLSVWmkr4GveteD6cDzsG iTSun14aWqEoShaXWDnvJCh51A1PdmHrXuhTi23uFD0JmtjmbNgVB6/KKZPMm9stvn nIbVkV9dM4pgRcvrYQ5pB2A0U5qRj0eyH3TzhrxAecujcSwtrLHG26RZU56IXc03ds T0Ye189IKVkgQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/LKTNvh_RpYolk4rjWKnxP8X2GvQ Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 15:05:07 -0000 On 12/28/14 9:35 PM, Stephan Wenger wrote: > Hi, > > Mark and I are editing the framework document to address comments. > This is with reference to my review, dated 12/16/2014, and specifically > point 4 therein, reproduced as follows: > > 4. Page 15, MUST strength for providing physical dimensions of known to > the system. I like this philosophically, but I think it’s meaningless > in practice, as the knowledge of coordinates of a pProvider is known to > the consumer only as a side effect of sending the measurements, right? > Perhaps less draconian language is more appropriate? Sounds to me > like a good place for a “SHOULD”? > > Unless someone objects the two MUST statements in section 6, second > bullet (page 15) will be replaced with less draconian SHOULD. The > modified bullet in markup is shown below. I think this is fine but, as always, some guidance should be given about what constitutes adequate justification for violating the SHOULD. Thanks, Paul > I suggest a deadline of January 9, 2015, but do so without checking with > the chairs—who are of course free to set a different date if they choose so. > Regards, > Stephan > > o Coordinates can be either in real, physical units (millimeters), > have an unknown scale or have no physical scale. Systems which > know their physical dimensions (for example professionally > installed Telepresence room systems)MUST _SHOULD_ always provide those > real-world measurements. Systems which don't know specific > physical dimensions but still know relative distancesMUST _SHOULD_ use > 'unknown scale'. 'No scale' is intended to be used where Media > Captures from different devices (with potentially different > scales) will be forwarded alongside one another (e.g. in the > case of an MCU). > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Dec 29 07:10:45 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276301A7025 for ; Mon, 29 Dec 2014 07:10:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_74=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MMpECdK9Tzmt for ; Mon, 29 Dec 2014 07:10:39 -0800 (PST) Received: from resqmta-ch2-11v.sys.comcast.net (resqmta-ch2-11v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:43]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A31051A70E2 for ; Mon, 29 Dec 2014 07:10:33 -0800 (PST) Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by resqmta-ch2-11v.sys.comcast.net with comcast id ZTAX1p0022Qkjl901TAYcm; Mon, 29 Dec 2014 15:10:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-15v.sys.comcast.net with comcast id ZTAY1p00D3Ge9ey01TAYwD; Mon, 29 Dec 2014 15:10:32 +0000 Message-ID: <54A16EE8.5070304@alum.mit.edu> Date: Mon, 29 Dec 2014 10:10:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> In-Reply-To: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419865832; bh=9Ekx8q33gQxEixF1TpDK+7IjEzp/zpg45CnZqbF8/5Y=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=G9e+mkjlVfrQi29rO2r07hmgqhLDZ1ztm5EtB0G42tv9R9OeoDZ/24wqVd4kJ1Zih CQ9ALLMDcpg6NvzBypZv6ogo/xrx4BWzsLvGhqiODg6JNjEyH2ACkdSnUFmmYDmcjv v2F5cJwKflQjeU3O+Kn3uJbBzodj8ThTPe4G0muDseaCvRylk1ewCWZEhSePbhKiW2 U69E1037pplWWPXR1vyUk9GQzS877Jh7BjnH67Rsy27qGWaR6Ry9T0FgbBxMKfR3rC +0WjsmwsLmlROhoBulNEWvj4yBJ2lFzl50ZDiGbI44oNPsKnsWKQbeKgaVB7NfcV4r 4vZfB/PtkjW7Q== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ejSz1r-pAQFKJtYdo-75p3AeSQE Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 15:10:41 -0000 On 12/29/14 5:46 AM, Roni Even wrote: > Hi Stephan, > > I am not sure what is the difference here between a MUST and a SHOULD. > Since it is required to send the scale value in the data model > (https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section-15.4 > ), what is the SHOULD here? I guess it really isn't necessary to have any normative language about items that are required in the data model schema. The normative language ought to focus on those places where there is a choice - in this case when it makes sense to use noscale, unknown, and mm. Language about that is already in the data model, but isn't normative. But it is clear enough, so maybe all is good. Thanks, Paul > Roni Even > > As individual > > *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan Wenger > *Sent:* 29 December, 2014 4:35 AM > *To:* CLUE > *Subject:* [clue] Framework, level of mandation for providing dimensions > > Hi, > > Mark and I are editing the framework document to address comments. > > This is with reference to my review, dated 12/16/2014, and specifically > point 4 therein, reproduced as follows: > > 4. Page 15, MUST strength for providing physical dimensions of known to > the system. I like this philosophically, but I think it’s meaningless > in practice, as the knowledge of coordinates of a pProvider is known to > the consumer only as a side effect of sending the measurements, right? > Perhaps less draconian language is more appropriate? Sounds to me > like a good place for a “SHOULD”? > > Unless someone objects the two MUST statements in section 6, second > bullet (page 15) will be replaced with less draconian SHOULD. The > modified bullet in markup is shown below. > > I suggest a deadline of January 9, 2015, but do so without checking with > the chairs—who are of course free to set a different date if they choose so. > > Regards, > > Stephan > > o Coordinates can be either in real, physical units (millimeters), > > have an unknown scale or have no physical scale. Systems which > > know their physical dimensions (for example professionally > > installed Telepresence room systems)MUST _SHOULD_ always provide those > > real-world measurements. Systems which don't know specific > > physical dimensions but still know relative distancesMUST _SHOULD_ use > > 'unknown scale'. 'No scale' is intended to be used where Media > > Captures from different devices (with potentially different > > scales) will be forwarded alongside one another (e.g. in the > > case of an MCU). > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Dec 29 09:26:58 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5E71A8874 for ; Mon, 29 Dec 2014 09:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQceLYe973RX for ; Mon, 29 Dec 2014 09:26:52 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0799.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::799]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E2291A8868 for ; Mon, 29 Dec 2014 09:26:52 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1274.namprd07.prod.outlook.com (25.160.149.17) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 17:26:12 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 17:26:12 +0000 From: Stephan Wenger To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Framework, level of mandation for providing dimensions Thread-Index: AQHQIxAV+8GIBcejdUedMqVY6uAHppymYzGAgABJ3AD//5/CAA== Date: Mon, 29 Dec 2014 17:26:11 +0000 Message-ID: References: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> <54A16EE8.5070304@alum.mit.edu> In-Reply-To: <54A16EE8.5070304@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1274; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(189002)(164054003)(24454002)(199003)(479174004)(87936001)(21056001)(2501002)(92566001)(107046002)(107886001)(46102003)(106116001)(66066001)(2171001)(99396003)(106356001)(4396001)(2656002)(86362001)(105586002)(122556002)(40100003)(54356999)(76176999)(50986999)(99286002)(77156002)(31966008)(15975445007)(97736003)(19580395003)(120916001)(101416001)(102836002)(20776003)(36756003)(19580405001)(68736005)(64706001)(2950100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 17:26:11.4248 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1274 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/NbHu4wS_2fdwMeupl28MeT9jojs Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:26:55 -0000 On 12/29/14, 07:10, "Paul Kyzivat" wrote: >On 12/29/14 5:46 AM, Roni Even wrote: >> Hi Stephan, >> >> I am not sure what is the difference here between a MUST and a SHOULD. >> Since it is required to send the scale value in the data model >>=20 >>(https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section >>-15.4 >> ), what is the SHOULD here? > >I guess it really isn't necessary to have any normative language about >items that are required in the data model schema. The normative language >ought to focus on those places where there is a choice - in this case >when it makes sense to use noscale, unknown, and mm. Language about that >is already in the data model, but isn't normative. But it is clear >enough, so maybe all is good. The reason of the =B3SHOULD=B2 is that a =B3MUST=B2 is unsupervisable and unenforcible. The language in the framework stated that a system MUST include measurements when they are known. So suppose you have a system that is all measured in, values entered through config files or UI, and whatnot, ready to go. How does a remote system know that? It doesn=B9t. It only knows it once it sees the measurements on the wire. If the measured-in endpoint decides not to send those measurement because it rains, because it=B9s Monday, or because it has somehow identified the remote system to be from a competitor and does not want to send the best possible media to make that remote system look bad, there is nothing anyone could do. Or identify the sender as broken, based on bits on the wire. I think that it is good practice in system level standards (and generally widely followed) not to provide hard MUSTs (or shalls or whatever) for unsupervisable and unenforcible properties. The data model statement is different, I think. If I understand it correctly, the data model simply requires the measurements to be signaled when a certain mode is signaled. That=B9s all fine. Clearer? Stephan > > Thanks, > Paul > >> Roni Even >> >> As individual >> >> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan Wenger >> *Sent:* 29 December, 2014 4:35 AM >> *To:* CLUE >> *Subject:* [clue] Framework, level of mandation for providing dimensions >> >> Hi, >> >> Mark and I are editing the framework document to address comments. >> >> This is with reference to my review, dated 12/16/2014, and specifically >> point 4 therein, reproduced as follows: >> >> 4. Page 15, MUST strength for providing physical dimensions of known to >> the system. I like this philosophically, but I think it=B9s meaningless >> in practice, as the knowledge of coordinates of a pProvider is known to >> the consumer only as a side effect of sending the measurements, right? >> Perhaps less draconian language is more appropriate? Sounds to me >> like a good place for a =B3SHOULD=B2? >> >> Unless someone objects the two MUST statements in section 6, second >> bullet (page 15) will be replaced with less draconian SHOULD. The >> modified bullet in markup is shown below. >> >> I suggest a deadline of January 9, 2015, but do so without checking with >> the chairs=8Bwho are of course free to set a different date if they >>choose so. >> >> Regards, >> >> Stephan >> >> o Coordinates can be either in real, physical units (millimeters), >> >> have an unknown scale or have no physical scale. Systems which >> >> know their physical dimensions (for example professionally >> >> installed Telepresence room systems)MUST _SHOULD_ always >>provide those >> >> real-world measurements. Systems which don't know specific >> >> physical dimensions but still know relative distancesMUST >>_SHOULD_ use >> >> 'unknown scale'. 'No scale' is intended to be used where Media >> >> Captures from different devices (with potentially different >> >> scales) will be forwarded alongside one another (e.g. in the >> >> case of an MCU). >> >> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > >_______________________________________________ >clue mailing list >clue@ietf.org >https://www.ietf.org/mailman/listinfo/clue From nobody Mon Dec 29 09:32:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A35FC1A8034 for ; Mon, 29 Dec 2014 09:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_74=0.6, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aq-P55eVEIuv for ; Mon, 29 Dec 2014 09:32:31 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94801A1B9E for ; Mon, 29 Dec 2014 09:32:30 -0800 (PST) Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-05v.sys.comcast.net with comcast id ZVXz1p00C2Udklx01VYVaV; Mon, 29 Dec 2014 17:32:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-ch2-18v.sys.comcast.net with comcast id ZVYU1p00K3Ge9ey01VYV6E; Mon, 29 Dec 2014 17:32:29 +0000 Message-ID: <54A1902C.7050002@alum.mit.edu> Date: Mon, 29 Dec 2014 12:32:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Stephan Wenger , "clue@ietf.org" References: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> <54A16EE8.5070304@alum.mit.edu> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1419874349; bh=XbORekVLB0dzppZZwHN+AfotVVKihoIF6npTA5wUYW4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=fTcxj2vdN1k7tmUSCF6ULr3ZZDy3AtbhgK/GIAq/OpPE+208rY5JkuuJjet0irXco kuMSQLR6H+76dIzNMLEMzmXVriUsZYDMrPzHD5EZBwfnWXFdo+zaTnBd7ilCaZd4EF kGBaQ927gWEDZJvCz6rjfXXdWehK/mEWPuAwfeiVl700h3iOSFm+ZVTHtEIpCwUzAL HfNJDnY6ENl3ny5adPAv5BXR6hGjWd92jzIrmm8PGXkCR9BlQ023ixDPUOJnaMU06I MuALxcRDJELIsTbb3UJHe9bsqmW5wO5GgVmBVWL6ZWQO0AlQPXhdAqo6NWqehw6uDq VzdhuXUJiV0KA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/a-Lr2H_c7Yt-7q-s2MXgcRPpDZ0 Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:32:35 -0000 On 12/29/14 12:26 PM, Stephan Wenger wrote: > > > On 12/29/14, 07:10, "Paul Kyzivat" wrote: > >> On 12/29/14 5:46 AM, Roni Even wrote: >>> Hi Stephan, >>> >>> I am not sure what is the difference here between a MUST and a SHOULD. >>> Since it is required to send the scale value in the data model >>> >>> (https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#section >>> -15.4 >>> ), what is the SHOULD here? >> >> I guess it really isn't necessary to have any normative language about >> items that are required in the data model schema. The normative language >> ought to focus on those places where there is a choice - in this case >> when it makes sense to use noscale, unknown, and mm. Language about that >> is already in the data model, but isn't normative. But it is clear >> enough, so maybe all is good. > > The reason of the ³SHOULD² is that a ³MUST² is unsupervisable and > unenforcible. > > The language in the framework stated that a system MUST include > measurements when they are known. So suppose you have a system that is > all measured in, values entered through config files or UI, and whatnot, > ready to go. How does a remote system know that? It doesn¹t. It only > knows it once it sees the measurements on the wire. If the measured-in > endpoint decides not to send those measurement because it rains, because > it¹s Monday, or because it has somehow identified the remote system to be > from a competitor and does not want to send the best possible media to > make that remote system look bad, there is nothing anyone could do. Or > identify the sender as broken, based on bits on the wire. > > I think that it is good practice in system level standards (and generally > widely followed) not to provide hard MUSTs (or shalls or whatever) for > unsupervisable and unenforcible properties. > > The data model statement is different, I think. If I understand it > correctly, the data model simply requires the measurements to be signaled > when a certain mode is signaled. That¹s all fine. I think you are making the case that this shouldn't be normative. So instead of MUST or SHOULD, use "should". And that is what is already done in the data model. Thanks, Paul > Clearer? > > Stephan > >> >> Thanks, >> Paul >> >>> Roni Even >>> >>> As individual >>> >>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan Wenger >>> *Sent:* 29 December, 2014 4:35 AM >>> *To:* CLUE >>> *Subject:* [clue] Framework, level of mandation for providing dimensions >>> >>> Hi, >>> >>> Mark and I are editing the framework document to address comments. >>> >>> This is with reference to my review, dated 12/16/2014, and specifically >>> point 4 therein, reproduced as follows: >>> >>> 4. Page 15, MUST strength for providing physical dimensions of known to >>> the system. I like this philosophically, but I think it¹s meaningless >>> in practice, as the knowledge of coordinates of a pProvider is known to >>> the consumer only as a side effect of sending the measurements, right? >>> Perhaps less draconian language is more appropriate? Sounds to me >>> like a good place for a ³SHOULD²? >>> >>> Unless someone objects the two MUST statements in section 6, second >>> bullet (page 15) will be replaced with less draconian SHOULD. The >>> modified bullet in markup is shown below. >>> >>> I suggest a deadline of January 9, 2015, but do so without checking with >>> the chairs‹who are of course free to set a different date if they >>> choose so. >>> >>> Regards, >>> >>> Stephan >>> >>> o Coordinates can be either in real, physical units (millimeters), >>> >>> have an unknown scale or have no physical scale. Systems which >>> >>> know their physical dimensions (for example professionally >>> >>> installed Telepresence room systems)MUST _SHOULD_ always >>> provide those >>> >>> real-world measurements. Systems which don't know specific >>> >>> physical dimensions but still know relative distancesMUST >>> _SHOULD_ use >>> >>> 'unknown scale'. 'No scale' is intended to be used where Media >>> >>> Captures from different devices (with potentially different >>> >>> scales) will be forwarded alongside one another (e.g. in the >>> >>> case of an MCU). >>> >>> >>> >>> _______________________________________________ >>> clue mailing list >>> clue@ietf.org >>> https://www.ietf.org/mailman/listinfo/clue >>> >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > > From nobody Mon Dec 29 09:37:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FC421A875B for ; Mon, 29 Dec 2014 09:37:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.302 X-Spam-Level: X-Spam-Status: No, score=-1.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRMUFajm9qD9 for ; Mon, 29 Dec 2014 09:37:18 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 334FC1A886C for ; Mon, 29 Dec 2014 09:37:14 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1225.namprd07.prod.outlook.com (25.160.146.153) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 17:36:46 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) with Microsoft SMTP Server (TLS) id 15.1.49.12; Mon, 29 Dec 2014 17:36:40 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Mon, 29 Dec 2014 17:36:40 +0000 From: Stephan Wenger To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] Framework, level of mandation for providing dimensions Thread-Index: AQHQIxAV+8GIBcejdUedMqVY6uAHppymYzGAgABJ3AD//5/CAIAAh+YA//97CoA= Date: Mon, 29 Dec 2014 17:36:39 +0000 Message-ID: References: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> <54A16EE8.5070304@alum.mit.edu> <54A1902C.7050002@alum.mit.edu> In-Reply-To: <54A1902C.7050002@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1276;UriScan:; x-forefront-prvs: 0440AC9990 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(377454003)(24454002)(479174004)(120916001)(101416001)(40100003)(105586002)(19580405001)(19580395003)(102836002)(31966008)(66066001)(106356001)(68736005)(106116001)(36756003)(15975445007)(99396003)(93886004)(97736003)(4396001)(50986999)(92566001)(2171001)(99286002)(86362001)(107046002)(2656002)(54356999)(64706001)(20776003)(77156002)(2501002)(21056001)(122556002)(107886001)(76176999)(46102003)(87936001)(2950100001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1276; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:0; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <7AA6D6D30EDF21439690A50C82AC2873@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Dec 2014 17:36:39.9723 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1276 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1225; X-OriginatorOrg: stewe.org Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xgPsjg0LJyX6pnow7BWJBySyWaI Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 17:37:20 -0000 QSBub24tbm9ybWF0aXZlIOKAnHNob3VsZOKAnSB3b3VsZCB3b3JrIGZvciBtZS4NClN0ZXBoYW4N Cg0KT24gMTIvMjkvMTQsIDA5OjMyLCAiUGF1bCBLeXppdmF0IiA8cGt5eml2YXRAYWx1bS5taXQu ZWR1PiB3cm90ZToNCg0KPk9uIDEyLzI5LzE0IDEyOjI2IFBNLCBTdGVwaGFuIFdlbmdlciB3cm90 ZToNCj4+DQo+Pg0KPj4gT24gMTIvMjkvMTQsIDA3OjEwLCAiUGF1bCBLeXppdmF0IiA8cGt5eml2 YXRAYWx1bS5taXQuZWR1PiB3cm90ZToNCj4+DQo+Pj4gT24gMTIvMjkvMTQgNTo0NiBBTSwgUm9u aSBFdmVuIHdyb3RlOg0KPj4+PiBIaSBTdGVwaGFuLA0KPj4+Pg0KPj4+PiBJIGFtIG5vdCBzdXJl IHdoYXQgaXMgdGhlIGRpZmZlcmVuY2UgaGVyZSBiZXR3ZWVuIGEgTVVTVCBhbmQgYSBTSE9VTEQu DQo+Pj4+IFNpbmNlIGl0IGlzIHJlcXVpcmVkIHRvIHNlbmQgdGhlIHNjYWxlIHZhbHVlIGluIHRo ZSBkYXRhIG1vZGVsDQo+Pj4+DQo+Pj4+IA0KPj4+PihodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi1jbHVlLWRhdGEtbW9kZWwtc2NoZW1hLTA3I3NlY3RpDQo+Pj4+b24NCj4+ Pj4gLTE1LjQNCj4+Pj4gKSwgd2hhdCBpcyB0aGUgU0hPVUxEIGhlcmU/DQo+Pj4NCj4+PiBJIGd1 ZXNzIGl0IHJlYWxseSBpc24ndCBuZWNlc3NhcnkgdG8gaGF2ZSBhbnkgbm9ybWF0aXZlIGxhbmd1 YWdlIGFib3V0DQo+Pj4gaXRlbXMgdGhhdCBhcmUgcmVxdWlyZWQgaW4gdGhlIGRhdGEgbW9kZWwg c2NoZW1hLiBUaGUgbm9ybWF0aXZlDQo+Pj5sYW5ndWFnZQ0KPj4+IG91Z2h0IHRvIGZvY3VzIG9u IHRob3NlIHBsYWNlcyB3aGVyZSB0aGVyZSBpcyBhIGNob2ljZSAtIGluIHRoaXMgY2FzZQ0KPj4+ IHdoZW4gaXQgbWFrZXMgc2Vuc2UgdG8gdXNlIG5vc2NhbGUsIHVua25vd24sIGFuZCBtbS4gTGFu Z3VhZ2UgYWJvdXQNCj4+PnRoYXQNCj4+PiBpcyBhbHJlYWR5IGluIHRoZSBkYXRhIG1vZGVsLCBi dXQgaXNuJ3Qgbm9ybWF0aXZlLiBCdXQgaXQgaXMgY2xlYXINCj4+PiBlbm91Z2gsIHNvIG1heWJl IGFsbCBpcyBnb29kLg0KPj4NCj4+IFRoZSByZWFzb24gb2YgdGhlIMKzU0hPVUxEwrIgaXMgdGhh dCBhIMKzTVVTVMKyIGlzIHVuc3VwZXJ2aXNhYmxlIGFuZA0KPj4gdW5lbmZvcmNpYmxlLg0KPj4N Cj4+IFRoZSBsYW5ndWFnZSBpbiB0aGUgZnJhbWV3b3JrIHN0YXRlZCB0aGF0IGEgc3lzdGVtIE1V U1QgaW5jbHVkZQ0KPj4gbWVhc3VyZW1lbnRzIHdoZW4gdGhleSBhcmUga25vd24uICBTbyBzdXBw b3NlIHlvdSBoYXZlIGEgc3lzdGVtIHRoYXQgaXMNCj4+IGFsbCBtZWFzdXJlZCBpbiwgdmFsdWVz IGVudGVyZWQgdGhyb3VnaCBjb25maWcgZmlsZXMgb3IgVUksIGFuZCB3aGF0bm90LA0KPj4gcmVh ZHkgdG8gZ28uICBIb3cgZG9lcyBhIHJlbW90ZSBzeXN0ZW0ga25vdyB0aGF0PyAgSXQgZG9lc27C uXQuICBJdCBvbmx5DQo+PiBrbm93cyBpdCBvbmNlIGl0IHNlZXMgdGhlIG1lYXN1cmVtZW50cyBv biB0aGUgd2lyZS4gIElmIHRoZSBtZWFzdXJlZC1pbg0KPj4gZW5kcG9pbnQgZGVjaWRlcyBub3Qg dG8gc2VuZCB0aG9zZSBtZWFzdXJlbWVudCBiZWNhdXNlIGl0IHJhaW5zLCBiZWNhdXNlDQo+PiBp dMK5cyBNb25kYXksIG9yIGJlY2F1c2UgaXQgaGFzIHNvbWVob3cgaWRlbnRpZmllZCB0aGUgcmVt b3RlIHN5c3RlbSB0bw0KPj5iZQ0KPj4gZnJvbSBhIGNvbXBldGl0b3IgYW5kIGRvZXMgbm90IHdh bnQgdG8gc2VuZCB0aGUgYmVzdCBwb3NzaWJsZSBtZWRpYSB0bw0KPj4gbWFrZSB0aGF0IHJlbW90 ZSBzeXN0ZW0gbG9vayBiYWQsIHRoZXJlIGlzIG5vdGhpbmcgYW55b25lIGNvdWxkIGRvLiAgT3IN Cj4+IGlkZW50aWZ5IHRoZSBzZW5kZXIgYXMgYnJva2VuLCBiYXNlZCBvbiBiaXRzIG9uIHRoZSB3 aXJlLg0KPj4NCj4+IEkgdGhpbmsgdGhhdCBpdCBpcyBnb29kIHByYWN0aWNlIGluIHN5c3RlbSBs ZXZlbCBzdGFuZGFyZHMgKGFuZA0KPj5nZW5lcmFsbHkNCj4+IHdpZGVseSBmb2xsb3dlZCkgbm90 IHRvIHByb3ZpZGUgaGFyZCBNVVNUcyAob3Igc2hhbGxzIG9yIHdoYXRldmVyKSBmb3INCj4+IHVu c3VwZXJ2aXNhYmxlIGFuZCB1bmVuZm9yY2libGUgcHJvcGVydGllcy4NCj4+DQo+PiBUaGUgZGF0 YSBtb2RlbCBzdGF0ZW1lbnQgaXMgZGlmZmVyZW50LCBJIHRoaW5rLiAgSWYgSSB1bmRlcnN0YW5k IGl0DQo+PiBjb3JyZWN0bHksIHRoZSBkYXRhIG1vZGVsIHNpbXBseSByZXF1aXJlcyB0aGUgbWVh c3VyZW1lbnRzIHRvIGJlDQo+PnNpZ25hbGVkDQo+PiB3aGVuIGEgY2VydGFpbiBtb2RlIGlzIHNp Z25hbGVkLiAgVGhhdMK5cyBhbGwgZmluZS4NCj4NCj5JIHRoaW5rIHlvdSBhcmUgbWFraW5nIHRo ZSBjYXNlIHRoYXQgdGhpcyBzaG91bGRuJ3QgYmUgbm9ybWF0aXZlLiBTbw0KPmluc3RlYWQgb2Yg TVVTVCBvciBTSE9VTEQsIHVzZSAic2hvdWxkIi4gQW5kIHRoYXQgaXMgd2hhdCBpcyBhbHJlYWR5 DQo+ZG9uZSBpbiB0aGUgZGF0YSBtb2RlbC4NCj4NCj4JVGhhbmtzLA0KPglQYXVsDQo+DQo+PiBD bGVhcmVyPw0KPj4NCj4+IFN0ZXBoYW4NCj4+DQo+Pj4NCj4+PiAJVGhhbmtzLA0KPj4+IAlQYXVs DQo+Pj4NCj4+Pj4gUm9uaSBFdmVuDQo+Pj4+DQo+Pj4+IEFzIGluZGl2aWR1YWwNCj4+Pj4NCj4+ Pj4gKkZyb206KmNsdWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYg T2YgKlN0ZXBoYW4NCj4+Pj5XZW5nZXINCj4+Pj4gKlNlbnQ6KiAyOSBEZWNlbWJlciwgMjAxNCA0 OjM1IEFNDQo+Pj4+ICpUbzoqIENMVUUNCj4+Pj4gKlN1YmplY3Q6KiBbY2x1ZV0gRnJhbWV3b3Jr LCBsZXZlbCBvZiBtYW5kYXRpb24gZm9yIHByb3ZpZGluZw0KPj4+PmRpbWVuc2lvbnMNCj4+Pj4N Cj4+Pj4gSGksDQo+Pj4+DQo+Pj4+IE1hcmsgYW5kIEkgYXJlIGVkaXRpbmcgdGhlIGZyYW1ld29y ayBkb2N1bWVudCB0byBhZGRyZXNzIGNvbW1lbnRzLg0KPj4+Pg0KPj4+PiBUaGlzIGlzIHdpdGgg cmVmZXJlbmNlIHRvIG15IHJldmlldywgZGF0ZWQgMTIvMTYvMjAxNCwgYW5kDQo+Pj4+c3BlY2lm aWNhbGx5DQo+Pj4+IHBvaW50IDQgdGhlcmVpbiwgcmVwcm9kdWNlZCBhcyBmb2xsb3dzOg0KPj4+ Pg0KPj4+PiA0LiBQYWdlIDE1LCBNVVNUIHN0cmVuZ3RoIGZvciBwcm92aWRpbmcgcGh5c2ljYWwg ZGltZW5zaW9ucyBvZiBrbm93bg0KPj4+PnRvDQo+Pj4+IHRoZSBzeXN0ZW0uICBJIGxpa2UgdGhp cyBwaGlsb3NvcGhpY2FsbHksIGJ1dCBJIHRoaW5rIGl0wrlzIG1lYW5pbmdsZXNzDQo+Pj4+IGlu IHByYWN0aWNlLCBhcyB0aGUga25vd2xlZGdlIG9mIGNvb3JkaW5hdGVzIG9mIGEgcFByb3ZpZGVy IGlzIGtub3duDQo+Pj4+dG8NCj4+Pj4gdGhlIGNvbnN1bWVyIG9ubHkgYXMgYSBzaWRlIGVmZmVj dCBvZiBzZW5kaW5nICB0aGUgbWVhc3VyZW1lbnRzLA0KPj4+PnJpZ2h0Pw0KPj4+PiAgICBQZXJo YXBzIGxlc3MgZHJhY29uaWFuIGxhbmd1YWdlIGlzIG1vcmUgYXBwcm9wcmlhdGU/ICBTb3VuZHMg dG8gbWUNCj4+Pj4gbGlrZSBhIGdvb2QgcGxhY2UgZm9yIGEgwrNTSE9VTETCsj8NCj4+Pj4NCj4+ Pj4gVW5sZXNzIHNvbWVvbmUgb2JqZWN0cyB0aGUgdHdvIE1VU1Qgc3RhdGVtZW50cyBpbiBzZWN0 aW9uIDYsIHNlY29uZA0KPj4+PiBidWxsZXQgKHBhZ2UgMTUpIHdpbGwgYmUgcmVwbGFjZWQgd2l0 aCBsZXNzIGRyYWNvbmlhbiBTSE9VTEQuICBUaGUNCj4+Pj4gbW9kaWZpZWQgYnVsbGV0IGluIG1h cmt1cCBpcyBzaG93biBiZWxvdy4NCj4+Pj4NCj4+Pj4gSSBzdWdnZXN0IGEgZGVhZGxpbmUgb2Yg SmFudWFyeSA5LCAyMDE1LCBidXQgZG8gc28gd2l0aG91dCBjaGVja2luZw0KPj4+PndpdGgNCj4+ Pj4gdGhlIGNoYWlyc+KAuXdobyBhcmUgb2YgY291cnNlIGZyZWUgdG8gc2V0IGEgZGlmZmVyZW50 IGRhdGUgaWYgdGhleQ0KPj4+PiBjaG9vc2Ugc28uDQo+Pj4+DQo+Pj4+IFJlZ2FyZHMsDQo+Pj4+ DQo+Pj4+IFN0ZXBoYW4NCj4+Pj4NCj4+Pj4gICAgbyAgQ29vcmRpbmF0ZXMgY2FuIGJlIGVpdGhl ciBpbiByZWFsLCBwaHlzaWNhbCB1bml0cyAobWlsbGltZXRlcnMpLA0KPj4+Pg0KPj4+PiAgICAg ICAgIGhhdmUgYW4gdW5rbm93biBzY2FsZSBvciBoYXZlIG5vIHBoeXNpY2FsIHNjYWxlLiAgU3lz dGVtcw0KPj4+PndoaWNoDQo+Pj4+DQo+Pj4+ICAgICAgICAga25vdyB0aGVpciBwaHlzaWNhbCBk aW1lbnNpb25zIChmb3IgZXhhbXBsZSBwcm9mZXNzaW9uYWxseQ0KPj4+Pg0KPj4+PiAgICAgICAg IGluc3RhbGxlZCBUZWxlcHJlc2VuY2Ugcm9vbSBzeXN0ZW1zKU1VU1QgIF9TSE9VTERfICBhbHdh eXMNCj4+Pj4gcHJvdmlkZSB0aG9zZQ0KPj4+Pg0KPj4+PiAgICAgICAgIHJlYWwtd29ybGQgbWVh c3VyZW1lbnRzLiAgU3lzdGVtcyB3aGljaCBkb24ndCBrbm93IHNwZWNpZmljDQo+Pj4+DQo+Pj4+ ICAgICAgICAgcGh5c2ljYWwgZGltZW5zaW9ucyBidXQgc3RpbGwga25vdyByZWxhdGl2ZSBkaXN0 YW5jZXNNVVNUDQo+Pj4+IF9TSE9VTERfICB1c2UNCj4+Pj4NCj4+Pj4gICAgICAgICAndW5rbm93 biBzY2FsZScuICAnTm8gc2NhbGUnIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgd2hlcmUNCj4+Pj5N ZWRpYQ0KPj4+Pg0KPj4+PiAgICAgICAgIENhcHR1cmVzIGZyb20gZGlmZmVyZW50IGRldmljZXMg KHdpdGggcG90ZW50aWFsbHkgZGlmZmVyZW50DQo+Pj4+DQo+Pj4+ICAgICAgICAgc2NhbGVzKSB3 aWxsIGJlIGZvcndhcmRlZCBhbG9uZ3NpZGUgb25lIGFub3RoZXIgKGUuZy4gaW4gdGhlDQo+Pj4+ DQo+Pj4+ICAgICAgICAgY2FzZSBvZiBhbiBNQ1UpLg0KPj4+Pg0KPj4+Pg0KPj4+Pg0KPj4+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+PiBjbHVl IG1haWxpbmcgbGlzdA0KPj4+PiBjbHVlQGlldGYub3JnDQo+Pj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPj4+Pg0KPj4+DQo+Pj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBjbHVlIG1haWxpbmcgbGlzdA0K Pj4+IGNsdWVAaWV0Zi5vcmcNCj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2NsdWUNCj4+DQo+Pg0KPg0KDQo= From nobody Mon Dec 29 10:51:41 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B21921A8EA9 for ; Mon, 29 Dec 2014 10:51:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_74=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z7mGY9Mi1LA1 for ; Mon, 29 Dec 2014 10:51:37 -0800 (PST) Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC321A8BC1 for ; Mon, 29 Dec 2014 10:51:36 -0800 (PST) Received: by mail-wg0-f51.google.com with SMTP id x12so19588693wgg.10 for ; Mon, 29 Dec 2014 10:51:35 -0800 (PST) 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:thread-index :content-language; bh=XnobxUCs/7EaRiGdmI4MoFfQ7Xgx2+zDXF7ZpnIm6n0=; b=f3ej5bTHXGyVesI2AI+ReszZRFWNQC/mDsVdyPGhxurK+n9P/o+kwIkp9Do/7J7J9r AdqSJVtd82GyuA3jM+Mb9QItdzLBs9/3cAclVE57b5Ro5sCuoi0Y1mGBwYDFJE0RQplj IH4HJD8o3XQd/xkNlY0YFMuqxNm0BUBJDqRpV0FQWE4BHegv26ZiEKDkg1sogqSluqCm EzLth/3Be9+7+wwP2SlusQh9N+2ARbPgFMzE+bKGDrbNCsMPWeQhqzRdnSFbQLonCC2G pfH1ebyjJcOEtjvJqZ583QCCEmoqPlHud3Rl0Q7KUPPqDQd2Aon6b1RPONRk1RYe4sKU Rsjw== X-Received: by 10.194.94.1 with SMTP id cy1mr93464015wjb.127.1419879095448; Mon, 29 Dec 2014 10:51:35 -0800 (PST) Received: from RoniE ([109.67.162.214]) by mx.google.com with ESMTPSA id wa5sm50981246wjc.8.2014.12.29.10.51.33 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Dec 2014 10:51:34 -0800 (PST) From: "Roni Even" To: "'Stephan Wenger'" , "'Paul Kyzivat'" , References: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> <54A16EE8.5070304@alum.mit.edu> <54A1902C.7050002@alum.mit.edu> In-Reply-To: Date: Mon, 29 Dec 2014 20:51:30 +0200 Message-ID: <0b8b01d02398$7790e4d0$66b2ae70$@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: AQJoaKwpMXOVzCePmsyH4w3dRwsbvwGUiE0OAgDRz2QBhyLG8QK3A5y3AdiOw3WbKPy1gA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/JSDhbRizehpCggQiLB1UYqOdXp8 Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Dec 2014 18:51:38 -0000 Hi, The whole idea of the telepresence work was to provide the required = information that will allow for optimal user experience and to = standardize it. Saying that one vendor will want to ignore it to make the other system = bad is missing this target and it will be better to have such system as = non-compliant. The texts states the cases for using each of the options so you must = have a reason to send no scale. The data model requires you to provide = the information.=20 So non-normative at all may look good but I am not sure if it means = something at all. I expect that the framework will provide guidelines = and normative language to make the best user experience and this = attribute is about it Roni > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Stephan Wenger > Sent: 29 December, 2014 7:37 PM > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] Framework, level of mandation for providing = dimensions >=20 > A non-normative =E2=80=9Cshould=E2=80=9D would work for me. > Stephan >=20 > On 12/29/14, 09:32, "Paul Kyzivat" wrote: >=20 > >On 12/29/14 12:26 PM, Stephan Wenger wrote: > >> > >> > >> On 12/29/14, 07:10, "Paul Kyzivat" wrote: > >> > >>> On 12/29/14 5:46 AM, Roni Even wrote: > >>>> Hi Stephan, > >>>> > >>>> I am not sure what is the difference here between a MUST and a > SHOULD. > >>>> Since it is required to send the scale value in the data model > >>>> > >>>> > = >>>>(https://tools.ietf.org/html/draft-ietf-clue-data-model-schema-07#se > >>>>cti > >>>>on > >>>> -15.4 > >>>> ), what is the SHOULD here? > >>> > >>> I guess it really isn't necessary to have any normative language > >>>about items that are required in the data model schema. The > >>>normative language ought to focus on those places where there is a > >>>choice - in this case when it makes sense to use noscale, unknown, > >>>and mm. Language about that is already in the data model, but = isn't > >>>normative. But it is clear enough, so maybe all is good. > >> > >> The reason of the =C2=B3SHOULD=C2=B2 is that a =C2=B3MUST=C2=B2 is = unsupervisable and > >> unenforcible. > >> > >> The language in the framework stated that a system MUST include > >>measurements when they are known. So suppose you have a system that > >>is all measured in, values entered through config files or UI, and > >>whatnot, ready to go. How does a remote system know that? It > >>doesn=C2=B9t. It only knows it once it sees the measurements on = the wire. > >>If the measured-in endpoint decides not to send those measurement > >>because it rains, because it=C2=B9s Monday, or because it has = somehow > >>identified the remote system to be from a competitor and does not > >>want to send the best possible media to make that remote system = look > >>bad, there is nothing anyone could do. Or identify the sender as > >>broken, based on bits on the wire. > >> > >> I think that it is good practice in system level standards (and > >>generally widely followed) not to provide hard MUSTs (or shalls or > >>whatever) for unsupervisable and unenforcible properties. > >> > >> The data model statement is different, I think. If I understand it > >>correctly, the data model simply requires the measurements to be > >>signaled when a certain mode is signaled. That=C2=B9s all fine. > > > >I think you are making the case that this shouldn't be normative. So > >instead of MUST or SHOULD, use "should". And that is what is already > >done in the data model. > > > > Thanks, > > Paul > > > >> Clearer? > >> > >> Stephan > >> > >>> > >>> Thanks, > >>> Paul > >>> > >>>> Roni Even > >>>> > >>>> As individual > >>>> > >>>> *From:*clue [mailto:clue-bounces@ietf.org] *On Behalf Of *Stephan > >>>>Wenger > >>>> *Sent:* 29 December, 2014 4:35 AM > >>>> *To:* CLUE > >>>> *Subject:* [clue] Framework, level of mandation for providing > >>>>dimensions > >>>> > >>>> Hi, > >>>> > >>>> Mark and I are editing the framework document to address = comments. > >>>> > >>>> This is with reference to my review, dated 12/16/2014, and > >>>>specifically point 4 therein, reproduced as follows: > >>>> > >>>> 4. Page 15, MUST strength for providing physical dimensions of > >>>>known to the system. I like this philosophically, but I think = it=C2=B9s > >>>>meaningless in practice, as the knowledge of coordinates of a > >>>>pProvider is known to the consumer only as a side effect of = sending > >>>>the measurements, right? > >>>> Perhaps less draconian language is more appropriate? Sounds = to > >>>>me like a good place for a =C2=B3SHOULD=C2=B2? > >>>> > >>>> Unless someone objects the two MUST statements in section 6, = second > >>>> bullet (page 15) will be replaced with less draconian SHOULD. = The > >>>> modified bullet in markup is shown below. > >>>> > >>>> I suggest a deadline of January 9, 2015, but do so without = checking > >>>>with the chairs=E2=80=B9who are of course free to set a different = date if > >>>>they choose so. > >>>> > >>>> Regards, > >>>> > >>>> Stephan > >>>> > >>>> o Coordinates can be either in real, physical units > >>>> (millimeters), > >>>> > >>>> have an unknown scale or have no physical scale. Systems > >>>>which > >>>> > >>>> know their physical dimensions (for example = professionally > >>>> > >>>> installed Telepresence room systems)MUST _SHOULD_ = always > >>>> provide those > >>>> > >>>> real-world measurements. Systems which don't know = specific > >>>> > >>>> physical dimensions but still know relative distancesMUST > >>>> _SHOULD_ use > >>>> > >>>> 'unknown scale'. 'No scale' is intended to be used where > >>>>Media > >>>> > >>>> Captures from different devices (with potentially = different > >>>> > >>>> scales) will be forwarded alongside one another (e.g. in > >>>> the > >>>> > >>>> case of an MCU). > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> clue mailing list > >>>> clue@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/clue > >>>> > >>> > >>> _______________________________________________ > >>> clue mailing list > >>> clue@ietf.org > >>> https://www.ietf.org/mailman/listinfo/clue > >> > >> > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Tue Dec 30 10:38:53 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB71A1A20 for ; Tue, 30 Dec 2014 10:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.398 X-Spam-Level: * X-Spam-Status: No, score=1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_74=0.6, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hsB1GidnCrQh for ; Tue, 30 Dec 2014 10:38:49 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0798.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:798]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E71E1A0273 for ; Tue, 30 Dec 2014 10:38:49 -0800 (PST) Received: from CY1PR0701MB1276.namprd07.prod.outlook.com (25.160.149.19) by CY1PR0701MB1274.namprd07.prod.outlook.com (25.160.149.17) with Microsoft SMTP Server (TLS) id 15.1.49.12; Tue, 30 Dec 2014 18:38:24 +0000 Received: from CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) by CY1PR0701MB1276.namprd07.prod.outlook.com ([25.160.149.19]) with mapi id 15.01.0049.002; Tue, 30 Dec 2014 18:38:24 +0000 From: Stephan Wenger To: Roni Even , 'Paul Kyzivat' , "clue@ietf.org" Thread-Topic: [clue] Framework, level of mandation for providing dimensions Thread-Index: AQHQIxAV+8GIBcejdUedMqVY6uAHppymYzGAgABJ3AD//5/CAIAAh+YA//97CoCAAJsKAIABCIQA Date: Tue, 30 Dec 2014 18:38:24 +0000 Message-ID: References: <0b6f01d02354$aadf72a0$009e57e0$@gmail.com> <54A16EE8.5070304@alum.mit.edu> <54A1902C.7050002@alum.mit.edu> <0b8b01d02398$7790e4d0$66b2ae70$@gmail.com> In-Reply-To: <0b8b01d02398$7790e4d0$66b2ae70$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.174.124.226] authentication-results: spf=none (sender IP is ) smtp.mailfrom=stewe@stewe.org; x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CY1PR0701MB1274; x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:; SRVR:CY1PR0701MB1274; x-forefront-prvs: 04410E544A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(24454002)(199003)(479174004)(13464003)(377454003)(189002)(51444003)(164054003)(77156002)(99286002)(97736003)(31966008)(62966003)(15975445007)(40100003)(50986999)(54356999)(76176999)(64706001)(36756003)(20776003)(19580405001)(68736005)(2950100001)(101416001)(2900100001)(102836002)(19580395003)(120916001)(106116001)(46102003)(66066001)(107046002)(2501002)(92566001)(21056001)(87936001)(107886001)(93886004)(2656002)(4396001)(122556002)(106356001)(99396003)(86362001)(105586002)(2171001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0701MB1274; H:CY1PR0701MB1276.namprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; A:0; MX:1; LANG:en; received-spf: None (protection.outlook.com: stewe.org does not designate permitted sender hosts) Content-Type: text/plain; charset="utf-8" Content-ID: <243ED035359D484E871969635140CEBA@namprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: stewe.org X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Dec 2014 18:38:24.4870 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 865fc51c-5fae-4322-98ef-0121a85df0b6 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0701MB1274 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/_cKtAksfcsDSNhlrFBfJ8AQ8apo Subject: Re: [clue] Framework, level of mandation for providing dimensions X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Dec 2014 18:38:51 -0000 SGkgUm9uaSwNCg0KT24gMTIvMjkvMTQsIDEwOjUxLCAiUm9uaSBFdmVuIiA8cm9uLmV2ZW4udGx2 QGdtYWlsLmNvbT4gd3JvdGU6DQoNCj5IaSwNCj5UaGUgd2hvbGUgaWRlYSBvZiB0aGUgdGVsZXBy ZXNlbmNlIHdvcmsgd2FzIHRvIHByb3ZpZGUgdGhlIHJlcXVpcmVkDQo+aW5mb3JtYXRpb24gdGhh dCB3aWxsIGFsbG93IGZvciBvcHRpbWFsIHVzZXIgZXhwZXJpZW5jZSBhbmQgdG8NCj5zdGFuZGFy ZGl6ZSBpdC4NCg0KT2ssIHRoYXTigJlzIGEgc29saWQgYXJndW1lbnQuICBBbmQgaXTigJlzIGJ5 IG5vIG1lYW5zIGEgbm92ZWx0eSB0aGF0IHRoZSBJRVRGDQpzcGVjaWZpZXMgdGhpbmdzIHRoYXQg aW5kdXN0cnkgd2lsbCBvY2Nhc2lvbmFsbHkgaWdub3JlLiAgSeKAmW0gZmluZQ0KcmV2ZXJ0aW5n IGJhY2sgdG8gTVVTVCAobWVhbmluZzogbm8gY2hhbmdlIGZyb20gd2hhdCB3YXMgaW4gLTE5KS4N Cg0KDQpTdGVwaGFuDQoNCj5TYXlpbmcgdGhhdCBvbmUgdmVuZG9yIHdpbGwgd2FudCB0byBpZ25v cmUgaXQgdG8gbWFrZSB0aGUgb3RoZXIgc3lzdGVtDQo+YmFkIGlzIG1pc3NpbmcgdGhpcyB0YXJn ZXQgYW5kIGl0IHdpbGwgYmUgYmV0dGVyIHRvIGhhdmUgc3VjaCBzeXN0ZW0gYXMNCj5ub24tY29t cGxpYW50Lg0KPg0KPlRoZSB0ZXh0cyBzdGF0ZXMgdGhlIGNhc2VzIGZvciB1c2luZyBlYWNoIG9m IHRoZSBvcHRpb25zIHNvIHlvdSBtdXN0IGhhdmUNCj5hIHJlYXNvbiB0byBzZW5kIG5vIHNjYWxl LiBUaGUgZGF0YSBtb2RlbCByZXF1aXJlcyB5b3UgdG8gcHJvdmlkZSB0aGUNCj5pbmZvcm1hdGlv bi4gDQo+DQo+U28gbm9uLW5vcm1hdGl2ZSBhdCBhbGwgbWF5IGxvb2sgZ29vZCBidXQgSSBhbSBu b3Qgc3VyZSBpZiBpdCBtZWFucw0KPnNvbWV0aGluZyBhdCBhbGwuIEkgZXhwZWN0IHRoYXQgdGhl IGZyYW1ld29yayB3aWxsIHByb3ZpZGUgZ3VpZGVsaW5lcyBhbmQNCj5ub3JtYXRpdmUgbGFuZ3Vh Z2UgdG8gbWFrZSB0aGUgYmVzdCB1c2VyIGV4cGVyaWVuY2UgYW5kIHRoaXMgYXR0cmlidXRlIGlz DQo+YWJvdXQgaXQNCj4NCj5Sb25pDQo+DQo+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K Pj4gRnJvbTogY2x1ZSBbbWFpbHRvOmNsdWUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFN0ZXBoYW4gV2VuZ2VyDQo+PiBTZW50OiAyOSBEZWNlbWJlciwgMjAxNCA3OjM3IFBNDQo+PiBU bzogUGF1bCBLeXppdmF0OyBjbHVlQGlldGYub3JnDQo+PiBTdWJqZWN0OiBSZTogW2NsdWVdIEZy YW1ld29yaywgbGV2ZWwgb2YgbWFuZGF0aW9uIGZvciBwcm92aWRpbmcNCj4+ZGltZW5zaW9ucw0K Pj4gDQo+PiBBIG5vbi1ub3JtYXRpdmUg4oCcc2hvdWxk4oCdIHdvdWxkIHdvcmsgZm9yIG1lLg0K Pj4gU3RlcGhhbg0KPj4gDQo+PiBPbiAxMi8yOS8xNCwgMDk6MzIsICJQYXVsIEt5eml2YXQiIDxw a3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0KPj4gDQo+PiA+T24gMTIvMjkvMTQgMTI6MjYg UE0sIFN0ZXBoYW4gV2VuZ2VyIHdyb3RlOg0KPj4gPj4NCj4+ID4+DQo+PiA+PiBPbiAxMi8yOS8x NCwgMDc6MTAsICJQYXVsIEt5eml2YXQiIDxwa3l6aXZhdEBhbHVtLm1pdC5lZHU+IHdyb3RlOg0K Pj4gPj4NCj4+ID4+PiBPbiAxMi8yOS8xNCA1OjQ2IEFNLCBSb25pIEV2ZW4gd3JvdGU6DQo+PiA+ Pj4+IEhpIFN0ZXBoYW4sDQo+PiA+Pj4+DQo+PiA+Pj4+IEkgYW0gbm90IHN1cmUgd2hhdCBpcyB0 aGUgZGlmZmVyZW5jZSBoZXJlIGJldHdlZW4gYSBNVVNUIGFuZCBhDQo+PiBTSE9VTEQuDQo+PiA+ Pj4+IFNpbmNlIGl0IGlzIHJlcXVpcmVkIHRvIHNlbmQgdGhlIHNjYWxlIHZhbHVlIGluIHRoZSBk YXRhIG1vZGVsDQo+PiA+Pj4+DQo+PiA+Pj4+DQo+PiA+Pj4+KGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWNsdWUtZGF0YS1tb2RlbC1zY2hlbWEtMDcjc2UNCj4+ID4+Pj5j dGkNCj4+ID4+Pj5vbg0KPj4gPj4+PiAtMTUuNA0KPj4gPj4+PiApLCB3aGF0IGlzIHRoZSBTSE9V TEQgaGVyZT8NCj4+ID4+Pg0KPj4gPj4+IEkgZ3Vlc3MgaXQgcmVhbGx5IGlzbid0IG5lY2Vzc2Fy eSB0byBoYXZlIGFueSBub3JtYXRpdmUgbGFuZ3VhZ2UNCj4+ID4+PmFib3V0ICBpdGVtcyB0aGF0 IGFyZSByZXF1aXJlZCBpbiB0aGUgZGF0YSBtb2RlbCBzY2hlbWEuIFRoZQ0KPj4gPj4+bm9ybWF0 aXZlIGxhbmd1YWdlICBvdWdodCB0byBmb2N1cyBvbiB0aG9zZSBwbGFjZXMgd2hlcmUgdGhlcmUg aXMgYQ0KPj4gPj4+Y2hvaWNlIC0gaW4gdGhpcyBjYXNlICB3aGVuIGl0IG1ha2VzIHNlbnNlIHRv IHVzZSBub3NjYWxlLCB1bmtub3duLA0KPj4gPj4+YW5kIG1tLiBMYW5ndWFnZSBhYm91dCB0aGF0 ICBpcyBhbHJlYWR5IGluIHRoZSBkYXRhIG1vZGVsLCBidXQgaXNuJ3QNCj4+ID4+Pm5vcm1hdGl2 ZS4gQnV0IGl0IGlzIGNsZWFyICBlbm91Z2gsIHNvIG1heWJlIGFsbCBpcyBnb29kLg0KPj4gPj4N Cj4+ID4+IFRoZSByZWFzb24gb2YgdGhlIMKzU0hPVUxEwrIgaXMgdGhhdCBhIMKzTVVTVMKyIGlz IHVuc3VwZXJ2aXNhYmxlIGFuZA0KPj4gPj4gdW5lbmZvcmNpYmxlLg0KPj4gPj4NCj4+ID4+IFRo ZSBsYW5ndWFnZSBpbiB0aGUgZnJhbWV3b3JrIHN0YXRlZCB0aGF0IGEgc3lzdGVtIE1VU1QgaW5j bHVkZQ0KPj4gPj5tZWFzdXJlbWVudHMgd2hlbiB0aGV5IGFyZSBrbm93bi4gIFNvIHN1cHBvc2Ug eW91IGhhdmUgYSBzeXN0ZW0gdGhhdA0KPj4gPj5pcyAgYWxsIG1lYXN1cmVkIGluLCB2YWx1ZXMg ZW50ZXJlZCB0aHJvdWdoIGNvbmZpZyBmaWxlcyBvciBVSSwgYW5kDQo+PiA+PndoYXRub3QsICBy ZWFkeSB0byBnby4gIEhvdyBkb2VzIGEgcmVtb3RlIHN5c3RlbSBrbm93IHRoYXQ/ICBJdA0KPj4g Pj5kb2VzbsK5dC4gIEl0IG9ubHkgIGtub3dzIGl0IG9uY2UgaXQgc2VlcyB0aGUgbWVhc3VyZW1l bnRzIG9uIHRoZSB3aXJlLg0KPj4gPj5JZiB0aGUgbWVhc3VyZWQtaW4gIGVuZHBvaW50IGRlY2lk ZXMgbm90IHRvIHNlbmQgdGhvc2UgbWVhc3VyZW1lbnQNCj4+ID4+YmVjYXVzZSBpdCByYWlucywg YmVjYXVzZSAgaXTCuXMgTW9uZGF5LCBvciBiZWNhdXNlIGl0IGhhcyBzb21laG93DQo+PiA+Pmlk ZW50aWZpZWQgdGhlIHJlbW90ZSBzeXN0ZW0gdG8gYmUgIGZyb20gYSBjb21wZXRpdG9yIGFuZCBk b2VzIG5vdA0KPj4gPj53YW50IHRvIHNlbmQgdGhlIGJlc3QgcG9zc2libGUgbWVkaWEgdG8gIG1h a2UgdGhhdCByZW1vdGUgc3lzdGVtIGxvb2sNCj4+ID4+YmFkLCB0aGVyZSBpcyBub3RoaW5nIGFu eW9uZSBjb3VsZCBkby4gIE9yICBpZGVudGlmeSB0aGUgc2VuZGVyIGFzDQo+PiA+PmJyb2tlbiwg YmFzZWQgb24gYml0cyBvbiB0aGUgd2lyZS4NCj4+ID4+DQo+PiA+PiBJIHRoaW5rIHRoYXQgaXQg aXMgZ29vZCBwcmFjdGljZSBpbiBzeXN0ZW0gbGV2ZWwgc3RhbmRhcmRzIChhbmQNCj4+ID4+Z2Vu ZXJhbGx5ICB3aWRlbHkgZm9sbG93ZWQpIG5vdCB0byBwcm92aWRlIGhhcmQgTVVTVHMgKG9yIHNo YWxscyBvcg0KPj4gPj53aGF0ZXZlcikgZm9yICB1bnN1cGVydmlzYWJsZSBhbmQgdW5lbmZvcmNp YmxlIHByb3BlcnRpZXMuDQo+PiA+Pg0KPj4gPj4gVGhlIGRhdGEgbW9kZWwgc3RhdGVtZW50IGlz IGRpZmZlcmVudCwgSSB0aGluay4gIElmIEkgdW5kZXJzdGFuZCBpdA0KPj4gPj5jb3JyZWN0bHks IHRoZSBkYXRhIG1vZGVsIHNpbXBseSByZXF1aXJlcyB0aGUgbWVhc3VyZW1lbnRzIHRvIGJlDQo+ PiA+PnNpZ25hbGVkICB3aGVuIGEgY2VydGFpbiBtb2RlIGlzIHNpZ25hbGVkLiAgVGhhdMK5cyBh bGwgZmluZS4NCj4+ID4NCj4+ID5JIHRoaW5rIHlvdSBhcmUgbWFraW5nIHRoZSBjYXNlIHRoYXQg dGhpcyBzaG91bGRuJ3QgYmUgbm9ybWF0aXZlLiBTbw0KPj4gPmluc3RlYWQgb2YgTVVTVCBvciBT SE9VTEQsIHVzZSAic2hvdWxkIi4gQW5kIHRoYXQgaXMgd2hhdCBpcyBhbHJlYWR5DQo+PiA+ZG9u ZSBpbiB0aGUgZGF0YSBtb2RlbC4NCj4+ID4NCj4+ID4JVGhhbmtzLA0KPj4gPglQYXVsDQo+PiA+ DQo+PiA+PiBDbGVhcmVyPw0KPj4gPj4NCj4+ID4+IFN0ZXBoYW4NCj4+ID4+DQo+PiA+Pj4NCj4+ ID4+PiAJVGhhbmtzLA0KPj4gPj4+IAlQYXVsDQo+PiA+Pj4NCj4+ID4+Pj4gUm9uaSBFdmVuDQo+ PiA+Pj4+DQo+PiA+Pj4+IEFzIGluZGl2aWR1YWwNCj4+ID4+Pj4NCj4+ID4+Pj4gKkZyb206KmNs dWUgW21haWx0bzpjbHVlLWJvdW5jZXNAaWV0Zi5vcmddICpPbiBCZWhhbGYgT2YgKlN0ZXBoYW4N Cj4+ID4+Pj5XZW5nZXINCj4+ID4+Pj4gKlNlbnQ6KiAyOSBEZWNlbWJlciwgMjAxNCA0OjM1IEFN DQo+PiA+Pj4+ICpUbzoqIENMVUUNCj4+ID4+Pj4gKlN1YmplY3Q6KiBbY2x1ZV0gRnJhbWV3b3Jr LCBsZXZlbCBvZiBtYW5kYXRpb24gZm9yIHByb3ZpZGluZw0KPj4gPj4+PmRpbWVuc2lvbnMNCj4+ ID4+Pj4NCj4+ID4+Pj4gSGksDQo+PiA+Pj4+DQo+PiA+Pj4+IE1hcmsgYW5kIEkgYXJlIGVkaXRp bmcgdGhlIGZyYW1ld29yayBkb2N1bWVudCB0byBhZGRyZXNzIGNvbW1lbnRzLg0KPj4gPj4+Pg0K Pj4gPj4+PiBUaGlzIGlzIHdpdGggcmVmZXJlbmNlIHRvIG15IHJldmlldywgZGF0ZWQgMTIvMTYv MjAxNCwgYW5kDQo+PiA+Pj4+c3BlY2lmaWNhbGx5ICBwb2ludCA0IHRoZXJlaW4sIHJlcHJvZHVj ZWQgYXMgZm9sbG93czoNCj4+ID4+Pj4NCj4+ID4+Pj4gNC4gUGFnZSAxNSwgTVVTVCBzdHJlbmd0 aCBmb3IgcHJvdmlkaW5nIHBoeXNpY2FsIGRpbWVuc2lvbnMgb2YNCj4+ID4+Pj5rbm93biB0byAg dGhlIHN5c3RlbS4gIEkgbGlrZSB0aGlzIHBoaWxvc29waGljYWxseSwgYnV0IEkgdGhpbmsgaXTC uXMNCj4+ID4+Pj5tZWFuaW5nbGVzcyAgaW4gcHJhY3RpY2UsIGFzIHRoZSBrbm93bGVkZ2Ugb2Yg Y29vcmRpbmF0ZXMgb2YgYQ0KPj4gPj4+PnBQcm92aWRlciBpcyBrbm93biB0byAgdGhlIGNvbnN1 bWVyIG9ubHkgYXMgYSBzaWRlIGVmZmVjdCBvZiBzZW5kaW5nDQo+PiA+Pj4+dGhlIG1lYXN1cmVt ZW50cywgcmlnaHQ/DQo+PiA+Pj4+ICAgIFBlcmhhcHMgbGVzcyBkcmFjb25pYW4gbGFuZ3VhZ2Ug aXMgbW9yZSBhcHByb3ByaWF0ZT8gIFNvdW5kcyB0bw0KPj4gPj4+Pm1lICBsaWtlIGEgZ29vZCBw bGFjZSBmb3IgYSDCs1NIT1VMRMKyPw0KPj4gPj4+Pg0KPj4gPj4+PiBVbmxlc3Mgc29tZW9uZSBv YmplY3RzIHRoZSB0d28gTVVTVCBzdGF0ZW1lbnRzIGluIHNlY3Rpb24gNiwgc2Vjb25kDQo+PiA+ Pj4+IGJ1bGxldCAocGFnZSAxNSkgd2lsbCBiZSByZXBsYWNlZCB3aXRoIGxlc3MgZHJhY29uaWFu IFNIT1VMRC4gIFRoZQ0KPj4gPj4+PiBtb2RpZmllZCBidWxsZXQgaW4gbWFya3VwIGlzIHNob3du IGJlbG93Lg0KPj4gPj4+Pg0KPj4gPj4+PiBJIHN1Z2dlc3QgYSBkZWFkbGluZSBvZiBKYW51YXJ5 IDksIDIwMTUsIGJ1dCBkbyBzbyB3aXRob3V0IGNoZWNraW5nDQo+PiA+Pj4+d2l0aCAgdGhlIGNo YWlyc+KAuXdobyBhcmUgb2YgY291cnNlIGZyZWUgdG8gc2V0IGEgZGlmZmVyZW50IGRhdGUgaWYN Cj4+ID4+Pj50aGV5ICBjaG9vc2Ugc28uDQo+PiA+Pj4+DQo+PiA+Pj4+IFJlZ2FyZHMsDQo+PiA+ Pj4+DQo+PiA+Pj4+IFN0ZXBoYW4NCj4+ID4+Pj4NCj4+ID4+Pj4gICAgbyAgQ29vcmRpbmF0ZXMg Y2FuIGJlIGVpdGhlciBpbiByZWFsLCBwaHlzaWNhbCB1bml0cw0KPj4gPj4+PiAobWlsbGltZXRl cnMpLA0KPj4gPj4+Pg0KPj4gPj4+PiAgICAgICAgIGhhdmUgYW4gdW5rbm93biBzY2FsZSBvciBo YXZlIG5vIHBoeXNpY2FsIHNjYWxlLiAgU3lzdGVtcw0KPj4gPj4+PndoaWNoDQo+PiA+Pj4+DQo+ PiA+Pj4+ICAgICAgICAga25vdyB0aGVpciBwaHlzaWNhbCBkaW1lbnNpb25zIChmb3IgZXhhbXBs ZSBwcm9mZXNzaW9uYWxseQ0KPj4gPj4+Pg0KPj4gPj4+PiAgICAgICAgIGluc3RhbGxlZCBUZWxl cHJlc2VuY2Ugcm9vbSBzeXN0ZW1zKU1VU1QgIF9TSE9VTERfICBhbHdheXMNCj4+ID4+Pj4gcHJv dmlkZSB0aG9zZQ0KPj4gPj4+Pg0KPj4gPj4+PiAgICAgICAgIHJlYWwtd29ybGQgbWVhc3VyZW1l bnRzLiAgU3lzdGVtcyB3aGljaCBkb24ndCBrbm93IHNwZWNpZmljDQo+PiA+Pj4+DQo+PiA+Pj4+ ICAgICAgICAgcGh5c2ljYWwgZGltZW5zaW9ucyBidXQgc3RpbGwga25vdyByZWxhdGl2ZSBkaXN0 YW5jZXNNVVNUDQo+PiA+Pj4+IF9TSE9VTERfICB1c2UNCj4+ID4+Pj4NCj4+ID4+Pj4gICAgICAg ICAndW5rbm93biBzY2FsZScuICAnTm8gc2NhbGUnIGlzIGludGVuZGVkIHRvIGJlIHVzZWQgd2hl cmUNCj4+ID4+Pj5NZWRpYQ0KPj4gPj4+Pg0KPj4gPj4+PiAgICAgICAgIENhcHR1cmVzIGZyb20g ZGlmZmVyZW50IGRldmljZXMgKHdpdGggcG90ZW50aWFsbHkgZGlmZmVyZW50DQo+PiA+Pj4+DQo+ PiA+Pj4+ICAgICAgICAgc2NhbGVzKSB3aWxsIGJlIGZvcndhcmRlZCBhbG9uZ3NpZGUgb25lIGFu b3RoZXIgKGUuZy4gaW4NCj4+ID4+Pj4gdGhlDQo+PiA+Pj4+DQo+PiA+Pj4+ICAgICAgICAgY2Fz ZSBvZiBhbiBNQ1UpLg0KPj4gPj4+Pg0KPj4gPj4+Pg0KPj4gPj4+Pg0KPj4gPj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gPj4+PiBjbHVlIG1h aWxpbmcgbGlzdA0KPj4gPj4+PiBjbHVlQGlldGYub3JnDQo+PiA+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPj4gPj4+Pg0KPj4gPj4+DQo+PiA+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID4+PiBjbHVl IG1haWxpbmcgbGlzdA0KPj4gPj4+IGNsdWVAaWV0Zi5vcmcNCj4+ID4+PiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NsdWUNCj4+ID4+DQo+PiA+Pg0KPj4gPg0KPj4gDQo+ PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gY2x1 ZSBtYWlsaW5nIGxpc3QNCj4+IGNsdWVAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vY2x1ZQ0KPg0KDQo=