Subject: [Sip] Last Call comments on draft-ietf-sip-refer-02

From: William Marshall <[email-masked]>
Date: Fri, 4 Jan 2002 17:13:44 -0500 (EST)

When I did my review of draft-ietf-sip-refer-02 prior to the
last call period, I missed the example that included "method="
as a URL parameter in the Refer-to header.  With this URL
parameter there are a few additional comments I wish to make.

First, it is necessary to register the header name "Method:",
since it would otherwise be ambiguous whether a URL parameter on
Refer-To is giving a value for the method in the Request-URI,
or the value for a header to be included in the request.

Secondly, and more importantly, some additional text is needed
to describe the formation of a request using the method parameter.
	(1) If the method is only vaid within an existing dialog,
then certain header fields (e.g. CSeq) need to be provided by
the UA that accepted the REFER request, with values determined
by the current state of the existing dialog.  
	(2) Security considerations need to discuss whether 
other dialog-dependent headers (e.g. From, To, Call-ID) need 
to be specified in the Refer-To or can be supplied by the UA.
	(3) The final sentence of section 3.5.1 implies that
a REFER with a sip: URL always sends INVITE - this needs to
be fixed.
	(4) Some default action needs to be specified for
cases where the UA does not understand the method value;
is this handled the same as not understanding the URL scheme?

I presume that the recommended policy for methods within existing
dialogs will prevent the obvious busy-signal-fix of sending
the destination REFER;method=BYE without any knowledge of the
active dialog identification.

Bill Marshall
[email-masked]

_______________________________________________
Sip mailing list  http://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: Robert Sparks <[email-masked]>
Date: Fri, 4 Jan 2002 17:46:30 -0500

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Friday, January 04, 2002 4:14 PM
> To: [email-masked]
> Subject: [Sip] Last Call comments on draft-ietf-sip-refer-02
> 
> 

I don't see this ambiguity, and I apologize for not understanding
the question earlier.

It is clearly a URL parameter specifying the method to be used, just
as if the URL had appeared on a web page. For it to be a header
to be included in the request, it would have to be represented as
a URL header parameter - after a question mark, such as:
  sip:foo@bar?method=INVITE

Am I still missing your point?

> to describe the formation of a request using the method parameter.

This text is actually needed for the more general case of how to
form a request from a URL (how do I form a request after clicking
on a URL on a web page, or accepting a URL with the values you mention
that has been manually entered into my phone?).

I've already added a section on forming requests from a URI
to the description of the SIP URI in the bis draft dealing 
with exactly these issues (1,2 and 4 anyhow). 

I will fix 3) in the REFER draft.

> active dialog identification.

Without the active dialog identification, even if the REFERed
party accepts the REFER and issues a BYE, its going to get
481ed.

---

From: William Marshall <[email-masked]>
Date: Fri, 4 Jan 2002 17:58:59 -0500 (EST)

Regarding the ambiguity between headers and method parameter,
I missed the distinction between "?" and ";" following the destination
URL.  So this isn't a problem with "method".  The original comment 
remains, though, about to-tag and from-tag being ambiguous between 
headers of that name and tags on a To/From header.

> party accepts the REFER and issues a BYE, its going to get

Unless the UA default action is to insert From/To/Call-ID from the 
active dialog, like it needs to do for the CSeq header.  Hopefully
no implementation would do that.

Bill Marshall
[email-masked]