Thanks for the pointers John. Helps in correcting my understanding of sip-version.
You said: > This raises the question of whether any of the changes in > rfc3261added to > the message semantics and imply additional capabilities. I'm > not clear if > this is the case. Yap. -Satya > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Thursday, September 05, 2002 12:33 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: RE: [Sip-implementors] sip version > > > It might be worth reading the below and RFC 2145. Apparently > there were > many interop problems when HTTP introduced and incremented the version > numbers. Perhaps the authors of SIP wished to avoid that > mess and do thier > best to make it backwards compatible without incrementing the version. > > rfc3261 states: > > SIP-Version: Both request and response messages include the > version of SIP in use, and follow [H3.1] (with > HTTP replaced > by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version > ordering, compliance requirements, and upgrading of version > numbers. To be compliant with this specification, > applications sending SIP messages MUST include a > SIP-Version > of "SIP/2.0". The SIP-Version string is case-insensitive, > but implementations MUST send upper-case. > > referring to section 3.1 of RFC 2616 which states: > > 3.1 HTTP Version > > HTTP uses a "<major>.<minor>" numbering scheme to indicate versions > of the protocol. The protocol versioning policy is > intended to allow > the sender to indicate the format of a message and its capacity for > understanding further HTTP communication, rather than the features > obtained via that communication. No change is made to the version > number for the addition of message components which do not affect > communication behavior or which only add to extensible > field values. > The <minor> number is incremented when the changes made to the > protocol add features which do not change the general > message parsing > algorithm, but which may add to the message semantics and imply > additional capabilities of the sender. The <major> number is > incremented when the format of a message within the protocol is > changed. See RFC 2145 [36] for a fuller explanation. > > This raises the question of whether any of the changes in > rfc3261added to > the message semantics and imply additional capabilities. I'm > not clear if > this is the case. > > John Hearty > Level3 > > > > -----Original Message----- > > From: Yadavalli, Satyamurthy [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, September 05, 2002 9:49 AM > > To: 'M. Ranganathan' > > Cc: [EMAIL PROTECTED] > > Subject: RE: [Sip-implementors] sip version > > > > > > Ranga, > > > > As I said, version numbers usually are used with a convention > > that a higher > > version MAY be compatible with a lower version. So a lower > > version system > > usually checks that its counterpart system's version is > > greater than or > > equal to its own version. If the counter part is a lesser > version than > > itself then it (the lower version system) may not permit > > interoperation but > > if the counterpart is greater version typically systems would allow > > interoperation as many standards strive for backward > > compatibility (as did > > the latest SIP). > > > > It would have been irrational for older system implementors > > to expect that > > SIP would forever be version 2.0 without evolving. > > > > Well, unless the RFC2543 had specified that compliant systems should > > interoperate with higher versions of SIP there is a > > possibility that older > > system implementors, unfortunately, had a hard check on the > > version number > > to be equal. > > > > If a next version of SIP would evolve instead of the > > branch-id mechanism > > something else may have to be invented to distinguish it, I > am afraid. > > > > -Satya > > > > > -----Original Message----- > > > From: M. Ranganathan [mailto:[EMAIL PROTECTED]] > > > Sent: Thursday, September 05, 2002 7:29 AM > > > To: Yadavalli, Satyamurthy > > > Cc: [EMAIL PROTECTED] > > > Subject: RE: [Sip-implementors] sip version > > > > > > > > > > > > Hi Satya: > > > > > > The choice of keeping the version number can be easily > > > explained if one > > > considers backward compatibility. Think of interoperability > > between a > > > 3261 componenet (UA/PROXY etc.) and an old 2543-compliant > > > component. If > > > you use a new version number in the 3261 component the 2543 > > > component will > > > fail. The magic cookie trick is in effect a version number as > > > you have noted > > > but it allows for backwards compatibility. > > > > > > Ranga. > > > > > > On Wed, 4 Sep 2002, Yadavalli, Satyamurthy wrote: > > > > > > > Kirill, > > > > I did read this section which explicitly talks about branch ID: > > > > "..so that servers receiving the request can determine that > > > the branch ID > > > > was constructed in the fashion described by this > > > > specification.." > > > > > > > > Ofcourse, this may be used as (an indirect) means to > > > distinguish between the > > > > two versions. > > > > > > > > Sounds strange though that the SIP/Version was not used for > > > a SIP entity to > > > > explicitly say that it is RFC3261 compliant...probably > > > there were some > > > > reasons for doing so (like many old entities doing strict > > > check for 2.0 > > > > instead of greater than or equal to 2.0)...may have been > > > discussed on the > > > > mailing lists much earlier. > > > > > > > > Thanks, > > > > Satya > > > > > > -- > > > M. Ranganathan > > > Advanced Networking Technologies Divsion > > > National Institute of Standards and Technology (NIST) > > > 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. > > > Tel: 301 975 3664 ; Fax: 301 590 0932 > > > > > > Advanced Networking Technologies For the People! > > > > > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
