Subject: RE: [Sip-implementors] Re: [SIP] Draft about diversion out of dat e

From: Matt Holdrege <[email-masked]>
Date: Thu, 17 May 2001 10:33:32 -0700

Comment below...

At 11:10 PM 5/16/2001, Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Matt Holdrege [mailto:[email-masked]]
> > Sent: Tuesday, May 15, 2001 6:30 PM
> > To: Jonathan Rosenberg
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [Sip-implementors] Re: [SIP] Draft about diversion out of
> > date
> >
> >
> > At 12:19 AM 5/15/2001, Jonathan Rosenberg wrote:
> > >Now, this problem is fixable. As Allison has mentioned
> > during IETF 50, all
> > >extensions henceforth MUST describe how backwards
> > compatibility operates.
> > >Therefore, the draft MUST describe how gateways, voicemail
> > servers, and
> > >anything else that looks at Diversion, would work in its absence.
> >
> > Jonathan, you mentioned that this was not standards track.
> > Why must we
> > describe backwards compatibility with any old
> > draft-yournamehere-sip-xxx.txt document?
>
>An informational document that simply describes one vendors approach does
>not need to worry about compliance with anything, since its just
>informational.
>
>However, this draft is aimed at becoming a standards track extension, and
>thus needs to worry about backwards compatibility.

The point is that we cannot know which individual draft will become 
standards track until it actually becomes standards track. The same goes 
for official draft-ietf-sip documents. There is a long history in the IETF 
of documents that are aimed at becoming standards track only to be rejected 
or significantly changed before they make standards track or even become an 
official WG document. Again, if someone chooses to  implement an individual 
draft, you cannot expect everyone else to have backwards compatibility with 
it, no matter what the intention is.

Also there seems to be a fair bit of controversy about this draft so I'm 
not sure you can even make a special exemption in this case. But my concern 
is more general. Dealing with the progress of the bis draft is hard enough. 
Let's not burden SIP implementations with "legacy" items that weren't 
really standards track at the time.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: [email-masked]
Date: Thu, 17 May 2001 13:31:27 -0500

> From: Matt Holdrege [mailto:[email-masked]]
...
> it, no matter what the intention is.

I'll give it a try.

Any internet-draft must address backwards compatibility with
*published*, *standards track* *RFCs* before it is passed to the
IESG for publication.

That's it. No one needs to worry about backwards compatibility
towards drafts of any kind. Technically, that means that, yes, we
could attempt to publish draft as an RFC now which doesn't address
any issues arising from backwards compatibility with the rfc2543-bis
draft. It would be stupid for us to do so (and we'd never be able
to fit it in on the calandar), but there are no procedural issues
with our doing so.

So, addressing the specific situation under discussion: no one ever
needs to address backwards compatibility issues with the diversion
draft unless (and even then, until) it is published as a standards
track RFC.

/a