From nobody Tue Jul 1 02:19:35 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0F641A00F8 for ; Tue, 1 Jul 2014 02:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hS5Y39axB9QI for ; Tue, 1 Jul 2014 02:19:32 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9501A00E1 for ; Tue, 1 Jul 2014 02:19:31 -0700 (PDT) X-AuditID: c1b4fb2d-f798a6d000000e9b-8b-53b27d21160d Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id F4.06.03739.12D72B35; Tue, 1 Jul 2014 11:19:30 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0174.001; Tue, 1 Jul 2014 11:19:29 +0200 From: Christer Holmberg To: Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] availability for design team call July 1 ??? Thread-Index: AQHPlBdax8nizo9J0EmeQbkkpfelLZuJ3KIAgAEWQLA= Date: Tue, 1 Jul 2014 09:19:29 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3ACC0B@ESESSMB209.ericsson.se> References: <53B0E009.1080100@alum.mit.edu>,<53B1AFCC.5020205@alum.mit.edu> In-Reply-To: <53B1AFCC.5020205@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+Jvja5S7aZgg5nb+S32n7rMbLFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvjy9q/zAWzOCs2bPzC2MC4kL2LkYNDQsBE YkqbbBcjJ5ApJnHh3nq2LkYuDiGBo4wSF25chHIWMkr0//jCCNLAJmAh0f1PG6RBRMBTYsfH KcwgtrCAg8SKP/sYIeKOEjsOr2ODsK0knjxdwA5iswioSDyZu4QJxOYV8JVY8fwKmC0k4C2x 59hBsF5OAR2JecvPg9UzAh30/dQasBpmAXGJW0/mM0EcKiCxZM95ZghbVOLl43+sELaixNXp y6HqdSQW7P7EBmFrSyxb+JoZYq+gxMmZT1gmMIrOQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg3 3chYL7UoM7m4OD9PLy+1ZBMjMEoObvmtu4Nx9WvHQ4wCHIxKPLwLlm4MFmJNLCuuzD3EKM3B oiTOu+jcvGAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjIt3L7NmObZrhtjddUszA8Lbr57c b5osMfvbuTdzrhor98x/8//6//1SX9re7Mi9Kybb/WRxgUF5bMbeS+UHmVn+KSR8CfI8G8W+ f+18ryc7rx1l0+fXUfvOO8mj6UUv/7pX/ir7H5mx5JxZN9PSu/HyitU/tL97bglNTXTeIh0v 6RUXcfn7zkglluKMREMt5qLiRABLwjHNcwIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/wwBLNINEDO7FQEUiwkHlIAXq2ro Subject: Re: [clue] availability for design team call July 1 ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 09:19:34 -0000 Hi, I intend to call in. Regards, Christer ________________________________________ From: clue [clue-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum= .mit.edu] Sent: Monday, 30 June 2014 9:43 PM To: clue@ietf.org Subject: Re: [clue] availability for design team call July 1 ??? A few of us are available for the call tomorrow, so we will go ahead and have it. Please come if you can, even though I know a number of people are unavailable. Thanks, Paul On 6/29/14 11:56 PM, Paul Kyzivat wrote: > Who all is able to attend the design team call this week? > Mary is away, Christian has a conflict. And this is Independence Day > week in the US. > > I can make it, but will we have enough people to get anything done? > > If you can make this call (topic: Signaling Open Issues) then please > reply to this email. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > _______________________________________________ clue mailing list clue@ietf.org https://www.ietf.org/mailman/listinfo/clue= From nobody Tue Jul 1 06:30:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C00D1A02C1 for ; Tue, 1 Jul 2014 06:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzoNPVaE682f for ; Tue, 1 Jul 2014 06:30:53 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 074261A0065 for ; Tue, 1 Jul 2014 06:30:52 -0700 (PDT) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta14.westchester.pa.mail.comcast.net with comcast id LzGZ1o0030mv7h05E1WsWP; Tue, 01 Jul 2014 13:30:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id M1Ws1o00N3ZTu2S3X1WsBf; Tue, 01 Jul 2014 13:30:52 +0000 Message-ID: <53B2B80C.3030805@alum.mit.edu> Date: Tue, 01 Jul 2014 09:30:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404221452; bh=gR18QdTrM4vCGR7U2wgkpCfknm2BYW1QkYtzfE6gvp0=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rTr/p14fpwP65Laur5eLo9txayEOfSVft956kTPetII76tHN1BCZPzoTTJmYka7Xx idHXhv0rvwnfAtnf9aGP/tvFHcWBq6Tm0hRVJf1gJHYPXmBsS9trOotD0P/JeR1w5V 4EkjZOm+9LJNytnENgfU2f9DRmgGQknuARN7vLLHSjhk1Ommv+V6qzuW27VEb0PhK5 HDfNpUJWSmPGZCi7FvRHhOGELfj4Sn3xNJ6Pm7V7Deo7qnv+xT+6iJqaTp4nlLlTS2 6w5hlKvK+2wMGuYKNstxM/8RtQ8DA58oikRAqWX6/9d/4PlywAm8pQyjN4RbxVymNf WdkLs7chSTRWA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/gr6XqzUnQtDVZLqq4LqS6ub8v7A Subject: [clue] design team call ended early today X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jul 2014 13:30:58 -0000 For anybody who might be coming late - a few of us met, and ended early. From nobody Fri Jul 4 04:22:39 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34CC1B2D30; Fri, 4 Jul 2014 04:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YnD24mbm_m0J; Fri, 4 Jul 2014 04:22:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D01451B2D2D; Fri, 4 Jul 2014 04:22:33 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140704112233.20593.27515.idtracker@ietfa.amsl.com> Date: Fri, 04 Jul 2014 04:22:33 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/PDgAdYDrKKSniacnC0djzJ4TgeM Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-signaling-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jul 2014 11:22:35 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : CLUE Signaling Authors : Paul Kyzivat Lennard Xiao Christian Groves Robert Hansen Filename : draft-ietf-clue-signaling-02.txt Pages : 31 Date : 2014-07-04 Abstract: This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.presta-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-signaling/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-signaling-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-signaling-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sat Jul 5 09:38:47 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 670C41A0233 for ; Sat, 5 Jul 2014 09:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jVATeCWEPhj for ; Sat, 5 Jul 2014 09:38:42 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 7B5DE1A01AA for ; Sat, 5 Jul 2014 09:38:42 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta06.westchester.pa.mail.comcast.net with comcast id NgLg1o0030ldTLk56gehoB; Sat, 05 Jul 2014 16:38:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id Ngeh1o00P3ZTu2S01gehJK; Sat, 05 Jul 2014 16:38:41 +0000 Message-ID: <53B82A11.7070009@alum.mit.edu> Date: Sat, 05 Jul 2014 12:38:41 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE References: <20140704112234.20593.32475.idtracker@ietfa.amsl.com> In-Reply-To: <20140704112234.20593.32475.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=q20140121; t=1404578321; bh=EbtHvAHnYy1/QcuRU5G6QdPNbeF52ndrshYKFl/CA/w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ufo2/AN4u5yQbBjosaSdc4f1zSLjIF+QPoky2nW2och02lW+STzxOWGeMuQUYVOis FJRw2AWJGTVlK9CMVy6L5rjd9cvbrdnChWz3/qdG6H9Ygd93yKzGcTUFruDBfDLz36 zTt18DyFrSwmBgkCnFZNDJmUKESotS1r8jVmCMWf6B4fEXOGI6iwAcxNhXNIVK3PlX EQdLQWjIh9mrKjVvKVEhBWGyACfzl0pVsbAj3iLeVeo8Df3fS37f/R+N8uvCH9BE+U C5p1/uOQsuCMITOFCzkLoUUYB7PTj82y+93Q6+KOexaN9mUCP9iWaZtbYZ2jNc+Hli 1VYwO9HGwJRfA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/0Dq17Afsd9UD8qVr7kAcTdUjMUg Subject: Re: [clue] New Version Notification for draft-ietf-clue-signaling-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Jul 2014 16:38:43 -0000 Thanks Rob! Just a couple of little things in the new version: Section 4.5.2.3: I question whether anything in this section should be normative. As best I can tell this section simply discusses implementation choices that may be made. Ultimately the receiver might choose to accept the initial media or not. And what it does with the media is its business. Nothing normative to test here. The one thing that perhaps should be normative is that the endpoints SHOULD NOT get upset and drop the call simply because the initial media has been rejected. Section 5.1: ... A CLUE-capable implementation MUST not reject CLUE protocol messages that contain elements that do not match an id in SDP. While it seems evident what this is intended to mean, when taken literally it might seem to say that if there are encID elements that don't match, then the message must not be rejected even for some other reason. Also, "MUST not" isn't good form. I suggest ... A CLUE-capable implementation MUST NOT reject a CLUE protocol message solely because it contains elements that do not match an id in SDP. Thanks, Paul From nobody Mon Jul 7 05:59:50 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DD4C1A0008 for ; Mon, 7 Jul 2014 05:59:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByOQ2b1-JqbA for ; Mon, 7 Jul 2014 05:59:38 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B01D1A0401 for ; Mon, 7 Jul 2014 05:59:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2105; q=dns/txt; s=iport; t=1404737972; x=1405947572; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=pAedjkK4zY/vkGD+ZsTy6TNnQluL2j4Flum2R4kBMGs=; b=h/6p8PjViceStZbro+PVZQUME/aOvrZm14vHvoOPKZh1PSosUUZ34Qou bRusnqC1HY6HX3CFmtHuYq6V3UMKTL+AqKH70LOH+a3cTkdwWhviMycVP 5CNQZUenmkAsDEcHllzjyB6gVznzS88RI8bX237kQTMpHM6+scwWdzESs k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al8GAIKYulOtJssW/2dsb2JhbABag2CsKwEBAQMFAW6SKYdFAYEqdYQDAQEBAwEBAQE1NgkBBgsLGAkWDwkDAgECARUwEwYCAQGINggNyVgTBIVwiTkWhC0BBJp2hw+MfYNEPA X-IronPort-AV: E=Sophos;i="5.01,618,1400025600"; d="scan'208";a="105973414" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 07 Jul 2014 12:59:30 +0000 Received: from [10.47.200.113] ([10.47.200.113]) (authenticated bits=0) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s67CxRAZ008284 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 7 Jul 2014 12:59:30 GMT Message-ID: <53BA9A47.5060001@cisco.com> Date: Mon, 07 Jul 2014 14:01:59 +0100 From: Robert Hansen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: clue@ietf.org References: <20140704112234.20593.32475.idtracker@ietfa.amsl.com> <53B82A11.7070009@alum.mit.edu> In-Reply-To: <53B82A11.7070009@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-User: rohanse2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/zMHXctrZ5HO1b4tvyrsFPmrDGkE Subject: Re: [clue] New Version Notification for draft-ietf-clue-signaling-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 12:59:45 -0000 Hi Paul, Comments in-line, On 05/07/14 17:38, Paul Kyzivat wrote: > Thanks Rob! > > Just a couple of little things in the new version: > > Section 4.5.2.3: > > I question whether anything in this section should be normative. > > As best I can tell this section simply discusses implementation > choices that may be made. Ultimately the receiver might choose to > accept the initial media or not. And what it does with the media is > its business. Nothing normative to test here. > > The one thing that perhaps should be normative is that the endpoints > SHOULD NOT get upset and drop the call simply because the initial > media has been rejected. Fair enough - the aim was to make clear to readers that some implementations might want to display an initial audio/video stream before the CLUE media was sorted out, while others might want to wait until CLUE media was sorted out before starting it up. And that in the latter case the initial answer was a good place to not accept this media. As you say, there's not much normative that can be said there, and it might be best to just ensure that people don't drop the call if they are in one mode and the far end is in the other. > Section 5.1: > > ... A CLUE-capable implementation MUST > not reject CLUE protocol messages that contain elements that > do not match an id in SDP. > > While it seems evident what this is intended to mean, when taken > literally it might seem to say that if there are encID elements that > don't match, then the message must not be rejected even for some other > reason. Also, "MUST not" isn't good form. I suggest > > ... A CLUE-capable implementation MUST > NOT reject a CLUE protocol message solely because it contains > elements that do not match an id in SDP. > [Rob] Agreed - didn't consider this interpretation, will go with your suggested text. > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Mon Jul 7 14:56:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB201B2966 for ; Mon, 7 Jul 2014 14:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH31D1F1qbWn for ; Mon, 7 Jul 2014 14:56:16 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 194901B2965 for ; Mon, 7 Jul 2014 14:56:16 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by QMTA11.westchester.pa.mail.comcast.net with comcast id PYY01o0030bG4ec5BZwF5z; Mon, 07 Jul 2014 21:56:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id PZwF1o00N3ZTu2S3PZwFVV; Mon, 07 Jul 2014 21:56:15 +0000 Message-ID: <53BB177F.7040308@alum.mit.edu> Date: Mon, 07 Jul 2014 17:56:15 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1404770175; bh=d2u50X0x4Mo2gDan7NWTtWJm90CcNHZHPnZTYi5j7L4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=mUHVlzNAye3eejmRe2RuNqSjFc2Sza7dDd2Y3S97zgZ4QmMrM8OHoJzfjJ7kFW/0F 8e3Ye7TnSB5z+5jUSwXLe0p1y5Tqpus7jSlYScGL+2S/2UQw5iSmgHJez6Ve0edcpB Z40UpwRXAZjPXGhf3q9zttlNR405MnN9XxapWk97ovGyo3CyeMfqV7YMPUE5dAXWBw 0qt9fx7P0/HwHCAJCQDV5jrWA2hP7twifvdUIGd+S4WXJqulhAScEvB0bpbL1DI190 0gLLItAXDX5ZIHBRWOpryFtuwcX73FdrQrcgq5O0pUCh11BM8g9AXYTJikUuH8vqf9 keVbwXYEkrxOQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/492ZzKRvoG87h1qf1vyBsRaaCtM Subject: [clue] CLUE draft agenda for IETF90 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2014 21:56:17 -0000 The draft agenda for CLUE is now available at: http://www.ietf.org/proceedings/90/agenda/agenda-90-clue Please review. Comments and suggestions welcome. Thanks, Paul From nobody Tue Jul 8 05:55:46 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E26A1B2833 for ; Tue, 8 Jul 2014 05:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDh0kQfUtrjA for ; Tue, 8 Jul 2014 05:55:43 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 59CEA1B2830 for ; Tue, 8 Jul 2014 05:55:43 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta10.westchester.pa.mail.comcast.net with comcast id PnrR1o00217dt5G5Aoviix; Tue, 08 Jul 2014 12:55:42 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id Povi1o00g3ZTu2S3ZoviT7; Tue, 08 Jul 2014 12:55:42 +0000 Message-ID: <53BBEA4E.6060601@alum.mit.edu> Date: Tue, 08 Jul 2014 08:55:42 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE References: <1661356127.2140201404823576670.JavaMail.nobody@rva2rmd001.webex.com> In-Reply-To: <1661356127.2140201404823576670.JavaMail.nobody@rva2rmd001.webex.com> X-Forwarded-Message-Id: <1661356127.2140201404823576670.JavaMail.nobody@rva2rmd001.webex.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=q20140121; t=1404824142; bh=jyk6MOfeGMjWFpn8bJx/okYxpYL6jBbnZMkCMtrusaA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OO3DLxmOnhdaFJJNQpSUIpIWMQWC9XTZLHnLAuHNeEi2Rd0ddTYqDbMKQ39xH2sXT +v8GwztjPNyU8UTGWFs7n4RQwLt1/YruHjEeSltbkauJ/PB5BnWIjMHeADucyxRAnR pedEWCreTt+ppU0Cy2zQXNeBZWZwaeMXj1M4rljqUY1wCMsdReBq0DJDOkQFmBR1Vf DVB4ydOwqhXZm3zCZFPcNEW7XJPlJMNQ35kqXHgocZdBM6tuEbo0hSt2piuT0ekhUi zHpiYnVIuTjgi/V30Xmwc1Rl9IZ7lnBKEaJA6PbAloh7P2oUM8wUwfpvZ0WBLKNYFD TSbMpHTP56/Qw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KOTLJlRZOh0WzjtlMgafZ5qRYmk Subject: [clue] Fwd: Meeting reminder: CLUE WG Signaling Design Team - TODAY: Protocol X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 12:55:44 -0000 -------- Original Message -------- Subject: Meeting reminder: CLUE WG Signaling Design Team Resent-Date: Tue, 8 Jul 2014 08:46:43 -0400 Resent-From: wg-alias-bounces@tools.ietf.org Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu Date: Tue, 8 Jul 2014 12:46:16 +0000 (GMT) From: messenger@webex.com Reply-To: clue-chairs@tools.ietf.org To: clue-chairs@tools.ietf.org You are scheduled to host this online meeting. Topic: CLUE WG Signaling Design Team Date: Tuesday, July 8, 2014 Time: 8:00 am, Central Daylight Time (Chicago, GMT-05:00) Meeting Number: 646 255 438 Meeting Password: 1234 Host Key: 506804 ------------------------------------------------------- To start the online meeting ------------------------------------------------------- 1. Go to https://ietf.webex.com/ietf/j.php?MTID=m97a075cdf11541feaead4fb3ea99d9ea 2. If you are not logged in, log in to your account. ------------------------------------------------------- Audio conference information ------------------------------------------------------- Call-in toll number (US/Canada): 1-650-479-3208 Access code:646 255 438 To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ietf.webex.com/ietf/systemdiagnosis.php http://www.webex.com IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation. From nobody Tue Jul 8 06:32:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA65B1B2853 for ; Tue, 8 Jul 2014 06:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZiSRJyawwOa for ; Tue, 8 Jul 2014 06:32:53 -0700 (PDT) Received: from qmta01.westchester.pa.mail.comcast.net (qmta01.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:16]) by ietfa.amsl.com (Postfix) with ESMTP id 9823C1B2AC5 for ; Tue, 8 Jul 2014 06:32:53 -0700 (PDT) Received: from omta03.westchester.pa.mail.comcast.net ([76.96.62.27]) by qmta01.westchester.pa.mail.comcast.net with comcast id PpAW1o0070bG4ec51pYtcm; Tue, 08 Jul 2014 13:32:53 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta03.westchester.pa.mail.comcast.net with comcast id PpYs1o01H3ZTu2S3PpYtMj; Tue, 08 Jul 2014 13:32:53 +0000 Message-ID: <53BBF304.90400@alum.mit.edu> Date: Tue, 08 Jul 2014 09:32:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE References: <1661356127.2140201404823576670.JavaMail.nobody@rva2rmd001.webex.com> <53BBEA4E.6060601@alum.mit.edu> In-Reply-To: <53BBEA4E.6060601@alum.mit.edu> 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=q20140121; t=1404826373; bh=r3DPsKtQpBhtwPjGkeecDjsGRuyAffH7thX9xAMdhZc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=o97iLunwsYRMgtlntkdDye9ZAqJ0mTTmLpLwr3rUlxQ3glycxn3cbrlk1QWgIjJqm d8g0ciIRp6ou9tmX+KWtllgd8ityW65E63zONru98ASfncqESLeg82uF0yW5AkVuQn kif7z0jlJw6KcH1gHmFbY34pTJQuptM/hpevkIPx2ZBnnNlhow+6N9cpu5Ufyv/1oT I2XU+DYtsM7tpCb632mch81be3KHnDK7qoqKMwrH/CeIWTGCfzt/wEwCWeM8R5kKi2 8ByRNoN0MUoDWvc7k0JdDbDKzY2WBcSakdS18Ew/9Bq1IJesM15xqaAgqze9F9uS5Z S5+gMG1ci2/RQ== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xb4B8HCaMMH8KIxtH_VQkQSfWZc Subject: [clue] CLUE WG Signaling Design Team (TODAY: Protocol) cancelled X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jul 2014 13:32:54 -0000 It turned out that there was nothing ready to discuss on the protocol, so we ended the meeting early. It has been the plan that this be the last design team meeting before IETF90. The slot is potentially available next week, but won't be used unless somebody requests it for something important. Next week is the week before IETF90. If you are like me, you will need most of that week to prepare for the meeting. Thanks, Paul On 7/8/14 8:55 AM, Paul Kyzivat wrote: > > > > -------- Original Message -------- > Subject: Meeting reminder: CLUE WG Signaling Design Team > Resent-Date: Tue, 8 Jul 2014 08:46:43 -0400 > Resent-From: wg-alias-bounces@tools.ietf.org > Resent-To: mary.ietf.barnes@gmail.com, pkyzivat@alum.mit.edu > Date: Tue, 8 Jul 2014 12:46:16 +0000 (GMT) > From: messenger@webex.com > Reply-To: clue-chairs@tools.ietf.org > To: clue-chairs@tools.ietf.org > > > > > You are scheduled to host this online meeting. > > Topic: CLUE WG Signaling Design Team > Date: Tuesday, July 8, 2014 > Time: 8:00 am, Central Daylight Time (Chicago, GMT-05:00) > Meeting Number: 646 255 438 > Meeting Password: 1234 > Host Key: 506804 > > ------------------------------------------------------- > To start the online meeting > ------------------------------------------------------- > 1. Go to > https://ietf.webex.com/ietf/j.php?MTID=m97a075cdf11541feaead4fb3ea99d9ea > 2. If you are not logged in, log in to your account. > > ------------------------------------------------------- > Audio conference information > ------------------------------------------------------- > Call-in toll number (US/Canada): 1-650-479-3208 > > Access code:646 255 438 > To check whether you have the appropriate players installed for UCF > (Universal Communications Format) rich media files, go to > https://ietf.webex.com/ietf/systemdiagnosis.php > > http://www.webex.com > > > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. You should inform all meeting attendees > prior to recording if you intend to record the meeting. Please note that > any such recordings may be subject to discovery in the event of litigation. > > From nobody Mon Jul 14 15:14:51 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBB71A014B for ; Mon, 14 Jul 2014 15:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dDrFxeeZS8-C for ; Mon, 14 Jul 2014 15:14:49 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 071131A0149 for ; Mon, 14 Jul 2014 15:14:48 -0700 (PDT) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by QMTA11.westchester.pa.mail.comcast.net with comcast id SLzt1o0041YDfWL5BNEowC; Mon, 14 Jul 2014 22:14:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta20.westchester.pa.mail.comcast.net with comcast id SNEn1o00g3ZTu2S3gNEneW; Mon, 14 Jul 2014 22:14:48 +0000 Message-ID: <53C45657.10802@alum.mit.edu> Date: Mon, 14 Jul 2014 18:14:47 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405376088; bh=6Q8TLxLOmvMufNNlbwvMjPH+ihQSJ9ep13ydHteqjbo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=rxvpkAMRwzWPz8fZOEFnP4CCxgfSZjIyA3EO6di7FI2mTlAStRRNUPgyoXsHg9Eet Pi0nEbm32R9fjHprcV5JjfYXZQZZ5TAa2MljoulSpvO+m/Gzd7uUS6yQQd52MgXkYc VfMVjpKjBvABIlo3/dVOsVSZei1LHxE+MiLId1Ccja9Wiwk/oDwDp0G104ykr76o45 R9BS7VpGjJ+VBdLgI15PX/QOJQ9snbHOmF3KW3SvHT/6M/3k4rJvI8vSitJd/sOXMx LExvUOreEJgaXTC6fU5J9FxO+PT4SJYpLfnA8sbKzDLxf8abxMizmQJOuW5JpadvGK uwQUEEqXf6Ruw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/eF4hb5Ic3IO8HD9RB_IDBtraNfI Subject: [clue] Comments on draft-ietf-clue-data-model-schema-06 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 22:14:50 -0000 I think I understand all the technical changes in this version, and they seem reasonable to me. The issues I noted are all editorial. Definition of "Camera-Left and Right": Internally it has "cameraright" that should be "camera-right". Also, I wonder if the term being defined (currently "Camera-Left and Right") should be "Camera-Left and Camera-Right", or else be two separate definitions. Definition of "Encoding or Individual Encoding": There is a spurious " s" at the end of the definition. Section 10.4: There was a change in this version, changing "recording" to "registration" in a couple of places. I don't understand what is meant by "registration" in this context, while "recording" made sense to me. Section 10.6: This version changed "MCC" to "MMCC". I think it was right before. I don't know what an MMCC is. In addition, there have been a large number of editorial changes, revising the English language usage. While preferred usage is somewhat subjective, for most of these changes IMO the -05 usage is preferable to the -06 usage. I didn't try to identify them all - there are many. I suggest reviewing the diff with an eye specifically on this. Thanks, Paul From nobody Mon Jul 14 15:43:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1B251A0188 for ; Mon, 14 Jul 2014 15:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ngV58xhJ07qM for ; Mon, 14 Jul 2014 15:43:33 -0700 (PDT) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 060791A0173 for ; Mon, 14 Jul 2014 15:43:32 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta06.westchester.pa.mail.comcast.net with comcast id SNNE1o0011ei1Bg56NjY17; Mon, 14 Jul 2014 22:43:32 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id SNjY1o00J3ZTu2S3kNjYbH; Mon, 14 Jul 2014 22:43:32 +0000 Message-ID: <53C45D14.1010404@alum.mit.edu> Date: Mon, 14 Jul 2014 18:43:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405377812; bh=f3+fsn/5XLGVdcl8b+B9fdMxZm1/+OfVCsQhdkfeniY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QwuLkdCafYO7PGCz2j/1deTpBDKJJFQoHC48M8NTGR3fMQuJ15YTT1HVA7H+fGCW/ OhPhsiLVGMGPhCy8d+r2kQO/5567qvSqTvJPdhCC9c4cLhhIgRnXut85hV4fzqwhIa WDJbvXd4Os+KFD5IT1oC4JyTc/AajFuY2YDHVylhGC6dICB33MrD4cYoYR94+Ne4ks JZLnxpwpqHWbbjZDW1Zx1HvcK2+EpF7tCJPVG4M/nAl453ExcAWp6NbwNvmBueT4IM Fjrn80ifQkIBdm6Tn5bfNDFqXF3ATbzlaKUetSG+qsjaAVydQvG/77LY5OwXJElMXB 6wj9Vi3Ev6new== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/vlz3vm0cCc3wKB030Bm0c3y0ivM Subject: [clue] Comments on draft-ietf-clue-protocol-01 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jul 2014 22:43:34 -0000 I know others have questioned representing versions as strings of form "M.m", vs. representing them as two fields. ISTM we need to discuss the tradeoffs here. This representation is certainly concise, and convenient for the sender. It would be convenient for the receiver too if all version comparisons were for equality. But there is need for the receiver to compare major and minor parts separately, and to do a numeric >= comparison on the minor version, so its necessary for the receiver to parse the received version values. Having them as separate attributes would make this easier. But it would make messages bigger. And it really just moves the parsing from the application code to the xml processor. Also, I think that the complex comparison only needs to be done for the OPTIONS message. Only the v= is used in other messages, and should only need an equality comparison as a verification. So in balance, I personally am in favor of the representation you have chosen. Have the examples been verified to be compatible with the schema? Thanks, Paul From nobody Wed Jul 16 10:20:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCA371A0091 for ; Wed, 16 Jul 2014 10:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQJYJ9Xvq6dD for ; Wed, 16 Jul 2014 10:20:44 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.1]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECA501A0089 for ; Wed, 16 Jul 2014 10:20:43 -0700 (PDT) Received: from [216.82.249.212:53060] by server-1.bemta-12.messagelabs.com id C7/D1-26773-A64B6C35; Wed, 16 Jul 2014 17:20:42 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-2.tower-219.messagelabs.com!1405531241!7785133!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 6335 invoked from network); 16 Jul 2014 17:20:42 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-2.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jul 2014 17:20:42 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 16 Jul 2014 10:20:41 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Wed, 16 Jul 2014 10:20:39 -0700 Thread-Topic: framework references to other documents - normative or informative? Thread-Index: Ac+hGbZKRsT5RsYZSESV1AYrGIVoAA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9BCRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/t_rSIcwvzlzeSmugs2aFlqTZWJE Subject: [clue] framework references to other documents - normative or informative? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:20:47 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9BCRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-ietf-clue-framework-16 has a section for "Informative References", wi= th a note reminding us to check if any of these should be normative. By wh= at criteria do we decide if a reference is informative or normative? Can a= nybody suggest how these should be categorized? And it seems to me we should add references to the other CLUE documents lik= e data model, protocol, signaling, and I would think those would be normati= ve, is that right? Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9BCRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-ietf-clue-= framework-16 has a section for “Informative References”, with a= note reminding us to check if any of these should be normative.  By w= hat criteria do we decide if a reference is informative or normative? = Can anybody suggest how these should be categorized?

 

And it seems to me = we should add references to the other CLUE documents like data model, proto= col, signaling, and I would think those would be normative, is that right?<= o:p>

 

Mark

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9BCRPMBOXPRD08p_-- From nobody Wed Jul 16 10:38:33 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F241A00E5 for ; Wed, 16 Jul 2014 10:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7jERHuvgPEdM for ; Wed, 16 Jul 2014 10:38:30 -0700 (PDT) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id E16D41A008B for ; Wed, 16 Jul 2014 10:38:29 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta12.westchester.pa.mail.comcast.net with comcast id T5LJ1o0021c6gX85C5eVH1; Wed, 16 Jul 2014 17:38:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta23.westchester.pa.mail.comcast.net with comcast id T5eV1o00P3ZTu2S3j5eV3v; Wed, 16 Jul 2014 17:38:29 +0000 Message-ID: <53C6B895.5020007@alum.mit.edu> Date: Wed, 16 Jul 2014 13:38:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405532309; bh=JdYGgMUU/p5rHiDsZWJnmJP+cURwMtZVpsP1EZhZz64=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gUeDMkccmNcz41A0rPIY+xddkIqOGFJNLLVnsV30r3ZHMjJvNRZ0HBmcP1M8nJ1ya ZMoHFfMdygSYwIJNIJClK4NgH5dm4LfuDQMkNuqa3uzv3eB0yiggRA2eaIXX6eS/AC tgAdDFPjbxKlExZYdm+D9TxFFUVnMf9c4QaTy7b+79bhK1nDfCqpiQGIi7F4KNOryg WYpmee63Jz0n/3sVphwT9Ntjs1xY5SCe1wE75DNtzhW9/V4HxZka5mfbGsCPszZb12 2lrs205Hs82u9tg56jiWGUu4I3+ArSebqMABAbJVVViyVqFlvCtP4maTwcd3UoZ8vo Z0iyvZHmIPGyA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/a0geiD4mcU7EjqcNS2JCsXQOrgg Subject: Re: [clue] framework references to other documents - normative or informative? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 17:38:30 -0000 On 7/16/14 1:20 PM, Duckworth, Mark wrote: > draft-ietf-clue-framework-16 has a section for “Informative References”, > with a note reminding us to check if any of these should be normative. > By what criteria do we decide if a reference is informative or > normative? Can anybody suggest how these should be categorized? See RFC3967 > And it seems to me we should add references to the other CLUE documents > like data model, protocol, signaling, and I would think those would be > normative, is that right? If the references aren't required to read the framework document itself then there is no need to include the reference. In fact IdNits will complain if you include references that aren't used at all in the doc. The complete set of normative references can be obtained by recursion. But perhaps a case can be made that an overview might be written to help the reader understand the document set, and that would include references to all the documents. Thanks, Paul From nobody Wed Jul 16 11:00:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0401A0154 for ; Wed, 16 Jul 2014 11:00:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9R5qYN-OI_N for ; Wed, 16 Jul 2014 11:00:53 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.105]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4151A014B for ; Wed, 16 Jul 2014 11:00:53 -0700 (PDT) Received: from [216.82.254.19:64694] by server-9.bemta-7.messagelabs.com id 31/E5-01466-4DDB6C35; Wed, 16 Jul 2014 18:00:52 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-6.tower-96.messagelabs.com!1405533651!20295704!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1600 invoked from network); 16 Jul 2014 18:00:52 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-6.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jul 2014 18:00:52 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 16 Jul 2014 10:59:56 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 16 Jul 2014 10:59:54 -0700 Thread-Topic: [clue] framework references to other documents - normative or informative? Thread-Index: Ac+hHMYVxrwgsdO3TqOjnqs65R2dTgAArvAg Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> <53C6B895.5020007@alum.mit.edu> In-Reply-To: <53C6B895.5020007@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZvhHug_5PXCp_ufMaMPiQzs1ZY4 Subject: Re: [clue] framework references to other documents - normative or informative? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 18:00:54 -0000 Thanks, I'll look at RFC3967. > But perhaps a case can be made that an overview might be written to help > the reader understand the document set, and that would include references > to all the documents. Yes, that's what I meant. Do you think the framework should include such a= n overview? Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Wednesday, July 16, 2014 1:38 PM > To: clue@ietf.org > Subject: Re: [clue] framework references to other documents - normative o= r > informative? >=20 > On 7/16/14 1:20 PM, Duckworth, Mark wrote: > > draft-ietf-clue-framework-16 has a section for "Informative > > References", with a note reminding us to check if any of these should b= e > normative. > > By what criteria do we decide if a reference is informative or > > normative? Can anybody suggest how these should be categorized? >=20 > See RFC3967 >=20 > > And it seems to me we should add references to the other CLUE > > documents like data model, protocol, signaling, and I would think > > those would be normative, is that right? >=20 > If the references aren't required to read the framework document itself > then there is no need to include the reference. In fact IdNits will compl= ain if > you include references that aren't used at all in the doc. >=20 > The complete set of normative references can be obtained by recursion. >=20 > But perhaps a case can be made that an overview might be written to help > the reader understand the document set, and that would include references > to all the documents. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Jul 16 11:23:30 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8241A014B for ; Wed, 16 Jul 2014 11:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phiN3QOaVl0k for ; Wed, 16 Jul 2014 11:23:24 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 05A891A00A8 for ; Wed, 16 Jul 2014 11:23:22 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id T4Ha1o0060vyq2s5A6PMUo; Wed, 16 Jul 2014 18:23:21 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id T6PM1o00j3ZTu2S3R6PMGe; Wed, 16 Jul 2014 18:23:21 +0000 Message-ID: <53C6C319.5040604@alum.mit.edu> Date: Wed, 16 Jul 2014 14:23:21 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> <53C6B895.5020007@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405535001; bh=W2aLhvlJ05/Ie76wyoBISW2ulK9GSvtrX2ShV1eBqns=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=EsGcrKX6ogZw/AtxiIYif/v+t3uhc5wa0pNQvdWOK8yn8Ko/THHiYihGUeosOBHlC hZyn64k2vYyrp5rLIaPS63XcwcF9YZYw3Avv8Em5B+DlNJbAPTG7zr275oz141WkBz T060VnGFbW08tyuzdwxHKCoa62Jkkywqkc7kGkMvwnbuSdj4NSrcOsbg2u1WDoz9vd DBYAH23DZ5jJLCBumGTGgdlS1ZOQDKY2uMU2E1xS6jfTsDKlqOfqHJtLR9sR4jdX6R gsjqh+wF48AYEJgoTx870AD9atQ3YijfoK6JzL5IgERMh4INWbcITmz4LgnqQgeDrC csnt0biE0JIvg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/y1teyr6NVptAMHXcxVE9PtAl5Q4 Subject: Re: [clue] framework references to other documents - normative or informative? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 18:23:25 -0000 On 7/16/14 1:59 PM, Duckworth, Mark wrote: > Thanks, I'll look at RFC3967. > >> But perhaps a case can be made that an overview might be written to help >> the reader understand the document set, and that would include references >> to all the documents. > > Yes, that's what I meant. Do you think the framework should include such an overview? Judgement call. In my personal opinion it isn't needed - just makes the doc bigger. Working top down will lead to the documents when they are needed. YMMV. Thanks, Paul > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Wednesday, July 16, 2014 1:38 PM >> To: clue@ietf.org >> Subject: Re: [clue] framework references to other documents - normative or >> informative? >> >> On 7/16/14 1:20 PM, Duckworth, Mark wrote: >>> draft-ietf-clue-framework-16 has a section for "Informative >>> References", with a note reminding us to check if any of these should be >> normative. >>> By what criteria do we decide if a reference is informative or >>> normative? Can anybody suggest how these should be categorized? >> >> See RFC3967 >> >>> And it seems to me we should add references to the other CLUE >>> documents like data model, protocol, signaling, and I would think >>> those would be normative, is that right? >> >> If the references aren't required to read the framework document itself >> then there is no need to include the reference. In fact IdNits will complain if >> you include references that aren't used at all in the doc. >> >> The complete set of normative references can be obtained by recursion. >> >> But perhaps a case can be made that an overview might be written to help >> the reader understand the document set, and that would include references >> to all the documents. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue > From nobody Wed Jul 16 11:43:03 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E071A01CB for ; Wed, 16 Jul 2014 11:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZabR9UWEIL_i for ; Wed, 16 Jul 2014 11:42:57 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E91E1A0175 for ; Wed, 16 Jul 2014 11:42:57 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id t60so1375215wes.34 for ; Wed, 16 Jul 2014 11:42:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=z2DE08dLUJ7wt76hPNGiF6N3KguAkr2RWuWn5nf6RuE=; b=bD+OiAVN60nNqNqKBt2ZdDSRHeie9Bw3C91azgPAJpwu+xxpgWyH75I4z76wjEV7J1 Y9ytGNM8ibT+vAtsCDcczKfFnQSGe41I4/iGbvkDB00Rh9emsWtIORNH60WA2qMPiIJc ekdCv7QSupgT/MGWDjOIzXz+xy0bYGCQNHCeVye3b0bfPLQDmX+hBgXPZ6mqkQcV9g3Q vsr0uDvboFPa+L/ytg3GrF5G9IbPUSr68gw1cbfUtY2y2DF+RS+icKZgeY2h+t7EmO2d mKFEWGJANoLZfnvLo6bhPmNXIVa9dVi6OVQLSHiTJUjqa8pwMCVQCrn7UHsa8gVoAoap 6vnQ== MIME-Version: 1.0 X-Received: by 10.194.179.4 with SMTP id dc4mr37881856wjc.32.1405536175448; Wed, 16 Jul 2014 11:42:55 -0700 (PDT) Received: by 10.216.222.67 with HTTP; Wed, 16 Jul 2014 11:42:55 -0700 (PDT) In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> <53C6B895.5020007@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> Date: Wed, 16 Jul 2014 13:42:55 -0500 Message-ID: From: Mary Barnes To: "Duckworth, Mark" Content-Type: multipart/alternative; boundary=089e013d115e74ea5304fe53e4c2 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/t1_66wsoO-dsJ2nKPWv5NpToBZY Cc: "clue@ietf.org" Subject: Re: [clue] framework references to other documents - normative or informative? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 18:43:00 -0000 --089e013d115e74ea5304fe53e4c2 Content-Type: text/plain; charset=UTF-8 I would think in cases where the framework currently refers explicitly to other WG deliverables, we could add a reference. I don't think it's absolutely necessary to add an overview to the framework. As far as the other references RFC 2119 and all the others could be made normative, although it's easier to leave the informational docs as Informative for obvious reasons (i.e., no downrefs). Mary. On Wed, Jul 16, 2014 at 12:59 PM, Duckworth, Mark < Mark.Duckworth@polycom.com> wrote: > Thanks, I'll look at RFC3967. > > > But perhaps a case can be made that an overview might be written to help > > the reader understand the document set, and that would include references > > to all the documents. > > Yes, that's what I meant. Do you think the framework should include such > an overview? > > Mark > > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Wednesday, July 16, 2014 1:38 PM > > To: clue@ietf.org > > Subject: Re: [clue] framework references to other documents - normative > or > > informative? > > > > On 7/16/14 1:20 PM, Duckworth, Mark wrote: > > > draft-ietf-clue-framework-16 has a section for "Informative > > > References", with a note reminding us to check if any of these should > be > > normative. > > > By what criteria do we decide if a reference is informative or > > > normative? Can anybody suggest how these should be categorized? > > > > See RFC3967 > > > > > And it seems to me we should add references to the other CLUE > > > documents like data model, protocol, signaling, and I would think > > > those would be normative, is that right? > > > > If the references aren't required to read the framework document itself > > then there is no need to include the reference. In fact IdNits will > complain if > > you include references that aren't used at all in the doc. > > > > The complete set of normative references can be obtained by recursion. > > > > But perhaps a case can be made that an overview might be written to help > > the reader understand the document set, and that would include references > > to all the documents. > > > > Thanks, > > Paul > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --089e013d115e74ea5304fe53e4c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I would think in cases where the framework currently refer= s explicitly to other WG deliverables, we could add a reference. =C2=A0I do= n't think it's absolutely necessary to add an overview to the frame= work.

As far as the other references RFC 2119 and all the others c= ould be made normative, although it's easier to leave the informational= docs as Informative for obvious reasons (i.e., no downrefs).

Mary.=C2=A0


On Wed, Jul 16, 2014 at 12:59 PM, Duckworth, Mark = <Mark.Duckworth@polycom.com> wrote:
Thanks, I'll look at RFC3967.

> But perhaps a case can be made that an overview might be written to he= lp
> the reader understand the document set, and that would include referen= ces
> to all the documents.

Yes, that's what I meant. =C2=A0Do you think the framework should= include such an overview?

Mark

> -----Original Message-----
> From: clue [mailto:clue-bounc= es@ietf.org] On Behalf Of Paul Kyzivat
> Sent: Wednesday, July 16, 2014 1:38 PM
> To: clue@ietf.org
> Subject: Re: [clue] framework references to other documents - normativ= e or
> informative?
>
> On 7/16/14 1:20 PM, Duckworth, Mark wrote:
> > draft-ietf-clue-framework-16 has a section for "Informative<= br> > > References", with a note reminding us to check if any of the= se should be
> normative.
> > By what criteria do we decide if a reference is informative or > > normative? =C2=A0Can anybody suggest how these should be categori= zed?
>
> See RFC3967
>
> > And it seems to me we should add references to the other CLUE
> > documents like data model, protocol, signaling, and I would think=
> > those would be normative, is that right?
>
> If the references aren't required to read the framework document i= tself
> then there is no need to include the reference. In fact IdNits will co= mplain if
> you include references that aren't used at all in the doc.
>
> The complete set of normative references can be obtained by recursion.=
>
> But perhaps a case can be made that an overview might be written to he= lp
> the reader understand the document set, and that would include referen= ces
> to all the documents.
>
> =C2=A0 =C2=A0 =C2=A0 Thanks,
> =C2=A0 =C2=A0 =C2=A0 Paul
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue

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

--089e013d115e74ea5304fe53e4c2-- From nobody Wed Jul 16 14:25:32 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C801A008C for ; Wed, 16 Jul 2014 14:25:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 19EV2GXwzYKX for ; Wed, 16 Jul 2014 14:25:26 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.100]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B331F1A00AF for ; Wed, 16 Jul 2014 14:25:26 -0700 (PDT) Received: from [216.82.254.20:36987] by server-4.bemta-7.messagelabs.com id CF/27-26972-5CDE6C35; Wed, 16 Jul 2014 21:25:25 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-47.messagelabs.com!1405545923!19408203!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30506 invoked from network); 16 Jul 2014 21:25:24 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-13.tower-47.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jul 2014 21:25:24 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 16 Jul 2014 14:25:23 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 16 Jul 2014 14:25:22 -0700 Thread-Topic: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt Thread-Index: Ac+T+XWXU1vBSXCgR/aH4I7P88S/wQNH1Kcw Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> References: <53B0ADDC.5060706@alum.mit.edu> In-Reply-To: <53B0ADDC.5060706@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/jfmN6RWTIig5UrLJPb2Dvf2-HCY Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:25:31 -0000 Hi Paul, Thanks for all the comments. Responses inline. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Sunday, June 29, 2014 8:23 PM > To: clue@ietf.org > Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt > > I apologize for being late with my own pre-WGLC review comments on this. > I ended up spending a lot more time on it than I allotted. (And I > procrastinated.) Also, I know there are some overlaps between my > comments and Christians. I've left them in because it is easier than remo= ving > them and I may have some different nuances. > > And here I am speaking as an individual, not a chair. > > References: > > There is no separate section for References. They are found at the end of > the "Changes since last version" section. I assume this is a bug. [Duckworth, Mark] I think you mean it should be section number 17? I'll fi= x that. It's been that way for a long time, not sure why. > Section 1: > > In the following: > > The signaling details and data model are provided > in subsequent documents. > > ISTM that the documents aren't "subsequent", in that there is no natural > ordering relationship among them. I suggest "separate" (or "companion") > documents. E.g., [Duckworth, Mark] I agree > Companion documents describe signaling details [reference] and > the data model. [reference] > (These documents aren't currently in the references.) [Duckworth, Mark] I agree we should add those to the references. Should we= itemize all the "companion documents" here, with very brief description of= them? > Section 3: > > Re Capture Device: > > Capture Device: A device that converts audio and video input into > an electrical signal, in most cases to be fed into a media encoder. > > This definition only applies to audio and video. (E.g., it excludes real-= time > text.) The grouping taxonomy defines it as: > a physical entity performing a Media Capture transformation. [Duckworth, Mark] How about changing the definition to: "A device that conv= erts physical input, such as audio, video or text, into an electrical signa= l, in most cases to be fed into a media encoder " This should cover cameras, microphones, keyboards... > Re Capture Encoding: > > Can we relate this directly to the grouping taxonomy? The taxonomy alread= y > does so, saying it is > > a term to describe an Encoded Stream > > I'm not certain this is quite right - I think the description is of more = than the > Encoded stream - maybe a "Source RTP Stream". Whatever we decide, we > should ensure that the fw and the taxonomy are updated to be consistent. [Duckworth, Mark] Previous discussion led to Bo updating the taxonomy to sa= y "Telepresence specifications from CLUE WG uses this term to describe an E= ncoded Stream (Section 2.1.7) related to CLUE specific semantic information= ." Do you think we need further clarification? Is this an issue for the t= axonomy document? [Duckworth, Mark] The definitions in CLUE framework are supposed to be norm= ative, so we can't define them in terms of the Informational taxonomy docum= ent, can we? > Re Endpoint: I think we could align better with the taxonomy. (We are pre= tty > close.) [Duckworth, Mark] I think it's not close, it's a different concept. My und= erstanding is that A CLUE endpoint can have multiple taxonomy end points. = An MCU is not a CLUE endpoint, but an MCU includes taxonomy end points. Wh= at do you suggest we change? > Re Front: > > Front: the portion of the room closest to the cameras. In going > towards back you move away from the cameras. > > Do we need this? It is only referenced once, in the definition of spatial > relationships. > > Also, unless all the cameras are placed on the same side of the room it i= s not > unique. (There is a separate Front for each camera.) [Duckworth, Mark] I think we need the definition, but maybe just in the spa= tial relation section and not explicitly in the definitions section, is tha= t what you mean? I understand your point about cameras in different locati= ons. I think each Capture Scene must have a unique Front direction, becaus= e it is supposed to have a single coordinate system for everything in the s= cene, even if cameras are in different places. Should we try to clarify th= is in the document? > Re MCU: > > The taxonomy now has what seems to be a good definition of MCU. Can we > refer to that one? We may have to specialize the definition for our purpo= ses > - requiring that it support CLUE. (That might mean we need to have a > different name, such as CLUE MCU.) [Duckworth, Mark] The taxonomy does have a good description of MCU, describ= ing how current common usage of the term MCU maps to other terms defined in= taxonomy. I agree this is consistent with CLUE's usage of MCU. Maybe we = should update the CLUE definition to be more like the taxonomy definition? = Or help me understand how a reference to the Informational taxonomy doc co= uld work. > Re Media Capture: > > Our definition differs from the taxonomy in a significant way. Ours descr= ibes > it as a form of "data" while the taxonomy describes it as a process. I'm = not > quite sure what to recommend for aligning these. I suspect one or the oth= er > needs to be renamed. [Duckworth, Mark] I think it is good the way it is. CLUE definition is "a = source of Media, such as from one or more Capture Devices or constructed fr= om other Media streams". I think the source of media can be from a process= (or transformation, as the taxonomy calls it). Taxonomy says : "Teleprese= nce specifications from CLUE WG uses this term to describe either a Media C= apture (Section 2.1.2) or a Media Source (Section 2.1.4), depending on in w= hich context the term is used." I think this is accurate. > Re Media Consumer: > > Media Consumer: an Endpoint or middle box that receives Media > streams > > I think "Media Streams" is too general here. I suggest: > > Media Consumer: an Endpoint or middle box that is capable of > receiving Media Encodings. [Duckworth, Mark] Do you mean "... capable of receiving Capture Encodings"?= I would agree with that. > Re Media Provider: > > Similar to above I suggest: > > Media Provider: an Endpoint or middle box that is capable of > sending Media Encodings. [Duckworth, Mark] I would agree with "... capable of sending Capture Encodi= ngs" > Re Multiple Content Capture: > > This is limited to audio and video. Couldn't we potentially have an MCC f= or > switched or mixed real-time text? How about: > > Multiple Content Capture: A Capture that mixes and/or switches > other Captures of a single type. (E.g. all audio or all video.) > Particular Media Captures may or may not be present in the > resultant Capture Encoding depending on time or space. Denoted as > MCCn in the example cases in this document. [Duckworth, Mark] I agree. > Instead of just mentioning that MCCn may be used in examples, shouldn't > we actually define MCC as an abbreviation? [Duckworth, Mark] I agree. How about just using "Multiple Content Capture = (MCC): A Capture that mixes...", which is how we do it for defining CSE. > Re Stream: > > Can we relate this to the taxonomy? I think this corresponds to both a > "Source RTP Stream" and a "Received RTP Stream". [Duckworth, Mark] I agree. Can we keep our current definition, and add an = informative reference to the taxonomy about this? > Re Middlebox: > > This term isn't defined but it is used. I think it deserves a definition. [Duckworth, Mark] I agree, but I don't have a good suggestion for a definit= ion :( Is it more general than an MCU? Is a device that has user agents f= or signaling, but no media handling, considered a middle box? > Section 4: > > The following: > > ... In a few circumstances, a CLUE Endpoint middlebox > includes only Consumer or Provider functionality, such as > recorder-type Consumers or webcam-type Providers. ... > > I *think* this should say "Endpoint *or* middlebox". [Duckworth, Mark] I agree. > Section 5: > > The following: > > This Advertisement and Configure MUST occur during call initiation > but MAY also happen at any time throughout the call, whenever there > is a change in what the Consumer wants to receive or (perhaps less > common) the Provider can send. > > seems overly restrictive. This need not occur during *call* initiation. > It is possible to initiate a call, but not enable clue until later. How > about: > > This Advertisement and Configure MUST occur once use of CLUE has > been enabled in a call, but MAY also happen at any time throughout > the call, whenever there is a change in what the Consumer wants to > receive or (perhaps less common) the Provider can send. [Duckworth, Mark] I agree > Figure 1 doesn't include the Global Capture Scene Entry List. [Duckworth, Mark] It is there in version -16 > Section 6 says: > > X increases from Camera-Left to Camera-Right > Y increases from front to back > > (Also see my comment on the definition of "Front".) > > Defining the coordinates relative to a camera is problematic since there = can > be multiple cameras. (Consider case where we have cameras facing the > audience and others facing speakers in front of the audience.) > > I'm not sure we can say anything better than that the X,Y coordinates sho= uld > be chosen to be sensible for the set of captures to be offered. > Perhaps an example where all the cameras point in generally the same > direction would get the point across. [Duckworth, Mark] We could clarify this. I'll try to propose something mor= e specific. > Section 7.1.1: > > Isn't mono/stereo now gone as a capture attribute? [Duckworth, Mark] Yes, I'll remove that. > Section 7.1.1.2: > > Perhaps we should say that the Point on Line of Capture actually defines = not > just the axis, but a vector indicating the direction of capture? [Duckworth, Mark] I agree > Section 7.1.1.3: > > I guess some restructuring is needed to limit area of capture to video. [Duckworth, Mark] Does area of capture apply only to video? Or can it appl= y to any media type other than audio? framework-16 simply says it does not= apply to audio. > Section 7.1.1.5: > > Didn't we agree to remove this. (That it will be handled as part of an > encoding.) [Duckworth, Mark] The "Audio Channel Format" section is removed in framewor= k-16. > Section 7.2.1.2: > > The explanation of 'index' is pretty fuzzy. ISTM that the meaning really = needs > to be specified separately for each token. E.g., for SoundLevel N means t= he > N'th most recent loudest speaker. For RoundRobin it is harder to describe= . [Duckworth, Mark] Makes sense for SoundLevel. Do we want to have an index = for RoundRobin? I suppose it could make sense there too. But I think the = current definition of the index is adequate. > Section 7.2.1.3: > > I have read this several times, and while I know this is about site switc= hing I > cannot figure it out from the words written here. Even the example isn't > helping me (and I don't think it should take an example to make it > understandable.) [Duckworth, Mark] I think there is a word missing: "To indicate that the Ca= pture Encodings associated with MCCs contain captures from the *same*source= at the same time..." It seems clear to me, so does anybody else have a su= ggestion for how to make this more clear? > For instance, ISTM that the synchronization id and the policy can give > conflicting criteria for what is included at each point in time. And also= the max > captures may define a composition policy that would violate the > synchronization. [Duckworth, Mark] I agree it is possible for a provider to do that in an ad= vertisement. I don't think we can prevent this syntactically in the data m= odel. I think it is okay to leave it this way. > Section 7.3: > > I have a question: Can a scene have captures that are not included in any > CSE? If not, then there probably ought to be something that says that. If= so, > then there are other issues. If so, then presumably it should be possible= to > have scenes with no CSEs. (Did we have this discussion previously?) [Duckworth, Mark] I thought we didn't want to have captures that were not i= n a CSE. But then maybe the addition of MCC concept would change that. An= MCC can include an individual capture from the same scene, and that indivi= dual capture might not have an encoding group, so then maybe in some cases = it wouldn't make sense to put that capture into a CSE? I'm not sure what p= roblems there would be if there are captures that are not in a CSE. What p= roblems do you see? > I suggest that the following: > > ... A Capture Scene includes one > or more Capture Scene entries, with each entry including one or > more Media Captures. ... > > be tweaked by: s/Media Captures/Media Captures of the same media type/ [Duckworth, Mark] I agree. > In the following: > > A provider MAY express spatial relationships between Captures that > are included in the same Capture Scene. However, there is not > necessarily the same spatial relationship between Media Captures > that are in different Capture Scenes. In other words, Capture > Scenes can use their own spatial measurement system as outlined > above in section 6. > > saying capture scenes *can* user their own spatial measurement system > suggests the contrary is a possibility - that they may share a spatial > measurement system. That isn't really true. We assume that each scene is > spatially unrelated to every other scene. So I suggest revising this as: > > A provider MAY express spatial relationships between Captures that > are included in the same Capture Scene. However, there is no > spatial relationship between Media Captures from > different Capture Scenes. In other words, Capture > Scenes each use their own spatial measurement system as outlined > above in section 6. [Duckworth, Mark] I agree. > While reading this section I find Capture Scene *Entry* to be a poor name= for > what it represents. ISTM that each CSE selects a set of captures that, > together, represent a view of the entire scene. (Some better than others.= ) I > think a better name for this would be *Scene View*. > > (I realize that while only a nomenclature change, this is a fundamental > element we use in talking to one another and so is mentally hard to chang= e. > But I think we at least ought to consider it as making clue more > understandable to outsiders. And of course we can consider other names.) > > Making such a change would of course result in renaming a number of other > things. I won't call those out specifically. [Duckworth, Mark] We can consider this. > Section 7.3.3: > > The following isn't quite right: > > ... Each item in this list is a set of one or more > Capture Scene Entries of the same media type. ... > > I can read this and think that CSEs are actually contained in this. It is= important > that what is included are *references* to CSEs defined in scenes. So I > suggest: > > ... Each item in this list is a set of references to one or more > of the Capture Scene Entries of the same media type that are > defined within scenes of the same advertisement. ... [Duckworth, Mark] I agree > And, in line with my comment about the naming of CSE, I think we can find= a > more understandable name for this thing than Global CSE List. > (IIRC the current name was my idea.) > > I'm thinking *Global View* would work as the name for one element of this > list. And then I guess the list of them would be *Global View List*. > > If we did all that, then 7.3.3 would start out as: > > 7.3.3. Global View List > > An advertisement can include an optional Global View List. > Each item in this list is a Global View. Each Global > View is a set of one or more references to Scene Views of the same > media type, defined within scenes of the same advertisement. > Each Global View is a suggestion from the Provider to the > Consumer for some Scene Views that provide a complete view of the > simultaneous captures provided by the provider, across the multiple > scenes of the advertisement. The Provider can include a Global > View List to help a consumer to choose sets of captures appropriate > to its capabilities or application. The choice of how to make these > suggestions in the Global View List, for what represents all > the scenes for which the provider can send media, is up to the > provider. This is very similar to how each Scene View represents a > particular scene. > > (But we would certainly add Global View to the definitions, and so part o= f the > above might appear there rather than here.) [Duckworth, Mark] I think we should consider these suggestions to improve t= he naming of these things. > Section 8: > > The following: > > ... If a > Capture Scene is included in a Simultaneous Transmission Set, then > all its Capture Scene Entries (of the corresponding media type) are > included in the Simultaneous Transmission Set. ... > > implies that there is some mechanism to determine the media type of the > simultaneous transmission set. Currently it is only determined by the typ= e of > its entries. But if all the entries are scenes, then that isn't good enou= gh. I can > think of a variety of fixes for this. We should discuss how to fix this. [Duckworth, Mark] I think this is an issue for the data model, not the fram= ework. > I find the following ambiguous or at least hard to understand: > > If an Advertisement does not include Simultaneous Transmission > Sets, then the Provider MUST be able to provide all Capture Scenes > simultaneously. If multiple capture Scene Entries are in a Capture > Scene then the Consumer chooses at most one Capture Scene Entry per > Capture Scene for each media type. Likewise, if there are no > Simultaneous Transmission Sets and there is a global CSE list, then > the Consumer chooses at most one set of CSEs of each media type, > from the global CSE list. > > It switches from what the provider MUST do (be able to provide all captur= e > scenes simultaneously), to what the consumer does, which doesn't seem to > be normative. [Duckworth, Mark] I agree we should reword it, to describe what the provide= r's advertisement means, without describing it as what the consumer does. > What is missing is a definition of what it means to be able to provide a > capture scene. I think "be able to provide a capture scene" means: be abl= e to > simultaneously provide all of the captures in any single CSE of the scene= . > > If that is right, then the question is how to write that as a clear norma= tive > statement. Either we can try to come up with text that says the above, or > else we could say that there is a default simultaneous transmission set a= nd > come up with an algorithm to derive it from the CSEs in the advertisement= . > (The algorithm is straightforward, but describing it in text is not.) Her= e is a cut > at the text: > > If an Advertisement does not include Simultaneous Transmission > Sets, then the Provider MUST be able to simultaneously provide > all the captures from any one CSE of each media type from each > capture scene. [Duckworth, Mark] This is an improvement for the beginning of the paragraph= . Then I think the rest of the paragraph should continue to describe what = the provider's advertisement means rather than describing what the consumer= does. > Section 9.3: > > I have some concerns with the first paragraph: > > Each Media Capture MAY be associated with at least one Encoding > Group, which is used to instantiate that Capture into one or more > Capture Encodings. Typically MCCs are assigned an Encoding Group > and thus become a Capture Encoding. The Captures (including other > MCCs) referenced by the MCC do not need to be assigned to an > Encoding Group. This means that all the Media Captures referenced > by the MCC will appear in the Capture Encoding according to any MCC > attributes. This allows an Advertiser to specify Capture attributes > associated with the Media Captures without the need to provide an > individual Capture Encoding for each of the inputs. > > The construction "MAY be associated with at least one" seems awkward, and > doesn't not the key point that if a capture is to be eligible for configu= ration it > MUST be associated with at least one. And then, "Typically MCCs are > assigned an Encoding Group and thus become a Capture Encoding" implies > that the assignment of the MCC to an encoding group > *causes* to become a Capture Encoding, which isn't right. I think the > following clarifies both of those points: > > Each Media Capture, including MCCs, MAY be associated with one or > more Encoding Groups. To be eligible for configuration, a Media > Capture MUST be associated with at least one Encoding Group, which > is used to instantiate that Capture into one or more Capture > Encodings. When an MCC is configured all the Media Captures > referenced by the MCC will appear in the Capture Encoding according > to the attributes of the chosen encoding of the MCC. This allows an > Advertiser to specify encoding attributes associated with the Media > Captures without the need to provide an individual Capture Encoding > for each of the inputs. [Duckworth, Mark] That is a good improvement. > Section 10: > > Some of the text in this section is out of date with changes we have made > along the way. This is most obvious in: > > For each Capture the Consumer wants to receive, it configures one > or more of the encodings in that capture's encoding group. The > Consumer does this by telling the Provider, in its Configure > Message, parameters such as the resolution, frame rate, bandwidth, > etc. for each Capture Encodings for its chosen Captures. ... > > This suggests that resolution, frame rate, bandwidth, etc. are specified = as > part of the Configure, which is no longer true. > > (I have been getting a similar feeling in earlier sections, but in each c= ase I > could read it as ok, because "parameters" could mean other things.) > > For the moment I'm not going to suggest a specific fix. It could be fixed > "here" with some minor rewording. But if we want to fix it document wide > then that should be done in a unified way. [Duckworth, Mark] This is fixed in version -16. I tried to fix it in all p= laces in the document. Please let me know if you find any more problems li= ke this. > And related to that is: > > In order to meaningfully create and send an initial Configure, the > Consumer needs to have received at least one Advertisement from the > Provider. > > It is now also necessary to have received an offer defining encodings of = the > captures of interest to the consumer. I think some rewording is required. [Duckworth, Mark] I agree. > Section 12.1.1: > > Area of Capture needs to come out for the audio captures, replaced by poi= nt > of capture and point on line of capture. [Duckworth, Mark] Done in version -16. > More important, based on our audio discussions, does it make sense to > provide separate audio captures for each camera? If not, what does make > sense? Perhaps just a single mono audio, a single surround sound audio, a= nd > an audio for the presentation? [Duckworth, Mark] I don't know what you mean. The example already has thre= e separate captures (AC0, AC1, AC2) corresponding to the three cameras. Pl= us AC3 for the whole room. Plus AC4 to go with the presentation video. > There is a reference to MCC5, which is not defined. [Duckworth, Mark] It should be VC5. > Section 12.2: > > This says: > > A sane, basic, algorithm might be for the consumer to go through > each Capture Scene in turn and find the collection of Video > Captures that best matches the number of screens it has ... > > But this doesn't say anything about CSEs - implying that ignoring them is > sensible. It is *possible*, but explaining how to decide in that case is = very > complex. I would think for the purposes here we would want to recommend > going through the CSEs looking for one that best exploits the locally ava= ilable > equipment. > > Did the above mean to say "... go through each CSE in turn ..."? [Duckworth, Mark] Yes, that makes more sense. > Section 12.3.1: > > Table 14 doesn't leave the consumer with much choice. For instance there = is > no choice that works for a consumer that can handle only one video stream= . > > ISTM that it would be better to merge tables 13 and 14, so that the consu= mer > can have both one-encoding and two-encoding options. [Duckworth, Mark] I think either way is just as good for the purpose of the= example, which is to illustrate basic usage of MCCs. > Section 12.3.3: > > The following appears after Table 20: > > Rather than considering what is displayed the CLUE concentrates > more on what the MCU sends. The MCU doesn't know anything about > the number of screens an endpoint has. > > Something is wrong with this - "the CLUE" makes no sense. Should "the" > be omitted, or was "this example" intended? [Duckworth, Mark] "the" should be omitted. > I also see a reference to section 7.3.2 that isn't linked (in the html) t= o the > actual section. Perhaps it is by value rather than reference in the sourc= e??? [Duckworth, Mark] Yes, I think there are multiple instances of using text v= alues rather than actual references in the source. I have to fix those. R= ight now our source is Microsoft Word format. I have to decide whether to = keep it in Word, or port it back to XML. Are there any good reasons to por= t it back to XML? > Section 15: > > There is a reference to "section x", that needs to be updated to referenc= e to > proper section. [Duckworth, Mark] Yes. > THE END > > Thanks, > Paul From nobody Wed Jul 16 14:37:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C2E1A0319 for ; Wed, 16 Jul 2014 14:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cF-J1-lABVTs for ; Wed, 16 Jul 2014 14:37:56 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.110]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C99E61A0085 for ; Wed, 16 Jul 2014 14:37:56 -0700 (PDT) Received: from [216.82.254.19:27717] by server-14.bemta-7.messagelabs.com id 56/4D-11449-3B0F6C35; Wed, 16 Jul 2014 21:37:55 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-13.tower-96.messagelabs.com!1405546673!13970404!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 8553 invoked from network); 16 Jul 2014 21:37:55 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-13.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jul 2014 21:37:55 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Wed, 16 Jul 2014 14:36:59 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Wed, 16 Jul 2014 14:36:58 -0700 Thread-Topic: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt Thread-Index: Ac+UDfQX2Yqwiaj4TDyDHs6t9geibQNL3E2A Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B2B@CRPMBOXPRD08.polycom.com> References: <539FE86F.7000902@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F078AD19EF4@CRPMBOXPRD08.polycom.com> <53B0D040.30800@nteczone.com> In-Reply-To: <53B0D040.30800@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/28adQvS7KQ7dUcDxB39-v9PIWbY Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:37:58 -0000 Christian, Thanks for the suggestions. Comments below. Mark ... snip... > >> Cl.3 General: Do we need a term to describe when multiple Capture > >> Scenes are used to give an overall "picture" of the endpoint, i.e. GCS= E? > > [Duckworth, Mark] I don't think we need a new term in section 3. > [CNG] I see Paul has a comment about GCSEs. [Duckworth, Mark] Yes, let's continue the discussion based on Paul's commen= ts. ..snip > >> Cl.7.3 para.6 & 7: Earlier in the draft it says that there is no > >> spatial relationship between scenes. However this paragraph is a littl= e > "fuzzy" > >> implying there may be relationship between scenes. Whilst physically > >> there may a relationship a consumer has no way of knowing this. The > >> default behaviour will not be to associate scenes. > > [Duckworth, Mark] I don't see anything that implies a relationship betw= een > scenes. Which sentences specifically do you mean? > [CNG] The sentence I'm referring to is "However, there is not necessarily= the > same spatial relationship between Media Captures that are in different > Capture Scenes." "Not necessarily" to me means there may or may not be a > spatial relationship between capture in different scenes. [Duckworth, Mark] Paul had a good suggestion to improve this. ..snip > >> Cl.9.2: There is no explicit mention of whether individual encodings > >> of multiple media types i.e. audio and video can belong to a single gr= oup. > > [Duckworth, Mark] The data model restricts an encoding group to a > particular media type. > [CNG] Yes but you shouldn't have to look at the data model to find this o= ut. I > think the inclusion of a sentence to the effect that encoding groups are > limited to a single media type would be beneficial. [Duckworth, Mark] See separate email dedicated to this issue. > >> Cl.10 para.2: I don't see the "special" handling outlined in this > >> paragraph. A consumer would have a separate CLUE channel with each > >> provider and treat the associations differently? > > [Duckworth, Mark] I don't understand your point. Do you think this > paragraph is unnecessary? > [CNG] Yes, it doesn't seem to add alot. An endpoint or an MCU need to > respond with a Configure based on the Advertisement and the MC > capabilities. [Duckworth, Mark] Okay with me to remove this paragraph, the one that start= s with "If multiple Providers connect to the same Consumer..." Does anybod= y else think removing this is a good idea? From nobody Wed Jul 16 14:44:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E1051A0319 for ; Wed, 16 Jul 2014 14:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck-UU2QKM-pG for ; Wed, 16 Jul 2014 14:44:56 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3541B1A008C for ; Wed, 16 Jul 2014 14:44:56 -0700 (PDT) Received: from [216.82.249.212:57769] by server-12.bemta-12.messagelabs.com id D5/38-09309-752F6C35; Wed, 16 Jul 2014 21:44:55 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-3.tower-219.messagelabs.com!1405547094!18445969!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30751 invoked from network); 16 Jul 2014 21:44:55 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-3.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jul 2014 21:44:55 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 16 Jul 2014 14:44:54 -0700 From: "Duckworth, Mark" To: Paul Kyzivat , "clue@ietf.org" Date: Wed, 16 Jul 2014 14:44:53 -0700 Thread-Topic: Encoding Group with multiple media types Thread-Index: Ac+hPkp9OiBHbU5ESvCxMudIDFcTrw== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B32@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/cLst19aN8j-1sOlfCXn0y4yv7Ok Subject: [clue] Encoding Group with multiple media types X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 21:44:58 -0000 I vaguely recall discussing this at some IETF meeting. I think the group d= ecided we should allow an encoding group to include individual encodings fo= r multiple media types. So I think I should make that clear in the text in= section 9.2, keep the example in 12.1.2 as it is, and we should update the= data model syntax to allow it. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Sunday, June 29, 2014 11:48 PM > To: clue@ietf.org > Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt >=20 > On 6/29/14 10:49 PM, Christian Groves wrote: >=20 > >>> Cl.9.2: There is no explicit mention of whether individual encodings > >>> of multiple media types i.e. audio and video can belong to a single g= roup. > >> [Duckworth, Mark] The data model restricts an encoding group to a > >> particular media type. >=20 > Section 12.1.2 shows an encoding group that has both audio and video > encodings, and discusses this as an alternative to having separate encodi= ng > groups. It is clearly saying this is intended. >=20 > > [CNG] Yes but you shouldn't have to look at the data model to find > > this out. I think the inclusion of a sentence to the effect that > > encoding groups are limited to a single media type would be beneficial. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Wed Jul 16 15:02:38 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7242F1A0354 for ; Wed, 16 Jul 2014 15:02:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4AnwA2vtC2w for ; Wed, 16 Jul 2014 15:02:34 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 167D41A032A for ; Wed, 16 Jul 2014 15:02:33 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s6GM2UIM012887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Jul 2014 17:02:31 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s6GM2TMU017917 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 17 Jul 2014 00:02:29 +0200 Received: from FR712WXCHMBA11.zeu.alcatel-lucent.com ([169.254.7.71]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Thu, 17 Jul 2014 00:02:29 +0200 From: "DRAGE, Keith (Keith)" To: "Duckworth, Mark" , Paul Kyzivat , "clue@ietf.org" Thread-Topic: [clue] framework references to other documents - normative or informative? Thread-Index: AQHPoRzbFOBCxJXylUCvpy6YO2LT6Jui270AgABfdlA= Date: Wed, 16 Jul 2014 22:02:28 +0000 Message-ID: <949EF20990823C4C85C18D59AA11AD8B207464@FR712WXCHMBA11.zeu.alcatel-lucent.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> <53C6B895.5020007@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/mlaKtACMPWzNik7KUbk1qCQyiCI Subject: Re: [clue] framework references to other documents - normative or informative? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:02:36 -0000 I strongly recommend keeping any referencing to the minimum you need - this= is not an academic paper for which you get kudos for the length of the ref= erence list. So normative references - those where you actually need the text from the r= eferenced document to implement the text in your document with RFC 2119 lan= guage. Follow the rules in RFC 3967. [Remember that if you ever get to iden= tifying any conformant implementations, e.g. for standards track, the norma= tive references need to be assessed as much as any RFC 2119 language in you= document.] So treat the assessment of the need any normative references in= the same way as you would consider the need for writing a MUST, a SHOULD = or a MAY. Informative references. Concentrate on those you really need to give unders= tanding of any key concepts, or explain any terminology. Leave the problem of an overview document to someone else. Keith > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > Sent: 16 July 2014 19:00 > To: Paul Kyzivat; clue@ietf.org > Subject: Re: [clue] framework references to other documents -=20 > normative or informative? >=20 > Thanks, I'll look at RFC3967. >=20 > > But perhaps a case can be made that an overview might be written to=20 > > help the reader understand the document set, and that would include=20 > > references to all the documents. >=20 > Yes, that's what I meant. Do you think the framework should=20 > include such an overview? >=20 > Mark >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Wednesday, July 16, 2014 1:38 PM > > To: clue@ietf.org > > Subject: Re: [clue] framework references to other documents -=20 > > normative or informative? > >=20 > > On 7/16/14 1:20 PM, Duckworth, Mark wrote: > > > draft-ietf-clue-framework-16 has a section for "Informative=20 > > > References", with a note reminding us to check if any of these=20 > > > should be > > normative. > > > By what criteria do we decide if a reference is informative or=20 > > > normative? Can anybody suggest how these should be categorized? > >=20 > > See RFC3967 > >=20 > > > And it seems to me we should add references to the other CLUE=20 > > > documents like data model, protocol, signaling, and I would think=20 > > > those would be normative, is that right? > >=20 > > If the references aren't required to read the framework document=20 > > itself then there is no need to include the reference. In=20 > fact IdNits=20 > > will complain if you include references that aren't used at=20 > all in the doc. > >=20 > > The complete set of normative references can be obtained by=20 > recursion. > >=20 > > But perhaps a case can be made that an overview might be written to=20 > > help the reader understand the document set, and that would include=20 > > references to all the documents. > >=20 > > Thanks, > > Paul > >=20 > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > = From nobody Wed Jul 16 15:12:04 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 202061A035E for ; Wed, 16 Jul 2014 15:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DUosu7pHlcrk for ; Wed, 16 Jul 2014 15:12:01 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.104]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87A991A035A for ; Wed, 16 Jul 2014 15:12:01 -0700 (PDT) Received: from [216.82.254.19:53316] by server-8.bemta-7.messagelabs.com id 47/1E-03912-0B8F6C35; Wed, 16 Jul 2014 22:12:00 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-96.messagelabs.com!1405548719!20321437!1 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 2476 invoked from network); 16 Jul 2014 22:12:00 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-10.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 16 Jul 2014 22:12:00 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Wed, 16 Jul 2014 15:11:59 -0700 From: "Duckworth, Mark" To: "DRAGE, Keith (Keith)" Date: Wed, 16 Jul 2014 15:11:58 -0700 Thread-Topic: [clue] framework references to other documents - normative or informative? Thread-Index: AQHPoRzbFOBCxJXylUCvpy6YO2LT6Jui270AgABfdlCAAAhaUA== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B3C@CRPMBOXPRD08.polycom.com> References: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6A9B@CRPMBOXPRD08.polycom.com> <53C6B895.5020007@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6AB0@CRPMBOXPRD08.polycom.com> <949EF20990823C4C85C18D59AA11AD8B207464@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8B207464@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/yZna7P3eqNNmXjbvGjczNpnGiOQ Cc: "clue@ietf.org" Subject: Re: [clue] framework references to other documents - normative or informative? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 22:12:03 -0000 Thanks Keith, that sounds like good advice! Mark > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Wednesday, July 16, 2014 6:02 PM > To: Duckworth, Mark; Paul Kyzivat; clue@ietf.org > Subject: RE: [clue] framework references to other documents - normative o= r > informative? >=20 > I strongly recommend keeping any referencing to the minimum you need - > this is not an academic paper for which you get kudos for the length of t= he > reference list. >=20 > So normative references - those where you actually need the text from the > referenced document to implement the text in your document with RFC > 2119 language. Follow the rules in RFC 3967. [Remember that if you ever g= et > to identifying any conformant implementations, e.g. for standards track, = the > normative references need to be assessed as much as any RFC 2119 language > in you document.] So treat the assessment of the need any normative > references in the same way as you would consider the need for writing a > MUST, a SHOULD or a MAY. >=20 > Informative references. Concentrate on those you really need to give > understanding of any key concepts, or explain any terminology. >=20 > Leave the problem of an overview document to someone else. >=20 > Keith >=20 > > -----Original Message----- > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark > > Sent: 16 July 2014 19:00 > > To: Paul Kyzivat; clue@ietf.org > > Subject: Re: [clue] framework references to other documents - > > normative or informative? > > > > Thanks, I'll look at RFC3967. > > > > > But perhaps a case can be made that an overview might be written to > > > help the reader understand the document set, and that would include > > > references to all the documents. > > > > Yes, that's what I meant. Do you think the framework should include > > such an overview? > > > > Mark > > > > > -----Original Message----- > > > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat > > > Sent: Wednesday, July 16, 2014 1:38 PM > > > To: clue@ietf.org > > > Subject: Re: [clue] framework references to other documents - > > > normative or informative? > > > > > > On 7/16/14 1:20 PM, Duckworth, Mark wrote: > > > > draft-ietf-clue-framework-16 has a section for "Informative > > > > References", with a note reminding us to check if any of these > > > > should be > > > normative. > > > > By what criteria do we decide if a reference is informative or > > > > normative? Can anybody suggest how these should be categorized? > > > > > > See RFC3967 > > > > > > > And it seems to me we should add references to the other CLUE > > > > documents like data model, protocol, signaling, and I would think > > > > those would be normative, is that right? > > > > > > If the references aren't required to read the framework document > > > itself then there is no need to include the reference. In > > fact IdNits > > > will complain if you include references that aren't used at > > all in the doc. > > > > > > The complete set of normative references can be obtained by > > recursion. > > > > > > But perhaps a case can be made that an overview might be written to > > > help the reader understand the document set, and that would include > > > references to all the documents. > > > > > > Thanks, > > > Paul > > > > > > _______________________________________________ > > > clue mailing list > > > clue@ietf.org > > > https://www.ietf.org/mailman/listinfo/clue > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > From nobody Wed Jul 16 16:39:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53D4A1A039B for ; Wed, 16 Jul 2014 16:39:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvP9RhcM6o5G for ; Wed, 16 Jul 2014 16:39:30 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 6C50C1A039A for ; Wed, 16 Jul 2014 16:39:29 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by QMTA11.westchester.pa.mail.comcast.net with comcast id TBVq1o0030ldTLk5BBfV71; Wed, 16 Jul 2014 23:39:29 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id TBfV1o0093ZTu2S01BfVo4; Wed, 16 Jul 2014 23:39:29 +0000 Message-ID: <53C70D31.5040900@alum.mit.edu> Date: Wed, 16 Jul 2014 19:39:29 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <53B0ADDC.5060706@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405553969; bh=k0fm3FQ4VB3TPBrQiammIcgZtiUIo/UhykLhYCrju5A=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=f22+mR++dH86x1YyQeNl9d7fWM+R658kRpVi3H5Evqo9bjTouvr3JlORmalwCQuOE 8eGyhq2oAYjK74uqu6//kbpyMI05BdioN9cPiurHHNwjzTKMAFNzp7cTWcEHfYYoDT 8h2BLopuB2KNiz2dBFH+E4H4cuh5JNKAFSVrBs/Yi0A6MI+o0Kgy3pPoepySfprHQE sUzac9qEmZlhwdNUpGUT7yeB0T4/ruJNfwZMDc+zIVHhAeY7p8NLOSdUk9QObZyDWC 7S/B2g4XZXeZatdH0IJi8kdlxd0Rtv5BS240SFlK9nRtsdH8mgsZpkpTxnGA4V+ETx 4KM8NhZryOHMg== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/QxMZHXV_Q0NOJwZuoWPZmHsFZ8I Subject: [clue] Framework - normative references to taxonomy ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Jul 2014 23:39:34 -0000 I'll reply more fully later. But I want to start discussion on one thing: You ask how we make a normative document like this depend on definitions in an informative document - the taxonomy. I don't know the answer to this. I'm interested to hear if somebody feels qualified to give a definitive answer. But my common sense answer to this is: ISTM that a document that only contains definitions can never be normative. But I think it is still ok for another document to make normative references to it. What do others think? Who can we ask for an authoritative answer? Thanks, Paul On 7/16/14 5:25 PM, Duckworth, Mark wrote: > Hi Paul, > Thanks for all the comments. Responses inline. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Sunday, June 29, 2014 8:23 PM >> To: clue@ietf.org >> Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt >> >> I apologize for being late with my own pre-WGLC review comments on this. >> I ended up spending a lot more time on it than I allotted. (And I >> procrastinated.) Also, I know there are some overlaps between my >> comments and Christians. I've left them in because it is easier than removing >> them and I may have some different nuances. >> >> And here I am speaking as an individual, not a chair. >> >> References: >> >> There is no separate section for References. They are found at the end of >> the "Changes since last version" section. I assume this is a bug. > [Duckworth, Mark] I think you mean it should be section number 17? I'll fix that. It's been that way for a long time, not sure why. > >> Section 1: >> >> In the following: >> >> The signaling details and data model are provided >> in subsequent documents. >> >> ISTM that the documents aren't "subsequent", in that there is no natural >> ordering relationship among them. I suggest "separate" (or "companion") >> documents. E.g., > [Duckworth, Mark] I agree > >> Companion documents describe signaling details [reference] and >> the data model. [reference] >> (These documents aren't currently in the references.) > [Duckworth, Mark] I agree we should add those to the references. Should we itemize all the "companion documents" here, with very brief description of them? > >> Section 3: >> >> Re Capture Device: >> >> Capture Device: A device that converts audio and video input into >> an electrical signal, in most cases to be fed into a media encoder. >> >> This definition only applies to audio and video. (E.g., it excludes real-time >> text.) The grouping taxonomy defines it as: >> a physical entity performing a Media Capture transformation. > [Duckworth, Mark] How about changing the definition to: "A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder " > This should cover cameras, microphones, keyboards... > >> Re Capture Encoding: >> >> Can we relate this directly to the grouping taxonomy? The taxonomy already >> does so, saying it is >> >> a term to describe an Encoded Stream >> >> I'm not certain this is quite right - I think the description is of more than the >> Encoded stream - maybe a "Source RTP Stream". Whatever we decide, we >> should ensure that the fw and the taxonomy are updated to be consistent. > [Duckworth, Mark] Previous discussion led to Bo updating the taxonomy to say "Telepresence specifications from CLUE WG uses this term to describe an Encoded Stream (Section 2.1.7) related to CLUE specific semantic information." Do you think we need further clarification? Is this an issue for the taxonomy document? > > [Duckworth, Mark] The definitions in CLUE framework are supposed to be normative, so we can't define them in terms of the Informational taxonomy document, can we? > >> Re Endpoint: I think we could align better with the taxonomy. (We are pretty >> close.) > [Duckworth, Mark] I think it's not close, it's a different concept. My understanding is that A CLUE endpoint can have multiple taxonomy end points. An MCU is not a CLUE endpoint, but an MCU includes taxonomy end points. What do you suggest we change? > >> Re Front: >> >> Front: the portion of the room closest to the cameras. In going >> towards back you move away from the cameras. >> >> Do we need this? It is only referenced once, in the definition of spatial >> relationships. >> >> Also, unless all the cameras are placed on the same side of the room it is not >> unique. (There is a separate Front for each camera.) > [Duckworth, Mark] I think we need the definition, but maybe just in the spatial relation section and not explicitly in the definitions section, is that what you mean? I understand your point about cameras in different locations. I think each Capture Scene must have a unique Front direction, because it is supposed to have a single coordinate system for everything in the scene, even if cameras are in different places. Should we try to clarify this in the document? > >> Re MCU: >> >> The taxonomy now has what seems to be a good definition of MCU. Can we >> refer to that one? We may have to specialize the definition for our purposes >> - requiring that it support CLUE. (That might mean we need to have a >> different name, such as CLUE MCU.) > [Duckworth, Mark] The taxonomy does have a good description of MCU, describing how current common usage of the term MCU maps to other terms defined in taxonomy. I agree this is consistent with CLUE's usage of MCU. Maybe we should update the CLUE definition to be more like the taxonomy definition? Or help me understand how a reference to the Informational taxonomy doc could work. > >> Re Media Capture: >> >> Our definition differs from the taxonomy in a significant way. Ours describes >> it as a form of "data" while the taxonomy describes it as a process. I'm not >> quite sure what to recommend for aligning these. I suspect one or the other >> needs to be renamed. > [Duckworth, Mark] I think it is good the way it is. CLUE definition is "a source of Media, such as from one or more Capture Devices or constructed from other Media streams". I think the source of media can be from a process (or transformation, as the taxonomy calls it). Taxonomy says : "Telepresence specifications from CLUE WG uses this term to describe either a Media Capture (Section 2.1.2) or a Media Source (Section 2.1.4), depending on in which context the term is used." I think this is accurate. > >> Re Media Consumer: >> >> Media Consumer: an Endpoint or middle box that receives Media >> streams >> >> I think "Media Streams" is too general here. I suggest: >> >> Media Consumer: an Endpoint or middle box that is capable of >> receiving Media Encodings. > [Duckworth, Mark] Do you mean "... capable of receiving Capture Encodings"? I would agree with that. > >> Re Media Provider: >> >> Similar to above I suggest: >> >> Media Provider: an Endpoint or middle box that is capable of >> sending Media Encodings. > [Duckworth, Mark] I would agree with "... capable of sending Capture Encodings" > >> Re Multiple Content Capture: >> >> This is limited to audio and video. Couldn't we potentially have an MCC for >> switched or mixed real-time text? How about: >> >> Multiple Content Capture: A Capture that mixes and/or switches >> other Captures of a single type. (E.g. all audio or all video.) >> Particular Media Captures may or may not be present in the >> resultant Capture Encoding depending on time or space. Denoted as >> MCCn in the example cases in this document. > [Duckworth, Mark] I agree. > >> Instead of just mentioning that MCCn may be used in examples, shouldn't >> we actually define MCC as an abbreviation? > [Duckworth, Mark] I agree. How about just using "Multiple Content Capture (MCC): A Capture that mixes...", which is how we do it for defining CSE. > >> Re Stream: >> >> Can we relate this to the taxonomy? I think this corresponds to both a >> "Source RTP Stream" and a "Received RTP Stream". > [Duckworth, Mark] I agree. Can we keep our current definition, and add an informative reference to the taxonomy about this? > >> Re Middlebox: >> >> This term isn't defined but it is used. I think it deserves a definition. > [Duckworth, Mark] I agree, but I don't have a good suggestion for a definition :( Is it more general than an MCU? Is a device that has user agents for signaling, but no media handling, considered a middle box? > >> Section 4: >> >> The following: >> >> ... In a few circumstances, a CLUE Endpoint middlebox >> includes only Consumer or Provider functionality, such as >> recorder-type Consumers or webcam-type Providers. ... >> >> I *think* this should say "Endpoint *or* middlebox". > [Duckworth, Mark] I agree. > >> Section 5: >> >> The following: >> >> This Advertisement and Configure MUST occur during call initiation >> but MAY also happen at any time throughout the call, whenever there >> is a change in what the Consumer wants to receive or (perhaps less >> common) the Provider can send. >> >> seems overly restrictive. This need not occur during *call* initiation. >> It is possible to initiate a call, but not enable clue until later. How >> about: >> >> This Advertisement and Configure MUST occur once use of CLUE has >> been enabled in a call, but MAY also happen at any time throughout >> the call, whenever there is a change in what the Consumer wants to >> receive or (perhaps less common) the Provider can send. > [Duckworth, Mark] I agree > >> Figure 1 doesn't include the Global Capture Scene Entry List. > [Duckworth, Mark] It is there in version -16 > >> Section 6 says: >> >> X increases from Camera-Left to Camera-Right >> Y increases from front to back >> >> (Also see my comment on the definition of "Front".) >> >> Defining the coordinates relative to a camera is problematic since there can >> be multiple cameras. (Consider case where we have cameras facing the >> audience and others facing speakers in front of the audience.) >> >> I'm not sure we can say anything better than that the X,Y coordinates should >> be chosen to be sensible for the set of captures to be offered. >> Perhaps an example where all the cameras point in generally the same >> direction would get the point across. > [Duckworth, Mark] We could clarify this. I'll try to propose something more specific. > >> Section 7.1.1: >> >> Isn't mono/stereo now gone as a capture attribute? > [Duckworth, Mark] Yes, I'll remove that. > >> Section 7.1.1.2: >> >> Perhaps we should say that the Point on Line of Capture actually defines not >> just the axis, but a vector indicating the direction of capture? > [Duckworth, Mark] I agree > >> Section 7.1.1.3: >> >> I guess some restructuring is needed to limit area of capture to video. > [Duckworth, Mark] Does area of capture apply only to video? Or can it apply to any media type other than audio? framework-16 simply says it does not apply to audio. > >> Section 7.1.1.5: >> >> Didn't we agree to remove this. (That it will be handled as part of an >> encoding.) > [Duckworth, Mark] The "Audio Channel Format" section is removed in framework-16. > >> Section 7.2.1.2: >> >> The explanation of 'index' is pretty fuzzy. ISTM that the meaning really needs >> to be specified separately for each token. E.g., for SoundLevel N means the >> N'th most recent loudest speaker. For RoundRobin it is harder to describe. > [Duckworth, Mark] Makes sense for SoundLevel. Do we want to have an index for RoundRobin? I suppose it could make sense there too. But I think the current definition of the index is adequate. > >> Section 7.2.1.3: >> >> I have read this several times, and while I know this is about site switching I >> cannot figure it out from the words written here. Even the example isn't >> helping me (and I don't think it should take an example to make it >> understandable.) > [Duckworth, Mark] I think there is a word missing: "To indicate that the Capture Encodings associated with MCCs contain captures from the *same*source at the same time..." It seems clear to me, so does anybody else have a suggestion for how to make this more clear? > >> For instance, ISTM that the synchronization id and the policy can give >> conflicting criteria for what is included at each point in time. And also the max >> captures may define a composition policy that would violate the >> synchronization. > [Duckworth, Mark] I agree it is possible for a provider to do that in an advertisement. I don't think we can prevent this syntactically in the data model. I think it is okay to leave it this way. > >> Section 7.3: >> >> I have a question: Can a scene have captures that are not included in any >> CSE? If not, then there probably ought to be something that says that. If so, >> then there are other issues. If so, then presumably it should be possible to >> have scenes with no CSEs. (Did we have this discussion previously?) > [Duckworth, Mark] I thought we didn't want to have captures that were not in a CSE. But then maybe the addition of MCC concept would change that. An MCC can include an individual capture from the same scene, and that individual capture might not have an encoding group, so then maybe in some cases it wouldn't make sense to put that capture into a CSE? I'm not sure what problems there would be if there are captures that are not in a CSE. What problems do you see? > >> I suggest that the following: >> >> ... A Capture Scene includes one >> or more Capture Scene entries, with each entry including one or >> more Media Captures. ... >> >> be tweaked by: s/Media Captures/Media Captures of the same media type/ > [Duckworth, Mark] I agree. > >> In the following: >> >> A provider MAY express spatial relationships between Captures that >> are included in the same Capture Scene. However, there is not >> necessarily the same spatial relationship between Media Captures >> that are in different Capture Scenes. In other words, Capture >> Scenes can use their own spatial measurement system as outlined >> above in section 6. >> >> saying capture scenes *can* user their own spatial measurement system >> suggests the contrary is a possibility - that they may share a spatial >> measurement system. That isn't really true. We assume that each scene is >> spatially unrelated to every other scene. So I suggest revising this as: >> >> A provider MAY express spatial relationships between Captures that >> are included in the same Capture Scene. However, there is no >> spatial relationship between Media Captures from >> different Capture Scenes. In other words, Capture >> Scenes each use their own spatial measurement system as outlined >> above in section 6. > [Duckworth, Mark] I agree. > >> While reading this section I find Capture Scene *Entry* to be a poor name for >> what it represents. ISTM that each CSE selects a set of captures that, >> together, represent a view of the entire scene. (Some better than others.) I >> think a better name for this would be *Scene View*. >> >> (I realize that while only a nomenclature change, this is a fundamental >> element we use in talking to one another and so is mentally hard to change. >> But I think we at least ought to consider it as making clue more >> understandable to outsiders. And of course we can consider other names.) >> >> Making such a change would of course result in renaming a number of other >> things. I won't call those out specifically. > [Duckworth, Mark] We can consider this. > >> Section 7.3.3: >> >> The following isn't quite right: >> >> ... Each item in this list is a set of one or more >> Capture Scene Entries of the same media type. ... >> >> I can read this and think that CSEs are actually contained in this. It is important >> that what is included are *references* to CSEs defined in scenes. So I >> suggest: >> >> ... Each item in this list is a set of references to one or more >> of the Capture Scene Entries of the same media type that are >> defined within scenes of the same advertisement. ... > [Duckworth, Mark] I agree > >> And, in line with my comment about the naming of CSE, I think we can find a >> more understandable name for this thing than Global CSE List. >> (IIRC the current name was my idea.) >> >> I'm thinking *Global View* would work as the name for one element of this >> list. And then I guess the list of them would be *Global View List*. >> >> If we did all that, then 7.3.3 would start out as: >> >> 7.3.3. Global View List >> >> An advertisement can include an optional Global View List. >> Each item in this list is a Global View. Each Global >> View is a set of one or more references to Scene Views of the same >> media type, defined within scenes of the same advertisement. >> Each Global View is a suggestion from the Provider to the >> Consumer for some Scene Views that provide a complete view of the >> simultaneous captures provided by the provider, across the multiple >> scenes of the advertisement. The Provider can include a Global >> View List to help a consumer to choose sets of captures appropriate >> to its capabilities or application. The choice of how to make these >> suggestions in the Global View List, for what represents all >> the scenes for which the provider can send media, is up to the >> provider. This is very similar to how each Scene View represents a >> particular scene. >> >> (But we would certainly add Global View to the definitions, and so part of the >> above might appear there rather than here.) > [Duckworth, Mark] I think we should consider these suggestions to improve the naming of these things. > >> Section 8: >> >> The following: >> >> ... If a >> Capture Scene is included in a Simultaneous Transmission Set, then >> all its Capture Scene Entries (of the corresponding media type) are >> included in the Simultaneous Transmission Set. ... >> >> implies that there is some mechanism to determine the media type of the >> simultaneous transmission set. Currently it is only determined by the type of >> its entries. But if all the entries are scenes, then that isn't good enough. I can >> think of a variety of fixes for this. We should discuss how to fix this. > [Duckworth, Mark] I think this is an issue for the data model, not the framework. > >> I find the following ambiguous or at least hard to understand: >> >> If an Advertisement does not include Simultaneous Transmission >> Sets, then the Provider MUST be able to provide all Capture Scenes >> simultaneously. If multiple capture Scene Entries are in a Capture >> Scene then the Consumer chooses at most one Capture Scene Entry per >> Capture Scene for each media type. Likewise, if there are no >> Simultaneous Transmission Sets and there is a global CSE list, then >> the Consumer chooses at most one set of CSEs of each media type, >> from the global CSE list. >> >> It switches from what the provider MUST do (be able to provide all capture >> scenes simultaneously), to what the consumer does, which doesn't seem to >> be normative. > [Duckworth, Mark] I agree we should reword it, to describe what the provider's advertisement means, without describing it as what the consumer does. > >> What is missing is a definition of what it means to be able to provide a >> capture scene. I think "be able to provide a capture scene" means: be able to >> simultaneously provide all of the captures in any single CSE of the scene. >> >> If that is right, then the question is how to write that as a clear normative >> statement. Either we can try to come up with text that says the above, or >> else we could say that there is a default simultaneous transmission set and >> come up with an algorithm to derive it from the CSEs in the advertisement. >> (The algorithm is straightforward, but describing it in text is not.) Here is a cut >> at the text: >> >> If an Advertisement does not include Simultaneous Transmission >> Sets, then the Provider MUST be able to simultaneously provide >> all the captures from any one CSE of each media type from each >> capture scene. > [Duckworth, Mark] This is an improvement for the beginning of the paragraph. Then I think the rest of the paragraph should continue to describe what the provider's advertisement means rather than describing what the consumer does. > >> Section 9.3: >> >> I have some concerns with the first paragraph: >> >> Each Media Capture MAY be associated with at least one Encoding >> Group, which is used to instantiate that Capture into one or more >> Capture Encodings. Typically MCCs are assigned an Encoding Group >> and thus become a Capture Encoding. The Captures (including other >> MCCs) referenced by the MCC do not need to be assigned to an >> Encoding Group. This means that all the Media Captures referenced >> by the MCC will appear in the Capture Encoding according to any MCC >> attributes. This allows an Advertiser to specify Capture attributes >> associated with the Media Captures without the need to provide an >> individual Capture Encoding for each of the inputs. >> >> The construction "MAY be associated with at least one" seems awkward, and >> doesn't not the key point that if a capture is to be eligible for configuration it >> MUST be associated with at least one. And then, "Typically MCCs are >> assigned an Encoding Group and thus become a Capture Encoding" implies >> that the assignment of the MCC to an encoding group >> *causes* to become a Capture Encoding, which isn't right. I think the >> following clarifies both of those points: >> >> Each Media Capture, including MCCs, MAY be associated with one or >> more Encoding Groups. To be eligible for configuration, a Media >> Capture MUST be associated with at least one Encoding Group, which >> is used to instantiate that Capture into one or more Capture >> Encodings. When an MCC is configured all the Media Captures >> referenced by the MCC will appear in the Capture Encoding according >> to the attributes of the chosen encoding of the MCC. This allows an >> Advertiser to specify encoding attributes associated with the Media >> Captures without the need to provide an individual Capture Encoding >> for each of the inputs. > [Duckworth, Mark] That is a good improvement. > >> Section 10: >> >> Some of the text in this section is out of date with changes we have made >> along the way. This is most obvious in: >> >> For each Capture the Consumer wants to receive, it configures one >> or more of the encodings in that capture's encoding group. The >> Consumer does this by telling the Provider, in its Configure >> Message, parameters such as the resolution, frame rate, bandwidth, >> etc. for each Capture Encodings for its chosen Captures. ... >> >> This suggests that resolution, frame rate, bandwidth, etc. are specified as >> part of the Configure, which is no longer true. >> >> (I have been getting a similar feeling in earlier sections, but in each case I >> could read it as ok, because "parameters" could mean other things.) >> >> For the moment I'm not going to suggest a specific fix. It could be fixed >> "here" with some minor rewording. But if we want to fix it document wide >> then that should be done in a unified way. > [Duckworth, Mark] This is fixed in version -16. I tried to fix it in all places in the document. Please let me know if you find any more problems like this. > >> And related to that is: >> >> In order to meaningfully create and send an initial Configure, the >> Consumer needs to have received at least one Advertisement from the >> Provider. >> >> It is now also necessary to have received an offer defining encodings of the >> captures of interest to the consumer. I think some rewording is required. > [Duckworth, Mark] I agree. > >> Section 12.1.1: >> >> Area of Capture needs to come out for the audio captures, replaced by point >> of capture and point on line of capture. > [Duckworth, Mark] Done in version -16. > >> More important, based on our audio discussions, does it make sense to >> provide separate audio captures for each camera? If not, what does make >> sense? Perhaps just a single mono audio, a single surround sound audio, and >> an audio for the presentation? > [Duckworth, Mark] I don't know what you mean. The example already has three separate captures (AC0, AC1, AC2) corresponding to the three cameras. Plus AC3 for the whole room. Plus AC4 to go with the presentation video. > >> There is a reference to MCC5, which is not defined. > [Duckworth, Mark] It should be VC5. > >> Section 12.2: >> >> This says: >> >> A sane, basic, algorithm might be for the consumer to go through >> each Capture Scene in turn and find the collection of Video >> Captures that best matches the number of screens it has ... >> >> But this doesn't say anything about CSEs - implying that ignoring them is >> sensible. It is *possible*, but explaining how to decide in that case is very >> complex. I would think for the purposes here we would want to recommend >> going through the CSEs looking for one that best exploits the locally available >> equipment. >> >> Did the above mean to say "... go through each CSE in turn ..."? > [Duckworth, Mark] Yes, that makes more sense. > >> Section 12.3.1: >> >> Table 14 doesn't leave the consumer with much choice. For instance there is >> no choice that works for a consumer that can handle only one video stream. >> >> ISTM that it would be better to merge tables 13 and 14, so that the consumer >> can have both one-encoding and two-encoding options. > [Duckworth, Mark] I think either way is just as good for the purpose of the example, which is to illustrate basic usage of MCCs. > >> Section 12.3.3: >> >> The following appears after Table 20: >> >> Rather than considering what is displayed the CLUE concentrates >> more on what the MCU sends. The MCU doesn't know anything about >> the number of screens an endpoint has. >> >> Something is wrong with this - "the CLUE" makes no sense. Should "the" >> be omitted, or was "this example" intended? > [Duckworth, Mark] "the" should be omitted. > >> I also see a reference to section 7.3.2 that isn't linked (in the html) to the >> actual section. Perhaps it is by value rather than reference in the source??? > [Duckworth, Mark] Yes, I think there are multiple instances of using text values rather than actual references in the source. I have to fix those. Right now our source is Microsoft Word format. I have to decide whether to keep it in Word, or port it back to XML. Are there any good reasons to port it back to XML? > >> Section 15: >> >> There is a reference to "section x", that needs to be updated to reference to >> proper section. > [Duckworth, Mark] Yes. > >> THE END >> >> Thanks, >> Paul > From nobody Thu Jul 17 11:56:10 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA93D1A0073 for ; Thu, 17 Jul 2014 11:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LWXb2wXASWML for ; Thu, 17 Jul 2014 11:52:24 -0700 (PDT) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB801A0002 for ; Thu, 17 Jul 2014 11:52:24 -0700 (PDT) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8BEC3C94BD; Thu, 17 Jul 2014 14:52:16 -0400 (EDT) Date: Thu, 17 Jul 2014 14:52:16 -0400 From: John Leslie To: Paul Kyzivat Message-ID: <20140717185216.GB31111@verdi> References: <53B0ADDC.5060706@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> <53C70D31.5040900@alum.mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53C70D31.5040900@alum.mit.edu> User-Agent: Mutt/1.4.1i Archived-At: http://mailarchive.ietf.org/arch/msg/clue/09IDEbgJWJmyXWw1TeSiCm6ABDY Cc: "clue@ietf.org" Subject: Re: [clue] Framework - normative references to taxonomy ??? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jul 2014 18:52:30 -0000 Paul Kyzivat wrote: > [ wrote:] > >> [Duckworth, Mark] The taxonomy does have a good description of MCU, >> describing how current common usage of the term MCU maps to other >> terms defined in taxonomy. I agree this is consistent with CLUE's >> usage of MCU. Maybe we should update the CLUE definition to be >> more like the taxonomy definition? Or help me understand how a >> reference to the Informational taxonomy doc could work. > > You ask how we make a normative document like this depend on definitions > in an informative document - the taxonomy. > > I don't know the answer to this. I'm interested to hear if somebody > feels qualified to give a definitive answer. The magic word is "downref" A good starting point is the DOWNREF Registry: http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry The standards-track document must contain a Normative Reference to the document with the needed definiton, and the IETF LastCall must specifically note the "downref". (The Document Shephard should make sure that happens -- it's common to have to repeat the LastCall to call out the downref.) RFC 3987 is _not_ exhaustive in its listing of conditions where this is appropriate: in practice, it's rare today for anyone to object to a downref. -- John Leslie From nobody Fri Jul 18 14:51:41 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBC51A0242 for ; Fri, 18 Jul 2014 14:51:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.465 X-Spam-Level: * X-Spam-Status: No, score=1.465 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5spFCdncfTpz for ; Fri, 18 Jul 2014 14:51:31 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC241A023F for ; Fri, 18 Jul 2014 14:51:31 -0700 (PDT) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta13.westchester.pa.mail.comcast.net with comcast id TwHN1o0030EZKEL5DxrWzo; Fri, 18 Jul 2014 21:51:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta01.westchester.pa.mail.comcast.net with comcast id TxrW1o00Q3ZTu2S3MxrWlq; Fri, 18 Jul 2014 21:51:30 +0000 Message-ID: <53C996E2.8080209@alum.mit.edu> Date: Fri, 18 Jul 2014 17:51:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "Duckworth, Mark" , "clue@ietf.org" References: <53B0ADDC.5060706@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405720290; bh=0hXRdJI0aKolNM7D/yfhRUdle7zYj9xZ/zE5uu7SoL8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=H/liOJPdzRohr6eLpQL5JGqhn061jWAkjdmagvvDKZnVX6v48SWMc1Uw5+DSr3yKU z1IyTHdHbVCNugqmXhoJgTf6qF1V/Efzb309Vwe0wap3Po69U4nnT4+0TAoh/U2MLc C2S+ZV68pYR7OQ5AyXzBtN32V8KZDXu/4BX2ImSk0igexsylOwkfIJJampO4MCShLd Uswn0l9YGcrYXTKU5hmRp6Gas6QyNpjixidto5XAZvaksYp85sf1sJVZHsAouWGqIL W7Rbz80l27vgTyMNLqV0iq0DsSqo1dCJLYESBMv2kmjfsLE6awRqchwNm/NOYBFf9z FIQBV7iXJLPDw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/niWEo75h8sCNuBVUA8yZXcvRzpQ Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 21:51:35 -0000 Hi Mark, Comments scattered throughout. On 7/16/14 5:25 PM, Duckworth, Mark wrote: > Hi Paul, > Thanks for all the comments. Responses inline. > Mark > >> -----Original Message----- >> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Sunday, June 29, 2014 8:23 PM >> To: clue@ietf.org >> Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt >> >> I apologize for being late with my own pre-WGLC review comments on this. >> I ended up spending a lot more time on it than I allotted. (And I >> procrastinated.) Also, I know there are some overlaps between my >> comments and Christians. I've left them in because it is easier than removing >> them and I may have some different nuances. >> >> And here I am speaking as an individual, not a chair. >> >> References: >> >> There is no separate section for References. They are found at the end of >> the "Changes since last version" section. I assume this is a bug. > [Duckworth, Mark] I think you mean it should be section number 17? I'll fix that. It's been that way for a long time, not sure why. Yes. Normally the top level section would be "References" with subsections for Normative References and Informative References. >> Section 1: >> >> In the following: >> >> The signaling details and data model are provided >> in subsequent documents. >> >> ISTM that the documents aren't "subsequent", in that there is no natural >> ordering relationship among them. I suggest "separate" (or "companion") >> documents. E.g., > [Duckworth, Mark] I agree > >> Companion documents describe signaling details [reference] and >> the data model. [reference] >> (These documents aren't currently in the references.) > [Duckworth, Mark] I agree we should add those to the references. Should we itemize all the "companion documents" here, with very brief description of them? This has already been separately discussed. >> Section 3: >> >> Re Capture Device: >> >> Capture Device: A device that converts audio and video input into >> an electrical signal, in most cases to be fed into a media encoder. >> >> This definition only applies to audio and video. (E.g., it excludes real-time >> text.) The grouping taxonomy defines it as: >> a physical entity performing a Media Capture transformation. > [Duckworth, Mark] How about changing the definition to: "A device that converts physical input, such as audio, video or text, into an electrical signal, in most cases to be fed into a media encoder " > This should cover cameras, microphones, keyboards... OK >> Re Capture Encoding: >> >> Can we relate this directly to the grouping taxonomy? The taxonomy already >> does so, saying it is >> >> a term to describe an Encoded Stream >> >> I'm not certain this is quite right - I think the description is of more than the >> Encoded stream - maybe a "Source RTP Stream". Whatever we decide, we >> should ensure that the fw and the taxonomy are updated to be consistent. > [Duckworth, Mark] Previous discussion led to Bo updating the taxonomy to say "Telepresence specifications from CLUE WG uses this term to describe an Encoded Stream (Section 2.1.7) related to CLUE specific semantic information." Do you think we need further clarification? Is this an issue for the taxonomy document? I'm not sure what the best way is to align these. Maybe we can find time to have a discussion with Bo about it. > [Duckworth, Mark] The definitions in CLUE framework are supposed to be normative, so we can't define them in terms of the Informational taxonomy document, can we? Discussed elsewhere. I think the answer is "yes we can". >> Re Endpoint: I think we could align better with the taxonomy. (We are pretty >> close.) > [Duckworth, Mark] I think it's not close, it's a different concept. My understanding is that A CLUE endpoint can have multiple taxonomy end points. An MCU is not a CLUE endpoint, but an MCU includes taxonomy end points. What do you suggest we change? Again I think we need to talk with Bo. The taxonomy is confusing. It has "End Point" and "Endpoint". (Where Endpoint is taken from CLUE.) I also think it is a problem that, because we say an MCU is not an Endpoint, we have no term that describes something that "does" CLUE. This has been fixed in the signaling draft. It defined CLUE-capable device. Perhaps we should import its definitions into the framework. Then both Endpoint and MCU are CLUE-capable devices. We might be better off formally make our terms "CLUE-Endpoint" and "CLUE-MCU", and then say that we often shorten them to just Endpoint and MCU in text. Then we can define CLUE-MCU as a MCU (from taxonomy) that supports CLUE. >> Re Front: >> >> Front: the portion of the room closest to the cameras. In going >> towards back you move away from the cameras. >> >> Do we need this? It is only referenced once, in the definition of spatial >> relationships. >> >> Also, unless all the cameras are placed on the same side of the room it is not >> unique. (There is a separate Front for each camera.) > [Duckworth, Mark] I think we need the definition, but maybe just in the spatial relation section and not explicitly in the definitions section, is that what you mean? I meant maybe we don't need a defined term at all. In the few places we need the concept just say more explicitly what we mean. > I understand your point about cameras in different locations. I think each Capture Scene must have a unique Front direction, because it is supposed to have a single coordinate system for everything in the scene, even if cameras are in different places. We have clearly defined that a scene has a single coordinate system. That doesn't mean that we must define front/back/left/right for a coordinate system. I don't see why that is helpful. ISTM that if we need them at all, then we should have "Camera-Front" and "Camera-Back". Also, I think there are problems with camera-left/right too. They are defined from the perspective of a person observing rendered media. That only works for a consumer, not a provider. And two consumers doing identical configurations of the same advertisement might choose to render differently so as to get different camera-left/right. ISTM that camera-* should be defined from the perspective of the axis of capture of the capture device, treated as a vector. Then Camera-Front is the direction of axis of capture, while Camera-Back is the opposite. And then for Camera-Left and Camera-Right construct a line perpendicular to both the axis of capture and the vertical axis. Left and Right are opposite directions on that - but I can't think how to choose which. Probably the "right hand rule". (Note this isn't well defined for cameras that point straight up or down.) > Should we try to clarify this in the document? > >> Re MCU: >> >> The taxonomy now has what seems to be a good definition of MCU. Can we >> refer to that one? We may have to specialize the definition for our purposes >> - requiring that it support CLUE. (That might mean we need to have a >> different name, such as CLUE MCU.) > [Duckworth, Mark] The taxonomy does have a good description of MCU, describing how current common usage of the term MCU maps to other terms defined in taxonomy. I agree this is consistent with CLUE's usage of MCU. Maybe we should update the CLUE definition to be more like the taxonomy definition? Or help me understand how a reference to the Informational taxonomy doc could work. See above. >> Re Media Capture: >> >> Our definition differs from the taxonomy in a significant way. Ours describes >> it as a form of "data" while the taxonomy describes it as a process. I'm not >> quite sure what to recommend for aligning these. I suspect one or the other >> needs to be renamed. > [Duckworth, Mark] I think it is good the way it is. CLUE definition is "a source of Media, such as from one or more Capture Devices or constructed from other Media streams". I think the source of media can be from a process (or transformation, as the taxonomy calls it). Taxonomy says : "Telepresence specifications from CLUE WG uses this term to describe either a Media Capture (Section 2.1.2) or a Media Source (Section 2.1.4), depending on in which context the term is used." I think this is accurate. OK >> Re Media Consumer: >> >> Media Consumer: an Endpoint or middle box that receives Media >> streams >> >> I think "Media Streams" is too general here. I suggest: >> >> Media Consumer: an Endpoint or middle box that is capable of >> receiving Media Encodings. > [Duckworth, Mark] Do you mean "... capable of receiving Capture Encodings"? I would agree with that. OK. But based on my earlier reference to signaling defs, how about: Media Consumer: a CLUE-Capable device that is capable of receiving Media Encodings. >> Re Media Provider: >> >> Similar to above I suggest: >> >> Media Provider: an Endpoint or middle box that is capable of >> sending Media Encodings. > [Duckworth, Mark] I would agree with "... capable of sending Capture Encodings" Same comment. >> Re Multiple Content Capture: >> >> This is limited to audio and video. Couldn't we potentially have an MCC for >> switched or mixed real-time text? How about: >> >> Multiple Content Capture: A Capture that mixes and/or switches >> other Captures of a single type. (E.g. all audio or all video.) >> Particular Media Captures may or may not be present in the >> resultant Capture Encoding depending on time or space. Denoted as >> MCCn in the example cases in this document. > [Duckworth, Mark] I agree. > >> Instead of just mentioning that MCCn may be used in examples, shouldn't >> we actually define MCC as an abbreviation? > [Duckworth, Mark] I agree. How about just using "Multiple Content Capture (MCC): A Capture that mixes...", which is how we do it for defining CSE. OK >> Re Stream: >> >> Can we relate this to the taxonomy? I think this corresponds to both a >> "Source RTP Stream" and a "Received RTP Stream". > [Duckworth, Mark] I agree. Can we keep our current definition, and add an informative reference to the taxonomy about this? OK >> Re Middlebox: >> >> This term isn't defined but it is used. I think it deserves a definition. > [Duckworth, Mark] I agree, but I don't have a good suggestion for a definition :( Is it more general than an MCU? Is a device that has user agents for signaling, but no media handling, considered a middle box? I think we *might* be able to just use MCU and drop use of middlebox. If there are cases where that isn't sufficient, then somebody needs to explain to me what was intended. >> Section 4: >> >> The following: >> >> ... In a few circumstances, a CLUE Endpoint middlebox >> includes only Consumer or Provider functionality, such as >> recorder-type Consumers or webcam-type Providers. ... >> >> I *think* this should say "Endpoint *or* middlebox". > [Duckworth, Mark] I agree. Looking again, I think thisis an appropriate place to use CLUE-capable device. >> Section 5: >> >> The following: >> >> This Advertisement and Configure MUST occur during call initiation >> but MAY also happen at any time throughout the call, whenever there >> is a change in what the Consumer wants to receive or (perhaps less >> common) the Provider can send. >> >> seems overly restrictive. This need not occur during *call* initiation. >> It is possible to initiate a call, but not enable clue until later. How >> about: >> >> This Advertisement and Configure MUST occur once use of CLUE has >> been enabled in a call, but MAY also happen at any time throughout >> the call, whenever there is a change in what the Consumer wants to >> receive or (perhaps less common) the Provider can send. > [Duckworth, Mark] I agree > >> Figure 1 doesn't include the Global Capture Scene Entry List. > [Duckworth, Mark] It is there in version -16 OK. Ideally the figure would show the relationships between the GCSE and the CSE entries. But I don't think it is feasible to show in one figure, especially with ascii art. >> Section 6 says: >> >> X increases from Camera-Left to Camera-Right >> Y increases from front to back >> >> (Also see my comment on the definition of "Front".) >> >> Defining the coordinates relative to a camera is problematic since there can >> be multiple cameras. (Consider case where we have cameras facing the >> audience and others facing speakers in front of the audience.) >> >> I'm not sure we can say anything better than that the X,Y coordinates should >> be chosen to be sensible for the set of captures to be offered. >> Perhaps an example where all the cameras point in generally the same >> direction would get the point across. > [Duckworth, Mark] We could clarify this. I'll try to propose something more specific. > >> Section 7.1.1: >> >> Isn't mono/stereo now gone as a capture attribute? > [Duckworth, Mark] Yes, I'll remove that. > >> Section 7.1.1.2: >> >> Perhaps we should say that the Point on Line of Capture actually defines not >> just the axis, but a vector indicating the direction of capture? > [Duckworth, Mark] I agree > >> Section 7.1.1.3: >> >> I guess some restructuring is needed to limit area of capture to video. > [Duckworth, Mark] Does area of capture apply only to video? Or can it apply to any media type other than audio? framework-16 simply says it does not apply to audio. Well, what types of media do we currently know of: audio, video, text. area of capture applies to video, not audio. What about text? I don't think so. *Maybe* point of capture applies. (Center of the keyboard?) Does axis of capture apply to text? I don't think so. So I think each type of media has distinct geometric attributes that describe it. What would we use for smell? (Actually it may be similar to audio.) >> Section 7.1.1.5: >> >> Didn't we agree to remove this. (That it will be handled as part of an >> encoding.) > [Duckworth, Mark] The "Audio Channel Format" section is removed in framework-16. > >> Section 7.2.1.2: >> >> The explanation of 'index' is pretty fuzzy. ISTM that the meaning really needs >> to be specified separately for each token. E.g., for SoundLevel N means the >> N'th most recent loudest speaker. For RoundRobin it is harder to describe. > [Duckworth, Mark] Makes sense for SoundLevel. Do we want to have an index for RoundRobin? I suppose it could make sense there too. But I think the current definition of the index is adequate. I suspect there is a reason to have have an index for each kind. But what that index *means* has to be defined separately for each kind. >> Section 7.2.1.3: >> >> I have read this several times, and while I know this is about site switching I >> cannot figure it out from the words written here. Even the example isn't >> helping me (and I don't think it should take an example to make it >> understandable.) > [Duckworth, Mark] I think there is a word missing: "To indicate that the Capture Encodings associated with MCCs contain captures from the *same*source at the same time..." It seems clear to me, so does anybody else have a suggestion for how to make this more clear? Still not working for me. How about: "All MCCs sharing a common value for Synchronization Identity MUST, at each point in time, contain captures from a single source." I think that is close, but "source" is wrong. I think we want "Site", but that isn't a defined term. Maybe "Endpoint" works: "All MCCs sharing a common value for Synchronization Identity MUST, at each point in time, contain captures from a single Endpoint." >> For instance, ISTM that the synchronization id and the policy can give >> conflicting criteria for what is included at each point in time. And also the max >> captures may define a composition policy that would violate the >> synchronization. > [Duckworth, Mark] I agree it is possible for a provider to do that in an advertisement. I don't think we can prevent this syntactically in the data model. I think it is okay to leave it this way. My head aches now. So for now I guess its ok to ignore this. >> Section 7.3: >> >> I have a question: Can a scene have captures that are not included in any >> CSE? If not, then there probably ought to be something that says that. If so, >> then there are other issues. If so, then presumably it should be possible to >> have scenes with no CSEs. (Did we have this discussion previously?) > [Duckworth, Mark] I thought we didn't want to have captures that were not in a CSE. But then maybe the addition of MCC concept would change that. An MCC can include an individual capture from the same scene, and that individual capture might not have an encoding group, so then maybe in some cases it wouldn't make sense to put that capture into a CSE? I'm not sure what problems there would be if there are captures that are not in a CSE. What problems do you see? Yeah, I guess that is a good enough reason to allow this. >> I suggest that the following: >> >> ... A Capture Scene includes one >> or more Capture Scene entries, with each entry including one or >> more Media Captures. ... >> >> be tweaked by: s/Media Captures/Media Captures of the same media type/ > [Duckworth, Mark] I agree. > >> In the following: >> >> A provider MAY express spatial relationships between Captures that >> are included in the same Capture Scene. However, there is not >> necessarily the same spatial relationship between Media Captures >> that are in different Capture Scenes. In other words, Capture >> Scenes can use their own spatial measurement system as outlined >> above in section 6. >> >> saying capture scenes *can* user their own spatial measurement system >> suggests the contrary is a possibility - that they may share a spatial >> measurement system. That isn't really true. We assume that each scene is >> spatially unrelated to every other scene. So I suggest revising this as: >> >> A provider MAY express spatial relationships between Captures that >> are included in the same Capture Scene. However, there is no >> spatial relationship between Media Captures from >> different Capture Scenes. In other words, Capture >> Scenes each use their own spatial measurement system as outlined >> above in section 6. > [Duckworth, Mark] I agree. > >> While reading this section I find Capture Scene *Entry* to be a poor name for >> what it represents. ISTM that each CSE selects a set of captures that, >> together, represent a view of the entire scene. (Some better than others.) I >> think a better name for this would be *Scene View*. >> >> (I realize that while only a nomenclature change, this is a fundamental >> element we use in talking to one another and so is mentally hard to change. >> But I think we at least ought to consider it as making clue more >> understandable to outsiders. And of course we can consider other names.) >> >> Making such a change would of course result in renaming a number of other >> things. I won't call those out specifically. > [Duckworth, Mark] We can consider this. I'm glad you agree. I think it is important, though perhaps painful to make the change. But I am biased since it is my idea. I think we need to talk about it. >> Section 7.3.3: >> >> The following isn't quite right: >> >> ... Each item in this list is a set of one or more >> Capture Scene Entries of the same media type. ... >> >> I can read this and think that CSEs are actually contained in this. It is important >> that what is included are *references* to CSEs defined in scenes. So I >> suggest: >> >> ... Each item in this list is a set of references to one or more >> of the Capture Scene Entries of the same media type that are >> defined within scenes of the same advertisement. ... > [Duckworth, Mark] I agree > >> And, in line with my comment about the naming of CSE, I think we can find a >> more understandable name for this thing than Global CSE List. >> (IIRC the current name was my idea.) >> >> I'm thinking *Global View* would work as the name for one element of this >> list. And then I guess the list of them would be *Global View List*. >> >> If we did all that, then 7.3.3 would start out as: >> >> 7.3.3. Global View List >> >> An advertisement can include an optional Global View List. >> Each item in this list is a Global View. Each Global >> View is a set of one or more references to Scene Views of the same >> media type, defined within scenes of the same advertisement. >> Each Global View is a suggestion from the Provider to the >> Consumer for some Scene Views that provide a complete view of the >> simultaneous captures provided by the provider, across the multiple >> scenes of the advertisement. The Provider can include a Global >> View List to help a consumer to choose sets of captures appropriate >> to its capabilities or application. The choice of how to make these >> suggestions in the Global View List, for what represents all >> the scenes for which the provider can send media, is up to the >> provider. This is very similar to how each Scene View represents a >> particular scene. >> >> (But we would certainly add Global View to the definitions, and so part of the >> above might appear there rather than here.) > [Duckworth, Mark] I think we should consider these suggestions to improve the naming of these things. > >> Section 8: >> >> The following: >> >> ... If a >> Capture Scene is included in a Simultaneous Transmission Set, then >> all its Capture Scene Entries (of the corresponding media type) are >> included in the Simultaneous Transmission Set. ... >> >> implies that there is some mechanism to determine the media type of the >> simultaneous transmission set. Currently it is only determined by the type of >> its entries. But if all the entries are scenes, then that isn't good enough. I can >> think of a variety of fixes for this. We should discuss how to fix this. > [Duckworth, Mark] I think this is an issue for the data model, not the framework. I think it is still a semantic issue. The data model will be constructed to be consistent with the FW. I forget whether we allow captures of different media types to be in the same STS. I *think* we discussed this and decided it was ok. *If* that is so, then I think you can simply omit "(of the corresponding media type)" from the above. But, if we want to restrict a single STS to a single media type and we want to allow including whole scenes in an STS, then we must provide a way to break the ambiguity. I can think of a couple of ways, but its easier to allow STSs to include all types. (Even if most of them won't.) >> I find the following ambiguous or at least hard to understand: >> >> If an Advertisement does not include Simultaneous Transmission >> Sets, then the Provider MUST be able to provide all Capture Scenes >> simultaneously. If multiple capture Scene Entries are in a Capture >> Scene then the Consumer chooses at most one Capture Scene Entry per >> Capture Scene for each media type. Likewise, if there are no >> Simultaneous Transmission Sets and there is a global CSE list, then >> the Consumer chooses at most one set of CSEs of each media type, >> from the global CSE list. >> >> It switches from what the provider MUST do (be able to provide all capture >> scenes simultaneously), to what the consumer does, which doesn't seem to >> be normative. > [Duckworth, Mark] I agree we should reword it, to describe what the provider's advertisement means, without describing it as what the consumer does. > >> What is missing is a definition of what it means to be able to provide a >> capture scene. I think "be able to provide a capture scene" means: be able to >> simultaneously provide all of the captures in any single CSE of the scene. >> >> If that is right, then the question is how to write that as a clear normative >> statement. Either we can try to come up with text that says the above, or >> else we could say that there is a default simultaneous transmission set and >> come up with an algorithm to derive it from the CSEs in the advertisement. >> (The algorithm is straightforward, but describing it in text is not.) Here is a cut >> at the text: >> >> If an Advertisement does not include Simultaneous Transmission >> Sets, then the Provider MUST be able to simultaneously provide >> all the captures from any one CSE of each media type from each >> capture scene. > [Duckworth, Mark] This is an improvement for the beginning of the paragraph. Then I think the rest of the paragraph should continue to describe what the provider's advertisement means rather than describing what the consumer does. OK >> Section 9.3: >> >> I have some concerns with the first paragraph: >> >> Each Media Capture MAY be associated with at least one Encoding >> Group, which is used to instantiate that Capture into one or more >> Capture Encodings. Typically MCCs are assigned an Encoding Group >> and thus become a Capture Encoding. The Captures (including other >> MCCs) referenced by the MCC do not need to be assigned to an >> Encoding Group. This means that all the Media Captures referenced >> by the MCC will appear in the Capture Encoding according to any MCC >> attributes. This allows an Advertiser to specify Capture attributes >> associated with the Media Captures without the need to provide an >> individual Capture Encoding for each of the inputs. >> >> The construction "MAY be associated with at least one" seems awkward, and >> doesn't not the key point that if a capture is to be eligible for configuration it >> MUST be associated with at least one. And then, "Typically MCCs are >> assigned an Encoding Group and thus become a Capture Encoding" implies >> that the assignment of the MCC to an encoding group >> *causes* to become a Capture Encoding, which isn't right. I think the >> following clarifies both of those points: >> >> Each Media Capture, including MCCs, MAY be associated with one or >> more Encoding Groups. To be eligible for configuration, a Media >> Capture MUST be associated with at least one Encoding Group, which >> is used to instantiate that Capture into one or more Capture >> Encodings. When an MCC is configured all the Media Captures >> referenced by the MCC will appear in the Capture Encoding according >> to the attributes of the chosen encoding of the MCC. This allows an >> Advertiser to specify encoding attributes associated with the Media >> Captures without the need to provide an individual Capture Encoding >> for each of the inputs. > [Duckworth, Mark] That is a good improvement. > >> Section 10: >> >> Some of the text in this section is out of date with changes we have made >> along the way. This is most obvious in: >> >> For each Capture the Consumer wants to receive, it configures one >> or more of the encodings in that capture's encoding group. The >> Consumer does this by telling the Provider, in its Configure >> Message, parameters such as the resolution, frame rate, bandwidth, >> etc. for each Capture Encodings for its chosen Captures. ... >> >> This suggests that resolution, frame rate, bandwidth, etc. are specified as >> part of the Configure, which is no longer true. >> >> (I have been getting a similar feeling in earlier sections, but in each case I >> could read it as ok, because "parameters" could mean other things.) >> >> For the moment I'm not going to suggest a specific fix. It could be fixed >> "here" with some minor rewording. But if we want to fix it document wide >> then that should be done in a unified way. > [Duckworth, Mark] This is fixed in version -16. I tried to fix it in all places in the document. Please let me know if you find any more problems like this. OK >> And related to that is: >> >> In order to meaningfully create and send an initial Configure, the >> Consumer needs to have received at least one Advertisement from the >> Provider. >> >> It is now also necessary to have received an offer defining encodings of the >> captures of interest to the consumer. I think some rewording is required. > [Duckworth, Mark] I agree. > >> Section 12.1.1: >> >> Area of Capture needs to come out for the audio captures, replaced by point >> of capture and point on line of capture. > [Duckworth, Mark] Done in version -16. > >> More important, based on our audio discussions, does it make sense to >> provide separate audio captures for each camera? If not, what does make >> sense? Perhaps just a single mono audio, a single surround sound audio, and >> an audio for the presentation? > [Duckworth, Mark] I don't know what you mean. The example already has three separate captures (AC0, AC1, AC2) corresponding to the three cameras. Plus AC3 for the whole room. Plus AC4 to go with the presentation video. I know it does. And I am questioning whether that makes sense. Doing some very rough plotting on paper, it appears that the AC0 is in front of VC0, AC1 is in front of VC2, and AC2 is in front of VC1. They are not in a line - AC2 is further back. All have axis of capture pointing (roughly) toward their corresponding screen. (I find the axis of capture surprising. I would expect it to point in the opposite direction - in the direction that the microphones presumably point.) But how much do these overlap in coverage? If somebody configures these, how would they render them to get reasonable results? But maybe it is good to have such an example because it will force confronting such issues. >> There is a reference to MCC5, which is not defined. > [Duckworth, Mark] It should be VC5. OK >> Section 12.2: >> >> This says: >> >> A sane, basic, algorithm might be for the consumer to go through >> each Capture Scene in turn and find the collection of Video >> Captures that best matches the number of screens it has ... >> >> But this doesn't say anything about CSEs - implying that ignoring them is >> sensible. It is *possible*, but explaining how to decide in that case is very >> complex. I would think for the purposes here we would want to recommend >> going through the CSEs looking for one that best exploits the locally available >> equipment. >> >> Did the above mean to say "... go through each CSE in turn ..."? > [Duckworth, Mark] Yes, that makes more sense. > >> Section 12.3.1: >> >> Table 14 doesn't leave the consumer with much choice. For instance there is >> no choice that works for a consumer that can handle only one video stream. >> >> ISTM that it would be better to merge tables 13 and 14, so that the consumer >> can have both one-encoding and two-encoding options. > [Duckworth, Mark] I think either way is just as good for the purpose of the example, which is to illustrate basic usage of MCCs. > >> Section 12.3.3: >> >> The following appears after Table 20: >> >> Rather than considering what is displayed the CLUE concentrates >> more on what the MCU sends. The MCU doesn't know anything about >> the number of screens an endpoint has. >> >> Something is wrong with this - "the CLUE" makes no sense. Should "the" >> be omitted, or was "this example" intended? > [Duckworth, Mark] "the" should be omitted. > >> I also see a reference to section 7.3.2 that isn't linked (in the html) to the >> actual section. Perhaps it is by value rather than reference in the source??? > [Duckworth, Mark] Yes, I think there are multiple instances of using text values rather than actual references in the source. I have to fix those. Right now our source is Microsoft Word format. I have to decide whether to keep it in Word, or port it back to XML. Are there any good reasons to port it back to XML? I am not going to ask you to convert to xml at this point. (It's a huge job.) If you have gotten this far with Word and have no compelling reason to change then just continue on. >> Section 15: >> >> There is a reference to "section x", that needs to be updated to reference to >> proper section. > [Duckworth, Mark] Yes. > >> THE END >> >> Thanks, >> Paul > From nobody Fri Jul 18 15:09:54 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08F6E1A0242 for ; Fri, 18 Jul 2014 15:09:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIlz8e8akhsR for ; Fri, 18 Jul 2014 15:09:53 -0700 (PDT) Received: from qmta04.westchester.pa.mail.comcast.net (qmta04.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:40]) by ietfa.amsl.com (Postfix) with ESMTP id 0198C1A0204 for ; Fri, 18 Jul 2014 15:09:52 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta04.westchester.pa.mail.comcast.net with comcast id TuKq1o0020cZkys54y9sGx; Fri, 18 Jul 2014 22:09:52 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id Ty9s1o0093ZTu2S3Wy9sf4; Fri, 18 Jul 2014 22:09:52 +0000 Message-ID: <53C99B30.8070207@alum.mit.edu> Date: Fri, 18 Jul 2014 18:09:52 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405721392; bh=d+6WX292zfOAUpcjTsnhYrS22T/QKLUXU2Flb/I3viM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=dAmgwYJLrl41TC3gZDoL7ZOXWjZcGX0zayMeThmJBy7JAMRRNrdiFckn5ncroL0oe 4H5QEtTT6ty+fQ2WG7O7WJkGYOP4sFqgWSGlE6ceyxZoPwLbPn7vgREfyYJfSGbQ/9 UHxkAz5yXZA3oZsRCtLvLH61mTx6+qPT88sfD9RKfItgfHuBukUVAZJaTukkxkU/LK ruQNghOkUbC0Pq8Qx8eA51pU2g3xmLqDLXWWaDIhVFgMJjrLhjrXY1ILreK+wyharX ahKZW6rXZUwpGxY9/alhVAZkFxfam/nXFIcwqR4ecWMe/GHJn+u7rl2TE1BExGDX5b kBHBYXYtox4Pw== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/mPaQ7oR07ExrtraLNiqfI7Qqtmo Subject: [clue] CLUE dinner poll X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 22:09:54 -0000 Folks - Here is link to doodle poll for a CLUE dinner next week. http://doodle.com/ga867gf7xa8w3u5m#table I have *not* investigated where we might go. (Our social directory has been occupied with more interesting things.) Once a preferred night is clear I'll see what I can find. If anyone has suggestions, please speak up. (You could put comments in the poll.) I'm not a noted gourmet, and I'm not allergic to any foods that I know of, so left to my own devices I might not make a great choice. Thanks, Paul From nobody Fri Jul 18 16:22:26 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 113101A02D0 for ; Fri, 18 Jul 2014 16:22:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BDHbZNo1ZRcR for ; Fri, 18 Jul 2014 16:22:20 -0700 (PDT) Received: from qmta07.westchester.pa.mail.comcast.net (qmta07.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:64]) by ietfa.amsl.com (Postfix) with ESMTP id 90DE21A02A2 for ; Fri, 18 Jul 2014 16:22:20 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta07.westchester.pa.mail.comcast.net with comcast id TyxX1o0080cZkys57zNL2Z; Fri, 18 Jul 2014 23:22:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id TzNK1o00V3ZTu2S3WzNK5B; Fri, 18 Jul 2014 23:22:20 +0000 Message-ID: <53C9AC2B.4010106@alum.mit.edu> Date: Fri, 18 Jul 2014 19:22:19 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: CLUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405725740; bh=mCVRfYStPNQNqKiBd+2X2FHdbb4Ph4aHladipHd5lJA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=tj2exw7yWvpJoogKTvC+KY87PU/t4VMgf3OtqcCI0KGKGaWlqGjqoGz1/YRfW84Gr a83TbxGIWVBfUq+WaAp5s6RQ3ijeLOXOnSvP6bfLvwEO17+xNFNqZ84bJBuHryGzPi CV0yM4jhaU5XH3eSE+RBMSdPXk0rp7L1OsoRO/SJwx3VwmzaEVtqCccwetwiQUAs2S Bh1yK2F3RE9TWPROhgshgYuvaGWAoRaKe62shvlaw/wVN6XGVjQ648t+uzH0tV+O0+ 80YdptkumovtplhVenMhFW570d4sH3VB+KBjVn6AmPrym/t/82fybwh14OMoVj325o 5ipb+WZiOs/Ng== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/bGOwdMb8tKPev2HKbbwxvATMXDs Subject: [clue] Aligning CLUE with draft-ietf-avtext-rtp-grouping-taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 23:22:26 -0000 The following are some terminology conflicts between CLUE and the the RTP Grouping Taxonomy draft: * Media Capture is described in the taxonomy as follows: 4.8. Media Capture Telepresence specifications from CLUE WG uses this term to describe either a Media Capture (Section 2.1.2) or a Media Source (Section 2.1.4), depending on in which context the term is used. 2.1.2. Media Capture Media Capture is the process of transforming the Physical Stimulus (Section 2.1.1) into digital Media using an appropriate sensor or transducer. 2.1.4. Media Source A Media Source is the logical source of a reference clock synchronized, time progressing, digital media stream, called a Source Stream (Section 2.1.5). This transformation takes one or more Raw Streams (Section 2.1.3) and provides a Source Stream as output. This output has been synchronized with some reference clock, even if just a system local wall clock. The CLUE term Media Capture means *either* a Taxonomy Media Capture or a Taxonomy Media Source, depending on context. Perhaps it is ok if it is the union of these two, *if* it is clear how they fit together and can be distinguished when need be. It would be better if our term meant only one of these things. But either way, it is pretty unreasonable to use the *same* term differently in the two documents. I think one of use must change. I don't care which one. * The "Endpoint"/"End Point" is described in the taxonomy as follows: 4.5. Endpoint Telepresence specifications from CLUE WG use this term to describe exactly one Participant (Section 2.2.3) and one or more End Points (Section 2.2.1). 2.2.1. End Point Editor's note: Consider if a single word, "Endpoint", is preferable A single addressable entity sending or receiving RTP packets. It may be decomposed into several functional blocks, but as long as it behaves as a single RTP stack entity it is classified as a single "End Point". 2.2.3. Participant A Participant is an entity reachable by a single signaling address, and is thus related more to the signaling context than to the media context. Technically there is no conflict here because "Endpoint" and "End Point" are different. But they are just different spelling, so easily confused that it presents a problem. Also, there is the note that the Taxonomy might want to change making them fully conflict. Again I think one of use must change. I don't care which one. * MCU is described in the taxonomy as follows: 4.7. Multipoint Control Unit (MCU) This term is commonly used to describe the central node in any type of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference. It describes a device that includes one Participant (Section 2.2.3) (usually corresponding to a so-called conference focus) and one or more related End Points (Section 2.2.1) (sometimes one or more per conference participant). This is a quite good definition for CLUE purposes, except that this definition does not assume CLUE support, while when we use MCU in CLUE we mean something that is an MCU in the sense defined here *and* also is a CLUE-Capable device as defined in the CLUE signaling draft. I think for this we should update the CLUE docs to use "CLUE MCU" instead of just "MCU", and then define that with reference to this definition. I'm hoping Jonathan can serve as a proxy for the taxonomy author team. For now I'm only sending this to clue, not mmusic. Thanks, Paul From nobody Sun Jul 20 18:30:47 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94751B2A66 for ; Sun, 20 Jul 2014 18:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmsAlPZ5MK8e for ; Sun, 20 Jul 2014 18:30:44 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD741B2AB2 for ; Sun, 20 Jul 2014 18:30:44 -0700 (PDT) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id UpAu1o0061vXlb85ApWk4b; Mon, 21 Jul 2014 01:30:44 +0000 Received: from dhcp-950a.meeting.ietf.org ([31.133.149.10]) by omta17.westchester.pa.mail.comcast.net with comcast id UpUb1o0090Di5JP3dpUdiZ; Mon, 21 Jul 2014 01:28:42 +0000 Message-ID: <53CC6CC3.2080604@alum.mit.edu> Date: Sun, 20 Jul 2014 21:28:35 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53C99B30.8070207@alum.mit.edu> In-Reply-To: <53C99B30.8070207@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405906244; bh=jErTDEwBXiReQL2a+zi0/zEIyykbZZxD/PB5FQcaLkg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WeMMrISfun4oaZ3fzptSi/F5Tq+x8armIIO8bR6ofkL6xCQBfuuhTbhkzmqDzZagn Yxm0LsJN19VdQJh5FymBs9RftarIra59pmqAYRTzqVW7qNenTtvVMlJS1VbblYGI6r ZxfAxNeILDFrv/5Le1HI2XdHjaV6JGWk/m1/Ef0WZaB4C0pVBLtexBzXuJfRSn2ESf oEk/DZUd4Gr2o1fIlgVYk4TEOxl3MecXsA5pzSlGHwlWnC/SExV/OBz0RDtQEFjV0n 1+qzFXNeBDI1FgHe83ydYNJkQ445EN/JmxHxnucYBe/vDvjNRqaPxkzoH5v6qV/XfC shQyt2FbV38Ew== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/t1DvQs3L-7uajZye7_8Gi6I-5uk Subject: Re: [clue] CLUE dinner poll X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 01:30:46 -0000 So far we have only four people expressing interest. They can all make it Monday, and only 3 on Wed. And Mary said she might be able to show up late on monday. So I'm going to call it for 8pm on Monday. I'll have to find a place. I'll try to reserve a few extra seats in case somebody else wants to sign up. I'll inform about the location tomorrow. Thanks, Paul On 7/18/14 6:09 PM, Paul Kyzivat wrote: > Folks - Here is link to doodle poll for a CLUE dinner next week. > > http://doodle.com/ga867gf7xa8w3u5m#table > > I have *not* investigated where we might go. (Our social directory has > been occupied with more interesting things.) > > Once a preferred night is clear I'll see what I can find. If anyone has > suggestions, please speak up. (You could put comments in the poll.) I'm > not a noted gourmet, and I'm not allergic to any foods that I know of, > so left to my own devices I might not make a great choice. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Jul 20 21:31:46 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3D71B2AC4 for ; Sun, 20 Jul 2014 21:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6IhaXPtnG1D for ; Sun, 20 Jul 2014 21:31:43 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A59C01B2A49 for ; Sun, 20 Jul 2014 21:31:42 -0700 (PDT) Received: from ppp118-209-224-58.lns20.mel6.internode.on.net ([118.209.224.58]:62264 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X95FX-0005SK-9l for clue@ietf.org; Mon, 21 Jul 2014 14:30:55 +1000 Message-ID: <53CC97AA.2010400@nteczone.com> Date: Mon, 21 Jul 2014 14:31:38 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53A8F05E.6080902@nteczone.com> <53AD4395.5080708@unina.it> <53B0D3BA.4090202@nteczone.com> <53B1895C.7050102@alum.mit.edu> In-Reply-To: <53B1895C.7050102@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-FrbouSLmj3ZvSZnr_I8Ya84Pi8 Subject: Re: [clue] Review Groves al data model 05 [Re: Pre-WGLC: draft-ietf-clue-data-model-schema-05.txt] X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 04:31:45 -0000 Hello Paul, Please see my reply below. Regards, Christian On 1/07/2014 1:59 AM, Paul Kyzivat wrote: > On 6/29/14 11:04 PM, Christian Groves wrote: > >>>> - General: Do we need a statement about whether the framework or the >>>> data model takes precedence regarding the definition of attributes? >>> 13. I'm not sure we need such a statement in the data model. >>> However, up to now, the data model has followed the news introduced >>> in the framework. >>> By looking at how we conceived them, they are strictly interconnected, >>> so updates in one should be reflected (if necessary, i.e., if new >>> elements are defined, or the existing one are changed in their >>> structure) in updates in the companion document (independently from >>> the precedence rule). >> [CNG] I agree they are fairly well aligned. However we may find in the >> future that the description of something is open to interpretation. In >> that case does the reader follow what the framework says or what the >> data model says? > > How can the data model not be definitive? If the model schema > disagrees with the FW, then how can you follow the fw? You are > constrained by what you can say with the schema. [CNG] There's syntax and semantics. You may be compliant with the data model syntax but use the elements in a different semantic way. This sort of error can creep in when there are two descriptions of an attribute/element. I.e. one in the framework and one in the data model. I agree the goal is to have no discrepancy however people not closely involved in the work might find some ambiguity later on. > > So ISTM that we ought to at least say that if the *schema* differs > from what the fw or the data model *text* say then the schema takes > precedence. We then must do a careful review to ensure consistency. [CNG] Fine by me. > > Thanks, > Paul > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Jul 20 21:34:06 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 875A51B2D5C for ; Sun, 20 Jul 2014 21:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSOqVRyAW7Qy for ; Sun, 20 Jul 2014 21:34:03 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 568241B2CC8 for ; Sun, 20 Jul 2014 21:34:03 -0700 (PDT) Received: from ppp118-209-224-58.lns20.mel6.internode.on.net ([118.209.224.58]:62266 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X95Ho-0005rL-BA for clue@ietf.org; Mon, 21 Jul 2014 14:33:16 +1000 Message-ID: <53CC9837.2050507@nteczone.com> Date: Mon, 21 Jul 2014 14:33:59 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53B192B0.6080907@cisco.com> In-Reply-To: <53B192B0.6080907@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/4_9ViirFdTn3VlEetFDMquQ490E Subject: Re: [clue] Data model - encoding group mandatory for all captures? X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 04:34:04 -0000 Hello Rob, I agree, it seems that should be optional given that individual captures do not have to have an encoding. As you point out this is necessary for MCCs. Regards, Christian On 1/07/2014 2:39 AM, Robert Hansen wrote: > One issue that I ran into while preparing a sample ADVERTISMENT of one > of our telepresence endpoints for the wiki - is > mandatory for all captures. However, what about captures that can't be > directly configured, but are instead just informational for MCCs? For > example, in this case I wanted to represent that the system has three > cameras, but only makes a single, voice-switched stream available - > you can't configure a captureEncoding of any of the cameras directly. > > In my example was able to work around the problem by making those > captures unavailable by not including them in the > list, but with the potential for captures to exist that are there > purely to provide info for the contents of MCCs it seems we should > have a way of expressing this properly. This isn't a simultaneity > issue but one where they can't be encoded. As such, making > optional would seem to be the answer here. > > Rob > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Sun Jul 20 21:47:42 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFABE1B2A5A for ; Sun, 20 Jul 2014 21:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJiY9m5ikmiE for ; Sun, 20 Jul 2014 21:47:38 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A40451B2D5B for ; Sun, 20 Jul 2014 21:47:37 -0700 (PDT) Received: from ppp118-209-224-58.lns20.mel6.internode.on.net ([118.209.224.58]:62343 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X95Uw-00085a-Av for clue@ietf.org; Mon, 21 Jul 2014 14:46:50 +1000 Message-ID: <53CC9B66.60105@nteczone.com> Date: Mon, 21 Jul 2014 14:47:34 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53B0ADDC.5060706@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> <53C996E2.8080209@alum.mit.edu> In-Reply-To: <53C996E2.8080209@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-pJ1wAwRSqcL_Boz_KRiOtzF3fg Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 04:47:39 -0000 Hello Mark and Paul, A few comments. Regards, Christian On 19/07/2014 7:51 AM, Paul Kyzivat wrote: > ..snip.. >>> Section 7.1.1.3: >>> >>> I guess some restructuring is needed to limit area of capture to video. >> [Duckworth, Mark] Does area of capture apply only to video? Or can >> it apply to any media type other than audio? framework-16 simply >> says it does not apply to audio. > > Well, what types of media do we currently know of: audio, video, text. > > area of capture applies to video, not audio. > > What about text? I don't think so. *Maybe* point of capture applies. > (Center of the keyboard?) > > Does axis of capture apply to text? I don't think so. > > So I think each type of media has distinct geometric attributes that > describe it. > > What would we use for smell? (Actually it may be similar to audio.) [CNG] Maybe we should just focus on video? We can always add an extra attributes for other media types if they become necessary. > ..snip.. >> >>> Section 7.2.1.2: >>> >>> The explanation of 'index' is pretty fuzzy. ISTM that the meaning >>> really needs >>> to be specified separately for each token. E.g., for SoundLevel N >>> means the >>> N'th most recent loudest speaker. For RoundRobin it is harder to >>> describe. >> [Duckworth, Mark] Makes sense for SoundLevel. Do we want to have an >> index for RoundRobin? I suppose it could make sense there too. But >> I think the current definition of the index is adequate. > > I suspect there is a reason to have have an index for each kind. But > what that index *means* has to be defined separately for each kind. [CNG] I don't see we need to define the index per kind. The index is the n x last speaker, no matter the kind. I can't see the concern with round robin here? > >>> Section 7.2.1.3: >>> >>> I have read this several times, and while I know this is about site >>> switching I >>> cannot figure it out from the words written here. Even the example >>> isn't >>> helping me (and I don't think it should take an example to make it >>> understandable.) >> [Duckworth, Mark] I think there is a word missing: "To indicate that >> the Capture Encodings associated with MCCs contain captures from the >> *same*source at the same time..." It seems clear to me, so does >> anybody else have a suggestion for how to make this more clear? > > Still not working for me. How about: > > "All MCCs sharing a common value for Synchronization Identity MUST, at > each point in time, contain captures from a single source." > > I think that is close, but "source" is wrong. I think we want "Site", > but that isn't a defined term. Maybe "Endpoint" works: > > "All MCCs sharing a common value for Synchronization Identity MUST, at > each point in time, contain captures from a single Endpoint." [CNG] I think endpoint works OK. > ..snip.. > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Sun Jul 20 21:57:56 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50891B2D83 for ; Sun, 20 Jul 2014 21:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ubu_0td4pECK for ; Sun, 20 Jul 2014 21:57:45 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05BE81B2D80 for ; Sun, 20 Jul 2014 21:57:45 -0700 (PDT) Received: from ppp118-209-224-58.lns20.mel6.internode.on.net ([118.209.224.58]:62394 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1X95ej-000194-R3 for clue@ietf.org; Mon, 21 Jul 2014 14:56:57 +1000 Message-ID: <53CC9DC5.7080206@nteczone.com> Date: Mon, 21 Jul 2014 14:57:41 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53C9AC2B.4010106@alum.mit.edu> In-Reply-To: <53C9AC2B.4010106@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZDLaidAAVQhT7kkpuowcIaPJHp4 Subject: Re: [clue] Aligning CLUE with draft-ietf-avtext-rtp-grouping-taxonomy X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 04:57:52 -0000 Hello Paul, Please see below. Regards, Christian On 19/07/2014 9:22 AM, Paul Kyzivat wrote: > The following are some terminology conflicts between CLUE and the the > RTP Grouping Taxonomy draft: > > * Media Capture is described in the taxonomy as follows: > > 4.8. Media Capture > > Telepresence specifications from CLUE WG uses this term to describe > either a Media Capture (Section 2.1.2) or a Media Source > (Section 2.1.4), depending on in which context the term is used. > > 2.1.2. Media Capture > > Media Capture is the process of transforming the Physical Stimulus > (Section 2.1.1) into digital Media using an appropriate sensor or > transducer. > > 2.1.4. Media Source > > A Media Source is the logical source of a reference clock > synchronized, time progressing, digital media stream, called a Source > Stream (Section 2.1.5). This transformation takes one or more Raw > Streams (Section 2.1.3) and provides a Source Stream as output. This > output has been synchronized with some reference clock, even if just > a system local wall clock. > > The CLUE term Media Capture means *either* a Taxonomy Media Capture or > a Taxonomy Media Source, depending on context. > > Perhaps it is ok if it is the union of these two, *if* it is clear how > they fit together and can be distinguished when need be. It would be > better if our term meant only one of these things. > > But either way, it is pretty unreasonable to use the *same* term > differently in the two documents. [CNG] I think the descriptions are correct. The "CLUE media capture" may be either a media capture or media source as described. Perhaps it can be easily fixed by calling cl.4.8 "CLUE Media Capture". > > I think one of use must change. I don't care which one. > > * The "Endpoint"/"End Point" is described in the taxonomy as follows: > > 4.5. Endpoint > > Telepresence specifications from CLUE WG use this term to describe > exactly one Participant (Section 2.2.3) and one or more End Points > (Section 2.2.1). > > 2.2.1. End Point > > Editor's note: Consider if a single word, "Endpoint", is > preferable > > A single addressable entity sending or receiving RTP packets. It may > be decomposed into several functional blocks, but as long as it > behaves as a single RTP stack entity it is classified as a single > "End Point". > > 2.2.3. Participant > > A Participant is an entity reachable by a single signaling address, > and is thus related more to the signaling context than to the media > context. > > Technically there is no conflict here because "Endpoint" and "End > Point" are different. But they are just different spelling, so easily > confused that it presents a problem. Also, there is the note that the > Taxonomy might want to change making them fully conflict. > > Again I think one of use must change. I don't care which one. [CNG] Again is it simply the case of pre-fixing 4.5 with "CLUE"? > > * MCU is described in the taxonomy as follows: > > 4.7. Multipoint Control Unit (MCU) > > This term is commonly used to describe the central node in any type > of star topology [I-D.ietf-avtcore-rtp-topologies-update] conference. > It describes a device that includes one Participant (Section 2.2.3) > (usually corresponding to a so-called conference focus) and one or > more related End Points (Section 2.2.1) (sometimes one or more per > conference participant). > > This is a quite good definition for CLUE purposes, except that this > definition does not assume CLUE support, while when we use MCU in CLUE > we mean something that is an MCU in the sense defined here *and* also > is a CLUE-Capable device as defined in the CLUE signaling draft. > > I think for this we should update the CLUE docs to use "CLUE MCU" > instead of just "MCU", and then define that with reference to this > definition. > > I'm hoping Jonathan can serve as a proxy for the taxonomy author team. > For now I'm only sending this to clue, not mmusic. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Mon Jul 21 07:34:47 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 855281A000D for ; Mon, 21 Jul 2014 07:34:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_27=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EZB19V94sPSb for ; Mon, 21 Jul 2014 07:34:43 -0700 (PDT) Received: from mail1.bemta7.messagelabs.com (mail1.bemta7.messagelabs.com [216.82.254.97]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B33C1A006D for ; Mon, 21 Jul 2014 07:34:40 -0700 (PDT) Received: from [216.82.254.19:16655] by server-1.bemta-7.messagelabs.com id 33/BC-28137-EF42DC35; Mon, 21 Jul 2014 14:34:38 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-5.tower-96.messagelabs.com!1405953268!18989072!2 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7031 invoked from network); 21 Jul 2014 14:34:34 -0000 Received: from crpehubprd01.polycom.com (HELO Crpehubprd01.polycom.com) (140.242.64.158) by server-5.tower-96.messagelabs.com with AES128-SHA encrypted SMTP; 21 Jul 2014 14:34:34 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by Crpehubprd01.polycom.com ([fe80::5efe:10.236.0.158%14]) with mapi; Mon, 21 Jul 2014 07:34:28 -0700 From: "Duckworth, Mark" To: "clue@ietf.org" Date: Mon, 21 Jul 2014 07:34:25 -0700 Thread-Topic: pre-WGLC comments on data model Thread-Index: Ac+k4ad4Z7SHhl3dTbO+VIcJItUtgg== Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B034@CRPMBOXPRD08.polycom.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B034CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7duw2Utacp77XQi2JobeFxuXwKY Subject: [clue] pre-WGLC comments on data model X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 14:34:46 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B034CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Comments on draft-ietf-clue-data-model-schema-06 Overall it is very good. I have mostly minor and editorial suggestions. T= here are still a few recent changes in the framework, and possible more com= ing, which we need to keep up to date in the data model. This set of comme= nts includes questions I raised in my email on June 27. >>>>> Major Issues: I thought we agreed should be optional, and some text and th= e XML for it needs to be updated. See the previous discussion here: http://www.ietf.org/mail-archive/web/clue/current/msg03594.html >>>>> Minor Issues: Is it possible to have a media capture type that is not video or audio or t= ext? Could it be done using just the mediaCaptureType generic element? Or= would there need to be a new element type that inherits from mediaCaptureT= ype? Is it worth mentioning this in the extensibility section? element - how about calling this something like = instead? Would this be better as an attribute rather than an element, lik= e the "mediaType" attribute for CSE in section 15.3? "simultaneousSetType" - the framework says "For shorthand convenience, a Pr= ovider MAY describe a Simultaneous Transmission Set in terms of Capture Sce= ne Entries and Capture Scenes". Looks like the data model allows using CSE= for shorthand, but not Capture Scenes. So should there be a "sceneIDREF" = element here? Also, as Paul noted in his review of the framework, there ne= eds to be a way to identify the media type for an STS if it includes only s= cenes. I suggest adding a (or ) element to the = simultaneousSetType, with the same meaning it has elsewhere. Then all the = media captures referenced in the STS must be of that media type. "captureEncodingType" - I agree with Christian it would be good to use "mm"= for millimeters in the schema. So the scaleType would have a line for enu= meration value=3D"mm" instead of value=3D"millimeters". "maxGroupBandwidth" - I think we should specify the units for this are bits= per second. The type is "xs:integer", but I think we should avoid using n= umeric types that don't have a range limit. How about using "xs:unsignedLo= ng" instead? "pointType" - I think we should avoid using numeric types that don't have a= range limit. How about using "xs:int" instead of "xs:decimal"? I was ass= uming we do not need to represent fractional millimeters here, I was always= assuming an int type. If people think we need to represent fractions, the= n should we use xs:float instead of xs:decimal? "sceneEntryType" - is the schema for this missing an attribute called "medi= aType"? This is described in section 15.3, but I don't see it in the schem= a. 10.4 paragraph 3 - it gives switched captures as an example of non spatiall= y definable, but the framework says "For a switched capture that switches b= etween different sections within a larger area, the area of capture MUST us= e coordinates for the larger potential area". So right now this looks like= a contradiction. I think the framework is correct though. 10.6 the text implies there must be some references to captures o= r CSEs, but the framework says "A MCC MAY contain no references to other Ca= ptures to indicate that the MCC contains content from multiple sources but = no information regarding those sources is given." The schema looks okay, a= s it has minOccurs=3D"0" for "captureIDREF" and "sceneEntryIDREF". And it = also has minOccurs=3D"0" for "content" in the media capture type in section= 10. So I think the schema is fine, but the text is wrong that says this s= tuff is mandatory. 10.7 - "...contain at each time captures coming from th= e same endpoint". I think it is more flexible than the same endpoint. The= framework says "It is the Provider that determines what the source for the= Captures is, so a Provider can choose how to group together Single Media C= aptures for the purpose of keeping them synchronized according to the Synch= ronisationID attribute." The provider is allowed flexibility in choosing h= ow to switch, even when it gives a syncID. For example, the provider might= decide to take video streams from three separate single camera endpoints a= nd switch them together to send to a consumer that receives three video str= eams simultaneously. audio captures - needs to be updated for recent decisions to remove audioCh= annelFormat, add the sensitivity pattern, and disallow area of capture. 21 - is the intent to remove this section, since an advertisemen= t is defined in the protocol document? 22 extensibility - is there a way to extend an enumerated type to include m= ore values? >>>>> Editorial Issues: The title page says "Intended status: Informational", but I think this shou= ld be Standards Track. 10.4 paragraph 3 "Capture of this kind are for example those related to reg= istrations..." I'm not sure what "registrations" means here. 10.6 has (MMCC), I think this should be (MCC) 10.15 "refers to my means..." should be "refers to by means" Regards, Mark --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B034CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Comments on draf= t-ietf-clue-data-model-schema-06

&n= bsp;

Overall it is very good.  I have mo= stly minor and editorial suggestions.  There are still a few recent ch= anges in the framework, and possible more coming, which we need to keep up = to date in the data model.  This set of comments includes questions I = raised in my email on June 27.

&nbs= p;

>>>>> Major Issues:

 

I tho= ught we agreed <capturePoint> should be optional, and some text and t= he XML for it needs to be updated.  See the previous discussion here:<= o:p>

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

 

 

>>>>> Minor Issues:

 

= Is it possible to have a media capture type that is not video or audio or t= ext?  Could it be done using just the mediaCaptureType generic element= ?  Or would there need to be a new element type that inherits from med= iaCaptureType?  Is it worth mentioning this in the extensibility secti= on?

 

<capturedMedia> element – how about calling this somethin= g like <mediaType> instead?  Would this be better as an attribut= e rather than an element, like the “mediaType” attribute for CS= E in section 15.3?

 

=

“simultaneousSetType” – the framewor= k says “For shorthand convenience, a Provider MAY describe a Simultan= eous Transmission Set in terms of Capture Scene Entries and Capture Scenes&= #8221;.  Looks like the data model allows using CSE for shorthand, but= not Capture Scenes.  So should there be a “sceneIDREF” el= ement here?  Also, as Paul noted in his review of the framework, there= needs to be a way to identify the media type for an STS if it includes onl= y scenes.  I suggest adding a <capturedMedia> (or <mediaType>) element to = the simultaneousSetType, with the same meaning it has elsewhere.  Then= all the media captures referenced in the STS must be of that media type.

 

“captureEncodingType” - I agree with Christian it would be goo= d to use “mm” for millimeters in the schema.  So the scale= Type would have a line for enumeration value=3D”mm” instead of = value=3D”millimeters”.

=  

“maxGroupBandwidth” –= ; I think we should specify the units for this are bits per second.  T= he type is “xs:integer”, but I think we should avoid using nume= ric types that don’t have a range limit.  How about using “= ;xs:unsignedLong” instead?

&n= bsp;

“pointType” - I think we sho= uld avoid using numeric types that don’t have a range limit.  Ho= w about using “xs:int” instead of “xs:decimal”?&nbs= p; I was assuming we do not need to represent fractional millimeters here, = I was always assuming an int type.  If people think we need to represe= nt fractions, then should we use xs:float instead of xs:decimal?=

 

“s= ceneEntryType” – is the schema for this missing an attribute ca= lled “mediaType”?  This is described in section 15.3, but = I don’t see it in the schema.

 

10.4 paragraph 3 – it gives swi= tched captures as an example of non spatially definable, but the framework = says “For a switched capture that switches between different sections= within a larger area, the area of capture MUST use coordinates for the lar= ger potential area”.  So right now this looks like a contradicti= on.  I think the framework is correct though.

 

10.6 <content>= the text implies there must be some references to captures or CSEs, but th= e framework says “A MCC MAY contain no references to other Captures t= o indicate that the MCC contains content from multiple sources but no infor= mation regarding those sources is given.”  The schema looks okay= , as it has minOccurs=3D”0” for “captureIDREF” and = “sceneEntryIDREF”.  And it also has minOccurs=3D”0&#= 8221; for “content” in the media capture type in section 10.&nb= sp; So I think the schema is fine, but the text is wrong that says this stu= ff is mandatory.

 

10.7 <synchronizationID> - “...contain at ea= ch time captures coming from the same endpoint”.  I think it is = more flexible than the same endpoint.  The framework says “It is= the Provider that determines what the source for the Captures is, so a Pro= vider can choose how to group together Single Media Captures for the purpos= e of keeping them synchronized according to the SynchronisationID attribute= .”  The provider is allowed flexibility in choosing how to switc= h, even when it gives a syncID.  For example, the provider might decid= e to take video streams from three separate single camera endpoints and swi= tch them together to send to a consumer that receives three video streams s= imultaneously.

 

audio captures – needs to be updated for recent deci= sions to remove audioChannelFormat, add the sensitivity pattern, and disall= ow area of capture.

 

21 <clueInfo> - is the intent to remove this se= ction, since an advertisement is defined in the protocol document?

 

22 ext= ensibility – is there a way to extend an enumerated type to include m= ore values?

 

>>>>> Editorial Issues:

 

The title page says = “Intended status: Informational”, but I think this should be St= andards Track.

 

10.4 paragraph 3 “Capture of this kind are for examp= le those related to registrations...”  I’m not sure what &= #8220;registrations” means here.

<= o:p> 

10.6 has (MMCC), I think this shou= ld be (MCC)

 

10.15 “refers to my means...” should be “re= fers to by means”

 

Regards,

Mark<= o:p>

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B034CRPMBOXPRD08p_-- From nobody Mon Jul 21 10:41:26 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71CA1A00F1 for ; Mon, 21 Jul 2014 10:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB-2mFmS10tg for ; Mon, 21 Jul 2014 10:41:16 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C37B51A01E6 for ; Mon, 21 Jul 2014 10:41:15 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id w61so7975310wes.9 for ; Mon, 21 Jul 2014 10:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=85rlX/8iZ6yFUJz0dzutHfJ3YLCoCM7XxqLxmT8kBTM=; b=gUpT/PBxlrKW5vdhj2hO8NMAao/72DD9sJxL/3skLpaS0lE63zIJlu6OrGudgUO/se hbIUMhejzdTygVYL+I7B3kfa2KgSvGW3crCta5+ei+C0IAN7Slm8wib9FA9FMfbGGTdx 2Kqqx/TBYWddXN5fs1M+DB+zucp/jLo6ZuXa/wJhIxjWY/C4fChQsos/qlNU0TXb8rXH wKIl1TrF02WbEmIu5YUy7pwcm61R9GC4cIqzoKJO6Ni9XqVGbNzPbcuembGdTbOjarOZ Fr3h84Di+08kxkqwB+CEZXxEYE5hQDSuUU63pgLQPopOQoUsWQv4TaxX1V3khxWc1uE/ 11/A== MIME-Version: 1.0 X-Received: by 10.180.81.234 with SMTP id d10mr6471514wiy.79.1405964474087; Mon, 21 Jul 2014 10:41:14 -0700 (PDT) Received: by 10.216.222.67 with HTTP; Mon, 21 Jul 2014 10:41:13 -0700 (PDT) In-Reply-To: <53CC6CC3.2080604@alum.mit.edu> References: <53C99B30.8070207@alum.mit.edu> <53CC6CC3.2080604@alum.mit.edu> Date: Mon, 21 Jul 2014 12:41:13 -0500 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=f46d044281340b830a04feb79db0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/3MoQ_ZSeDUWTAfrf6_heLemCJ4k Cc: CLUE Subject: Re: [clue] CLUE dinner poll X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:41:22 -0000 --f46d044281340b830a04feb79db0 Content-Type: text/plain; charset=UTF-8 I won't be able to join you all. It was Wednesday where I might have been able to come later. Thanks, Mary On Sun, Jul 20, 2014 at 8:28 PM, Paul Kyzivat wrote: > So far we have only four people expressing interest. They can all make it > Monday, and only 3 on Wed. And Mary said she might be able to show up late > on monday. > > So I'm going to call it for 8pm on Monday. I'll have to find a place. I'll > try to reserve a few extra seats in case somebody else wants to sign up. > > I'll inform about the location tomorrow. > > Thanks, > Paul > > > On 7/18/14 6:09 PM, Paul Kyzivat wrote: > >> Folks - Here is link to doodle poll for a CLUE dinner next week. >> >> http://doodle.com/ga867gf7xa8w3u5m#table >> >> I have *not* investigated where we might go. (Our social directory has >> been occupied with more interesting things.) >> >> Once a preferred night is clear I'll see what I can find. If anyone has >> suggestions, please speak up. (You could put comments in the poll.) I'm >> not a noted gourmet, and I'm not allergic to any foods that I know of, >> so left to my own devices I might not make a great choice. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> >> > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --f46d044281340b830a04feb79db0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I won't be able to join you all. It was Wednesday wher= e I might have been able to come later.

Thanks,
Mary


On Sun, Jul 20, 2014 at 8:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
So far we have only four people expressing interest. They can all make it M= onday, and only 3 on Wed. And Mary said she might be able to show up late o= n monday.

So I'm going to call it for 8pm on Monday. I'll have to find a plac= e. I'll try to reserve a few extra seats in case somebody else wants to= sign up.

I'll inform about the location tomorrow.

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

On 7/18/14 6:09 PM, Paul Kyzivat wrote:
Folks - Here is link to doodle poll for a CLUE dinner next week.

http= ://doodle.com/ga867gf7xa8w3u5m#table

I have *not* investigated where we might go. (Our social directory has
been occupied with more interesting things.)

Once a preferred night is clear I'll see what I can find. If anyone has=
suggestions, please speak up. (You could put comments in the poll.) I'm=
not a noted gourmet, and I'm not allergic to any foods that I know of,<= br> so left to my own devices I might not make a great choice.

=C2=A0 =C2=A0 =C2=A0Thanks,
=C2=A0 =C2=A0 =C2=A0Paul

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


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

--f46d044281340b830a04feb79db0-- From nobody Mon Jul 21 10:55:35 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 902C91A02A0 for ; Mon, 21 Jul 2014 10:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.021 X-Spam-Level: X-Spam-Status: No, score=-0.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuIee57DDPHz for ; Mon, 21 Jul 2014 10:55:30 -0700 (PDT) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403BC1A0275 for ; Mon, 21 Jul 2014 10:55:30 -0700 (PDT) X-ASG-Debug-ID: 1405965327-05f2753c1cee71d0001-dOUo1C Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id pWlTeKJoQfOEQwcI (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 19:55:27 +0200 (CEST) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from dhcp-8403.meeting.ietf.org (dhcp-8403.meeting.ietf.org [31.133.132.3]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id s6LHtOWd014999 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Jul 2014 19:55:26 +0200 Content-Type: multipart/alternative; boundary="Apple-Mail=_E6A48C45-3442-43AA-AE00-F36D684E1DD3" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\)) From: Simon Pietro Romano X-ASG-Orig-Subj: Re: [clue] CLUE dinner poll In-Reply-To: Date: Mon, 21 Jul 2014 19:55:23 +0200 Message-Id: References: <53C99B30.8070207@alum.mit.edu> <53CC6CC3.2080604@alum.mit.edu> To: Mary Barnes X-Mailer: Apple Mail (2.1878.2) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1405965327 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi Received-SPF: softfail (unina.it: domain of transitioning spromano@unina.it does not designate 31.133.132.3 as permitted sender) X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Bayes: INNOCENT GLOBAL 0.0000 1.0000 -2.0210 X-Barracuda-Spam-Score: -2.02 X-Barracuda-Spam-Status: No, SCORE=-2.02 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SPF_SOFTFAIL, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.7686 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 HTML_MESSAGE BODY: HTML included in message 0.00 BSF_SPF_SOFTFAIL Custom Rule SPF Softfail Archived-At: http://mailarchive.ietf.org/arch/msg/clue/an3h_CUuFkaNLFmVLex7PFwkPuU Cc: CLUE Subject: Re: [clue] CLUE dinner poll X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 17:55:33 -0000 --Apple-Mail=_E6A48C45-3442-43AA-AE00-F36D684E1DD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Sorry guys, I cannot make it for tonight's dinner, either. Will join you next time! Simon On 21/lug/2014, at 19:41, Mary Barnes wrote: > I won't be able to join you all. It was Wednesday where I might have been= able to come later. >=20 > Thanks, > Mary >=20 >=20 > On Sun, Jul 20, 2014 at 8:28 PM, Paul Kyzivat wro= te: > So far we have only four people expressing interest. They can all make it= Monday, and only 3 on Wed. And Mary said she might be able to show up late= on monday. >=20 > So I'm going to call it for 8pm on Monday. I'll have to find a place. I'l= l try to reserve a few extra seats in case somebody else wants to sign up. >=20 > I'll inform about the location tomorrow. >=20 > Thanks, > Paul >=20 >=20 > On 7/18/14 6:09 PM, Paul Kyzivat wrote: > Folks - Here is link to doodle poll for a CLUE dinner next week. >=20 > http://doodle.com/ga867gf7xa8w3u5m#table >=20 > I have *not* investigated where we might go. (Our social directory has > been occupied with more interesting things.) >=20 > Once a preferred night is clear I'll see what I can find. If anyone has > suggestions, please speak up. (You could put comments in the poll.) I'm > not a noted gourmet, and I'm not allergic to any foods that I know of, > so left to my own devices I might not make a great choice. >=20 > Thanks, > Paul >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue >=20 > _______________________________________________ > 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~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( ( ) \_) ) / (_/ ----=0D 5x1000 AI GIOVANI RICERCATORI=0D DELL'UNIVERSIT=C0 DI NAPOLI=0D Codice Fiscale: 00876220633=0D www.unina.it/Vademecum5permille=0D --Apple-Mail=_E6A48C45-3442-43AA-AE00-F36D684E1DD3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Sorry guys,

I cannot make it for tonight's dinner, either. Will join you next ti= me!

Simon


O= n 21/lug/2014, at 19:41, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:

I won't = be able to join you all. It was Wednesday where I might have been able to c= ome later.

Thanks,
Mary


On Sun, Jul 20, 2014 at 8:28 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
So far we have only four people expressing interest. They can all make it M= onday, and only 3 on Wed. And Mary said she might be able to show up late o= n monday.

So I'm going to call it for 8pm on Monday. I'll have to find a place. I'll = try to reserve a few extra seats in case somebody else wants to sign up.

I'll inform about the location tomorrow.

        Thanks,
        Paul


On 7/18/14 6:09 PM, Paul Kyzivat wrote:
Folks - Here is link to doodle poll for a CLUE dinner next week.

http= ://doodle.com/ga867gf7xa8w3u5m#table

I have *not* investigated where we might go. (Our social directory has
been occupied with more interesting things.)

Once a preferred night is clear I'll see what I can find. If anyone has
suggestions, please speak up. (You could put comments in the poll.) I'm
not a noted gourmet, and I'm not allergic to any foods that I know of,
so left to my own devices I might not make a great choice.

     Thanks,
     Paul

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


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

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

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

    <<Molti mi dicono che lo scoraggiamento =E8 l'alibi d= egli 
    idioti. Ci rifletto un istante; e mi scor= aggio>>. Magritte.
          =          &= nbsp;                oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~= ~~~~
=                  \= (            (   )
    &= nbsp;                    =         \_)          ) /
                   =                     &nbs= p;                     &n= bsp;        (_/

=







----
=0D 5x1000 AI GIOVANI=0D RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice Fiscale:=0D 00876220633
www.unina.it= /Vademecum5permille

  ­­  = --Apple-Mail=_E6A48C45-3442-43AA-AE00-F36D684E1DD3-- From nobody Mon Jul 21 12:15:49 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61EA71A03C6 for ; Mon, 21 Jul 2014 12:15:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YsyGaRdNhlxO for ; Mon, 21 Jul 2014 12:15:47 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id F3CEC1A03C8 for ; Mon, 21 Jul 2014 12:15:46 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id V5fc1o0040ldTLk5E7Fm16; Mon, 21 Jul 2014 19:15:46 +0000 Received: from dhcp-a479.meeting.ietf.org ([31.133.164.121]) by omta04.westchester.pa.mail.comcast.net with comcast id V7DM1o00Z2dUFrz017DQ49; Mon, 21 Jul 2014 19:13:37 +0000 Message-ID: <53CD6650.7090803@alum.mit.edu> Date: Mon, 21 Jul 2014 15:13:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "mark.duckworth@polycom.com" , Jonathan Lennox , Paul Coverdale References: <53C99B30.8070207@alum.mit.edu> <53CC6CC3.2080604@alum.mit.edu> In-Reply-To: <53CC6CC3.2080604@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1405970146; bh=Tq+O8e8L56388wL7G3JkWLyGveSkO3J0qumDrWqc7PA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=uthi355k+llbR77Cx1bgv3uT83cgO+FzQ5j10mS+0EYGp2e1LSOi/126DgBH/P0zG oR3/vjaQ4MY6MsyTGH1sjvy9Pvj+9kGf44DOvjsMU5ngbw6InAF1QkkOauJ5gPO1eT gGroYNGoo9VSDb4T6jN40M9LDM5fQT19maYKfhSnZQAMK0XPsbwuB58err1/v6iFQa 7J5lEg51eR0XPEkjbH8AeEmNBWKP1wxbzwgtf6QVDfKyOKXfpMuOX1Zx+Gf8zAv+4s z66wJoBepOivqHPoLjeWxzNUsSq1/pGDF3C8gdB9raNmKY8DkHXKST0s5G8x8TntE7 zEL3mBuCwKrzA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/e1NISQYqK7AjvFlLBfHvTleDj_E Cc: clue@ietf.org Subject: [clue] CLUE dinner Monday at 8 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 19:15:48 -0000 We only have four signups. I've booked space for six at Oliver & Bondacini, and 33 Yonge Street, corner of Front, at 8pm tonight. Please confirm if you want one of the other two spots. People who want to walk together can assemble in the hotel lobby, somewhere around the registration desk. I figure 7:45 departure from the hotel. Thanks, Paul On 7/20/14 9:28 PM, Paul Kyzivat wrote: > So far we have only four people expressing interest. They can all make > it Monday, and only 3 on Wed. And Mary said she might be able to show up > late on monday. > > So I'm going to call it for 8pm on Monday. I'll have to find a place. > I'll try to reserve a few extra seats in case somebody else wants to > sign up. > > I'll inform about the location tomorrow. > > Thanks, > Paul > > On 7/18/14 6:09 PM, Paul Kyzivat wrote: >> Folks - Here is link to doodle poll for a CLUE dinner next week. >> >> http://doodle.com/ga867gf7xa8w3u5m#table >> >> I have *not* investigated where we might go. (Our social directory has >> been occupied with more interesting things.) >> >> Once a preferred night is clear I'll see what I can find. If anyone has >> suggestions, please speak up. (You could put comments in the poll.) I'm >> not a noted gourmet, and I'm not allergic to any foods that I know of, >> so left to my own devices I might not make a great choice. >> >> Thanks, >> Paul >> >> _______________________________________________ >> clue mailing list >> clue@ietf.org >> https://www.ietf.org/mailman/listinfo/clue >> > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Tue Jul 22 05:44:19 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29F051A0AF8 for ; Tue, 22 Jul 2014 05:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QvjT3W2NnSR3 for ; Tue, 22 Jul 2014 05:44:15 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4926A1A0AFD for ; Tue, 22 Jul 2014 05:44:08 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so5924795wiw.6 for ; Tue, 22 Jul 2014 05:44:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=UjBmPxbSxu4FNu1xosCrVkEUfHK3QmAqcI3M7MSs7KQ=; b=PvVhn5oqpfA6M6k3wsU9ZdubqqU9DnIJvceF5meXyyUry//iOxFB3HDo8VaJ/Gxvtv blL4si3na3BUhjy/gCNBMaLpSKz9oCI6kzyOacZPoIvnAPgpTScDB4SbUvQRePvfPiSn TkDf6oMdyEsnrRAtvq2aAWTO3SB0lqRlzraJAfECFoCZMAgVeo0iz+WQxJNMvc3I5PA3 h400ZPT2A/iVyA+YuqaGmOezknVUBnd8Rmsy4VBf5wxmWRpPLTsIy+BdB0Ec7DMumVAY 0zrZS+ht2HninWnWIvcImoPjRaJ+v+N4lnMoJFj68GfLWJTfty1ywVVAaK+9NTOoZnwi 8HPw== MIME-Version: 1.0 X-Received: by 10.194.179.4 with SMTP id dc4mr33284251wjc.32.1406033046883; Tue, 22 Jul 2014 05:44:06 -0700 (PDT) Received: by 10.216.222.67 with HTTP; Tue, 22 Jul 2014 05:44:06 -0700 (PDT) Date: Tue, 22 Jul 2014 07:44:06 -0500 Message-ID: From: Mary Barnes To: CLUE Content-Type: multipart/alternative; boundary=089e013d115e4d54b804fec794d0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7QGHUibo07M2q4EJUZLHHTmQYRY Cc: "Alissa Cooper \(alcoop\)" Subject: [clue] Terminology X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 12:44:16 -0000 --089e013d115e4d54b804fec794d0 Content-Type: text/plain; charset=UTF-8 Hi all, Given the concerns raised that there wasn't true consensus during the call for consensus on "referencing" draft-ietf-avtext-rtp-grouping-taxonomy, we'd like to keep the discussion open for a few weeks. Other than the information on slide 7 of Mark's presentation, the discussion was rather theoretical. Thus, the proposal is that people review the framework document for an eye for terms that could lead to a misunderstanding of the CLUE framework. If people can identify specific text in the document and explain why they believe the term used in the CLUE document is misleading, then we can discuss each instance and determine if the WG agrees that we need to make changes. It is *really* important for people to keep in mind that the critical deliverables for the WG at this point are the solution documents. If the terminology doesn't lead to errors in the protocol or misunderstanding of the solution details, then do we really have a problem? Given how far along we are with the framework and the planned WGLC in 5 weeks time, the deadline for identifying specific text/terms in the CLUE framework that are problematic is August 14, 2014. Regards, Mary as WG co-chair --089e013d115e4d54b804fec794d0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi all,


Given the concerns raised that there wasn't true consensus during the c= all for consensus on "referencing"=C2=A0draft-ietf-avtext-rtp-gro= uping-taxonomy, we'd like to keep the discussion open for a few weeks.= =C2=A0=C2=A0Other than the information on slide 7=C2=A0of Mark's presen= tation, the discussion was rather theoretical.=C2=A0 Thus, the proposal is = that people review the framework document for an eye for terms that could l= ead to a misunderstanding of the CLUE framework. =C2=A0=C2=A0


If people= can identify specific text in the document and explain why they believe th= e term used in the CLUE document is misleading, then we can discuss each in= stance and determine if the WG agrees that we need to make changes.=C2=A0


<= p style=3D"margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica">It is *rea= lly* important for people to keep in mind that the critical deliverables fo= r the WG at this point are the solution documents. =C2=A0If the terminology= doesn't lead to errors in the protocol or misunderstanding of the solu= tion details, then do we really have a problem? =C2=A0


<= /p>

Given how= far along we are with the framework and the planned WGLC in 5 weeks time,= =C2=A0 the deadline for identifying specific text/terms in the CLUE framewo= rk that are problematic is August 14, 2014. =C2=A0


<= p style=3D"margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica">Regards,

Mary

as WG co-chair

--089e013d115e4d54b804fec794d0-- From nobody Tue Jul 22 06:51:00 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A781B286E; Tue, 22 Jul 2014 06:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I8TFW3-nOyxD; Tue, 22 Jul 2014 06:50:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A87331B284B; Tue, 22 Jul 2014 06:50:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.1.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140722135051.17260.70318.idtracker@ietfa.amsl.com> Date: Tue, 22 Jul 2014 06:50:51 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/PXaIuGt_NsVA-G3Jf296Qe_Rt_w Cc: clue@ietf.org Subject: [clue] I-D Action: draft-ietf-clue-rtp-mapping-02.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2014 13:50:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF. Title : Mapping RTP streams to CLUE media captures Authors : Roni Even Jonathan Lennox Filename : draft-ietf-clue-rtp-mapping-02.txt Pages : 17 Date : 2014-07-22 Abstract: This document describes mechanisms and recommended practice for mapping RTP media streams defined in SDP to CLUE media captures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-clue-rtp-mapping/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-clue-rtp-mapping-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-rtp-mapping-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jul 23 18:07:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0B141A03C0 for ; Wed, 23 Jul 2014 18:07:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KTRrfJBYii6A for ; Wed, 23 Jul 2014 18:07:06 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCA521A03F2 for ; Wed, 23 Jul 2014 18:07:05 -0700 (PDT) Received: from ppp118-209-74-250.lns20.mel4.internode.on.net ([118.209.74.250]:52431 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XA7Uo-0003K3-SM for clue@ietf.org; Thu, 24 Jul 2014 11:06:58 +1000 Message-ID: <53D05C32.8080500@nteczone.com> Date: Thu, 24 Jul 2014 11:06:58 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: "clue@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Z3BO0ykYkdTopbqwxu-DcHHZIuk Subject: [clue] READV X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 01:07:11 -0000 Hello I heard that there were some discussions at the meeting regarding the READV and in particular questions: 1. Do we need a separate READV response message to carry the CLUE data? 2. Couldn't the READV simply trigger the MP to send an ADV? It seems that the answer at the meeting to 1 was "Yes" and the answer to 2 was "No". Can anyone give some background / reasons for those answers? Is there some fundamental issue with using the READV as a trigger rather having to send CLUE Advertisement data in the READV response? The state machines in the protocol draft appear to use ADV in response to a READV. Regards, Christian From nobody Thu Jul 24 08:39:48 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8081A02D6 for ; Thu, 24 Jul 2014 08:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecCSFmjWa9zi for ; Thu, 24 Jul 2014 08:39:39 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id 79A8C1A01FF for ; Thu, 24 Jul 2014 08:39:39 -0700 (PDT) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta15.westchester.pa.mail.comcast.net with comcast id WELd1o0061c6gX85FFffxW; Thu, 24 Jul 2014 15:39:39 +0000 Received: from dhcp-90b7.meeting.ietf.org ([31.133.144.183]) by omta23.westchester.pa.mail.comcast.net with comcast id WFdX1o00D3xdsjB3jFdZao; Thu, 24 Jul 2014 15:37:37 +0000 Message-ID: <53D1283B.604@alum.mit.edu> Date: Thu, 24 Jul 2014 11:37:31 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53B0ADDC.5060706@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> <53C996E2.8080209@alum.mit.edu> <53CC9B66.60105@nteczone.com> In-Reply-To: <53CC9B66.60105@nteczone.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406216379; bh=n7hUGYyNzJaGr38xtSfYuzN3BA7+4ep2/XJDsr1BKOk=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Ygv8TnDCFZZrgJxMpLlewgBeVSoj8oCylEU1IUkAmYhrJ5qNTy428gugIMHY8S4dw RuLI3PMRqQkiUUMXYp5jxSXmhuK0ACcGx5Nc/R1swBeyiK1q7tRSpOmTqkyV9kb0u4 smNS1QhlcoTJk6XSiYGxrxSkGO4KHomM06E/CLTMBAFXjz1rNO0tlBUR6oAaHqpa7z kFDvphrKwl3fjOiXpHyOBzov0xFLGLoqenppJl7XS2/q7+JIBjwmQ9b8TnPckCCceU Cj7FH93nH7svoPtGHgTRfeOgV34tbaiV81wWac5hkV5us+unKtKZv4O/KDJNIT2gWF vIurrHlBvLbhA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/GVL7kZzjFolpfEaM5jxta5GmPiY Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 15:39:45 -0000 Inline On 7/21/14 12:47 AM, Christian Groves wrote: > Hello Mark and Paul, > > A few comments. > > Regards, Christian > > On 19/07/2014 7:51 AM, Paul Kyzivat wrote: >> ..snip.. >>>> Section 7.1.1.3: >>>> >>>> I guess some restructuring is needed to limit area of capture to video. >>> [Duckworth, Mark] Does area of capture apply only to video? Or can >>> it apply to any media type other than audio? framework-16 simply >>> says it does not apply to audio. >> >> Well, what types of media do we currently know of: audio, video, text. >> >> area of capture applies to video, not audio. >> >> What about text? I don't think so. *Maybe* point of capture applies. >> (Center of the keyboard?) >> >> Does axis of capture apply to text? I don't think so. >> >> So I think each type of media has distinct geometric attributes that >> describe it. >> >> What would we use for smell? (Actually it may be similar to audio.) > [CNG] Maybe we should just focus on video? We can always add an extra > attributes for other media types if they become necessary. My point here was to distinguish things that are defined generically for all captures from those that are defined specifically for a particular type of capture. The question is whether there are any spatial attributes that are generic. If not (and AFAIK that seems to be the case) then we pick and choose for each type. Audio and Video can both choose to include point of capture and axis of capture. Video also includes area of capture. What is appropriate for text is unclear - maybe none, maybe point of capture but not axis. >> ..snip.. >>> >>>> Section 7.2.1.2: >>>> >>>> The explanation of 'index' is pretty fuzzy. ISTM that the meaning >>>> really needs >>>> to be specified separately for each token. E.g., for SoundLevel N >>>> means the >>>> N'th most recent loudest speaker. For RoundRobin it is harder to >>>> describe. >>> [Duckworth, Mark] Makes sense for SoundLevel. Do we want to have an >>> index for RoundRobin? I suppose it could make sense there too. But >>> I think the current definition of the index is adequate. >> >> I suspect there is a reason to have have an index for each kind. But >> what that index *means* has to be defined separately for each kind. > [CNG] I don't see we need to define the index per kind. The index is the > n x last speaker, no matter the kind. I can't see the concern with round > robin here? IIUC, with round robin who is speaking is irrelevant to switching, so the index can't mean n x last speaker. I *guess* that for round robin the alternatives are arranged in a sequence (the same sequence used in the MCC?) containing captures C(0)...C(N-1). Then we can imagine an integer cursor K that is periodically incremented modulo N. With that in place, then RoundRobin X identifies capture C( (K+X) mod N ). My point is that defining what the index means for RoundRobin requires something like that. (There may be an easier way to describe it.) Thinking more, maybe you can say that each switching policy defines a sequence of choices from among the candidates. And then index 0 means the most recent choice from the sequence, while index I selects prior choices from that sequence. Thanks, Paul From nobody Thu Jul 24 10:58:08 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FC871ABB2B for ; Thu, 24 Jul 2014 10:57:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4mm8Xlh4Wg20 for ; Thu, 24 Jul 2014 10:57:49 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1E21AD6B0 for ; Thu, 24 Jul 2014 10:57:25 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so4489989wiv.3 for ; Thu, 24 Jul 2014 10:57:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version:content-type :thread-index:content-language; bh=XO6nwa6nqISxCWcOMytaQsoaj5X9oAhnYUDLVcHs/rA=; b=OClDRK+rjUOCBSPk5zpGBy3SMLYRDvLHSXKbKAfI7ZiPzkehBCCjC4JucPqC3uGHC1 ZA3wC6WBvgNXXof94caxUO0JLdNjQDabiidr8HdJkjf4MZmsQdkhbi728iu1cogFs82P tgpEir6SDCpeBKHirV659PasZmKx4G7C/QTQjn2d/62MFlHk7AT2i/KjbWthUFrZxN4d JfX92AEgcD+mnbLOcpCfz3Y91vrrDdha6MC/WW8x3lpLRkpINnUyGcMwuauZPsf3r+m8 gVM3BGTY01Y/gqsjoUS1cz3J7t3BGiI0jRb0htAtuls+gXOFbEzeBqdJwN/4mKl3qrlX yCfw== X-Received: by 10.180.10.232 with SMTP id l8mr6595091wib.30.1406224644171; Thu, 24 Jul 2014 10:57:24 -0700 (PDT) Received: from RoniE ([2001:67c:370:160:1cad:6376:8898:432c]) by mx.google.com with ESMTPSA id hp6sm25359100wib.23.2014.07.24.10.57.22 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Jul 2014 10:57:23 -0700 (PDT) From: "Roni Even" To: Date: Thu, 24 Jul 2014 20:57:21 +0300 Message-ID: <010201cfa768$b8724e50$2956eaf0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0103_01CFA781.DDBFD470" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac+naECRBCGSxMsXQfCvJH7LhVWGpQ== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ly2-r605ZKo_w_ftU4jwCkkUFJY Subject: [clue] framewaor audio example section 12.1.1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 17:57:56 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0103_01CFA781.DDBFD470 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, The coordinate for audio are correct but seems weird. The line of capture goes down from the microphone to the camera, this will mean that it will go up in the other direction towards the room. I think that having the same z coordinate to the point of capture and point on the line of capture will make more sense Roni ------=_NextPart_000_0103_01CFA781.DDBFD470 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

The coordinate = for audio are correct but seems weird. The line of capture goes down = from the microphone to the camera, this will mean that it will go up in = the other direction towards the room. I think that having the same z = coordinate to the point of capture and point on the line of capture will = make more sense

Roni

------=_NextPart_000_0103_01CFA781.DDBFD470-- From nobody Thu Jul 24 11:38:21 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041311B27D9 for ; Thu, 24 Jul 2014 11:38:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N1IOeEPe_Nfe for ; Thu, 24 Jul 2014 11:38:19 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) by ietfa.amsl.com (Postfix) with ESMTP id BD12A1B27F0 for ; Thu, 24 Jul 2014 11:38:13 -0700 (PDT) Received: from xct101cnc.rim.net ([10.65.161.201]) by mhs210cnc.rim.net with ESMTP/TLS/AES128-SHA; 24 Jul 2014 14:38:14 -0400 Received: from XMB122CNC.rim.net ([fe80::28c6:fa1c:91c6:2e23]) by XCT101CNC.rim.net ([fe80::9c22:d9c:c906:c488%16]) with mapi id 14.03.0174.001; Thu, 24 Jul 2014 14:38:12 -0400 From: Andrew Allen To: "clue@ietf.org" Thread-Topic: Question on relationship between Clue protocol SDP negotiation and RFC 5688 Thread-Index: Ac+nbeJTS3AYwjuOQcCJVTK5LS7b7A== Date: Thu, 24 Jul 2014 18:38:12 +0000 Message-ID: Accept-Language: en-CA, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.249] Content-Type: multipart/alternative; boundary="_000_BBF5DDFE515C3946BC18D733B20DAD233990F850XMB122CNCrimnet_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/xAMNbkaGyqvF4ABBA7nzCfJTHi4 Subject: [clue] Question on relationship between Clue protocol SDP negotiation and RFC 5688 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jul 2014 18:38:21 -0000 --_000_BBF5DDFE515C3946BC18D733B20DAD233990F850XMB122CNCrimnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable One issue I have been struggling with is understanding what should be popul= ated in the sip.app-tsubype media feature tag defined in RFC 5688. Ideally IMHO this should indicate the support for the clue channel media t= ype but it is not clear to me from RFC 5688 and the clue drafts that this w= ill be what most implementers would populate. Maybe this should be clarifie= d in CLUE. Andrew --_000_BBF5DDFE515C3946BC18D733B20DAD233990F850XMB122CNCrimnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

One issue I have been struggling with is understandi= ng what should be populated in the sip.app-tsubype media feature tag define= d in RFC 5688.

 

Ideally IMHO  this should indicate the support = for the clue channel media type but it is not clear to me from RFC 5688 and= the clue drafts that this will be what most implementers would populate. M= aybe this should be clarified in CLUE.

 

Andrew

--_000_BBF5DDFE515C3946BC18D733B20DAD233990F850XMB122CNCrimnet_-- From nobody Thu Jul 24 17:21:59 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07F2E1A0A9E for ; Thu, 24 Jul 2014 17:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcmGzj4SHM4A for ; Thu, 24 Jul 2014 17:21:55 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C017A1A055D for ; Thu, 24 Jul 2014 17:21:54 -0700 (PDT) Received: from ppp118-209-150-128.lns20.mel6.internode.on.net ([118.209.150.128]:57766 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XATGQ-00024I-V2 for clue@ietf.org; Fri, 25 Jul 2014 10:21:35 +1000 Message-ID: <53D1A31A.2070206@nteczone.com> Date: Fri, 25 Jul 2014 10:21:46 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <53B0ADDC.5060706@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> <53C996E2.8080209@alum.mit.edu> <53CC9B66.60105@nteczone.com> <53D1283B.604@alum.mit.edu> In-Reply-To: <53D1283B.604@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/12LLdSH5v6BYVAH4S27OQYj_qVs Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 00:21:57 -0000 Hello Paul, I don't see the complexity in round robin. Even in round robin there will be the active site, then the previously active site is the last speaker, the previously active site to that is the n x last speaker, etc. So if site A has index 0, when site B is selected as has index 0 then site A will have index 1. I don't think we need to go into mathematical definitions for this nor specific behaviour for each type of queue. I think the concept of current instance and prior instance/s is a generic enough concept. The current text from the draft is: An index is used to represent an instance in the policy setting. A index of 0 represents the most current instance of the policy, i.e. the active speaker, 1 represents the previous instance, i.e. the previous active speaker and so on. It already talks about "instances" rather than "speakers" so I can't really see the issue. Regards, Christian >>> ..snip.. >>>> >>>>> Section 7.2.1.2: >>>>> >>>>> The explanation of 'index' is pretty fuzzy. ISTM that the meaning >>>>> really needs >>>>> to be specified separately for each token. E.g., for SoundLevel N >>>>> means the >>>>> N'th most recent loudest speaker. For RoundRobin it is harder to >>>>> describe. >>>> [Duckworth, Mark] Makes sense for SoundLevel. Do we want to have an >>>> index for RoundRobin? I suppose it could make sense there too. But >>>> I think the current definition of the index is adequate. >>> >>> I suspect there is a reason to have have an index for each kind. But >>> what that index *means* has to be defined separately for each kind. >> [CNG] I don't see we need to define the index per kind. The index is the >> n x last speaker, no matter the kind. I can't see the concern with round >> robin here? > > IIUC, with round robin who is speaking is irrelevant to switching, so > the index can't mean n x last speaker. > > I *guess* that for round robin the alternatives are arranged in a > sequence (the same sequence used in the MCC?) containing captures > C(0)...C(N-1). Then we can imagine an integer cursor K that is > periodically incremented modulo N. With that in place, then RoundRobin > X identifies capture C( (K+X) mod N ). > > My point is that defining what the index means for RoundRobin requires > something like that. (There may be an easier way to describe it.) > > Thinking more, maybe you can say that each switching policy defines a > sequence of choices from among the candidates. And then index 0 means > the most recent choice from the sequence, while index I selects prior > choices from that sequence. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > From nobody Thu Jul 24 20:29:25 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07131A058E for ; Thu, 24 Jul 2014 20:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XcQyzzxmr60K for ; Thu, 24 Jul 2014 20:29:22 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEDF21A0538 for ; Thu, 24 Jul 2014 20:29:21 -0700 (PDT) Received: from ppp118-209-150-128.lns20.mel6.internode.on.net ([118.209.150.128]:61018 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAWBo-00050F-LK for clue@ietf.org; Fri, 25 Jul 2014 13:29:00 +1000 Message-ID: <53D1CF09.5090505@nteczone.com> Date: Fri, 25 Jul 2014 13:29:13 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/722oC64h4PDMpPgyIJ2mVqumCjE Subject: Re: [clue] Question on relationship between Clue protocol SDP negotiation and RFC 5688 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 03:29:23 -0000 In clause 3 of draft-ietf-clue-signaling-02 it defines a media feature tag "sip.clue". Would we need to populate a sip.app-subtype beyond that? Regards, Christian On 25/07/2014 4:38 AM, Andrew Allen wrote: > > One issue I have been struggling with is understanding what should be > populated in the sip.app-tsubype media feature tag defined in RFC 5688. > > Ideally IMHO this should indicate the support for the clue channel > media type but it is not clear to me from RFC 5688 and the clue drafts > that this will be what most implementers would populate. Maybe this > should be clarified in CLUE. > > Andrew > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Thu Jul 24 20:52:12 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 251BE1A03BD for ; Thu, 24 Jul 2014 20:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hiGRkDwWNfCP for ; Thu, 24 Jul 2014 20:52:09 -0700 (PDT) Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2A7B1A020B for ; Thu, 24 Jul 2014 20:52:09 -0700 (PDT) Received: from ppp118-209-150-128.lns20.mel6.internode.on.net ([118.209.150.128]:61105 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XAWXs-0000M6-BX for clue@ietf.org; Fri, 25 Jul 2014 13:51:48 +1000 Message-ID: <53D1D461.9000302@nteczone.com> Date: Fri, 25 Jul 2014 13:52:01 +1000 From: Christian Groves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <010201cfa768$b8724e50$2956eaf0$@gmail.com> In-Reply-To: <010201cfa768$b8724e50$2956eaf0$@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cserver5.myshophosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - nteczone.com X-Get-Message-Sender-Via: cserver5.myshophosting.com: authenticated_id: christian.groves@nteczone.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: http://mailarchive.ietf.org/arch/msg/clue/e9atpZOqjbmUVa82ppiz3dvktK8 Subject: Re: [clue] framewaor audio example section 12.1.1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 03:52:11 -0000 Hello Roni, According to the 12.1.1 the capture points of the audio and videos are all at the same Z level i.e. 800. The video points of capture are at 0 on the Y axis. The audio points of capture are at 2000 on the Y axis (further back into the room). The audio point on line of captures are at ~2925 on the Y axis and 379 on the Z axis (further back into the room and below the audio and capture points). So I don't understand how the line of capture is down from the microphone to the camera? It does go down from the audio capture point to the approximate middle of the video capture area. Regards, Christian On 25/07/2014 3:57 AM, Roni Even wrote: > > Hi, > > The coordinate for audio are correct but seems weird. The line of > capture goes down from the microphone to the camera, this will mean > that it will go up in the other direction towards the room. I think > that having the same z coordinate to the point of capture and point on > the line of capture will make more sense > > Roni > > > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jul 25 11:30:02 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 442301A041C for ; Fri, 25 Jul 2014 11:30:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k150n7zixWxC for ; Fri, 25 Jul 2014 11:29:59 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.12]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930B91A0365 for ; Fri, 25 Jul 2014 11:29:59 -0700 (PDT) Received: from [216.82.249.212:5636] by server-12.bemta-12.messagelabs.com id 3E/11-01453-722A2D35; Fri, 25 Jul 2014 18:29:59 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-7.tower-219.messagelabs.com!1406312996!20873162!6 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3554 invoked from network); 25 Jul 2014 18:29:58 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-7.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2014 18:29:58 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 25 Jul 2014 11:29:39 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Fri, 25 Jul 2014 11:29:37 -0700 Thread-Topic: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt Thread-Index: Ac+nnnSiny7rLdBvSg+CHgts62AApQAl+FhA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B54B@CRPMBOXPRD08.polycom.com> References: <53B0ADDC.5060706@alum.mit.edu> <5C4AC54BFF7A0842A6A11F554D6FB52F078BCD6B24@CRPMBOXPRD08.polycom.com> <53C996E2.8080209@alum.mit.edu> <53CC9B66.60105@nteczone.com> <53D1283B.604@alum.mit.edu> <53D1A31A.2070206@nteczone.com> In-Reply-To: <53D1A31A.2070206@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/KaZRhKXn1yEL3j4W0g6dScGDhQY Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:30:01 -0000 I agree with Christian, I don't see a need for any change. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Thursday, July 24, 2014 8:22 PM > To: clue@ietf.org > Subject: Re: [clue] Pre-WGLC: draft-ietf-clue-framework-15.txt >=20 > Hello Paul, >=20 > I don't see the complexity in round robin. Even in round robin there will= be > the active site, then the previously active site is the last speaker, the > previously active site to that is the n x last speaker, etc. So if site A= has index > 0, when site B is selected as has index 0 then site A will have index 1. >=20 > I don't think we need to go into mathematical definitions for this nor sp= ecific > behaviour for each type of queue. I think the concept of current instance= and > prior instance/s is a generic enough concept. The current text from the d= raft > is: >=20 > An index is used to represent an instance in the policy setting. A > index of 0 represents the most current instance of the policy, i.e. > the active speaker, 1 represents the previous instance, i.e. the > previous active speaker and so on. >=20 > It already talks about "instances" rather than "speakers" so I can't real= ly see > the issue. >=20 > Regards, Christian >=20 > >>> ..snip.. > >>>> > >>>>> Section 7.2.1.2: > >>>>> > >>>>> The explanation of 'index' is pretty fuzzy. ISTM that the meaning > >>>>> really needs to be specified separately for each token. E.g., for > >>>>> SoundLevel N means the N'th most recent loudest speaker. For > >>>>> RoundRobin it is harder to describe. > >>>> [Duckworth, Mark] Makes sense for SoundLevel. Do we want to have > >>>> an index for RoundRobin? I suppose it could make sense there too. > >>>> But I think the current definition of the index is adequate. > >>> > >>> I suspect there is a reason to have have an index for each kind. But > >>> what that index *means* has to be defined separately for each kind. > >> [CNG] I don't see we need to define the index per kind. The index is > >> the n x last speaker, no matter the kind. I can't see the concern > >> with round robin here? > > > > IIUC, with round robin who is speaking is irrelevant to switching, so > > the index can't mean n x last speaker. > > > > I *guess* that for round robin the alternatives are arranged in a > > sequence (the same sequence used in the MCC?) containing captures > > C(0)...C(N-1). Then we can imagine an integer cursor K that is > > periodically incremented modulo N. With that in place, then RoundRobin > > X identifies capture C( (K+X) mod N ). > > > > My point is that defining what the index means for RoundRobin requires > > something like that. (There may be an easier way to describe it.) > > > > Thinking more, maybe you can say that each switching policy defines a > > sequence of choices from among the candidates. And then index 0 means > > the most recent choice from the sequence, while index I selects prior > > choices from that sequence. > > > > Thanks, > > Paul > > > > _______________________________________________ > > clue mailing list > > clue@ietf.org > > https://www.ietf.org/mailman/listinfo/clue > > >=20 > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue From nobody Fri Jul 25 11:45:48 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31A81A0371 for ; Fri, 25 Jul 2014 11:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWCT0G_AZFNM for ; Fri, 25 Jul 2014 11:45:42 -0700 (PDT) Received: from mail1.bemta12.messagelabs.com (mail1.bemta12.messagelabs.com [216.82.251.17]) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41FA91A0334 for ; Fri, 25 Jul 2014 11:45:42 -0700 (PDT) Received: from [216.82.249.212:39591] by server-17.bemta-12.messagelabs.com id 22/56-12819-5D5A2D35; Fri, 25 Jul 2014 18:45:41 +0000 X-Env-Sender: Mark.Duckworth@polycom.com X-Msg-Ref: server-10.tower-219.messagelabs.com!1406313940!20943922!3 X-Originating-IP: [140.242.64.158] X-StarScan-Received: X-StarScan-Version: 6.11.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 3060 invoked from network); 25 Jul 2014 18:45:41 -0000 Received: from crpehubprd01.polycom.com (HELO crpehubprd02.polycom.com) (140.242.64.158) by server-10.tower-219.messagelabs.com with AES128-SHA encrypted SMTP; 25 Jul 2014 18:45:41 -0000 Received: from CRPMBOXPRD08.polycom.com ([fe80::9050:ae9:abfa:9da8]) by crpehubprd02.polycom.com ([::1]) with mapi; Fri, 25 Jul 2014 11:44:58 -0700 From: "Duckworth, Mark" To: Christian Groves , "clue@ietf.org" Date: Fri, 25 Jul 2014 11:44:57 -0700 Thread-Topic: [clue] framewaor audio example section 12.1.1 Thread-Index: Ac+nu9J1ZvxRL4AmQuaaBeKuIjACCAAe4OEA Message-ID: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551@CRPMBOXPRD08.polycom.com> References: <010201cfa768$b8724e50$2956eaf0$@gmail.com> <53D1D461.9000302@nteczone.com> In-Reply-To: <53D1D461.9000302@nteczone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551CRPMBOXPRD08p_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/8zSJu5jJ_4XmesHUMx91EtDq9RQ Subject: Re: [clue] framewaor audio example section 12.1.1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 18:45:44 -0000 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551CRPMBOXPRD08p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I agree with Christian, that is the way I intended to set up the example. Referring to "Figure 4: Room Layout", I have added approximate location of = the audio captures and their axes. This is a top view. The microphones ar= e above the table, possibly hanging from the ceiling. The axis of capture = points down (at an angle, not straight down) toward the people sitting at t= he table, like Christian said. ,-. d ( )`--.__ +---+ `-' / `--.__ | | ,-. | <---AC1 `-.._ |_-+Camera 2 (VC2) ( ).' ___..-+-''`+-+ `-' |_...---'' | | ,-.c+-..__ +---+ ( )| ``--..__ | | `-' | ``+-..|_-+Camera 1 (VC1) ,-. | <---AC2 __..--'|+-+ ( )| __..--' | | `-'b|..--' +---+ ,-. |``---..___ | | ( )\ ```--..._|_-+Camera 0 (VC0) `-' \ <---AC0 _..-''`-+ ,-. \ __.--'' | | ( ) |..-'' +---+ `-' a So following up on the IETF 90 discussion about this, I think the example s= patial information for audio is correct and makes sense for a plausible rea= l world example. Maybe I should update the diagram in the framework, simil= ar to above, to show the AC locations in the top view? BTW I am on vacation for the next week, so I will follow up on the other is= sues after that. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Thursday, July 24, 2014 11:52 PM > To: clue@ietf.org > Subject: Re: [clue] framewaor audio example section 12.1.1 > > Hello Roni, > > According to the 12.1.1 the capture points of the audio and videos are al= l at > the same Z level i.e. 800. The video points of capture are at 0 on the Y = axis. > The audio points of capture are at 2000 on the Y axis (further back into = the > room). > The audio point on line of captures are at ~2925 on the Y axis and 379 on= the Z > axis (further back into the room and below the audio and capture points). > > So I don't understand how the line of capture is down from the microphone > to the camera? It does go down from the audio capture point to the > approximate middle of the video capture area. > > > Regards, Christian > > On 25/07/2014 3:57 AM, Roni Even wrote: > > > > Hi, > > > > The coordinate for audio are correct but seems weird. The line of > > capture goes down from the microphone to the camera, this will mean > > that it will go up in the other direction towards the room. I think > > that having the same z coordinate to the point of capture and point on > > the line of capture will make more sense > > > > Roni > > > > > > > > _______________________________________________ > > 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 --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551CRPMBOXPRD08p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I agree with Christian, that is the way I in= tended to set up the example.

= Referring to “Figure 4: Roo= m Layout”, I have added approximate location of the audio captures an= d their axes.  This is a top view.  The microphones are above the= table, possibly hanging from the ceiling.  The axis of capture points= down (at an angle, not straight down) toward the people sitting at the tab= le, like Christian said.

 

   ,-. = d
  (   )`--.__       = +---+
   `-' /     `--.__  | &n= bsp; |
,-.  | <---AC1    `-.._ |_-+Camera 2 (VC2= )
(   ).'        ___..-+-''= `+-+
`-' |_...---''      |   |
,= -.c+-..__          +---+
(&= nbsp;  )|     ``--..__  |   |
`= -' |            = ; ``+-..|_-+Camera 1 (VC1)
,-. |  <---AC2   __..--'|+= -+
(   )|     __..--'   | &= nbsp; |
`-'b|..--'         = ; +---+
,-. |``---..___     |   |
(&nb= sp;  )\          ```--...= _|_-+Camera 0 (VC0)
`-'  \ <---AC0     _..-= ''`-+
  ,-. \      __.--'' |   |=
(   ) |..-''        +---+=
  `-' a

So following up on the IETF 90 discuss= ion about this, I think the example spatial information for audio is correc= t and makes sense for a plausible real world example.  Maybe I should = update the diagram in the framework, similar to above, to show the AC locat= ions in the top view?

 

BTW I am on vacation f= or the next week, so I will follow up on the other issues after that.<= /o:p>

 

Mark

 

> -----Original Message---= --

> From: clue [mailto:clue-bounces@ietf.org= ] On Behalf Of Christian Groves

> Sent: Thurs= day, July 24, 2014 11:52 PM

> To: clue@ietf.o= rg

> Subject: Re: [clue] framewaor audio exam= ple section 12.1.1

>

> Hello Roni,

>

> According to the 12.1.1 the capture points of the audio and vide= os are all at

> the same Z level i.e. 800. Th= e video points of capture are at 0 on the Y axis.

> The audio points of capture are at 2000 on the Y axis (further back = into the

> room).

= > The audio point on line of captures are at ~2925 on the Y axis and 379= on the Z

> axis (further back into the room = and below the audio and capture points).

>

> So I don't understand how the line of captur= e is down from the microphone

> to the camera= ? It does go down from the audio capture point to the

> approximate middle of the video capture area.

>

>

= > Regards, Christian

>

> On 25/07/2014 3:57 AM, Roni Even wrote:

> >

> > Hi,

> >

> > The coordinate for = audio are correct but seems weird. The line of

&= gt; > capture goes down from the microphone to the camera, this will mea= n

> > that it will go up in the other dire= ction towards the room. I think

> > that h= aving the same z coordinate to the point of capture and point on

> > the line of capture will make more sense

> >

> > Roni

=

> >

> >

<= p class=3DMsoPlainText>> >

> > _____= __________________________________________

> = > clue mailing list

> > clu= e@ietf.org

> > https://www.ietf.org/mailman/listinfo/clue

=

>

> _____________= __________________________________

> clue mai= ling list

> = clue@ietf.org<= /a>

> https= ://www.ietf.org/mailman/listinfo/clue

= --_000_5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551CRPMBOXPRD08p_-- From nobody Fri Jul 25 14:32:36 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5608D1A014B for ; Fri, 25 Jul 2014 14:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id si5lC71hCaZM for ; Fri, 25 Jul 2014 14:32:34 -0700 (PDT) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id 7AF411A00D8 for ; Fri, 25 Jul 2014 14:32:34 -0700 (PDT) Received: from omta06.westchester.pa.mail.comcast.net ([76.96.62.51]) by qmta05.westchester.pa.mail.comcast.net with comcast id WlME1o00716LCl055lYaD7; Fri, 25 Jul 2014 21:32:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([206.47.221.210]) by omta06.westchester.pa.mail.comcast.net with comcast id WlWR1o0074YyHWu3SlWTXz; Fri, 25 Jul 2014 21:30:31 +0000 Message-ID: <53D2CC71.6060309@alum.mit.edu> Date: Fri, 25 Jul 2014 17:30:25 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: <010201cfa768$b8724e50$2956eaf0$@gmail.com> <53D1D461.9000302@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551@CRPMBOXPRD08.polycom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406323954; bh=jW0dALSeTP/8itaRBisFtCHX8WEg/1xErele3XzTc04=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=McwaaUr9dvFzRdIcLNUzadBBvc07PnHU2zDdv4WZ0MPtBSN87EiZeuCE6bYWk14ot bb0tWK246ITWLYj/5M2XBTm7Enmx3L66woVvGq4jjVq6ecJyQPnW0Lys9fa/ORX6i0 AmpnqFgeLv47yk9XqnF3ZjtnLTwCNwu8CrHHxmVA/lzLS9neCB73esromy8l8whkMq wTKDPhtPi0JlgDCZ15hD0uJM6EoSfJXkWYdnp/Ud3s2DSoFLDmMBKBEt9K/XlENWlx dtTJdrn0pvpF8qlPbvoqjeMOXzbnphm6DVlReKN04TS18M+kTshocf7ZO+7FJbwY0s Wy06g0POtx79w== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/7QeGKviA0AqGylYAzIZGb4dOl6I Subject: Re: [clue] framewaor audio example section 12.1.1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:32:35 -0000 On 7/25/14 2:44 PM, Duckworth, Mark wrote: > I agree with Christian, that is the way I intended to set up the example. > So following up on the IETF 90 discussion about this, I think the > example spatial information for audio is correct and makes sense for a > plausible real world example. Maybe I should update the diagram in the > framework, similar to above, to show the AC locations in the top view? I think that would be helpful. > BTW I am on vacation for the next week, so I will follow up on the other > issues after that. You don't think an IETF meeting is enough vacation? :-) Enjoy your vacation. Thanks, Paul From nobody Fri Jul 25 14:55:20 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE751A0392 for ; Fri, 25 Jul 2014 14:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8GmTjBtyuf4 for ; Fri, 25 Jul 2014 14:55:18 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 72CED1A037C for ; Fri, 25 Jul 2014 14:55:18 -0700 (PDT) Received: from omta14.westchester.pa.mail.comcast.net ([76.96.62.60]) by qmta03.westchester.pa.mail.comcast.net with comcast id WlRS1o0031HzFnQ53lvJyT; Fri, 25 Jul 2014 21:55:18 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([206.47.221.210]) by omta14.westchester.pa.mail.comcast.net with comcast id WltA1o0054YyHWu3altCYW; Fri, 25 Jul 2014 21:53:16 +0000 Message-ID: <53D2D1C6.3040508@alum.mit.edu> Date: Fri, 25 Jul 2014 17:53:10 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: clue@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1406325318; bh=tXDYCUU36+ViWU9heBlIOc3opUnFvhoZ8tu64mW1Z3w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OcW+h0zlndcwb3fIXU10Gk4+a12zuR3wJEYvE4rJDQ48EQi4C9689zerUS4zewNyJ pT+Vh7lJLCnjLKmbGZOtPaX3H3A4ZZMSqmO7l1vGB9HhpulnDpRSZBa8dBVoJDosOG Zjjh1MLLwFtI9H8hDOH7LMeU7maTT6jsOEqF4gZAlJcMLQeZTSUS21fEZN1L42DJXN HZh9oSO9SOOrkXGY6YAS3SO2Gn98RUVAxfwonVXbM2qH7zoKvVZuX/iqN80ayRikBz 71iTSq2UUKuxJK4Lk7rPRgF5QAe0Q4rRvYLzG8F9rQ+UKcYrc1e+tLTeqIo183B/xC pIptYRqAt5P1w== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Det28OoMMk_QNcn_XI92a7fs6A4 Subject: Re: [clue] Question on relationship between Clue protocol SDP negotiation and RFC 5688 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jul 2014 21:55:19 -0000 On 7/24/14 2:38 PM, Andrew Allen wrote: > One issue I have been struggling with is understanding what should be > populated in the sip.app-tsubype media feature tag defined in RFC 5688. > > Ideally IMHO this should indicate the support for the clue channel > media type but it is not clear to me from RFC 5688 and the clue drafts > that this will be what most implementers would populate. Maybe this > should be clarified in CLUE. We have not considered this. If we were to do so, it would be +sip.app-subtype="webrtc-datachannel". But I don't think this would be very helpful. It doesn't say we want to use the datachannel for clue. The +sip.clue, already mentioned by Christian, is more helpful. Thanks, Paul From nobody Fri Jul 25 18:52:46 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB71C1A0087 for ; Fri, 25 Jul 2014 18:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x7pak9iiL2Fd for ; Fri, 25 Jul 2014 18:52:36 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8131A00A7 for ; Fri, 25 Jul 2014 18:52:35 -0700 (PDT) X-AuditID: c1b4fb25-f79da6d000004ad3-03-53d309e1d2dc Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id BE.C1.19155.1E903D35; Sat, 26 Jul 2014 03:52:33 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.4]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0174.001; Sat, 26 Jul 2014 03:52:32 +0200 From: Christer Holmberg To: "clue@ietf.org" , "clue-chairs@tools.ietf.org" Thread-Topic: IETF#90: CLUE (2nd session) raw notes Thread-Index: Ac+odD3rCVwRn+/rQvqgk/eZwu+LMQ== Date: Sat, 26 Jul 2014 01:52:32 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D3D5626@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D3D5626ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje5DzsvBBjPOiFnMnPaB1WL/qcvM DkweS5b8ZPL4cvkzWwBTFJdNSmpOZllqkb5dAlfG36crmAu2dDJWvPz2ibWBsauqi5GTQ0LA ROJ0YwszhC0mceHeerYuRi4OIYGjjBJvWzaxQDiLGCU+T38AVMXBwSZgIdH9TxukQUQgQaLp 1g4mEFtYQE/i0IkeJoi4scTfGz8YQcpFgOLP+mJBwiwCqhIzu9axgdi8Ar4SHdtawcoZgfZ+ P7UGzGYWEJe49WQ+E8Q9AhJL9pyHuk1U4uXjf6wQtpJE45InrBD1+RLzZq1igZgpKHFy5hOW CYxCs5CMmoWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tTgpN93IWC+1 KDO5uDg/Ty8vtWQTIzBODm75rbqD8fIbx0OMAhyMSjy8CrMvBQuxJpYVV+YeYpTmYFES5114 bl6wkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkaO7i1b3F49/+v/YqWSn4T4u8dXF4uKvVBV 29M6ifOq1SmHU1GKq0Kan3w+aTMjulcjaMWmde6XWtvjNwc9+xT/dfJT361Mge/1QnWN9Up1 bPXfXY/YoF/WPVmHkUORx/c5337HRwcczflfhWp8Ub89v8XO5Vxdxtpdtcu3m06f/WRmbYLJ gU4lluKMREMt5qLiRAAlQYwJdAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/clue/Q-ddePTGXdXJVCWiZp34mKDlz9Q Subject: [clue] IETF#90: CLUE (2nd session) raw notes X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jul 2014 01:52:39 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D3D5626ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Below are my raw notes from the second CLUE session. Regards, Christer ---------------------- Topic: CLUE Framework Draft: draft-ietf-clue-framework-16 Presenter: Mark Duckworth ISSUE: The following terminology renaming was suggested: Capture Scene Entry (CSE) -> Capture Scene View (CSV) Global CSE Lite -> Global View List OUTCOME: The suggested changes were agreed. ISSUE: Orientation of coordinate system - camera left/right, front/back OUTCOME: Mark will prepare a suggestion on how to describe the coordinate s= ystem without using left/right/front/back terminology. ISSUE: Synchronisation ID clarifications OUTCOME: People are requested to look at the e-mail thread associated with = the issue ISSUE: Media type of a Simultaneous Transmission Set OUTCOME: It will be clarified that all media captures within a STS will hav= e the same media type ISSUE: Example 12.1.1 treatment of audio captures OUTCOME: Mark is going to look at the example which has caused confusion. P= eople are requested to check the example for errors. Topic: CLUE Signaling Draft: draft-ietf-clue-signaling-02 Presenter: Paul Kyzivat It was indicated that all of Paul K's significant concerns have been addres= sed in the latest version of the draft, and that a pre-WGLC could be called= for in the end of October. Cullen Jennings and Christer Holmberg committed to review the document. ISSUES STATUS: #28: Resolved #25: Will be reassigned as a Protocol issue #24, #30: Resolved. BFCP usage will not be defined. NEW ISSUE: A new issue will be opened regarding fallback to normal session. Topic: CLUE protocol Call Flows Draft: draft-even-clue-call-flows-00 Presenter: Roni Even OUTCOME: - - We will not add details regarding ICE messages (ICE candidates can be s= hown in SDP) and BUNDLE into the call flows - We will add an example showing the usage of secure media, using SRTP-DT= LS - We will add an example on modifying a CLUE call to a "normal" call. --_000_7594FB04B1934943A5C02806D1A2204B1D3D5626ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Below are my raw notes from the second CLUE session.=

 

Regards,

 

Christer

 

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

 

Topic:     CLUE Framework

Draft:     draft-ietf-clue-framework-16

Presenter: Mark Duckworth

 

 

ISSUE:= The following terminology renaming was suggested:

      Capture Scene Entry (CSE) -> Capture S= cene View (CSV)

      Global CSE Lite -> Global View List

OUTCOME: The suggested changes were agreed.

 

ISSUE:= Orientation of coordinate system - camera left/right, front/back

OUTCOME: Mark will prepare a suggestion on how to describe the coordinate system = without using left/right/front/back terminology.

 

ISSUE:= Synchronisation ID clarifications

OUTCOME: People are requested to look at the e-mail thread associated with the is= sue

 

ISSUE:= Media type of a Simultaneous Transmission Set

OUTCOME: It will be clarified that all media captures within a STS will have the = same media type

 

ISSUE:= Example 12.1.1 treatment of audio captures

OUTCOME: Mark is going to look at the example which has caused confusion. People = are requested to check the example for errors.

 

 

 

Topic:     C= LUE Signaling

Draft:     draft-ietf-clue-signaling-02

Presenter: Paul Kyzivat

 

It was indicated that all of Paul K’s significant concerns have be= en addressed in the latest version of the draft, and that a pre-WGLC could = be called for in the end of October.

 

Cullen Jennings and Christer Holmberg committed to review the document.<= o:p>

 

ISSUES STATUS:

 

#28: Resolved

#25: Will be reassigned as a Protocol issue

#24, #30: Resolved. BFCP usage will not be defined.

 

NEW ISSUE:

 

A new issue will be opened regarding fallback to normal session.

 

 

 

Topic:     CLUE protocol Call Flows

Draft:     draft-even-clue-call-flows-00

Presenter: Roni Even

 

OUTCOME:

-    

-   We will not add details regarding ICE messages (ICE candidates can = be shown in SDP) and BUNDLE into the call flows

-   We will add an example showing the usage of secure media, using SRT= P-DTLS

-   We will add an example on modifying a CLUE call to a "normal&q= uot; call.

 

 

--_000_7594FB04B1934943A5C02806D1A2204B1D3D5626ESESSMB209erics_-- From nobody Sun Jul 27 20:51:51 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7BE1A0029 for ; Sun, 27 Jul 2014 20:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMZ0mUB9bSzP for ; Sun, 27 Jul 2014 20:51:48 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 151421A0021 for ; Sun, 27 Jul 2014 20:51:47 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id el20so5073389lab.27 for ; Sun, 27 Jul 2014 20:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s/vw6W87+tDQaMaQH+VcofB7QeJWStQNj8mtPxh4S/U=; b=Jrh2xQ+QLQT9JkHguCdi3hzvrckPylIpsp5Zq2Pmh8eaK33HkNL98z1OKMT0BQUtZj F/WdsqbYyyWCMNoS6wUe41gkNn3iGSdvqcnt+Nsfr2B9Iz24Ay2ncZ10rFFTiHE/PsRw nD4LMru5WV3pGnMwrdCGvkQ8bi3AZuX6fLMqkfyZP4lhSljSBA43kFRQCUDEiRU8Rr9I 4/Ibylhp37N9FdfQFfUqPj2uDe15BPtN75KpWP+dXD+HnD+sXPdt3fGB+MrwM2evWitm 7wH/LF5+HcOgY+lOO+KVTsgc8Nckzy1crG1zFuB7Fkywo0+lruedWHJP+k82rnVW33Ds eFyg== MIME-Version: 1.0 X-Received: by 10.112.209.73 with SMTP id mk9mr29562334lbc.64.1406519505327; Sun, 27 Jul 2014 20:51:45 -0700 (PDT) Received: by 10.112.157.194 with HTTP; Sun, 27 Jul 2014 20:51:45 -0700 (PDT) In-Reply-To: <53D2CC71.6060309@alum.mit.edu> References: <010201cfa768$b8724e50$2956eaf0$@gmail.com> <53D1D461.9000302@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551@CRPMBOXPRD08.polycom.com> <53D2CC71.6060309@alum.mit.edu> Date: Mon, 28 Jul 2014 06:51:45 +0300 Message-ID: From: Ron Even To: Paul Kyzivat Content-Type: multipart/alternative; boundary=001a11c335367c1dd504ff38d7f6 Archived-At: http://mailarchive.ietf.org/arch/msg/clue/76J_AYTzkI8X9l2xIDOjvk616PQ Cc: "clue@ietf.org" Subject: Re: [clue] framewaor audio example section 12.1.1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 03:51:50 -0000 --001a11c335367c1dd504ff38d7f6 Content-Type: text/plain; charset=UTF-8 Hi, I am also on vacation but I think the question is what is the meaning of the capture point for audio and how it relates to the audio from the people in room. Where are the people in relation with the audio point of capture and for the other example also with regards to the video cameras Roni. On Friday, July 25, 2014, Paul Kyzivat wrote: > On 7/25/14 2:44 PM, Duckworth, Mark wrote: > >> I agree with Christian, that is the way I intended to set up the example. >> > > So following up on the IETF 90 discussion about this, I think the >> example spatial information for audio is correct and makes sense for a >> plausible real world example. Maybe I should update the diagram in the >> framework, similar to above, to show the AC locations in the top view? >> > > I think that would be helpful. > > BTW I am on vacation for the next week, so I will follow up on the other >> issues after that. >> > > You don't think an IETF meeting is enough vacation? :-) > > Enjoy your vacation. > > Thanks, > Paul > > _______________________________________________ > clue mailing list > clue@ietf.org > https://www.ietf.org/mailman/listinfo/clue > --001a11c335367c1dd504ff38d7f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi,
I am also on vacation but I think th= e question is what is the meaning of the capture point for audio and how it= relates to the audio from the people in room. Where are the people in rela= tion with the audio point of capture and for the other example also with re= gards to the video cameras
Roni.

On Friday, July 25,= 2014, Paul Kyzivat <pkyzivat@a= lum.mit.edu> wrote:
On 7/25/14 2:44 PM, Duckworth, Mark wrote:
I agree with Christian, that is the way I intended to set up the example.

So following up on the IETF 90 discussion about this, I think the
example spatial information for audio is correct and makes sense for a
plausible real world example. =C2=A0Maybe I should update the diagram in th= e
framework, similar to above, to show the AC locations in the top view?

I think that would be helpful.

BTW I am on vacation for the next week, so I will follow up on the other issues after that.

You don't think an IETF meeting is enough vacation? :-)

Enjoy your vacation.

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

_______________________________________________
clue mailing list
clue@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/clue
--001a11c335367c1dd504ff38d7f6-- From nobody Mon Jul 28 09:30:16 2014 Return-Path: X-Original-To: clue@ietfa.amsl.com Delivered-To: clue@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A670D1A038A for ; Mon, 28 Jul 2014 09:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q6MbUBt-RRCI for ; Mon, 28 Jul 2014 09:30:12 -0700 (PDT) Received: from mail-pd0-x229.google.com (mail-pd0-x229.google.com [IPv6:2607:f8b0:400e:c02::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13A301A038F for ; Mon, 28 Jul 2014 09:30:12 -0700 (PDT) Received: by mail-pd0-f169.google.com with SMTP id y10so10204619pdj.28 for ; Mon, 28 Jul 2014 09:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=G/CUwUVGIRCFOBkCuT8jk2pRsO2a4RJr2fxE8JJJXVQ=; b=QnSRbuqX29QtVEqRqvtTnGeJEUvjX2Ul7aIK1oK35YcykBmRzfli+cEWDLYk5dzaAp fzu8EbuTi4vw7XMp6lLfPgkXEe4dlWmCSigc8G9oRmLoovPXlU0zrs03TVt3+WC7xpF5 EfuSiCZ1S+NxZivXph0k8euD8seQBivmUcovAcq1xfsZlReE12ucvMUUUCJ4tZvDo0ZW NSGTQ3uig+fqZZ0GyRa3CKUHZjqJPT6JhxrFPpsLyUPdQgeLvo9jDOI4bTQ7DkNGEP4Q nBh7uQtOxJDqhXNd+tFSiB0KbJVmmV5Cuaz9tkklwPZAAGuKtl26elwJOcxIuuIFrwbG O+3g== X-Received: by 10.66.183.11 with SMTP id ei11mr11392975pac.116.1406565011666; Mon, 28 Jul 2014 09:30:11 -0700 (PDT) Received: from RoniE (209-82-80-116.dedicated.allstream.net. [209.82.80.116]) by mx.google.com with ESMTPSA id fy1sm7575147pdb.66.2014.07.28.09.30.09 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 28 Jul 2014 09:30:10 -0700 (PDT) From: "Roni Even" To: "'Duckworth, Mark'" , "'Christian Groves'" , References: <010201cfa768$b8724e50$2956eaf0$@gmail.com> <53D1D461.9000302@nteczone.com> <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551@CRPMBOXPRD08.polycom.com> In-Reply-To: <5C4AC54BFF7A0842A6A11F554D6FB52F078BE5B551@CRPMBOXPRD08.polycom.com> Date: Mon, 28 Jul 2014 19:30:08 +0300 Message-ID: <012c01cfaa81$32bddb00$98399100$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012D_01CFAA9A.580C99A0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKi5MkWwqqkEvjkyW58oiu2pImfYAIcwvxbAtFExDCZ58g8UA== Content-Language: en-us Archived-At: http://mailarchive.ietf.org/arch/msg/clue/-rcEg02JOuxeHzU8xWwzT1kc6ck Subject: Re: [clue] framewaor audio example section 12.1.1 X-BeenThere: clue@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: CLUE - ControLling mUltiple streams for TElepresence List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jul 2014 16:30:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012D_01CFAA9A.580C99A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Guys, You are right, sorry for the wrong email before. It will be good to explain that the microphones are above the people in the room Roni From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, Mark Sent: 25 July, 2014 9:45 PM To: Christian Groves; clue@ietf.org Subject: Re: [clue] framewaor audio example section 12.1.1 I agree with Christian, that is the way I intended to set up the example. Referring to "Figure 4: Room Layout", I have added approximate location of the audio captures and their axes. This is a top view. The microphones are above the table, possibly hanging from the ceiling. The axis of capture points down (at an angle, not straight down) toward the people sitting at the table, like Christian said. ,-. d ( )`--.__ +---+ `-' / `--.__ | | ,-. | <---AC1 `-.._ |_-+Camera 2 (VC2) ( ).' ___..-+-''`+-+ `-' |_...---'' | | ,-.c+-..__ +---+ ( )| ``--..__ | | `-' | ``+-..|_-+Camera 1 (VC1) ,-. | <---AC2 __..--'|+-+ ( )| __..--' | | `-'b|..--' +---+ ,-. |``---..___ | | ( )\ ```--..._|_-+Camera 0 (VC0) `-' \ <---AC0 _..-''`-+ ,-. \ __.--'' | | ( ) |..-'' +---+ `-' a So following up on the IETF 90 discussion about this, I think the example spatial information for audio is correct and makes sense for a plausible real world example. Maybe I should update the diagram in the framework, similar to above, to show the AC locations in the top view? BTW I am on vacation for the next week, so I will follow up on the other issues after that. Mark > -----Original Message----- > From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Christian Groves > Sent: Thursday, July 24, 2014 11:52 PM > To: clue@ietf.org > Subject: Re: [clue] framewaor audio example section 12.1.1 > > Hello Roni, > > According to the 12.1.1 the capture points of the audio and videos are all at > the same Z level i.e. 800. The video points of capture are at 0 on the Y axis. > The audio points of capture are at 2000 on the Y axis (further back into the > room). > The audio point on line of captures are at ~2925 on the Y axis and 379 on the Z > axis (further back into the room and below the audio and capture points). > > So I don't understand how the line of capture is down from the microphone > to the camera? It does go down from the audio capture point to the > approximate middle of the video capture area. > > > Regards, Christian > > On 25/07/2014 3:57 AM, Roni Even wrote: > > > > Hi, > > > > The coordinate for audio are correct but seems weird. The line of > > capture goes down from the microphone to the camera, this will mean > > that it will go up in the other direction towards the room. I think > > that having the same z coordinate to the point of capture and point on > > the line of capture will make more sense > > > > Roni > > > > > > > > _______________________________________________ > > 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 ------=_NextPart_000_012D_01CFAA9A.580C99A0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Guys,

You are right, sorry for = the wrong email before.

It will be good to explain that the microphones = are above the people in the room

 

Roni

 

From:= = clue [mailto:clue-bounces@ietf.org] On Behalf Of Duckworth, = Mark
Sent: 25 July, 2014 9:45 PM
To: Christian = Groves; clue@ietf.org
Subject: Re: [clue] framewaor audio = example section 12.1.1

 

I agree with Christian, that is the = way I intended to set up the example.

Referring = to “Figure 4: Room Layout”, I have added approximate = location of the audio captures and their axes.  This is a top = view.  The microphones are above the table, possibly hanging from = the ceiling.  The axis of capture points down (at an angle, not = straight down) toward the people sitting at the table, like Christian = said.

 

   ,-. d
  = (   )`--.__        = +---+
   `-' /     `--.__  = |   |
,-.  | <---AC1    `-.._ = |_-+Camera 2 (VC2)
(   = ).'        ___..-+-''`+-+
`-' = |_...---''      |   = |
,-.c+-..__          = +---+
(   )|     ``--..__  = |   |
`-' = |            = ``+-..|_-+Camera 1 (VC1)
,-. |  <---AC2   = __..--'|+-+
(   )|     = __..--'   |   = |
`-'b|..--'          = +---+
,-. |``---..___     |   = |
(   = )\          = ```--..._|_-+Camera 0 (VC0)
`-'  \ = <---AC0     _..-''`-+
  ,-. = \      __.--'' |   |
(   = ) |..-''        +---+
  `-' = a

So following up on the IETF 90 = discussion about this, I think the example spatial information for audio = is correct and makes sense for a plausible real world example.  = Maybe I should update the diagram in the framework, similar to above, to = show the AC locations in the top view?

 

BTW I am on vacation for the next = week, so I will follow up on the other issues after = that.

 

Mark

 

> = -----Original Message-----

> = From: clue [mailto:clue-bounces@ietf.org] = On Behalf Of Christian Groves

> = Sent: Thursday, July 24, 2014 11:52 PM

> To: clue@ietf.org

> Subject: Re: [clue] framewaor audio example = section 12.1.1

> =

> Hello Roni,

>

> = According to the 12.1.1 the capture points of the audio and videos are = all at

> the same Z level i.e. = 800. The video points of capture are at 0 on the Y = axis.

> The audio points of = capture are at 2000 on the Y axis (further back into = the

> room).

> The audio point on line of captures are at = ~2925 on the Y axis and 379 on the Z

> axis (further back into the room and below the = audio and capture points).

> =

> So I don't understand how = the line of capture is down from the microphone

> to the camera? It does go down from the audio = capture point to the

> = approximate middle of the video capture area.

>

> =

> Regards, = Christian

>

> On 25/07/2014 3:57 AM, Roni Even = wrote:

> >

> > Hi,

> >

> > The coordinate for audio are correct but = seems weird. The line of

> > = capture goes down from the microphone to the camera, this will = mean

> > that it will go up = in the other direction towards the room. I think

> > that having the same z coordinate to the = point of capture and point on

> = > the line of capture will make more sense

> >

> > Roni

> >

> >

> >

> > = _______________________________________________

> > clue mailing list

> > clue@ietf.org<= o:p>

> > https://www.ietf.org/mail= man/listinfo/clue

> =

> = _______________________________________________

> clue mailing list

> clue@ietf.org<= o:p>

> https://www.ietf.org/mail= man/listinfo/clue

------=_NextPart_000_012D_01CFAA9A.580C99A0--