attached mail follows:
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.Received on Tuesday, 8 August 2000 08:18:08 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:07 UTC