Subject: [clue] MCC attributes composed and switching

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 6 Feb 2014 09:55:24 -0800

In draft-ietf-clue-data-model-schema-03, and at the design team meeting Feb 4, Roberta and Simon suggested adding the <composed> and <switching> elements in the data model, for MCCs.  This is practically the same as the previous composed and switched attributes we had for any media capture, but now restricted to use with MCCs rather than any individual capture.

Based on other recent discussions on the list, it seems to me it is useful to support these optional attributes so the provider can more accurately indicate what it is doing.  If the group agrees, I will add these attributes back into the framework for MCCs.

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 13:09:49 -0500

On 2/6/14 12:55 PM, Duckworth, Mark wrote:
> In draft-ietf-clue-data-model-schema-03, and at the design team meeting
> Feb 4, Roberta and Simon suggested adding the <composed> and <switching>
> elements in the data model, for MCCs.  This is practically the same as
> the previous composed and switched attributes we had for any media
> capture, but now restricted to use with MCCs rather than any individual
> capture.
>
> Based on other recent discussions on the list, it seems to me it is
> useful to support these optional attributes so the provider can more
> accurately indicate what it is doing.  If the group agrees, I will add
> these attributes back into the framework for MCCs.

See my earlier comment today regarding MaxCaptures.

I *think* if we have MaxCaptures (or maybe NumCaptures) then that 
effectively serves the same purpose as <composed> and <switching>. I 
think we should probably have one or the other, while having both seems 
like overkill.

I'm tending toward preferring the flags rather than the number.

Stylistically, I would prefer <switched> over <switching>, for 
consistency with <composed>.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Thu, 6 Feb 2014 10:27:16 -0800

Paul,

So are you suggesting we should remove the maxCaptures attribute, and add the composed and switched attributes?  And not add numCaptures or minCaptures?  That would be okay with me.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Thursday, February 06, 2014 1:10 PM
> To: [email-masked]
> Subject: Re: [clue] MCC attributes composed and switching
> 
> > In draft-ietf-clue-data-model-schema-03, and at the design team
> > meeting Feb 4, Roberta and Simon suggested adding the <composed> and
> > <switching> elements in the data model, for MCCs.  This is practically
> > the same as the previous composed and switched attributes we had for
> > any media capture, but now restricted to use with MCCs rather than any
> > individual capture.
> >
> effectively serves the same purpose as <composed> and <switching>. I think
> we should probably have one or the other, while having both seems like
> overkill.
> 
> Stylistically, I would prefer <switched> over <switching>, for consistency with
> <composed>.
> 
> 	Thanks,
> 	Paul
> 
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Feb 2014 16:01:49 -0500

> So are you suggesting we should remove the maxCaptures attribute, and add the composed and switched attributes?  And not add numCaptures or minCaptures?  That would be okay with me.

I am *suggesting* we consider that, unless we can figure out how the 
number is better.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 07 Feb 2014 12:01:28 +1100

I agree that having both is overkill. I believe that MaxCaptures is a 
better approach as it better allows an Advertiser and Consumer to 
distinguish between offered MCCs.

Regards, Christian

On 7/02/2014 8:01 AM, Paul Kyzivat wrote:
>> So are you suggesting we should remove the maxCaptures attribute, and 
>> add the composed and switched attributes?  And not add numCaptures or 
>> minCaptures?  That would be okay with me.
>
>>> think