Subject: [clue] MCC grouping label - RE: Advertising what is in an MCC - allow wildcard?

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 17 Jan 2014 15:12:19 -0800

We discussed this topic in the Jan 14 design team meeting.  The group had interest in the concept, but not my specific proposal.  Jonathan had an interesting idea, which I think better serves the purpose.  

Instead of the MCC referring specifically to other media captures that can be contained within the MCC, the MCC can refer to zero or more "MCC grouping labels".  Any other media capture can include an attribute (zero or more) with a particular MCC grouping label.  The meaning is that any MC that has the same grouping label that is reference by an MCC can be included in that MCC.

I think this doesn't change at all the meaning of MCC, but it will affect the syntax of how we describe it in the data model for CLUE messages.

If the group agrees with this concept, I can propose specific changes to the framework.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Duckworth, Mark
> Sent: Friday, January 10, 2014 3:47 PM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [clue] Advertising what is in an MCC - allow wildcard?
> 
> Paul,
> 
> Yes, I think the wildcard is just a syntax shortcut.
> One other impact that I was thinking of is if we decide to have partial updates
> of advertisements then it removes the need to re-advertise any MCC(*)
> captures when other captures change.  Without wildcard, any other addition
> or removal of a contributing capture means also re-advertising every MCC
> with a new list of contributors.
> I think the wildcard fits very nicely with the switching scenario option (2) from
> the other discussion thread.
> 
> Mark
> 
> > -----Original Message-----
> > From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> > Sent: Friday, January 10, 2014 1:24 PM
> > To: [email-masked]
> > Subject: Re: [clue] Advertising what is in an MCC - allow wildcard?
> >
> > On 1/9/14 5:11 PM, Duckworth, Mark wrote:
> > > In an advertisement, the provider can indicate which other captures
> > > are referenced by an MCC, for example:
> > >
> > > Individual captures advertised: VC1, VC2, VC3, VC4, VC5
> > >
> > > MCC1(VC1, VC2)
> > >
> > > This means MCC1 can include VC1 and/or VC2, but not the others.
> > >
> > > MCC2()
> > >
> > > Without any specific references, this means the provider is not
> > > saying which other captures can be included in MCC2, and the
> > > consumer cannot choose.
> > >
> > > I propose adding a wildcard:
> > >
> > > MCC3(*)
> >
> > IIUC you mean this to be strictly a syntactic shortcut, not adding any
> > functionality that isn't present without it.
> >
> > > This means MCC3 can include any of the other captures VC1 through
> > > VC5, and the consumer can choose.
> >
> > Do you intent this to mean all the captures in the advertisement, or
> > all the captures in the same scene?
> >
> > > For some types of MCUs, that want to give consumers the choice of
> > > which specific captures to receive in an MCC, this is useful for
> > > large advertisements with many media captures.
> >
> > Perhaps. But I have my doubts that this would be of common use in
> practice.
> >
> > So it becomes a question of whether the added implementation burden of
> > supporting this optimization is justified for the number of cases when
> > it would be of use.
> >
> > 	Thanks,
> > 	Paul
> >
> > > When endpoints join or leave a
> > > conference, causing the advertisement to change to add or remove
> > > scenes and captures, the part of the advertisement with MCCs
> > > wouldn't have to change at all.
> > >
> > > Related text from framework-13:
> > >
> > >  From 7.2: "The MCC may contain a reference to the Single Media
> > > Captures... (or) A MCC MAY contain no references to other Captures
> > > to indicate that the MCC contains content from multiple sources but
> > > no information regarding those sources is given."  And in section 10
> > > "If the MCC in the advertisement does not reference any individual
> > > captures, then the Consumer cannot choose what is included in the MCC"
> > >
> > > I propose adding text:
> > >
> > > The MCC may contain a wildcard reference, meaning it can refer to
> > > any of the other captures in the advertisement.  The consumer, in a
> > > configure message, may choose which of the other media captures it
> > > wishes to receive in the MCC.
> > >
> > > What do you think?
> > >
> > > Mark
> > >
> > >
> > >
> > > _______________________________________________
> > > clue mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/clue
> > >
> >
> > _______________________________________________
> > clue mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/clue
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Jan 2014 12:20:47 -0500

> If the group agrees with this concept, I can propose specific changes to the framework.

This WFM, conceptually.
There are details to be worked out for this to be practical and 
convenient. Those details will presumably be in the data model.

Specifically, in the declaration of the MCC, there must be some syntax 
for the reference. Two approaches come to mind:

1) the new labels share a single namespace with capture ids in the 
advertisement. The MCC declaration has an element that is used to 
reference these IDs, of either kind. You can tell which kind by 
resolving the reference.

2) the new labels have a distinct namespace from capture ids. The MCC 
declaration allows two different kinds of elements, one to reference 
capture ids, and another to reference these new labels.

I'm inclined to prefer (2) - it seems less kludgy, and is probably 
equally concise.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Mon, 20 Jan 2014 13:55:27 +1100

I'd like some more explanation of the concept before agreeing.

The reason why I went with CaptureIDs for the MCC and the individual 
captures was to prevent yet another namespace in CLUE. It also worked in 
with the fact that the Consumer currently only returns CaptureIDs and 
EncodingIDs. Are we now saying that an Advertiser sends MCC1(label1) and 
if a Consumer wants a subset it returns MCC(Capture1, Capture2, 
Capture3, etc?). I particularly avoided the use of attributes for this 
because CLUE Configures don't reference attributes.

Why couldn't CLUE simply have pattern matching based on regular 
expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.).

Christian

On 19/01/2014 4:20 AM, Paul Kyzivat wrote:
>> We discussed this topic in the Jan 14 design team meeting.  The group 
>> had interest in the concept, but not my specific proposal.  Jonathan 
>> had an interesting idea, which I think better serves the purpose.
>>
>> Instead of the MCC referring specifically to other media captures 
>> that can be contained within the MCC, the MCC can refer to zero or 
>> more "MCC grouping labels".  Any other media capture can include an 
>> attribute (zero or more) with a particular MCC grouping label.  The 
>> meaning is that any MC that has the same grouping label that is 
>> reference by an MCC can be included in that MCC.
>>
>> I think this doesn't change at all the meaning of MCC, but it will 
>> affect the syntax of how we describe it in the data model for CLUE 
>> messages.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2014 13:14:31 -0500

> because CLUE Configures don't reference attributes.

My thought was that the the consumer could return:

- MCC()
- MCC(capture1, capture2, ...)
- MCC(label1)
- MCC(label1, label2, ...)
- MCC(capture1, label1, ...)

> expressions the ID? i.e. (VC. or VC[1-5] or .C1 etc.).

That is a possibility. I question whether it is simpler. I guess it does 
make advertisements smaller.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 20 Jan 2014 13:46:12 -0800

Paul and Christian,

I was thinking much the same as Paul's approach 2.  But maybe the configure message could be limited to something like this?:
- MCC()
- MCC(capture1, capture2,...)

In the configure message, I'm not sure there is an advantage to specifying MCC subsets by label rather than always using capture ID.

I always thought of the capture IDs as just a unique identifier, with no intrinsic meaning, like GUIDs.  That's why specifying groups of them with ranges (VC1 through VC4) or regular expressions doesn't make sense to me.  Putting more meaning into the identifiers seems like a big change to me.

Mark

> Sent: Monday, January 20, 2014 1:15 PM
> To: [email-masked]
> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in an MCC -
> allow wildcard?
> 
> > captures was to prevent yet another namespace in CLUE. It also worked
> > in with the fact that the Consumer currently only returns CaptureIDs
> > and EncodingIDs. Are we now saying that an Advertiser sends
> > MCC1(label1) and if a Consumer wants a subset it returns MCC(Capture1,
> > Capture2, Capture3, etc?). I particularly avoided the use of
> > attributes for this because CLUE Configures don't reference attributes.
> 
> That is a possibility. I question whether it is simpler. I guess it does make
> advertisements smaller.
> 
> 	Thanks,
> 	Paul
> 
> > Christian
> >
> >
> >>> We discussed this topic in the Jan 14 design team meeting.  The
> >>> group had interest in the concept, but not my specific proposal.
> >>> Jonathan had an interesting idea, which I think better serves the
> purpose.
> >>>
> >> Specifically, in the declaration of the MCC, there must be some
> >> syntax for the reference. Two approaches come to mind:
> >>
> >>>> One other impact that I was thinking of is if we decide to have
> >>>> partial updates of advertisements then it removes the need to
> >>>> re-advertise any MCC(*) captures when other captures change.
> >>>> Without wildcard, any other addition or removal of a contributing
> >>>> capture means also re-advertising every MCC with a new list of
> >>>> contributors.
> >>>> I think the wildcard fits very nicely with the switching scenario
> >>>> option (2) from the other discussion thread.
> >>>>
> >>>> Mark
> >>>>
> >>>>>> In an advertisement, the provider can indicate which other
> >>>>>> captures are referenced by an MCC, for example:
> >>>>>>
> >>>>> IIUC you mean this to be strictly a syntactic shortcut, not adding
> >>>>> any functionality that isn't present without it.
> >>>>>
> >>>>> Do you intent this to mean all the captures in the advertisement,
> >>>>> or all the captures in the same scene?
> >>>>>
> >>>>> So it becomes a question of whether the added implementation
> >>>>> burden of supporting this optimization is justified for the number
> >>>>> of cases when it would be of use.
> >>>>>
> >>>>>     Thanks,
> >>>>>     Paul
> >>>>>
> >>>>>> Captures... (or) A MCC MAY contain no references to other
> >>>>>> Captures to indicate that the MCC contains content from multiple
> >>>>>> sources but no information regarding those sources is given."
> >>>>>> And in section 10 "If the MCC in the advertisement does not
> >>>>>> reference any individual captures, then the Consumer cannot
> >>>>>> choose what is included in the MCC"
> >>>>>>
> >>>>>> I propose adding text:
> >>>>>>
> >>>>>> any of the other captures in the advertisement.  The consumer, in
> >>>>>> a configure message, may choose which of the other media captures
> >>>>>> it wishes to receive in the MCC.
> >>>>>>
> >>>>>> What do you think?
> >>>>>>
> >>>>>> Mark
> >>>>>>
> >>>>>>
> >>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 20 Jan 2014 17:15:17 -0500

Hmm. I now realize I didn't say what I meant. What I meant was:

My thought was that the the advertiser could specify *any* of:

While the consumer could return either of:

- MCC()

	Sorry,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 21 Jan 2014 09:40:46 +1100

I think before going for the label approach I think it would be worth to 
go through some examples and compare the size of the messages, i.e. 
comparing using the CaptureIDs vs Labels. Actually I think we need some 
more examples in general to understand the savings for wildcarding. If 
you have to specify an attribute with possibly several labels on each 
Capture then we might not be saving much (if anything) for the complexity.

Also if we mix captures and label then I assume that we have to define 
the name space for each to ensure they didn't overlap? Currently 
captureIDs could be anything.

With respect to putting meaning into the CaptureIDs is it really a big 
change for captureIDs to have some meaning within the session? Our 
convention in the framework of ACx, VCx, etc seems to be working quite 
well. I'm not sure why you'd want the CaptureID to be globally unique 
like a GUID? That seems like overkill. If people are assuming that 
CaptureIDs are globally unique across a MCU or network then I think we 
need to discuss that because I not sure everyone has the same view.

Regards, Christian

On 21/01/2014 9:15 AM, Paul Kyzivat wrote:
>> I was thinking much the same as Paul's approach 2.  But maybe the 
>> configure message could be limited to something like this?:
>> - MCC()
>> In the configure message, I'm not sure there is an advantage to 
>> specifying MCC subsets by label rather than always using capture ID.
>>
>> I always thought of the capture IDs as just a unique identifier, with 
>> no intrinsic meaning, like GUIDs.  That's why specifying groups of 
>> them with ranges (VC1 through VC4) or regular expressions doesn't 
>> make sense to me.  Putting more meaning into the identifiers seems 
>> like a big change to me.
>>
>> Mark
>>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 20 Jan 2014 14:49:26 -0800

No, I wasn't thinking capture IDs are globally unique, I was just using that as an example of something else where it doesn't make sense to specify ranges or use regular expressions.

Mark

> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, January 20, 2014 5:41 PM
> To: Paul Kyzivat; Duckworth, Mark; [email-masked]
> I think before going for the label approach I think it would be worth to go
> through some examples and compare the size of the messages, i.e.
> more examples in general to understand the savings for wildcarding. If you
> have to specify an attribute with possibly several labels on each Capture then
> we might not be saving much (if anything) for the complexity.
> 
> Also if we mix captures and label then I assume that we have to define the
> name space for each to ensure they didn't overlap? Currently captureIDs
> could be anything.
> 
> With respect to putting meaning into the CaptureIDs is it really a big change
> for captureIDs to have some meaning within the session? Our convention in
> the framework of ACx, VCx, etc seems to be working quite well. I'm not sure
> why you'd want the CaptureID to be globally unique like a GUID? That seems
> like overkill. If people are assuming that CaptureIDs are globally unique
> across a MCU or network then I think we need to discuss that because I not
> sure everyone has the same view.
> 
> Regards, Christian
> 
> >>> Subject: Re: [clue] MCC grouping label - RE: Advertising what is in
> >>> an MCC - allow wildcard?
> >>>
> >>>> The reason why I went with CaptureIDs for the MCC and the
> >>>> individual captures was to prevent yet another namespace in CLUE.
> >>>> It also worked in with the fact that the Consumer currently only
> >>>> returns CaptureIDs and EncodingIDs. Are we now saying that an
> >>>> Advertiser sends
> >>>> MCC1(label1) and if a Consumer wants a subset it returns
> >>>> MCC(Capture1, Capture2, Capture3, etc?). I particularly avoided the
> >>>> use of attributes for this because CLUE Configures don't reference
> >>>> attributes.
> >>>
> >>> That is a possibility. I question whether it is simpler. I guess it
> >>> does make advertisements smaller.
> >>>
> >>>     Thanks,
> >>>     Paul
> >>>
> >>>> Christian
> >>>>
> >>>>
> >>>>>> that can be contained within the MCC, the MCC can refer to zero
> >>>>>> or more "MCC grouping labels".  Any other media capture can
> >>>>>> include an attribute (zero or more) with a particular MCC
> >>>>>> grouping label.  The meaning is that any MC that has the same
> >>>>>> grouping label that is reference by an MCC can be included in that
> MCC.
> >>>>>>
> >>>>>> I think this doesn't change at all the meaning of MCC, but it
> >>>>>> will affect the syntax of how we describe it in the data model
> >>>>>> for CLUE messages.
> >>>>>>
> >>>>> 2) the new labels have a distinct namespace from capture ids. The
> >>>>> MCC declaration allows two different kinds of elements, one to
> >>>>> reference capture ids, and another to reference these new labels.
> >>>>>
> >>>>>>> Without wildcard, any other addition or removal of a
> >>>>>>> contributing capture means also re-advertising every MCC with a
> >>>>>>> new list of contributors.
> >>>>>>> I think the wildcard fits very nicely with the switching
> >>>>>>> scenario option (2) from the other discussion thread.
> >>>>>>>
> >>>>>>> Mark
> >>>>>>>
> >>>>>>>>> Without any specific references, this means the provider is
> >>>>>>>>> not saying which other captures can be included in MCC2, and
> >>>>>>>>> the consumer cannot choose.
> >>>>>>>>>
> >>>>>>>> IIUC you mean this to be strictly a syntactic shortcut, not
> >>>>>>>> adding any functionality that isn't present without it.
> >>>>>>>>
> >>>>>>>>> This means MCC3 can include any of the other captures VC1
> >>>>>>>>> through VC5, and the consumer can choose.
> >>>>>>>>
> >>>>>>>> Do you intent this to mean all the captures in the
> >>>>>>>> advertisement, or all the captures in the same scene?
> >>>>>>>>
> >>>>>>>>> For some types of MCUs, that want to give consumers the
> choice
> >>>>>>>>> of which specific captures to receive in an MCC, this is
> >>>>>>>>> useful for large advertisements with many media captures.
> >>>>>>>>
> >>>>>>>> burden of supporting this optimization is justified for the
> >>>>>>>> number of cases when it would be of use.
> >>>>>>>>
> >>>>>>>>      Thanks,
> >>>>>>>>      Paul
> >>>>>>>>
> >>>>>>>>> When endpoints join or leave a conference, causing the
> >>>>>>>>> advertisement to change to add or remove scenes and captures,
> >>>>>>>>> the part of the advertisement with MCCs wouldn't have to
> >>>>>>>>> change at all.
> >>>>>>>>>
> >>>>>>>>>    From 7.2: "The MCC may contain a reference to the Single
> >>>>>>>>> Media Captures... (or) A MCC MAY contain no references to
> >>>>>>>>> other Captures to indicate that the MCC contains content from
> >>>>>>>>> multiple sources but no information regarding those sources is
> given."
> >>>>>>>>> The MCC may contain a wildcard reference, meaning it can refer
> >>>>>>>>> to any of the other captures in the advertisement. The
> >>>>>>>>> consumer, in a configure message, may choose which of the
> >>>>>>>>> other media captures it wishes to receive in the MCC.
> >>>>>>>>>
> >>>>>>>>> What do you think?
> >>>>>>>>>
> >>>>>>>>> Mark
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>

---

From: Christian Groves <[email-masked]>
Date: Tue, 21 Jan 2014 10:08:10 +1100

Hello Mark,

I agree it doesn't make sense for specifying ranges etc for GUIDs but I 
think comparing GUIDs and CaptureIDs isn't fair because they are 
different beasts. As I mentioned below the scope of CaptureIDs is for a 
particular session. Would generating an ID according to a pattern be 
much of a burden compared to generating a random number for a limited 
set of IDs such as one would find in a session? It might have additional 
benefits when it comes to trouble shooting.

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 21 Jan 2014 05:03:01 -0800

Hello Christian,
Regarding the size of messages, I think in general the label idea will reduce the size.  Take Capture Scene #8 from the framework section 12.3.3 as an example.  Let's count the number of "tags" (or elements, or attributes, or whatever you want to call them) we need to indicate the associations between MCCs and other captures.

MCC4 through MCC12, each referring to 12 individual captures.  That is 9 x 12 = 108 "tags".

With the labeling mechanism, each of the 12 individual captures has just one MCC grouping label, and they can all be the same value.  That is 12 "tags".  Plus each MCC has just one grouping label, again the same value, so that is 9 more tags.  Total of just 21 "tags" vs. 108 "tags".  So that is a big savings using the labeling mechanism.

Mark

---

From: Christian Groves <[email-masked]>
Date: Wed, 22 Jan 2014 11:03:53 +1100

Hello Mark,

That is a saving. If we used something like VC4-V15 in each MCC that 
would be a bigger saving again as there would be no label.

I'm not against the label concept I think it just needs to be considered 
against some examples.
I think the other thing to consider is the multiple use case. If you 
were to take 12.3.3 and wanted to use the labels for all the VCs in MCCs 
then you end up with:

VC1
VC2
VC3
VC4(label=1,4)
VC5(label=2,4)
VC6(label=3,4)
VC7(label=1,4)
VC8(label=2,4)
VC9(label=3,4)
VC10(label=1,4)
VC11(label=2,4)
VC12(label=3,4)
VC13(label=1,4)
VC14(label=2,4)
VC15(label=3,4)

A further issue is would label also apply to MCCs and CSEs? i.e. in 
tables 23 and 24 of the framework we use the same IDs in the CSE and 
MCC13. There would be a saving also if we could use "label" for both 
these instances.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jan 2014 13:17:38 -0500

> would be a bigger saving again as there would be no label.

I think I have finally understood what you are proposing. I agree that 
it could work to allow use of regular expressions applied to capture ids 
to select individual captures within the same advertisement, in the 
specification of MCCs, and possibly in CSEs too.

That would be an alternative to using separate labels. And as long as it 
is used just within the advertisement, the same entity is assigning the 
capture ids and constructing the REs that reference them, so has full 
freedom to construct the capture ids in a way that makes it convenient 
to write REs that match what it wants to match.

In principle the REs could also be used in Configure messages to select 
the subset of captures desired in an MCC. But I think it would have 
little value there, because it would be difficult to automate the 
construction of the REs for an arbitrary advertisement. (For that 
matter, its not clear to me how the consumer chooses a subset at all. 
The most likely things I can imagine are:
- some algorithm chooses a complete CSE and displays it.
   Then user can request to have some portion of the display omitted.
- some algorithm gives previews of possible layouts and lets users
   pick, with omissions.
All if these involve identifying specific captures identified in the 
advertisement. The capture ids probably aren't interesting to the end 
user. So selection is based on picking particular captures, not REs.)

So I see no reason to use REs in the Configure.

The downside of REs, if there is one, is that they may be more complex 
to implement in some contexts. (Though there are RE libraries for most 
environments.) They might also be slightly more costly in computation, 
but probably not enough to matter.

We would of course need to choose a precise definition of RE syntax.

> were to take 12.3.3 and wanted to use the labels for all the VCs in MCCs

When using labels, it would be easier to follow if the labels had some 
significance. E.g. labels like "left", "center", "right".

> MCC13. There would be a saving also if we could use "label" for both

With either labels or REs, it does seem to make sense to allow their use 
in both MCCs and CSEs.

	Thanks,
	Paul

>> Regarding the size of messages, I think in general the label idea will
>> reduce the size.  Take Capture Scene #8 from the framework section
>> 12.3.3 as an example.  Let's count the number of "tags" (or elements,
>> or attributes, or whatever you want to call them) we need to indicate
>> the associations between MCCs and other captures.
>>
>> With the labeling mechanism, each of the 12 individual captures has
>> just one MCC grouping label, and they can all be the same value.  That
>> is 12 "tags".  Plus each MCC has just one grouping label, again the
>> same value, so that is 9 more tags.  Total of just 21 "tags" vs. 108
>> "tags".  So that is a big savings using the labeling mechanism.
>>
>> Mark
>>
>>> an MCC -

---

From: Christian Groves <[email-masked]>
Date: Thu, 23 Jan 2014 12:44:01 +1100

Hello Paul,

Please see my comments below.

Regards, Christian

On 23/01/2014 5:17 AM, Paul Kyzivat wrote:
> it could work to allow use of regular expressions applied to capture 
> ids to select individual captures within the same advertisement, in 
> the specification of MCCs, and possibly in CSEs too.
>
> That would be an alternative to using separate labels. And as long as 
> it is used just within the advertisement, the same entity is assigning 
> the capture ids and constructing the REs that reference them, so has 
> full freedom to construct the capture ids in a way that makes it 
> convenient to write REs that match what it wants to match.
[CNG] Yes I agree the intention would only to be to use it in the 
advertisement.
>
> In principle the REs could also be used in Configure messages to 
> select the subset of captures desired in an MCC. But I think it would 
> have little value there, because it would be difficult to automate the 
[CNG] I agree. I don't see the need for labels either.
> We would of course need to choose a precise definition of RE syntax.
[CNG] Yes
> significance. E.g. labels like "left", "center", "right".
[CNG] Easier to follow for who? In terms of a consumer the labels are 
really just related to the syntax so probably wouldn't be seen by a 
person. I think in this case any random label would be sufficient. If we 
want spatial significance better to use spatial parameters.

> With either labels or REs, it does seem to make sense to allow their 
> use in both MCCs and CSEs.
>
>     Thanks,
>     Paul
>
>> Regards, Christian
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jan 2014 10:26:27 -0500

> want spatial significance better to use spatial parameters.

In use I agree it doesn't matter.
But in the *examples* it is easier if they have some significance.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 24 Jan 2014 08:15:41 -0800

It sounds like a few of us are agreeing in principle that there could be better ways of expressing in an advertisement which captures can be included in an MCC rather than just giving a list of captures as part of the MCC description.

For the framework document, I think it already covers as much detail that is appropriate for that document, basically this:
- in an advertisement, an MCC may contain a reference to the other media captures contained in the MCC
- in a configure message, an MCC may contain a reference to the other media captures the consumer wishes to receive as part of the MCC

Details of the syntax for how to represent this should be in the data model.  I don't think there are any other issues about this that belong in the framework.  Our discussion about grouping labels and regular expressions should apply to the data model.  Does this make sense?

Mark

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, January 23, 2014 10:26 AM
> To: Christian Groves; Duckworth, Mark; [email-masked]
> >> When using labels, it would be easier to follow if the labels had
> >> some significance. E.g. labels like "left", "center", "right".
> > person. I think in this case any random label would be sufficient. If
> > we want spatial significance better to use spatial parameters.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jan 2014 11:46:30 -0500

> Details of the syntax for how to represent this should be in the data model.  I don't think there are any other issues about this that belong in the framework.  Our discussion about grouping labels…

WFM

---

From: Christian Groves <[email-masked]>
Date: Tue, 28 Jan 2014 14:37:15 +1100

Hello Mark,

In general I agree that this could be part of the data model but I think 
if we were to use this in the examples in the framework then we would 
also need to talk briefly about the label concept in the framework.

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 28 Jan 2014 09:24:05 -0800

Christian,

I think the framework does not need to say whether or not the associations between MCC and constituent captures are made in XML by direct reference to capture ID, regular expression describing capture ID, by using some other label, or any other means.  The framework should just say there is an association, and the details are in the data model.

The interim meeting Jan 27 agreed with this position.

Regards,
Mark

> From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
> Sent: Monday, January 27, 2014 10:37 PM
> To: [email-masked]
> In general I agree that this could be part of the data model but I think if we
> were to use this in the examples in the framework then we would also need
> to talk briefly about the label concept in the framework.
> 
> Regards, Christian
> 
> > It sounds like a few of us are agreeing in principle that there could be
> better ways of expressing in an advertisement which captures can be
> included in an MCC rather than just giving a list of captures as part of the MCC
> description.
> >
> > For the framework document, I think it already covers as much detail that is
> appropriate for that document, basically this:
> > - in a configure message, an MCC may contain a reference to the other
> > media captures the consumer wishes to receive as part of the MCC
> >
> > Details of the syntax for how to represent this should be in the data model.
> I don't think there are any other issues about this that belong in the
> framework.  Our discussion about grouping labels and regular expressions
> should apply to the data model.  Does this make sense?
> >
> > Mark
> >
> >>> [CNG] Easier to follow for who? In terms of a consumer the labels
> >>> are really just related to the syntax so probably wouldn't be seen
> >>> by a person. I think in this case any random label would be
> >>> sufficient. If we want spatial significance better to use spatial
> parameters.

---

From: Christian Groves <[email-masked]>
Date: Wed, 29 Jan 2014 09:52:03 +1100

Hello Mark,

I think maybe you've misunderstood my email. I didn't ask for a treatise 
on labels to be added, I did use "briefly" and "concept" in my email 
below. If we want to show the labels being used in the examples in 
framework then we need to explain something about them. Otherwise people 
won't know how to interpret it.

If we don't use labels in the examples in the framework then there is no 
issue.

Regards,
Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 28 Jan 2014 14:56:55 -0800

Hi Christian,
I didn't expect framework examples to use labels or regular expressions for this, so I agree there is no issue.
Mark

> Sent: Tuesday, January 28, 2014 5:52 PM
> To: Duckworth, Mark; [email-masked]
> I think maybe you've misunderstood my email. I didn't ask for a treatise on
> labels to be added, I did use "briefly" and "concept" in my email below. If we
> want to show the labels being used in the examples in framework then we
> need to explain something about them. Otherwise people won't know how
> to interpret it.
> 
> > I think the framework does not need to say whether or not the
> associations between MCC and constituent captures are made in XML by
> direct reference to capture ID, regular expression describing capture ID, by
> using some other label, or any other means.  The framework should just say
> there is an association, and the details are in the data model.
> >
> >> In general I agree that this could be part of the data model but I
> >> think if we were to use this in the examples in the framework then we
> >> would also need to talk briefly about the label concept in the framework.
> >>
> >> Regards, Christian
> >>
> >> included in an MCC rather than just giving a list of captures as part
> >> of the MCC description.
> >>> - in a configure message, an MCC may contain a reference to the
> >>> other media captures the consumer wishes to receive as part of the
> >>> MCC
> >>>
> >> I don't think there are any other issues about this that belong in
> >> the framework.  Our discussion about grouping labels and regular
> >> expressions should apply to the data model.  Does this make sense?
> >>> Mark
> >>>