RE: LAST CALL, "HTTP State Management Mechanism (Rev1) " to Proposed Standard

At 04:51 PM 7/9/97 -0700, Yaron Goland wrote:
>Oops sorry, things do tend to fall between the cracks.
>BTW I find it strange that we are pushing a draft to proposed standard
>when no one has implemented it and, in so far as I am aware, is even
>planning on implementing it. Is the cookie spec really relevant in a
>world with OPS? 

	We rely on cookies for a lot more than storing a user profile. OPS is
really welcome, but is only a tangentially complementary technology.

>Do we really want to officially stamp a mechanism which:
>	Renders proxies useless?
>	Prevents sharing of cookies between sites that are owned by the
>same entity but have different domains?
>	Prevents sharing of cookies more than one level deep within a
>single domain?

	I have not seen any arguments in this list which counter the various
scenarios where a server owner has a right and a necessity to store state
info in a client. Ignorance of cookies and what they ameliorate (server
states, huge hidden URLs, vast hackery) drives the paranoia that impedes a
useful state mechanism. UA helpfiles and configuration UIs that allow
defeating Cookies (and the Net apps that rely on them) are more than proof
against this ignorance. The remedies to Cookie incompatibility in the new
draft are valuable, but rendered worthless if Cookies are unused due to
their unreliable presence in an application architecture.

>My standard objection to requirement effecting the UI and feature set of
>user agents apply and are well document in the archives of this group so
>I won't repeat them.
>		Yaron

>> -----Original Message-----
>> From:	Larry Masinter []
>> Sent:	Tuesday, July 08, 1997 7:33 AM
>> To:
>> Subject:	LAST CALL, "HTTP State Management Mechanism (Rev1) " to
>> Proposed Standard
>> draft-ietf-http-state-man-mec-02.txt
>> > This document specifies a way to create a stateful session with HTTP
>> > requests and responses.  It describes two new headers, Cookie and
>> Set-
>> > Cookie2, which carry state information between participating origin
>> > servers and user agents.  The method described here differs from
>> > Netscape's Cookie proposal, but it can interoperate with HTTP/1.0
>> user
>> > agents that use Netscape's method.  (See the HISTORICAL section.)
>> > 
>> > This document reflects implementation experience with RFC 2109 and
>> > obsoletes it.
>> I am not aware of any comments on this draft since its release
>> on June 20.
>> Unless there are any new objections, we will submit this as Proposed
>> Standard on July 15.
Matthew Rubenstein                    North American Media Engines
Toronto, Ontario   *finger matt for public key*      (416)943-1010

			    Chess is for computers.

Received on Wednesday, 9 July 1997 17:24:22 UTC