Re: [Sip] Info Package Versioning

[Eric Burger]

I'm leaning toward "inside the INFO packet", or, ad hoc. My reasoning is if Y is X with a little more, if you advertise Y, would X understand it? X would probably say, "hmmm - version greater than me, so I should reject it." That doesn't help.

On Oct 31, 2008, at 8:59 AM, Christer Holmberg wrote:

On the other hand, if you are on the XML bandwagon, you could always have backwards compatible stuff in your schema.

Hi,

Before I give my vote, I just want to clarify a little what I meant.

Assume you have package A, which can carry some information.


information still remains exactly the same. You create package B.

Now, package B would be fully backward compatible with package A.


have to indicate explicit support of both package A and B.


compeltely new package.


info packet itself.

Regards,

Christer

Then you figure out you need a new information element, but all the old But, if there is no versioning, and backward compability guidelines, I would Of course, if package B is NOT backward compatible, it would have to be a Another option is of course to deal with these kind of things inside the

-----Original Message-----
From: Eric Burger [mailto:[EMAIL PROTECTED]
Sent: 30. lokakuuta 2008 18:53
To: Christer Holmberg
Cc: SIP IETF
Subject: Info Package Versioning

Channeling Keith here: is there a real use case for package
versioning?

I cannot imagine backwards-compatible packages. Once one
starts changing the stuff in an INFO package, it is a
different package. That is, rather than

   Info-Package: foo-package;version=1
   Info-Package: foo-package;version=2

You, in reality have:

   Info-Package: foo-package
   Info-Package: something-like-foo-but-not-really-foo-anymore

This is more especially so when one considers there is no
possibility of negotiating package versions, whereas there is
a possibility of negotiating different packages.

For the one instance one could come up with in theory for
needing versioning, remember one does get to have an
arbitrary parameter:

   Info-Package: foo-package               /* Version 1 */
   Info-Package: foo-package;bar        /* Version 2 */


Is this latter mechanism sufficient?

Yet another poll:

[ ] We must have abstract versioning as part of the Info
Framework document

[ ] We do not need to have abstract versioning, as it does
not do anything for anyone

[ ] We do not need abstract versioning, but it would be
worthwhile including some text,
    like what is above, to show people how to do it.

[ ] Something else? _____________________________________



On Oct 27, 2008, at 4:48 PM, Christer Holmberg wrote:

[snip]

The wording could be better. There are no explicit IANA
considerations

about registering an INFO package. Its just implied here.

Its a little

confusing here what is intended to be part of the

*definition* of a new package vs. what is intended to be in the
content

of a particular package instance in an INFO message.

We do need to have a section on what needs to be part of an info
package definition. The mime type is one thing, for sure.

I guess we should also look at what/if we can re-use from

SIP events.

We also need to decide whether info packages should have a version
number system. From experience I think that would be very useful.

Info-Package: foo-package;version=1

...or something like that.

[snip]

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip