HTTP Working Group R. Fielding
Internet-Draft Adobe Systems Incorporated
Intended status: Standards Track M. Nottingham
Expires: September 3, 2016 March 2, 2016
The Key HTTP Response Header Field
draft-ietf-httpbis-key-01
Abstract
The 'Key' header field for HTTP responses allows an origin server to
describe the secondary cache key (RFC 7234, Section 4.1) for a
resource, by conveying what is effectively a short algorithm that can
be used upon later requests to determine if a stored response is
reusable for a given request.
Key has the advantage of avoiding an additional round trip for
validation whenever a new request differs slightly, but not
significantly, from prior requests.
Key also informs user agents of the request characteristics that
might result in different content, which can be useful if the user
agent is not sending request header fields in order to reduce the
risk of fingerprinting.
Note to Readers
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ .
Working Group information can be found at http://httpwg.github.io/ ;
source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/key .
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
Fielding & Nottingham Expires September 3, 2016 [Page 1]
Internet-Draft Key March 2016
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 3, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. The "Key" Response Header Field . . . . . . . . . . . . . . . 4
2.1. Relationship with Vary . . . . . . . . . . . . . . . . . 5
2.2. Calculating a Secondary Cache Key . . . . . . . . . . . . 6
2.2.1. Creating a Header Field Value . . . . . . . . . . . . 8
2.2.2. Failing Parameter Processing . . . . . . . . . . . . 8
2.3. Key Parameters . . . . . . . . . . . . . . . . . . . . . 9
2.3.1. div . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2. partition . . . . . . . . . . . . . . . . . . . . . . 10
2.3.3. match . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.4. substr . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.5. param . . . . . . . . . . . . . . . . . . . . . . . . 13
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
3.1. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Registrations . . . . . . . . . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Normative References . . . . . . . . . . . . . . . . . . 15
5.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 16
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . 16
B.1. Since -00 . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
Fielding & Nottingham Expires September 3, 2016 [Page 2]
Internet-Draft Key March 2016
1. Introduction
In HTTP caching [RFC7234], the Vary response header field effectively
modifies the key used to store and access a response to include
information from the request's headers. This "secondary cache key"
allows proactive content negotiation [RFC7231] to work with caches.
Vary's operation is generic; it works well when caches understand the
semantics of the selecting headers. For example, the Accept-Language
request header field has a well-defined syntax for expressing the
client's preferences; a cache that understands this header field can
select the appropriate response (based upon its Content-Language
header field) and serve it to a client, without any knowledge of the
underlying resource.
Vary does not work as well when the criteria for selecting a response
are specific to the resource. For example, if the nature of the
response depends upon the presence or absence of a particular Cookie
([RFC6265]) in a request, Vary doesn't have a mechanism to offer
enough fine-grained, resource-specific information to aid a cache's
selection of the appropriate response.
This document defines a new response header field, "Key", that allows
resources to describe the secondary cache key in a fine-grained,
resource-specific manner, leading to improved cache efficiency when
responses depend upon such headers.
1.1. Examples
For example, this response header field:
Key: cookie;param=_sess;param=ID
indicates that the selected response depends upon the "_sess" and
"ID" cookie values.
This Key:
Key: user-agent;substr=MSIE
indicates that there are two possible secondary cache keys for this
resource; one for requests whose User-Agent header field contains
"MSIE", and another for those that don't.
A more complex example:
Fielding & Nottingham Expires September 3, 2016 [Page 3]
Internet-Draft Key March 2016
Key: user-agent;substr=MSIE;Substr="mobile", Cookie;param="ID"
indicates that the selected response depends on the presence of two
strings in the User-Agent request header field, as well as the value
of the "ID" cookie request header field.
1.2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
This document uses the Augmented Backus-Naur Form (ABNF) notation of
[RFC5234] (including the DQUOTE rule), and the list rule extension
defined in [RFC7230], Section 7. It includes by reference the field-
name, quoted-string and quoted-pair rules from that document, the OWS
rule from [RFC7230] and the parameter rule from [RFC7231].
2. The "Key" Response Header Field
The "Key" response header field describes the portions of the request
that the resource currently uses to select representations.
As such, its semantics are similar to the "Vary" response header
field, but it allows more fine-grained description, using "key
parameters".
Caches can use this information as part of determining whether a
stored response can be used to satisfy a given request. When a cache
knows and fully understands the Key header field for a given
resource, it MAY ignore the Vary response header field in any stored
responses for it.
Additionally, user agents can use Key to discover if additional
request header fields might influence the resource's selection of
responses.
The Key field-value is a comma-delimited list of selecting header
fields (similar to Vary), with zero to many parameters each,
delimited by semicolons.
Key = 1#key-value
key-value = field-name *( OWS ";" OWS parameter )
Note that, as per [RFC7231], parameter names are case-insensitive,
and parameter values can be double-quoted strings (potentially with
"\"-escaped characters inside).
Fielding & Nottingham Expires September 3, 2016 [Page 4]
Internet-Draft Key March 2016
The following header fields have the same effect:
Vary: Accept-Encoding, Cookie
Key: Accept-Encoding, Cookie
However, Key's use of parameters allows:
Key: Accept-Encoding, Cookie; param=foo
to indicate that the secondary cache key depends upon the Accept-
Encoding header field and the "foo" Cookie.
One important difference between Vary and Key is how they are
applied. Vary is specified to be specific to the response it occurs
within, whereas Key is specific to the resource (as identified by the
request URL) it is associated with. The most recent key you receive
for a given resource is applicable to all responses from that
resource.
This difference allows more efficient implementation (and reflects
practices that many caches use in implementing Vary already).
This specification defines a selection of Key parameters to address
common use cases such as selection upon individual Cookie header
fields, User-Agent substrings and numerical ranges. Future
parameters may define further capabilities.
2.1. Relationship with Vary
Origin servers SHOULD still send Vary when using Key, to ensure
backwards compatibility.
For example,
Vary: User-Agent
Key: User-Agent;substr="mozilla"
Note that, in some cases, it may be better to explicitly use "Vary:
*" if clients and caches don't have any practical way to use the Vary
header field's value. For example,
Vary: *
Key: Cookie;param="ID"
Fielding & Nottingham Expires September 3, 2016 [Page 5]
Internet-Draft Key March 2016
Except when Vary: * is used, the set of headers used in Key SHOULD
reflect the same request header fields as Vary does, even if they
don't have parameters. For example,
Vary: Accept-Encoding, User-Agent
Key: Accept-Encoding, User-Agent;substr="mozilla"
Here, Accept-Encoding is included in Key without parameters; caches
MAY treat these as they do values in the Vary header, relying upon
knowledge of their generic semantics to select an appropriate
response.
2.2. Calculating a Secondary Cache Key
When used by a cache to determine whether a stored response can be
used to satisfy a presented request, each field-name in Key
identifies a potential request header, just as with the Vary response
header field.
However, each of these can have zero to many key parameters that
change how the response selection process (as defined in [RFC7234],
Section 4.3)) works.
In particular, when a cache fully implements this specification, it
creates a secondary cache key for every request by following the
instructions in the Key header field, ignoring the Vary header for
this purpose.
Then, when a new request is presented, the secondary cache key
generated for that request can be compared to the stored one to find
the appropriate response, to determine if it can be selected.
To generate a secondary cache key for a given request (including that
which is stored with a response) using Key, the following steps are
taken:
1) If the Key header field is not present on the most recent
cacheable (as per [RFC7234], Section 3)) response seen for the
resource, abort this algorithm (i.e., fall back to using Vary to
determine the secondary cache key).
2) Let "key_value" be the result of Creating a Header Field Value
(Section 2.2.1) with "key" as the "target_field_name" and the
most recently seen response header list for the resource as
"header_list".
3) Let "secondary_key" be an empty string.
Fielding & Nottingham Expires September 3, 2016 [Page 6]
Internet-Draft Key March 2016
4) Create "key_list" by splitting "key_value" on "," characters,
excepting "," characters within quoted strings, as per [RFC7230]
Section 3.2.6..
5) For "key_item" in "key_list":
1) Remove any leading and trailing WSP from "key_item".
2) If "key_item" does not contain a ";" character, fail
parameter processing (Section 2.2.2) and skip to the next
"key_item".
3) Let "field_name" be the string before the first ";" character
in "key_item", removing any WSP between them.
4) Let "field_value" be the result of Creating a Header Field
Value (Section 2.2.1) with "field_name" as the
"target_field_name" and the request header list as
"header_list".
5) Let "parameters" be the string after the first ";" character
in "key_item", removing any WSP between them.
6) Create "param_list" by splitting "parameters" on ";"
characters, excepting ";" characters within quoted strings,
as per [RFC7230] Section 3.2.6.
7) For "parameter" in "param_list":
1) If "parameter" does not contain a "=", fail parameter
processing (Section 2.2.2) and skip to the next
"key_item".
2) Remove any WSP at the beginning and/or end of
"parameter".
3) Let "param_name" be the string before the first "="
character in "parameter", case-normalized to lowercase.
4) If "param_name" does not identify a Key parameter
processing algorithm that is implemented, fail parameter
processing (Section 2.2.2) and skip to the next
"key_item".
5) Let "param_value" be the string after the first "="
character in "parameter".
6) If the first and last characters of "param_value" are
both DQUOTE:
1) Remove the first and last characters of
"param_value".
2) Replace quoted-pairs within "param_value" with the
octet following the backslash, as per [RFC7230]
Section 3.2.6.
7) If "param_value" does not conform to the syntax defined
for it by the parameter definition, fail parameter
processing Section 2.2.2 and skip to the next "key_item".
8) Run the identified processing algorithm on "field_value"
with the "param_value", and append the result to
Fielding & Nottingham Expires September 3, 2016 [Page 7]
Internet-Draft Key March 2016
"secondary_key". If parameter processing fails
Section 2.2.2, skip to the next "key_item".
9) Append a separator character (e.g., NULL) to
"secondary_key".
6) Return "secondary_key".
Note that this specification does not require that exact algorithm to
be implemented. However, implementations' observable behavior MUST
be identical to running it. This includes parameter processing
algorithms; implementations MAY use different internal artefacts for
secondary cache keys, as long as the results are the same.
Likewise, while the secondary cache key associated with both stored
and presented requests is required to use the most recently seen Key
header field for the resource in question, this can be achieved using
a variety of implementation strategies, including (but not limited
to):
o Generating a new secondary cache key for every stored response
associated with the resource upon each request.
o Caching the secondary cache key with the stored request/response
pair and re-generating it when the Key header field is observed to
change.
o Caching the secondary cache key with the stored response and
invalidating the stored response(s) when the Key header field is
observed to change.
2.2.1. Creating a Header Field Value
Given a header field name "target_field_name" and "header_list", a
list of ("field_name", "field_value") tuples:
1) Let "target_field_values" be an empty list.
2) For each ("field_name", "field_value") tuple in "header_list":
1) If "field_name" does not match "target_field_name", skip to
the next tuple.
2) Strip leading and trailing WSP from "field_value" and append
it to "target_field_values".
3) If "target_field_values" is empty, return an empty string.
4) Return the concatenation of "target_field_values", separating
each with "," characters.
2.2.2. Failing Parameter Processing
In some cases, a key parameter cannot determine a secondary cache key
corresponding to its nominated header field value. When this
Fielding & Nottingham Expires September 3, 2016 [Page 8]
Internet-Draft Key March 2016
happens, Key processing needs to fail safely, so that the correct
behavior is observed.
When this happens, implementations MUST either behave as if the Key
header was not present, or assure that the nominated header fields
being compared match, as per [RFC7234], Section 4.1.
2.3. Key Parameters
A Key parameter associates a name with a specific processing
algorithm that takes two inputs; a HTTP header value "header_value"
(as described in Section 2.2.1), and "parameter_value", a string that
indicates how the identified header should be processed.
The set of key parameters (and their associated processing
algorithms) is extensible; see Section 3. This document defines the
following key parameters:
2.3.1. div
The "div" parameter normalizes positive integer header values into
groups by dividing them by a configured value.
Its value's syntax is:
div = 1*DIGIT
To process a set of header fields against a div parameter, follow
these steps (or their equivalent):
1) If "parameter_value" is "0", fail parameter processing
Section 2.2.2.
2) If "header_value" is the empty string, return "none".
3) If "header_value" contains a ",", remove it and all subsequent
characters.
4) Remove all WSP characters from "header_value".
5) If "header_value" does not match the div ABNF rule, fail
parameter processing (Section 2.2.2).
6) Return the quotient of "header_value" / "parameter_value"
(omitting the modulus).
For example, the Key:
Key: Bar;div=5
Fielding & Nottingham Expires September 3, 2016 [Page 9]
Internet-Draft Key March 2016
indicates that the "Bar" header's field value should be partitioned
into groups of 5. Thus, the following field values would be
considered the same (because, divided by 5, they all result in 0):
Bar: 1
Bar: 3 , 42
Bar: 4, 1
whereas these would be considered to be in a different group
(because, divided by 5, they all result in 2);
Bar: 12
Bar: 10
Bar: 14, 1
2.3.2. partition
The "partition" parameter normalizes positive numeric header values
into pre-defined segments.
Its value's syntax is:
partition = [ segment ] *( ":" [ segment ] )
segment = [ 0*DIGIT "." ] 1*DIGIT
To process a set of header fields against a partition parameter,
follow these steps (or their equivalent):
1) If "header_value" is the empty string, return "none".
2) If "header_value" contains a ",", remove it and all subsequent
characters.
3) Remove all WSP characters from "header_value".
4) If "header_value" does not match the segment ABNF rule, fail
parameter processing (Section 2.2.2).
5) Let "segment_id" be 0.
6) Create a list "segment_list" by splitting "parameter_value" on
":" characters.
7) For each "segment_value" in "segment_list":
1) If "header_value" is less than "segment_value" when they are
numerically compared, skip to step 7.
2) Increment "segment_id" by 1.
8) Return "segment_id".
For example, the Key:
Fielding & Nottingham Expires September 3, 2016 [Page 10]
Internet-Draft Key March 2016
Key: Foo;partition=20:30:40
indicates that the "Foo" header's field value should be divided into
four segments:
o less than 20
o 20 to less than 30
o 30 to less than 40
o forty or greater
Thus, the following headers would all be normalized to the first
segment:
Foo: 1
Foo: 0
Foo: 4, 54
Foo: 19.9
whereas the following would fall into the second segment:
Foo: 20
Foo: 29.999
Foo: 24 , 10
2.3.3. match
The "match" parameter is used to determine if an exact value occurs
in a list of header values. It is case-sensitive.
Its value's syntax is:
match = ( token / quoted-string )
To process a set of header fields against a match parameter, follow
these steps (or their equivalent):
1) If "header_value" is the empty string, return "none".
2) Create "header_list" by splitting "header_value" on ","
characters.
3) For each "header_item" in "header_list":
1) Remove leading and trailing WSP characters in "header_item".
2) If the value of "header_item" is character-for-character
identical to "parameter_value", return "1".
4) Return "0".
Fielding & Nottingham Expires September 3, 2016 [Page 11]
Internet-Draft Key March 2016
For example, the Key:
Key: Baz;match="charlie"
Would return "1" for the following header field values:
Baz: charlie
Baz: foo, charlie
Baz: bar, charlie , abc
and "0" for these:
Baz: theodore
Baz: joe, sam
Baz: "charlie"
Baz: Charlie
Baz: cha rlie
Baz: charlie2
2.3.4. substr
The "substr" parameter is used to determine if a value occurs as a
substring of an item in a list of header values. It is case-
sensitive.
Its value's syntax is:
substr = ( token / quoted-string )
To process a set of header fields against a substr parameter, follow
these steps (or their equivalent):
1) If "header_value" is the empty string, return "none".
2) Create "header_list" by splitting "header_value" on ","
characters.
3) For each "header_item" in "header_list":
1) Remove leading and trailing WSP characters in "header_item".
2) If the value of "parameter_value" is character-for-character
present as a substring of "header_value", return "1".
4) Return "0".
For example, the Key:
Fielding & Nottingham Expires September 3, 2016 [Page 12]
Internet-Draft Key March 2016
Key: Abc;substr=bennet
Would return "1" for the following header field values:
Abc: bennet
Abc: foo, bennet
Abc: abennet00
Abc: bar, 99bennet , abc
Abc: "bennet"
and "0" for these:
Abc: theodore
Abc: joe, sam
Abc: Bennet
Abc: Ben net
2.3.5. param
The "param" parameter considers the request header field as a list of
key=value parameters, and uses the nominated key's value as the
secondary cache key.
Its value's syntax is:
param = ( token / quoted-string )
To process a list of header fields against a param parameter, follow
these steps (or their equivalent):
1) Let "header_list" be an empty list.
2) Create "header_list_tmp1" by splitting header_value on ","
characters.
3) For each "header_item_tmp1" in "header_list_tmp1":
1) Create "header_list_tmp2" by splitting "header_item_tmp1" on
";" characters.
2) For each "header_item_tmp2" in "header_list_tmp2":
1) Remove leading and trailing WSP from "header_item_tmp2".
2) Append "header_item_tmp2" to header_list.
4) For each "header_item" in "header_list":
1) If the "=" character does not occur within "header_item",
skip to the next "header_item".
Fielding & Nottingham Expires September 3, 2016 [Page 13]
Internet-Draft Key March 2016
2) Let "item_name" be the string occurring before the first "="
character in "header_item".
3) If "item_name" does not case-insensitively match
"parameter_value", skip to the next "header_item".
4) Return the string occurring after the first "=" character in
"header_item".
5) Return the empty string.
Note that steps 2 and 3 accommodate semicolon-separated values, so
that it can be used with the Cookie request header field.
For example, the Key:
Key: Def;param=liam
The following headers would return the string (surrounded in single
quotes) indicated:
Def: liam=123 // '123'
Def: mno=456 // ''
Def: // ''
Def: abc=123; liam=890 // '890'
Def: liam="678" // '"678"'
3. IANA Considerations
This specification defines the HTTP Key Parameter Registry,
maintained at http://www.iana.org/assignments/http-parameters/http-
parameters.xhtml#key .
3.1. Procedure
Key Parameter registrations MUST include the following fields:
o Parameter Name: [name]
o Reference: [Pointer to specification text]
Values to be added to this namespace require IETF Review (see
Section 4.1 of [RFC5226]) and MUST conform to the purpose of content
coding defined in this section.
3.2. Registrations
This specification makes the following entries in the HTTP Key
Parameter Registry:
Fielding & Nottingham Expires September 3, 2016 [Page 14]
Internet-Draft Key March 2016
+----------------+---------------+
| Parameter Name | Reference |
+----------------+---------------+
| div | Section 2.3.1 |
| partition | Section 2.3.2 |
| match | Section 2.3.3 |
| substr | Section 2.3.4 |
| param | Section 2.3.5 |
+----------------+---------------+
4. Security Considerations
Because Key is an alternative to Vary, it is possible for caches to
behave differently based upon whether they implement Key. Likewise,
because support for any one Key parameter is not required, it is
possible for different implementations of Key to behave differently.
In both cases, an attacker might be able to exploit these
differences.
This risk is mitigated by the requirement to fall back to Vary when
unsupported parameters are encountered, coupled with the requirement
that servers that use Key also include a relevant Vary header.
An attacker with the ability to inject response headers might be able
to perform a cache poisoning attack that tailors a response to a
specific user (e.g., by Keying to a Cookie that's specific to them).
While the attack is still possible without Key, the ability to tailor
is new.
When implemented, Key might result in a larger number of stored
responses for a given resource in caches; this, in turn, might be
used to create an attack upon the cache itself. Good cache
replacement algorithms and denial of service monitoring in cache
implementations are reasonable mitigations against this risk.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<http://www.rfc-editor.org/info/rfc5234>.
Fielding & Nottingham Expires September 3, 2016 [Page 15]
Internet-Draft Key March 2016
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<http://www.rfc-editor.org/info/rfc7231>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>.
5.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<http://www.rfc-editor.org/info/rfc6265>.
Appendix A. Acknowledgements
Thanks to Ilya Grigorik, Amos Jeffries and Yoav Weiss for their
feedback.
Appendix B. Changes
B.1. Since -00
o Issue 108 (field-name cardinality) closed with no action.
o Issue 104 (Support "Or" operator) closed with no action.
o Issue 107 (Whitespace requirement) addressed by allowing
whitespace around parameters.
o Issue 106 (Policy for Key parameter registry) closed with no
action.
Authors' Addresses
Fielding & Nottingham Expires September 3, 2016 [Page 16]
Internet-Draft Key March 2016
Roy T. Fielding
Adobe Systems Incorporated
Email: fielding@gbiv.com
URI: http://roy.gbiv.com/
Mark Nottingham
Email: mnot@mnot.net
URI: https://www.mnot.net/
Fielding & Nottingham Expires September 3, 2016 [Page 17]
