draft-ietf-httpstate-cookie-11.txt   draft-ietf-httpstate-cookie-12.txt 
httpstate A. Barth httpstate A. Barth
Internet-Draft U.C. Berkeley Internet-Draft U.C. Berkeley
Obsoletes: 2109 (if approved) September 5, 2010 Obsoletes: 2109 (if approved) September 16, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: March 9, 2011 Expires: March 20, 2011
HTTP State Management Mechanism HTTP State Management Mechanism
draft-ietf-httpstate-cookie-11 draft-ietf-httpstate-cookie-12
Abstract Abstract
This document defines the HTTP Cookie and Set-Cookie header fields. This document defines the HTTP Cookie and Set-Cookie header fields.
These header fields can be used by HTTP servers to store state These header fields can be used by HTTP servers to store state
(called cookies) at HTTP user agents, letting the servers maintain a (called cookies) at HTTP user agents, letting the servers maintain a
stateful session over the mostly stateless HTTP protocol. Although stateful session over the mostly stateless HTTP protocol. Although
cookies have many historical infelicities that degrade their security cookies have many historical infelicities that degrade their security
and privacy, the Cookie and Set-Cookie header fields are widely used and privacy, the Cookie and Set-Cookie header fields are widely used
on the Internet. on the Internet.
skipping to change at page 2, line 33 skipping to change at page 2, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 9, 2011. This Internet-Draft will expire on March 20, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 30 skipping to change at page 3, line 30
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11 4. Server Requirements . . . . . . . . . . . . . . . . . . . . . 11
4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Set-Cookie . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 12 4.1.2. Semantics (Non-Normative) . . . . . . . . . . . . . . 12
4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 15 4.2.2. Semantics . . . . . . . . . . . . . . . . . . . . . . 15
5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16 5. User Agent Requirements . . . . . . . . . . . . . . . . . . . 16
5.1. Algorithms . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Subcomponent Algorithms . . . . . . . . . . . . . . . . . 16
5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Dates . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1.2. Domains and domain-match . . . . . . . . . . . . . . . 18 5.1.2. Canonicalized host names . . . . . . . . . . . . . . . 18
5.1.3. Paths and path-match . . . . . . . . . . . . . . . . . 18 5.1.3. Domain matching . . . . . . . . . . . . . . . . . . . 18
5.1.4. Paths and path-match . . . . . . . . . . . . . . . . . 18
5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 19 5.2. The Set-Cookie Header . . . . . . . . . . . . . . . . . . 19
5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 21 5.2.1. The Expires Attribute . . . . . . . . . . . . . . . . 21
5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 21 5.2.2. The Max-Age Attribute . . . . . . . . . . . . . . . . 21
5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 22 5.2.3. The Domain Attribute . . . . . . . . . . . . . . . . . 22
5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 22 5.2.4. The Path Attribute . . . . . . . . . . . . . . . . . . 22
5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 22 5.2.5. The Secure Attribute . . . . . . . . . . . . . . . . . 23
5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 23 5.2.6. The HttpOnly Attribute . . . . . . . . . . . . . . . . 23
5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23 5.3. Storage Model . . . . . . . . . . . . . . . . . . . . . . 23
5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 26 5.4. The Cookie Header . . . . . . . . . . . . . . . . . . . . 26
6. Implementation Considerations . . . . . . . . . . . . . . . . 29 6. Implementation Considerations . . . . . . . . . . . . . . . . 29
6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Limits . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Application Programming Interfaces . . . . . . . . . . . . 29 6.2. Application Programming Interfaces . . . . . . . . . . . . 29
6.3. IDNA dependency and migration . . . . . . . . . . . . . . 29
7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 30
7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 30 7.1. Third-Party Cookies . . . . . . . . . . . . . . . . . . . 30
7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 30 7.2. User Controls . . . . . . . . . . . . . . . . . . . . . . 30
8. Security Considerations . . . . . . . . . . . . . . . . . . . 32 8. Security Considerations . . . . . . . . . . . . . . . . . . . 32
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 32 8.2. Ambient Authority . . . . . . . . . . . . . . . . . . . . 32
8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 33 8.3. Clear Text . . . . . . . . . . . . . . . . . . . . . . . . 33
8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 33 8.4. Session Identifiers . . . . . . . . . . . . . . . . . . . 33
8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 34 8.5. Weak Confidentiality . . . . . . . . . . . . . . . . . . . 34
8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 34 8.6. Weak Integrity . . . . . . . . . . . . . . . . . . . . . . 34
8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 35 8.7. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 35
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 36 9.1. Cookie . . . . . . . . . . . . . . . . . . . . . . . . . . 36
skipping to change at page 7, line 5 skipping to change at page 7, line 5
OWS SHOULD either not be produced or be produced as a single SP OWS SHOULD either not be produced or be produced as a single SP
character. character.
2.3. Terminology 2.3. Terminology
The terms user agent, client, server, proxy, and origin server have The terms user agent, client, server, proxy, and origin server have
the same meaning as in the HTTP/1.1 specification ([RFC2616], Section the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
1.3). 1.3).
The terms request-host and request-uri refer to the values the user The request-host is the fully-qualified domain name of the host to
agent would send to the server as, respectively, the host (but not which the user agent is sending an HTTP request or is receiving an
port) and the absoluteURI (http_URL) of the HTTP Request-Line. HTTP response from (i.e., the fully-qualified domain name of the host
to which it sent the corresponding HTTP request).
The term request-uri is defined in Section 5.1.2 of [RFC2616].
Two sequences of octets are said to case-insensitively match each Two sequences of octets are said to case-insensitively match each
other if and only if they are equivalent under the i;ascii-casemap other if and only if they are equivalent under the i;ascii-casemap
collation defined in [RFC4790]. collation defined in [RFC4790].
3. Overview 3. Overview
This section outlines a way for an origin server to send state This section outlines a way for an origin server to send state
information to a user agent and for the user agent to return the information to a user agent and for the user agent to return the
state information to the origin server. state information to the origin server.
To store state, the origin server includes a Set-Cookie header in an To store state, the origin server includes a Set-Cookie header in an
HTTP response. In subsequent requests, the user agent returns a HTTP response. In subsequent requests, the user agent returns a
Cookie request header to the origin server. The Cookie header Cookie request header to the origin server. The Cookie header
contains cookies the user agent received in previous Set-Cookie contains cookies the user agent received in previous Set-Cookie
headers. The origin server is free to ignore the Cookie header or headers. The origin server is free to ignore the Cookie header or
use its contents for an application-defined purpose. use its contents for an application-defined purpose.
Origin servers can send a Set-Cookie response header with any Origin servers can send a Set-Cookie response header with any
response. An origin server can include multiple Set-Cookie header response. An origin server can include multiple Set-Cookie header
fields in a single response. Note that folding multiple Set-Cookie fields in a single response.
header fields into a single header field might change the semantics
of the header because the U+002C (",") character is used by the Set- Note that folding multiple Set-Cookie header fields into a single
Cookie header in a way that conflicts with such folding. header field might change the semantics of the header because the
U+002C (",") character is used by the Set-Cookie header in a way that
conflicts with such folding. This historical infelicity is
incompatible with the usual mechanism for folding HTTP headers as
defined in [RFC2616].
3.1. Examples 3.1. Examples
Using the Set-Cookie header, a server can send the user agent a short Using the Set-Cookie header, a server can send the user agent a short
string in an HTTP response that the user agent will return in future string in an HTTP response that the user agent will return in future
HTTP requests. For example, the server can send the user agent a HTTP requests. For example, the server can send the user agent a
"session identifier" named SID with the value 31d4d96e407aad42. The "session identifier" named SID with the value 31d4d96e407aad42. The
user agent then returns the session identifier in subsequent user agent then returns the session identifier in subsequent
requests. requests.
skipping to change at page 11, line 43 skipping to change at page 11, line 43
cookie-value = token cookie-value = token
token = <token, defined in [RFC2616], Section 2.2> token = <token, defined in [RFC2616], Section 2.2>
cookie-av = expires-av / max-age-av / domain-av / cookie-av = expires-av / max-age-av / domain-av /
path-av / secure-av / httponly-av / path-av / secure-av / httponly-av /
extension-av extension-av
expires-av = "Expires=" sane-cookie-date expires-av = "Expires=" sane-cookie-date
sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1> sane-cookie-date = <rfc1123-date, defined in [RFC2616], Section 3.3.1>
max-age-av = "Max-Age=" 1*DIGIT max-age-av = "Max-Age=" 1*DIGIT
domain-av = "Domain=" domain-value domain-av = "Domain=" domain-value
domain-value = <subdomain, defined in [RFC1034], Section 3.5> domain-value = <subdomain>
; defined in [RFC1034], Section 3.5, as
; enhanced by [RFC1123], Section 2.1>
path-av = "Path=" path-value path-av = "Path=" path-value
path-value = <any CHAR except CTLs or ";"> path-value = <any CHAR except CTLs or ";">
secure-av = "Secure" secure-av = "Secure"
httponly-av = "HttpOnly" httponly-av = "HttpOnly"
extension-av = <any CHAR except CTLs or ";"> extension-av = <any CHAR except CTLs or ";">
Note that some of the grammatical terms above reference documents Note that some of the grammatical terms above reference documents
that use different grammatical notations than this document (which that use different grammatical notations than this document (which
uses ABNF from [RFC5234]). uses ABNF from [RFC5234]).
The semantics of the cookie-value are not defined by this document. The semantics of the cookie-value are not defined by this document.
To maximize compatibility with user agents, servers that wish to To maximize compatibility with user agents, servers that wish to
store non-ASCII data in a cookie-value SHOULD encode that data using store non-ASCII data in a cookie-value SHOULD encode that data using
a printable ASCII encoding. a printable ASCII encoding.
skipping to change at page 14, line 21 skipping to change at page 14, line 21
NOTE: For security reasons, many user agents are configured to reject NOTE: For security reasons, many user agents are configured to reject
Domain attributes that correspond to "public suffixes." For example, Domain attributes that correspond to "public suffixes." For example,
some user agents will reject Domain attributes of "com" or "co.uk". some user agents will reject Domain attributes of "com" or "co.uk".
4.1.2.4. The Path Attribute 4.1.2.4. The Path Attribute
The scope of each cookie is limited to a set of paths, controlled by The scope of each cookie is limited to a set of paths, controlled by
the Path attribute. If the server omits the Path attribute, the user the Path attribute. If the server omits the Path attribute, the user
agent will use the "directory" of the request-uri's path component as agent will use the "directory" of the request-uri's path component as
the default value. (See Section 5.1.3 for more details.) the default value. (See Section 5.1.4 for more details.)
The user agent will include the cookie in an HTTP request only if the The user agent will include the cookie in an HTTP request only if the
path portion of the request-uri matches (or is a subdirectory of) the path portion of the request-uri matches (or is a subdirectory of) the
cookie's Path attribute, where the U+002F ("/") character is cookie's Path attribute, where the U+002F ("/") character is
interpreted as a directory separator. interpreted as a directory separator.
Although seemingly useful for isolating cookies between different Although seemingly useful for isolating cookies between different
paths within a given domain, the Path attribute cannot be relied upon paths within a given domain, the Path attribute cannot be relied upon
for security (see Section 8). for security (see Section 8).
skipping to change at page 16, line 13 skipping to change at page 16, line 13
header. header.
5. User Agent Requirements 5. User Agent Requirements
For historical reasons, the full semantics of cookies (as presently For historical reasons, the full semantics of cookies (as presently
deployed on the Internet) contain a number of exotic quirks. This deployed on the Internet) contain a number of exotic quirks. This
section is intended to specify the Cookie and Set-Cookie headers in section is intended to specify the Cookie and Set-Cookie headers in
sufficient detail to allow a user agent implementing these sufficient detail to allow a user agent implementing these
requirements precisely to interoperate with existing servers. requirements precisely to interoperate with existing servers.
5.1. Algorithms 5.1. Subcomponent Algorithms
This section defines a number of algorithms used by user agents to This section defines some algorithms used by user agents to process
process the Cookie and Set-Cookie headers. specific subcomponents of the Cookie and Set-Cookie headers.
5.1.1. Dates 5.1.1. Dates
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to parse a cookie-date: algorithm to parse a cookie-date. Note that the various boolean
flags defined as a part of the algorithm are initially "not set".
1. Using the grammar below, divide the cookie-date into date-tokens. 1. Using the grammar below, divide the cookie-date into date-tokens.
cookie-date = *delimiter date-token-list *delimiter cookie-date = *delimiter date-token-list *delimiter
date-token-list = date-token *( 1*delimiter date-token ) date-token-list = date-token *( 1*delimiter date-token )
delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E delimiter = %x09 / %x20-2F / %x3B-40 / %x5B-60 / %x7B-7E
date-token = day-of-month / month / year / time / mystery date-token = day-of-month / month / year / time / mystery
day-of-month = 1*2DIGIT day-of-month = 1*2DIGIT
month = "jan" [ mystery ] / "feb" [ mystery ] / month = "jan" [ mystery ] / "feb" [ mystery ] /
"mar" [ mystery ] / "apr" [ mystery ] / "mar" [ mystery ] / "apr" [ mystery ] /
skipping to change at page 18, line 5 skipping to change at page 18, line 5
* the second-value is greater than 59. * the second-value is greater than 59.
6. Let the parsed-cookie-date be the date whose day-of-month, month, 6. Let the parsed-cookie-date be the date whose day-of-month, month,
year, hour, minute, and second (in GMT) are the day-of-month- year, hour, minute, and second (in GMT) are the day-of-month-
value, the month-value, the year-value, the hour-value, the value, the month-value, the year-value, the hour-value, the
minute-value, and the second-value, respectively. If no such minute-value, and the second-value, respectively. If no such
date exists, abort these steps and fail to parse the cookie-date. date exists, abort these steps and fail to parse the cookie-date.
7. Return the parsed-cookie-date as the result of this algorithm. 7. Return the parsed-cookie-date as the result of this algorithm.
5.1.2. Domains and domain-match 5.1.2. Canonicalized host names
A canonicalized string is the string converted to ASCII according to A canonicalized domain name is the string generated by the following
the IDNA specification [RFC3490] and converted to lower case. algorithm:
1. Convert the domain name to a sequence of NR-LDH labels (see
Section 2.3.2.2 of [RFC5890]) and/or A-labels according to the
appropriate IDNA specification [RFC5891] or [RFC3490] (see
Section 6.3 of this specification)
2. Convert the labels to lower case.
3. Concatenate the labels, separating each label from the next with
a U+002E (".") character.
5.1.3. Domain matching
A string domain-matches a given domain string if at least one of the A string domain-matches a given domain string if at least one of the
following conditions hold: following conditions hold:
o The domain string and the string are identical. o The domain string and the string are identical.
o All of the following conditions hold: o All of the following conditions hold:
* The domain string is a suffix of the string. * The domain string is a suffix of the string.
* The last character of the string that is not included in the * The last character of the string that is not included in the
domain string is a U+002E (".") character. domain string is a U+002E (".") character.
* The string is a host name (i.e., not an IP address). * The string is a host name (i.e., not an IP address).
5.1.3. Paths and path-match 5.1.4. Paths and path-match
The user agent MUST use an algorithm equivalent to the following The user agent MUST use an algorithm equivalent to the following
algorithm to compute the default-path of a cookie: algorithm to compute the default-path of a cookie:
1. Let uri-path be the path portion of the request-uri if such a 1. Let uri-path be the path portion of the request-uri if such a
portion exists (and empty otherwise). For example, if the portion exists (and empty otherwise). For example, if the
request-uri contains just a path (and optional query string), request-uri contains just a path (and optional query string),
then the uri-path is that path (without the U+003F ("?") then the uri-path is that path (without the U+003F ("?")
character or query string), and if the request-uri contains a character or query string), and if the request-uri contains a
full absoluteURI, the uri-path is the path component of that URI. full absoluteURI, the uri-path is the path component of that URI.
skipping to change at page 30, line 5 skipping to change at page 29, line 44
parse the syntax used by the Cookie and Set-Cookie headers, which parse the syntax used by the Cookie and Set-Cookie headers, which
many programmers have done incorrectly, resulting in interoperability many programmers have done incorrectly, resulting in interoperability
problems. problems.
Instead of providing string-based APIs to cookies, platforms would be Instead of providing string-based APIs to cookies, platforms would be
well-served by providing more semantic APIs. It is beyond the scope well-served by providing more semantic APIs. It is beyond the scope
of this document to recommend specific API designs, but there are of this document to recommend specific API designs, but there are
clear benefits to accepting an abstract "Date" object instead of a clear benefits to accepting an abstract "Date" object instead of a
serialized date string. serialized date string.
6.3. IDNA dependency and migration
IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not
backwards-compatible. For this reason, there will be a transition
period (possibly of a number of years). User agents SHOULD implement
IDNA2008 [RFC5890] and MAY implement [Unicode Technical Standard #46
<http://unicode.org/reports/tr46/>] in order to facilitate a smoother
IDNA transition. If a user agent does not implement IDNA2008, the
user agents MUST implement IDNA2003 [RFC3490].
7. Privacy Considerations 7. Privacy Considerations
Cookies are often criticized for letting servers track users. For Cookies are often criticized for letting servers track users. For
example, a number of "web analytics" companies use cookies to example, a number of "web analytics" companies use cookies to
recognize when a user returns to a web site or visits another web recognize when a user returns to a web site or visits another web
site. Although cookies are not the only mechanism servers can use to site. Although cookies are not the only mechanism servers can use to
track users across HTTP requests, cookies facilitate tracking because track users across HTTP requests, cookies facilitate tracking because
they are persistent across user agent sessions and can be shared they are persistent across user agent sessions and can be shared
between domains. between domains.
skipping to change at page 37, line 12 skipping to change at page 37, line 12
Specification document: this specification (Section 5.2) Specification document: this specification (Section 5.2)
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)", "Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, March 2003. RFC 3490, March 2003.
skipping to change at page 37, line 36 skipping to change at page 37, line 39
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet [RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
Application Protocol Collation Registry", RFC 4790, Application Protocol Collation Registry", RFC 4790,
March 2007. March 2007.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5890] Klensin, J., "Internationalized Domain Names for
Applications (IDNA): Definitions and Document Framework",
RFC 5890, August 2010.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891, August 2010.
10.2. Informative References 10.2. Informative References
[RFC2109] Kristol, D. and L. Montulli, "HTTP State Management [RFC2109] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2109, February 1997. Mechanism", RFC 2109, February 1997.
[RFC2965] Kristol, D. and L. Montulli, "HTTP State Management [RFC2965] Kristol, D. and L. Montulli, "HTTP State Management
Mechanism", RFC 2965, October 2000. Mechanism", RFC 2965, October 2000.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[Netscape] [Netscape]
"Persistent Client State -- HTTP Cookies". Netscape Communications Corp., "Persistent Client State --
HTTP Cookies", 1999, <http://web.archive.org/web/
20020803110822/http://wp.netscape.com/newsref/std/
cookie_spec.html>.
[Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and [Kri2001] Kristol, D., "HTTP Cookies: Standards, Privacy, and
Politics", ACM Transactions on Internet Technology Vol. 1, Politics", ACM Transactions on Internet Technology Vol. 1,
#2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>. #2, November 2001, <http://arxiv.org/abs/cs.SE/0105018>.
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
Appendix A. Acknowledgements Appendix A. Acknowledgements
 End of changes. 24 change blocks. 
27 lines changed or deleted 74 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/