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

[Brian Rosen <[e-mail]>]

<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

On Apr 6, 2011, at 4:21 AM, Elwell, John wrote:

> 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: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Scott Orton
>> Sent: 31 March 2011 17:21
>> To: Parthasarathi R (partr); Paul Kyzivat (pkyzivat); Peter 
>> Saint-Andre
>> Cc: [e-mail]
>> Subject: Re: [siprec] draft-ram-siprec-metadata-format-01
>> 
>> Inline comments.
>> 
>> -----Original Message-----
>> From: Parthasarathi R (partr) [mailto:[e-mail]] 
>> Sent: Thursday, March 31, 2011 10:42 AM
>> To: Scott Orton; Paul Kyzivat (pkyzivat); Peter Saint-Andre
>> Cc: [e-mail]
>> Subject: RE: [siprec] draft-ram-siprec-metadata-format-01
>> 
>> Scott,
>> 
>> Thanks for the feedback.
>> 
>> Thanks
>> Partha
>> 
>> -----Original Message-----
>> From: [e-mail] 
>> [mailto:[e-mail]] On Behalf
>> Of Scott Orton
>> Sent: Thursday, March 31, 2011 8:59 PM
>> To: Paul Kyzivat (pkyzivat); Peter Saint-Andre
>> Cc: [e-mail]
>> 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: [e-mail] 
>> [mailto:[e-mail]] On Behalf
>> Of Paul Kyzivat
>> Sent: Thursday, March 31, 2011 7:19 AM
>> To: Peter Saint-Andre
>> Cc: [e-mail]
>> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>> _______________________________________________
>>>> siprec mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>> 
>>> 
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
>> _______________________________________________
>> siprec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/siprec
>> 
> _______________________________________________
> siprec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/siprec