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

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? 

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?

4.2.2 - "If an attribute appears more than once in a cookie, the
behavior is undefined." Undefined things have a habit of defining
themselves, let us not repeat the mistakes which caused so much trouble
with cookies in the first place. If an attribute appears more than once
then the first appearance defines the value and subsequent attributes
are ignored.
4.2.2 - Security - "When it sends a "secure" cookie back to a server,
the user agent should use no less than the same level of security as was
used when it received the cookie from the server." What does this mean?
How does one decide equivalence?
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.

> -----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.

Received on Wednesday, 9 July 1997 16:54:01 UTC