Subject: [siprec] Extension data (was RE: draft-ram-siprec-metadata-format-01)

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

I tend to agree with Scott that it would be easier to send extension data as part of the object to which it relates, rather than as a separate object.

Advantages:
1. There is no need for an identifier on the extension data, since it is always sent as part of the object.
2. When sending an updated object, it is clear by the presence or absence of extension data whether previous extension data still applies.

Disadvantages:
1. It is not possible to update the extension data without updating the entire object.

I believe the advantages outweigh the disadvantage.

John (as individual)

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Scott Orton
> Sent: 31 March 2011 17:21
> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Peter 
> Saint-Andre
> Cc: [email-masked]
> Subject: Re: [siprec] draft-ram-siprec-metadata-format-01
> 
> Inline comments.
> 
> -----Original Message-----
> From: Parthasarathi R (partr) [mailto:[email-masked]] 
> Sent: Thursday, March 31, 2011 10:42 AM
> To: Scott Orton; Paul Kyzivat (pkyzivat); Peter Saint-Andre
> Cc: [email-masked]
> Subject: RE: [siprec] draft-ram-siprec-metadata-format-01
> 
> Scott,
> 
> Thanks for the feedback.
> 
> Thanks
> Partha
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Scott Orton
> Sent: Thursday, March 31, 2011 8:59 PM
> To: Paul Kyzivat (pkyzivat); Peter Saint-Andre
> Cc: [email-masked]
> Subject: Re: [siprec] draft-ram-siprec-metadata-format-01
> 
> Here is some feedback on draft-ram-siprec-metadata-format-01. 
> 
> In the xml schema, the group is not listed as an element in 
> the sequence
> for the recording-metadata, which conflicts with the example in 5.1.
> 
> <Partha> Agreed. I'll update in the next revision </partha>
> 
> In addition, I found it confusing that the extension data is 
> included in
> the participant type but not included in any of the other defined
> elements in the recording-metadata. I think it might be good idea to
> include the extension data as last element in the sequences for the
> group, session, etc. As that would eliminate the need for the parent
> attribute in the extension data assuming it stays close to its current
> format.
> 
> <partha> It purely depend on whether extension-data has to be 
> partially
> passed across separately or not. Currently mechanism allows to pass
> extension data partially within RS whereas in case it is an element
> within any of the metadata block element like participant, stream then
> it has to be passed across with any change in that particular metadata
> block element.
> 
> 
> <Scott> I see the advantages of it being separate for the 
> partial update. I would just like it to be consistent. Either 
> in each element or in none of the elements. I think the key 
> to deciding where to include the extension data is how a 
> partial update should treat the data. If for example in the 
> initial metadata you send to the SRS there is extensiondata 
> associated with the participant. Then in an UPDATE the 
> partial metadata for the participant update the stop-time, 
> but does not include the extensiondata. How is the SRS 
> expected to handle the lack of extensiondata? Should it treat 
> it as the extensiondata is no longer relevant and delete it 
> or should it assume it is not changed. If it should treat it 
> as unchanged then how do you delete the extension data if it 
> is no longer relevant. Since the definition of the extension 
> data requires at least one string there is no way to remove 
> it. All this leads me to believe that the extension data 
> should be part of each element and there s
>  hould be no generic extensiondata element in the 
> recording-metadata.  </Scott>
> 
> In case everyone feels that there is no need to pass extensiondata
> explicitly, it realy simply the solution as there is no need another
> open item like parent id within extensiondata </partha>
>  
> 
> Regards,
>    Scott
>   
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Thursday, March 31, 2011 7:19 AM
> To: Peter Saint-Andre
> Cc: [email-masked]
> Subject: Re: [siprec] draft-ram-siprec-metadata-format-01
> 
> 
> 
> On 3/31/2011 5:06 AM, Peter Saint-Andre wrote:
> > I am booked through 11 PM tonight.
> >
> > Tomorrow I have the following windows of time:
> >
> > 07:00-07:30
> > 15:15-16:00
> >
> > Naturally that time might get filled if issues come up in 
> some of my 
> > working groups. :)
> 
> But you also have 11-12pm tonite? :-)
> (That is much better for me than the others.)
> 
> Maybe its just too late in the week to hope for this.
> We can take it to the list.
> 
> 	Thanks,
> 	Paul
> 
> > On 3/31/11 10:55 AM, Paul Kyzivat wrote:
> >> Peter/Joe,
> >>
> >> Do either of you have any time in the remainder of the 
> week when some
> 
> >> of us could sit and try to sort out the right way to do 
> the extension
> data?
> >> I doubt it would take very long.
> >>
> >>      Thanks,
> >>      Paul
> >>
> >> On 3/30/2011 6:25 PM, Peter Saint-Andre wrote:
> >>> Here is some quick feedback on 
> draft-ram-siprec-metadata-format-01. 
> >>> I hope to review it more fully soon.
> >>>
> >>> 1. I would change application/recording to 
> application/recording+xml
> 
> >>> in accordance with RFC 3023 (many specs illustrate the use of XML 
> >>> media types -- see for example RFC 4287).
> >>>
> >>> 2. The large number of<extensiondata/>   elements is a 
> bit confusing
> in
> >>> the examples.
> >>>
> >>> 3. In Section 5.1, the example has one<extensiondata/>   element
> >>> qualified by the 'urn:ietf:params:xml:ns:siprec' 
> namespace (no other
> >>> namespace is defined) and then multiple<extensiondata/>   elements
> >>> qualified by other namespaces ('http://example.com/groupapp', 
> >>> 'http://example.com/sessionapp', etc.). Although those other 
> >>> namespaces are certainly *allowed* to use "extensiondata" as an 
> >>> element name (that's the beauty of namespaces), it is confusing in
> this document.
> >>> Perhaps you even meant to have<extensiondata/>   elements 
> qualified
> by
> >>> the 'urn:ietf:params:xml:ns:siprec' and then child elements 
> >>> qualified by other namespaces (in accordance with the schema). 
> >>> However, that is not clear in the spec.
> >>>
> >>> 4. There is no built-in datatype for xs:urnuuid, xs:streamMode, 
> >>> xs:requester, and so on. See W3C XML Schema Part 2:
> >>>
> >>>      http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
> >>>
> >>> 5. The data in the<name/>   elements with xml:lang="it" really
> should be
> >>> Giulietta Capuleti and Romeo Montecchi. ;-)
> >>>
> >>> Peter
> >>>
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> siprec mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/siprec
> >> _______________________________________________
> >> siprec mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/siprec
> >
> >
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 6 Apr 2011 08:57:35 -0400

<as individual>
We can provide an extension point in each object that allows a new namespace.  Then you can define  the extension in a new namespace and you get backwards compatibility without redefining the object.

I'm actually not a fan of that idea for extensions that are seen to have wide applicability.  I'd rather redefine the object.

Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Apr 2011 16:12:43 -0400

Scott,

One general principle (IMO): metadata is *never* deleted as a 
consequence of the mechanisms we are defining - the database is 
essentially write-only. But everything will be timestamped. (If the SRS 
wants to delete metadata by policy it may.)

For some things the interpretation of transmitting the same thing again 
is that there is a single value at any point in time - sending a new 
value affects what the value is considered to be for subsequent times.

For other things, (and this needs to be discussed) it may be that values 
just accumulate as received, and all apply to the thing they attach to 
for all time.

	Does that sound right?
	Thanks,
	Paul

On 3/31/2011 12:21 PM, Scott Orton wrote:
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Scott Orton
> In the xml schema, the group is not listed as an element in the sequence
> <Partha>  Agreed. I'll update in the next revision</partha>
>
> In addition, I found it confusing that the extension data is included in
> <partha>  It purely depend on whether extension-data has to be partially
> <Scott>  I see the advantages of it being separate for the partial update. I would just like it to be consistent. Either in each element or in none of the elements. I think the key to deciding where to include the extension data is how a partial update should treat the data. If for example in the initial metadata you send to the SRS there is extensiondata associated with the participant. Then in an UPDATE the partial metadata for the participant update the stop-time, but does not include the extensiondata. How is the SRS expected to handle the lack of extensiondata? Should it treat it as the extensiondata is no longer relevant and delete it or should it assume it is not changed. If it should treat it as unchanged then how do you delete the extension data if it is no longer relevant. Since the definition of the extension data requires at least one string there is no way to remove it. All this leads me to believe that the extension data should be part of each element and the
re should be no generic extensiondata element in the recording-metadata.</Scott>
> open item like parent id within extensiondata</partha>
>
>
> Regards,
>     Scott
>
>
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
>> Naturally that time might get filled if issues come up in some of my
>> working groups. :)
>
>>> Do either of you have any time in the remainder of the week when some
>
>>> of us could sit and try to sort out the right way to do the extension
> data?
>>>> Here is some quick feedback on draft-ram-siprec-metadata-format-01.
>>>> 1. I would change application/recording to application/recording+xml
>
>>>> 2. The large number of<extensiondata/>    elements is a bit confusing
> in
>>>> the examples.
>>>>
>>>> qualified by the 'urn:ietf:params:xml:ns:siprec' namespace (no other
>>>> Perhaps you even meant to have<extensiondata/>    elements qualified
> by

---

From: Scott Orton <[email-masked]>
Date: Mon, 11 Apr 2011 13:16:51 -0700

Paul,
   It does. I cannot see a reason why anyone who is recording a call would not want to see the changes in the metadata as part of the history of the recorded call. 

Scott

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, April 01, 2011 3:13 PM
To: Scott Orton
Cc: Parthasarathi R (partr); Peter Saint-Andre; [email-masked]
Subject: Re: [siprec] draft-ram-siprec-metadata-format-01

Scott,

	Does that sound right?
	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 12 Apr 2011 10:50:03 +0530

Scott,

Your requirement for changing the metadata was discussed as "retention
policy" attribute during the metadata model draft review. It was decided
to be considered as outside the scope of SIPREC because it is no
possible for SRC to dictate SRS policy in the standard manner.  

Thanks
Partha

-----Original Message-----
From: Scott Orton [mailto:[email-masked]] 
Sent: Tuesday, April 12, 2011 1:47 AM
To: Paul Kyzivat (pkyzivat)
Cc: Parthasarathi R (partr); Peter Saint-Andre; [email-masked]
Subject: RE: [siprec] draft-ram-siprec-metadata-format-01

Paul,
   It does. I cannot see a reason why anyone who is recording a call
would not want to see the changes in the metadata as part of the history
of the recorded call. 

Scott

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]]
Sent: Friday, April 01, 2011 3:13 PM
To: Scott Orton
Cc: Parthasarathi R (partr); Peter Saint-Andre; [email-masked]
Subject: Re: [siprec] draft-ram-siprec-metadata-format-01

Scott,

	Does that sound right?
	Thanks,
	Paul

On 3/31/2011 12:21 PM, Scott Orton wrote:
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott Orton
> In the xml schema, the group is not listed as an element in the 
> sequence for the recording-metadata, which conflicts with the example
in 5.1.
> In addition, I found it confusing that the extension data is included 
> in the participant type but not included in any of the other defined 

> partially passed across separately or not. Currently mechanism allows 
> to pass extension data partially within RS whereas in case it is an 
> element within any of the metadata block element like participant, 
> stream then it has to be passed across with any change in that 
> particular metadata block element.
>
>
> <Scott>  I see the advantages of it being separate for the partial 
> update. I would just like it to be consistent. Either in each element 
> or in none of the elements. I think the key to deciding where to 
> include the extension data is how a partial update should treat the 
> data. If for example in the initial metadata you send to the SRS there

> is extensiondata associated with the participant. Then in an UPDATE 
> the partial metadata for the participant update the stop-time, but 
> does not include the extensiondata. How is the SRS expected to handle 
> the lack of extensiondata? Should it treat it as the extensiondata is 
> no longer relevant and delete it or should it assume it is not 
> changed. If it should treat it as unchanged then how do you delete the

> extension data if it is no longer relevant. Since the definition of 
> the extension data requires at least one string there is no way to 
> remove it. All this leads me to believe that the extension data should

> be part of each element and the
re should be no generic extensiondata element in the
recording-metadata.</Scott>
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
qualified