Subject: [siprec] Review of metadata-03

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jul 2011 10:59:51 +0200

I have reviewed metadata-03 up to and including section 6 and have the following comments (as individual):

1. In general, we are much too liberal with normative language. I have highlighted in later comments some particular places where we use it inappropriately. In particular, we should not use it for things that are more a matter for the protocol document. Also, since this document is defining the metadata model and its XML representation, I think we can just use simple present tense, rather than normative statements, to state what the model or its XML representation is. This applies in many places, but I have avoided repeating my comments in all places.

2. In general, we should avoid saying too much about the protocol or about conveyance of a metadata XML document, but should restrict ourselves, as far as possible, to the model and the XML document format. Again, specific comments touch on this.

3. On terminology, I think it might be more helpful to restrict the term "element" to cases where we are talking about XML elements, and use some other term (e.g., object, class) when talking about components of the model. Then we could say, for example, that a 'stream' XML element represents a 'Media Stream' object or an object of class 'Media Stream'.

4. Related to this, I think we should stick to a single convention, either:
- use the same name for the model object and for the corresponding XML element (we do this for "Participant", for example, at present); or
- use different names (we do this for "Media Stream" and "stream", for example, at present).

5. Section 3:
"Metadata element: A metadata element represent one block/class of
   metadata model."
This says what it represents, not what it is. Is it an XML element or what? Also, all definitions should be in the form of a dictionary definition, not a sentence.

6. Terms "Metadata attributes" and "XML attributes are defined (section 3) but not used.

7. "Metadata Composition" is defined (section 3) but used only in the title of 6.6.1, which could perhaps be changed to something that doesn't need defining. In fact a later comment questions the need for 6.6.1.

8. Section 3:
"Metadata associations represents the
   associations between different Metadata elements in the model.  It
   uses UML notation."
Defining Metadata Associations in terms of associations is not very helpful, and I can't find the term used anywhere.

9. Section 4 and elsewhere:
I don't think Extension data should be shown as a separate block. Rather like start-time and stop-time, it is just a property of other blocks. In fact, I would go so far as to say that extension data should not be in the model - it is an XML technique that allows an extended model to be accommodated in future, but the model itself (being abstract) does not need such an extensibility mechanism.

10. Section 4:
"The metadata MUST be conveyed within the Recording
   Session Dialog."
I think this statement is outside scope of this document - more a protocol matter.

11. Section 4:
"Note that the metadata model captures changes that occur over the
   duration of the recording session."
I don't believe it captures changes. I think the model allows the capture of a snapshot of a recording's metadata at a given instant in time. Metadata changes to reflect changes in what is being recorded.

12. Section 4:
"then the SRC MUST convey
   a change of participant and the properties of the new media stream to
   the SRS."
The "MUST convey" statement seems more like a protocol matter. All we can say is that the model changes and there is a need for the SRC to convey the change in the model to the SRS.

13. Section 4:
"Some of the metadata is not required to be conveyed explicitly from
   the SRC to the SRS, if it can be obtained contextually by the SRS.
   For instance, the timing of RS block changes(like Start / Stop time)
   may not be explicitly conveyed from the SRC to the SRS (The Date
   header in RS dialog SIP message MAY provide the timing, but it is
   optional).  In such cases the time a change occurred may be assumed
   to be the same as the time when notification of the change is
   received by the SRS."
This is starting to talk about conveyance, rather than the model itself. I am not sure it belongs in this section. Also we shouldn't make normative statements ("MAY") on protocol issues. Furthermore, the statement about the time of change being the time the notification is received is not necessarily valid. For example, send notification with a change, this is lost, a little later the SRS asks for a snapshot, the snapshot is sent and the SRS observes the change - however, the time is wrong.

14. Section 5:
"The
   media related details of metadata MUST be passed across using session
   description protocol (SDP) [RFC4566].  SDP attributes describes about
   different media formats like audio, video."
We should not be making normative statements. We should express in terms like: "Some data from the metadata model is assumed to be made available to the SRS through SDP, and therefore this data is not represented in the XML document format specified in this document.

15. Section 5:
"MUST be passed across"
I don't think a normative statement about passing across is appropriate to this document. I think it is sufficient here to say "are represented".

16. Section 5:
"The linkage between application/rs-metadata+xml XML schema and
   metadata SDP is done using the SDP label attribute (a=label:xxx)
   referenced in [RFC4574]."
I think this is trying to say something like:
"The SDP label attribute [RFC4574] provides an identifier by which a metadata XML document can refer to a specific media description in the SDP sent from the SRC to the SRS."

17. Section 5:
"Metadata is passed across in Recording Session(RS) incrementally
   whenever there is a change in CS."
I don't think we should be talking about passing across - we should limit ourselves to talking about the format. I think this should say something like:
"The XML document format can be used to represent either the complete metadata or a partial update to the metadata. The latter includes only elements that have changed compared to the previously reported metadata."

18. Section 5.1:
"which will be embedded
   as a message body"
Out of scope - delete.

19. Section 5.1:
"Recording object is a XML document."
There seems to be confusion between this statement and the opening of the previous paragraph ("Recording Metadata document is an XML document"). Also it is unclear what "recording object" is.

20. Section 5.1.2:
"dataMode element shows whether the XML document is complete document
   or partial update.  The default value is complete."
Any particular reason why this is an element rather than an attribute? I don't have a strong opinion either way - just curious, because it seems like the sort of thing that might typically be an attribute.

21. Section 6.1:
"This element is represented by a SIP RS dialog and hence there is no
   need for this element to be reflected in metadata XML"
Would it be more accurate or more helpful to say that the Recording Session object is represented by recording XML element? That in turn relies on the SIP/SDP session with which the XML document is associated to provide some of the attributes of the Recording Session element. Also I think, for consistency, this statement should be in a new sub-section 6.1.3, since it concerns representation, not modelling.

22. Section 6.1.1:
"A Recording Session element MAY have attributes like:" I don't think RFC 2119 language is appropriate. We are defining the model - we are not giving permission for somebody to define the model. We should simply state (present tense) the attributes that apply. If any are optional, we could state that it is optional (rather than "MAY"), or we could say that it can have zero instances. Also, the word "like" leaves the list open ended, which is certainly unsatisfactory for a normative statement. But even if we change the language to informative, I think we need to be more precise.

23. Section 6.1.1:
"Start and End time value MUST be derived from"
This is not a testable requirement - how do you test that something has been derived, unless there is a requirement to do more with the derived information? I think "are derivable" would suffice. Also, I think this would be more appropriate for 6.1.3.

23. Section 6.1.1:
"Start/End time MAY be set to the time at
      which SRS receives"
Again I don't think RFC2119 language is appropriate. This is not a protocol document. Could say "are derivable from...".  Again it would be applicable to 6.1.3.

23. Section 6.1.2:
"Also the allowance of
      zero instances is to accommodate persistent recording, where there
      may be none."
It seems this sentence is more applicable to the next bullet (concerning CS) than to the CSG bullet.

24. Section 6.1.2:
"Each CS Group MUST be associated with one or more Recording
      Sessions [Here each RS can be setup by the potentially different
      SRCs."
This bullet doesn't fit below the introductory text (which is talking about what an RS must have). In fact this information is repeated in 6.2.2 , which seems a more appropriate place.

25. Section 6.2:
"A Communication Session Group provides association or linking of
   Communication Sessions."
I think we need to say a little more (informatively) about how grouping might be used.

26. Section 6.2.1:
"SRC (or MAY be SRS) MUST
   ensure the uniqueness of Unique-ID in case multiple SRC interacts
   with the same SRS."
How do I interpret this normative language? I think we need to say that the SRC is responsible for assigning Unique-ID values that are unique.

27. Section 6.2.2:
"o  There can be one or more Recording Session elements per
      Communication Session Group.
   o  Each Communication Session Group MUST be associated with one or
      more RS [Here each RS can be setup by the potentially different
      SRCs]"
What is the difference between these two bullets?

28. Section 6.2.2:
"Each CS MAY be associated to zero or one CS-Group"
Would this fit better in 6.3.2?

28. Section 6.2.3:
"Group element is an optional element"
Do we need to say "optional". We already know from 6.1.2 that an RS has zero or more associated CSGs - isn't that sufficient?

29. Section 6.2.3:
"Each group element has unique URN UUID attribute which
   helps to uniquely identify CSG."
Why does it only help - why doesn't uniquely identify?

30. Section 6.3.1:
"The communication session MAY contain a Call Termination Reason"
This conflicts with the "MUST" in the sentence introducing the bullets.

31. Section 6.3.1:
"Attributes like Retention (represent the value/duration for which
   Media streams of the CS needs to be retained), Force Deletion, Access"
These look like named attributes, which they are not. Are we trying to say something like:
"This document does not specify attributes relating to what should happen to a recording of a CS after it has been delivered to the SRS, e.g., how long to retain the recording, what access controls to apply. The SRS is assumed to behave in accordance with policy. The ability for the SRC to influence this policy is outside the scope of this document." Also, should such a statement occur up front, e.g., in section 4?

32. Section 6.3.1:
"However if there are
   implementations where SRC has enough information, this could be sent
   as Extension Data attached to CS"
Extension data is an XML concept, so should be covered in 6.3.3.

33. Section 6.3.2:
"CS to have atleast two or more participants"
Are there any corner cases where there might be fewer than two?

34. Section 6.3.2:
"o  Participant MUST be associated with one or more CS's.  This may
      even includes participants who are not directly part of any CS.
      An example of such a case is participants in a premixed media
      stream.  The SRC may have knowledge of such Participants, yet not
      have any signaling relationship with them.  This might arise if
      one participant in CS is a conf focus.  Another use case is if one
      UA in CS works in 3pcc mode to acquire an MoH media stream, this
      might be reflected as unique source for media stream without
      having a reported signaling relationship to it.  In all these
      cases if SRC can learn enough information about the Participant,
      they MUST be associated with CS."
All this is very confusing. I think what it is saying is that the SRC might not have direct signalling relationships with all participants in a CS, but should nevertheless create a Participant object for each participant that it knows about, e.g., participants visible as a result of the conference event package [RFC4575]. I failed to understand the bit about MoH, so that too would need rewording if retained.

35. Section 6.3.2:
"o  The model also allows participants in CS that are not participants
      in the media.  An example is the identity of a 3pcc controller
      that has initiated a CS to two or more participants of the CS.
      Another example is the identity of a conference focus.  Of course
      a focus is probably in the media, but since it may only be there
      as a mixer, it may not report itself as a participant in any of
      the media streams."
It is unclear why these cases would need to be Participants. However, I agree that where nothing is known about what is beyond a conference focus or B2BUA, the conference focus or B2BUA itself should probably be identified (if possible).

36. Section 6.3.2:
"o  A stream can be associated with 1 or more CS.  An example is
      multicast MoH stream which might be associated with many CSs."
I don't find this a convincing example. Does the SRC know for certain that the two streams are both the same MoH, and if so whether they are synchronized or not (if that matters)?

37. Section 6.3.2 (same bullet):
"Also if we were to consider a B2BUA to have a separate CS on each
      "side" then they might share a stream.(Though more likely this
      would be treated as a single CS.)"
Again, this is a possibility, but why would a B2BUA want to do this - it seems to complicate the metadata unnecessarily?

38. Section 6.3.3:
"Each communication session(CS) has one session element"
I would suggest changing "has" to "is represented by".

39. Section 6.3.3:
"Reason element MAY be included to indicate the reason for
   termination."
In order to tie it more clearly to the model, I would suggest changing "to indicate the reason for termination" to "to represent the Termination Reason attribute".

40. Section 6.4.1:
"AoR list - Has list of AoRs."
Should we use a more generic name, rather than AOR? For example, "Identifier", since it need not necessarily be a SIP AOR, but could, for example, be a TEL URI, or even a JID if the CS is not a SIP session?

41. Concerning the same bullet, in the schema, this has maxOccurs=1, so it doesn't seem to be a list, just a single AOR. I think a single identifier might be sufficient.

42. Section 6.4.1:
"o  Name - This attribute represents Participant name(SIP display
      name) or DN number ( in case it is known)"
Assuming "DN number" means "directory number", or telephone number, why is this part of the name attribute, rather than the previous attribute? For example, I have available a tel: URI from P-Asserted-Identity - why would I treat that as name rather than identifier?

43. Section 6.4.1:
"Other attributes [ like Participant Role, Participant type ] MAY be
   carried as part of extension data to Participant from SRC to SRS."
Again this seems to be a statement about XML, so more relevant to 6.4.3 (if we need to say anything at all).

44. Section 6.4.3:
"Participant element provides information regarding the specific
   participant involved in the recording"
I think this should say something like: "A participant element represents a Participant object."

45. Section 6.4.3:
""receive" element"
I think this should be ""recv" element".

46. Section 6.4.3:
"and by
   default all participant will receive the stream"
I can't figure out how this works. If I omit a "recv" element for a particular Participant, it seems to mean that the Participant is receiving by default. So how do I indicate that a Participant is NOT receiving a stream?

47. Section 6.4.3:
"URN UUID of participant
   *MUST* used in the scope of CSG "
What does this mean?

48. Section 6.4.3:
"and no new URN UUID has to be created
   for the same element (participant, stream) between different CS in
   the same CSG."
Concerning the mention of "stream", why are we talking about stream in the section on participant?

49. Section 6.4.3:
"careful
   usage of URN UUID to original AoR"
What does this mean?

50. Section 6.5:
"Different instances of Media Stream block would be
   created whenever there is a change in media (e.g. dir change like
   pause/resume and/or codec change and/or participant change."
It is unclear to me why this would be so. None of the things mentioned here are attributes of Media Stream, so why would a new block be created if any of these change?

51. Section 6.5.1:
The schema also has mode element, which presumably must have a corresponding attribute in the model, yet I don't see it in this section.

52. Section 6.5.2:
"Label attribute is used ..."
I think we need to say that this corresponds to Media Stream Reference above.

53. Section 6.5.2:
"The media mode helps "
Is this the "mode" element?

54: "6.6.1.  Composition"
Why do we need this section? We don't have a "composition" section for "start-time", for example, this being another example of an element type that can appear in different parent elements.

John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 14 Jul 2011 20:29:04 +0530

Hi John,

Thanks a lot for your elaborate review and comments. I will respond to
your comments in sets (to avoid large mail-threads).
Here are answers (inline)  to few comments (First 6).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Elwell, John
> Sent: Thursday, July 14, 2011 2:30 PM
> To: [email-masked]
> Subject: [siprec] Review of metadata-03
> 
> 1. In general, we are much too liberal with normative language. I have
> highlighted in later comments some particular places where we use it
> inappropriately. In particular, we should not use it for things that
> are more a matter for the protocol document. Also, since this document
> is defining the metadata model and its XML representation, I think we
> can just use simple present tense, rather than normative statements,
to
> state what the model or its XML representation is. This applies in
many
> places, but I have avoided repeating my comments in all places.

I agree for the text related to the model we can remove the normative
statements.
IMO at least for the XML schema portions we need to have normative
statements as this document is a proposed standard. Please let us know
If I am missing something.

> 2. In general, we should avoid saying too much about the protocol or
> about conveyance of a metadata XML document, but should restrict
> ourselves, as far as possible, to the model and the XML document
> format. Again, specific comments touch on this.

We have already removed some of the sections to delivery (like
examples). I will look at your specific comments to see if anything else
needs to be moved

> 
> 3. On terminology, I think it might be more helpful to restrict the
> term "element" to cases where we are talking about XML elements, and
> use some other term (e.g., object, class) when talking about
components
> of the model. Then we could say, for example, that a 'stream' XML
> element represents a 'Media Stream' object or an object of class
'Media
> Stream'.
The model uses UML notation/terminology where as Schema uses XML
terminology. I will go over the draft again and correct where ever
required.

> - use the same name for the model object and for the corresponding XML
> element (we do this for "Participant", for example, at present); or

We have used the names "stream", "session" in XML schema to keep the
number of characters to minimum and still convey meaning. The metadata
element names has long names like "Communication Session". To show the
mapping we have defined the XML element equivalent to a metadata element
within the same section. Is this not clear enough ? Or Do you still
prefer same names across model & format ?

> This says what it represents, not what it is. Is it an XML element or
> what? Also, all definitions should be in the form of a dictionary
> definition, not a sentence.

Let me try to suggest a better list of definitions. Please suggest
corrections.

Metadata model: The metadata model is a UML class diagram and has a
collection of classes. Metadata model class diagram show the classes,
their interrelationships (which includes association, composition).

Metadata element or Metadata block: Each class in the metadata UML class
diagram is called as metadata element/block in this document.  The
metadata model has a collection of metadata elements.  Examples include
Recording Session element/block, Participant element/block e.t.c. Each
metadata element has an upper part that holds the name of the class
(Examples - Recording Session, Communication Session Group,
Communication Session) and the bottom part that contains the attributes
of the class (Examples- Start Time, End Time).

> 
> 6. Terms "Metadata attributes" and "XML attributes are defined
(section
> 3) but not used.

The intent here to describe what "attribute" means. We have sections for
each element that talks about attributes of each class. Is it ok if I
put the definition as below. Or is the above definition of Metadata
element sufficient to cover attributes also ?

attributes: attribute represents attributes of a Metadata element or
metadata block. The attributes are represented at the bottom part of a
metadata element. Examples include Start Time, End Time e.t.c.

Regards,
Ram

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jul 2011 17:40:44 +0200

Ram,

Thanks for responding quickly on these. See my further remarks below: 

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 14 July 2011 15:59
> To: Elwell, John; [email-masked]
> Subject: RE: [siprec] Review of metadata-03
> 
> Hi John,
> 
> > I have reviewed metadata-03 up to and including section 6 
> and have the
> > following comments (as individual):
> > 
[JRE] Of course, the schema itself does not contain prose, so cannot contain normative statements. But normative statements might be appropriate in some places, e.g., XML documents MUST use this schema.

> terminology. I will go over the draft again and correct where ever
[JRE] The main thing is consistency and avoiding ambiguity. It would be better to avoid using the term "element" for both things, if at all possible. Otherwise we will need somewhat clumsy constructs such as "XML element X represents an instance of UML element Y".
Also, I don't know if we need a reference to UML or whether that is already used in RFCs without the need for a reference.

> > - use different names (we do this for "Media Stream" and 
> "stream", for
> > example, at present).
> 
[JRE] I said either always use the same name for both or always use different names for both. I agree that XML names should not be too long and also that UML names should clearly describe what they mean (and therefore may be longer), so perhaps always making them different is the better choice. That would involve finding a solution for "participant", where there isn't an obvious longer form or shorter form (except perhaps "party"). I don't mind too much if you ignore this comments - I just thought it would be a nice-to-have.

> their interrelationships (which includes association, composition).
[JRE] First, it should be worded as a dictionary definition, not as sentences. Secondly, the first sentence doesn't seem sufficiently complete to me and the second sentence says nothing more than what a UML class diagram is, i.e., it is not specific to a metadata model. So how about:
"Metadata model: An abstract representation of metadata using a UML class diagram."

> metadata model has a collection of metadata elements. 
[JRE] Why do we need two terms for the same thing? (metadata element and metadata block)? The term "block" has the advantage of avoiding a clash with XML elements.  But what is the difference between a "block" and a "class" - excuse my weakness on UML.

> Examples include
> Recording Session element/block, Participant element/block e.t.c. 
[JRE] If we need to give examples as part of a definition, the definition is weak.

> Each
[JRE] This should not be part of the definition - it describes structure. However, if you are trying to describe how to interpret a diagram, as opposed to producing a definition, this type of information may be fine.

> element sufficient to cover attributes also ?
[JRE] One issue is that in XML, the term attribute has a specific meaning. It would be good not to use "attribute" for the model, to avoid clash with XML, but I fear that may be unavoidable. I don't recall exactly what its meaning is in UML. If we use it as in UML, we should not need to redefine it.

> metadata block. 
[JRE] If we eliminate "metadata element" to avoid having two terms for the same thing, this definition would reduce to "attribute represents attributes of a Metadata block", which tells me very little (and also conflicts with XML attribute).

> The attributes are represented at the bottom part of a
[JRE] This is telling me how to interpret a diagram - it should not be part of a definition.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Sat, 16 Jul 2011 17:16:32 +0530

John,

Thanks a lot for the detailed comments. I have replied for few of the
comments which look straight forward to me. The authors of the draft
will discuss and get back for the rest of the comments ASAP. Please read
inline.

Thanks
Partha 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Elwell, John
> I have reviewed metadata-03 up to and including section 6 and 
> have the following comments (as individual):
> 
> 1. In general, we are much too liberal with normative 
> language. I have highlighted in later comments some 
> particular places where we use it inappropriately. In 
> particular, we should not use it for things that are more a 
> matter for the protocol document. Also, since this document 
> is defining the metadata model and its XML representation, I 
> think we can just use simple present tense, rather than 
> normative statements, to state what the model or its XML 
> representation is. This applies in many places, but I have 
> avoided repeating my comments in all places.
> 
> 2. In general, we should avoid saying too much about the 
> protocol or about conveyance of a metadata XML document, but 
> should restrict ourselves, as far as possible, to the model 
> and the XML document format. Again, specific comments touch on this.
> 
> 3. On terminology, I think it might be more helpful to 
> restrict the term "element" to cases where we are talking 
> about XML elements, and use some other term (e.g., object, 
> class) when talking about components of the model. Then we 
> could say, for example, that a 'stream' XML element 
> represents a 'Media Stream' object or an object of class 
> 'Media Stream'.
> 
> - use the same name for the model object and for the 
> corresponding XML element (we do this for "Participant", for 
> example, at present); or
> "stream", for example, at present).
> 
> 5. Section 3:
> This says what it represents, not what it is. Is it an XML 
> element or what? Also, all definitions should be in the form 
> of a dictionary definition, not a sentence.
> 
> 7. "Metadata Composition" is defined (section 3) but used 
> only in the title of 6.6.1, which could perhaps be changed to 
> something that doesn't need defining. In fact a later comment 
> questions the need for 6.6.1.
> 
> 8. Section 3:
> Defining Metadata Associations in terms of associations is 
> not very helpful, and I can't find the term used anywhere.
> 
> I don't think Extension data should be shown as a separate 
> block. Rather like start-time and stop-time, it is just a 
> property of other blocks. In fact, I would go so far as to 
> say that extension data should not be in the model - it is an 
> XML technique that allows an extended model to be 
> accommodated in future, but the model itself (being abstract) 
> does not need such an extensibility mechanism.
> 
> 10. Section 4:
<Partha> This statement is as per our discussion on "recording" element
in RS. "recording" metadata element will be represented using RS SIP
messages. The statement is better presented in the metadata draft and in
case the text has to be modified, Pls suggest.  </Partha> 

> I don't believe it captures changes. I think the model allows 
> the capture of a snapshot of a recording's metadata at a 
> given instant in time. Metadata changes to reflect changes in 
> what is being recorded.
> 
> 12. Section 4:
> The "MUST convey" statement seems more like a protocol 
> matter. All we can say is that the model changes and there is 
> a need for the SRC to convey the change in the model to the SRS.

<Partha> Agreed </Partha>
> This is starting to talk about conveyance, rather than the 
> model itself. I am not sure it belongs in this section. Also 
> we shouldn't make normative statements ("MAY") on protocol 
> issues. Furthermore, the statement about the time of change 
> being the time the notification is received is not 
> necessarily valid. For example, send notification with a 
> change, this is lost, a little later the SRS asks for a 
> snapshot, the snapshot is sent and the SRS observes the 
> change - however, the time is wrong.
> 
> 14. Section 5:
> "The
> We should not be making normative statements. We should 
> express in terms like: "Some data from the metadata model is 
> assumed to be made available to the SRS through SDP, and 
> therefore this data is not represented in the XML document 
> format specified in this document.
> 
> 15. Section 5:
> "MUST be passed across"
> I don't think a normative statement about passing across is 
> appropriate to this document. I think it is sufficient here 
> to say "are represented".
> 
> 16. Section 5:
> "The SDP label attribute [RFC4574] provides an identifier by 
> which a metadata XML document can refer to a specific media 
> description in the SDP sent from the SRC to the SRS."
> 
> 17. Section 5:
> I don't think we should be talking about passing across - we 
> should limit ourselves to talking about the format. I think 
> this should say something like:
> "The XML document format can be used to represent either the 
> complete metadata or a partial update to the metadata. The 
> latter includes only elements that have changed compared to 
> the previously reported metadata."
> 
> 18. Section 5.1:
> "which will be embedded
>    as a message body"
> Out of scope - delete.
> 
> 19. Section 5.1:
> There seems to be confusion between this statement and the 
> opening of the previous paragraph ("Recording Metadata 
> document is an XML document"). Also it is unclear what 
> "recording object" is.
> 
> 20. Section 5.1.2:
> Any particular reason why this is an element rather than an 
> attribute? I don't have a strong opinion either way - just 
> curious, because it seems like the sort of thing that might 
> typically be an attribute.
> 
<Partha> In the metadata XML document, XML attribute is used only in
case of unique value for an element. The rest of the data is represented
as an element. </Partha>

> Would it be more accurate or more helpful to say that the 
> Recording Session object is represented by recording XML 
> element? 
<Partha> Recording session metadata element is not represented in XML.
As we discussed earlier, the value has to derived from RS dialog
</Partha>

That in turn relies on the SIP/SDP session with 
> which the XML document is associated to provide some of the 
> attributes of the Recording Session element. Also I think, 
> for consistency, this statement should be in a new 
> sub-section 6.1.3, since it concerns representation, not modelling.

<Partha> Agreed for the last sentence </Partha>

> 
> 22. Section 6.1.1:
> "A Recording Session element MAY have attributes like:" I 
> don't think RFC 2119 language is appropriate. We are defining 
> the model - we are not giving permission for somebody to 
> define the model. We should simply state (present tense) the 
> attributes that apply. If any are optional, we could state 
> that it is optional (rather than "MAY"), or we could say that 
> it can have zero instances. Also, the word "like" leaves the 
> list open ended, which is certainly unsatisfactory for a 
> normative statement. But even if we change the language to 
> informative, I think we need to be more precise.
> 
> 23. Section 6.1.1:
> This is not a testable requirement - how do you test that 
> something has been derived, unless there is a requirement to 
> do more with the derived information? I think "are derivable" 
> would suffice. Also, I think this would be more appropriate for 6.1.3.
> 
> 23. Section 6.1.1:
> Again I don't think RFC2119 language is appropriate. This is 
> not a protocol document. Could say "are derivable from...".  
> Again it would be applicable to 6.1.3.
> 
> 23. Section 6.1.2:
> "Also the allowance of
> This bullet doesn't fit below the introductory text (which is 
> talking about what an RS must have). In fact this information 
> is repeated in 6.2.2 , which seems a more appropriate place.
> 
> 25. Section 6.2:
> How do I interpret this normative language? I think we need 
> to say that the SRC is responsible for assigning Unique-ID 
> values that are unique.
> 
> 27. Section 6.2.2:
> Do we need to say "optional". We already know from 6.1.2 that 
> an RS has zero or more associated CSGs - isn't that sufficient?

<Partha> This is more of elaborative text. Even though Sec 6.1.2 and XML
schema helps to infer, it is better to have this text for readability
</Partha> 
> Why does it only help - why doesn't uniquely identify?

<Partha>This text will be updated according to the unique id usage
e-mail thread in SIPREC </Partha>

> This conflicts with the "MUST" in the sentence introducing 

<Partha> Agreed. "MUST" has to be modified </Partha>

> "This document does not specify attributes relating to what 
> should happen to a recording of a CS after it has been 
> delivered to the SRS, e.g., how long to retain the recording, 
> what access controls to apply. The SRS is assumed to behave 
> in accordance with policy. The ability for the SRC to 
> influence this policy is outside the scope of this document." 
> Also, should such a statement occur up front, e.g., in section 4?
> 
> 32. Section 6.3.1:
> "However if there are
<Partha> We don't know the usecase till now and concluded for two
participant. In case you know of any usecase, Please let us know
</Partha>

> All this is very confusing. I think what it is saying is that 
> the SRC might not have direct signalling relationships with 
> all participants in a CS, but should nevertheless create a 
> Participant object for each participant that it knows about, 
> e.g., participants visible as a result of the conference 
> event package [RFC4575]. I failed to understand the bit about 
> MoH, so that too would need rewording if retained.
> 
> 35. Section 6.3.2:
> It is unclear why these cases would need to be Participants. 
> However, I agree that where nothing is known about what is 
> beyond a conference focus or B2BUA, the conference focus or 
> B2BUA itself should probably be identified (if possible).
> 
> 36. Section 6.3.2:
> I don't find this a convincing example. Does the SRC know for 
> certain that the two streams are both the same MoH, and if so 
> whether they are synchronized or not (if that matters)?
> 
> Again, this is a possibility, but why would a B2BUA want to 
> do this - it seems to complicate the metadata unnecessarily?
> 
> 38. Section 6.3.3:

<Partha> Agreed </Partha>

> In order to tie it more clearly to the model, I would suggest 
> changing "to indicate the reason for termination" to "to 
> represent the Termination Reason attribute".
> 

<Partha> Agreed </Partha>

> Should we use a more generic name, rather than AOR? For 
> example, "Identifier", since it need not necessarily be a SIP 
> AOR, but could, for example, be a TEL URI, or even a JID if 
> the CS is not a SIP session?
> 
> 41. Concerning the same bullet, in the schema, this has 
> maxOccurs=1, so it doesn't seem to be a list, just a single 
> AOR. I think a single identifier might be sufficient.
> 
> 42. Section 6.4.1:
> Assuming "DN number" means "directory number", or telephone 
> number, why is this part of the name attribute, rather than 
> the previous attribute? For example, I have available a tel: 
> URI from P-Asserted-Identity - why would I treat that as name 
> rather than identifier?
> 
> 43. Section 6.4.1:
> Again this seems to be a statement about XML, so more 
> relevant to 6.4.3 (if we need to say anything at all).
> 
> 44. Section 6.4.3:
> I think this should say something like: "A participant 
> element represents a Participant object."
> 
> 45. Section 6.4.3:
> ""receive" element"

<Partha> Agreed </Partha>

> I can't figure out how this works. If I omit a "recv" element 
> for a particular Participant, it seems to mean that the 
> Participant is receiving by default. So how do I indicate 
> that a Participant is NOT receiving a stream?
> 
> 47. Section 6.4.3:
> "URN UUID of participant
> It is unclear to me why this would be so. None of the things 
> mentioned here are attributes of Media Stream, so why would a 
> new block be created if any of these change?
> 
> 51. Section 6.5.1:
> The schema also has mode element, which presumably must have 
> a corresponding attribute in the model, yet I don't see it in 
> this section.
> 
> 52. Section 6.5.2:
> Why do we need this section? We don't have a "composition" 
> section for "start-time", for example, this being another 
> example of an element type that can appear in different 
> parent elements.
> 
> 
> John
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jul 2011 09:17:25 +0200

(Stripping out the ones we have dealt with) 

> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: 16 July 2011 12:47

> case the text has to be modified, Pls suggest.  </Partha> 
[JRE] My concern was more with the use of RFC 2119 language - sorry for not expressing it better. Just saying it MUST be conveyed within the RS dialog is not really testable. I would expect the protocol draft to make normative statements about exactly how to convey. Also I don't think we need to mention "dialog" - that too is a matter for the protocol document. Also the previous sentence "The metadata MUST be conveyed from SRC to SRS" doesn't need to use normative language. Instead of the two sentences, just say something like "Metadata is conveyed from SRC to SRS as part of the RS".

> case of unique value for an element. The rest of the data is 
[JRE] I don't understand this explanation. Can anyone else shed light?

> As we discussed earlier, the value has to derived from RS dialog
[JRE] I was wondering how the recording XML element relates to the model. I guess it is just a placeholder for those objects in the model that need to be represented in XML. Perhaps we can say something to that effect in section 5. I withdraw my comment concerning 6.1.

> schema helps to infer, it is better to have this text for readability
[JRE] I still find it unhelpful to say "optional", given that all of the elements at this level are optional (minOccurs=0) - a partial XML document can omit any of them, can't it? It is confusing to say one is optional when, in effect, all are optional. Don't forget, this particular section (6.2.3) is concerned with XML representation, not the model.

> participant. In case you know of any usecase, Please let us know
[JRE] I am not aware of a use case - I just feel slightly uncomfortable. Leave it for now.

John (as individual)

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Mon, 18 Jul 2011 14:15:48 +0530

John,

Please read inline.

Thanks
Partha 

> From: Elwell, John [mailto:[email-masked]] 
> Sent: Monday, July 18, 2011 12:47 PM
> To: Parthasarathi R (partr); [email-masked]
> [JRE] My concern was more with the use of RFC 2119 language - 
> sorry for not expressing it better. Just saying it MUST be 
> conveyed within the RS dialog is not really testable. I would 
> expect the protocol draft to make normative statements about 
> exactly how to convey. Also I don't think we need to mention 
> "dialog" - that too is a matter for the protocol document. 
> Also the previous sentence "The metadata MUST be conveyed 
> from SRC to SRS" doesn't need to use normative language. 
> Instead of the two sentences, just say something like 
> "Metadata is conveyed from SRC to SRS as part of the RS".

<Partha> Agreed. We will update in the next revision </Partha>
> [JRE] I don't understand this explanation. Can anyone else shed light?
<Partha> Attribute of an XML element is used in this XML document only
in case the value is constant and unique throughout for the element. In
case the value shall be changed, then it is represented as sub-element
within an element. This is as per recommendation provided by Joe.
</Partha>

> [JRE] I was wondering how the recording XML element relates 
> to the model. I guess it is just a placeholder for those 
> objects in the model that need to be represented in XML. 
> Perhaps we can say something to that effect in section 5. I 
> withdraw my comment concerning 6.1.
> 
<Partha> Agreed. We will add text related to recording XML element in
sec 5 for more clarity </Partha>

> [JRE] I still find it unhelpful to say "optional", given that 
> all of the elements at this level are optional (minOccurs=0) 
> - a partial XML document can omit any of them, can't it? It 
> is confusing to say one is optional when, in effect, all are 
> optional. Don't forget, this particular section (6.2.3) is 
> concerned with XML representation, not the model.
<Partha> optional in the model perspective apart from the specific XML
document (minOccurs=0). Let me think and come up with the appropriate
text to clarify this </Partha>

> uncomfortable. Leave it for now.
<Partha> Let us track this as an open item for IETF-81 and explore the
possibility </Partha>

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 18 Jul 2011 12:21:42 +0200

Partha,

Just following up on the dataMode element versus attribute discussion. Copying Joe too. See below.

> Sent: 18 July 2011 09:46

> within an element. This is as per recommendation provided by Joe.
[JRE] So you are saying that value of the dataMode flag can vary over time? This is true, of course. However, the recording element is a little bit different from the elements below it (session, stream, participant...). The recording element is a sort of container for child elements, and I don't really think it has a lifetime beyond that of a single XML document. The dataMode flag, likewise, has a lifetime only for the single XML document in which it is contained. It describes only whether that particular XML document is complete metadata or partial metadata. It is not an update of the dataMode flag in a previous XML document. So I don't think this particular criterion for making it an element, rather than an attribute, is valid. I am not expert enough to know whether there might be other criteria that lead to use of an element rather than an attribute.

John (as individual)

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 21 Jul 2011 10:56:48 +0530

Hi John / Partha,

> <Partha> Let us track this as an open item for IETF-81 and explore the

A comment on this- In the current model Each CS class has atleast two
participants.  IOW the current model does not allow a CS with less than
2 participants.  Is there a need to track this as open item ? As I
remember we did agree initially that each CS shall have atleast two
participants.

Let me know so that I can add this to slide deck as open item if need
be.

Regards,
Ram

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 21 Jul 2011 11:07:29 +0530

Ram,

As you mentioned, it was discussed during IETF-80 with different
use-case like studio mode recording, voice mail. Then, we agreed to go
with minimum 2 participant. I have asked this item to be re-opened
because John is slightly uncomfortable and expects more opinion/usecase.
IMO, it is better to discuss in IETF-81 and close forever.

Thanks
Partha 

> From: Ram Mohan R (rmohanr) 
> Sent: Thursday, July 21, 2011 10:57 AM
> To: Parthasarathi R (partr); Elwell, John; [email-masked]
> A comment on this- In the current model Each CS class has 
> atleast two participants.  IOW the current model does not 
> allow a CS with less than 2 participants.  Is there a need to 
> track this as open item ? As I remember we did agree 
> initially that each CS shall have atleast two participants.
> 
> Let me know so that I can add this to slide deck as open item 
> if need be.
> 
> Regards,
> Ram
> 
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 21 Jul 2011 10:21:27 +0200

Don't re-open is on my account. I failed to recall the past discussion.

John 

> Sent: 21 July 2011 06:37
> To: Ram Mohan R (rmohanr); Elwell, John; [email-masked]

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 21 Jul 2011 14:29:05 +0530

John,

Thanks for the closure of minimum 2 participant per CS open item.

Thanks
Partha 

> Sent: Thursday, July 21, 2011 1:51 PM
> To: Parthasarathi R (partr); Ram Mohan R (rmohanr); [email-masked]
> > > A comment on this- In the current model Each CS class has atleast 
> > > two participants.  IOW the current model does not allow a CS with 
> > > less than 2 participants.  Is there a need to track this as open 
> > > item ? As I remember we did agree initially that each CS 
> shall have 
> > > atleast two participants.
> > > 
> > > Let me know so that I can add this to slide deck as open item if 
> > > need be.
> > > 
> > > Regards,
> > > Ram
> > > 
> > > 
> > 
>