From mary.ietf.barnes@gmail.com Wed Jan 2 07:57:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F61321F861C for ; Wed, 2 Jan 2013 07:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSYmslk2U4jD for ; Wed, 2 Jan 2013 07:57:57 -0800 (PST) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) by ietfa.amsl.com (Postfix) with ESMTP id E290221F85D2 for ; Wed, 2 Jan 2013 07:57:56 -0800 (PST) Received: by mail-qa0-f42.google.com with SMTP id hg5so11675980qab.15 for ; Wed, 02 Jan 2013 07:57:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=pF/peUprABnR4dfFNLn6RYxz656kOsui26nP5vCxycs=; b=patq7mhbIhdzWcPvYKTNzzSVR/X9I7HRz4DcWsyz+YHNwTm0602ALIVAs0KSriXb0U LUB75rA7pzNKKg7/PI1mMlJAySPMb3yDewUtohxTqlC9Fn57ITLMEjWNJ100iIyAPSxd y+aH8S5SHwhLOnLgid5WG3bmTEG6TSeoEQhoZ0KojetQ9MO27hX9wQDXhsYljPm6oS3K DPtsSY8/KuP2j7ui0/3EwjB8N/llGbWJlhFBTOxJOTGmjxl3aT+w3PagAovNYm0plxii 61bMfHrGZlnFlSFJfsnW7g509MHNS728LTDlydia5xejdHBxlnFiVLKEc4nYNW1ZjZLd G+0g== MIME-Version: 1.0 Received: by 10.224.179.211 with SMTP id br19mr22966061qab.43.1357142276469; Wed, 02 Jan 2013 07:57:56 -0800 (PST) Received: by 10.49.131.199 with HTTP; Wed, 2 Jan 2013 07:57:56 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Jan 2013 09:57:56 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/mixed; boundary=485b397dcfdd4c74a004d2504f49 Subject: [clue] Fwd: New framework I-D posted X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 15:57:57 -0000 --485b397dcfdd4c74a004d2504f49 Content-Type: text/plain; charset=ISO-8859-1 Hi folks, It would be really good for folks to take the time to review the updated document this week and post any comments/questions to the list. We can then discuss this on next Monday's call (Jan. 7th @ 10am Central). Just a point of curiosity to the authors, what was the motivation for switching back to Winword? If it's a lack of an XML editor, there are some decent quality freeware ones out there, including some WYSIWG add ons. Thanks, Mary. ---------- Forwarded message ---------- From: Stephan Wenger Date: Mon, Dec 24, 2012 at 6:49 PM Subject: [clue] New framework I-D posted To: "clue@ietf.org" Hi all, I just posted an update to the framework draft. Most of the changes are in the introduction, covering the basic outline of the CLUE operation as discussed during the design team call. It is our intention to streamline this section later and to move out some of the information into sections more appropriate than the intro. In the spirit of avoiding "misapplying yesterday's technology today", we are using Winword between us editors now, so there is no XML version. This resulted also in formatting changes which is going to make the diff a bit less useful than usual. It will be better from the next version onwards. If you want the word file, please contact me. Stephan _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue --485b397dcfdd4c74a004d2504f49 Content-Type: message/rfc822 Content-Disposition: attachment Content-Transfer-Encoding: base64 Content-ID: <9B170F1A978A7E49A4F1E7A009DE0ADC@namprd07.prod.outlook.com> X-Attachment-Id: a49b4ad82bba7842_0.1 UmVjZWl2ZWQ6IGZyb20gQkxVUFJEMDcxMkhUMDAyLm5hbXByZDA3LnByb2Qub3V0bG9vay5jb20g KDEwLjI1NS4yMTguMTYzKSBieQ0KIEJZMlBSRDA3MTBIVDAwMy5uYW1wcmQwNy5wcm9kLm91dGxv b2suY29tICgxMC4yNTUuODYuMzgpIHdpdGggTWljcm9zb2Z0IFNNVFANCiBTZXJ2ZXIgKFRMUykg aWQgMTQuMTYuMjQ1LjI7IFR1ZSwgMjUgRGVjIDIwMTIgMDA6NDQ6MjIgKzAwMDANClJlY2VpdmVk OiBmcm9tIEJMVVBSRDA3MTJIVDAwMS5uYW1wcmQwNy5wcm9kLm91dGxvb2suY29tICgxMC4yNTUu MjE4LjE2MikgYnkNCiBCTFVQUkQwNzEySFQwMDIubmFtcHJkMDcucHJvZC5vdXRsb29rLmNvbSAo MTAuMjU1LjIxOC4xNjMpIHdpdGggTWljcm9zb2Z0DQogU01UUCBTZXJ2ZXIgKFRMUykgaWQgMTQu MTYuMjQ1LjI7IFR1ZSwgMjUgRGVjIDIwMTIgMDA6NDQ6MjIgKzAwMDANClJlY2VpdmVkOiBmcm9t IG1haWw5My12YTMtUi5iaWdmaXNoLmNvbSAoMjE2LjMyLjE4MC4xMTcpIGJ5DQogQkxVUFJEMDcx MkhUMDAxLm5hbXByZDA3LnByb2Qub3V0bG9vay5jb20gKDEwLjI1NS4yMTguMTYyKSB3aXRoIE1p Y3Jvc29mdA0KIFNNVFAgU2VydmVyIChUTFMpIGlkIDE0LjE2LjI0NS4yOyBUdWUsIDI1IERlYyAy MDEyIDAwOjQ0OjIxICswMDAwDQpSZWNlaXZlZDogZnJvbSBtYWlsOTMtdmEzIChsb2NhbGhvc3Qg WzEyNy4wLjAuMV0pCWJ5IG1haWw5My12YTMtUi5iaWdmaXNoLmNvbQ0KIChQb3N0Zml4KSB3aXRo IEVTTVRQIGlkIDlEQkZCMzQwMTBBCWZvciA8c3Rld2VAc3Rld2Uub3JnPjsgVHVlLCAyNSBEZWMg MjAxMg0KIDAwOjQ0OjIxICswMDAwIChVVEMpDQpYLUZvcmVmcm9udC1BbnRpc3BhbS1SZXBvcnQ6 IENJUDo2NC4xNzAuOTguMzA7S0lQOihudWxsKTtVSVA6KG51bGwpO0lQVjpOTEk7SDptYWlsLmll dGYub3JnO1JEOm1haWwuaWV0Zi5vcmc7RUZWRDpOTEkNClgtU3BhbVNjb3JlOiAtMjANClgtQmln RmlzaDogcHMtMjAoeno5MzZlSXp6MWRlMGgxMjAyaDFlNzZoMWQxYWgxZDJhaHp6ODI3NWRoMTAz M0lMMTczMjZhaHoyZmg2NjhoODM5aDkzZmhkMjRoMTI4OGgxMmE1aDEyYTloMTJiZGgxMzdhaDEz YjZoMTNlYWgxNDQxaDE0ZGRoMTUwNGgxNTM3aDE1M2JoMTYyZGgxNjMxaDE3NThoMTY2NGkxMTU1 aCkNClJlY2VpdmVkLVNQRjogcGFzcyAobWFpbDkzLXZhMzogZG9tYWluIG9mIGlldGYub3JnIGRl c2lnbmF0ZXMgNjQuMTcwLjk4LjMwIGFzIHBlcm1pdHRlZCBzZW5kZXIpIGNsaWVudC1pcD02NC4x NzAuOTguMzA7IGVudmVsb3BlLWZyb209aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnOyBoZWxvPW1h aWwuaWV0Zi5vcmcgO2FpbC5pZXRmLm9yZyA7DQpSZWNlaXZlZDogZnJvbSBtYWlsOTMtdmEzIChs b2NhbGhvc3QubG9jYWxkb21haW4gWzEyNy4wLjAuMV0pIGJ5IG1haWw5My12YTMNCiAoTWVzc2Fn ZVN3aXRjaCkgaWQgMTM1NjM5NjI1OTQwODM1XzI5NzA3OyBUdWUsIDI1IERlYyAyMDEyIDAwOjQ0 OjE5ICswMDAwDQogKFVUQykNClJlY2VpdmVkOiBmcm9tIFZBM0VIU01IUzAzMy5iaWdmaXNoLmNv bSAodW5rbm93biBbMTAuNy4xNC4yMzVdKQlieQ0KIG1haWw5My12YTMuYmlnZmlzaC5jb20gKFBv c3RmaXgpIHdpdGggRVNNVFAgaWQgMDVBRDA0RTAwNzQJZm9yDQogPHN0ZXdlQHN0ZXdlLm9yZz47 IFR1ZSwgMjUgRGVjIDIwMTIgMDA6NDQ6MTkgKzAwMDAgKFVUQykNClJlY2VpdmVkOiBmcm9tIG1h aWwuaWV0Zi5vcmcgKDY0LjE3MC45OC4zMCkgYnkgVkEzRUhTTUhTMDMzLmJpZ2Zpc2guY29tDQog KDEwLjcuOTkuNDMpIHdpdGggTWljcm9zb2Z0IFNNVFAgU2VydmVyIGlkIDE0LjEuMjI1LjIzOyBU dWUsIDI1IERlYyAyMDEyDQogMDA6NDQ6MTggKzAwMDANClJlY2VpdmVkOiBmcm9tIGxvY2FsaG9z dCAobG9jYWxob3N0IFsxMjcuMC4wLjFdKQlieSBpZXRmYS5hbXNsLmNvbSAoUG9zdGZpeCkNCiB3 aXRoIEVTTVRQIGlkIDI4RTRFMjFGOEI0ODsJTW9uLCAyNCBEZWMgMjAxMiAxNjo0NDoxOCAtMDgw MCAoUFNUKQ0KWC1WaXJ1cy1TY2FubmVkOiBhbWF2aXNkLW5ldyBhdCBhbXNsLmNvbQ0KUmVjZWl2 ZWQ6IGZyb20gbWFpbC5pZXRmLm9yZyAoWzY0LjE3MC45OC4zMF0pCWJ5IGxvY2FsaG9zdCAoaWV0 ZmEuYW1zbC5jb20NCiBbMTI3LjAuMC4xXSkgKGFtYXZpc2QtbmV3LCBwb3J0IDEwMDI0KQl3aXRo IEVTTVRQIGlkIGZiSHZ0a2o0ZVI0UzsgTW9uLCAyNA0KIERlYyAyMDEyIDE2OjQ0OjE3IC0wODAw IChQU1QpDQpSZWNlaXZlZDogZnJvbSBpZXRmYS5hbXNsLmNvbSAobG9jYWxob3N0IFsxMjcuMC4w LjFdKQlieSBpZXRmYS5hbXNsLmNvbQ0KIChQb3N0Zml4KSB3aXRoIEVTTVRQIGlkIEJCRjRCMjFG OEFBMzsJTW9uLCAyNCBEZWMgMjAxMiAxNjo0NDoxNyAtMDgwMCAoUFNUKQ0KRnJvbTogPGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZz4NClRvOiA8c3Rld2VAc3Rld2Uub3JnPg0KQ0M6IDxtYXJrLmR1 Y2t3b3J0aEBwb2x5Y29tLmNvbT4sIDxhcGVwcGVyZUBnbWFpbC5jb20+DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWlldGYtY2x1ZS1mcmFtZXdvcmstMDgudHh0 DQpYLVRlc3QtSURUcmFja2VyOiBubw0KWC1JRVRGLUlEVHJhY2tlcjogNC4zNw0KTWVzc2FnZS1J RDogPDIwMTIxMjI1MDA0NDE3LjI2MDc2LjQ3NzM1LmlkdHJhY2tlckBpZXRmYS5hbXNsLmNvbT4N CkRhdGU6IE1vbiwgMjQgRGVjIDIwMTIgMTY6NDQ6MTcgLTA4MDANClJldHVybi1QYXRoOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmcNClgtTVMtRXhjaGFuZ2UtT3JnYW5pemF0aW9uLVNDTDogMQ0K WC1NUy1FeGNoYW5nZS1Pcmdhbml6YXRpb24tQVZTdGFtcC1NYWlsYm94OiBNU0ZURkY7MTswOzAg MCAwDQpYLU1TLUV4Y2hhbmdlLU9yZ2FuaXphdGlvbi1BdXRoU291cmNlOiBCTFVQUkQwNzEySFQw MDEubmFtcHJkMDcucHJvZC5vdXRsb29rLmNvbQ0KWC1NUy1FeGNoYW5nZS1Pcmdhbml6YXRpb24t QXV0aEFzOiBBbm9ueW1vdXMNCkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0iVVMt QVNDSUkiDQpDb250ZW50LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0DQpNSU1FLVZlcnNpb246IDEu MA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLWNsdWUtZnJhbWV3b3JrLTA4 LnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGVwaGFuIFdlbmdlciBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LWll dGYtY2x1ZS1mcmFtZXdvcmsNClJldmlzaW9uOgkgMDgNClRpdGxlOgkJIEZyYW1ld29yayBmb3Ig VGVsZXByZXNlbmNlIE11bHRpLVN0cmVhbXMNCkNyZWF0aW9uIGRhdGU6CSAyMDEyLTEyLTI0DQpX RyBJRDoJCSBjbHVlDQpOdW1iZXIgb2YgcGFnZXM6IDQyDQpVUkw6ICAgICAgICAgICAgIA0KaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaWV0Zi1jbHVlLWZyYW1ld29y ay0wOC50eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1pZXRmLWNsdWUtZnJhbWV3b3JrDQpIdG1saXplZDogICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtY2x1ZS1mcmFtZXdvcmstMDgNCkRpZmY6ICAgICAg ICAgICAgDQpodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLWNsdWUt ZnJhbWV3b3JrLTA4DQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1vIG9mZmVycyBhIGZyYW1ld29y ayBmb3IgYSBwcm90b2NvbCB0aGF0IGVuYWJsZXMgZGV2aWNlcw0KICAgaW4gYSB0ZWxlcHJlc2Vu Y2UgY29uZmVyZW5jZSB0byBpbnRlcm9wZXJhdGUgYnkgc3BlY2lmeWluZyB0aGUNCiAgIHJlbGF0 aW9uc2hpcHMgYmV0d2VlbiBtdWx0aXBsZSBtZWRpYSBzdHJlYW1zLg0KDQogICAgICAgICAgICAg ICAgICANCg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCg0KDQo= --485b397dcfdd4c74a004d2504f49-- From mary.ietf.barnes@gmail.com Wed Jan 2 09:02:09 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1DA021F8613 for ; Wed, 2 Jan 2013 09:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSL+Ji+eIpEC for ; Wed, 2 Jan 2013 09:02:07 -0800 (PST) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) by ietfa.amsl.com (Postfix) with ESMTP id A36A921F850D for ; Wed, 2 Jan 2013 09:02:07 -0800 (PST) Received: by mail-qa0-f43.google.com with SMTP id cr7so11732446qab.2 for ; Wed, 02 Jan 2013 09:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=0iUtxl1Etfcf2oLntHZ6TmkC1A7aJLViNAdNthX9WDM=; b=Zxzf5bkA7S/LglK69AZdmlO/wdJmZC1xYKA6+DvzJMyyCXATm7jteLcB3zRfkfvqH2 UoAr8fgRQVGoWbu9oImTWDEZltoaEhIKxCTz6aBHCmmH9YomTVNnpzzgZKoIdqZt50U9 yQNEt9z/+4K6+gB/S5naiQEvP3jsgNixhte+Uw3j1xh5M3bbxNUvcIepLVNG92jwwxX7 RwmnxZIIJnzLohy7dpLkS62pafJzeHts9eKwbavWWoD/9yBIbXlNctxOcd5rHiVrM06K RfXO5uNJonRKSKeHOKOe1CljvA8771WjvIq6cSh1a/4v8A5UeInutNhRhJgIDe7cCWs+ K4mA== MIME-Version: 1.0 Received: by 10.224.179.211 with SMTP id br19mr23196779qab.43.1357146127125; Wed, 02 Jan 2013 09:02:07 -0800 (PST) Received: by 10.49.131.199 with HTTP; Wed, 2 Jan 2013 09:02:06 -0800 (PST) In-Reply-To: References: Date: Wed, 2 Jan 2013 11:02:06 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [clue] Doodle Poll: CLUE WG Interim Meeting - Jan 21, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Jan 2013 17:02:09 -0000 We had a terrible response to the poll - both in numbers and results. I hope this does not reflect level of interest in getting the CLUE work done, but rather that the date was not good for the majority. So, we will NOT be having a virtual interim on Jan 21st. We *may* have a design team meeting during the regular slot IF we can get enough discussion and proposals on the table within the next couple weeks. Per my earlier email on the framework document updates, we will have a call as planned on Jan. 7th. We can see how things go over the next few weeks and decide whether a virtual interim on Feb. 11th would be useful. As always comments or concerns on the work/meeting plans can be raised on the list or please contact both chairs offlist. Thanks, Mary. On Tue, Dec 18, 2012 at 1:13 PM, Mary Barnes wrote: > Hi all, > > Per the Plans for 2013 email: > > please respond to this Doodle poll, so we can find the optimal time > for a 2 hour virtual interim meeting on Jan. 21st: > http://www.doodle.com/rbee8q2ry5prtbba > > The focus of this virtual interim would be the Framework document (and > data model as time allows). We would like to get resolution on the > open issues. The expectation is that there would be an updated > Framework document, including updated content based on discussion at > Dec. 3rd design team meeting as well as the proposed refactoring, no > later than Jan 14th to allow the group time to review before the > meeting. > > Thanks, > Mary. From spromano@unina.it Fri Jan 4 09:20:29 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3FC21F85ED for ; Fri, 4 Jan 2013 09:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.718 X-Spam-Level: X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vVOgVTt+cxkS for ; Fri, 4 Jan 2013 09:20:27 -0800 (PST) Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3FE21F85E6 for ; Fri, 4 Jan 2013 09:20:27 -0800 (PST) Received: from [192.168.1.111] ([151.77.186.103]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r04HKHuw001718 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 4 Jan 2013 18:20:18 +0100 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2E0E2D61-3B7F-46C2-9B2C-50AF532BF377" From: Simon Pietro Romano In-Reply-To: Date: Fri, 4 Jan 2013 18:20:20 +0100 Message-Id: References: To: clue@ietf.org X-Mailer: Apple Mail (2.1283) Subject: Re: [clue] New framework I-D posted X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2013 17:20:30 -0000 --Apple-Mail=_2E0E2D61-3B7F-46C2-9B2C-50AF532BF377 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, I just read the new framework document. I'll try to report in this mail = a couple of considerations, with the aim of fostering further discussion = on the list. =46rom a high-level perspective, my first comment is that I am afraid we = are still stuck on the very basic issue of defining the inner workings = of clue, in terms of protocol, protocol messages, call flows and the = like. I think the situation is much better when it comes to the data model, = which is now in a pretty good shape (it can definitely be fine-tuned, = but I see no major outstanding issue).=20 With respect to the inner workings, I thought we had somehow agreed on = the fact that CLUE is, in a nutshell, a sort of enriched O/A based on = advanced SDP-based negotiations (involving all the work-in-progress = stuff on RTP mapping/multiplexing) and relying on a dedicated CLUE = channel which is used to transfer all information that does not fit into = SDP (e.g., spatial information). Just to summarize my current = understanding, and per Stephan's e-mail of December 1st 2012, the phases = involved should be something like: > With reference to the call flow 02 doc = (https://datatracker.ietf.org/doc/draft-romanow-clue-call-flow/?include_te= xt=3D1) that exchange could look as follows: > Invite from Alice, just like A.1 in call-flow-02 > 200 OK from Bob, A.2 > CLUE Advertisement Alice A.3, covering geometry stuff, encoding = groups, etc. > CLUE Advertisement Bob A.4; note that 3 and 4 would in practice = overlap in time > CLUE Response from Alice A.5, with the difference that these reposes = DO NOT have the side effect of initiating any media channel related = activity; they are pure signaling > CLUE Response from Bob, A.6, same remark.. 5 and 6 could overlap in = time. > Re-invite from Alice and Bob, respectively, with media channels as = CLUE-"negotiated" > 200 OK from Bob, Alice. As the endpoints have already established = their operation points through CLUE, this step will not fail except if = an entity not involved in the CLUE negotiation intervenes=97i.e. a = middle box doesn't like that call. The above steps are quite nicely reported in the Introduction of the new = draft (outline starting at the end of page 4). By reading that part of = the document (as well as the cited e-mail thread), I once again realize = we need to clearly define what we mean by 'Advertisement'. Is this a = message flowing across the CLUE channel and containing just the stuff = that cannot be mapped onto SDP? Or is it a higher-level message = containing general information about a clue telepresence room and which = can be transported partially inside SDP and partially across the clue = channel (for the parts that do not match any SDP structure)? The = difference is in my view important, because in the latter case every = time we state we 'send and advertisement' (like, e.g., in points 3. and = 4. above), we mean we are sending "one SDP offer on the vanilla SIP = channel + one clue message on the clue meta-channel". I don't know what = is other people's opinion on this, but I think it is fundamental we = converge on an agreed-upon definition. If we went for the latter = approach, we might state in the framework that the advertisement is a = 'logical' message having a well defined structure and which can be = 'partially' mapped onto SDP. Somehow related to the above point, I got completely lost when I arrived = at section 9.4 (message flow, pages 26 and 27). The introduction of the = "Consumer capabilities" message and related "Capture Advertisement" and = "Configure Encodings" sounds totally new to me. I read the note about = the authors' thinking and I believe this idea goes into the direction = sketched by someone at the last meeting (if I recall correctly, it was = stated stated that it might be useful to somehow pre-filter the = advertisement sent by a provider) and which did not get that much = consensus. Just correct me if I'm wrong. In any case, this introduces a = brand new perspective inside clue signaling, which should be better = introduced and illustrated in the introductory part. Anyhow, coming back to the document's structure, I keep on believing we = should avoid putting into the framework document too many details about = the data model. I'd prefer the framework to contain high-level = descriptions of the overall architecture, protocol, messages, data model = and call flows. The reader of this document should come out with a clear = idea of what CLUE means and does, while being redirected to the = companion documents for the details. Practically speaking, I would = suggest to move most of the material currently contained in sections 5 = through 8 to the data model draft (which should also contain the XML = schema). The framework might elaborate more on the big picture and try = and clarify the overall functionality of clue. What do the others think = of this? Finally, a few minor nits: - I would avoid explicitly mentioning H264-related stuff in the data = model (like with macroblocks -- maxH264Mbps) - why is the ID of the EncodingGroup called 'encodeGroupID' and not = 'encodingGroupID' ? - section 10, first bullet: replace 'can done' with 'can be done' - section 10, third bullet: "Adding new codecs" --> remove 'a' That's all for now. Cheers, Simon Il giorno 02/gen/2013, alle ore 16:57, Mary Barnes ha scritto: > Hi folks, >=20 > It would be really good for folks to take the time to review the > updated document this week and post any comments/questions to the > list. We can then discuss this on next Monday's call (Jan. 7th @ 10am > Central). >=20 > Just a point of curiosity to the authors, what was the motivation for > switching back to Winword? If it's a lack of an XML editor, there > are some decent quality freeware ones out there, including some WYSIWG > add ons. >=20 > Thanks, > Mary. >=20 >=20 > ---------- Forwarded message ---------- > From: Stephan Wenger > Date: Mon, Dec 24, 2012 at 6:49 PM > Subject: [clue] New framework I-D posted > To: "clue@ietf.org" >=20 >=20 > Hi all, > I just posted an update to the framework draft. Most of the changes > are in the introduction, covering the basic outline of the CLUE > operation as discussed during the design team call. It is our > intention to streamline this section later and to move out some of the > information into sections more appropriate than the intro. > In the spirit of avoiding "misapplying yesterday's technology today", > we are using Winword between us editors now, so there is no XML > version. This resulted also in formatting changes which is going to > make the diff a bit less useful than usual. It will be better from > the next version onwards. If you want the word file, please contact > me. > Stephan >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_2E0E2D61-3B7F-46C2-9B2C-50AF532BF377 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = all,

I just read the new framework document. I'll try = to report in this mail a couple of considerations, with the aim of = fostering further discussion on the list.

=46rom = a high-level perspective, my first comment is that I am afraid we are = still stuck on the very basic issue of defining the inner workings of = clue, in terms of protocol, protocol messages, call flows and the = like.
I think the situation is much better when it comes to = the data model, which is now in a pretty good shape (it can definitely = be fine-tuned, but I see no major outstanding = issue). 
With respect to the inner workings, I thought we = had somehow agreed on the fact that CLUE is, in a nutshell, a sort of = enriched O/A based on advanced SDP-based negotiations (involving all the = work-in-progress stuff on RTP mapping/multiplexing) and relying on a = dedicated CLUE channel which is used to transfer all information that = does not fit into SDP (e.g., spatial information). Just to summarize my = current understanding, and per Stephan's e-mail of December 1st 2012, = the phases involved should be something = like:

With reference to = the call flow 02 doc (https://datatracker.ietf.org/doc/draft-romanow-clue-call-fl= ow/?include_text=3D1) that exchange could look as = follows:
  1. Invite from Alice, just like A.1 in = call-flow-02
  2. 200 OK from Bob, A.2
  3. CLUE Advertisement = Alice A.3, covering geometry stuff, encoding groups, etc.
  4. CLUE = Advertisement Bob A.4; note that 3 and 4 would in practice overlap in = time
  5. CLUE Response from Alice A.5, with the difference that = these reposes DO NOT have the side effect of initiating any media = channel related activity; they are pure signaling
  6. CLUE Response = from Bob, A.6, same remark.. 5 and 6 could overlap in = time.
  7. Re-invite from Alice and Bob, respectively, with media = channels as CLUE-"negotiated"
  8. 200 OK from Bob, Alice.  As = the endpoints have already established their operation points through = CLUE, this step will not fail except if an entity not involved in the = CLUE negotiation intervenes=97i.e. a middle box doesn't like that = call.
The above steps are quite = nicely reported in the Introduction of the new draft (outline starting = at the end of page 4). By reading that part of the document (as well as = the cited e-mail thread), I once again realize we need to clearly define = what we mean by 'Advertisement'. Is this a message flowing across the = CLUE channel and containing just the stuff that cannot be mapped onto = SDP? Or is it a higher-level message containing general information = about a clue telepresence room and which can be transported partially = inside SDP and partially across the clue channel (for the parts that do = not match any SDP structure)? The difference is in my view important, = because in the latter case every time we state we 'send and = advertisement' (like, e.g., in points 3. and 4. above), we mean we are = sending "one SDP offer on the vanilla SIP channel + one clue message on = the clue meta-channel". I don't know what is other people's opinion on = this, but I think it is fundamental we converge on an agreed-upon = definition. If we went for the latter approach, we might state in the = framework that the advertisement is a 'logical' message having a well = defined structure and which can be 'partially' mapped onto = SDP.

Somehow related to the above point, = I got completely lost when I arrived at section 9.4 (message flow, pages = 26 and 27). The introduction of the "Consumer capabilities" message and = related "Capture Advertisement" and "Configure Encodings" sounds totally = new to me. I read the note about the authors' thinking and I believe = this idea goes into the direction sketched by someone at the last = meeting (if I recall correctly, it was stated stated that it might be = useful to somehow pre-filter the advertisement sent by a provider) and = which did not get that much consensus. Just correct me if I'm wrong. In = any case, this introduces a brand new perspective inside clue signaling, = which should be better introduced and illustrated in the introductory = part.

Anyhow, coming back to the document's = structure, I keep on believing we should avoid putting into the = framework document too many details about the data model. I'd prefer the = framework to contain high-level descriptions of the overall = architecture, protocol, messages, data model and call flows. The reader = of this document should come out with a clear idea of what CLUE means = and does, while being redirected to the companion documents for the = details. Practically speaking, I would suggest to move most of the = material currently contained in sections 5 through 8 to the data model = draft (which should also contain the XML schema). The framework might = elaborate more on the big picture and try and clarify the overall = functionality of clue. What do the others think of = this?

Finally, a few minor = nits:

- I would avoid explicitly mentioning = H264-related stuff in the data model (like with macroblocks -- = maxH264Mbps)
- why is the ID of the EncodingGroup called = 'encodeGroupID' and not 'encodingGroupID' ?
- section 10, = first bullet: replace 'can done' with 'can be done'
- section = 10, third bullet: "Adding  new codecs" --> remove = 'a'

That's all for = now.

Cheers,

Simon
=




Il = giorno 02/gen/2013, alle ore 16:57, Mary Barnes ha scritto:

Hi = folks,

It would be really good for folks to take the time to = review the
updated document this week and post any comments/questions = to the
list.  We can then discuss this on next Monday's call = (Jan. 7th @ 10am
Central).

Just a point of curiosity to the = authors, what was the motivation for
switching back to Winword? =     If it's a lack of an XML editor, there
are = some decent quality freeware ones out there, including some = WYSIWG
add ons.

Thanks,
Mary.


---------- = Forwarded message ----------
From: Stephan Wenger <stewe@stewe.org>
Date: Mon, = Dec 24, 2012 at 6:49 PM
Subject: [clue] New framework I-D = posted
To: "clue@ietf.org" = <clue@ietf.org>


Hi = all,
I just posted an update to the framework draft.  Most of = the changes
are in the introduction, covering the basic outline of = the CLUE
operation as discussed during the design team call.  It = is our
intention to streamline this section later and to move out = some of the
information into sections more appropriate than the = intro.
In the spirit of avoiding "misapplying yesterday's technology = today",
we are using Winword between us editors now, so there is no = XML
version.   This resulted also in formatting changes = which is going to
make the diff a bit less useful than usual. =  It will be better from
the next version onwards.  If you = want the word file, please = contact
me.
Stephan


_____________________________________= __________
clue mailing list
clue@ietf.org
https://www.ietf.org/ma= ilman/listinfo/clue
<Allegato di posta = elettronica.eml>_______________________________________________<= br>clue mailing = list
clue@ietf.org
https://www.ietf.org/mailman/listinfo/clue

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

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





= --Apple-Mail=_2E0E2D61-3B7F-46C2-9B2C-50AF532BF377-- From pkyzivat@alum.mit.edu Sun Jan 6 14:09:00 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C533221F853C for ; Sun, 6 Jan 2013 14:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.033 X-Spam-Level: X-Spam-Status: No, score=0.033 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PA0VnR3e5wKh for ; Sun, 6 Jan 2013 14:09:00 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id D00B421F851E for ; Sun, 6 Jan 2013 14:08:57 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id keJM1k0091swQuc55m8xxt; Sun, 06 Jan 2013 22:08:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id km8w1k00j3ZTu2S3bm8wVU; Sun, 06 Jan 2013 22:08:57 +0000 Message-ID: <50E9F5F8.2050900@alum.mit.edu> Date: Sun, 06 Jan 2013 17:08:56 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1357510137; bh=GXPC+QxSSZxMGH1iauEygC26l84p0EanmrTyuF76f10=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=aU7IA3zug1NAb5ioMTPKMVAwpx+ZMgvUpmBEpMWmJaTv6VjsQHJ9qszpCmYXYPBvZ RG7SrCMIB1HjCA5G33SANp87FH0TPMJPUG3OQNZHZOBX6zngZKeYjT9/BeetCREaIU QNWy4EfVIpXk/b5L8kch18nOkvTnyj2eLCUAeR5T60e3QSEK39xMS9arPhF1ao2k/8 lD9yOGhqobpXtcw3WkQQtteZMhLzqFd8vfHL6diCVFhVtQA4q99djEWA6tyBSYR9xJ EnSOA7Xc48jlHsYPS1Tgg/0JWIMERkiZSdY/l01FHJpdXWQR2rt3pwhyjqBhmTsryr 0+zUh7pjYkAYg== Subject: Re: [clue] Fwd: New framework I-D posted: draft-ietf-clue-framework-08 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Jan 2013 22:09:00 -0000 [as an individual] There is no Changes Since Last Version entry for this version! As best I can tell, there are substantial changes/additions to the Intro, and some small but significant changes in Definitions, and all other changes are superficial. Here are some comments, both on the changes, and unchanged parts. Intro: One initial motivation for this memo ... seems oddly phrased. We don't normally refer to drafts as memos. How about replacing "memo" with "document"? This CLUE exchange is followed by an SDP offer answer exchange that not only establishes those aspects of the media that have not been "negotiated" over CLUE, ... This makes it sound like the framework is constraining the ordering of clue and o/a messages. Lets decide if that is so, and not imply things that aren't intended. During the lifetime of a call, further exchanges can occur over the CLUE channel. ... Later, the discussion of legacy devices seems incomplete. It explains how a clue device realizes it is connected to a legacy device, but not what the expectations are in this case. I think we need to say more about the level of support expected for legacy devices. Definitions: We have Capture Encoding, Capture Scene, Capture Scene Entry, and Media Capture, but we have no definition for Capture itself! I suggest we define Capture as synonymous with Media Capture. Capture Scene: a structure representing the scene that is captured by a collection of capture devices. A capture scene includes attributes and one or more capture scene entries, with each entry including one or more media captures. The def of scene is circular. How about: Capture Scene: a structure representing a spatial region containing one or more Capture Devices, each capturing media representing a portion of the region. The spatial region represented by a scene may or may not correspond to a real region in physical space, such as a room. A capture scene includes attributes and one or more capture scene entries, with each entry including one or more media captures. "Individual Encoding: A variable with a set of attributes that describes the maximum values of a single audio or video capture encoding.": in what respect is this a *variable*? I think "parameter" is more appropriate. Also the definition is circular. And shouldn't it just be called "Encoding" rather than "Individual Encoding"? (That is the way it is used.) "Media Capture: a source of Media, such as from one or more Capture Devices. A Media Capture (MC) may be the source of one or more capture encodings": This seems to be using "source" two ways, as seems confusing to me. I think there are some key points that ought to be made here: - it is of a single media type (audio/video) - it is associated with exactly one scene - it has one set of location information. (what do we say about this for switched/composed captures?) - it has one or more possible encodings - it MAY be available in multiple encodings simultaneously Media Consumer: an Endpoint or middle box that receives media streams Media Provider: an Endpoint or middle box that sends Media streams Wouldn't it be better to use Capture Encoding than stream in both of the above? Section 4: Overview: A provider organizes its media captures that represent the same scene into capture scenes. A consumer chooses which media captures it wants to receive according to the capture scenes sent by the provider. Awkward language. How about: A provider organizes its media captures into one or more capture scenes, each representing a spatial region, such as a room. A consumer chooses which media captures it wants to receive from each scene. Section 5: Probably more detail than we want. (E.g. the stuff about scale units.) But I'm ok to leave it here until we are sure that it has been incorporated into another doc. Section 6: To distinguish between multiple instances, video and audio captures are numbered such as: VC1, VC2 and AC1, AC2. VC1 and VC2 refer to two different video captures and AC1 and AC2 refer to two different audio captures. AFAIK the intent is really that these are arbitrary labels, not numbers, and that the usage shown is just a convention. It would be best if this would say that. E.g. To identify and distinguish between multiple instances, video and audio captures are labeled. For instance: VC1, VC2 and AC1, AC2 where VC1 and VC2 refer to two different video captures and AC1 and AC2 refer to two different audio captures. Section 6.2: A capture scene is a structure representing the scene that is captured by a collection of capture devices. ... Same issue as I mentioned above regarding the definition of Capture Scene. Section 7.1: 7.1. Individual Encodings An individual encoding represents a way to encode a media capture to become a capture encoding, ... As mentioned earlier, I think the term should be Encoding, not Individual Encoding. ("Individual" can still be used as an adjective, but it isn't part of the term itself.) So I suggest this should be: 7.1. Encoding An individual Encoding represents a way to encode a Media Capture to form a Capture Encoding, ... Tables 2 & 4: These formatting of these tables is screwed up - the horizontal lines have been wrapped to two lines. In order to insulate for H264 specifics, would it be reasonable to replace macroblocks per second with pixels per second? Aside from rounding, this just seems to be a linear change in units. Or perhaps max pixels per frame, in conjunction with max frame rate. Section 9: The consumer need not send a new configure message to the provider when it receives a new capture advertisement from the provider unless the contents of the new capture advertisement cause the consumer's current configure message to become invalid. This begs the question of how you would determine if your current configure would be come invalid. I guess the simple answer is: take the old configure message, and change it only to update the advertisement id to refer to the new advertisement. Then verify if it is a correct config relative to the new advertisement. If so, that means that if the new advertisement uses old IDs to reference changed attributes, then the consumer has implicitly requested those changes. IMO we want to *recommend* that there be a new config in response to each new advertisement, even while saying what to expect until that is done. Section 9.4: I thought we had abandoned the Consumer Capability message. If so, it should be removed from the framework. Given how long we have had it without any firm identified need, I think removing it now is safe. It can always be returned later if need be. Section 10: The macroblocks-per-second attributes, with a fixed size of macroblock, is not very extensible. As noted above, I think we might be able to abstract it. Section 11.4: Why have a subsection for media consumer behavior, but none for media provider behavoir? I suggest moving 11.1-11.3 down under a new "media provider behavior" section. Thanks, Paul From mary.ietf.barnes@gmail.com Mon Jan 7 07:02:19 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E10121F865D for ; Mon, 7 Jan 2013 07:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RFm9LUVhq1mo for ; Mon, 7 Jan 2013 07:02:18 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 79C9621F8460 for ; Mon, 7 Jan 2013 07:02:18 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id x40so12376001qcp.40 for ; Mon, 07 Jan 2013 07:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+ToNpNpVvJQTLEoJwtgneSvaurrdVjEKU7jAWlnrv34=; b=pWpMAhyz6zeko29jJwTvzgNQkuAG9Jd3T5CT/ZTR5PyrwDBMNr1WJWiSDHwcMZ++O9 fi5BGCAGf8wNVeiP8aYZoqtrhd1th1pfOwjkIsucO6IwHezvnEf9ItY3VWzspyG96Js4 ZVoGxNkGCviXhvMC6nUd1f70gKEI/HEhgoDOVkVbFaC9x+/rpcdHbs62fN8Mv15CU2/8 qrh0ZxFYr3tAmNfaXLgRvgfHjjf+cnekfShc0yCkC1Id8P7JQOMRlL0YF7RsN24DXrVX jMsPzdmIXTR9nKw2v9sDg/MF1Wb0eiZIO0wR++yy1vy74eAXlwot1xcnp9u6jDqND0gS 2EMg== MIME-Version: 1.0 Received: by 10.224.179.211 with SMTP id br19mr41636545qab.43.1357570937951; Mon, 07 Jan 2013 07:02:17 -0800 (PST) Received: by 10.49.131.199 with HTTP; Mon, 7 Jan 2013 07:02:17 -0800 (PST) Date: Mon, 7 Jan 2013 09:02:17 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Reminder: Design Team call today - Framework updates X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:02:19 -0000 Hi all, This is a reminder that we do have a call today. The plan is to discuss the updated framework. There has been two reviews/sets of comments posted to the mailing list: - http://www.ietf.org/mail-archive/web/clue/current/msg02302.html - http://www.ietf.org/mail-archive/web/clue/current/msg02303.html I'm hoping more folks have reviewed the document. Mary. From spromano@unina.it Mon Jan 7 07:52:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 609F321F872E for ; Mon, 7 Jan 2013 07:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.304 X-Spam-Level: X-Spam-Status: No, score=-98.304 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37dXX1h3PwMw for ; Mon, 7 Jan 2013 07:52:08 -0800 (PST) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by ietfa.amsl.com (Postfix) with ESMTP id 9E80921F872C for ; Mon, 7 Jan 2013 07:52:07 -0800 (PST) Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id r07Fq4X5021286 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 7 Jan 2013 16:52:04 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_CAF38E8D-9CAF-4492-946E-E116F1D66D07" Date: Mon, 7 Jan 2013 16:52:12 +0100 Message-Id: To: clue@ietf.org Mime-Version: 1.0 (Apple Message framework v1283) X-Mailer: Apple Mail (2.1283) Subject: [clue] Design team meeting today? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 15:52:08 -0000 --Apple-Mail=_CAF38E8D-9CAF-4492-946E-E116F1D66D07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear all, are we going to have the design meeting today? Did you circulate updated = information about webex details? Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_CAF38E8D-9CAF-4492-946E-E116F1D66D07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Dear = all,

are we going to have the design meeting today? = Did you circulate updated information about webex = details?

Cheers,

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

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





= --Apple-Mail=_CAF38E8D-9CAF-4492-946E-E116F1D66D07-- From mary.ietf.barnes@gmail.com Mon Jan 7 08:04:07 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9222821F867D for ; Mon, 7 Jan 2013 08:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bt3-S4hlamkK for ; Mon, 7 Jan 2013 08:04:07 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE5421F8732 for ; Mon, 7 Jan 2013 08:04:06 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id v28so12469707qcm.39 for ; Mon, 07 Jan 2013 08:04:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=AnmHZvz4eaqg7ORd3LCj7Mx7akCzOobxJXcG2U2OCLw=; b=ToWRbZ/icKdrx9RvtCPKAXCACUR3Aj4yJRA+QDR7OQHTuPRoDUPDjP0N6iqoJ1QPK+ HWB+sZanqY36j97ief/uUhF5oOYeoeCpq74KYPJO7li7ruypsmys3JDWOwC0MMFeuEUv bfnqIGgeP0zDO7lGgiD5wb3TRCgIMN8Qy1GbXZKgypYaF7/F1+W1R0eeODnqVXNndhW6 Rz7Ep1exaCXVypG/bEfbOEjUcC6UcjJIhnY35DA2kTHzUbtSVcCuOaN1stg1wLE+dP9Y t0Zec+/1HKkm06wVrQrwrohml/coY4QSeoQTCeQgwYoHO9OjwyWbM0s4vQlr7hDX02mN KW2w== MIME-Version: 1.0 Received: by 10.224.195.138 with SMTP id ec10mr43379014qab.3.1357574645547; Mon, 07 Jan 2013 08:04:05 -0800 (PST) Received: by 10.49.131.199 with HTTP; Mon, 7 Jan 2013 08:04:05 -0800 (PST) In-Reply-To: References: Date: Mon, 7 Jan 2013 10:04:05 -0600 Message-ID: From: Mary Barnes To: Simon Pietro Romano Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: CLUE Subject: Re: [clue] Design team meeting today? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 16:04:07 -0000 Webex details are here: http://www.ietf.org/mail-archive/web/clue/current/msg01970.html On Mon, Jan 7, 2013 at 9:52 AM, Simon Pietro Romano wro= te: > Dear all, > > are we going to have the design meeting today? Did you circulate updated > information about webex details? > > Cheers, > > Simon > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 -- Fax: +39 081 7683816 > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_= / > > > > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From apeppere@gmail.com Thu Jan 10 10:52:01 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA89221F841E for ; Thu, 10 Jan 2013 10:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rMX0diHiVXv9 for ; Thu, 10 Jan 2013 10:51:58 -0800 (PST) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) by ietfa.amsl.com (Postfix) with ESMTP id 80ECE21F8200 for ; Thu, 10 Jan 2013 10:51:56 -0800 (PST) Received: by mail-qa0-f45.google.com with SMTP id j15so1953240qaq.4 for ; Thu, 10 Jan 2013 10:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=jQPbgjAePwQ9OKxjby9c5YTxMeRnKp1f9Ckca4Dt+jo=; b=rJFiQATfJOBzyJNigO+EPEI+C2UXoBqs5koy9dyMNtvCH5VfBacNrIBssheQ8f6FH4 apGoICJxXVIxmKpNmxsZvqhM2QWGTu+k5BdMPssg/v+gke4ZtQFR6oqToM79dmHx9que xizoALDg6WpjpvliusYYJU2J6kDCyJMzq7OvZ8ot42vi06Ss6HkWnjgd33IdVI02D8rQ SXiAjZW3Y3gnjvTMBe3jksngyc0UThZuaJVl0NdcKFqsvjXvLwF9CIPhXondjRBgHqjP YpinlNAGqpUSN1p42XqVhLqPSAQrHqkgJDc446q/YyUXgXhvCv3QIDzO9llTsxQmnIls 4YHQ== MIME-Version: 1.0 Received: by 10.224.78.82 with SMTP id j18mr46144004qak.69.1357843915301; Thu, 10 Jan 2013 10:51:55 -0800 (PST) Received: by 10.49.62.131 with HTTP; Thu, 10 Jan 2013 10:51:55 -0800 (PST) Date: Thu, 10 Jan 2013 18:51:55 +0000 Message-ID: From: Andy Pepperell To: clue@ietf.org Content-Type: multipart/alternative; boundary=20cf3074b2503b63a004d2f3ac37 Subject: [clue] CLUE design call meeting notes, 7 January 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 18:52:01 -0000 --20cf3074b2503b63a004d2f3ac37 Content-Type: text/plain; charset=ISO-8859-1 All, Apologies for not sending these out until now; here are the notes I took on Monday's call. Andy Simon: I tried to provider notes, and foster discussion on a few more items. Together with Roberta we're trying to write down a call flow including Offer / Answer and CLUE messages. Simon: I think that the new introduction to the framework is quite useful as it tries to shed some light on the new features. I really like this new approach I think it did contain a number of unresolved issues. We have not yet reached consensus on a number of important issues - so trying to focus on those issues. Trying to put ourselves into the body of a newcomer - some parts of the document are really helpful but some are distracting and contain too much information. Simon: Before RTP mapping issue, should focus more on the messages flowing on the CLUE control channel. Useful to describe those messages at a very high level rather than the detail. I think the detail is needed, but it should come afterwards, Roni: The way I read what Simon was writing was that he was viewing the CLUE messages as a capability exchange but I worry what happens what happens in the second and further advertisements, and whether we require a new O/A after the advertisement / configuration cycle. Paul: as I read the framework right now, it explains it quite well, and the O/A isn't needed in all such cases. We keep coming round to this; until we get the signalling nailed down we can't get these questions answered. I'm not sure we can. Mary: really we're in a chicken and egg situation and we need to work through the detail and see if it works. Mark: That's what we tried to do within Stephan's changes - not sure if that addresses Roni's question except at a very high level. There's likely to be an additional O/A after the initial CLUE messages. Paul: the highlighted paragraph in the framework document ("During the lifetime of a call...") takes a position on this (O/A done later than the advertisement / configure). It's still a little unclear here. Simon: sorry to interrupt... with reference to the data model link, we tried to go through this from the data model point of view: http://www.grid.unina.it/Didattica/RetiDiCalcolatori/inf/draft-clue-call-flow-example-00.html The advertisement should be seen as a copy of the data model information, 99% the same as the data model. Not trying to worry about what parts of the data model can be modelled in SDP and what cannot, but what might flow between 2 CLUE capable endpoints on the CLUE channel, exchange of XML documents describing the telepresence room. Updates SDP would be the result of ongoing work in MMUSIC (RTP multiplexing, BUNDLE etc.) - I feel this is out of scope for CLUE at this time. Paul: I agree with what you say - do we want to put this level of detail into the framework? Mark: I agree that these diagrams are consistent with the new framework material and they would be useful in the framework document. Simon: It is my view that these documents are more important for the framework than the data model. Paul: I think it should be made clear that the point of the reinvite is to enable the most recent configuration. Roni: I don't have any problem with this example - I think it is correct. I have a problem with the next stage - if we want to send a new configuration, how does it work? If we have a later configure, do we always have a reinvite? Paul: I think the reinvite is (always) optional - if the configuration is consistent with SDP 1 and SDP 2, we shouldn't need a reinvite. Roni: Paul, I have a question: how do you know if you have to reinvite or wait for a new reinvite before you can send? You might need a reinvite from both sides, and get glare. Paul: we have this come up again and again - we can just let glare be handled (as it has to be handleable anyway). For the framework this should be enough - otherwise the extra detail would make the framework too big, and more distracting. In a signalling document, we need to go into that in excruciating detail. Simon: I agree, at the moment we need to agree that the advertisement is sent across the CLUE channel if 2 sides are both CLUE capable. In the picture, advertisement 1 and 2 aren't sent in an SDP body, but they're transferred directly via XML across the CLUE channel - it would be a good step forward for this to be agreed. Jonathan: I have one comment on what Paul said: I think I agree with you, Paul, in that you don't need to send an updated SDP if the existing is compatible with the current adv / configure, but I'm thinking about the case where the old SDP is consistent with the new configure etc. but not optimal. i.e. it works for the minimal but not the optimal one. e.g.Configuration says I can do up to 1080p but the SDP says up to 720p. Paul: That's not inconsistent with saying the O/A is optional Jonathan: my concern is that it is optional, then it becomes confusing to know for implementors whether to wait for a new O/A or to continue with what I've got Roni: that's my concern also, whether you're allowed to send the new configuration Jonathan: you'd be *allowed* but it might not be optimal Paul: what happens between the new advertisement and the new config? Paul: by the time you've advertised and configs, both sides know enough to send a new O/A, but which side should reinvite? Jonathan: in the situation that the consumer sends the configure and shortly thereafter the provider sends the new reinvite do I send media based on the old SDP or wait for a new reinvite to come in. Andy: re-advertisements generally not in sync - the sort of event that would cause one side to [need to] re-advertise wouldn't be co-incident with the other side needing to do so, so this is not necessarily a common case Paul: when you get a new configure you should start to honour it based on the existing SDP rather than assume a new SDP will arrive Jonathan: I agree that's the obvious thing to do but I'm concerned *(audio went very static-y at this point and difficult to hear)* Paul: at the beginning of the call it's a different story (both sides will advertise and configure) Paul: whoever does an offer answer should do it based on the most recent configure in both directions, not just your own as the other guy's might require more more m-lines than yours Rob: deciding who should reinvite is generally bad Paul: I think requiring O/A based on config is good Rob: even with 2 well-behaved endpoints you could have middleboxes doing anything, not following conventions etc. so need to be careful Paul: conventions won't nail down everything, but they provide guidance. even if you're required to do O/A because you send config, if you receive one before you send one then you need to take that into account. if that puts you in a situation where you don't need to O/A then that's cool. Both sides send configured, both send offer then you get glare. one side wins the back off and it sends an offer. It would send offer that takes into account both offers, and so the other side has achieve what he needs to achieve Andy: I think your approach (Paul) here with the configurer required to do the O/A if necessary is a good one, even though there's still likely to be glare-type cases at the start of the call Simon: from our side we'll continue working on this stuff, and we'll continue on e-mail threads. Mark: we should continue on the e-mail list, and there are some extra threads not related to version 8 of the framework, and we should get consensus on a few specific things and get those in the next version. There are some discussions on capture attributes that haven't yet been concluded. Could people also, via e-mail,c all out the various sections of the framework document they think should be moved to other documents, though not actually move those things yet. --20cf3074b2503b63a004d2f3ac37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All,

Apologies for not sending these out until now; here are the not= es I took on Monday's call.

Andy


Simon: I tried to pr= ovider notes, and foster discussion on a few more=20 items. Together with Roberta we're trying to write down a call flow=20 including Offer / Answer and CLUE messages.

Simon: I thi= nk=20 that the new introduction to the framework is quite useful as it tries=20 to shed some light on the new features. I really like this new approach I think it did contain a number of unresolved issues. We have not yet=20 reached consensus on a number of important issues - so trying to focus=20 on those issues. Trying to put ourselves into the body of a newcomer -=20 some parts of the document are really helpful but some are distracting=20 and contain too much information.

Simon: Before RTP mapping issue, should focus more on t= he=20 messages flowing on the CLUE control channel. Useful to describe those=20 messages at a very high level rather than the detail. I think the detail is needed, but it should come afterwards,=A0

Roni: The way I read what Simon was writing was that he was viewing the CLUE messages as a capability exchange but I worry=20 what happens what happens in the second and further advertisements, and=20 whether we require a new O/A after the advertisement / configuration=20 cycle.

Paul: as I read the framework right now, it explains it quite well, and the O/A isn't needed in all such cases. We keep=20 coming round to this; until we get the signalling nailed down we can't= =20 get these questions answered. I'm not sure we can.

Mary: really we're in a chicken and egg situation a= nd we need to work through the detail and see if it works.
Mark: That's what we tried to do within Stephan's changes - not sure if = that=20 addresses Roni's question except at a very high level. There's like= ly to be an additional O/A after the initial CLUE messages.

Paul: the highlighted paragraph in the framework=20 document ("During the lifetime of a call...") takes a position on= this=20 (O/A done later than the advertisement / configure). It's still a littl= e unclear here.

Simon: sorry to interrupt... with reference to the=20 data model link, we tried to go through this from the data model point=20 of view:
The advertisement should be seen as a copy of the data model informati= on, 99% the same as the data model.
Not trying to worry about what parts of the data model can be modelled in=20 SDP and what cannot, but what might flow between 2 CLUE capable=20 endpoints on the CLUE channel, exchange of XML documents describing the=20 telepresence room. Updates SDP would be the result of ongoing work in=20 MMUSIC (RTP multiplexing, BUNDLE etc.) - I feel this is out of scope for CLUE at this time.

Paul: I agree with what you say - do we want to put thi= s level of detail into the framework?

Mark: I agree that these diagrams are consistent with the new framework=20 material and they would be useful in the framework document.

Simon: It is my view that these documents are more impo= rtant for the framework than the data model.

Paul:= I think it should be made clear that the point of the reinvite is to enabl= e the most recent configuration.

Roni: I don't have any problem with this example - = I think it is correct. I have a problem with the next stage - if we want=20 to send a new configuration, how does it work? If we have a later=20 configure, do we always have a reinvite?

Paul: I think the reinvite is (always) optional - if the configuration is consistent with SDP 1 and SDP 2, we shouldn't nee= d a reinvite.

Roni: Paul, I have a question: how do you know if you have to reinvite or wait for a new reinvite before=20 you can send? You might need a reinvite from both sides, and get glare.

Paul: we have this come up again and again - we can=20 just let glare be handled (as it has to be handleable anyway). For the=20 framework this should be enough - otherwise the extra detail would make the= framework too big, and more distracting. In a signalling document, we need to go into=20 that in excruciating detail.

Simon: I agree, at the moment we need to agree that=20 the advertisement is sent across the CLUE channel if 2 sides are both=20 CLUE capable. In the picture, advertisement 1 and 2 aren't sent in an S= DP body, but they're transferred directly via XML across the CLUE channel= - it would be a good step forward for this to be agreed.

Jonathan: I have one comment on what Paul said: I=20 think I agree with you, Paul, in that you don't need to send an updated= =20 SDP if the existing is compatible with the current adv / configure, but=20 I'm thinking about the case where the old SDP is consistent with the ne= w configure etc. but not optimal. i.e. it works for the minimal but not=20 the optimal one. e.g.Configuration says I can do up to 1080p but the SDP sa= ys up to 720p.

Paul: That's not inconsistent w= ith saying the O/A is optional
Jonathan: my concern is that it is optional, then it becomes confusing to know=20 for implementors whether to wait for a new O/A or to continue with what=20 I've got
Roni: that's my concern also, whether you're allowed to send t= he new configuration
Jonathan: you'd be *allowed* but it migh= t not be optimal

Paul: what happens between the ne= w advertisement and the new config?=A0
Paul: by the time you've advertised and configs, both sides know e= nough to send a new O/A, but which side should reinvite?

Jonathan: in the situation that the consumer sends the configure and shortly=20 thereafter the provider sends the new reinvite do I send media based on=20 the old SDP or wait for a new reinvite to come in.=A0
Andy: re-advertisements generally not in sync - the sort of event that= would cause one side to [need to] re-advertise wouldn't be co-incident= with the other side needing to do so, so this is not necessarily a common = case
Paul: when=20 you get a new configure you should start to honour it based on the=20 existing SDP rather than assume a new SDP will arrive
Jonathan: I= agree that's the obvious thing to do but I'm concerned (audio w= ent very static-y at this point and difficult to hear)

Paul: at the beginning of the call it's a different= story (both sides will advertise and configure)
Paul: whoever does an offer answer should do it based on the most recent=20 configure in both directions, not just your own as the other guy's migh= t require more more m-lines than yours

Rob: deciding who should reinvite is generally bad
Paul: I think requiring O/A based on config is good
Rob: even with 2 well-behaved endpoints you could have middleboxes doing=20 anything, not following conventions etc. so need to be careful
Paul: conventions won't nail down everything, but they provide=20 guidance. even if you're required to do O/A because you send config, if= =20 you receive one before you send one then you need to take that into=20 account. if that puts you in a situation where you don't need to O/A=20 then that's cool. Both sides send configured, both send offer then you= =20 get glare. one side wins the back off and it sends an offer. It would=20 send offer that takes into account both offers, and so the other side=20 has achieve what he needs to achieve
Andy: I think your approach (Paul) here with the configurer=20 required to do the O/A if necessary is a good one, even though there's= =20 still likely to be glare-type cases at the start of the call

=
Simon: from our side we'll continue working on this stuff, and we&= #39;ll continue on e-mail threads.

Mark: we should continue on the e-mail list, and there are some extra threads not related to version 8 of the framework, and we should get consensus=20 on a few specific things and get those in the next version. There are=20 some discussions on capture attributes that haven't yet been concluded.= =20 Could people also, via e-mail,c all out the various sections of the=20 framework document they think should be moved to other documents, though not actually move those things yet.
--20cf3074b2503b63a004d2f3ac37-- From Mark.Duckworth@polycom.com Fri Jan 11 13:33:47 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BDD21F8956 for ; Fri, 11 Jan 2013 13:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FPeughPcpaBh for ; Fri, 11 Jan 2013 13:33:46 -0800 (PST) Received: from Crpehubprd01.polycom.com (crpehubprd01.polycom.com [140.242.64.158]) by ietfa.amsl.com (Postfix) with ESMTP id 8338521F8903 for ; Fri, 11 Jan 2013 13:33:45 -0800 (PST) Received: from Crpmboxprd01.polycom.com ([fe80::ad68:5a0:c919:66b6]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Fri, 11 Jan 2013 13:33:44 -0800 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Fri, 11 Jan 2013 13:33:40 -0800 Thread-Topic: [clue] Fwd: New framework I-D posted: draft-ietf-clue-framework-08 Thread-Index: Ac3sWnLsFirOsDgbRSCIdjDZS63CRwD5WRjQ Message-ID: <44C6B6B2D0CF424AA90B6055548D7A610391FB7EC6@CRPMBOXPRD01.polycom.com> References: <50E9F5F8.2050900@alum.mit.edu> In-Reply-To: <50E9F5F8.2050900@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [clue] Fwd: New framework I-D posted: draft-ietf-clue-framework-08 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 21:33:48 -0000 Hi Paul, I agree we should have a "changes since last version" section in every new = version. Sorry about that. Are there places where we use the term "capture" by itself? It should alwa= ys be "media capture", so I agree with you that "capture" is the same as "m= edia capture". I think your definition of Capture Scene is an improvement, I like it. Good point about definition of Individual Encoding. But the term "individu= al encoding" is used in section 7.1, not just "encoding". I'll look more c= losely to see if I agree with you about changing it to just "encoding". Ho= w about this: (Individual) Encoding: a representation of a way to encode a media capture = to become a capture encoding. And further elaboration of (Individual) Encoding should be in the body of t= he document, or data model, and not included in the definition. I think your key points about Media Capture are important, but should not b= e part of a simple definition. Stephan, Andy, and myself were planning on = trying to shorten some of the definitions (so they are simple definitions, = not complete explanations) and leave the explanations and elaboration to th= e body of the documents. Media Consumer and Media Provider - I think "stream" is actually better her= e than "capture encoding", given that stream is defined as a capture encodi= ng sent via RTP. I agree with your other suggestions about sections 4 through 11. Mark > -----Original Message----- > From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of > Paul Kyzivat > Sent: Sunday, January 06, 2013 5:09 PM > To: clue@ietf.org > Subject: Re: [clue] Fwd: New framework I-D posted: draft-ietf-clue- > framework-08 >=20 > [as an individual] >=20 > There is no Changes Since Last Version entry for this version! > As best I can tell, there are substantial changes/additions to the Intro,= and > some small but significant changes in Definitions, and all other changes = are > superficial. >=20 > Here are some comments, both on the changes, and unchanged parts. >=20 > Intro: >=20 > One initial motivation for this memo ... >=20 > seems oddly phrased. We don't normally refer to drafts as memos. How > about replacing "memo" with "document"? >=20 > This CLUE exchange is followed by an SDP offer answer exchange > that not only establishes those aspects of the media that have not > been "negotiated" over CLUE, ... >=20 > This makes it sound like the framework is constraining the ordering of cl= ue > and o/a messages. Lets decide if that is so, and not imply things that ar= en't > intended. >=20 > During the lifetime of a call, further exchanges can occur over > the CLUE channel. ... >=20 > Later, the discussion of legacy devices seems incomplete. It explains how= a > clue device realizes it is connected to a legacy device, but not what the > expectations are in this case. I think we need to say more about the leve= l of > support expected for legacy devices. >=20 > Definitions: >=20 > We have Capture Encoding, Capture Scene, Capture Scene Entry, and Media > Capture, but we have no definition for Capture itself! I suggest we defin= e > Capture as synonymous with Media Capture. >=20 > Capture Scene: a structure representing the scene that is captured > by a collection of capture devices. A capture scene includes > attributes and one or more capture scene entries, with each entry > including one or more media captures. >=20 > The def of scene is circular. How about: >=20 > Capture Scene: a structure representing a spatial region containing > one or more Capture Devices, each capturing media representing a > portion of the region. The spatial region represented by a scene > may or may not correspond to a real region in physical space, such > as a room. A capture scene includes attributes and one > or more capture scene entries, with each entry including one or more > media captures. >=20 > "Individual Encoding: A variable with a set of attributes that describes = the > maximum values of a single audio or video capture encoding.": in what > respect is this a *variable*? I think "parameter" is more appropriate. Al= so the > definition is circular. And shouldn't it just be called "Encoding" rather= than > "Individual Encoding"? (That is the way it is used.) >=20 > "Media Capture: a source of Media, such as from one or more Capture > Devices. A Media Capture (MC) may be the source of one or more capture > encodings": This seems to be using "source" two ways, as seems confusing = to > me. I think there are some key points that ought to be made here: > - it is of a single media type (audio/video) > - it is associated with exactly one scene > - it has one set of location information. > (what do we say about this for switched/composed captures?) > - it has one or more possible encodings > - it MAY be available in multiple encodings simultaneously >=20 > Media Consumer: an Endpoint or middle box that receives media > streams >=20 > Media Provider: an Endpoint or middle box that sends Media streams >=20 > Wouldn't it be better to use Capture Encoding than stream in both of the > above? >=20 > Section 4: Overview: >=20 > A provider organizes its media captures that represent the same > scene into capture scenes. A consumer chooses which media > captures it wants to receive according to the capture scenes sent > by the provider. >=20 > Awkward language. How about: >=20 > A provider organizes its media captures into one or more capture > scenes, each representing a spatial region, such as a room. A > consumer chooses which media captures it wants to receive from > each scene. >=20 > Section 5: >=20 > Probably more detail than we want. (E.g. the stuff about scale units.) Bu= t I'm > ok to leave it here until we are sure that it has been incorporated into > another doc. >=20 > Section 6: >=20 > To distinguish between multiple instances, video and audio > captures are numbered such as: VC1, VC2 and AC1, AC2. VC1 and VC2 > refer to two different video captures and AC1 and AC2 refer to two > different audio captures. >=20 > AFAIK the intent is really that these are arbitrary labels, not numbers, = and > that the usage shown is just a convention. It would be best if this would= say > that. E.g. >=20 > To identify and distinguish between multiple instances, video and > audio captures are labeled. For instance: VC1, VC2 and AC1, AC2 > where VC1 and VC2 refer to two different video captures and AC1 > and AC2 refer to two different audio captures. >=20 > Section 6.2: >=20 > A capture scene is a structure representing the scene that is > captured by a collection of capture devices. ... >=20 > Same issue as I mentioned above regarding the definition of Capture Scene= . >=20 > Section 7.1: >=20 > 7.1. Individual Encodings >=20 > An individual encoding represents a way to encode a media capture > to become a capture encoding, ... >=20 > As mentioned earlier, I think the term should be Encoding, not Individual > Encoding. ("Individual" can still be used as an adjective, but it isn't p= art of the > term itself.) So I suggest this should be: >=20 > 7.1. Encoding >=20 > An individual Encoding represents a way to encode a Media Capture > to form a Capture Encoding, ... >=20 > Tables 2 & 4: These formatting of these tables is screwed up - the horizo= ntal > lines have been wrapped to two lines. >=20 > In order to insulate for H264 specifics, would it be reasonable to replac= e > macroblocks per second with pixels per second? Aside from rounding, this > just seems to be a linear change in units. Or perhaps max pixels per fram= e, in > conjunction with max frame rate. >=20 > Section 9: >=20 > The consumer need not send a new configure message to the provider > when it receives a new capture advertisement from the provider > unless the contents of the new capture advertisement cause the > consumer's current configure message to become invalid. >=20 > This begs the question of how you would determine if your current configu= re > would be come invalid. >=20 > I guess the simple answer is: take the old configure message, and change = it > only to update the advertisement id to refer to the new advertisement. > Then verify if it is a correct config relative to the new advertisement. >=20 > If so, that means that if the new advertisement uses old IDs to reference > changed attributes, then the consumer has implicitly requested those > changes. >=20 > IMO we want to *recommend* that there be a new config in response to > each new advertisement, even while saying what to expect until that is > done. >=20 > Section 9.4: >=20 > I thought we had abandoned the Consumer Capability message. If so, it > should be removed from the framework. Given how long we have had it > without any firm identified need, I think removing it now is safe. It can= always > be returned later if need be. >=20 > Section 10: >=20 > The macroblocks-per-second attributes, with a fixed size of macroblock, i= s > not very extensible. As noted above, I think we might be able to abstract= it. >=20 > Section 11.4: >=20 > Why have a subsection for media consumer behavior, but none for media > provider behavoir? >=20 > I suggest moving 11.1-11.3 down under a new "media provider behavior" > section. >=20 > Thanks, > Paul > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From pkyzivat@alum.mit.edu Fri Jan 11 14:38:57 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37DB221F8919 for ; Fri, 11 Jan 2013 14:38:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.128 X-Spam-Level: X-Spam-Status: No, score=-0.128 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4vRTU9fCMOv for ; Fri, 11 Jan 2013 14:38:56 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id D958121F8506 for ; Fri, 11 Jan 2013 14:38:55 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta03.westchester.pa.mail.comcast.net with comcast id mc8D1k00B0cZkys53mevsz; Fri, 11 Jan 2013 22:38:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id mmer1k00K3ZTu2S3Wmesdh; Fri, 11 Jan 2013 22:38:55 +0000 Message-ID: <50F09479.1000409@alum.mit.edu> Date: Fri, 11 Jan 2013 17:38:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Duckworth, Mark" References: <50E9F5F8.2050900@alum.mit.edu> <44C6B6B2D0CF424AA90B6055548D7A610391FB7EC6@CRPMBOXPRD01.polycom.com> In-Reply-To: <44C6B6B2D0CF424AA90B6055548D7A610391FB7EC6@CRPMBOXPRD01.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=q20121106; t=1357943935; bh=qk/Q0591BvHR2ka0jHT16k5t0XSFjO7NfX1ItUcYaJA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=HJFZ2/LkgGPiQzczrjOCnz4gYi0j+eIFr3M9KE7Fje9vWGkIWNnnQS8OaeaopcgGv RdoFIEmrV6BS6mzkOlEKIW0df9sGy8iu1NT9pTevnGPT/fYwtsIYMYzjsWZtsSVR5E 423wptjpGFiCS7UZE4dM9iPRpWabSaqBbjjnyGLrAaXFz7tTU8ouUXis7/rIaN7s4Y PGbKBoZlOb2K3o+bKh59SBt7eqGs4Xehqro8HEVcIxt0QcS4IUTPca9TM8kdNXlU42 cFki6dy8MpL3bMnAGEkjN6PHCmtFT5Pp/w23KSJfrl2Zb54Q20yXFHFDLNG8wk06eF HxgloqAqk96KA== Cc: "clue@ietf.org" Subject: Re: [clue] Fwd: New framework I-D posted: draft-ietf-clue-framework-08 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 22:38:57 -0000 On 1/11/13 4:33 PM, Duckworth, Mark wrote: > Hi Paul, > > I agree we should have a "changes since last version" section in every new version. Sorry about that. > > Are there places where we use the term "capture" by itself? It should always be "media capture", so I agree with you that "capture" is the same as "media capture". I'm not sure if it is used "by itself" or not. But it is used in Capture Scene, Capture Encoding, etc. (rather than Media Capture Scene, Media Capture Encoding). And whether it is used alone in this document or not, we certainly use it alone in discussions. It could just be noted as shorthand for Media Capture. > I think your definition of Capture Scene is an improvement, I like it. > > Good point about definition of Individual Encoding. But the term "individual encoding" is used in section 7.1, not just "encoding". I'll look more closely to see if I agree with you about changing it to just "encoding". How about this: > > (Individual) Encoding: a representation of a way to encode a media capture to become a capture encoding. That could work. It just seems weird to me. It seems more natural to use "individual" in its normal role as an adjective - "individual Encoding" rather than "Individual Encoding". Or if you think "Encoding" isn't specific enough, how about "Media Encoding" as a parallel to "Media Capture"? (With "Encoding" being a shorthand for "Media Capture".) > And further elaboration of (Individual) Encoding should be in the body of the document, or data model, and not included in the definition. > > I think your key points about Media Capture are important, but should not be part of a simple definition. Stephan, Andy, and myself were planning on trying to shorten some of the definitions (so they are simple definitions, not complete explanations) and leave the explanations and elaboration to the body of the documents. Yes, that seems like the right thing to do. > Media Consumer and Media Provider - I think "stream" is actually better here than "capture encoding", given that stream is defined as a capture encoding sent via RTP. OK. > I agree with your other suggestions about sections 4 through 11. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue-bounces@ietf.org [mailto:clue-bounces@ietf.org] On Behalf Of >> Paul Kyzivat >> Sent: Sunday, January 06, 2013 5:09 PM >> To: clue@ietf.org >> Subject: Re: [clue] Fwd: New framework I-D posted: draft-ietf-clue- >> framework-08 >> >> [as an individual] >> >> There is no Changes Since Last Version entry for this version! >> As best I can tell, there are substantial changes/additions to the Intro, and >> some small but significant changes in Definitions, and all other changes are >> superficial. >> >> Here are some comments, both on the changes, and unchanged parts. >> >> Intro: >> >> One initial motivation for this memo ... >> >> seems oddly phrased. We don't normally refer to drafts as memos. How >> about replacing "memo" with "document"? >> >> This CLUE exchange is followed by an SDP offer answer exchange >> that not only establishes those aspects of the media that have not >> been "negotiated" over CLUE, ... >> >> This makes it sound like the framework is constraining the ordering of clue >> and o/a messages. Lets decide if that is so, and not imply things that aren't >> intended. >> >> During the lifetime of a call, further exchanges can occur over >> the CLUE channel. ... >> >> Later, the discussion of legacy devices seems incomplete. It explains how a >> clue device realizes it is connected to a legacy device, but not what the >> expectations are in this case. I think we need to say more about the level of >> support expected for legacy devices. >> >> Definitions: >> >> We have Capture Encoding, Capture Scene, Capture Scene Entry, and Media >> Capture, but we have no definition for Capture itself! I suggest we define >> Capture as synonymous with Media Capture. >> >> Capture Scene: a structure representing the scene that is captured >> by a collection of capture devices. A capture scene includes >> attributes and one or more capture scene entries, with each entry >> including one or more media captures. >> >> The def of scene is circular. How about: >> >> Capture Scene: a structure representing a spatial region containing >> one or more Capture Devices, each capturing media representing a >> portion of the region. The spatial region represented by a scene >> may or may not correspond to a real region in physical space, such >> as a room. A capture scene includes attributes and one >> or more capture scene entries, with each entry including one or more >> media captures. >> >> "Individual Encoding: A variable with a set of attributes that describes the >> maximum values of a single audio or video capture encoding.": in what >> respect is this a *variable*? I think "parameter" is more appropriate. Also the >> definition is circular. And shouldn't it just be called "Encoding" rather than >> "Individual Encoding"? (That is the way it is used.) >> >> "Media Capture: a source of Media, such as from one or more Capture >> Devices. A Media Capture (MC) may be the source of one or more capture >> encodings": This seems to be using "source" two ways, as seems confusing to >> me. I think there are some key points that ought to be made here: >> - it is of a single media type (audio/video) >> - it is associated with exactly one scene >> - it has one set of location information. >> (what do we say about this for switched/composed captures?) >> - it has one or more possible encodings >> - it MAY be available in multiple encodings simultaneously >> >> Media Consumer: an Endpoint or middle box that receives media >> streams >> >> Media Provider: an Endpoint or middle box that sends Media streams >> >> Wouldn't it be better to use Capture Encoding than stream in both of the >> above? >> >> Section 4: Overview: >> >> A provider organizes its media captures that represent the same >> scene into capture scenes. A consumer chooses which media >> captures it wants to receive according to the capture scenes sent >> by the provider. >> >> Awkward language. How about: >> >> A provider organizes its media captures into one or more capture >> scenes, each representing a spatial region, such as a room. A >> consumer chooses which media captures it wants to receive from >> each scene. >> >> Section 5: >> >> Probably more detail than we want. (E.g. the stuff about scale units.) But I'm >> ok to leave it here until we are sure that it has been incorporated into >> another doc. >> >> Section 6: >> >> To distinguish between multiple instances, video and audio >> captures are numbered such as: VC1, VC2 and AC1, AC2. VC1 and VC2 >> refer to two different video captures and AC1 and AC2 refer to two >> different audio captures. >> >> AFAIK the intent is really that these are arbitrary labels, not numbers, and >> that the usage shown is just a convention. It would be best if this would say >> that. E.g. >> >> To identify and distinguish between multiple instances, video and >> audio captures are labeled. For instance: VC1, VC2 and AC1, AC2 >> where VC1 and VC2 refer to two different video captures and AC1 >> and AC2 refer to two different audio captures. >> >> Section 6.2: >> >> A capture scene is a structure representing the scene that is >> captured by a collection of capture devices. ... >> >> Same issue as I mentioned above regarding the definition of Capture Scene. >> >> Section 7.1: >> >> 7.1. Individual Encodings >> >> An individual encoding represents a way to encode a media capture >> to become a capture encoding, ... >> >> As mentioned earlier, I think the term should be Encoding, not Individual >> Encoding. ("Individual" can still be used as an adjective, but it isn't part of the >> term itself.) So I suggest this should be: >> >> 7.1. Encoding >> >> An individual Encoding represents a way to encode a Media Capture >> to form a Capture Encoding, ... >> >> Tables 2 & 4: These formatting of these tables is screwed up - the horizontal >> lines have been wrapped to two lines. >> >> In order to insulate for H264 specifics, would it be reasonable to replace >> macroblocks per second with pixels per second? Aside from rounding, this >> just seems to be a linear change in units. Or perhaps max pixels per frame, in >> conjunction with max frame rate. >> >> Section 9: >> >> The consumer need not send a new configure message to the provider >> when it receives a new capture advertisement from the provider >> unless the contents of the new capture advertisement cause the >> consumer's current configure message to become invalid. >> >> This begs the question of how you would determine if your current configure >> would be come invalid. >> >> I guess the simple answer is: take the old configure message, and change it >> only to update the advertisement id to refer to the new advertisement. >> Then verify if it is a correct config relative to the new advertisement. >> >> If so, that means that if the new advertisement uses old IDs to reference >> changed attributes, then the consumer has implicitly requested those >> changes. >> >> IMO we want to *recommend* that there be a new config in response to >> each new advertisement, even while saying what to expect until that is >> done. >> >> Section 9.4: >> >> I thought we had abandoned the Consumer Capability message. If so, it >> should be removed from the framework. Given how long we have had it >> without any firm identified need, I think removing it now is safe. It can always >> be returned later if need be. >> >> Section 10: >> >> The macroblocks-per-second attributes, with a fixed size of macroblock, is >> not very extensible. As noted above, I think we might be able to abstract it. >> >> Section 11.4: >> >> Why have a subsection for media consumer behavior, but none for media >> provider behavoir? >> >> I suggest moving 11.1-11.3 down under a new "media provider behavior" >> section. >> >> Thanks, >> Paul >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From pkyzivat@alum.mit.edu Mon Jan 14 07:09:35 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B844321F891A for ; Mon, 14 Jan 2013 07:09:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.14 X-Spam-Level: X-Spam-Status: No, score=-0.14 tagged_above=-999 required=5 tests=[AWL=0.297, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Idp0NVSFjPuu for ; Mon, 14 Jan 2013 07:09:34 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2DB21F88AE for ; Mon, 14 Jan 2013 07:09:34 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by QMTA11.westchester.pa.mail.comcast.net with comcast id npTf1k0010xGWP85Br9R8K; Mon, 14 Jan 2013 15:09:25 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id nr9R1k00x3ZTu2S3Yr9RAz; Mon, 14 Jan 2013 15:09:25 +0000 Message-ID: <50F41FA5.1070400@alum.mit.edu> Date: Mon, 14 Jan 2013 10:09:25 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 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=q20121106; t=1358176165; bh=IaeF2tf5B9dNAneDhc851kne7LwgzUnFZWXI4mmOc2U=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GQ8sq4hyxrHXxCU3k+DRKbkdjvfonDO+DzNc4ok8kXKnTc+4r5jqUawauvoJS1pA9 EoAzTzVTZwABHtC74wVgA7Ozbf/8AmulEVOCcwbD+xwDX5u5EfqHK/N8wPTjfXCU4r WpqSHQuE3pW2iOWe1qpLpoIa82MgW7tX+DNx5UtTaJ/cydeHU3OMzbdKjDM1IAIv4K rLK2EuK2LAvZZa1ZtwRnbRquvl/joI73wyj9ZhTeRqYlb7YdUdM5sbq/6NLxQADPsH LpLQfqTdJJOJxEzwnr6rbQJaTclR+PsjaoUfJ6I9W71HhjIoRMlLCQ5dNj7kDGIW5b fWayHBQHdrDTg== Subject: [clue] Cancelling today's design team meeting X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jan 2013 15:09:35 -0000 We don't seem to have anything ready to discuss. So please use the time to work on homework so we can have something to discuss next week. Thanks, Paul From internet-drafts@ietf.org Tue Jan 15 14:06:50 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9F911E80E9; Tue, 15 Jan 2013 14:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61Gr6HeFqKCc; Tue, 15 Jan 2013 14:06:49 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D68E921F845A; Tue, 15 Jan 2013 14:06:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130115220649.20824.24077.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 14:06:49 -0800 Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:06:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the ControLling mUltiple streams for tElepres= ence Working Group of the IETF. Title : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Filename : draft-ietf-clue-telepresence-requirements-03.txt Pages : 14 Date : 2013-01-15 Abstract: This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-clue-telepresence-requirement= s-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mary.ietf.barnes@gmail.com Tue Jan 15 14:25:14 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7D911E80EF for ; Tue, 15 Jan 2013 14:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.439 X-Spam-Level: X-Spam-Status: No, score=-103.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOldGUJRoUdU for ; Tue, 15 Jan 2013 14:25:13 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 29A0311E80E9 for ; Tue, 15 Jan 2013 14:25:12 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id x40so450472qcp.12 for ; Tue, 15 Jan 2013 14:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=zOwbYu++nSC5VglEFWto1g0I/JzVduUKrsqHbHkWKC8=; b=RoX6W/OWseixTEFr6mcHPkbp66KiJkxrNIhp5TyhdELD4MeDOMOD4PxAuPiusk7ULN sETgDgkdkrt5deZ5iBPt+P/nj39iC/QTlfeTmXiwXlkJbNr5eiNO5IVAUZ5WdNz67ERQ 3dJWjzR5SV7Hr0545d/8kHKMqb9t7UVBuOKsd0Y8fV7RHOa3oYMo0FwV9mBwfyRtzUVj yzl3ADl91lVYuzhQ2vLpJmK1J0kMGjvVOz34wai2eBxN+oYqjYuhkE6pwWpFZ+QVXnxk y/2ugAYlc1sv8c9+OGXD7dVcp+GH8eKouO+mIGwthheQVme5O0HNKa9DQSd0uMy4/Deq C0Ww== MIME-Version: 1.0 Received: by 10.49.72.136 with SMTP id d8mr91456276qev.62.1358288712271; Tue, 15 Jan 2013 14:25:12 -0800 (PST) Received: by 10.49.131.199 with HTTP; Tue, 15 Jan 2013 14:25:12 -0800 (PST) In-Reply-To: <20130115220649.20824.24077.idtracker@ietfa.amsl.com> References: <20130115220649.20824.24077.idtracker@ietfa.amsl.com> Date: Tue, 15 Jan 2013 16:25:12 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Fwd: I-D Action: draft-ietf-clue-telepresence-requirements-03.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 22:25:14 -0000 Hi all, The following summarizes the changes to the document: 1) Updated IANA section - i.e., no IANA registrations required. 2) Added security requirement. 3) Added some initial text to the security section. At this point, this is actually the only WG document that even mentions security. It will be very important to have a comprehensive security threat analysis in the framework document as well as the details in the solution documents. Otherwise, these documents won't get published. Note, that there are still open issues identified in the appendix that must be resolved before we can publish this document. In addition, the document needs to add some definitions. As was noted for the framework, "capture" isn't actually defined anywhere - note that there is a definition for "render". There are also a couple other terms that I think need definitions, including "spatial/spatially" (used in the context of "layout", "matching" and "position") and "scene" (used both with "capture" and without). Site switching and segment switching are also not defined, but there is an editor's note that the requirement that uses those terms needs rewording. Right now, some of the definitions in this document are also duplicated in the framework document. I personally think it helps with the readability. We just need to make sure that they remain consistent or it is noted where they might differ (as is noted, for example, for the definition of MCU in the Framework where it differs with what's defined in the other RFCs). There are also some terms in this document that are not duplicated in the framework (but are used) such as "Local" and "Render". Thus, I think we should add a statement to the framework definition section referencing the requirements document, noting that some are duplicated in the FW for readability. Regards, Mary. Note: I made the changes to this version as Steve is busied with ITU-T for the next two weeks. If anyone else would be willing to be the backup editor for the WG requirements document, please let me know. ---------- Forwarded message ---------- From: Date: Tue, Jan 15, 2013 at 4:06 PM Subject: [clue] I-D Action: draft-ietf-clue-telepresence-requirements-03.txt To: i-d-announce@ietf.org Cc: clue@ietf.org 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 : Requirements for Telepresence Multi-Streams Author(s) : Allyn Romanow Stephen Botzko Filename : draft-ietf-clue-telepresence-requirements-03.txt Pages : 14 Date : 2013-01-15 Abstract: This memo discusses the requirements for a specification that enables telepresence interoperability, by describing the relationship between multiple RTP streams. In addition, the problem statement and definitions are also covered herein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-telepresence-requirements There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-telepresence-requirements-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-telepresence-requirements-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue From mary.ietf.barnes@gmail.com Mon Jan 21 07:12:33 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 996B021F8835 for ; Mon, 21 Jan 2013 07:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GP2RT6lOHdkK for ; Mon, 21 Jan 2013 07:12:33 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1901D21F8834 for ; Mon, 21 Jan 2013 07:12:33 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id d42so2489069qca.29 for ; Mon, 21 Jan 2013 07:12:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=0wo5kkX8WKxEG+lMNsD2Wuqk2NZENd8Hh7pSubAelN8=; b=MT04M06cHz4fFLW4w3AbUxRFJ6DmCdy8QyHgj3RT166BQ6KC0qa9DF89/KzsaDa9PV OXq0eKzxEKTR9bsFrLgcXWANKKqJBtkmPvrNDsayFcyQdqhMGlcUROj+w61wYHxNeXmp XQ2C2NylYXkFDh1ivVEmN0dRYPXADrHkZNHntT9W7nyzQJcjJz36hv6J1NxC+JWTSS7x jFB6V8cIjDcJnJ/6fYEVZknf1OospNC4UuamWw2JkJJyiBWvpTaZqHy1aCc2BN2teZaF NuWP06ji7ALq45hJnv/rEXJdYOsv3fOqmhcK1WUpEjyKdn4Kh46RJzcMSd750aQc3Rea UMxg== MIME-Version: 1.0 X-Received: by 10.229.201.200 with SMTP id fb8mr3431245qcb.122.1358781152454; Mon, 21 Jan 2013 07:12:32 -0800 (PST) Received: by 10.49.131.199 with HTTP; Mon, 21 Jan 2013 07:12:32 -0800 (PST) Date: Mon, 21 Jan 2013 09:12:32 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] No Design Team Meeting today - Jan 21st X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 15:12:33 -0000 Note there is no meeting today. It is a US holiday for some folks and there has been no new mailing list discussion over the past week. Regards, Mary. From mary.ietf.barnes@gmail.com Wed Jan 23 15:16:08 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC87921F87A5 for ; Wed, 23 Jan 2013 15:16:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soehNP2+Xs6O for ; Wed, 23 Jan 2013 15:16:08 -0800 (PST) Received: from mail-qc0-f180.google.com (mail-qc0-f180.google.com [209.85.216.180]) by ietfa.amsl.com (Postfix) with ESMTP id DFD2521F84B2 for ; Wed, 23 Jan 2013 15:16:07 -0800 (PST) Received: by mail-qc0-f180.google.com with SMTP id v28so982773qcm.25 for ; Wed, 23 Jan 2013 15:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=hbF26QqMOD+7R9lW3hei2jaD85w6a28TQVRZLWGOpes=; b=hEgsXJ+9H8HikRrIqkLGS7Pzngak7J5kqcHDQF+Uja8fH/QFG15ueUQ/+GNDsS1sEW QtMUzeons5MXbx0oIdSaGYVj4dEvUbhbgQZ47v/6j8P9AQf3d4H1gZkG0hB50NWUqnML Z2D7+B6XrjNjaDplxAsOXvpVrtJUlzk42JxfaGPnAZ56fK3fXz4CIKB1jbIstiZJz17u tam643orzWQkQB6Grt54NiUdooaJb36wg85CNVtZQPv2CIGdn0MlI6+aC7x0wbRnmf88 V1k4aqtIa48OPNR7CCEwBlO+7OA7GkCAm/SmPQD7QhQufpLdRJzUFOst47SJEtF1PWYr 7aEw== MIME-Version: 1.0 X-Received: by 10.224.86.136 with SMTP id s8mr3657772qal.72.1358982961783; Wed, 23 Jan 2013 15:16:01 -0800 (PST) Received: by 10.49.131.199 with HTTP; Wed, 23 Jan 2013 15:16:01 -0800 (PST) Date: Wed, 23 Jan 2013 17:16:01 -0600 Message-ID: From: Mary Barnes To: CLUE Content-Type: text/plain; charset=ISO-8859-1 Subject: [clue] Proposal for CLUE WG Design Team meeting on January 28, 2013 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 23:16:08 -0000 Hi all, We have had virtually no mailing list discussion over the past couple weeks on this mailing list. Paul and I (as chairs) thought it would be a good idea to have a planning meeting next Monday to determine what we need to do and who will be doing what for the IETF-86 deadlines, as it's not clear that the approach discussed at IETF-85 is going to be effective: http://www.ietf.org/mail-archive/web/clue/current/msg02129.html We are at the point that we need details laid out otherwise we'll have the same discussions we've been having over the past 6-12 months. As noted last week, we also still have some work to do for the requirements document: http://www.ietf.org/mail-archive/web/clue/current/msg02312.html An additional author/editor for that document would be quite helpful, in particular someone that can drive the issues to conclusion on the mailing list. It would be really good if we could actually get some documents completed in the WG. Note that the deadlines for IETF-86 are as follows: -00 Deadline: Feb. 18th, 2012 (3 weeks from Monday) Final Draft deadline: Feb. 25th, 2012 (4 weeks from Monday) It's also important to consider that there is a joint RTCWEB/MMUSIC interim meeting planned for Feb. 5-7 in Boston: http://www.ietf.org/mail-archive/web/rtcweb/current/msg06143.html Some of these decisions may impact CLUE. Note, that Roni has been engaged in this thread and it would be good for others to contribute and pay attention to these discussions: http://www.ietf.org/mail-archive/web/mmusic/current/msg10153.html While it is extremely time consuming to follow the RTCWEB mailing list, the MMUSIC list, where the discussion has been cross-posted is not nearly as crazy and the discussions should be happening primarily there. So, I highly encourage folks involved in the CLUE signaling to make sure they are subscribed to that mailing list. Regards, Mary and Paul. From pkyzivat@alum.mit.edu Thu Jan 31 13:43:10 2013 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EDB121F86A2 for ; Thu, 31 Jan 2013 13:43:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.314 X-Spam-Level: X-Spam-Status: No, score=-0.314 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEguHqwyYt5d for ; Thu, 31 Jan 2013 13:43:09 -0800 (PST) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 787A721F867A for ; Thu, 31 Jan 2013 13:43:09 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta04.westchester.pa.mail.comcast.net with comcast id udDz1k0041ei1Bg54lj7db; Thu, 31 Jan 2013 21:43:07 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id ulj71k00s3ZTu2S3klj7WM; Thu, 31 Jan 2013 21:43:07 +0000 Message-ID: <510AE569.90506@alum.mit.edu> Date: Thu, 31 Jan 2013 16:43:05 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "Robert Hansen (rohanse2)" , Roni Even , Simon Pietro Romano , Roberta Presta , "Christer.Holmberg@ericsson.com" References: <20130131200528.4109.45255.idtracker@ietfa.amsl.com> In-Reply-To: <20130131200528.4109.45255.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130131200528.4109.45255.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1359668587; bh=vZzUwBlQnKIsFAQlPEErD5eLJPOb2p6OMdYWQo+s8UM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=j4kK4UvWdn8jgo5DDcDPPCQLyVJTTfWBiBMYSVh3jJ5zKyrFRvjpKOmWQrPg0SBLK xg1g/O8I8UnFRNBfGqiHZk9cqOPeN5/Y8P8WrNG6kdI5uAyL4izOyJHY8lqBI7iY4z diCtp5A7xYrfvdy4fmAG1wRtrflFXz/3ekgMl+sw0WS03KOnQK1sRAeDrwXtSo8+lo x6xHaadBQDPCPPQxvY2tKlj0Hm8rrWwUkD3vgcD54aPC5Qr1Kn8bV54zS2KUInsn8c 0cgpnQsqnuoIYtBlHkQnRyCeFS0JQjRJi+r+08u2al6Ul+MH85rZF7jmAkleF91ClZ I+z0FSWr+s9Zw== Cc: CLUE Subject: [clue] Posted: draft-kyzivat-clue-signaling-00.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 21:43:10 -0000 I just posted the signaling draft that I promised during the Monday design team meeting. I don't expect this to be controversial. It's mostly just an empty outline. AFAIK pretty much everything in it currently should be in line with the thinking of the wg. Certainly there is much to *quibble* about. More importantly, I want this to be a focus for discussion of what is *missing* from it. What I'm looking for now is: - suggestions for changing the scope and structure of the document; - details (text) to flesh this out. Text can come two ways: - email describing what to add/change, and where. - a revised draft, published with a new name. A new draft may be the most practical way to address big structural changes and for proposals that have lots of parts that are spread through the document. Note that I submitted this with the xml source. So anybody can pull the xml and use it create a new draft. Hopefully this will kick start progress on signaling. Thanks, Paul -------- Original Message -------- Subject: New Version Notification for draft-kyzivat-clue-signaling-00.txt Date: Thu, 31 Jan 2013 12:05:28 -0800 From: internet-drafts@ietf.org To: pkyzivat@alum.mit.edu A new version of I-D, draft-kyzivat-clue-signaling-00.txt has been successfully submitted by Paul Kyzivat and posted to the IETF repository. Filename: draft-kyzivat-clue-signaling Revision: 00 Title: CLUE Signaling Creation date: 2013-01-31 WG ID: Individual Submission Number of pages: 9 URL: http://www.ietf.org/internet-drafts/draft-kyzivat-clue-signaling-00.txt Status: http://datatracker.ietf.org/doc/draft-kyzivat-clue-signaling Htmlized: http://tools.ietf.org/html/draft-kyzivat-clue-signaling-00 Abstract: This document specifies how signaling is conducted in the course of CLUE sessions. This includes how SIP/SDP signaling is applied to CLUE sessions as well as defining a CLUE-specific signaling protocol that complements SIP/SDP and supports negotiation of CLUE application level data. The IETF Secretariat