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

Adam Barth <ietf@adambarth.com> Thu, 25 February 2010 00:02 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FAD728C28F for <http-state@core3.amsl.com>; Wed, 24 Feb 2010 16:02:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z9ySxuhVuwwQ for <http-state@core3.amsl.com>; Wed, 24 Feb 2010 16:02:32 -0800 (PST)
Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 17B5228C1FB for <http-state@ietf.org>; Wed, 24 Feb 2010 16:02:32 -0800 (PST)
Received: by gyg13 with SMTP id 13so1051752gyg.31 for <http-state@ietf.org>; Wed, 24 Feb 2010 16:04:37 -0800 (PST)
Received: by 10.101.3.34 with SMTP id f34mr422121ani.135.1267056276971; Wed, 24 Feb 2010 16:04:36 -0800 (PST)
Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by mx.google.com with ESMTPS id 34sm966586yxf.29.2010.02.24.16.04.34 (version=SSLv3 cipher=RC4-MD5); Wed, 24 Feb 2010 16:04:35 -0800 (PST)
Received: by iwn29 with SMTP id 29so3867870iwn.31 for <http-state@ietf.org>; Wed, 24 Feb 2010 16:04:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.231.153.1 with SMTP id i1mr492748ibw.35.1267056274101; Wed, 24 Feb 2010 16:04:34 -0800 (PST)
In-Reply-To: <4B85BBA6.7040604@stpeter.im>
References: <5c4444771002231855s36391fdfgd30a1ebc57722915@mail.gmail.com> <4B84A55E.6000304@stpeter.im> <5c4444771002232011x7ef1a15dj23a5b58357915fa6@mail.gmail.com> <4B85BBA6.7040604@stpeter.im>
From: Adam Barth <ietf@adambarth.com>
Date: Wed, 24 Feb 2010 16:04:14 -0800
Message-ID: <5c4444771002241604p79cc80beo721a1366562434cb@mail.gmail.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: http-state@ietf.org
Subject: Re: [http-state] Whether to recommend the cookie protocol (was Re: I-D Action:draft-ietf-httpstate-cookie-04.txt)
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Feb 2010 00:02:33 -0000

I didn't understand very much of your message, probably because I'm
ignorant of the relevant technologies and their associated social
conventions.  In any case, the subject is moot because the text you're
arguing against has been removed.

Kind regards,
Adam


On Wed, Feb 24, 2010 at 3:52 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
> On 2/23/10 9:11 PM, Adam Barth wrote:
>> On Tue, Feb 23, 2010 at 8:04 PM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
>>> On 2/23/10 7:55 PM, Adam Barth wrote:
>>>> On Tue, Feb 23, 2010 at 9:10 AM, Anne van Kesteren <annevk@opera.com> wrote:
>>>>> On Tue, 23 Feb 2010 17:15:04 +0100, <Internet-Drafts@ietf.org> 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/
>
>
>
>