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
