Subject: [Sip] I-D ACTION:draft-willis-sip-cookies-00.txt

From: [email-masked]
Date: Thu, 12 Jul 2001 07:06:08 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIP Cookies
	Author(s)	: D. Willis, B. Rosen
	Filename	: draft-willis-sip-cookies-00.txt
	Pages		: 9
	Date		: 11-Jul-01
	
This document describes an extension to SIP (RFC 2543) to provide a 
mechanism for storing state and other information in SIP comparable 
to the HTTP state mechanisms defined in RFC 2109.  This extension 
includes a new SIP header ('Cookie:'), an option tag for feature 
negotiation ('cookie') and IANA registration considerations for 
registering the 'cookie' extension, semantics of the value of the 
Cookie: header, and behavioral rules for processing these headers by 
SIP nodes supporting the 'cookie' extension. This document also 
briefly discusses possible uses of cookies, and security 
considerations for their use.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-willis-sip-cookies-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-willis-sip-cookies-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-willis-sip-cookies-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 16 Jul 2001 10:54:56 +0100

Quick Question.

Why are "non-participatory" Redirect Servers required to
copy the Cookie header into responses?  Am I being really
dull here?

Thanks,

 - Jo.

_______________________________________________
Sip mailing list  http://www.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: Michael Thomas <[email-masked]>
Date: Wed, 18 Jul 2001 03:41:39 -0700 (PDT)

OK, I'll bite. How does this differ from the state
draft?  I've scanned it over and it looks to be
doing about the same thing. What am I missing?

	    Mike

[email-masked] writes:
 > Content-Type: text/plain
 > Content-ID:	<[email-masked]>
 > 
 > ENCODING mime
 > FILE /internet-drafts/draft-willis-sip-cookies-00.txt
 > Content-Type: text/plain
 > Content-ID:	<[email-masked]>

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 19 Jul 2001 08:24:09 -0500

Cookies persist across redirection because the logical association of a
"call" (from a human rather than SIP point of view) persists across
redirection.

A participatory server understands the content of the cookie and may change
it. For example, if one were to implement a call history function (like
cc-redirect) using cookies, a redirect sever could either insert a new
history cookie or update the existing history cookie to explains that a
redirection has occurred, possibly with a reason why that redirection
occurred. Or it might be configured for maximum privacy, and therefore rip
out any cookies that might compromise privacy.

Non-participatory servers don't understand the content of a cookie,
therefore they do not know enough to make a decision on a cookie. They just
blindly propagate the cookies that are there. For example, let's say a call
is redirected twice -- once by a redirector that understands the history
cookie as described above, and once by a redirector that doesn't. The first
redirectory introduces a history cookie. We want that cookie to survive the
second redirection.

In a nutshell, this level of persistency is one thing that differentiates a
"cookie" from a "state header", others being a slightly more expressive
syntac and IANA maechanisms for definining "standard" cookies.

One might ask why a nonparticipatory  redirector returns cookies when UASes
are required to store cookies and resubmit them. It's because of a case that
I'm not sure is handled clearly in the current draft. How does a
participatory server indicate that a particular cookie should be deleted?
Remember that the  UAS doesn't know whether a particular server is
participatory or not on a given cookie. So one approach would be a for a UAS
to discard cookies for a particular call when those cookies aren't present
in a 302 response to that call. I'm not entirely happy with this approach,
and the floor is open for suggestions.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 19 Jul 2001 17:40:37 -0500

Differences:

1) Much more like HTTP cookies, including most of the syntax. I believe an
HTTP cookie parser could accept the syntax described in the SIP cookie
draft. State headers are quite different.
2) More persistence of the cookie information -- for example, applied to new
calls resulting from redirect or transfer of old one.
3) No IPR restrictions, unlike State (see Ch. 9 of state draft).
4) Clear syntax to identify the source of the cookie.
5) No Supported-header specified. This may or may not be a bonus.
6) The Cookie is not correlated with to/from/callID tags in quite the same
way.
7) Obvious extensibility to define "standard" cookies.

--
Dean

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 19 Jul 2001 17:40:38 -0500

Differences:

--
Dean

---

From: "Jo Hornsby" <[email-masked]>
Date: Mon, 30 Jul 2001 17:28:07 +0100

> One might ask why a nonparticipatory redirector returns cookies 
> when UASes are required to store cookies and resubmit them.

I'm getting confused.  Should this read "UACs"?

> It's because of a case that
> participatory or not on a given cookie. So one approach would be 
> a for a UAS to discard cookies for a particular call when those
> cookies aren't present in a 302 response to that call. I'm not
> entirely happy with this approach, and the floor is open for
> suggestions.

The problem that leaps out at me here is that a Redirect Server
that knows nothing of this extension will not return the cookie,
which would be interpreted as a deletion with this logic.  This
doesn't seem desirable.  Also, the draft seems to indicate that
this behaviour be extended to classes other than 3xx.  The
moment we break out of 3xx, it seems to me that deciding whether
a SIP Server is a Redirect Server or not becomes a little
less clear.

How about looking at the response to see if it has a Cookie
header in?  If it doesn't, then the Redirect Server either
doesn't understand the extension or doesn't care.  If it does
have a header, then this could be taken as the updated list
of Cookies to use.  This would require a slight change to the
grammar to allow no Cookies (so that all could be deleted),
but that doesn't seem too offensive.

Cheers,

 - Jo.