Re: cookie draft available

Dave Kristol asked me to provide some specifics for tightening up some
of the expository language in the draft.  Below are some suggested
wording changes.  The original text is included with a > where I
referenced only a single sentence or so ; where I worked on a section,
only the section numbers are present.  In no case did I intend to
change the behavior of the protocol, so if you see something that
looks like it means something different, please flag it!

			Regards,
				Ted Hardie
________________________________________________________________________ 
>Fully-qualified host name (FQHN) means either the numeric IP address 
>of a host, or its full Internet domain name, resolved to a top-level 
>domain such as .com or .uk.

Fully qualified host name (FQHN) means either the numeric IP address
of a host, or its fully qualified domain name.  The fully qualified
domain name is preferred, for the reasons given in RFC 1900 (ref).
The port number does not form part of the FQHN.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3. State and Sessions

This proposal describes a method for creating stateful sessions with
HTTP requests and responses.  Currently, HTTP servers respond to each
client request without relating that request to previous or subsequent
requests; the proposed method allows clients and servers who wish to
exchange state information to place http requests and responses within
a larger context. This context we term a session.  This context might,
for example, be used to create a "shopping cart", in which user
selections can be aggregated before purchase, or a magazine browsing
system, in which a user's previous reading affects which offerings are
presented.

There are, of course, may different potential contexts and thus many
different potential types of session.  The designers' paradigm for the
sessions created by the exchange of cookies has these key attributes:

1. Each session has a beginning and an end.

2. Each session is relatively short-lived.

3. Either the user agent or the origin server may terminate a session.

4. The session is created by the exchange of state information.

Additionally, the designers wish to create a system which fits within
the dimensions of the solution space for stateful dialogs identified
by Koen Hamilton.  The system is thus meant to be:

* Simple to implement.

* Simple to use.

* Compatible with previous implementations.

* Easily deployed after standardization.

* Reliable.

* Protective of the privacy of its users.

* Compatible with cache control.

* Low-risk when used with older, non-compatible caches.

* As complex as possible within the framework of its other
requirements.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4.2.1 
>(Note that "session" here is a logical connection, not a physical one.
>These logical sessions should not be confused with various "keepalive" 
>proposals for physical sessions.)

(Note that the "session" here does not refer to a persistent network
connection but to a logical session created from HTTP requests and
responses.  The presence or absence of a persistent connection should
have no effect on the use of cookie-derived sessions).
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
4.3.5

Users must have control over sessions in order to insure privacy (see
Privacy Section Below).  To ease implementation and to prevent an
additional layer of complexity where adequate safeguards exist, this
proposal does distinguish, however, between transactions which are
verifiable and those which are unverifiable.  A transaction is
verifiable if the user has the option to review the request-URI prior
to its use in the transaction.  A transaction is unverifiable if the
user does not have that option.  Unverifiable transactions typically
occur when a user-agent automatically request inlined or embedded
entities and when a user agent resolves a redirection (3xx) response
from an origin server.  Thus origin transactions, those directly
initiated by the user, tend to be verifiable where transactions
consequent on those origin transactions tend to be unverifiable.

When making an unverifiable transaction, a user agent must only enable
sessions if a cookie with a domain attribute D was sent or received in
the origin transaction and the host name in the Request-URI of the
unverifiable transaction domain-matches D.

This restriction prevents a malicious service author from using
unverifiable transactions to induce a user agent to start or continue
a session with a server in a different domain.  The starting or
continuation of such sessions could be contrary to the privacy
expectations of the user, and could also present a security problem.
User agents may offer configurable options that allow the user agent,
or any autonomous programs that the user agent executes to ignore the
above rule, so long as these override options default to "off".

NB: Many current user agents already provide acceptable review
methods, which render most user-selected links verifiable.  Among the
current review methods are: 
........as before
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>4.4 How an Origin Server Interprets Cookie 
4.4 How an Origin Server Interprets a Cookie
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
6.3 
>Furthermore, they should provide the following minimum capabilities: 
General-use user agents should provide the following
minimum capabilities: 
........as before (to the end of indented requirements).

User agents created for specific purposes or for limited-capacity
devices must provide at least 20 cookies of 4096 bytes, to ensure that
the user can interact with a session-based origin server.

Received on Friday, 19 April 1996 15:20:49 UTC