Subject: [clue] a few issues on data model draft

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 18 Jul 2012 01:22:29 +0000

Folks,

There are several issues related to the data model that we'd like us to consider. These are things that are not exactly the same as in the framework, to a lesser or greater extent. They were brought up during the data model presentation at the interim meeting. I wonder if we could work on resolving them?

List based on draft-romanow-clue-data-model-01

1.  Any problem with using media-type for capture attribute as described in the draft?

2.  Any problem with using content-type for capture attribute as described in the draft?

3.  DERIVED for capture attribute- Should we have a variable called something like DERIVED, that takes various values, one of which is composed. That would mean that if DERIVED is not =composed, that the capture is not composed, and if it =composed then it is. I don't have another descriptor to propose now, but there could be others either now or later.

Why this change from the framework? I think it is more general than composed Boolean, yet semantically similar.

This does not prevent us from having qualifiers to describe composed, to help  distinguish between different composed captures, as has  been discussed. Also, it needs to be possible to have multiple values for "DERIVED", that is the values should not be mutually exclusive.

4.  Leave switched as a Boolean as in framework. The proposal in the draft seems infeasible - we don't want CLUE  to have to include all the ways in which products might want to implement switching. It would be better to make this more general, but we have no suggestion for it at present- it does not really match the meaning of a derived capture.

5.  As part of the capture description, should we have a parameter NATIVE-ASPECT-RATIO, which indicates the aspect ratio for the capture if there is one, such as 4:3 for a video camera? The reason is that it can help rendering.

Currently it is not possible to tell whether a remote video source is natively 4:3 or 16:9, for instance. If we have this, there might usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream selection message as part of the  (e.g. in "<stream-description> / <encoding>").

6.   Multiplex ID - Value sent by consumer in its stream selection message with the encoding id and capture id. This is the mechanism by which the consumer tells the provider which multiplex id to generate that stream with, so that the consumer can demultiplex the stream correctly when receiving it.
This is the link between RTP and CLUE as discussed in draft-lennox-clue-rtp-usage.

     Think should probably be re-named.

           7.  AUDIO-RENDERING-ID -  If the notion of an audio rendering tag is

     adopted, this would be needed. It is an ID provided by the consumer to the

     provider. The provider uses the tag to associate an audio stream with a video

    stream.

Clearly this doesn't cover all the data model issues, but it's a start.

Thanks,

Andy and Allyn

---

From: "Roni Even" <[email-masked]>
Date: Wed, 18 Jul 2012 23:56:15 +0200

Hi,

Reviewed the draft, inline for your question (BTW: not all the new
attributes here are in BOLD for example captureID)

Other comments

1.       Need to add axis of capture to the media capture (now in the
framework)

2.       The capture scene text and language should be sets of (text,
language), I think is not the current structure

Thanks

Roni

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Allyn Romanow (allyn)
Sent: 18 July, 2012 3:22 AM
To: CLUE ([email-masked])
Subject: [clue] a few issues on data model draft

Folks,

There are several issues related to the data model that we'd like us to
consider. These are things that are not exactly the same as in the
framework, to a lesser or greater extent. They were brought up during the
data model presentation at the interim meeting. I wonder if we could work on
resolving them?

1.  Any problem with using media-type for capture attribute as described in
the draft?

RE: OK

2.  Any problem with using content-type for capture attribute as described
in the draft?

                RE: I did not see any difference from the framework in which
case I am OK.

3.  DERIVED for capture attribute- Should we have a variable called
something like DERIVED, that takes various values, one of which is composed.
That would mean that if DERIVED is not =composed, that the capture is not
composed, and if it =composed then it is. I don't have another descriptor to
propose now, but there could be others either now or later.

Why this change from the framework? I think it is more general than composed
Boolean, yet semantically similar.

This does not prevent us from having qualifiers to describe composed, to
help  distinguish between different composed captures, as has  been
discussed. Also, it needs to be possible to have multiple values for
"DERIVED", that is the values should not be mutually exclusive.

                RE:  I am OK if this is for future extension but am not sure
about the structure  the high level derived which has Compose and future
something (not sure what). The composed has a value (true, false) and child
elements for extensions . Is this the proposed structure?

4.  Leave switched as a Boolean as in framework. The proposal in the draft
seems infeasible - we don't want CLUE  to have to include all the ways in
which products might want to implement switching. It would be better to make
this more general, but we have no suggestion for it at present- it does not
really match the meaning of a derived capture.

                RE: I think that if we have the extension for composed as I
outlined above we can have similar here.

5.  As part of the capture description, should we have a parameter
NATIVE-ASPECT-RATIO, which indicates the aspect ratio for the capture if
there is one, such as 4:3 for a video camera? The reason is that it can help
rendering.

Currently it is not possible to tell whether a remote video source is
natively 4:3 or 16:9, for instance. If we have this, there might usefully be
a "PREFERRED-ASPECT-RATIO" in the consumer's stream selection message as
part of the  (e.g. in "<stream-description> / <encoding>").

                RE: No need, first of all it does not work with switched
capture that may have different aspect ratios. Also this is available in the
SDP as well as a way for receiver to ask for specific ratio using the SDP
image attribute.

6.   Multiplex ID - Value sent by consumer in its stream selection message
with the encoding id and capture id. This is the mechanism by which the
consumer tells the provider which multiplex id to generate that stream with,
so that the consumer can demultiplex the stream correctly when receiving it.

This is the link between RTP and CLUE as discussed in
draft-lennox-clue-rtp-usage.

               RE: I do not see the need the mapping is to the capture ID
which is a numeric value. See
http://tools.ietf.org/html/draft-even-clue-rtp-mapping-03 

           7.  AUDIO-RENDERING-ID -  If the notion of an audio rendering tag
is

     adopted, this would be needed. It is an ID provided by the consumer to
the

     provider. The provider uses the tag to associate an audio stream with a
video

    stream.

                RE; suggest to take this out at the moment until we agree if
needed and how to map.

Thanks,

Andy and Allyn

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 18 Jul 2012 20:59:37 +0000

Hi Roni,
Sure, these are easy to add-
thanks

From: Roni Even [mailto:[email-masked]]
Sent: Wednesday, July 18, 2012 2:56 PM
To: Allyn Romanow (allyn); 'CLUE'
Subject: RE: [clue] a few issues on data model draft

Hi,
Reviewed the draft, inline for your question (BTW: not all the new attributes here are in BOLD for example captureID)

Other comments

1.       Need to add axis of capture to the media capture (now in the framework)

2.       The capture scene text and language should be sets of (text, language), I think is not the current structure

Thanks
Roni

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Allyn Romanow (allyn)
Sent: 18 July, 2012 3:22 AM
To: CLUE ([email-masked]<mailto:[email-masked]>)
Subject: [clue] a few issues on data model draft

Folks,

RE: OK

                RE: I did not see any difference from the framework in which case I am OK.

                RE:  I am OK if this is for future extension but am not sure about the structure  the high level derived which has Compose and future something (not sure what). The composed has a value (true, false) and child elements for extensions . Is this the proposed structure?

                RE: I think that if we have the extension for composed as I outlined above we can have similar here.

                RE: No need, first of all it does not work with switched capture that may have different aspect ratios. Also this is available in the SDP as well as a way for receiver to ask for specific ratio using the SDP image attribute.

               RE: I do not see the need the mapping is to the capture ID which is a numeric value. See http://tools.ietf.org/html/draft-even-clue-rtp-mapping-03

    stream.

                RE; suggest to take this out at the moment until we agree if needed and how to map.

Thanks,

Andy and Allyn

---

From: "Espen Berger (espeberg)" <[email-masked]>
Date: Mon, 23 Jul 2012 15:26:45 +0000

I have two questions to the data model draft.

The first questions is related to naming differences between the CLUE framework and the CLUE data model. Some examples of differences. the framework uses Description and the data model uses capture-scene-text, the framework uses capture and the data model uses capture-description . Isn't it natural that both documents share the same vocabulary?

The second questions is related to the concept of doing a data model as the basis for both advertisement and configuration messages. Playing around with some XML examples messages it's not obvious that the two messages types share a common data model. I do see similarities between the initial advertisement, the current active configuration and the advantages of be able to describe the state of a running CLUE system. Assume this will be sorted out when we look at the details of how to do configuration in CLUE.

Additional comments inline.

-Espen

From: [email-masked] [mailto:[email-masked]] On Behalf Of Allyn Romanow (allyn)
Sent: 18. juli 2012 23:00
To: Roni Even; 'CLUE'
Subject: Re: [clue] a few issues on data model draft

Hi Roni,

From: Roni Even [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, July 18, 2012 2:56 PM
To: Allyn Romanow (allyn); 'CLUE'
Subject: RE: [clue] a few issues on data model draft

Hi,

Other comments

Thanks
Roni

Folks,

RE: OK
EBE> Supported, since its allow us to join the audio and video encodings into a single list of encodings.

                RE: I did not see any difference from the framework in which case I am OK.
               EBE> The framework use the 'content' name and the data model the 'content-type' name. Why not use the same name?

                RE:  I am OK if this is for future extension but am not sure about the structure  the high level derived which has Compose and future something (not sure what). The composed has a value (true, false) and child elements for extensions . Is this the proposed structure?
EBE> I like the idea of describing the origin of the capture with an attribute that is more extensible than a Boolean. What about creating enumerated values for the two origins we are currently discussing. We have 'composed' (composed=true) meaning that the media has been changed in some way and original (composed=false).

                RE: No need, first of all it does not work with switched capture that may have different aspect ratios. Also this is available in the SDP as well as a way for receiver to ask for specific ratio using the SDP image attribute.
EBE> The image attribute (RFC6236) document talks about image resolution and picture aspect ratio, and how they relates to codec specific parameters like h264 max-fs and max-mbps.  An attribute can have a single value, a list of values or a range.

    stream.

                RE; suggest to take this out at the moment until we agree if needed and how to map.
EBE> I assume that matching RTCP SDES CNAME is still the preferred mechanisms for syncing audio and video for lip-sync (as defined in RFC3550). When we discussed audio tags last interim it as was presented as a tool for improving directional audio.

Thanks,

Andy and Allyn

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jul 2012 17:10:12 -0400

Allyn,

[replying as an individual]

On 7/17/12 9:22 PM, Allyn Romanow (allyn) wrote:
> Folks,
>
> There are several issues related to the data model that we’d like us to
> framework, to a lesser or greater extent. They were brought up during
> the data model presentation at the interim meeting. I wonder if we could
> work on resolving them?
>
> 1.Any problem with using media-type for capture attribute as described
> in the draft?

I don't understand this.

IIUC, the intent is to use <CLUE-info> in both directions between 
provider and consumer.

In the advertisement from provider to consumer its clearly necessary to 
indicate the media type of a capture. That is so regardless of whether 
the consumer supports it or not.

The message from consumer to provider, for the purpose of choosing and 
configuring the captures it wishes to receive, it seems unnecessary to 
repeat any of the info from the advertisement that remains invariant, 
with the exception of the <capture-id>, which is needed to refer to the 
advertisement.

> 2.Any problem with using content-type for capture attribute as described
> in the draft?

Same comment as for 1 above.

> 3.DERIVED for capture attribute- Should we have a variable called
> something like DERIVED, that takes various values, one of which is
> composed. That would mean that if DERIVED is not =composed, that the
> capture is not composed, and if it =composed then it is. I don’t have
> another descriptor to propose now, but there could be others either now
> or later.
>
> Why this change from the framework? I think it is more general than
> composed Boolean, yet semantically similar.
>
> “DERIVED”, that is the values should not be mutually exclusive.

> 4. Leave switched as a Boolean as in framework. The proposal in the
> draft seems infeasible – we don’t want CLUE to have to include all the
> ways in which products might want to implement switching. It would be
> better to make this more general, but we have no suggestion for it at
> present- it does not really match the meaning of a derived capture.

I don't yet have an opinion on <DERIVED> and <switched>. I'd like to 
hear what others have to say.

It seems to me that switching and composition are two forms of mixing 
video. And they are not mutually exclusive. You can mix using one or the 
other, or both. And of course there are multiple ways of composing and 
switching.

The situation is somewhat the same for audio, but the ways of composing 
and switching are different. (Switching for audio is probably only 
dependent on audio. Switching for video is typically also dependent on 
audio.)

> 5.As part of the capture description, should we have a parameter
> there is one, such as 4:3 for a video camera? The reason is that it can
> help rendering.
>
> natively 4:3 or 16:9, for instance. If we have this, there might
> usefully be a "PREFERRED-ASPECT-RATIO" in the consumer's stream
> selection message as part of the (e.g. in "<stream-description> /
> <encoding>").
>
> 6.Multiplex ID – Value sent by consumer in its stream selection message
> consumer tells the provider which multiplex id to generate that stream
> with, so that the consumer can demultiplex the stream correctly when
> receiving it.

I look in draft-lennox-clue-rtp-usage and I don't see any mention of the 
*consumer* supplying the multiplex ID. It talks of the sender choosing 
it, and the benefit that provides for reusing encodings to multiple 
receivers.

> 7.AUDIO-RENDERING-ID – If the notion of an audio rendering tag is
>
> Clearly this doesn’t cover all the data model issues, but it’s a start.

Some other things:

I kind of implied it above, but I question whether it makes sense to use 
the same document format for both advertisement and configuration. If 
two formats were specified, then there would certainly be elements that 
appear in both, but not *all* elements.

Also, this version has eliminated the indicators of which elements can 
be repeated, and which are optional. Why?

	Thanks,
	Paul

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 29 Jul 2012 03:48:49 +0000

Hi Roni,
Thanks much for your comments, please see inline -

Best,
Allyn

Hi,

okay

Other comments

Yes--

Thanks
Roni

Folks,

RE: OK

AR- I was thinking that it would be Derived, with value composed. So, if it were composed you would have this, otherwise not. Do there need to be child elements of composed?

Then there would be other derived values as they are identified in the future.

It seems more general than calling out composed as the top level attribute...

AR- Sorry,  I don't understand your suggestion.. would you mind writing it out the way it would be in the data model?

AR - I'll let Andy respond to this

AR- I think this will be discussed at the upcoming meeting in the CLUE session Monday.

    stream.

AR - Sure, tabling it till later seems fine.

Thanks,

Andy and Allyn

---

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 29 Jul 2012 04:09:16 +0000

Hi Paul,
Please see inline

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, July 23, 2012 2:10 PM
To: [email-masked]
Subject: Re: [clue] a few issues on data model draft

Allyn,

On 7/17/12 9:22 PM, Allyn Romanow (allyn) wrote:
> Folks,
>
> There are several issues related to the data model that we'd like us 
> to consider. These are things that are not exactly the same as in the 
> the data model presentation at the interim meeting. I wonder if we 
> could work on resolving them?
>

I don't understand this.

IIUC, the intent is to use <CLUE-info> in both directions between provider and consumer.

In the advertisement from provider to consumer its clearly necessary to indicate the media type of a capture. That is so regardless of whether the consumer supports it or not.

The message from consumer to provider, for the purpose of choosing and configuring the captures it wishes to receive, it seems unnecessary to repeat any of the info from the advertisement that remains invariant, with the exception of the <capture-id>, which is needed to refer to the advertisement.

AR- I don't understand what you are saying - it sounds like you are talking about messages.. but this is just the data model not how the defined elements may or may not be used in messages
Do you not think that audio and video should be called out as media types in CLUE? If not, why not?

> 2.Any problem with using content-type for capture attribute as 
> described in the draft?

AR - me too, same as above.

> capture is not composed, and if it =composed then it is. I don't have 
> another descriptor to propose now, but there could be others either 
> now or later.
>
> This does not prevent us from having qualifiers to describe composed, 
> to help distinguish between different composed captures, as has been 

> draft seems infeasible - we don't want CLUE to have to include all the 

I don't yet have an opinion on <DERIVED> and <switched>. I'd like to hear what others have to say.

It seems to me that switching and composition are two forms of mixing video. And they are not mutually exclusive. You can mix using one or the other, or both. And of course there are multiple ways of composing and switching.

The situation is somewhat the same for audio, but the ways of composing and switching are different. (Switching for audio is probably only dependent on audio. Switching for video is typically also dependent on
audio.)

AR-  I think this is a rhetorical comment, without need for response.

> NATIVE-ASPECT-RATIO, which indicates the aspect ratio for the capture 
> if there is one, such as 4:3 for a video camera? The reason is that it 
> can help rendering.
>
> 6.Multiplex ID - Value sent by consumer in its stream selection 
> message with the encoding id and capture id. This is the mechanism by 
> which the consumer tells the provider which multiplex id to generate 
> that stream with, so that the consumer can demultiplex the stream 
> correctly when receiving it.

I look in draft-lennox-clue-rtp-usage and I don't see any mention of the
*consumer* supplying the multiplex ID. It talks of the sender choosing it, and the benefit that provides for reusing encodings to multiple receivers.

AR- As in comment to Roni, this should be sorted in the RTP usage discussion, and then the data model can describe as appropriate

> 7.AUDIO-RENDERING-ID - If the notion of an audio rendering tag is
>

Some other things:

I kind of implied it above, but I question whether it makes sense to use the same document format for both advertisement and configuration. If two formats were specified, then there would certainly be elements that appear in both, but not *all* elements.

AR- There seems to be some confusion -- we aren't doing advertisements and configurations here. We're doing overall data model. I agree that both messages won't both use all the defined data elements, of course.

Also, this version has eliminated the indicators of which elements can be repeated, and which are optional. Why?
AR- because these aren't the messages which have to do with usage, just the definitions.. the data model.. not how the elements defined here can be used.

	Thanks,
	Paul
_______________________________________________
clue mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/clue

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 29 Jul 2012 02:23:51 -0400

There seems to be a common theme in some of the comments about the 
relationship of this data model to clue messages.

IIUC, the approach to describing the model was borrowed from XCON, and 
in XCON it describes a *single* XML structured document syntax.

As used here it still seems to be  structured that way. The description 
is hierarchical, so its not clear how one would pick and choose from it 
to construct different messages. *IF* it was a hierarchical document 
with repeated and optional elements, then it would be *possible* to use 
the same document format for advertisements and configuration, but use 
the repeating and optionality to convey different elements in each. But 
IMO that is a BADDDDD approach.

Alternately, we could start with a schema that defines a bunch of 
independent xml elements, and then assemble those into aggregates for 
the different message types. But I don't think the current thing does 
that. If its intended to, then it needs more explanation.

	Thanks,
	Paul (as individual)

On 7/29/12 12:09 AM, Allyn Romanow (allyn) wrote:
> IIUC, the intent is to use<CLUE-info>  in both directions between provider and consumer.
>
> The message from consumer to provider, for the purpose of choosing and configuring the captures it wishes to receive, it seems unnecessary to repeat any of the info from the advertisement that remains invariant, with the exception of the<capture-id>, which is needed to refer to the advertisement.
>
> I don't yet have an opinion on<DERIVED>  and<switched>. I'd like to hear what others have to say.
>