Subject: [siprec] draft-ram-siprec-metadata-format-01

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 31 Mar 2011 00:25:15 +0200

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

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Mar 2011 04:55:10 -0400

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:
> 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
> namespace is defined) and then multiple<extensiondata/>  elements
> Perhaps you even meant to have<extensiondata/>  elements qualified by
> 5. The data in the<name/>  elements with xml:lang="it" really should be
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 31 Mar 2011 11:06:49 +0200

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. :)

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 Mar 2011 08:19:23 -0400

> Tomorrow I have the following windows of time:

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

---

From: Scott Orton <[email-masked]>
Date: Thu, 31 Mar 2011 08:28:30 -0700

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.

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.

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

	Thanks,
	Paul

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Thu, 31 Mar 2011 21:12:11 +0530

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

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.

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

	Thanks,
	Paul

>> 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. 
>>> 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).
>>>
>>> '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.
>>> 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.
>>>

---

From: Scott Orton <[email-masked]>
Date: Thu, 31 Mar 2011 09:21:18 -0700

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

<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 should be no generic extensiondata element in the recording-metadata.  </Scott>

Regards,
   Scott

-----Original Message-----

	Thanks,
	Paul

data?

this document.