Subject: Re: [siprec] Metadata version indicator consensus?

From: Ofir Roth <[email-masked]>
Date: Wed, 5 Dec 2012 11:36:53 +0200

Hi,

In regarding to the Andrew's statement below: 
> I also got the impression that there was a body of opinion that the 
> version should NOT be automatically incremented on a per draft basis.

I think that there is a concrete need for such support in versioning per draft - especially in the few first drafts where there were major changes between drafts. 
The fact is that there are implementations out there which are not planned to be aligned with the formal/final RFC version. 

Thanks,
Ofir.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hutton, Andrew
Sent: Tuesday, November 27, 2012 8:58 PM
To: [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

Hi All,

I noticed a typo in the first sentence it should have read:

Having just read through the thread again with the possible exception of Mary I think that everyone who contributed to the discussion is in favor of some kind of version number for metadata. Does anyone disagree with that?

Sorry about that I think the rest of the text is ok.

Regards
Andy

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hutton, Andrew
> Sent: 27 November 2012 18:31
> To: [email-masked]
> Subject: [siprec] Metadata version indicator consensus?
> 
> Hi All,
> 
> Having just read through the thread again and with the possible 
> exception of Mary I don't think that everyone who contributed to the 
> discussion is in favour of some kind of version number for metadata.
> Does anyone disagree with that?
> 
> I also got the impression that there was a body of opinion that the 
> version should NOT be automatically incremented on a per draft basis.
> 
> So I think we may be able to get consensus to use the mechanism as 
> used by XMPP as indicated by Matt Miller in http://www.ietf.org/mail- 
> archive/web/siprec/current/msg03532.html. In which he stated:
> 
> "This led the XSF to use a protocol versioning scheme currently in use 
> (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and 
> increments with each protocol-breaking change.  It meant that 
> different teams understood to what level another had implemented to, 
> and adoption of an I-D phase document to an RFC phase document meant 
> no churn simply because the XSF accepted the work".
> 
> So for SIPREC we would use something like 
> "urn:ietf:params:xml:ns:recording:0" starting with the next update to 
> the draft and then only update the version number if we doing 
> something that brakes the backwards compatibility.
> 
> Could people please let us know if they agree or disagree with this.
> 
> Regards
> Andy (SIPREC Co-Chair).
> 
> 
> _______________________________________________
> 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: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 5 Dec 2012 10:00:32 +0000

> On 05/12/12 3:06 PM, "Ofir Roth" <[email-masked]> wrote:

>I think that there is a concrete need for such support in versioning per
>draft - especially in the few first drafts where there were major changes
>between drafts.

Are you asking about having metadata versions for the older versions (10
and below) of the draft ? I am afraid that may not be possible. From ver
11 we would have this versioning numbers assuming we agree on what is
being discussed in this thread.

Ram
 
> 
>The fact is that there are implementations out there which are not
>planned to be aligned with the formal/final RFC version.
>
>Thanks,
>Ofir.
>
>Having just read through the thread again with the possible exception of
>Mary I think that everyone who contributed to the discussion is in favor
>of some kind of version number for metadata. Does anyone disagree with
>that?
>

---

From: Ofir Roth <[email-masked]>
Date: Wed, 5 Dec 2012 12:16:13 +0200

Hi Ram, 

Why is it not possible?

Thanks,
Ofir.

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2012 12:01 PM
To: Ofir Roth; [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

>I think that there is a concrete need for such support in versioning 
>per draft - especially in the few first drafts where there were major 
>changes between drafts.

Are you asking about having metadata versions for the older versions (10 and below) of the draft ? I am afraid that may not be possible. From ver
11 we would have this versioning numbers assuming we agree on what is being discussed in this thread.

Ram
 
>Having just read through the thread again with the possible exception 
>of Mary I think that everyone who contributed to the discussion is in 
>favor of some kind of version number for metadata. Does anyone disagree 
>with that?
>
>> "This led the XSF to use a protocol versioning scheme currently in 
>> use (e.g. "urn:xmpp:carbons:2"), where the number starts at 0 and

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Dec 2012 11:10:02 -0500

> Why is it not possible?

It would require rewriting history?

Specifically, changing the name of the schema (or anything about it) 
would require a new draft.

And in any case this should be about interoperating with implementations 
that already exist. Nobody should be creating a *new* implementation to 
an obsolete draft.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Wed, 5 Dec 2012 21:49:27 +0530

Ofir,

It is not possible to change the published draft XML schema. IMO, it is not
required to change the XML schema for each upcoming draft also. In case
there is a change in the XML schema, the version shall be incremented. I
agree with you that the initial version is not required to be "0", please
let me know how abt starting the value with "1".

Apart from this, <snip>
>planned to be aligned with the formal/final RFC version.
</snip>

Your above statement was my initial concern because the market leader
implement the draft and claim for the (SIPREC) compliance which forces other
vendors to implement the draft version as well as RFC version in the
reality.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ofir Roth
Sent: Wednesday, December 05, 2012 3:46 PM
To: Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

Hi Ram, 

Why is it not possible?

Thanks,
Ofir.

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2012 12:01 PM
To: Ofir Roth; [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

>per draft - especially in the few first drafts where there were major 

Are you asking about having metadata versions for the older versions (10 and
below) of the draft ? I am afraid that may not be possible. From ver
11 we would have this versioning numbers assuming we agree on what is being
discussed in this thread.

Ram

---

From: "Simon Farrow" <[email-masked]>
Date: Wed, 5 Dec 2012 10:35:52 -0800

Ram

I copied the schema from section 8 from the
draft-ieft-siprec-metadata-10.txt file (copy included in the text file
siprec-metadata-10.txt). I got some namespace errors I ran xsd.exe over it.
I modified it so xsd.exe now works and I have included it
(siprec-metadata-10-SF.txt) as attachment.

The salient points are

The tns was missing on recording (and other types) type e.g. <xs:element
name="recording" type="tns:recording"/>

A couple of xs: were missing from datetime.

I appreciate there are a couple of ways of achieving the same results but I
have included mine as a starting point in creating a standardized schema.

Simon Farrow
Stancil Corporation
2644 South Croddy Way
Santa Ana
CA 92704
 <http://www.stancilcorp.com> http://www.stancilcorp.com
[email-masked]
714-546-2002 ext 4311

---

From: Ofir Roth <[email-masked]>
Date: Thu, 6 Dec 2012 14:30:53 +0200

Hi Partha,

Still, considering the fact that there are such implementations, I think it will be very helpful to have 0.x versions according to the draft numbers. 
>From my experience with such implementations, it is very hard to determine the draft number by just looking in the metadata XML itself. 

Thanks,
Ofir.

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2012 6:19 PM
To: Ofir Roth; 'Ram Mohan R (rmohanr)'; [email-masked]
Subject: RE: [siprec] Metadata version indicator consensus?

Ofir,

It is not possible to change the published draft XML schema. IMO, it is not required to change the XML schema for each upcoming draft also. In case there is a change in the XML schema, the version shall be incremented. I agree with you that the initial version is not required to be "0", please let me know how abt starting the value with "1".

Apart from this, <snip>
</snip>

Your above statement was my initial concern because the market leader implement the draft and claim for the (SIPREC) compliance which forces other vendors to implement the draft version as well as RFC version in the reality.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ofir Roth
Sent: Wednesday, December 05, 2012 3:46 PM
To: Ram Mohan R (rmohanr); [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

Hi Ram, 

Why is it not possible?

Thanks,
Ofir.

-----Original Message-----
From: Ram Mohan R (rmohanr) [mailto:[email-masked]]
Sent: Wednesday, December 05, 2012 12:01 PM
To: Ofir Roth; [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

Ram

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 06 Dec 2012 11:55:27 -0500

>>From my experience with such implementations, it is very hard to determine the draft number by just looking in the metadata XML itself.

If we change increment the version number in the schema urn each time 
there is a schema change, then you can search through draft versions for 
the one where that first appeared. It is a little harder than pulling 
the draft number out of the URN, but not much.

The advantage of that over changing with each draft is that editorial 
changes that don't affect the schema also don't affect interoperability. 
Especially, if you implement draft-NN and then that goes to draft-NN+3 
and then becomes an RFC without changing the schema then your 
implementation need not be revised to be compatible with the spec.

	Thanks,
	Paul

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 8 Dec 2012 13:16:53 +0530

Hi all,

Based on the discussion in this mail thread, I propose the following
metadata version indicator text to be added in the "namespace" section of
draft-ietf-siprec-metadata draft:

"The URN is as follows: urn:ietf:params:xml:ns:recording:1
				
The value '1' represent SIPREC metadata version. This version value helps
SRS to know the exact metadata XML schema sent by SRC. The version value
MUST be incremented by one in case there is a changed in metadata XML schema
in the forthcoming draft revision or future updates. Also, the version
number does not indicate the backward compatibility with the previous
version."

Please let me know in case any objection/suggestion to the above text.

Thanks
Partha

PS: The initial value is chosen as "1" because couple of earlier
implementation exists.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Thursday, December 06, 2012 10:25 PM
To: [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

On 12/6/12 7:30 AM, Ofir Roth wrote:
> Hi Partha,
>
> Still, considering the fact that there are such implementations, I think
it will be very helpful to have 0.x versions according to the draft numbers.
>>From my experience with such implementations, it is very hard to determine
the draft number by just looking in the metadata XML itself.

	Thanks,
	Paul

> It is not possible to change the published draft XML schema. IMO, it is
not required to change the XML schema for each upcoming draft also. In case
there is a change in the XML schema, the version shall be incremented. I
agree with you that the initial version is not required to be "0", please
let me know how abt starting the value with "1".
> Are you asking about having metadata versions for the older versions (10
and

---

From: Brian Rosen <[email-masked]>
Date: Mon, 10 Dec 2012 09:48:59 -0500

may I suggest:

The value '1' represent SIPREC metadata version. This version value allows the
SRS to know the exact metadata XML schema sent by the SRC. This document describes version 1.  Implementations may not interoperate if the version implemented by the sender is not known by the receiver.  No negotiation of versions is provided.  There is no significance to the version number although documents which update or obsolete this document (possibly including drafts of such documents) should include a higher version number if the metadata changes in a non-interoperable way.

I don't think a MUST can be used to bind a future document writer.

Brian

On Dec 8, 2012, at 2:46 AM, Parthasarathi R <[email-masked]> wrote:

> The version value
> in the forthcoming draft revision or future updates

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 10 Dec 2012 22:54:52 +0530

Brian,

Thanks for your suggested text. In case it is not recommended to use "MUST"
for future document writer, I'm fine. I have only one concern in the
suggested text. The last statement words "in a non-interoperable way" seems
to indicate some kind of backward-compatibility which has to be ensured in
the draft for interoperable changes in XML schema. I agree with your
suggestion except for the last 5 words and the updated text will look like:

" The value '1' represent SIPREC metadata version. This version value allows
the SRS to know the exact metadata XML schema sent by the SRC. This document
describes version 1.  Implementations may not interoperate if the version
implemented by the sender is not known by the receiver.  No negotiation of
versions is provided.  There is no significance to the version number
although documents which update or obsolete this document (possibly
including drafts of such documents) should include a higher version number
if the metadata XML schema changes."

I'm not very clear how to qualify whether the updated XML schema is backward
compatible with earlier XML schema. Please let me know your opinion on the
same.

Also, I'm not sure whether lowercase "should" keyword is allowed within
standard track document and I'll run IETF nits tool with the text to confirm
my doubt.

Thanks
Partha 

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, December 10, 2012 8:19 PM
To: Parthasarathi R
Cc: [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

may I suggest:

The value '1' represent SIPREC metadata version. This version value allows
the
SRS to know the exact metadata XML schema sent by the SRC. This document
describes version 1.  Implementations may not interoperate if the version
implemented by the sender is not known by the receiver.  No negotiation of
versions is provided.  There is no significance to the version number
although documents which update or obsolete this document (possibly
including drafts of such documents) should include a higher version number
if the metadata changes in a non-interoperable way.

Brian

---

From: Brian Rosen <[email-masked]>
Date: Mon, 10 Dec 2012 12:29:13 -0500

I'm happy with the reword.  

I do think you can use "should" where we are not defining protocol behavior.

I should think so anyway :)

Brian

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 10 Dec 2012 23:15:23 +0530

Brian,

Thanks for the quick closure. 

Hi all,

Could you please let us know any objection/suggestion to the below proposed
text in a week time. 

Thanks
Partha

-----Original Message-----
From: Brian Rosen [mailto:[email-masked]] 
Sent: Monday, December 10, 2012 10:59 PM
To: Parthasarathi R
Cc: [email-masked]
Subject: Re: [siprec] Metadata version indicator consensus?

Brian
On Dec 10, 2012, at 12:24 PM, Parthasarathi R <[email-masked]>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Tue, 11 Dec 2012 05:03:17 +0000

I am fine with the below text.

Ram

> On 10/12/12 11:15 PM, "Parthasarathi R" <[email-masked]>
>wrote:

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 11 Dec 2012 12:09:51 +0000

Hi Simon,

Thanks for doing that great input.

Regards
Andy (SIPREC Co-Chair).

From: [email-masked] [mailto:[email-masked]] On Behalf Of Simon Farrow
Sent: 05 December 2012 18:36
To: 'Ram Mohan R (rmohanr)'; [email-masked]
Subject: [siprec] Metadata

Ram

I copied the schema from section 8 from the draft-ieft-siprec-metadata-10.txt file (copy included in the text file siprec-metadata-10.txt). I got some namespace errors I ran xsd.exe over it. I modified it so xsd.exe now works and I have included it (siprec-metadata-10-SF.txt) as attachment.

The salient points are

The tns was missing on recording (and other types) type e.g. <xs:element name="recording" type="tns:recording"/>

I appreciate there are a couple of ways of achieving the same results but I have included mine as a starting point in creating a standardized schema.

Simon Farrow
Stancil Corporation
2644 South Croddy Way
Santa Ana
CA 92704
http://www.stancilcorp.com
[email-masked]<mailto:[email-masked]>
714-546-2002 ext 4311

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 11 Dec 2012 12:31:33 +0000

I am also ok with the latest text.

Andy

> Behalf Of Ram Mohan R (rmohanr)
> Sent: 11 December 2012 05:03
> To: Parthasarathi R; 'Brian Rosen'; [email-masked]
> >> suggested text. The last statement words "in a non-interoperable
> way"
> >seems
> >> to indicate some kind of backward-compatibility which has to be
> ensured
> >>in
> >> suggestion except for the last 5 words and the updated text will
> look
> >like:
> >>
> >> " The value '1' represent SIPREC metadata version. This version
> value
> >allows
> >> implemented by the sender is not known by the receiver.  No
> negotiation
> >>of
> >> compatible with earlier XML schema. Please let me know your opinion
> on
> >>the
> >> same.
> >>
> >> implemented by the sender is not known by the receiver.  No
> negotiation
> >>of
> >>> MUST be incremented by one in case there is a changed in metadata
> XML
> >> schema

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 12 Dec 2012 03:10:21 +0000

Hi Simon,

Thanks for your inputs and for validating the fixing the nits.

All,

Here are the changes proposed by Simon. Please let me know if any one has
concerns. 

Note: As I am not an XML expert I cross checked these modifications with
Joe Hildebrand and Peter Saint-Andre here in Cisco to understand the
impact. Their feedback is " as long as the element name + namespace URI is
known to not collide with anything else that group has done, it's fine to
put them in the same namespace" and since there are no collisions here we
should be fine.
I have also copied them here in this mail to help us with any questions
this WG has.

Gist of the changes proposed by Simon:

   <xs:element name="recording" type="recording"/>
    Replaced by
   <xs:element name="recording" type="tns:recording"/>

The types of elements  (e.g dataMode, group, session, stream, participant)
are all defined as type="tns:<element_name>". In the earlier version it
was type="element_name".
   
Please let me know if any one has concerns in the above changes. Otherwise
I will incorporate these in the next revision of the draft.

Regards,
Ram

PS: Attached the original schema (siprec-metadata-10) as well as modified
one(siprec-metadata-10-SF)

> On 11/12/12 5:39 PM, "Hutton, Andrew"
><[email-masked]> wrote:

>siprec-metadata-10.txt). I got some namespace errors I ran xsd.exe over
>it. I modified it so xsd.exe now works and I have included it
>I appreciate there are a couple of ways of achieving the same results but
>I have included mine as a starting point in creating a standardized
>schema.
>
>
>Simon Farrow
>Stancil Corporation
>2644 South Croddy Way
>Santa Ana
>CA 92704