[Sip] Info Package Versioning

[Eric Burger]

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



   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





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


Is this latter mechanism sufficient?

Yet another poll:






    like what is above, to show people how to do it.

[ ] Something else? _____________________________________



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

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 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: [ ] 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,

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


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.

We do need to have a section on what needs to be part of an info package

[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