Re: [clue] contradiction in framework about simultaneous captures in a CSE

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 21 February 2014 17:39 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 C27C61A01E4 for <clue@ietfa.amsl.com>; Fri, 21 Feb 2014 09:39:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKGau-tYZgJg for <clue@ietfa.amsl.com>; Fri, 21 Feb 2014 09:39:39 -0800 (PST)
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 09A011A021C for <clue@ietf.org>; Fri, 21 Feb 2014 09:39:38 -0800 (PST)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta10.westchester.pa.mail.comcast.net with comcast id V2J11n0070vyq2s5A5fbeF; Fri, 21 Feb 2014 17:39:35 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id V5fa1n00o3ZTu2S3R5faab; Fri, 21 Feb 2014 17:39:35 +0000
Message-ID: <53078F56.20804@alum.mit.edu>
Date: Fri, 21 Feb 2014 12:39:34 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "Duckworth, Mark" <Mark.Duckworth@polycom.com>, "clue@ietf.org" <clue@ietf.org>
References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> <530784E1.7020100@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com>
In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393004375; bh=iKz2DqJak9oRVxLenMb9LxYu9rVEoQhp2eVsXGMdQXw=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=K3sfEMzj5gCcYbURJMeODWTITcK+XygLtG4ZRP0SYjghyZmGN3nNmYGh6mglArWFa zrGq45ECUVq4xREiGjXSUBucplFgLOYh1oKNMonMD44fDDJIex6UxmLMEmwrqq2OA0 2Yu5rqFnXaE/ltRw6AJlAkmowZ7w0U60V0Jb0T71ir0gY0wPSR+itjTh5/A3gih+Uk eRyGvlX6A3MnwFa2bzrJm8mg4vRvemi+CtHQdN1kgO35dhwgNEG1JYhXPb+uiKvLir cfCeJ7UHd0DdPpxF4P/hM4UQX7YMXw16J2NVtcKlL8KCxIL9LAmFz+kiS62suXoz3S Sw0tdG/07+79Q==
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/as8s6MF-tAVLPGhw4hN6V8vuw6Q
Subject: Re: [clue] contradiction in framework about simultaneous captures in a CSE
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Feb 2014 17:39:41 -0000

On 2/21/14 12:20 PM, Duckworth, Mark wrote:
> Hi Paul,
>
> I thought of that possibility also.  But I think our intent was for the provider to be able to advertise the complete scene information for original sources, including CSEs, even if the provider didn't include encoding groups for those captures.  I think it is useful to include the CSEs for captures without encoding groups, because the consumer can use this information for choosing captures, or choosing subsets within MCCs.
>
> Another possibility is to say either all captures in a CSE must include an encoding group, or none of the captures in a CSE can include an encoding group.  I can't think of a case that makes sense to include a mixture.

We can just say that the provider must be capable of simultaneously 
delivering all those captures in a CSE *that have an encoding group*.

That would allow an CSE that has some captures with encoding groups and 
some without. I can't think of any reason to do that, but it seems 
easier than adding more arbitrary rules.

	Thanks,
	Paul

> Mark
>
>> -----Original Message-----
>> From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: Friday, February 21, 2014 11:55 AM
>> To: clue@ietf.org
>> Subject: Re: [clue] contradiction in framework about simultaneous captures
>> in a CSE
>>
>> On 2/21/14 10:06 AM, Duckworth, Mark wrote:
>>
>>> Here is a proposal for changing the sentence in 7.3:
>>>
>>> "If all the Captures in a single Capture Scene Entry have an Encoding
>>> Group, then the Provider MUST be capable of encoding and sending all
>>> those Captures simultaneously."
>>>
>>> Is that a good change?
>>
>> The above implies that if some but not all captures in a CSE have encoding
>> groups, then there is no requirement for the provider to be able to send
>> them simultaneously.
>>
>> Does it make sense to define a CSE containing captures without encoding
>> groups?
>>
>> Is there any reason to do so?
>>
>> ISTM that we could instead say that a CSE MUST NOT reference a capture
>> that has no encoding group. Then 7.3 would be ok as it is.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> clue mailing list
>> clue@ietf.org
>> https://www.ietf.org/mailman/listinfo/clue
>