Re: Info Package Versioning

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 the other hand, if you are on the XML bandwagon, you could always  
have backwards compatible stuff in your schema.


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

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

_______________________________________________
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