Re: [http-state] Whether to recommend the cookie protocol (was Re: I-D Action:draft-ietf-httpstate-cookie-04.txt)

[Peter Saint-Andre <[e-mail]>]

On 2/23/10 9:11 PM, Adam Barth wrote:
> On Tue, Feb 23, 2010 at 8:04 PM, Peter Saint-Andre <[e-mail]> wrote:
>> On 2/23/10 7:55 PM, Adam Barth wrote:
>>> On Tue, Feb 23, 2010 at 9:10 AM, Anne van Kesteren <[e-mail]> wrote:
>>>> On Tue, 23 Feb 2010 17:15:04 +0100, <[e-mail]> wrote:
>>>>> The cookie protocol has many
>>>>> historical infelicities and should be avoided for new applications of
>>>>> HTTP.
>>>>
>>>> What exactly does this mean?
>>>
>>> It means that we don't think new applications of HTTP (e.g., SIP)
>>> should use the cookie protocol.  Cookies have caused significant
>>> security problems for the web.  For new applications, it's probably a
>>> good idea to use another state management mechanism.
>>
>> Could you explain the sense in which SIP is an application of HTTP?
> 
> Oh, I could be using the wrong terminology here.  How would you
> describe the relation between SIP and HTTP?

As far as I can see, there is none, which is why I'm confused. SIP is a
non-web, non-HTTP technology. The same is true of XMPP. Now, some
non-web, non-HTTP technologies have bindings to HTTP, often achieved
using long polling (this is true of XMPP, whose "BOSH" technology is
used to emulate TCP connections via long polling over HTTP). In that
case the HTTP binding might use cookies but typically does not. But
natively a technology like SIP or XMPP is utterly distinct from HTTP.

>> I'm
>> trying to understand which of the following best captures what you are
>> saying:
>>
>> 1. Non-web technologies SHOULD NOT use cookies but instead SHOULD define
>> their own application-specific methods for state management.
>>
>> 2. Non-web technologies that define bindings to HTTP (e.g., the HTTP
>> binding for XMPP defined in [BOSH]) SHOULD NOT use cookies even within
>> such a binding but instead SHOULD define their own application-specific
>> methods for state management.
> 
> I'm not sure what the difference between these options is. 

It might be a distinction without a difference. See above on HTTP
bindings vs. native modes for technologies like SIP and XMPP.

> I'm not
> sure we should recommend application-specific state management.
> Instead, we should aim for a general-purpose HTTP state management
> mechanism that doesn't suck (in phase two, of course).

Right, but are we aiming for a general-purpose state management
mechanism or a general-purpose *HTTP* state management mechanism? If the
former, we're designing for SIP and XMPP and FTP and Gopher and SMTP and
HTTP and any other application-level technology. If the latter then the
job is much easier (though still hard).

Do we really need to say anything about non-HTTP technologies in an
informational document on HTTP state management? It's not clear to me
that we do.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/