[Sip] SIP-cookies

[[e-mail]]

Comments on draft-willis-sip-cookies-00:

This draft provides a good base-line for definition of a SIP-cookie 
functionality, derived from RFC 2109.

Some comments/observations:

1. The proposed SIP-cookie borrows heavily from the definition/procedures of 
cookies for HTTP (RFC 2109). Given the known possibility of abuse of cookies 
in HTTP, it is very important that the avoidance of such abuse be considered 
for SIP.

2. Currently, if one disables all cookies in their browser, certain web-based 
applications such as on-line shopping are not usable, but this does not 
affect access to most web-browsing. If the support of SIP cookies is 
essential to the provision of regular telephone type service (e.g., Call 
Transfer), a user would not be able to disable cookies, thereby exposing 
themselves to possible abuse. The draft is written as if a User Agent is 
required to store cookies, that is, can not disable them as a web-browser can 
today.

3. Section 8, Security Considerations states: "Cookies in SIP, unlike cookies 
in HTTP, are discarded at the conclusion of a session." It is not clear why 
this is stated, since RFC 2109 allows the User Agent to discard cookies. It 
states that "When a user agent terminates execution, it should let the user 
discard all state information." It seems that the common browsers do not 
choose to provide the user with this option to discard cookies upon exit, 
probably since the companies that produce them want to use these persistent 
cookies as much as any other companies. If these same companies implement SIP 
functionality, it can be expected that they will choose to not discard 
SIP-cookies at the conclusion of a telephone call either.

4. As I understand the draft, it requires a user agent to store cookies, and 
seems to make a strong objective that it must store at least 10 cookies of at 
least 4096 bytes each, and that it must include all stored cookies in every 
subsequent message it sends associated with a call. Since other draft 
proposals result in sending a very large number of messages for some 
capabilities, especially those associated with providing security, it would 
appear that this results in huge amounts of data being sent. It is obvious 
this can not lead to an efficient telephone service.

5. One could easily envision services that would benefit from retaining 
SIP-cookies after completion of a call in order to support a new call.

6. This draft appears to be one more admission that processing of many (maybe 
all) telephone type applications requires that the entity controlling the 
service have knowledge of the "state" of the call. In an increasing number of 
defined applications, it is a proxy that controls the service (not the user 
agent as perhaps originally envisioned) and that proxy needs to "remember" 
the state of the call and service. RFC 2543 included the concept of a 
"stateful proxy", which maintains the state of a transaction (until a 
definitive response is received). The proposed revision of SIP further 
refines this definition of "stateful proxy" and then introduces the notion of 
a "call stateful (proxy)" which maintains the state "from the initiating 
INVITE to the terminating BYE", but it does not describe in detail the 
operation of a "call stateful proxy".

For the control of telephone services using SIP beyond the simple, basic 
call, it appears that the time has come to admit that these services require 
a "call stateful proxy" and not to depend on storing of "cookies" in user 
agents as a substitute.

7. For some yet to be defined SIP-provided services, this cookie mechanism 
will probably be essential. In line with the recent draft for "SIP Change 
Process", draft-tsvarea-sipchange-00.txt, a definition of the requirements 
needs to be submitted to SIPPING. This would identify the specific class of 
services/capabilities that require the addition of a SIP-cookie. It should be 
intended for special cases (equivalent to the shopping cart example in RFC 
2109), not support for everyday telephone services.

Mike Pierce
Artel



_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip