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. Then you figure out you need a new information element, but all the old information still remains exactly the same. You create package B. Now, package B would be fully backward compatible with package A. But, if there is no versioning, and backward compability guidelines, I would have to indicate explicit support of both package A and B. Of course, if package B is NOT backward compatible, it would have to be a compeltely new package. Another option is of course to deal with these kind of things inside the info packet itself. Regards, Christer > -----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
