Reported by: Arne Thomassen; arne@arne-thomassen.de
Date: ???

In section 1:

   The terms user agent, client, server, proxy, origin server, and
   http_URL have the same meaning as in the HTTP/1.1 specification
   [RFC2616].  The terms abs_path and absoluteURI have the same meaning
   as in the URI Syntax specification [RFC2396].

Should be:

   The terms user agent, client, server, proxy, origin server, and
   header field, and the tokens DIGIT, token, http_URL, and quoted-string
   have the same meaning as in the HTTP/1.1 specification [RFC2616].  The
   tokens abs_path and absoluteURI have the same meaning as in the URI
   Syntax specification [RFC2396].

   The grammar uses the notation from the HTTP/1.1 specification
   [RFC2616] to describe the syntax of HTTP header fields.

In section 1:

   The term effective host name is related to host name.  If a host name
   contains no dots, the effective host name is that name with the
   string .local appended to it.  Otherwise the effective host name is
   the same as the host name.  Note that all effective host names
   contain at least one dot.

Should be:

   The term effective host name is related to host name.  If a host name
   is a host domain name and contains no dots, the effective host name
   is that name with the string .local appended to it.  Otherwise the
   effective host name is the same as the host name.

In section 3.1:

   The two state management headers, Set-Cookie2 and Cookie, have common
   syntactic properties involving attribute-value pairs.  The following
   grammar uses the notation, and tokens DIGIT (decimal digits), token
   (informally, a sequence of non-special, non-white space characters),
   and http_URL from the HTTP/1.1 specification [RFC2616] to describe
   their syntax.

Should be:

   The two state management header fields Set-Cookie2 and Cookie have
   common syntactic properties involving attribute-value pairs.

In section 3.2.1:

   A user agent returns a Cookie request header (see below) to the
   origin server if it chooses to continue a session.

Should be:

   A user agent returns one or more Cookie request header fields (see
   below) to the origin server if it chooses to continue a session.

In section 3.2.2:

      confidentially and authenticity of the information in the cookie.

Should be:

      confidentiality and authenticity of the information in the cookie.

In section 3.3.4:

   3.3.4  Sending Cookies to the Origin Server  When it sends a request
   to an origin server, the user agent includes a Cookie request header
   if it has stored cookies that are applicable to the request, based on

Should be:

   3.3.4  Sending Cookies to the Origin Server  When it sends a request
   to an origin server, the user agent includes one or more Cookie
   request header fields if it has stored cookies that are applicable to
   the request, based on

In section 3.3.4:

   port            =  "$Port" [ "=" <"> value <"> ]

Should be:

   port            =  "$Port" [ "=" <"> portlist <"> ]

In section 3.3.4:

   The port attribute of the Cookie request header MUST mirror the Port
   attribute, if one was present, in the corresponding Set-Cookie2
   response header.  That is, the port attribute MUST be present if the
   Port attribute was present in the Set-Cookie2 header, and it MUST
   have the same value, if any.  Otherwise, if the Port attribute was
   absent from the Set-Cookie2 header, the attribute likewise MUST be
   omitted from the Cookie request header.

Should be:

   The port attribute of the Cookie request header field MUST be exactly
   the value of the Port attribute, if one was present, in the corre-
   sponding Set-Cookie2 response header field.  That is, the port
   attribute MUST be present if the Port attribute was present in the
   Set-Cookie2 header field, and it MUST have the same value (the exact
   character sequence), if any.  Otherwise, if the Port attribute was
   absent from the Set-Cookie2 header field, the attribute likewise MUST
   be omitted from the Cookie request header field.

In section 7.2:

         Cookie: $Version="1"; session_id="1234",
                 $Version="1"; session_id="1111"; $Domain=".cracker.edu"

Should be:

         Cookie: $Version="1"; session_id="1234"
         Cookie: $Version="1"; session_id="1111"; $Domain=".cracker.edu"

Throughout the document, "header" should be "header field", and
"headers" should be "header fields", respectively.

Reported by: Arne Thomassen; arne@arne-thomassen.de
Date: ???

In section 4.2.1:

   An origin server may include multiple Set-Cookie headers in a
   response.  Note that an intervening gateway could fold multiple such
   headers into a single header.

Should be:

   An origin server MAY include multiple Set-Cookie header fields in a
   response.

In section 10.1.2:

   Netscape's original proposal defined an Expires header that took a
   date value in a fixed-length variant format in place of Max-Age:

Should be:

   Netscape's original proposal defined an Expires attribute that took a
   date value in a fixed-length variant format in place of Max-Age:

In section 10.1.2, the following paragraph should be appended:

   Contrary to RFC 2616, 4.2, origin servers, proxies etc. MUST NOT
   combine Set-Cookie response header fields. This restriction is
   necessary because a Set-Cookie header field that follows Netscape's
   original proposal will contain an unquoted comma after a weekday name
   in an Expires attribute value, and existing incorrect/unaware user
   agent implementations will be confused when a comma can also mean a
   cookie separator.