Subject: [siprec] Metadata version indication

From: Ofir Roth <[email-masked]>
Date: Wed, 24 Oct 2012 09:39:13 +0200

Hi,

>From our experience in SIPREC implementations, we often come across vendors that use different versions of the SIPREC metadata versions (which are not necessarily aligned with the latest version of metadata).
AFAIK, there is no way to indicate the metadata version as part of the XML/SIP headers.

I think that having such indication will be very useful for SIPREC implementers as they can reject or handle the metadata according to their ability to use those versions.

I will appreciate your comment on that.

Thanks,
Ofir Roth.

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 24 Oct 2012 14:49:08 +0530

Hi Ofir,

This issues was raised earlier by Hadriel. I agree that it is good to have
"version" element inside recording element to indicate the current version
of the SIPREC metadata. This helps in case the metadata is extended from 1.0
to 2.0 by the update of RFC. 

I'm not very sure whether it is accepted in IETF draft to update the version
of XML schema for each revision of the draft. For example, the current
version for the metadata draft will be 0.8 and the next revision of the
draft will be updated as 0.9. Let us look more comments for the generic
approach to solve this issue.

Thanks

Partha 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ofir Roth
Sent: Wednesday, October 24, 2012 1:09 PM
To: [email-masked]
Subject: [siprec] Metadata version indication

Hi,

>From our experience in SIPREC implementations, we often come across vendors
that use different versions of the SIPREC metadata versions (which are not
necessarily aligned with the latest version of metadata). 

AFAIK, there is no way to indicate the metadata version as part of the
XML/SIP headers. 

I think that having such indication will be very useful for SIPREC
implementers as they can reject or handle the metadata according to their
ability to use those versions. 

Thanks,
Ofir Roth.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 24 Oct 2012 12:03:37 -0400

I appreciate the problem here. There are a variety of ways to solve it.

The obvious one would be to keep changing the content-type, by embedding 
a version number in the mime-type name itself. This could present some 
logistical difficulties as we transition from draft to RFC. I guess it 
might also not be approved by mime gurus. It has the advantage that you 
won't accidentally try to parse a syntax you aren't prepared for.

Another way is to change the xmlns urn for each draft. As long as every 
version starts with the <recording> element that will be sufficient to 
disambiguate without getting into parsing trouble.

Another would be to add another (optional?) attribute to the <recording> 
element.

I don't know enough about XML to have a strong preference among these.

But it may be a little late for this. How many more changes to the 
schema do we expect before RFC?

	Thanks,
	Paul

On 10/24/12 5:19 AM, Parthasarathi R wrote:
> Hi Ofir,
>
> This issues was raised earlier by Hadriel. I agree that it is good to
> have “version” element inside recording element to indicate the current
> version of the SIPREC metadata. This helps in case the metadata is
> extended from 1.0 to 2.0 by the update of RFC.
>
> I’m not very sure whether it is accepted in IETF draft to update the
> version of XML schema for each revision of the draft. For example, the
> current version for the metadata draft will be 0.8 and the next revision
> of the draft will be updated as 0.9. Let us look more comments for the
> generic approach to solve this issue.
>
> Thanks
>
> Partha
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Ofir Roth
> *Sent:* Wednesday, October 24, 2012 1:09 PM
> *To:* [email-masked]
> *Subject:* [siprec] Metadata version indication
>
> Hi,
>
>  From our experience in SIPREC implementations, we often come across
> vendors that use different versions of the SIPREC metadata versions
> (which are not necessarily aligned with the latest version of metadata).
>
> implementers as they can reject or handle the metadata according to
> their ability to use those versions.
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Wed, 24 Oct 2012 18:14:20 +0000

I'm not sure of the best mechanism either, but whatever it is should be helpful for future extensions as well as during our current standardization effort. 

Cheers,
Charles

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Paul Kyzivat
> Sent: Wednesday, October 24, 2012 9:04 AM
> To: [email-masked]
> Subject: Re: [siprec] Metadata version indication
> 
> > have "version" element inside recording element to indicate the current
> > I'm not very sure whether it is accepted in IETF draft to update the

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 25 Oct 2012 16:51:54 +0000

Also appreciate the issue here is anybody aware of a precedent for this being solved in other working groups?

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: 24 October 2012 17:04
> To: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 25 Oct 2012 13:08:51 -0400

I forgot: another alternative is a mime type parameter.

	Thanks,
	Paul

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 26 Oct 2012 18:52:15 +0000

[Channeling recommendation from Matt]

In the XMPP Standards Foundation (XSF), we started to include versioning into the XML namespace:

	urn:xmpp:{protocol-shortname}:{version}

For instance, Message Carbons (specified in XEP-0280) uses the namespace "urn:xmpp:carbons:2".

Now, the version number doesn't update with each revision of the specification.  Instead, it updates with any change that is not compatible with the previous protocol version.  Also, once the XEP moves from "Experimental" (roughly analogous to internet-drafts; many changes possible) to "Draft" (roughly analogous to RFC; changes are very minimal, mostly clarifications), the protocol version is *NOT CHANGED*.

This seems to be working out well for us; it means that anyone that's up to date from the experimental phase is current when we go draft/recommended-to-implement.

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

> Sent: Thursday, October 25, 2012 10:09 AM
> To: [email-masked]