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

Christian Groves <Christian.Groves@nteczone.com> Mon, 24 February 2014 01:39 UTC

Return-Path: <Christian.Groves@nteczone.com>
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 39B381A078F for <clue@ietfa.amsl.com>; Sun, 23 Feb 2014 17:39:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2
X-Spam-Level: **
X-Spam-Status: No, score=2 tagged_above=-999 required=5 tests=[BAYES_80=2] 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 TpoBSl7ck2dn for <clue@ietfa.amsl.com>; Sun, 23 Feb 2014 17:39:06 -0800 (PST)
Received: from cserver5.myshophosting.com (cserver5.myshophosting.com [175.107.161.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE09E1A078C for <clue@ietf.org>; Sun, 23 Feb 2014 17:39:05 -0800 (PST)
Received: from ppp118-209-108-194.lns20.mel4.internode.on.net ([118.209.108.194]:56394 helo=[127.0.0.1]) by cserver5.myshophosting.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <Christian.Groves@nteczone.com>) id 1WHkRZ-0001KT-Vb for clue@ietf.org; Mon, 24 Feb 2014 12:34:54 +1100
Message-ID: <530AA2B7.5090105@nteczone.com>
Date: Mon, 24 Feb 2014 12:39:03 +1100
From: Christian Groves <Christian.Groves@nteczone.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: clue@ietf.org
References: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDA32@CRPMBOXPRD07.polycom.com> <530784E1.7020100@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB2A@CRPMBOXPRD07.polycom.com> <53078F56.20804@alum.mit.edu> <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB47@CRPMBOXPRD07.polycom.com>
In-Reply-To: <49E45C59CA48264997FEBFB29B6BC2D60C9D5FDB47@CRPMBOXPRD07.polycom.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/IROA9PcvbeWD26-Jtbn5fwK2Wzk
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: Mon, 24 Feb 2014 01:39:08 -0000

WFM.
Christian
On 22/02/2014 4:41 AM, Duckworth, Mark wrote:
> That works for me.
> Mark
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu]
>> Sent: Friday, February 21, 2014 12:40 PM
>> To: Duckworth, Mark; clue@ietf.org
>> Subject: Re: [clue] contradiction in framework about simultaneous captures
>> in a CSE
>>
>> 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
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>