Subject: RE: [SIP] Re: My comments on bis-02

From: Eric Tremblay <[email-masked]>
Date: Mon, 11 Dec 2000 15:52:48 -0500

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Saturday, December 09, 2000 17:17
> To: 'Fairlie-Cuninghame, Robert'; Jonathan Rosenberg; Henning G.
> Schulzrinne; Billy Biggs; [email-masked]
> Subject: RE: [SIP] Re: My comments on bis-02
> 
> 
> 
> 
>  
> 
> > -----Original Message-----
> > From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> > Sent: Wednesday, December 06, 2000 12:21 AM
> > To: 'Jonathan Rosenberg'; Henning G. Schulzrinne; Billy Biggs;
> > [email-masked]
> > Subject: RE: [SIP] Re: My comments on bis-02
> > 
> > 
> > > > > 5. Due to the proliferation of the Also header in BYE 
> > > > requests, I would
> > > > >    suggest that it be added to the bis draft, with its meaning
> > > > >    restricted to use with the BYE method.
> > > > 
> > > > Tentatively added.
> > > 
> > > Hold on a sec.... BYE/Also is in a draft that has expired a 
> > > long time ago. I
> > > thought we revisited this and came up with the REFER 
> > > mechanism. Also, AFAIK,
> > > has been discarded, along with its usage in BYE. I don't know what
> > > proliferation you are talking about. 
> > 
> > Jonathan,
> > 
> > It is such a simple yet useful mechanism (that I beleive quite a few
> > implementations support), isn't it reasonable to leave it in 
> > the bis draft
> > even though it does overlap (or is a subset of) the 
> > functionality of the ful
> > blown REFER.
> 
> I think it is confusing and will ultimately lead to interoperability
> problems.
> 
> I am sorry that there are implementations that choose to ship 
> products based
> on -00 drafts that are experimental in nature. The BYE/Also 
> mechanism has
> issues, and we have resolved these in the REFER draft.

I totally agree with Jonathan.  I think the standard should be "technically
driven" (addendum and modifications to the specs for technical reasons)
instead of being driven by the fact that people have already implemented a
draft.  A draft is bound to change, and it can always be dropped.  

Let's see it that way: It is easier to remove code than to add.  Since
people will be supporting the REFER spec anyway sooner or later, then why
add the burden for future developers to support the BYE(Also) service?  If
we leave it in the spec, then it will be used and we will be running head
first into interop problems. This is just a short term patch for those that
don't yet support REFER, and a patch should not make it to a standard.

If this makes it to the specs, then we will have to decide where to draw the
line. Do the SIP WG wants to always have to cope with vendors that have
implemented and sold a draft version of a spec and modify the standard
accordingly?  We are talking about a standard that could (I hope!) have a
very long life, and things can easily get ugly in the long term if we decide
to add something in the draft only because "some implementations already
support it and it once was a draft (that was dropped!)".  I need a much
better reason than this to convince me that this should get into the SIP
standard.

My 5 cents,

EricT

> 
> -Jonathan R.
> ---
> Jonathan D. Rosenberg                       72 Eagle Rock Ave.
> Chief Scientist                             First Floor
> dynamicsoft                                 East Hanover, NJ 07936
> [email-masked]                     FAX:   (973) 952-5050
> http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
> http://www.dynamicsoft.com
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: "Simon Barber" <[email-masked]>
Date: Mon, 11 Dec 2000 19:13:37 -0800

Eric - can I say I agree very much with this view - we should not be tied by
supporting previous drafts - this will end up making a very messy protocol.
We are, of course, bound to support previous versions of the RFC, and we
should ensure that implementations of RFC2543 work with any new RFC, but we
CAN deprecate features from new implementations. BYE has it's problems, and
we must continue to support it for RFC2543 implementations, warts and all -
but we should use a completely new mechanism, if it makes sense technically,
rather than extending the broken BYE for the new RFC.

Simon

----- Original Message -----
From: "Eric Tremblay" <[email-masked]>
To: "'Jonathan Rosenberg'" <[email-masked]>; "'Fairlie-Cuninghame,
Robert'" <[email-masked]>; "Henning G. Schulzrinne"
<[email-masked]>; "Billy Biggs" <[email-masked]>;
<[email-masked]>
Sent: Monday, December 11, 2000 12:52 PM
Subject: RE: [SIP] Re: My comments on bis-02