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

From: Igor Slepchin <[email-masked]>
Date: Fri, 1 Dec 2000 15:31:46 -0500

> > > 2. In 4.2.5, it is noted that CANCEL requests cannot have Route
> > >    headers.  Why not?  Are you assuming that CANCEL is only useful
> > >    for an initial request?  This breaks since we need to 
> be able to
> > >    CANCEL a pending REFER or other extension method which doesn't
> > >    complete quickly, for example.
> > 
> > Removed.
> 
>   I think I was wrong on this one.  CANCEL is of hop-by-hop 
> significance
> within a transaction and doesn't use the Route.  Stateful proxies
> instead remember and the UA sends the CANCEL just to the 
> first entry in
> the Route.

A proxy might be stateless and still record-route. Route actually does make
sense in a CANCEL in this scenario.

---
Igor Slepchin

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

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Sun, 03 Dec 2000 16:36:19 -0500

Billy Biggs wrote:

>   The text currently is:
> 
>   "If no protocol is specified, the client tries UDP (if UDP is
>    supported).  If the attempt fails, or the client doesn't support UDP
>    but supports other protocols, it tries those protocols in some
>    unspecified order."
> 
>   This implies that clients do not need to support UDP.  I thought UDP
> was a requirement, but it looks like it's only a SHOULD for clients.
> MUST is only used in the section on a minimal implementation.

Removed qualifier.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 5 Dec 2000 13:11:52 -0500

> -----Original Message-----
> From: Henning G. Schulzrinne [mailto:[email-masked]]
> Sent: Friday, November 24, 2000 4:42 PM
> To: Billy Biggs; [email-masked]
> Subject: [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 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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Tue, 5 Dec 2000 21:20:37 -0800

> 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 know you want to keep SIP trimmed to the bare essentials but I think this
is a high gain verse low complexity addition. [Whereeas AFAIK doesn't fit
this criteria in my mind - it deserves the full REFER implementation.]

Robert.

---

From: Tan Ya-Ching <[email-masked]>
Date: Wed, 6 Dec 2000 16:38:48 +0100

If you add the Also header to the bis draft, you would also have to add the Requested-By header for the INVITE as a result of the BYE with Also. The REFER draft has introduced the Referred-By header for the same purpose. So should it be the Requested-By (as in the expired draft-ietf-mmusic-sip-cc-01), or the Referred-By header ?

Ya-Ching

> From:	Fairlie-Cuninghame, Robert [SMTP:[email-masked]]
> Sent:	Wednesday, December 06, 2000 6:21 AM
> To:	'Jonathan Rosenberg'; Henning G. Schulzrinne; Billy Biggs; [email-masked]
> Subject:	RE: [SIP] Re: My comments on bis-02
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 9 Dec 2000 17:16:43 -0500

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Wednesday, December 06, 2000 12:21 AM

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.

-Jonathan R.
---

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Mon, 11 Dec 2000 17:30:42 -0800

> > issues, and we have resolved these in the REFER draft.

Hi Jonathan, 
 
I think this statement is being a little harsh. Companies wanting to be a
step ahead of the curve will obviously want to add things above and beyond
what is set in concrete in the core SIP spec (which is still a moving target
in terms of compliance). I dont think there is anything wrong with this -
__in the commercial world__ you can't begrudge companies for wanting to
release products with differentiated feature sets. I don't see any
difference between a company coming up with propretary additions and
implementing standards still in a draft stage as long as they don't affect
core SIP compatibility. The BYE/Also is a good example. If the BYE/Also is
not adopted by IETF then UA's who have implemented this will not suddenly be
incompatible or cause problems with or UA/proxies not supporting this. So a
year ago, if a company needed to add blind transfer capability, why
shouldn't they have implemented the BYE/Also draft rather than  coming up
with a proprietary scheme BYE/MyAlso ? [I am just asking a question and
_not_ advocating that BYE/Also should be added to the draft (which I agree
should not be driven only by the realities of commerical world).] 

I understand that it is undesirable from a techical standpoint that
companies add "extra bits" but in real world, being "sorry that there are
implementations that choose to ship products based on -00 drafts that are
experimental in nature" is an unrealistic expectation.

[Feel free not to reply to this email as it is now more a philosphical than
technical argument.]

Please note, I am not (and was not) infering or refering to any capabilties
about any product produced by the company owning the domain of my email
address. It would be a mistake to assume so.

Regards,

Robert.

-- My opinions are my own. I tried selling them once but everybody
	seems to already have one. -- 
> 
> 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.
> > ---