Subject: [siprec] #76: Address rest of the John's comments sent on metadata-03

From: "siprec issue tracker" <[email-masked]>
Date: Fri, 02 Sep 2011 06:48:03 -0000

#76: Address rest of the John's comments sent on metadata-03

 John has sent 54 comments (most of which are related to text and usage of
 normative language) after reviewing metadata-03. Ver-04 tries to address
 several of these comments. This ticket is to track the comments that are
 not yet closed in ver-04.

 Comments are at http://www.ietf.org/mail-
 archive/web/siprec/current/msg02260.html

 open Comments(NOT addressed in ver 04)- 13 19, 20, 34, 35, 40, 41, 42, 43,
 47 to 54

-- 
--------------------------------+-------------------------------------------
 Reporter:  rmohanr@…           |       Owner:  rmohanr@…        
     Type:  defect              |      Status:  new              
 Priority:  minor               |   Milestone:                   
Component:  metadata            |     Version:                   
 Severity:  Active WG Document  |    Keywords:                   
--------------------------------+-------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/siprec/trac/ticket/76>
siprec <http://tools.ietf.org/siprec/>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Mon, 5 Sep 2011 08:26:26 +0530

John,

All of your comments are addressed/discussed as part of this mail except comment 34 & 35. The details are as follows:

Comment 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.

<partha> This statement was added in the initial stage of the draft to ascertain that there is no 1:1 mapping between metadata model attribute and metadata XML element. Now, we have better clarity on the model to XML element relationship. I agree that there is no need of any normative statement here. We shall add the text as follows:

""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 example: RS dialog id shall be used to uniquely identify recording session object in the model.".
</partha>

Comment 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.
<partha> I agree that this statement has to be reworded as "Recording element is the topmost element in Recording metadata XML document" </partha>

Comment 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.
<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>

Comment 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?
<partha> I'm fine with the terminology of 'Identifier' to make it generic and include TEL URI. Having said that, JID is outside the scope of SIPREC as CS in SIPREC is assumed to SIP session. </partha>

Comment 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.
<partha> I agree that we have to be consistent in text & syntax. We have to update the XML syntax as it is agreed upon in IETF-81 that multiple identifier is possible. </partha>

Comment 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?
<partha> Display name is the intent behavior. The text shall be changed as " Name - This attribute represents Participant name(SIP display name)".  But the open question is how to related multiple name to multiple instance for a given participant. </partha>

Comment 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).
<partha> Here, the discussion is about the attributes which are not included in the standard metadata model. So, it is appropriate place is 6.4.1 rather than 6.4.3.</partha>

Comment 47. Section 6.4.3:
"URN UUID of participant *MUST* used in the scope of CSG "
What does this mean?
<partha> The correct statement is "URN UUID of a given participant *MUST* same within the scope of CSG if CSG exists". Hope this clarifies </partha>

Comment 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?
<partha> This is a general mechanism for participant & stream. If it is confusing, we will add separate text in participant & stream section. </partha>

Comment 49. Section 6.4.3:
"careful usage of URN UUID to original AoR"
What does this mean?
<partha> The complete statement is as follows:
"In case URN UUID has to be used permanent, careful usage of URN UUID to original AoR has to be decided by the    implementers and it is implementer's choice.". 

The reason for adding this statement is that URN UUID shall be used outside the scope of CSG and the usage may cause interop if it is not used with due diligence. The implementer has to be careful while designing URN UUID as a permanent value  </partha>

Comment 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?

<partha> Metadata model media stream includes RS SDP which are included using media stream reference (label attribute). For each change in the RS SDP, media stream object is created in the model but there is no impact in metadata XML. </partha>

Comment 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.
<partha> we will add "mode" element in the next revision </partha>

Comment 52. Section 6.5.2:
"Label attribute is used ..."
I think we need to say that this corresponds to Media Stream Reference above.
<partha> Text will be updated to reflect "Media stream reference" </partha>

Comment 53. Section 6.5.2:
"The media mode helps "
Is this the "mode" element?
<partha> Yes, your understanding is correct.

Comment 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.
<partha> There is a difference between attribute  & composition. Start-time is an attribute for couple of metadata element but it does not create object of itself. Extension-data is a separate class which shall have any objects but will be contained within specified metadata class </partha>

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf
>Of siprec issue tracker
>Sent: Friday, September 02, 2011 12:18 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: [siprec] #76: Address rest of the John's comments sent on
>metadata-03
>
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 5 Sep 2011 09:36:00 +0200

Partha,

Thanks for your answers. See my further remarks below: 

> From: Ravindran Parthasarathi [mailto:[email-masked]] 
> Sent: 05 September 2011 03:56
> To: siprec issue tracker; [email-masked]; Elwell, John
> Cc: [email-masked]
> Subject: RE: [siprec] #76: Address rest of the John's 
> comments sent on metadata-03
> 
> John,
> 
> All of your comments are addressed/discussed as part of this 
> mail except comment 34 & 35. The details are as follows:
> 
> Comment 13. Section 4:
> 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.
> 
> <partha> This statement was added in the initial stage of the 
> draft to ascertain that there is no 1:1 mapping between 
> metadata model attribute and metadata XML element. Now, we 
> have better clarity on the model to XML element relationship. 
> I agree that there is no need of any normative statement 
> here. We shall add the text as follows:
> 
> ""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 example: RS dialog id shall be 
> used to uniquely identify recording session object in the model.".
> </partha>
[JRE] This is better, although I think we can live without the example (which is too much to do with protocol). I have further comments on the whole paragraph in -04, which I will submit in due course.

> 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.
> <partha> I agree that this statement has to be reworded as 
> "Recording element is the topmost element in Recording 
> metadata XML document" </partha>
[JRE] OK

> 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>
[JRE] I don't understand your explanation. What is meant by "only in case of unique value for an element"?

> 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?
> <partha> I'm fine with the terminology of 'Identifier' to 
> make it generic and include TEL URI. Having said that, JID is 
> outside the scope of SIPREC as CS in SIPREC is assumed to SIP 
> session. </partha>
[JRE] OK

> 
> Comment 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.
> <partha> I agree that we have to be consistent in text & 
> syntax. We have to update the XML syntax as it is agreed upon 
> in IETF-81 that multiple identifier is possible. </partha>
[JRE] OK

> 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?
> <partha> Display name is the intent behavior. The text shall 
> be changed as " Name - This attribute represents Participant 
> name(SIP display name)".  But the open question is how to 
> related multiple name to multiple instance for a given 
> participant. </partha>
[JRE] Perhaps the <identifier/> element needs to contain the equivalent of name-addr in SIP, and then we would not need a separate <name/> element.

> Again this seems to be a statement about XML, so more 
> relevant to 6.4.3 (if we need to say anything at all).
> <partha> Here, the discussion is about the attributes which 
> are not included in the standard metadata model. So, it is 
> appropriate place is 6.4.1 rather than 6.4.3.</partha>
[JRE] I think it would be sufficient to say in 6.4.1 that such other properties are not standardized. Extension data is an XML mechanism, and relevant only in 6.4.3.

> <partha> The correct statement is "URN UUID of a given 
> participant *MUST* same within the scope of CSG if CSG 
> exists". Hope this clarifies </partha>
[JRE] This still does not parse. Should it be "...MUST be the same..."?

> "and no new URN UUID has to be created for the same element 
> (participant, stream) between different CS in
>    the same CSG."
> <partha> This is a general mechanism for participant & 
> stream. If it is confusing, we will add separate text in 
> participant & stream section. </partha>
[JRE] OK, do that.

> "In case URN UUID has to be used permanent, careful usage of 
> URN UUID to original AoR has to be decided by the    
> implementers and it is implementer's choice.". 
> 
> The reason for adding this statement is that URN UUID shall 
> be used outside the scope of CSG and the usage may cause 
> interop if it is not used with due diligence. The implementer 
> has to be careful while designing URN UUID as a permanent 
> value  </partha>
[JRE] It is not clear to me what problem this statement is trying to address. What does one need to take care of when implementing?

> 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?
> 
> <partha> Metadata model media stream includes RS SDP which 
> are included using media stream reference (label attribute). 
> For each change in the RS SDP, media stream object is created 
> in the model but there is no impact in metadata XML. </partha>
[JRE] This does not make sense to me. Firstly, why does a change in RS SDP create a new media stream object, rather than modifying an existing media stream object? Secondly, why does it even change the media stream object? If I look at the attributes in 6.5.1, I see that all the information to be found in an SDP media description is missing (e.g., port, transport, media type, security information, formats, direction...). This would suggest to me that if something changes in SDP (e.g., a direction change), this would NOT change the media stream object in the model (and likewise it would not change the <stream/> element in XML).

> 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.
[JRE] OK

> <partha> Text will be updated to reflect "Media stream 
[JRE] OK

> 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.
> <partha> There is a difference between attribute  & 
> composition. Start-time is an attribute for couple of 
> metadata element but it does not create object of itself. 
> Extension-data is a separate class which shall have any 
> objects but will be contained within specified metadata class 
> </partha>
[JRE] My knowledge of UML is insufficient to argue with you here. However, as I have mentioned already, I am not convinced that we need to model extension data in UML - I think it is sufficient just to define it as an extension mechanism for the XML.

John

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

> >From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> >Of siprec issue tracker
> > John has sent 54 comments (most of which are related to 
> text and usage
> >of
> > open Comments(NOT addressed in ver 04)- 13 19, 20, 34, 35, 
> 40, 41, 42,
> >43,
> > 47 to 54
> >
> >--
> >--------------------------------+----------------------------
> -----------
> >----
> > Reporter:  rmohanr@...           |       Owner:  rmohanr@...
> >--------------------------------+----------------------------
> -----------
> >----
> >