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

Reply via email to