Subject: [clue] data model for specifying attribute value in Configure message

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 12 Jul 2013 13:54:35 -0700

I think the data model is intended to support building a Configure message by using a list of captureEncoding elements.  If so, there also needs to be a way to add parameter values of items where the Provider has offered a choice.

>From the framework:
  For each Media Capture in the message, the Consumer may also
  specify the value of any attributes for which the Provider has
  offered a choice, for example the value for the Scene-switch-policy
  attribute.

Currently, I think Scene-switch-policy is the only attribute in this category.

Does it make sense to add an element to do this into the captureEncodingType?  This is similar to item 11 in my other list of comments http://www.ietf.org/mail-archive/web/clue/current/msg02666.html.

Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jul 2013 17:08:46 -0400

I've brought this up before, but I'll try again:

As currently conceived, this mechanism has problems.

Specifically, these attributes apply to captures, not capture-encodings.

Suppose I configure two different encodings of the same capture, and 
supply different attributes to each. (E.g. one with site switching and 
one with scene switching.)

At that point, what is the meaning of the capture? I have two encodings 
which may be showing entirely different content. IMO this is nonsense.

So I think there is a problem with attributes that can be specified in 
the configure. There are a variety of possible solutions. The simplest 
is simply to disallow them.

	Thanks,
	Paul

On 7/12/13 4:54 PM, Duckworth, Mark wrote:
> I think the data model is intended to support building a Configure
> message by using a list of captureEncoding elements.  If so, there also
> needs to be a way to add parameter values of items where the Provider
> has offered a choice.
>
>  From the framework:
>
> Does it make sense to add an element to do this into the
> captureEncodingType?  This is similar to item 11 in my other list of
> comments http://www.ietf.org/mail-archive/web/clue/current/msg02666.html.
>
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 12 Jul 2013 14:44:46 -0700

Paul, I agree it doesn't make sense to include different values of the attribute for the same capture.  This is related to the statement in the framework in section 6.2.2 "The Consumer must choose the same value for all the Media Captures in the Capture Scene Entry."  So for me, the question is should we devise an XML schema for this such that it is impossible for the Consumer to construct an inconsistent message?  Or is it okay to have a schema with potentially redundant information, thus enabling the possibility for the values to be inconsistent?  My proposal allows the inconsistency, and I agree it would be better to avoid the redundancy and possibility of inconsistency.  I could make another proposal along those lines later.

Are you saying there are also other problems with attributes that can be specified in the Configure message?  What about specifying the encoding parameters, we agreed on that before didn't we?  That is very similar to specifying attribute values.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Friday, July 12, 2013 5:09 PM
> To: [email-masked]
> Subject: Re: [clue] data model for specifying attribute value in Configure
> message
> 
> Suppose I configure two different encodings of the same capture, and supply
> different attributes to each. (E.g. one with site switching and one with scene
> switching.)
> 
> So I think there is a problem with attributes that can be specified in the
> configure. There are a variety of possible solutions. The simplest is simply to
> disallow them.
> 
> 	Thanks,
> 	Paul
> 
> 
> 
> > message by using a list of captureEncoding elements.  If so, there
> > also needs to be a way to add parameter values of items where the
> > Provider has offered a choice.
> >
> >  From the framework:
> >

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jul 2013 13:06:13 +1000

Hello Mark,

I don't think the rule regarding CSE helps. The configure only lists the 
CaptureID/EncodingID, no CSE or SceneID. The trouble with having 
parameters in the Configure is that effectively a CaptureID no longer 
lists a unique capture. You could in theory have a CaptureID with 
different sets of attributes. An Advertisement could offer a CaptureID 
with multiple values and a set of encodings. A consumer could in theory 
return the same CaptureID multiple times with different values and the 
same encoding ID. This would lead to the same CaptureEncoding which 
would cause referencing issues.

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 17 Jul 2013 08:45:56 -0700

Hi Christian,

I think I understand your point, and it does seem like an issue in the data-model-schema-00 document, section 22.

<!-- CAPTURE ENCODING TYPE -->
<xs:complexType name="captureEncodingType">
  <xs:sequence>
    <xs:element name="mediaCaptureID" type="xs:string"/>
    <xs:element name="encodingID" type="xs:string"/>
    <xs:element name="captureParameters" type="captureParametersType" minOccurs="0"/>
    <xs:element name="encodingParameters" type="encodingParametersType" minOccurs="0"/>
  </xs:sequence>
  <xs:attribute name="ID" type="xs:ID"/>
</xs:complexType>

This structure requires the captureParameters to be specified for each captureEncodingType, but this isn't what we want.  I think it would be better to have a structure that specifies a mediaCaptureID just once, with just one corresponding captureParameters element, but with a list of encodingID and encodingParameters to represent the multiple encodings of the single media capture.

Mark

> Christian Groves
> Sent: Sunday, July 14, 2013 11:06 PM
> To: [email-masked]
> parameters in the Configure is that effectively a CaptureID no longer lists a
> unique capture. You could in theory have a CaptureID with different sets of
> attributes. An Advertisement could offer a CaptureID with multiple values
> and a set of encodings. A consumer could in theory return the same
> CaptureID multiple times with different values and the same encoding ID.
> This would lead to the same CaptureEncoding which would cause referencing
> issues.
> 
> Regards, Christian
> 
> > Paul, I agree it doesn't make sense to include different values of the
> attribute for the same capture.  This is related to the statement in the
> framework in section 6.2.2 "The Consumer must choose the same value for
> all the Media Captures in the Capture Scene Entry."  So for me, the question
> is should we devise an XML schema for this such that it is impossible for the
> Consumer to construct an inconsistent message?  Or is it okay to have a
> schema with potentially redundant information, thus enabling the possibility
> for the values to be inconsistent?  My proposal allows the inconsistency, and
> I agree it would be better to avoid the redundancy and possibility of
> inconsistency.  I could make another proposal along those lines later.
> >
> > Are you saying there are also other problems with attributes that can be
> specified in the Configure message?  What about specifying the encoding
> parameters, we agreed on that before didn't we?  That is very similar to
> specifying attribute values.
> >
> > Mark
> >
> >> From: [email-masked] [mailto:[email-masked]] On Behalf
> >> Of Paul Kyzivat
> >> Subject: Re: [clue] data model for specifying attribute value in
> >> Configure message
> >>
> >> supply different attributes to each. (E.g. one with site switching
> >> and one with scene
> >> switching.)
> >>
> >> At that point, what is the meaning of the capture? I have two
> >> encodings which may be showing entirely different content. IMO this is
> nonsense.
> >>
> >> So I think there is a problem with attributes that can be specified
> >> in the configure. There are a variety of possible solutions. The
> >> simplest is simply to disallow them.
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >>
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jul 2013 12:02:22 -0400

This *helps*. But it still means that a capture is only unique in the 
context of a configure. For instance this means that an MCU can't 
construct a capture once for all the endpoints that configure it.

Of course this is true for capture-encodings too. But the effect is to 
constrain the architecture, putting the implementation of 
switching/composition into the encoding side of the pipeline. Maybe that 
is fine - I don't know the implementation details. But it is worth 
considering.

But for me it is a conceptual issue - it fuzzes up what "capture" *means*.

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 17 Jul 2013 09:53:38 -0700

Hi Paul,

Comments inline.

Mark

> Sent: Wednesday, July 17, 2013 12:02 PM
> To: [email-masked]
> This *helps*. But it still means that a capture is only unique in the context of
> a configure.

[Duckworth, Mark]  But to begin with, a capture is only unique within the context of an advertisement.  Then a configure references an advertisement.  I don't see the problem with specifying an attribute in the configure, for which the MCU has advertised choices.  I view it as a shorthand for advertising separate captures with separate attribute values.  I thought that was the motivation for including the "select a value from the advertised choices" mechanism (for the scene-switch-policy attribute).

[Duckworth, Mark]  If we remove this mechanism, and simply have the Provider advertise separate captures with separate attribute values, would this address your concern?

> For instance this means that an MCU can't construct a capture
> once for all the endpoints that configure it.

 [Duckworth, Mark] It would be an internal implementation detail if an MCU wants to relate captures from one advertisement in one CLUE protocol session to captures in another advertisement in another CLUE protocol session.  From CLUE protocol point of view, there should be no relationship.

> Of course this is true for capture-encodings too. But the effect is to constrain
> the architecture, putting the implementation of switching/composition into
> the encoding side of the pipeline. Maybe that is fine - I don't know the
> implementation details. But it is worth considering.

 [Duckworth, Mark] I don't follow what you are trying to say.

> >      <xs:element name="captureParameters"
> type="captureParametersType" minOccurs="0"/>
> >      <xs:element name="encodingParameters"
> type="encodingParametersType" minOccurs="0"/>
> >    </xs:sequence>
> >    <xs:attribute name="ID" type="xs:ID"/> </xs:complexType>
> >
> > This structure requires the captureParameters to be specified for each
> captureEncodingType, but this isn't what we want.  I think it would be better
> to have a structure that specifies a mediaCaptureID just once, with just one
> corresponding captureParameters element, but with a list of encodingID and
> encodingParameters to represent the multiple encodings of the single media
> capture.
> >
> > Mark
> >
> >> Of Christian Groves
> >> I don't think the rule regarding CSE helps. The configure only lists
> >> the CaptureID/EncodingID, no CSE or SceneID. The trouble with having
> >> different sets of attributes. An Advertisement could offer a
> >> CaptureID with multiple values and a set of encodings. A consumer
> >> could in theory return the same CaptureID multiple times with different
> values and the same encoding ID.
> >> This would lead to the same CaptureEncoding which would cause
> >> referencing issues.
> >>
> >> Regards, Christian
> >>
> >> attribute for the same capture.  This is related to the statement in
> >> the framework in section 6.2.2 "The Consumer must choose the same
> >> value for all the Media Captures in the Capture Scene Entry."  So for
> >> me, the question is should we devise an XML schema for this such that
> >> it is impossible for the Consumer to construct an inconsistent
> >> message?  Or is it okay to have a schema with potentially redundant
> >> information, thus enabling the possibility for the values to be
> >> inconsistent?  My proposal allows the inconsistency, and I agree it
> >> would be better to avoid the redundancy and possibility of inconsistency.
> I could make another proposal along those lines later.
> >>>
> >> specified in the Configure message?  What about specifying the
> >> encoding parameters, we agreed on that before didn't we?  That is
> >> very similar to specifying attribute values.
> >>>
> >>> Mark
> >>>
> >>>> From: [email-masked] [mailto:[email-masked]] On
> >>>> Behalf Of Paul Kyzivat
> >>>> Suppose I configure two different encodings of the same capture,
> >>>> and supply different attributes to each. (E.g. one with site
> >>>> switching and one with scene
> >>>> switching.)
> >>>>
> >>>>> captureEncodingType?  This is similar to item 11 in my other list
> >>>>> of comments http://www.ietf.org/mail-
> >>>> archive/web/clue/current/msg02666.html.
> >>>>> Mark
> >>>>>
> >>>>>
> >>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Jul 2013 13:16:05 -0400

> [Duckworth, Mark]  But to begin with, a capture is only unique within the context of an advertisement.  Then a configure references an advertisement.  I don't see the problem with specifying an att…

See below comment.

> [Duckworth, Mark]  If we remove this mechanism, and simply have the Provider advertise separate captures with separate attribute values, would this address your concern?

Yes.

>   [Duckworth, Mark] It would be an internal implementation detail if an MCU wants to relate captures from one advertisement in one CLUE protocol session to captures in another advertisement in anot…

Yes, I agree it is. But I can imagine that an implementation might find 
it important to share as much as possible of the processing pipeline 
between multiple endpoints. We should at least be mindful if we are 
making this more difficult.

OTOH, I suppose an MCU that wants to do that could construct its 
advertisements so that they don't provide any inconvenient configure 
options.

>   [Duckworth, Mark] I don't follow what you are trying to say.

I'm saying that if a capture offers multiple encodings, then that 
presents some of the same issues - that different encodings of a capture 
might need to be generated depending on what is configured.

I'm assuming there is some sort of processing pipeline, from reception, 
decoding, switching & composition, encoding. The question is how much of 
this pipeline can be common among different endpoints of the MCU.

But I'm probably obsessing.

>> But for me it is a conceptual issue - it fuzzes up what "capture" *means*.

And this is the fundamental issue to me. With this kind of 
parameterization, what is the definition of a capture, independent of 
the configuration parameters? Can we explain it in a way that makes 
sense? (Especially to people not intimately involved in clue.)

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2013 11:15:47 +1000

Hello Mark,

What is needed is a structure that only allows one set of 
captureParameters per mediaCaptureID AND that the chosen set of 
captureParameters are used in all CaptureEncodings that reference the 
mediaCaptureID. This guarantees uniqueness.

Having such a restriction does have side effects. For example: if the 
Provider indicates the support of segment and site switched for one 
CaptureID and the consumer wants both types of Captures in different 
capture encodings then this would not be possible. For this to be 
possible the Provider would have to Advertise one CaptureID with 
"segment" and another CaptureID with "site". If this is the case then 
the question is, is there any point in having a list of values in the 
first place?

Regards, Christian

---

From: "Duckworth, Mark" <[email-masked]>
Date: Wed, 17 Jul 2013 18:40:05 -0700

> Sent: Wednesday, July 17, 2013 9:16 PM
> To: [email-masked]
> What is needed is a structure that only allows one set of captureParameters
> per mediaCaptureID AND that the chosen set of captureParameters are used
> in all CaptureEncodings that reference the mediaCaptureID. This guarantees
> uniqueness.

[Duckworth, Mark] Yes, this is exactly what I was trying to suggest.

> Having such a restriction does have side effects. For example: if the Provider
> indicates the support of segment and site switched for one CaptureID and
> the consumer wants both types of Captures in different capture encodings
> then this would not be possible. For this to be possible the Provider would
> have to Advertise one CaptureID with "segment" and another CaptureID
> with "site". If this is the case then the question is, is there any point in having
> a list of values in the first place?

[Duckworth, Mark] It sounds like you and Paul are both suggesting we remove this "advertise a choice of values for the Consumer to choose from" mechanism from the scene-switch-policy attribute.  Instead, just use it like all the other attributes where the Advertisement indicates the attribute and its value.  Then we could also simplify the data model, removing the captureParameters element.  That would be fine with me.

---

From: Christian Groves <[email-masked]>
Date: Thu, 18 Jul 2013 13:09:29 +1000

Hello Mark,

Actually I'm torn on this one. Being able to provide a list of values 
and have the Consumer choose seems like a good capability to be built 
into the protocol. However the implementation becomes problematic and 
adds complications. I had thought about the Consumer appending the 
mediaCaptureID i.e. 1a, 1b, 1c if it wants multiple instances but how 
would that work with STS? Also what would be the interaction when there 
are multiple set of attributes that have multiple values? Without a 
simple way to introduce it may be simpler to KISS and remove the 
captureParameters element. However if someone can come up with a way to 
support it I'm all ears :-).

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jul 2013 11:02:05 -0400

On 7/17/13 9:15 PM, Christian Groves wrote:
> capture encodings then this would not be possible.

Another consequence of this is that putting the switching attribute on a 
CSE makes little sense. Rather the attribute needs to be on the 
individual captures. (Putting it on the CSE causes trouble if the same 
capture appears in more than one CSE with different attribute values.)

	Thanks,
	Paul

> For this to be
>> I think I understand your point, and it does seem like an issue in the
>> data-model-schema-00 document, section 22.
>>
>> captureEncodingType, but this isn't what we want.  I think it would be
>> better to have a structure that specifies a mediaCaptureID just once,
>> with just one corresponding captureParameters element, but with a list
>> of encodingID and encodingParameters to represent the multiple
>> encodings of the single media capture.
>>
>> Mark
>>
>>> Configure
>>> lists a
>>> referencing

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Jul 2013 11:04:50 -0400

I also waffle on this. On one hand this seems like a syntactic trick to 
reduce the size of advertisements, and that might be a good thing. But 
it does have these unintended consequences.

IMO we would be better off to follow the KISS principle for now.
If that proves to be inadequate then it can be addressed later.

	Thanks,
	Paul (as individual)

On 7/17/13 11:09 PM, Christian Groves wrote:
>>> captureParameters
>>> Provider
>> [Duckworth, Mark] It sounds like you and Paul are both suggesting we
>> remove this "advertise a choice of values for the Consumer to choose
>> from" mechanism from the scene-switch-policy attribute.  Instead, just
>> use it like all the other attributes where the Advertisement indicates
>> the attribute and its value.  Then we could also simplify the data
>> model, removing the captureParameters element.  That would be fine
>> with me.
>>
>>> Regards, Christian
>>>
>>>
>>>> I think I understand your point, and it does seem like an issue in
>>>> the data-
>>> model-schema-00 document, section 22.

---

From: Roberta Presta <[email-masked]>
Date: Mon, 22 Jul 2013 17:20:28 +0200

Hi all,

to summarize:
- no more <switchingPolicies> as capture scene entry attribute
- the switching policy becomes a media capture attribute
- no more capture parameters in the capture encoding definition
Right?
It sounds definitely simpler than before.

Thanks,

Roberta

Il 18/07/2013 17:04, Paul Kyzivat ha scritto:
> I also waffle on this. On one hand this seems like a syntactic trick 
> to reduce the size of advertisements, and that might be a good thing. 
> But it does have these unintended consequences.
>
>>>> Behalf Of
>>>>>>>> encodings which may be showing entirely different content. IMO 
>>>>>>>> this
>>>>>>>> is
>>>>>> nonsense.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 22 Jul 2013 14:03:41 -0400

> It sounds definitely simpler than before.

Buts lets see if we have consensus before changing text again.

	Thanks,
	Paul