Subject: Re: [siprec] Metadata version indication

From: Brian Rosen <[email-masked]>
Date: Thu, 8 Nov 2012 16:31:59 -0500

In the meeting today, this subject was raised again.

There is a nuance that was discussed, which was coming up with a way to know versions of the metadata prior to publication.

Namespaces for XML in the IETF tend to look like:
urn:ietf:params:xml:ns:foo

I would propose that we have the namespace here be:
urn:ietf:params:xml:ns:recording:<version>

I propose that drafts have the <Version> = 0.<draft version>
so, for example: urn:ietf:params:xml:ns:recording:0.09
I propose that the text have an RFC editor note to replace the version with "1.0" when the RFC is published

Brian

On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu) <[email-masked]> wrote:

> [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.
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf
>> Of Paul Kyzivat
>> Sent: Thursday, October 25, 2012 10:09 AM
>> To: [email-masked]
>> Subject: Re: [siprec] Metadata version indication
>> 
>> I forgot: another alternative is a mime type parameter.
>> 
>> 	Thanks,
>> 	Paul
>> 
>> On 10/24/12 12:03 PM, Paul Kyzivat wrote:
>>> 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).
>>>> 
>>>> 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.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> siprec mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/siprec
>>>> 
>>> 
>>> _______________________________________________
>>> siprec mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/siprec
>>> 
>> 
>> _______________________________________________
>> 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: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Nov 2012 09:04:09 -0500

> I propose that the text have an RFC editor note to replace the version with "1.0" when the RFC is published

Having the version coupled to the version of the draft is attractive in 
its simplicity. But it is a bit messy when there are versions of the 
metatdata that don't change the schema. But that hardly ever happens, so 
maybe it doesn't matter.

With this scheme we will have to think of something else beyond V1.0. 
But I suppose we will then have a bis draft then and we can use the same 
scheme with that.

So yes, this WFM.

	Thanks,
	Paul

---

From: "Dave Higton" <[email-masked]>
Date: Fri, 9 Nov 2012 14:15:00 +0000

It isn't possible to look into the future with the certainty that nothing will change.

I, too, think it would be helpful to have a version number in the metadata.

I'd vote for it to be decoupled from the version of SIPREC.  It's just a number, after all.

Dave

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 09 November 2012 14:04
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [siprec] Metadata version indication

On 11/8/12 4:31 PM, Brian Rosen wrote:
> I propose that drafts have the <Version> = 0.<draft version> so, for 
> example: urn:ietf:params:xml:ns:recording:0.09

Having the version coupled to the version of the draft is attractive in its simplicity. But it is a bit messy when there are versions of the metatdata that don't change the schema. But that hardly ever happens, so maybe it doesn't matter.

With this scheme we will have to think of something else beyond V1.0. 
But I suppose we will then have a bis draft then and we can use the same scheme with that.

So yes, this WFM.

	Thanks,
	Paul

>>> From: [email-masked] [mailto:[email-masked]] On 
>>> Behalf Of Paul Kyzivat
>>>> 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.
>>>>
>>>>> 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
>>>>>  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.
>>>>>
>>>>> implementers as they can reject or handle the metadata according 
>>>>> to their ability to use those versions.
>>>>>

NICE Systems UK Limited ("NICE") is registered in England under company number, 3403044. The registered office of NICE is at Tollbar Way, Hedge End, Southampton, Hampshire SO30 2ZP.

Confidentiality: This communication and any attachments are intended for the above-named persons only and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of NICE. If this communication has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender by e-mail immediately.

Monitoring: NICE may monitor incoming and outgoing e-mails.

Viruses: Although we have taken steps toward ensuring that this e-mail and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.

---

From: "Parthasarathi R" <[email-masked]>
Date: Mon, 12 Nov 2012 23:11:16 +0530

Hi all,

I like the idea of using version in XML namespace. Including Peter in this
mail thread to get XML expert comments in this approach. 

BTW, While Mary discussed about SIPREC version in the meeting, I worried a
bit in case Vendor/Customer consider the draft version as a standard
compliance. It may be possible in the future as today, I'm seeing the
convention of requesting & showing the standard compliance for informational
RFC.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Paul Kyzivat
Sent: Friday, November 09, 2012 7:34 PM
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [siprec] Metadata version indication

On 11/8/12 4:31 PM, Brian Rosen wrote:
> There is a nuance that was discussed, which was coming up with a way to
know versions of the metadata prior to publication.

So yes, this WFM.

	Thanks,
	Paul

>> 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.
>>>> Another would be to add another (optional?) attribute to the
<recording>

---

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

I would like to understand better the WG perspective on this version.  My
understanding from Hadriel was that the only use for this is for a version
1.0 system (per the RFC to be) to know that it can't interface with a .07,
for example.  The reasoning seems to be that people have already
implemented various versions of the draft.  So, it seems the primary reason
is so that one would know right off whether the implementations were
compatible.  However, that does require that existing implementations make
changes to add their version number.   How many of these implementations
are out there now?

My expectation and what I was expressing at the microphone is as Partha
suggests, vendor A has implemented .07 and vendor B has implemented the
RFC.  Since vendor A also still interfaces with systems that also
implemented .07, they need to support both in their product. Thus, I can't
see people using the version number as Hadriel suggests (i.e., know you
can't interwork), but rather I can see people interpreting the various
versions as needing to be made interoperable.  As was discussed in INSIPID,
it seems to me that if there is an expectation of interoperability with a
specific version of the draft, then we should publish that as
informational.

I would think it might be possible that the metadata could be adjusted to
accommodate the earlier versions - i.e, someone that has implemented the
RFC might be able to interoperate with a .07.  But, I personally think that
likely puts undue burden and complexity on the schema.

My understanding is that in the web world, this versioning is the norm.
 However, in the web world, software changes very frequently.  In the world
in which many of these implementations will operate, the world does not
change frequently.  Thus, someone that has implemented .07 is likely not to
implement the RFC for a while.

Mary.

On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R <
[email-masked]> wrote:

> Of
> Behalf
> every
> the

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 13 Nov 2012 16:06:48 -0500

Mary,

IMO, the first draft that incorporates this idea (say it is -10, since 
-09 didn't) will include the version number 0.10 in the schema URN. E.g.

urn:ietf:params:xml:ns:recording:0.10

Implementations of that will include this URN. Older implementations 
will not have a version number in their namespace urn. Then:

- Older versions interoperating (or not) with each other will
   continue unchanged.

- Older versions interoperating with new versions won't understand
   the versioning, but will presumably note the mismatch of schema URN
   and maybe punt.

- Newer versions interoperating with versions prior to -10 will note
   the mismatch, as they will when interoperating with versions >=
   to -10 that differ from their own.

	Thanks,
	Paul

On 11/13/12 3:30 PM, Mary Barnes wrote:
> I would like to understand better the WG perspective on this version.
>   My understanding from Hadriel was that the only use for this is for a
> version 1.0 system (per the RFC to be) to know that it can't interface
> with a .07, for example.  The reasoning seems to be that people have
> already implemented various versions of the draft.  So, it seems the
> primary reason is so that one would know right off whether the
> implementations were compatible.  However, that does require that
> existing implementations make changes to add their version number.   How
> many of these implementations are out there now?
>
> implemented .07, they need to support both in their product. Thus, I
> can't see people using the version number as Hadriel suggests (i.e.,
> know you can't interwork), but rather I can see people interpreting the
> various versions as needing to be made interoperable.  As was discussed
> in INSIPID, it seems to me that if there is an expectation of
> interoperability with a specific version of the draft, then we should
> publish that as informational.
>
> I would think it might be possible that the metadata could be adjusted
> to accommodate the earlier versions - i.e, someone that has implemented
> the RFC might be able to interoperate with a .07.  But, I personally
> think that likely puts undue burden and complexity on the schema.
>
>   However, in the web world, software changes very frequently.  In the
> world in which many of these implementations will operate, the world
> does not change frequently.  Thus, someone that has implemented .07 is
> likely not to implement the RFC for a while.
>
> Mary.
>
>
> On Mon, Nov 12, 2012 at 11:41 AM, Parthasarathi R
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of
>     Paul Kyzivat
>     Cc: [email-masked] <mailto:[email-masked]>
>      > I propose that the text have an RFC editor note to replace the
>     version
>     with "1.0" when the RFC is published
>
>      > On Oct 26, 2012, at 2:52 PM, Charles Eckel (eckelcu)
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>      >
>      >> In the XMPP Standards Foundation (XSF), we started to include
>     versioning
>     into the XML namespace:
>      >>
>      >> For instance, Message Carbons (specified in XEP-0280) uses the
>     namespace
>     "urn:xmpp:carbons:2".
>      >>
>      >> Matt Miller < [email-masked] <mailto:[email-masked]> >
>      >> Cisco Systems, Inc.
>      >>
>      >>> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>      >>> Of Paul Kyzivat
>      >>> To: [email-masked] <mailto:[email-masked]>
>      >>>>> *From:[email-masked]
>     <mailto:[email-masked]> [mailto:[email-masked]
>     <mailto:[email-masked]>] *On
>      >>>>> Behalf Of *Ofir Roth
>      >>>>> *To:* [email-masked] <mailto:[email-masked]>
>     across
>      >>>>> [email-masked] <mailto:[email-masked]>
>      >>>> [email-masked] <mailto:[email-masked]>
>      >>> [email-masked] <mailto:[email-masked]>
>      >> [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Tue, 13 Nov 2012 16:33:20 -0600

I still don't get Hadriel's point then as he seemed concerned about what's
in the field right now.  If we are saying version 10 is the draft folks
should implement now while they wait for the RFC, then publish that as
experimental.

I would also think that designing the metadata with extensibilIty would
help for the folks that might want interoperability with earlier versions.

I also think that you should not go by draft versions.  You should go by
actual versions of the metadata.  People that aren't directly involved in
this (e.g., people who review RFPs, etc.) won't at all get the subtlety
that you might be able to implement different versions and have the
document still contain the same metadata.  If you go the version route,
you're going to need explanatory text somewhere as to which versions have
the same metadata.

I understand the need for folks to deploy products now based upon specs
that might be out there.  But, IMHO, that's at their own risk and I really
think we're going down a rathole if for every new set of protocol work, we
are going to make sure that there's at least one version of the draft that
still works.

Mary.

On Tuesday, November 13, 2012, Paul Kyzivat wrote:

> Mary,
>
> IMO, the first draft that incorporates this idea (say it is -10, since -09
> didn't) will include the version number 0.10 in the schema URN. E.g.
>
> urn:ietf:params:xml:ns:**recording:0.10
>
> Implementations of that will include this URN. Older implementations will
> not have a version number in their namespace urn. Then:
>
>>      > urn:ietf:params:xml:ns:**recording:<version>
>>      >
>>      > so, for example: urn:ietf:params:xml:ns:**recording:0.09
>>      >>      urn:xmpp:{protocol-shortname}:**{version}
>>      >>
>>     draft/recommended-to-**implement.
>>      >>
>>      >> - m&m
>>      >>
>>      >>>>> ______________________________**_________________
>>      >>>>> 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
>>      >>> 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
>>     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>
>>
>>
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Nov 2012 11:56:49 -0500

On 11/13/12 5:33 PM, Mary Barnes wrote:
> I still don't get Hadriel's point then as he seemed concerned about
> what's in the field right now.  If we are saying version 10 is the draft
> folks should implement now while they wait for the RFC, then publish
> that as experimental.

Publishing as experimental is way too heavy weight for the purpose here.

> help for the folks that might want interoperability with earlier versions.

I don't want to see us confine ourselves to backward compatible changes 
before we get to version 1.0.

> actual versions of the metadata.  People that aren't directly involved
> in this (e.g., people who review RFPs, etc.) won't at all get the
> subtlety that you might be able to implement different versions and have
> the document still contain the same metadata.  If you go the version
> route, you're going to need explanatory text somewhere as to which
> versions have the same metadata.

I had also been thinking of counting versions independently of draft 
version numbers. Brian suggested using draft version numbers. (Prior to 
1.0.) While that has the potential disadvantage of showing change when 
there is none, I think every version of the doc to date has had some 
change to the schema, so I don't think it is such a risk. And there is 
great convenience in tying it to the draft version number. So I was 
happy to go along with this, though I don't feel strongly about it.

> that might be out there.

AFAIK we are not talking about *products*. Rather we are talking about 
*prototypes*, and testing of interoperability among prototypes.

> But, IMHO, that's at their own risk and I
> really think we're going down a rathole if for every new set of protocol
> work, we are going to make sure that there's at least one version of the
> draft that still works.

If we were building a mechanism solely for this pre-release purpose I 
would be opposed. I see this as installing a mechanism that will work 
for version 1.0 and future standardized extensions/revisions of it. And 
then it is convenient that the same mechanism can be used for this 
pre-standard testing as well.

	Thanks,
	Paul

>     IMO, the first draft that incorporates this idea (say it is -10,
>     since -09 didn't) will include the version number 0.10 in the schema
>     URN. E.g.
>
>     urn:ietf:params:xml:ns:__recording:0.10
>
>              I like the idea of using version in XML namespace.
>         Including Peter
>              in this
>              BTW, While Mary discussed about SIPREC version in the
>         meeting, I
>              worried a
>               > There is a nuance that was discussed, which was coming
>         up with a
>              way to
>               > urn:ietf:params:xml:ns:__recording:<version>
>               >
>               > so, for example: urn:ietf:params:xml:ns:__recording:0.09
>               >>      urn:xmpp:{protocol-shortname}:__{version}
>               >>
>              "Experimental" (roughly analogous to internet-drafts; many
>         changes
>              possible)
>               >> This seems to be working out well for us; it means that
>         anyone
>              that's up
>              draft/recommended-to-__implement.
>               >>
>               >> - m&m
>               >>
>               >>>> I appreciate the problem here. There are a variety of
>         ways to
>              solve it.
>               >>>>
>               >>>> 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
>               >>>> Another way is to change the xmlns urn for each
>         draft. As long
>              as every
>               >>>>> This issues was raised earlier by Hadriel. I agree
>         that it is
>              good to
>               >>>>> 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
>               >>>>> 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
>               >>>>> 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
>               >>>>> _________________________________________________
>               >>>>> 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
>               >>> 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
>         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>
>
>
>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 14 Nov 2012 12:10:34 -0500

> If we were building a mechanism solely for this pre-release purpose I would be opposed. I see this as installing a mechanism that will work for version 1.0 and future standardized extensions/revisions of it. And then it is convenient that the same mechanism can be used for this pre-standard testing as well.
> 
This

---

From: Mary Barnes <[email-masked]>
Date: Wed, 14 Nov 2012 14:07:14 -0600

> Publishing as experimental is way too heavy weight for the purpose here.

[MB]  I somewhat disagree that this is heavyweight but it's not worth
debating. /MB]

> before we get to version 1.0.

[MB] Yeah.  I said in my first response that this likely would be too
restrictive. [/MB]

> there is none, I think every version of the doc to date has had some change
> to the schema, so I don't think it is such a risk. And there is great
> convenience in tying it to the draft version number. So I was happy to go
> along with this, though I don't feel strongly about it.
>
>

[MB] If you are talking about prototypes, then why do you need the version
number in the protocol?  Why can't the people that are doing the testing
*ask* what version is supported.  If they are not the same, then you are
wasting your time trying to test, right?   Or, is the expectation that
someone that has implemented .11 MUST be able to interoperate with .10?  I
don't think that's what you are suggesting.

> would be opposed. I see this as installing a mechanism that will work for
> version 1.0 and future standardized extensions/revisions of it. And then it
> is convenient that the same mechanism can be used for this pre-standard
> testing as well.
>
[MB] I agree that you need a version number. 1.0 for the first version of
the RFC and then 2.0 if you do a bis.  If someone wants to put the .10 in
there and work with another vendor to see if their .10 software works with
the other guy's, I don't see that this requires anything to be put into the
documents being produced by this WG. Nor, do I think it requires any more
discussion.  We don't develops specs to ensure that prototypes (and various
draft versions) are interoperable, we do prototypes to ensure the final
RFCs enable interoperability.  Certainly, the former would be a good thing
as that means the document is headed in the right direction. [/MB]

>>     urn:ietf:params:xml:ns:__**recording:0.10
>>
>>
>>         <[email-masked] <mailto:partha@parthasarathi.**co.in<[email-masked]>
>> >>
>>         wrote:
>>
>>              Hi all,
>>
>>              convention of requesting & showing the standard compliance
>> for
>>              informational
>>              RFC.
>>
>>              Thanks
>>              Partha
>>
>>              From: [email-masked] <mailto:siprec-bounces@ietf.**
>> org <[email-masked]>>
>>              [mailto:siprec-bounces@ietf.**org <[email-masked]>
>>         <mailto:siprec-bounces@ietf.**org <[email-masked]>>] On
>>              Behalf Of
>>              Paul Kyzivat
>>               > urn:ietf:params:xml:ns:__**recording:<version>
>>
>>               >
>>               > so, for example: urn:ietf:params:xml:ns:__**
>> recording:0.09
>>
>>               >>      urn:xmpp:{protocol-shortname}:**__{version}
>>
>>               >>
>>              specification.  Instead, it updates with any change that is
>> not
>>              compatible
>>              draft/recommended-to-__**implement.
>>
>>               >>
>>               >> - m&m
>>               >>
>>               >>> From: [email-masked]
>>         <mailto:siprec-bounces@ietf.**org <[email-masked]>>
>>              [mailto:siprec-bounces@ietf.**org <[email-masked]>
>>         <mailto:siprec-bounces@ietf.**org <[email-masked]>>] On
>>              Behalf
>>               >>> Of Paul Kyzivat
>>               >>>> a version number in the mime-type name itself. This
>> could
>>              present some
>>               >>>> version starts with the <recording> element that will
>> be
>>              sufficient to
>>               >>>> I don't know enough about XML to have a strong
>> preference
>>              among these.
>>               >>>>
>>              <mailto:siprec-bounces@ietf.**org <[email-masked]>>
>>         [mailto:siprec-bounces@ietf.**org <[email-masked]>
>>              <mailto:siprec-bounces@ietf.**org <[email-masked]>>]
>> *On
>>               >>>>> Behalf Of *Ofir Roth
>>               >>>>> ______________________________**___________________
>>
>>               >>>>> siprec mailing list
>>               >>>>> https://www.ietf.org/mailman/_**_listinfo/siprec<https://www.ietf.org/mailman/__listinfo/siprec>
>>         <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>
>>         <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>
>>         <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>
>>         <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>
>>         <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>
>>         <https://www.ietf.org/mailman/**listinfo/siprec<https://www.ietf.org/mailman/listinfo/siprec>
>> >
>>
>>
>>
>>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Nov 2012 15:23:48 -0500

On 11/14/12 3:07 PM, Mary Barnes wrote:

> [MB] If you are talking about prototypes, then why do you need the
> version number in the protocol?  Why can't the people that are doing the
> testing *ask* what version is supported.  If they are not the same, then
> you are wasting your time trying to test, right?   Or, is the
> expectation that someone that has implemented .11 MUST be able to
> interoperate with .10?  I don't think that's what you are suggesting.

I'll let Hadriel speak to this.

>     If we were building a mechanism solely for this pre-release purpose
>     I would be opposed. I see this as installing a mechanism that will
>     work for version 1.0 and future standardized extensions/revisions of
>     it. And then it is convenient that the same mechanism can be used
>     for this pre-standard testing as well.
>
> [MB] I agree that you need a version number. 1.0 for the first version
> of the RFC and then 2.0 if you do a bis.  If someone wants to put the
> .10 in there and work with another vendor to see if their .10 software
> works with the other guy's, I don't see that this requires anything to
> be put into the documents being produced by this WG. Nor, do I think it
> requires any more discussion.

I don't expect anything to be in the document about how pre-1.0 versions 
are assigned. (That wouldn't be very useful when the RFC is published.) 
But the editor of the metadata draft does need to know what to put into 
the draft schemas. Consider it an informal agreement. I wouldn't object 
to a to-be-removed-by-RFC-editor note.

> We don't develops specs to ensure that
> prototypes (and various draft versions) are interoperable, we do
> prototypes to ensure the final RFCs enable interoperability.  Certainly,
> the former would be a good thing as that means the document is headed in
> the right direction. [/MB]

I'm not inclined to be sympathetic to people who whine that the RFC is 
incompatible with some implementation they made of a pre-RFC draft.

But I am fine with doing trivial things that ease testing and getting to 
RFC-compatible implementations.

	Thanks,
	Paul

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 14 Nov 2012 20:39:38 +0000

> as that means the document is headed in the right direction. [/MB]

Anecdotal evidence from my work in the XMPP Standards Foundation (XSF):

The XSF started with namespaces (e.g. "http://jabber.org/protocol/muc") that did not change once a document was published.  This worked in a perfect world, where these implementers are in perfect lockstep with each other, always updating to the current state of the I-D within moments (maybe days) of its publication, up to the point it becomes an RFC.

But we do not live in a perfect world, and people develop at different rates, and sometimes step away from something for a while and might miss a couple of I-D versions.  I dare say that some here might even deploy software based on an intermediate version, for various reasons we probably don't agree with ideologically.

So, the XSF moved to using one namespace for the I-D like phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC phase (e.g. "urn:xmpp:time").  This helped differentiate between "pre-RFC" versions from "at-RFC" versions, but it was painfully annoying to implementers because they had to go through changes and deployment of those changes simply for a change of a constant.

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.

I don't know how much this applies here; feel free to use all, none, or some level in between.

- m&m

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 14 Nov 2012 16:08:23 -0500

Matt,

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

IIUC, there are a sequence of versions: 1, 2, ..., i, ... j, ... k, ...

and formally adopted ones (initial RFC and RFC'ed revisions) correspond 
to whichever ones happen to have ended up in drafts that become RFCs. So 
maybe in above i,j,k might have been standardized versions while the 
ones in between have no normative status. (E.g. draft-foo-core-99 has 
version i, as does the RFC it becomes. Draft-foo-corebis-00 has version 
i+1, while draft-foo-corebis-19 and the RFC it becomes have version j, etc.)

Is that right?

I would be ok with that approach.

	Thanks,
	Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Nov 2012 14:12:53 -0700

On 11/14/12 2:08 PM, Paul Kyzivat wrote:
>> On Nov 14, 2012, at 1:07 PM, Mary Barnes
>> <[email-masked]> wrote:
>>>> If we were building a mechanism solely for this pre-release
>>>> purpose I would be opposed. I see this as installing a
>>>> mechanism that will work for version 1.0 and future
>>>> standardized extensions/revisions of it. And then it is
>>>> convenient that the same mechanism can be used for this
>>> [MB] I agree that you need a version number. 1.0 for the first 
>>> version of the RFC and then 2.0 if you do a bis.  If someone
>>> wants to put the .10 in there and work with another vendor to
>>> see if their .10 software works with the other guy's, I don't
>>> see that this requires anything to be put into the documents
>>> being produced by this WG. Nor, do I think it requires any 
>>> more discussion.  We don't develops specs to ensure that
>>> prototypes (and various draft versions) are interoperable, we
>>> do prototypes to ensure the final RFCs enable interoperability.
>>> Certainly, the former would be a good thing as that means the
>>> document is headed in the right direction. [/MB]
>> 
>> 
>> The XSF started with namespaces (e.g. 
>> "http://jabber.org/protocol/muc") that did not change once a
>> document was published.  This worked in a perfect world, where
>> these implementers are in perfect lockstep with each other,
>> always updating to the current state of the I-D within moments
>> (maybe days) of its publication, up to the point it becomes an
>> RFC.
>> 
>> But we do not live in a perfect world, and people develop at
>> different rates, and sometimes step away from something for a
>> while and might miss a couple of I-D versions.  I dare say that
>> some here might even deploy software based on an intermediate
>> version, for various reasons we probably don't agree with
>> ideologically.
>> 
>> So, the XSF moved to using one namespace for the I-D like phase
>> (e.g. "urn:xmpp:time:tmp") and a different for the RFC phase
>> (e.g. "urn:xmpp:time").  This helped differentiate between
>> "pre-RFC" versions from "at-RFC" versions, but it was painfully
>> annoying to implementers because they had to go through changes
>> and deployment of those changes simply for a change of a
>> constant.
>> 
>> 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.
> 

We've never gone beyond 3 or 4.

We only rev the version if the protocol changes in
backward-incompatible ways. We don't change it with every new version
of the document. This is protocol versioning, not spec versioning.

> and formally adopted ones (initial RFC and RFC'ed revisions)
> correspond to whichever ones happen to have ended up in drafts that
> become RFCs. So maybe in above i,j,k might have been standardized
> versions while the ones in between have no normative status. (E.g.
> draft-foo-core-99 has version i, as does the RFC it becomes.
> Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19
> and the RFC it becomes have version j, etc.)
> 
> Is that right?

Basically, yes.

Peter

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

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 14 Nov 2012 21:22:21 +0000

On Nov 14, 2012, at 2:08 PM, Paul Kyzivat <[email-masked]> wrote:

> and formally adopted ones (initial RFC and RFC'ed revisions) correspond to whichever ones happen to have ended up in drafts that become RFCs. So maybe in above i,j,k might have been standardized versions while the ones in between have no normative status. (E.g. draft-foo-core-99 has version i, as does the RFC it becomes. Draft-foo-corebis-00 has version i+1, while draft-foo-corebis-19 and the RFC it becomes have version j, etc.)
> 
> Is that right?
> 

That is correct.

- m&m

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 15 Nov 2012 21:45:03 +0530

Thanks to Peter & Matt for sharing XSF XML namespace versioning experience. 

Hi all,

As per the below discussion, the namespace has to be updated for each RFC
(standardized) version and not for each revision of the draft. SIPREC
metadata namespace has to be updated as urn:ietf:params:xml:ns:recording:1
in the next revision of the draft in case "1" is assumed as a starting
number. Please let us know in case anybody has difference of opinion in this
proposal.

Including Hadriel in this mail thread as the original requirement of draft
specific XML version is started by him.

Thanks
Partha

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Peter Saint-Andre
Sent: Thursday, November 15, 2012 2:43 AM
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [siprec] Metadata version indication

Basically, yes.

Peter

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

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 15 Nov 2012 22:43:25 +0530

Including the correct Hadriel e-mail id.

-----Original Message-----
From: Parthasarathi R [mailto:[email-masked]] 
Sent: Thursday, November 15, 2012 9:45 PM
To: 'Peter Saint-Andre'; 'Paul Kyzivat'; [email-masked]'
Cc: [email-masked]'
Subject: RE: [siprec] Metadata version indication

Hi all,

Thanks
Partha

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

Basically, yes.

Peter

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Nov 2012 15:48:24 -0500

<as individual>
I don't think that is right.

I could be misunderstanding something but there is no specific proposal to change what I originally outlined.  There was a discussion of changing the scheme to just increment the version when the protocol changed, ignoring whether that was a draft or RFC.  We could do that, but I think the original proposal works well enough.

There is a clear desire to have some way to indicate versions of drafts, as long as the RFC has a simple (say "version 1.0") version everyone understands.  There doesn't seem to be any downside to changing the version on drafts.  The only discussion on that point was whether it changes on every draft, or every draft that changes the schema.

As long as the draft contains an RFC editor note to set the version to a fixed, agreed value when the RFC is published, we can do anything we want to with the draft versions without causing any harm.

On Nov 15, 2012, at 12:13 PM, Parthasarathi R <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
> Comment: Using GnuPG with Mozilla - http://www.enigmail.net/
> 
> iEYEARECAAYFAlCkCVUACgkQNL8k5A2w/vxh0wCePNWuC2P+OzMxaU9fULD9M6te
> gfMAnijzCSOmh4mtgfC3wFauL34Inbdr
> =Eb3O
> -----END PGP SIGNATURE-----

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 15 Nov 2012 14:06:54 -0700

A simple question (pointer to previous list message is fine): what
problem are we trying to solve here?

On 11/15/12 1:48 PM, Brian Rosen wrote:
> <as individual> I don't think that is right.
> 
> I could be misunderstanding something but there is no specific
> proposal to change what I originally outlined.  There was a
> discussion of changing the scheme to just increment the version when
> the protocol changed, ignoring whether that was a draft or RFC.  We
> could do that, but I think the original proposal works well enough.
> 
> There is a clear desire to have some way to indicate versions of
> drafts, as long as the RFC has a simple (say "version 1.0") version
> everyone understands.  There doesn't seem to be any downside to
> changing the version on drafts.  The only discussion on that point
> was whether it changes on every draft, or every draft that changes
> the schema.
> 
> As long as the draft contains an RFC editor note to set the version
> to a fixed, agreed value when the RFC is published, we can do
> anything we want to with the draft versions without causing any
> harm.
> 
> 
> 
> 
>> -----Original Message----- From: Parthasarathi R
>> [mailto:[email-masked]] Sent: Thursday, November 15,
>> 2012 9:45 PM To: 'Peter Saint-Andre'; 'Paul Kyzivat';
>> [email-masked]' Cc: [email-masked]' Subject: RE:
>> [siprec] Metadata version indication
>> 
>> As per the below discussion, the namespace has to be updated for
>> each RFC (standardized) version and not for each revision of the
>> draft. SIPREC metadata namespace has to be updated as
>> urn:ietf:params:xml:ns:recording:1 in the next revision of the
>> draft in case "1" is assumed as a starting number. Please let us
>> know in case anybody has difference of opinion in this proposal.
>> 
>> Including Hadriel in this mail thread as the original requirement
>> of draft specific XML version is started by him.
>> 
>> Thanks Partha
>> 
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Peter Saint-Andre 
>> Sent: Thursday, November 15, 2012 2:43 AM To: Paul Kyzivat Cc:
>> [email-masked] Subject: Re: [siprec] Metadata version indication
>> 
>>>>>>> If we were building a mechanism solely for this
>>>>>>> pre-release purpose I would be opposed. I see this as
>>>>>>> installing a mechanism that will work for version 1.0 and
>>>>>>> future standardized extensions/revisions of it. And then
>>>>>>> it is convenient that the same mechanism can be used for
>>>>>>> this pre-standard testing as well.
>>>>>>> 
>>>>>> [MB] I agree that you need a version number. 1.0 for the
>>>>>> first version of the RFC and then 2.0 if you do a bis.  If
>>>>>> someone wants to put the .10 in there and work with another
>>>>>> vendor to see if their .10 software works with the other
>>>>>> guy's, I don't see that this requires anything to be put
>>>>>> into the documents being produced by this WG. Nor, do I
>>>>>> think it requires any more discussion.  We don't develops
>>>>>> specs to ensure that prototypes (and various draft
>>>>>> versions) are interoperable, we do prototypes to ensure the
>>>>>> final RFCs enable interoperability. Certainly, the former
>>>>>> would be a good thing as that means the document is headed
>>>>>> in the right direction. [/MB]
>>>>> 
>>>>> 
>>>>> document was published.  This worked in a perfect world,
>>>>> where these implementers are in perfect lockstep with each
>>>>> other, always updating to the current state of the I-D within
>>>>> moments (maybe days) of its publication, up to the point it
>>>>> becomes an RFC.
>>>>> 
>>>>> different rates, and sometimes step away from something for
>>>>> a while and might miss a couple of I-D versions.  I dare say
>>>>> that some here might even deploy software based on an
>>>>> intermediate version, for various reasons we probably don't
>>>>> agree with ideologically.
>>>>> 
>>>>> So, the XSF moved to using one namespace for the I-D like
>>>>> phase (e.g. "urn:xmpp:time:tmp") and a different for the RFC
>>>>> phase (e.g. "urn:xmpp:time").  This helped differentiate
>>>>> between "pre-RFC" versions from "at-RFC" versions, but it was
>>>>> painfully annoying to implementers because they had to go
>>>>> through changes and deployment of those changes simply for a
>>>>> change of a constant.
>>>>> 
>>>>> 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.
>>>> 
> backward-incompatible ways. We don't change it with every new
> version of the document. This is protocol versioning, not spec
> versioning.
> 
>>>> correspond to whichever ones happen to have ended up in drafts
>>>> that become RFCs. So maybe in above i,j,k might have been
>>>> standardized versions while the ones in between have no
>>>> normative status. (E.g. draft-foo-core-99 has version i, as
>>>> does the RFC it becomes. Draft-foo-corebis-00 has version i+1,
>>>> while draft-foo-corebis-19 and the RFC it becomes have version
>>>> j, etc.)
>>>> 
>>>> Is that right?
> 
> Basically, yes.
> 
> Peter
> 
>> _______________________________________________ siprec mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/siprec
>> 
>> _______________________________________________ siprec mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/siprec
> 

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

---

From: Brian Rosen <[email-masked]>
Date: Thu, 15 Nov 2012 16:13:27 -0500

There was a request to have a version number in the schema namespace that changed when versions changed in drafts as well as RFCs, because we are already doing interoperability testing, and we've been stung by different implementations of the drafts not interworking.

That's the problem.

Brian

---

From: Mary Barnes <[email-masked]>
Date: Thu, 15 Nov 2012 17:39:44 -0600

But, this version doesn't do anything to improve the interop situation.
 All that it will tell you is that Vendor A can't interop with Vendor B if
they have each implemented different versions which have different
metadata.   My understanding of what Hadriel said was that this is all he
wants to know - i.e., different versions mean you can't interoperate.
Unless the expectation is that vendors/implementors support multiple
versions, then I don't see how this improves the situation and adds any
more value than Vendor A asking Vendor B what version they have
implemented.

If the issue is that the RFC won't be available in time for people that are
implementing, I still suggest that one version of the draft be selected and
publish that as "this is what's currently implemented", which was the
approach being taken in INSIPID.

Mary.

On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen <[email-masked]> wrote:

> There was a request to have a version number in the schema namespace that
> changed when versions changed in drafts as well as RFCs, because we are
> already doing interoperability testing, and we've been stung by different
> implementations of the drafts not interworking.
>
> That's the problem.
>
> Brian

---

From: "Dave Higton" <[email-masked]>
Date: Fri, 16 Nov 2012 10:43:54 +0000

I think it's a lesson from programming life: when you're exchanging formatted data, always include version information.

It gives the possibility of interworking with more than one version.

If you are unable or unwilling to interwork with more than one version, at least it lets you know if you've been given a version that you can't interwork with, rather than trying and falling over with errors.

Dave

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: 15 November 2012 23:40
To: Brian Rosen
Cc: [email-masked]
Subject: Re: [siprec] Metadata version indication

But, this version doesn't do anything to improve the interop situation.  All that it will tell you is that Vendor A can't interop with Vendor B if they have each implemented different versions which have different metadata.   My understanding of what Hadriel said was that this is all he wants to know - i.e., different versions mean you can't interoperate.   Unless the expectation is that vendors/implementors support multiple versions, then I don't see how this improves the situation and adds any more value than Vendor A asking Vendor B what version they have implemented.

If the issue is that the RFC won't be available in time for people that are implementing, I still suggest that one version of the draft be selected and publish that as "this is what's currently implemented", which was the approach being taken in INSIPID.

Mary.

On Thu, Nov 15, 2012 at 3:13 PM, Brian Rosen <[email-masked]<mailto:[email-masked]>> wrote:
There was a request to have a version number in the schema namespace that changed when versions changed in drafts as well as RFCs, because we are already doing interoperability testing, and we've been stung by different implementations of the drafts not interworking.

That's the problem.

Brian
On Nov 15, 2012, at 4:06 PM, Peter Saint-Andre <[email-masked]<mailto:[email-masked]>> wrote:

>> On Nov 15, 2012, at 12:13 PM, Parthasarathi R
>> <[email-masked]<mailto:[email-masked]>> wrote:
>>
>>> [mailto:[email-masked]<mailto:[email-masked]>] Sent: Thursday, November 15,
>>> [email-masked]<mailto:[email-masked]>' Cc: [email-masked]<mailto:[email-masked]>' Subject: RE:
>>> -----Original Message----- From: [email-masked]<mailto:[email-masked]>
>>> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Peter Saint-Andre
>>> [email-masked]<mailto:[email-masked]> Subject: Re: [siprec] Metadata version indication
>>>
>>>>>> <[email-masked]<mailto:[email-masked]>> wrote:
>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/siprec
>>>
>>> list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/siprec
>>
>
> --
> Peter Saint-Andre
> https://stpeter.im/
>
>

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 16 Nov 2012 11:22:09 +0000

Hi,

The only reason for needing a version number is to aid interoperability and I tend to agree with Mary that creating a version based on draft numbers does nothing to improve interoperability in fact it may make things worse.

However we do need drafts to be implemented and interop testing to take place and it is highly likely that some of these pre-RFC implementations will get deployed and probably already are. When performing such interop testing it would be helpful if the metadata contained the version of the draft that was implemented so why not make that an element in the metadata which is included for information only. At least then developers/testers will be able to quickly see what they are dealing with and it would have no impact on interoperability.

In addition I think we do need a version number which changes only when backwards compatibility is an issue and I like the idea of learning from the experience of the XSF and including a protocol version number (i.e. recording xmlns='urn:ietf:params:xml:ns:recording:1') which does not change just because the RFC is published as again that would seem to harm interoperability for no good reason. I would support getting this in to the next update of the draft.

What we then need is this type of energy to be put in to completing the work and getting to an RFC without too many more versions of the draft which is I think the best solution to the problem.

Regards
Andy (As an individual).

> Behalf Of Mary Barnes
>  All that it will tell you is that Vendor A can't interop with Vendor B
> if they have each implemented different versions which have different
> metadata.   My understanding of what Hadriel said was that this is all
> he wants to know - i.e., different versions mean you can't
> interoperate.   Unless the expectation is that vendors/implementors
> support multiple versions, then I don't see how this improves the
> situation and adds any more value than Vendor A asking Vendor B what
> version they have implemented.
> 
> If the issue is that the RFC won't be available in time for people that
> are implementing, I still suggest that one version of the draft be
> selected and publish that as "this is what's currently implemented",
> which was the approach being taken in INSIPID.
> 
> Mary.
> 
> 
> 
> There was a request to have a version number in the schema namespace
> that changed when versions changed in drafts as well as RFCs, because
> we are already doing interoperability testing, and we've been stung by
> different implementations of the drafts not interworking.
> 
> That's the problem.
> 
> Brian
> >> <[email-masked]> wrote:
> >>

---

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Fri, 16 Nov 2012 16:18:14 +0000

I'm in favor a adding the version number. I think we need it to make the metadata extensible in the future, and adding it now reduces the guesswork required on behalf of the development community implementing pre-RFC versions. We need such efforts in order to validate the model and corresponding schema, so anything we can do to make their life better sounds good to me. An implementation may choose to ignore the version field, or refuse to interwork with anything other than version x, or try to interwork intelligently with version x as well as version x-1. By adding the version number we enable such interworking.

Cheers,
Charles

> Of Hutton, Andrew
> Sent: Friday, November 16, 2012 3:22 AM
> To: Mary Barnes; Brian Rosen
> Cc: [email-masked]
> The only reason for needing a version number is to aid interoperability and I
> tend to agree with Mary that creating a version based on draft numbers
> does nothing to improve interoperability in fact it may make things worse.
> 
> However we do need drafts to be implemented and interop testing to take
> place and it is highly likely that some of these pre-RFC implementations will
> get deployed and probably already are. When performing such interop
> testing it would be helpful if the metadata contained the version of the
> draft that was implemented so why not make that an element in the
> metadata which is included for information only. At least then
> developers/testers will be able to quickly see what they are dealing with
> and it would have no impact on interoperability.
> 
> In addition I think we do need a version number which changes only when
> backwards compatibility is an issue and I like the idea of learning from the
> experience of the XSF and including a protocol version number (i.e.
> recording xmlns='urn:ietf:params:xml:ns:recording:1') which does not
> change just because the RFC is published as again that would seem to harm
> interoperability for no good reason. I would support getting this in to the
> next update of the draft.
> 
> What we then need is this type of energy to be put in to completing the
> work and getting to an RFC without too many more versions of the draft
> which is I think the best solution to the problem.
> 
> Regards
> Andy (As an individual).
> 
> 
> 
>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 16 Nov 2012 10:29:51 -0600

On Fri, Nov 16, 2012 at 10:18 AM, Charles Eckel (eckelcu) <[email-masked]

> I'm in favor a adding the version number. I think we need it to make the
> metadata extensible in the future, and adding it now reduces the guesswork
> required on behalf of the development community implementing pre-RFC
> versions. We need such efforts in order to validate the model and
> corresponding schema, so anything we can do to make their life better
> sounds good to me. An implementation may choose to ignore the version
> field, or refuse to interwork with anything other than version x, or try to
> interwork intelligently with version x as well as version x-1. By adding
> the version number we enable such interworking.
>

[MB] Or you end up with 4 SIPREC implementations at an interop event, each
supporting a different version and thus no one interworks. For implementors
that need to interwork with multiple other implementations due to a
business requirement, I think this just adds chaos.  If we are doing this,
then what's the motivation for ever publishing an RFC?   I think the trying
"to interwork intelligently" with multiple versions will result in some
ugly, error prone code.  Note, that I understand the need and importance of
implementing drafts to increase the probability that the final RFC is
accurate so that there is confidence that interop happens in a timely
manner.  I can also understand Hadriel's point (somewhat) that one would
not interop with a system that wasn't the same version, which I thought was
what motivated the addition of this version number.  I think this document
should clearly state that there should be no expectation of interop if the
version numbers are not the same *unless* the plan is to ensure, for
example, that version 2.0 would be backwards compatible with 1.0, in which
case you need to put in that extensibility now, in which case you could
ensure backwards compatibility with your different draft versions.
[/MB]