Subject: [clue] FW: New Version Notification for draft-romanow-clue-data-model-01.txt

From: "Allyn Romanow (allyn)" <[email-masked]>
Date: Wed, 6 Jun 2012 10:43:07 -0700

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

---

From: Christian Groves <[email-masked]>
Date: Thu, 21 Jun 2012 14:30:25 +1000

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:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>