< draft-ietf-httpbis-alt-svc-00.txt   draft-ietf-httpbis-alt-svc-01.txt >
HTTPbis Working Group M. Nottingham HTTPbis Working Group M. Nottingham
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track P. McManus Intended status: Standards Track P. McManus
Expires: September 29, 2014 Mozilla Expires: October 3, 2014 Mozilla
J. Reschke J. Reschke
greenbytes greenbytes
March 28, 2014 April 1, 2014
HTTP Alternative Services HTTP Alternative Services
draft-ietf-httpbis-alt-svc-00 draft-ietf-httpbis-alt-svc-01
Abstract Abstract
This document specifies "alternative services" for HTTP, which allow This document specifies "alternative services" for HTTP, which allow
an origin's resources to be authoritatively available at a separate an origin's resources to be authoritatively available at a separate
network location, possibly accessed with a different protocol network location, possibly accessed with a different protocol
configuration. configuration.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on September 29, 2014. This Internet-Draft will expire on October 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 32 skipping to change at page 2, line 32
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3
2. Alternative Services Concepts . . . . . . . . . . . . . . . . 4 2. Alternative Services Concepts . . . . . . . . . . . . . . . . 4
2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 5 2.1. Host Authentication . . . . . . . . . . . . . . . . . . . 5
2.2. Alternative Service Caching . . . . . . . . . . . . . . . 6 2.2. Alternative Service Caching . . . . . . . . . . . . . . . 6
2.3. Requiring Server Name Indication . . . . . . . . . . . . . 6 2.3. Requiring Server Name Indication . . . . . . . . . . . . . 6
2.4. Using Alternative Services . . . . . . . . . . . . . . . . 6 2.4. Using Alternative Services . . . . . . . . . . . . . . . . 6
3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 7 3. The Alt-Svc HTTP Header Field . . . . . . . . . . . . . . . . 7
3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 8 3.1. Caching Alt-Svc Header Field Values . . . . . . . . . . . 8
4. The Service HTTP Header Field . . . . . . . . . . . . . . . . 9 4. The Service HTTP Header Field . . . . . . . . . . . . . . . . 9
5. The 4NN Not Authoritative HTTP Status Code . . . . . . . . . . 9 5. The 421 Not Authoritative HTTP Status Code . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6.1. The Alt-Svc Message Header Field . . . . . . . . . . . . . 10 6.1. The Alt-Svc Message Header Field . . . . . . . . . . . . . 10
6.2. The Service Message Header Field . . . . . . . . . . . . . 10 6.2. The Service Message Header Field . . . . . . . . . . . . . 10
6.3. The 4NN Not Authoritative HTTP Status Code . . . . . . . . 10 6.3. The 421 Not Authoritative HTTP Status Code . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Changing Ports . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Changing Hosts . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 12 7.3. Changing Protocols . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Change Log (to be removed by RFC Editor before Appendix A. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 14 publication) . . . . . . . . . . . . . . . . . . . . 14
A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 14 A.1. Since draft-nottingham-httpbis-alt-svc-05 . . . . . . . . 14
A.2. Since draft-ietf-httpbis-alt-svc-00 . . . . . . . . . . . 14
1. Introduction 1. Introduction
HTTP [HTTP-p1] conflates the identification of resources with their HTTP [HTTP-p1] conflates the identification of resources with their
location. In other words, "http://" (and "https://") URLs are used location. In other words, "http://" (and "https://") URLs are used
to both name and find things to interact with. to both name and find things to interact with.
In some cases, it is desirable to separate these aspects; to be able In some cases, it is desirable to separate these aspects; to be able
to keep the same identifier for a resource, but interact with it to keep the same identifier for a resource, but interact with it
using a different location on the network. using a different location on the network.
For example: For example:
o An origin server might wish to redirect a client to an alternative o An origin server might wish to redirect a client to an alternative
when it needs to go down for maintenance, or it has found an when it needs to go down for maintenance, or it has found an
alternative in a location that is more local to the client. alternative in a location that is more local to the client.
o An origin server might wish to offer access to its resources using o An origin server might wish to offer access to its resources using
a new protocol (such as HTTP/2, see [HTTP2]) or one using improved a new protocol (such as HTTP/2, see [HTTP2]) or one using improved
security (such as TLS, see [RFC5246]). security (such as Transport Layer Security (TLS), see [RFC5246]).
o An origin server might wish to segment its clients into groups of o An origin server might wish to segment its clients into groups of
capabilities, such as those supporting Server Name Indication capabilities, such as those supporting Server Name Indication
(SNI, see Section 3 of [RFC6066]) and those not supporting it, for (SNI, see Section 3 of [RFC6066]) and those not supporting it, for
operational purposes. operational purposes.
This specification defines a new concept in HTTP, "Alternative This specification defines a new concept in HTTP, "Alternative
Services", that allows a resource to nominate additional means of Services", that allows a resource to nominate additional means of
interacting with it on the network. It defines a general framework interacting with it on the network. It defines a general framework
for this in Section 2, along with a specific mechanism for for this in Section 2, along with a specific mechanism for
skipping to change at page 3, line 48 skipping to change at page 3, line 48
not authoritative for a given origin, in cases where the wrong not authoritative for a given origin, in cases where the wrong
location is used. location is used.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
This document uses the Augmented BNF defined in [RFC5234] along with This document uses the Augmented BNF defined in [RFC5234] along with
the "OWS", "DIGIT", "DQUOTE", "parameter", "uri-host", "port" and the "OWS", "delta-seconds", "parameter", "port", "token", and "uri-
"delta-second" rules from [HTTP-p1], and uses the "#rule" extension host" rules from [HTTP-p1], and uses the "#rule" extension defined in
defined in Section 7 of that document. Section 7 of that document.
2. Alternative Services Concepts 2. Alternative Services Concepts
This specification defines a new concept in HTTP, the "alternative This specification defines a new concept in HTTP, the "alternative
service". When an origin (see [RFC6454]) has resources that are service". When an origin (see [RFC6454]) has resources that are
accessible through a different protocol / host / port combination, it accessible through a different protocol / host / port combination, it
is said to have an alternative service. is said to have an alternative service.
An alternative service can be used to interact with the resources on An alternative service can be used to interact with the resources on
an origin server at a separate location on the network, possibly an origin server at a separate location on the network, possibly
skipping to change at page 4, line 37 skipping to change at page 4, line 37
By their nature, alternative services are explicitly at the By their nature, alternative services are explicitly at the
granularity of an origin; i.e., they cannot be selectively applied to granularity of an origin; i.e., they cannot be selectively applied to
resources within an origin. resources within an origin.
Alternative services do not replace or change the origin for any Alternative services do not replace or change the origin for any
given resource; in general, they are not visible to the software given resource; in general, they are not visible to the software
"above" the access mechanism. The alternative service is essentially "above" the access mechanism. The alternative service is essentially
alternative routing information that can also be used to reach the alternative routing information that can also be used to reach the
origin in the same way that DNS CNAME or SRV records define routing origin in the same way that DNS CNAME or SRV records define routing
information at the name resolution level. Each origin maps to a set information at the name resolution level. Each origin maps to a set
of these routes - the default route is derived from origin itself and of these routes -- the default route is derived from origin itself
the other routes are introduced based on alternative-protocol and the other routes are introduced based on alternative-protocol
information. information.
Furthermore, it is important to note that the first member of an Furthermore, it is important to note that the first member of an
alternative service tuple is different from the "scheme" component of alternative service tuple is different from the "scheme" component of
an origin; it is more specific, identifying not only the major an origin; it is more specific, identifying not only the major
version of the protocol being used, but potentially communication version of the protocol being used, but potentially communication
options for that protocol. options for that protocol.
This means that clients using an alternative service will change the This means that clients using an alternative service will change the
host, port and protocol that they are using to fetch resources, but host, port and protocol that they are using to fetch resources, but
skipping to change at page 5, line 17 skipping to change at page 5, line 17
a certificate for the origin's host name, not that of the a certificate for the origin's host name, not that of the
alternative. Likewise, the Host header field is still derived from alternative. Likewise, the Host header field is still derived from
the origin, not the alternative service (just as it would if a CNAME the origin, not the alternative service (just as it would if a CNAME
were being used). were being used).
The changes MAY, however, be made visible in debugging tools, The changes MAY, however, be made visible in debugging tools,
consoles, etc. consoles, etc.
Formally, an alternative service is identified by the combination of: Formally, an alternative service is identified by the combination of:
o An ALPN protocol, as per [I-D.ietf-tls-applayerprotoneg] o An Application Layer Protocol Negotiation (ALPN) protocol, as per
[I-D.ietf-tls-applayerprotoneg]
o A host, as per [RFC3986] o A host, as per [RFC3986], Section 3.2.2
o A port, as per [RFC3986] o A port, as per [RFC3986], Section 3.2.3
Additionally, each alternative service MUST have: Additionally, each alternative service MUST have:
o A freshness lifetime, expressed in seconds; see Section 2.2 o A freshness lifetime, expressed in seconds; see Section 2.2
There are many ways that a client could discover the alternative There are many ways that a client could discover the alternative
service(s) associated with an origin. service(s) associated with an origin.
2.1. Host Authentication 2.1. Host Authentication
skipping to change at page 6, line 31 skipping to change at page 6, line 31
To mitigate risks associated with caching compromised values (see To mitigate risks associated with caching compromised values (see
Section 7.2 for details), user agents SHOULD examine cached Section 7.2 for details), user agents SHOULD examine cached
alternative services when they detect a change in network alternative services when they detect a change in network
configuration, and remove any that could be compromised (for example, configuration, and remove any that could be compromised (for example,
those whose association with the trust root is questionable). UAs those whose association with the trust root is questionable). UAs
that do not have a means of detecting network changes SHOULD place an that do not have a means of detecting network changes SHOULD place an
upper bound on their lifetime. upper bound on their lifetime.
2.3. Requiring Server Name Indication 2.3. Requiring Server Name Indication
A client must only use a TLS-based alternative service if the client A client MUST only use a TLS-based alternative service if the client
also supports TLS Server Name Indication (SNI) ([RFC6066], Section also supports TLS Server Name Indication (SNI) ([RFC6066], Section
3). This supports the conservation of IP addresses on the 3). This supports the conservation of IP addresses on the
alternative service host. alternative service host.
2.4. Using Alternative Services 2.4. Using Alternative Services
By their nature, alternative services are optional; clients are not By their nature, alternative services are optional; clients are not
required to use them. However, it is advantageous for clients to required to use them. However, it is advantageous for clients to
behave in a predictable way when they are used by servers (e.g., for behave in a predictable way when they are used by servers (e.g., for
load balancing). load balancing).
skipping to change at page 7, line 20 skipping to change at page 7, line 20
information leakage. information leakage.
Furthermore, if the connection to the alternative service fails or is Furthermore, if the connection to the alternative service fails or is
unresponsive, the client MAY fall back to using the origin. Note, unresponsive, the client MAY fall back to using the origin. Note,
however, that this could be the basis of a downgrade attack, thus however, that this could be the basis of a downgrade attack, thus
losing any enhanced security properties of the alternative service. losing any enhanced security properties of the alternative service.
3. The Alt-Svc HTTP Header Field 3. The Alt-Svc HTTP Header Field
An HTTP(S) origin server can advertise the availability of An HTTP(S) origin server can advertise the availability of
alternative services (see Section 2) to clients by adding an Alt-Svc alternative services to clients by adding an Alt-Svc header field to
header field to responses. responses.
Alt-Svc = 1#( alternative *( OWS ";" OWS parameter ) ) Alt-Svc = 1#( alternative *( OWS ";" OWS parameter ) )
alternative = DQUOTE protocol-id DQUOTE "=" port alternative = protocol-id "=" port
protocol-id = <ALPN protocol identifier> protocol-id = token ; percent-encoded ALPN protocol identifier
ALPN protocol names are octet sequences with no additional
constraints on format. Octets not allowed in tokens ([HTTP-p1],
Section 3.2.6) MUST be percent-encoded as per Section 2.1 of
[RFC3986]. Consequently, the octet representing the percent
character "%" (hex 25) MUST be percent-encoded as well.
In order to have precisely one way to represent any ALPN protocol
name, the following additional constraints apply:
1. Octets in the ALPN protocol MUST NOT be percent-encoded if they
are valid token characters except "%", and
2. When using percent-encoding, uppercase hex digits MUST be used.
With these constraints, recipients can apply simple string comparison
to match protocol identifiers.
For example: For example:
Alt-Svc: "http2"=8000 Alt-Svc: http2=8000
This indicates that the "http2" protocol on the same host using the This indicates that the "http2" protocol on the same host using the
indicated port (in this case, 8000). indicated port (in this case, 8000).
Examples for protocol name escaping:
+--------------------+-------------+---------------------+
| ALPN protocol name | protocol-id | Note |
+--------------------+-------------+---------------------+
| http2 | http2 | No escaping needed |
+--------------------+-------------+---------------------+
| w=x:y#z | w%3Dx%3Ay#z | "=" and ":" escaped |
+--------------------+-------------+---------------------+
| x%y | x%25y | "%" needs escaping |
+--------------------+-------------+---------------------+
Alt-Svc MAY occur in any HTTP response message, regardless of the Alt-Svc MAY occur in any HTTP response message, regardless of the
status code. status code.
Alt-Svc does not allow advertisement of alternative services on other Alt-Svc does not allow advertisement of alternative services on other
hosts, to protect against various header-based attacks. hosts, to protect against various header-based attacks.
It can, however, have multiple values: It can, however, have multiple values:
Alt-Svc: "h2c"=8000, "h2"=443 Alt-Svc: h2c=8000, h2=443
The value(s) advertised by Alt-Svc can be used by clients to open a The value(s) advertised by Alt-Svc can be used by clients to open a
new connection to one or more alternative services immediately, or new connection to one or more alternative services immediately, or
simultaneously with subsequent requests on the same connection. simultaneously with subsequent requests on the same connection.
Intermediaries MUST NOT change or append Alt-Svc values. Intermediaries MUST NOT change or append Alt-Svc field values.
Finally, note that while it may be technically possible to put
content other than printable ASCII in a HTTP header field, some
implementations only support ASCII (or a superset of it) in header
field values. Therefore, this field SHOULD NOT be used to convey
protocol identifiers that are not printable ASCII, or those that
contain quote characters.
[[syntax: The header field syntax is both misleading (use of double
quotes although not a quoted string) and incomplete (does not support
all values). Alternate proposal in <http://lists.w3.org/Archives/
Public/ietf-http-wg/2014JanMar/0856.html>.]]
3.1. Caching Alt-Svc Header Field Values 3.1. Caching Alt-Svc Header Field Values
When an alternative service is advertised using Alt-Svc, it is When an alternative service is advertised using Alt-Svc, it is
considered fresh for 24 hours from generation of the message. This considered fresh for 24 hours from generation of the message. This
can be modified with the 'ma' (max-age) parameter; can be modified with the 'ma' (max-age) parameter;
Alt-Svc: "h2"=443;ma=3600 Alt-Svc: h2=443;ma=3600
which indicates the number of seconds since the response was which indicates the number of seconds since the response was
generated the alternative service is considered fresh for. generated the alternative service is considered fresh for.
ma = delta-seconds ma = delta-seconds
See Section 4.2.3 of [HTTP-p6] for details of determining response See Section 4.2.3 of [HTTP-p6] for details of determining response
age. age.
For example, a response: For example, a response:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: text/html Content-Type: text/html
Cache-Control: 600 Cache-Control: 600
Age: 30 Age: 30
Alt-Svc: "h2c"=8000; ma=60 Alt-Svc: h2c=8000; ma=60
indicates that an alternative service is available and usable for the indicates that an alternative service is available and usable for the
next 60 seconds. However, the response has already been cached for next 60 seconds. However, the response has already been cached for
30 seconds (as per the Age header field value), so therefore the 30 seconds (as per the Age header field value), so therefore the
alternative service is only fresh for the 30 seconds from when this alternative service is only fresh for the 30 seconds from when this
response was received, minus estimated transit time. response was received, minus estimated transit time.
When an Alt-Svc response header field is received from an origin, its When an Alt-Svc response header field is received from an origin, its
value invalidates and replaces all cached alternative services for value invalidates and replaces all cached alternative services for
that origin. that origin.
skipping to change at page 9, line 29 skipping to change at page 10, line 5
When using an Alternate Service, clients MUST include a Service When using an Alternate Service, clients MUST include a Service
header in all requests. header in all requests.
For example: For example:
GET /thing GET /thing
Host: origin.example.com Host: origin.example.com
Service: alternate.example.net Service: alternate.example.net
User-Agent: Example/1.0 User-Agent: Example/1.0
5. The 4NN Not Authoritative HTTP Status Code 5. The 421 Not Authoritative HTTP Status Code
The 4NN (Not Authoritative) status code indicates that the current The 421 (Not Authoritative) status code indicates that the current
origin server (usually, but not always an alternative service; see origin server (usually, but not always an alternative service; see
Section 2) is not authoritative for the requested resource, in the Section 2) is not authoritative for the requested resource, in the
sense of [HTTP-p1], Section 9.1. sense of [HTTP-p1], Section 9.1.
Clients receiving 4NN (Not Authoritative) from an alternative service Clients receiving 421 (Not Authoritative) from an alternative service
MUST remove the corresponding entry from its alternative service MUST remove the corresponding entry from its alternative service
cache (see Section 2.2) for that origin. Regardless of the cache (see Section 2.2) for that origin. Regardless of the
idempotency of the request method, they MAY retry the request, either idempotency of the request method, they MAY retry the request, either
at another alternative server, or at the origin. at another alternative server, or at the origin.
4NN (Not Authoritative) MAY carry an Alt-Svc header field. 421 (Not Authoritative) MAY carry an Alt-Svc header field.
This status code MUST NOT be generated by proxies. This status code MUST NOT be generated by proxies.
A 4NN response is cacheable by default; i.e., unless otherwise A 421 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [HTTP-p6]). Section 4.2.2 of [HTTP-p6]).
[[code: We should decide on the status code before Last Call.]] [[apr: This really ought to be 420.]]
6. IANA Considerations 6. IANA Considerations
6.1. The Alt-Svc Message Header Field 6.1. The Alt-Svc Message Header Field
This document registers Alt-Svc in the Permanent Message Header This document registers Alt-Svc in the Permanent Message Header
Registry [RFC3864]. Registry [RFC3864].
o Header Field Name: Alt-Svc o Header Field Name: Alt-Svc
skipping to change at page 10, line 41 skipping to change at page 11, line 17
o Application Protocol: http o Application Protocol: http
o Status: standard o Status: standard
o Author/Change Controller: IETF o Author/Change Controller: IETF
o Specification Document: [this document] o Specification Document: [this document]
o Related Information: o Related Information:
6.3. The 4NN Not Authoritative HTTP Status Code 6.3. The 421 Not Authoritative HTTP Status Code
This document registers the 4NN (Not Authoritative) HTTP Status code This document registers the 421 (Not Authoritative) HTTP Status code
in the Hypertext Transfer Protocol (HTTP) Status Code Registry
([HTTP-p2], Section 8.2). ([HTTP-p2], Section 8.2).
o Status Code: 4NN Status Code: 421
o Short Description: Not Authoritative Short Description: Not Authoritative
o Specification: [this document], Section 5 Specification: Section 5 of this document
7. Security Considerations 7. Security Considerations
Identified security considerations should be enumerated in the [[anchor1: Identified security considerations should be enumerated in
appropriate documents depending on which proposals are accepted. the appropriate documents depending on which proposals are accepted.
Those listed below are generic to all uses of alternative services; Those listed below are generic to all uses of alternative services;
more specific ones might be necessary. more specific ones might be necessary.]]
7.1. Changing Ports 7.1. Changing Ports
Using an alternative service implies accessing an origin's resources Using an alternative service implies accessing an origin's resources
on an alternative port, at a minimum. An attacker that can inject on an alternative port, at a minimum. An attacker that can inject
alternative services and listen at the advertised port is therefore alternative services and listen at the advertised port is therefore
able to hijack an origin. able to hijack an origin.
For example, an attacker that can add HTTP response header fields can For example, an attacker that can add HTTP response header fields can
redirect traffic to a different port on the same host using the Alt- redirect traffic to a different port on the same host using the Alt-
skipping to change at page 14, line 23 skipping to change at page 14, line 47
August 2008. August 2008.
Appendix A. Change Log (to be removed by RFC Editor before publication) Appendix A. Change Log (to be removed by RFC Editor before publication)
A.1. Since draft-nottingham-httpbis-alt-svc-05 A.1. Since draft-nottingham-httpbis-alt-svc-05
This is the first version after adoption of This is the first version after adoption of
draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It draft-nottingham-httpbis-alt-svc-05 as Working Group work item. It
only contains editorial changes. only contains editorial changes.
A.2. Since draft-ietf-httpbis-alt-svc-00
Selected 421 as proposed status code for "Not Authoritative".
Changed header field syntax to use percent-encoding of ALPN protocol
names (<https://github.com/http2/http2-spec/issues/446>).
Authors' Addresses Authors' Addresses
Mark Nottingham Mark Nottingham
Akamai Akamai
EMail: mnot@mnot.net EMail: mnot@mnot.net
URI: http://www.mnot.net/ URI: http://www.mnot.net/
Patrick McManus Patrick McManus
Mozilla Mozilla
 End of changes. 38 change blocks. 
56 lines changed or deleted 83 lines changed or added

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