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

From: Christian Groves <[email-masked]>
Date: Wed, 18 Jul 2012 11:49:38 +1000

Hello Allyn,

I thought i'd resend this seeing you're opening up discussion on the 
data model. I didn't see a response to this email. Maybe it was missed?

Regards, Christian

On 21/06/2012 2:30 PM, Christian Groves wrote:
> Hello Allyn and Andy,
>
> Post the interim meeting I've had a bit of a closer look at the data 
> model and I have a few comments/questions:
>
>
> o Section 4 - Perhaps the numbering in section 4 could follow the 
> hierarchy of the XML scheme. i.e. rather than <capture-description> 
> being at level 4.2 it could be 4.1.1. It might make it easier for 
> readers to follow.
>
> o Sect. 4.3 <capture-id> - This indicates that the alphanumeric value 
> is unique. Within what scope is it unique? i.e. the framework uses the 
> ACx and VCx conventions. Where x could be the same value for both 
> audio and video. So is the ID unique to an endpoint / capture scene / 
> media etc? Maybe we want to keep the alphanumeric convention AC,VC etc?
>
> o Sect. 4.4 - If we adopted the naming scheme from the framework 
> perhaps this element is redundant? Alternatively could audio/video 
> result in another branch? i.e. be sub-elements all the parameters 
> relevant to audio would be under it and all the video parameters would 
> be under the video branch.
>
> o Sect. 4.5 - The description seems to only focus on video. Wouldn't 
> an audio feed generated by a computer also be valid?
>
> o Sect. 4.8.1 - The framework calls this "Are of capture". We probably 
> should be consistent.
>
> o Sect. 4.8.3 - FYI, in ITU-T q5/16 at the last meeting a proposal was 
> received to add this to the parameters document. The proposal wasn't 
> supported as it was felt more information was necessary.
>
> o Sect. 4.12 - It says "...When there are multiple entries of the same 
> media type in the capture scene,...". I'm not sure what the 
> significance is of "the same media type". According to the text below 
> it entries can either be a list of audio or video, so they'll always 
> be the same media type.
>
> o Sect. 4.12.3.2 Nit missing opening "<".
>
> o Sect. 4.12 - It would be good to align the names with the framework.
>
> Regards, Christian
>
>
> On 7/06/2012 3:43 AM, Allyn Romanow (allyn) wrote:
>> Hi,
>> I've updated the data model draft to correct an error. The original 
>> draft had characters suggesting that elements be mandatory or 
>> repeated. This is really appropriate for the messages but not for the 
>> basic information model. The current draft follows the example of 
>> XCON RFC 6501 in saying only that the top level element, in our case, 
>> CLUE-info, is mandatory.
>>
>> Regards,
>> Ally
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]]
>> Sent: Wednesday, June 06, 2012 10:38 AM
>> To: Allyn Romanow (allyn)
>> Cc: [email-masked]
>> Subject: New Version Notification for 
>> draft-romanow-clue-data-model-01.txt
>>
>> A new version of I-D, draft-romanow-clue-data-model-01.txt has been 
>> successfully submitted by Allyn Romanow and posted to the IETF 
>> repository.
>>
>> Filename:     draft-romanow-clue-data-model
>> Revision:     01
>> Title:         Data model for the CLUE Framework
>> Creation date:     2012-06-06
>> WG ID:         Individual Submission
>> Number of pages: 11
>>
>> Abstract:
>>     This draft is for discussion in the CLUE working group.  It proposes
>>     a data model for the CLUE Framework.
>>
>>
>>
>> The IETF Secretariat
>> _______________________________________________
>> 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: "Allyn Romanow (allyn)" <[email-masked]>
Date: Sun, 29 Jul 2012 03:19:27 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: Wednesday, June 20, 2012 9:30 PM
To: [email-masked]
Subject: Re: [clue] FW: New Version Notification for draft-romanow-clue-data-model-01.txt

Hello Allyn and Andy,

Post the interim meeting I've had a bit of a closer look at the data model and I have a few comments/questions:

AR- Okay

o Sect. 4.3 <capture-id> - This indicates that the alphanumeric value is 
unique. Within what scope is it unique? i.e. the framework uses the ACx 
and VCx conventions. Where x could be the same value for both audio and 
video. So is the ID unique to an endpoint / capture scene / media etc? 
Maybe we want to keep the alphanumeric convention AC,VC etc?

AR- I'm going to let Andy respond to this

o Sect. 4.4 - If we adopted the naming scheme from the framework perhaps 
this element is redundant? Alternatively could audio/video result in 
another branch? i.e. be sub-elements all the parameters relevant to 
audio would be under it and all the video parameters would be under the 
video branch.
 AR- this seems a bit more complicated to me

o Sect. 4.5 - The description seems to only focus on video. Wouldn't an 
audio feed generated by a computer also be valid?

AR- does this need to treated differently and therefore need to be distinguished?

AR- I don't believe that the data model elements should need to name things the way the framework does. You can make the framework doc nomenclature match the data model at the end of the process, if people want to do that. 
The framework describes the concepts and was done prior to the data model which is a somewhat formal specification of data elements. I wouldn't expect the names to be exactly the same.

AR- that is interesting. What is your opinion on whether it is useful in CLUE?

o Sect. 4.12 - It says "...When there are multiple entries of the same 
media type in the capture scene,...". I'm not sure what the significance 
is of "the same media type". According to the text below it entries can 
either be a list of audio or video, so they'll always be the same media 
type.

AR- I'm not sure what the confusion is, but I get the message that the statement isn't clear 
How would it be to say:
	 Each capture entry represents the capture scene, though with different captures. For example, if there are 6 participants in the scene, 	one entry may be for 3 captures, each of which sees 2 participants; and another capture entry may be for one switched capture, where 	the video and audio depends on an algorithm, such as most recent speaker.

AR- see above

Regards, Christian

On 7/06/2012 3:43 AM, Allyn Romanow (allyn) wrote:
> Hi,
> I've updated the data model draft to correct an error. The original draft had characters suggesting that elements be mandatory or repeated. This is really appropriate for the messages but not for the basic information model. The current draft follows the example of XCON RFC 6501 in saying only that the top level element, in our case, CLUE-info, is mandatory.
>
> Regards,
> Ally
>
> Subject: New Version Notification for draft-romanow-clue-data-model-01.txt
>
> A new version of I-D, draft-romanow-clue-data-model-01.txt has been successfully submitted by Allyn Romanow and posted to the IETF repository.
>

---

From: Andy Pepperell <[email-masked]>
Date: Mon, 30 Jul 2012 14:22:29 +0100

>AR- I'm going to let Andy respond to this

Thanks Allyn (I think..!).

Christian,

The truth is that there's no fixed plan for this as yet; partly this is
because depending on other pending CLUE decisions, the requirements for
this may change - for instance there are RTP drafts out there that talk
about the capture ID being in RTP packet [header]s, which might constrain
its range and nature (especially if it were at some point required to form
an SSRC etc.).

My take though is that the capture IDs should be limited in scope to the
provider advertisement and consumer stream choice messages - this being so
there's no requirement for them to be numeric or be limited to some pre-set
range. I think even given this though, our original thinking was that
they'd be simple numeric values (e.g. "1" -> left camera media capture, "2"
-> right camera media capture, "3" -> pre-mixed audio stream etc.) within,
say, a 32 bit range, and the "ACn" / "VCn" notation in the framework etc.
is just for clarity.

We were thinking that the uniqueness would span all media captures declared
by a provider in its advertisement - partly this is because there may be
some constructs that span capture scenes and / or span audio and video (for
instance, simultaneity constraints as expressed by the provider
advertisement) and partly this was with one eye to future extensibility to
media captures of types other than simple audio or video (where it might be
undesirable or awkward to have to come up with new additional alphanumeric
prefixes).

Hope this helps,

Andy

On Sun, Jul 29, 2012 at 4:19 AM, Allyn Romanow (allyn) <[email-masked]>wrote:

> AR- I don't believe that the data model elements should need to name
> things the way the framework does. You can make the framework doc
> nomenclature match the data model at the end of the process, if people want
> to do that.
> The framework describes the concepts and was done prior to the data model
> which is a somewhat formal specification of data elements. I wouldn't
> expect the names to be exactly the same.
>
>          Each capture entry represents the capture scene, though with
> different captures. For example, if there are 6 participants in the scene,
>        one entry may be for 3 captures, each of which sees 2 participants;
> and another capture entry may be for one switched capture, where    the
> video and audio depends on an algorithm, such as most recent speaker.
>
> draft had characters suggesting that elements be mandatory or repeated.
> This is really appropriate for the messages but not for the basic
> information model. The current draft follows the example of XCON RFC 6501
> in saying only that the top level element, in our case, CLUE-info, is
> mandatory.
> >
> > Regards,
> > Ally
> >
> successfully submitted by Allyn Romanow and posted to the IETF repository.
> >

---

From: Christian Groves <[email-masked]>
Date: Tue, 31 Jul 2012 14:28:48 +1000

Hello Allyn,

Please see my response below.

Regards, Christian

On 29/07/2012 1:19 PM, Allyn Romanow (allyn) wrote:
> ..snip..
[CNG] Perhaps but this would need to be addressed by the framework 
first? As it currently stands the parameter is for both audio and video 
so it should be described that way.
> The framework describes the concepts and was done prior to the data model which is a somewhat formal specification of data elements. I wouldn't expect the names to be exactly the same.
[CNG] I think we should have a good reason to name a parameter 
differently in the data model as compared to the framework. The 
framework and the data model are both living documents subject to change 
so I don't think there's a before and after. If whilst developing the 
data model a better name is chosen then I think the goal is to have it 
the same in the framework and the data model and both documents would be 
updated accordingly.
> AR- that is interesting. What is your opinion on whether it is useful in CLUE?
[CNG] If we have spatial information for captures then my opinion is 
that the aspect ratio isn't needed. However I haven't seen any real 
analysis or justification on how it would be used. So if someone could 
put together a good case for it then i'd consider it.
> 	 Each capture entry represents the capture scene, though with different captures. For example, if there are 6 participants in the scene, 	one entry may be for 3 captures, each of which sees 2 part…
[CNG] I think the last part of the sentence needs work. Capture scene 
entries must be the same media so it may lead to confusion where in the 
first part a video capture is mentioned and then we say "where video and 
audio depends....". It would be more correct to say "... where the video 
depends on an algorithm...".

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Jul 2012 22:36:54 -0700

Speaking *as* co-chair, I think that before we are done the data model 
and the framework must agree on terminology, other that perhaps 
punctuation, separator characters, etc. As we evolve the documents they 
will no doubt get out of sync for some period of time. I don't care 
which doc gets changed to align them as long as they get aligned.

	Thanks,
	Paul

On 7/30/12 9:28 PM, Christian Groves wrote:
>> nomenclature match the data model at the end of the process, if people
>> want to do that.
>> The framework describes the concepts and was done prior to the data
>> model which is a somewhat formal specification of data elements. I
>> wouldn't expect the names to be exactly the same.
>> Each capture entry represents the capture scene, though with different
>> captures. For example, if there are 6 participants in the scene, one
>> entry may be for 3 captures, each of which sees 2 participants; and
>> another capture entry may be for one switched capture, where the video
>> and audio depends on an algorithm, such as most recent speaker.