Forwarded message 1
The IESG has approved publication of the following Internet-Drafts:
o Use of HTTP State Management <draft-iesg-http-cookies-03.txt> as a
BCP.
o HTTP State Management Mechanism
<draft-ietf-http-state-man-mec-12.txt> as a Proposed Standard.
The IESG contact person is Patrik Faltstrom.
Technical Summary
The draft-ietf-http-state-man-mec-12.txt 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 [Netscape], but it can
interoperate with HTTP/1.0 user agents that use Netscape's method.
(See the HISTORICAL section.) The document reflects implementation
experiences from RFC 2109 [RFC2109] and obsoletes it.
Even though this protocol has been approved for the Internet standards
track, some current and potential uses of the protocol are not within
the scope of the standard approved by IESG.
draft-iesg-http-cookies-03.txt identifies specific uses of HTTP State
Management protocol which are either (a) nonstandard and thus not
recommended by IETF, or (b) nonstandard, believed to be harmful, and
discouraged. It also details additional privacy considerations which
are not covered by the HTTP State Management protocol specification.
Working Group Summary
It was early obvious that RFC 2109 had to be replaced due to
implementation experiences. Various players on the Internet do though
use cookies and states for different uses, and because of this, the
discussion sometimes was quite heated. The IESG reviewed the issues,
and wrote an applicability statement which after a lot of discussions
ended up becoming draft-iesg-http-cookies-03.txt, which explains what
parts of the state-man-mec which are in scope of IETF discussions.
Protocol Quality
The protocol was reviewed by Patrik Faltstrom.
Note to RFC Editor:
Please include the following text as an IESG Note:
The IESG notes that this mechanism makes use of the .local
top-level domain (TLD) internally when handling host names
that don't contain any dots, and that this mechanism might
not work in the expected way should an actual .local TLD
ever be registered.