Subject: RE: [Sip] Refer status/adjustment

From: Adam Roach <[email-masked]>
Date: Tue, 25 Jun 2002 11:45:29 -0400

> -----Original Message-----
> From: Daniel G. Petrie [mailto:[email-masked]]
> 
> My major concern relates
> to the existing installed base implemented on prior drafts
> of REFER.  There is a significant installed base of
> products and services that depend upon prior versions
> of the REFER draft.  There are some upward compatability
> issues in the changes proposed in this draft.

I understand what you're saying -- call transfer functionality
fills a real need, and has been under construction for some time
now. However, I fear that imposing backwards-compatibility
requirements based on internet-drafts is a dangerous precedent
that we need to avoid with all possible vigor. 

Historically, we've been pretty good about doing this; in
particular, you'll notice a lack of provisions in the current
draft for the TRANSFER verb, using the REFER response to convey
the INVITE status, or for using the "Also" header in BYE messages.
All of these omissions break backwards compatibilty with earlier
work-in-progress.

I think this situation points to the need for field-upgradable
equipment as a risk management strategy, especially when
implementing towards works-in-progress. Luckily, I beleive you
had the foresight to address this. :)

/a

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Daniel G. Petrie" <[email-masked]>
Date: Tue, 25 Jun 2002 13:12:39 -0400

I agree that you generally should not look at drafts as
having installed base.  However this is not a precedent.
Strict routing was never completely defined in RFC2543.
It was clarified and defined in drafts.  Yet a choice was
made to make strict routing upward compatible in RFC3261.

The previous changes to transfer (that you listed) were
very significant and were not compatible.   However the
implementations were few and mostly only deployed in
labs.  The latest draft of REFER has been around for quite a while
with few compatibility changes.  There is a very significant installed
base that implements it.  This presents a difficult challenge for
service providers and enterprises that have multi-vendor solutions.
They cannot move forward until all the vendors do.  I will
ignore the dependency nightmare that occurs if you look at
the cross enterprise and service provider interoperability problem.

As a bit of a side note: I as a vendor have had to support BYE Also
until very recently.  There were some compatibility tricks for the
transfer changes (e.g. method name support is easy to query using
OPTIONS).  SIP, the protocol supported the the various changes in
the way transfer was implemented.  Even if it had not it was less of an
impact when those changes were made due to the side of the
installed base.

Sorry I did not mean to go on.  I guess my main point is do not
underestimate the power of the market to sanction a draft into
a standard.