draft-ietf-capport-api-05.txt   draft-ietf-capport-api-06.txt 
Captive Portal Interaction T. Pauly, Ed. Captive Portal Interaction T. Pauly, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Standards Track D. Thakore, Ed. Intended status: Standards Track D. Thakore, Ed.
Expires: 7 August 2020 CableLabs Expires: 2 October 2020 CableLabs
4 February 2020 31 March 2020
Captive Portal API Captive Portal API
draft-ietf-capport-api-05 draft-ietf-capport-api-06
Abstract Abstract
This document describes an HTTP API that allows clients to interact This document describes an HTTP API that allows clients to interact
with a Captive Portal system. with a Captive Portal system. With this API, clients can discover
how to get out of captivity and fetch state about their Captive
Portal sessions.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 7 August 2020. This Internet-Draft will expire on 2 October 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Workflow . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. API Details . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. API Connection Details . . . . . . . . . . . . . . . . . . . 3
4.1. URI of Captive Portal API endpoint . . . . . . . . . . . 3 4.1. Server Authentication . . . . . . . . . . . . . . . . . . 4
4.1.1. Server Authentication . . . . . . . . . . . . . . . . 4 5. API State Structure . . . . . . . . . . . . . . . . . . . . . 5
4.2. JSON Keys . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Example Interaction . . . . . . . . . . . . . . . . . . . . . 6
4.3. Example Interaction . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7.1. Privacy Considerations . . . . . . . . . . . . . . . . . 7
5.1. Privacy Considerations . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8.1. Captive Portal API JSON Media Type Registration . . . . . 7
6.1. Captive Portal API JSON Media Type Registration . . . . . 7 8.2. Captive Portal API Keys Registry . . . . . . . . . . . . 8
6.2. Captive Portal API Keys Registry . . . . . . . . . . . . 8 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
8.1. Normative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
This document describes a HyperText Transfer Protocol (HTTP) This document describes a HyperText Transfer Protocol (HTTP)
Application Program Interface (API) that allows clients to interact Application Program Interface (API) that allows clients to interact
with a Captive Portal system. The API defined in this document has with a Captive Portal system. The API defined in this document has
been designed to meet the requirements in the Captive Portal been designed to meet the requirements in the Captive Portal
Architecture [I-D.ietf-capport-architecture]. Specifically, the API Architecture [I-D.ietf-capport-architecture]. Specifically, the API
provides: provides:
* The state of captivity (whether or not the client has access to * The state of captivity (whether or not the client has access to
the Internet) the Internet)
* A URI that a client browser can present to a user to get out of * A URI that a client browser can present to a user to get out of
captivity captivity
* An encrypted connection (TLS for both the API and portal URI) * An encrypted connection (using TLS for connections to both the API
and user portal)
2. Terminology 2. Terminology
This document leverages the terminology and components described in This document leverages the terminology and components described in
[I-D.ietf-capport-architecture] and additionally uses the following [I-D.ietf-capport-architecture] and additionally defines the
association: following terms:
* Captive Portal Client: The client that interacts with the Captive * Captive Portal Client: The client that interacts with the Captive
Portal API is typically some application running on the User Portal API is typically some application running on the User
Equipment that is connected to the Captive Network. This is also Equipment that is connected to the Captive Network. This is also
referred to as the "client" in this document. referred to as the "client" in this document.
* Captive Portal API Server: The server exposing the API's defined * Captive Portal API Server: The server exposing the API's defined
in this document to the client. This is also referred to as the in this document to the client. This is also referred to as the
"API server" in this document. "API server" in this document.
skipping to change at page 3, line 26 skipping to change at page 3, line 26
2. API Server interaction, in which a client queries the state of 2. API Server interaction, in which a client queries the state of
the captive portal and retrieves the necessary information to get the captive portal and retrieves the necessary information to get
out of captivity. out of captivity.
3. Enforcement, in which the enforcement device in the network 3. Enforcement, in which the enforcement device in the network
blocks disallowed traffic. blocks disallowed traffic.
This document defines the mechanisms used in the second category. It This document defines the mechanisms used in the second category. It
is assumed that the location of the Captive Portal API server has is assumed that the location of the Captive Portal API server has
been discovered by the client as part of Provisioning. The mechanism been discovered by the client as part of Provisioning. A set of
for discovering the API Server endpoint is not covered by this mechanisms for discovering the API Server endpoint is defined in
document. [I-D.ietf-capport-rfc7710bis].
4. API Details
4.1. URI of Captive Portal API endpoint 4. API Connection Details
The URI of the API endpoint MUST be accessed using HTTP over TLS The API server endpoint MUST be accessed using HTTP over TLS (HTTPS)
(HTTPS) and SHOULD be served on port 443 [RFC2818]. The client and SHOULD be served on port 443 [RFC2818]. The client SHOULD NOT
SHOULD NOT assume that the URI for a given network attachment will assume that the URI for a given network attachment will stay the
stay the same, and SHOULD rely on the discovery or provisioning same, and SHOULD rely on the discovery or provisioning process each
process each time it joins the network. Depending on how the Captive time it joins the network.
Portal system is configured, the URI might be unique for each client
host and between sessions for the same client host.
For example, if the Captive Portal API server is hosted at For example, if the Captive Portal API server is hosted at
example.org, the URI's of the API could be: "example.org", the URI of the API could be "https://example.org/
captive-portal/api"
* "https://example.org/captive-portal/api" As described in Section 3 of [I-D.ietf-capport-architecture], the
identity of the client needs to be visible to the Captive Portal API
server in order for the server to correctly reply with the client's
portal state. If the identifier used by the Captive Portal system is
the client's IP address, the system needs to ensure that the same IP
address is visible to both the API server and the enforcement device.
* "https://example.org/captive-portal/api/X54PD" If the API server needs information about the client identity that is
not otherwise visible to it, the URI provided to the client during
provisioning can be distinct per client. Thus, depending on how the
Captive Portal system is configured, the URI might be unique for each
client host and between sessions for the same client host.
4.1.1. Server Authentication For example, a Captive Portal system that uses per-client session
URIs could use "https://example.org/captive-portal/api/X54PD" as its
API URI.
4.1. Server Authentication
The purpose of accessing the Captive Portal API over an HTTPS The purpose of accessing the Captive Portal API over an HTTPS
connection is twofold: first, the encrypted connection protects the connection is twofold: first, the encrypted connection protects the
integrity and confidentiality of the API exchange from other parties integrity and confidentiality of the API exchange from other parties
on the local network; and second, it provides the client of the API on the local network; and second, it provides the client of the API
an opportunity to authenticate the server that is hosting the API. an opportunity to authenticate the server that is hosting the API.
This authentication is aimed at allowing a user to be reasonably This authentication is aimed at allowing a user to be reasonably
confident that the entity providing the Captive Portal API has a confident that the entity providing the Captive Portal API has a
valid certificate for the hostname in the URI (such as valid certificate for the hostname in the URI (such as
"example.com"). The hostname of the API SHOULD be displayed to the "example.com"). The hostname of the API SHOULD be displayed to the
skipping to change at page 4, line 37 skipping to change at page 4, line 43
that are referenced by certificates provided by the API server. In that are referenced by certificates provided by the API server. In
addition to connections to OCSP responders and CRLs, a captive addition to connections to OCSP responders and CRLs, a captive
network SHOULD also permit connections to Network Time Protocol (NTP) network SHOULD also permit connections to Network Time Protocol (NTP)
[RFC5905] servers or other time-sync mechnisms to allow clients to [RFC5905] servers or other time-sync mechnisms to allow clients to
accurately validate certificates. accurately validate certificates.
Certificates with missing intermediate certificates that rely on Certificates with missing intermediate certificates that rely on
clients validating the certificate chain using the URI specified in clients validating the certificate chain using the URI specified in
the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT the Authority Information Access (AIA) extension [RFC5280] SHOULD NOT
be used by the Captive Portal API server. If the certificates do be used by the Captive Portal API server. If the certificates do
require the use of AIA, the captive network will need to allow client require the use of AIA, the captive network MUST allow client access
access to the host specified in the URI. to the host specified in the URI.
If the client is unable to validate the certificate presented by the If the client is unable to validate the certificate presented by the
API server, it MUST NOT proceed with any of the behavior for API API server, it MUST NOT proceed with any of the behavior for API
interaction described in this document. The client will proceed to interaction described in this document. The client will proceed to
interact with the captive network as if the API capabilities were not interact with the captive network as if the API capabilities were not
present. It may still be possible for the user to access the network present. It may still be possible for the user to access the network
by being redirected to a web portal. by being redirected to a web portal.
4.2. JSON Keys 5. API State Structure
The Captive Portal API data structures are specified in JavaScript The Captive Portal API data structures are specified in JavaScript
Object Notation (JSON) [RFC8259]. Requests and responses for the Object Notation (JSON) [RFC8259]. Requests and responses for the
Captive Portal API use the "application/captive+json" media type. Captive Portal API use the "application/captive+json" media type.
Clients SHOULD include this media type as an Accept header in their Clients SHOULD include this media type as an Accept header in their
GET requests, and servers MUST mark this media type as their Content- GET requests, and servers MUST mark this media type as their Content-
Type header in responses. Type header in responses.
The following keys are defined at the top-level of the JSON structure The following key MUST be included in the top-level of the JSON
returned by the API server: structure returned by the API server:
* "captive" (required, boolean): indicates whether the client is in * "captive" (boolean): indicates whether the client is in a state of
a state of captivity, i.e it has not satisfied the conditions to captivity, i.e it has not satisfied the conditions to access the
access the external network. If the client is captive (i.e. external network. If the client is captive (i.e. captive=true),
captive=true), it can still be allowed enough access for it to it can still be allowed enough access for it to perform server
perform server authentication Section 4.1.1. authentication Section 4.1.
* "user-portal-url" (optional, string): provides the URL of a web The following keys can be optionally included in the top-level of the
portal with which a user can interact. JSON structure returned by the API server:
* "venue-info-url" (optional, string): provides the URL of a webpage * "user-portal-url" (string): provides the URL of a web portal with
or site on which the operator of the network has information that which a user can interact.
it wishes to share with the user (e.g., store info, maps, flight
* "venue-info-url" (string): provides the URL of a webpage or site
on which the operator of the network has information that it
wishes to share with the user (e.g., store info, maps, flight
status, or entertainment). status, or entertainment).
* "can-extend-session" (optional, boolean): indicates that the URL * "can-extend-session" (boolean): indicates that the URL specified
specified as "user-portal-url" allows the user to extend a session as "user-portal-url" allows the user to extend a session once the
once the client is no longer in a state of captivity. This client is no longer in a state of captivity. This provides a hint
provides a hint that a client system can suggest accessing the that a client system can suggest accessing the portal URL to the
portal URL to the user when the session is near its limit in terms user when the session is near its limit in terms of time or bytes.
of time or bytes.
* "seconds-remaining" (optional, integer): indicates the number of * "seconds-remaining" (integer): indicates the number of seconds
seconds remaining, after which the client will be placed into a remaining, after which the client will be placed into a captive
captive state. The API server SHOULD include this value if the state. The API server SHOULD include this value if the client is
client is not captive (i.e. captive=false) and SHOULD omit this not captive (i.e. captive=false) and the client session is time-
value for captive clients. limited, and SHOULD omit this value for captive clients (i.e.
captive=true).
* "bytes-remaining" (optional, integer): indicates the number of * "bytes-remaining" (integer): indicates the number of bytes
bytes remaining, after which the client will be in placed into a remaining, after which the client will be in placed into a captive
captive state. The byte count represents the total number of IP state. The byte count represents the sum of the total number of
packet (layer 3) bytes sent and received by the client. Captive IP packet (layer 3) bytes sent and received by the client.
portal systems might not count traffic to whitelisted servers, Captive portal systems might not count traffic to whitelisted
such as the API server, but clients cannot rely on such behavior. servers, such as the API server, but clients cannot rely on such
behavior. The API server SHOULD include this value if the client
is not captive (i.e. captive=false) and the client session is
byte-limited, and SHOULD omit this value for captive clients (i.e.
captive=true).
The valid JSON keys can be extended by adding entries to the Captive The valid JSON keys can be extended by adding entries to the Captive
Portal API Keys Registry Section 6. If a client receives a key that Portal API Keys Registry Section 8. If a client receives a key that
it does not recognize, it MUST ignore the key and any associated it does not recognize, it MUST ignore the key and any associated
values. All keys other than the ones defined in this document as values. All keys other than the ones defined in this document as
"required" will be considered optional. "required" will be considered optional.
4.3. Example Interaction 6. Example Interaction
A client connected to a captive network upon discovering the URI of A client connected to a captive network upon discovering the URI of
the API server will query the API server to retrieve information the API server will query the API server to retrieve information
about its captive state and conditions to escape captivity. To about its captive state and conditions to escape captivity. To
request the Captive Portal JSON content, a client sends an HTTP GET request the Captive Portal JSON content, a client sends an HTTP GET
request: request:
GET /captive-portal/api/X54PD GET /captive-portal/api/X54PD
Host: example.org Host: example.org
Accept: application/captive+json Accept: application/captive+json
skipping to change at page 6, line 42 skipping to change at page 6, line 49
"can-extend-session": true "can-extend-session": true
} }
Upon receiving this information the client will provide this Upon receiving this information the client will provide this
information to the user so that they may navigate the web portal (as information to the user so that they may navigate the web portal (as
specified by the user-portal-url value) to enable access to the specified by the user-portal-url value) to enable access to the
external network. Once the user satisfies the requirements for external network. Once the user satisfies the requirements for
extenal network access, the client SHOULD query the API server again extenal network access, the client SHOULD query the API server again
to verify that it is no longer captive. to verify that it is no longer captive.
5. Security Considerations Captive Portal JSON content can contain per-client data that is not
appropriate to store in an intermediary cache. Captive Portal API
servers SHOULD set the Cache-Control header in any responses to
"private", or a more restrictive value [RFC7234].
7. Security Considerations
One of the goals of this protocol is to improve the security of the One of the goals of this protocol is to improve the security of the
communication between client hosts and Captive Portal systems. communication between client hosts and Captive Portal systems.
Client traffic is protected from passive listeners on the local Client traffic is protected from passive listeners on the local
network by requiring TLS-encrypted connections between the client and network by requiring TLS-encrypted connections between the client and
the Captive Portal API server, as described in Section 4. All the Captive Portal API server, as described in Section 4. All
communication between the clients and the API server MUST be communication between the clients and the API server MUST be
encrypted. encrypted.
In addition to encrypting communications between clients and Captive In addition to encrypting communications between clients and Captive
Portal systems, this protocol requires a basic level of Portal systems, this protocol requires a basic level of
authentication from the API server, as described in Section 4.1.1. authentication from the API server, as described in Section 4.1.
Specifically, the API server MUST present a valid certificate on Specifically, the API server MUST present a valid certificate on
which the client can perform revocation checks. This allows the which the client can perform revocation checks. This allows the
client to ensure that the API server has authority for a hostname client to ensure that the API server has authority for a hostname
that can be presented to a user. that can be presented to a user.
It is important to note that while the server authentication checks It is important to note that while the server authentication checks
can validate a specific hostname, it is certainly possible for the can validate a specific hostname, it is certainly possible for the
API server to present a valid certificate for a hostname that uses API server to present a valid certificate for a hostname that uses
non-standard characters or is otherwise designed to trick the user non-standard characters or is otherwise designed to trick the user
into believing that its hostname is some other, more trustworthy, into believing that its hostname is some other, more trustworthy,
name. This is a danger of any scenario in which a hostname is not name. This is a danger of any scenario in which a hostname is not
typed in by a user. typed in by a user.
5.1. Privacy Considerations 7.1. Privacy Considerations
Information passed in this protocol may include a user's personal Information passed between a client and a Captive Portal system may
information, such as a full name and credit card details. Therefore, include a user's personal information, such as a full name and credit
it is important that Captive Portal API Servers do not allow access card details. Therefore, it is important that Captive Portal API
to the Captive Portal API over unencrypted sessions. Servers do not allow access to the Captive Portal API over
unencrypted sessions.
6. IANA Considerations 8. IANA Considerations
IANA is requested to create a registration for an "application/ IANA is requested to create a registration for an "application/
captive+json" media type (Section 6.1) and a registry for fields in captive+json" media type (Section 8.1) and a registry for fields in
that format (Section 6.2). that format (Section 8.2).
6.1. Captive Portal API JSON Media Type Registration 8.1. Captive Portal API JSON Media Type Registration
This document registers the media type for Captive Portal API JSON This document registers the media type for Captive Portal API JSON
text, "application/captive+json". text, "application/captive+json".
Type name: application Type name: application
Subtype name: captive+json Subtype name: captive+json
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: Encoding considerations are identical to Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. those specified for the "application/json" media type.
Security considerations: See Section 5 Security considerations: See Section 7
Interoperability considerations: This document specifies format of Interoperability considerations: This document specifies format of
conforming messages and the interpretation thereof. conforming messages and the interpretation thereof.
Published specification: This document Published specification: This document
Applications that use this media type: This media type is intended Applications that use this media type: This media type is intended
to be used by servers presenting the Captive Portal API, and to be used by servers presenting the Captive Portal API, and
clients connecting to such captive networks. clients connecting to such captive networks.
Additional information: None Additional information: None
skipping to change at page 8, line 26 skipping to change at page 8, line 40
Authors' Addresses section. Authors' Addresses section.
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: CAPPORT IETF WG Author: CAPPORT IETF WG
Change controller: IETF Change controller: IETF
6.2. Captive Portal API Keys Registry 8.2. Captive Portal API Keys Registry
IANA is asked to create and maintain a new registry called "Captive IANA is asked to create and maintain a new registry called "Captive
Portal API Keys", which will reserve JSON keys for use in Captive Portal API Keys", which will reserve JSON keys for use in Captive
Portal API data structures. The initial contents of this registry Portal API data structures. The initial contents of this registry
are provided in Section 4.2. are provided in Section 5.
Each entry in the registry contains the following fields: Each entry in the registry contains the following fields:
Key: The JSON key being registered, in string format. Key: The JSON key being registered, in string format.
Type: The type of the JSON value to be stored, as one of the value Type: The type of the JSON value to be stored, as one of the value
types defined in [RFC8259]. types defined in [RFC8259].
Description: A brief description explaining the meaning of the Description: A brief description explaining the meaning of the
value, how it might be used, and/or how it should be interpreted value, how it might be used, and/or how it should be interpreted
skipping to change at page 9, line 7 skipping to change at page 9, line 19
New assignments for Captive Portal API Keys Registry will be New assignments for Captive Portal API Keys Registry will be
administered by IANA through Expert Review [RFC8126]. The Designated administered by IANA through Expert Review [RFC8126]. The Designated
Expert is expected to validate the existence of documentation Expert is expected to validate the existence of documentation
describing new keys in a permanent publicly available specification. describing new keys in a permanent publicly available specification.
The expert is expected to validate that new keys have a clear meaning The expert is expected to validate that new keys have a clear meaning
and do not create unnecessary confusion or overlap with existing and do not create unnecessary confusion or overlap with existing
keys. Keys that are specific to non-generic use cases, particularly keys. Keys that are specific to non-generic use cases, particularly
ones that are not specified as part of an IETF document, are ones that are not specified as part of an IETF document, are
encouraged to use a domain-specific prefix. encouraged to use a domain-specific prefix.
7. Acknowledgments 9. Acknowledgments
This work in this document was started by Mark Donnelly and Margaret This work in this document was started by Mark Donnelly and Margaret
Cullen. Thanks to everyone in the CAPPORT Working Group who has Cullen. Thanks to everyone in the CAPPORT Working Group who has
given input. given input.
8. References 10. References
8.1. Normative References 10.1. Normative References
[I-D.ietf-capport-rfc7710bis]
Kumari, W. and E. Kline, "Captive-Portal Identification in
DHCP / RA", Work in Progress, Internet-Draft, draft-ietf-
capport-rfc7710bis-03, 30 March 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-capport-
rfc7710bis-03.txt>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<https://www.rfc-editor.org/info/rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
skipping to change at page 9, line 43 skipping to change at page 10, line 13
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>. <https://www.rfc-editor.org/info/rfc6960>.
[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,
<https://www.rfc-editor.org/info/rfc7234>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
8.2. Informative References 10.2. Informative References
[I-D.ietf-capport-architecture] [I-D.ietf-capport-architecture]
Larose, K. and D. Dolson, "CAPPORT Architecture", Work in Larose, K., Dolson, D., and H. Liu, "CAPPORT
Progress, Internet-Draft, draft-ietf-capport-architecture- Architecture", Work in Progress, Internet-Draft, draft-
05, 31 December 2019, <http://www.ietf.org/internet- ietf-capport-architecture-06, 15 February 2020,
drafts/draft-ietf-capport-architecture-05.txt>. <http://www.ietf.org/internet-drafts/draft-ietf-capport-
architecture-06.txt>.
Authors' Addresses Authors' Addresses
Tommy Pauly (editor) Tommy Pauly (editor)
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014,
United States of America United States of America
Email: tpauly@apple.com Email: tpauly@apple.com
 End of changes. 41 change blocks. 
95 lines changed or deleted 134 lines changed or added

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