Subject: RE: [Sip] Comment on refer-with-norefersub-01

From: "Orit Levin" <[email-masked]>
Date: Fri, 10 Jun 2005 12:29:54 -0700

Why we are reopening this never ending discussion again?
Below is the precise recap of the achieved "compromise" that worked for
everyone back in the last IETF:

----------------------------------------------------------------------
Topic: REFER Extensions 
by Orit Levin 
see draft-ietf-sip-refer-with-norefersub-01.txt 
Slides were presented that should be included in proceedings. 

Only one open issue remained for the draft since its WGLC. This was 
"How does a REFER-Issuer enable the feature?". Alternatives include: 
a) Commonly preceded by OPTIONS, b) supported header in the request, 
c) required header in the response, d) require header in the request. 

Discussion agreed that the Supported header is the wrong approach, as 
it indicates which features are supported by the sender, not required 
for the respondent. 

Discussion became prolonged, and the participants were moved to the 
hallway for a focused discussion. This discussion reached the 
following conclusion: 

  1) Add a new header to be used with REFER request and the 
      corresponding response
  2) Keep option tag 
  3) Including this option tag in Require header is NOT RECOMMENDED. 

This conclusion was shared with the WG, and no objections were noted. 
------------------------------------------------------------------------

Does anyone think that we need to rehash it again? If we are in
agreement, I will revise the draft accordingly and re-submit it ASAP.
Otherwise, lets continue the discussion...

Thanks,
Orit.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: Friday, June 10, 2005 11:25 AM
> To: Dean Willis; [email-masked]
> Cc: Alan Johnston; Tom Hiller
> Subject: Re: [Sip] Comment on refer-with-norefersub-01
> 
> 
> It seems like a very common case people want to use this is 
> for click to dial and in that case, there is no previous signaling.
> 
> So far, to my knowledge, no one has provided an argument of 
> how the require helps in any case. It will reduce 
> interoperability between clients that do and do not support 
> this. Unless someone has an argument why the require is 
> needed, I think we should drop it.
> 
> (And if using the require on call flows with correctly 
> behaving OMA endpoints somehow reduced the bandwidth, I'd 
> view that as a reason but so far no one has provided an 
> example of this)
> 
> Cullen
> 
> 
> On 6/10/05 11:55 AM, "Dean Willis" <[email-masked]> wrote:
> 
> > 
> > On Mar 7, 2005, at 4:23 PM, Johnston, Alan wrote:
> > 
> >> In most cases (at least for common ones such as transfer 
> and remote 
> >> call control), the UA issuing the REFER has had some kind of SIP 
> >> message exchange with the REFER recipient.  As a result, 
> the UA will 
> >> know based on a previously received Supported header whether the 
> >> recipient supports the extension before it sends the REFER with 
> >> Require.
> >> 
> >> True, this doesn't cover all cases, but these cases seem like the 
> >> most common ones that would want to use this feature.  In other 
> >> words, the main reason for suppressing the subscription is 
> that the 
> >> UA has another method of finding out the result of the 
> REFER, and the 
> >> number of messages is trying to be minimized.
> >> 
> > 
> > 
> > Ok, so are we concluding that the text is okay as written, 
> or does it 
> > need the change Cullen suggested?
> > 
> > C'mon folks, OMA wants to use this draft. We need to close 
> it up, one 
> > way or another.
> > 
> > --
> > Dean
> 
> _______________________________________________
> 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
> 

_______________________________________________
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: Cullen Jennings <[email-masked]>
Date: Fri, 10 Jun 2005 19:40:59 -0500

I'm in 100% agreement with Orit - sounds good to me.

Cullen

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 10 Jun 2005 22:56:29 -0400

This conclusion also (still) sounds fine to me.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Dean Willis <[email-masked]>
Date: Sun, 12 Jun 2005 15:01:45 -0500

> everyone back in the last IETF:

My fault. My brain slipped and I completely forgot about the conclusion 
at the last IETF meeting.

We have a conclusion.

Orit is going to write it up.

When it is written up, we are going to poll the list, and if we still 
have a consensus, send it to the IESG for review.

--
Dean