Subject: [siprec] Metadata version indicator consensus?

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 27 Nov 2012 18:31:21 +0000

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

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Nov 2012 13:49:45 -0500

I am fine with this.

It means the RFC has some non-zero/non-one version, but that is okay.

Brian

On Nov 27, 2012, at 1:31 PM, "Hutton, Andrew" <[email-masked]> wrote:

> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 27 Nov 2012 18:58:23 +0000

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

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Nov 2012 13:08:14 -0600

I would still like to understand the intent of the version number as I've
asked in several of the threads on this topic.  If folks can answer these
questions so it's clear what the intended usage and meaning of that version
number is, that would address my primary concerns:
1)  If the version number is not the same, then is there no intention to
try to interop?  ["Yes" was the impression I got from what Hadriel said but
the subsequent discussion didn't seem to agree with that]
2) Is the expectation for implementations to be backwards compatible -
e.g., version 1.1 MUST be able to support 1.0 implementations?  [This is my
biggest concern.  If it's "Yes", then I think there is then a burden added
when any changes are made to the schema to minimize the complexity for
implementors.]

Mary.

On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew <
[email-masked]> wrote:

> 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?
>
> 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:
>
> (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".
>
> "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.
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Tue, 27 Nov 2012 19:23:58 +0000

Hi Mary,

See below.

Regards
Andy

> From: Mary Barnes [mailto:[email-masked]]
> Sent: 27 November 2012 19:08
> To: Hutton, Andrew
> Cc: [email-masked]
> Subject: Re: [siprec] Metadata version indicator consensus?
> 
> I would still like to understand the intent of the version number as
> I've asked in several of the threads on this topic.  If folks can
> answer these questions so it's clear what the intended usage and
> meaning of that version number is, that would address my primary
> concerns:
> 1)  If the version number is not the same, then is there no intention
> to try to interop?  ["Yes" was the impression I got from what Hadriel
> said but the subsequent discussion didn't seem to agree with that]

[AndyH] It was my impression from the discussion that if the version number is different then there is no intention to interop.

> e.g., version 1.1 MUST be able to support 1.0 implementations?  [This
> is my biggest concern.  If it's "Yes", then I think there is then a
> burden added when any changes are made to the schema to minimize the
> complexity for implementors.]
> 

[AndyH] - No I don't believe there is this expectation. The version number would only be incremented if there is a backwards compatibility issue so I would hope that such changes are rare. Having said that they are more likely to occur whilst the draft is immature which I don't believe is a problem.

> Mary.
> 
> 
> On Tue, Nov 27, 2012 at 12:31 PM, Hutton, Andrew
> <[email-masked]> wrote:
> Hi All,
>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Nov 2012 13:30:26 -0600

Given your's and Brian's answers, I think some text should be added around
the description of the version number indicating that the intent is to
minimize interop problems  -i.e., you'll know that the entity you intend to
interact with is of the same version number and that there is no
expectation for interop between different version numbers and there is no
intention to ensure backwards compatibility with previous versions.

Thanks,
Mary.

On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew <
[email-masked]> wrote:

> [AndyH] It was my impression from the discussion that if the version
> number is different then there is no intention to interop.
>
>
> [AndyH] - No I don't believe there is this expectation. The version number
> would only be incremented if there is a backwards compatibility issue so I
> would hope that such changes are rare. Having said that they are more
> likely to occur whilst the draft is immature which I don't believe is a
> problem.

---

From: Brian Rosen <[email-masked]>
Date: Tue, 27 Nov 2012 14:48:43 -0500

Seems reasonable to me.

Brian

On Nov 27, 2012, at 2:30 PM, Mary Barnes <[email-masked]> wrote:

> Given your's and Brian's answers, I think some text should be added around the description of the version number indicating that the intent is to minimize interop problems  -i.e., you'll know that the entity you intend to interact with is of the same version number and that there is no expectation for interop between different version numbers and there is no intention to ensure backwards compatibility with previous versions.  
> 
> Thanks,
> Mary.
> 
> 
> On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew <[email-masked]> wrote:
> Hi Mary,
> 
> See below.
> 
> Regards
> Andy
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Nov 2012 15:07:17 -0500

I'm ok with this.

While I think there should be no *expectation* of interoperability with 
different version numbers, I also think there is nothing *forbidding* an 
SRS from supporting SRCs using different versions.

	Thanks,
	Paul

On 11/27/12 2:48 PM, Brian Rosen wrote:
> Seems reasonable to me.
>
> Brian
>
> On Nov 27, 2012, at 2:30 PM, Mary Barnes <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> Given your's and Brian's answers, I think some text should be added
>> around the description of the version number indicating that the
>> intent is to minimize interop problems  -i.e., you'll know that the
>> entity you intend to interact with is of the same version number and
>> that there is no expectation for interop between different version
>> numbers and there is no intention to ensure backwards compatibility
>> with previous versions.
>>
>> Thanks,
>> Mary.
>>
>>
>> On Tue, Nov 27, 2012 at 1:23 PM, Hutton, Andrew
>> <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Hi Mary,
>>
>>     See below.
>>
>>     Regards
>>     Andy
>>
>>     > From: Mary Barnes [mailto:[email-masked]
>>     <mailto:[email-masked]>]
>>     > Cc: [email-masked] <mailto:[email-masked]>
>>     [AndyH] It was my impression from the discussion that if the
>>     version number is different then there is no intention to interop.
>>
>>
>>     [AndyH] - No I don't believe there is this expectation. The
>>     version number would only be incremented if there is a backwards
>>     compatibility issue so I would hope that such changes are rare.
>>     Having said that they are more likely to occur whilst the draft is
>>     immature which I don't believe is a problem.
>>
>>
>>
>>
>>     > Mary.
>>     >
>>     >
>>     > <[email-masked]
>>     <mailto:[email-masked]>> wrote:
>>     > Hi All,
>>     >
>>     > [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 27 Nov 2012 14:37:26 -0600

Sure - it's not forbidden, but it's not recommended and we don't want
people saying the spec is broken because the different versions don't
interoperate.

Mary.

On Tue, Nov 27, 2012 at 2:07 PM, Paul Kyzivat <[email-masked]> wrote:

>> <mailto:mary.ietf.barnes@**gmail.com <[email-masked]>>>
>> wrote:
>>
>>> <andrew.hutton@siemens-**enterprise.com<[email-masked]>
>>> <mailto:andrew.hutton@siemens-**enterprise.com<[email-masked]>>>
>>> wrote:
>>>
>>>     Hi Mary,
>>>
>>>     See below.
>>>
>>>     Regards
>>>     Andy
>>>
>>>     > From: Mary Barnes [mailto:mary.ietf.barnes@**gmail.com<[email-masked]>
>>>     <mailto:mary.ietf.barnes@**gmail.com <[email-masked]>>]
>>>     > <andrew.hutton@siemens-**enterprise.com<[email-masked]>
>>>     <mailto:andrew.hutton@siemens-**enterprise.com<[email-masked]>>>
>>> wrote:
>>>     > Hi All,
>>>     >
>>>     > archive/web/siprec/current/**msg03532.html. In which he stated:
>>>     >
>>>     > "urn:ietf:params:xml:ns:**recording:0" starting with the next
>>>     update to
>>>     > ______________________________**_________________
>>>     > siprec mailing list
>>>     > https://www.ietf.org/mailman/**listinfo/siprec<https://www.ietf.org/mailman/listinfo/siprec>
>>>
>>>
>>> ______________________________**_________________
>>> siprec mailing list
>>> https://www.ietf.org/mailman/**listinfo/siprec<https://www.ietf.org/mailman/listinfo/siprec>
>>>
>>
>>
>>
>> ______________________________**_________________
>> siprec mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/siprec<https://www.ietf.org/mailman/listinfo/siprec>
>>
>>
> ______________________________**_________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/siprec<https://www.ietf.org/mailman/listinfo/siprec>
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 29 Nov 2012 16:46:51 +0000

I am ok with this approach and the recommendation.

Ram

> On 28/11/12 1:37 AM, "Paul Kyzivat" <[email-masked]> wrote: