rfc8908xml2.original.xml   rfc8908.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent"> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?> <rfc consensus="true" xmlns:xi="http://www.w3.org/2001/XInclude"
<?rfc symrefs="yes"?> ipr="trust200902" docName="draft-ietf-capport-api-08" number="8908" categor
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft y="std"
-ietf-capport-api-08" category="std" obsoletes="" updates="" submissionType="IET obsoletes="" updates="" submissionType="IETF" xml:lang="en"
F" xml:lang="en" tocInclude="true" sortRefs="true" symRefs="true" version="3"> tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.39.0 --> <!-- xml2rfc v2v3 conversion 2.39.0 -->
<front> <front>
<title abbrev="Captive Portal API">Captive Portal API</title> <title abbrev="Captive Portal API">Captive Portal API</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-capport-api-08"/> <seriesInfo name="RFC" value="8908"/>
<author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor"> <author initials="T." surname="Pauly" fullname="Tommy Pauly" role="editor">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<postal> <postal>
<street>One Apple Park Way</street> <street>One Apple Park Way</street>
<city>Cupertino, California 95014</city> <city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>tpauly@apple.com</email> <email>tpauly@apple.com</email>
</address> </address>
</author> </author>
<author initials="D." surname="Thakore" fullname="Darshak Thakore" role="edi tor"> <author initials="D." surname="Thakore" fullname="Darshak Thakore" role="edi tor">
<organization>CableLabs</organization> <organization>CableLabs</organization>
<address> <address>
<postal> <postal>
<street>858 Coal Creek Circle</street> <street>858 Coal Creek Circle</street>
<city>Louisville, CO 80027</city> <city>Louisville</city>
<region>CO</region>
<code>80027</code>
<country>United States of America</country> <country>United States of America</country>
</postal> </postal>
<email>d.thakore@cablelabs.com</email> <email>d.thakore@cablelabs.com</email>
</address> </address>
</author> </author>
<date year="2020" month="June" day="18"/> <date month="September" year="2020" />
<workgroup>Captive Portal Interaction</workgroup> <workgroup>Captive Portal Interaction</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>This document describes an HTTP API that allows clients to interact wit <t>This document describes an HTTP API that allows clients to interact
h a Captive Portal system. With this API, clients can discover how to get out of with a Captive Portal system. With this API, clients can discover how to
captivity and fetch state about their Captive Portal sessions.</t> get out of captivity and fetch state about their Captive Portal
sessions.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default"> <section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name> <name>Introduction</name>
<t>This document describes a HyperText Transfer Protocol (HTTP) Applicatio <t>This document describes a HyperText Transfer Protocol (HTTP)
n Program Interface (API) that allows clients to interact with a Captive Portal Application Programming Interface (API) that allows clients to interact wi
system. The API defined in this document has been designed to meet the requireme th
nts in the Captive Portal Architecture <xref target="I-D.ietf-capport-architectu a Captive Portal system. The API defined in this document has been
re" format="default"/>. Specifically, the API provides:</t> designed to meet the requirements in the Captive Portal Architecture
<xref target="I-D.ietf-capport-architecture"
format="default"/>. Specifically, the API provides:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>The state of captivity (whether or not the client has access to the <li>The state of captivity (whether or not the client has access to
Internet)</li> the Internet).</li>
<li>A URI of a user-facing web portal that can be used to get out of cap <li>A URI of a user-facing web portal that can be used to get out of
tivity</li> captivity.</li>
<li>Authenticated and encrypted connections, using TLS for connections t <li>Authenticated and encrypted connections, using TLS for connections
o both the API and user-facing web portal</li> to both the API and user-facing web portal.</li>
</ul> </ul>
</section> </section>
<section anchor="terms" numbered="true" toc="default"> <section anchor="terms" numbered="true" toc="default">
<name>Terminology</name> <name>Terminology</name>
<t>This document leverages the terminology and components described in <xr <t>This document leverages the terminology and components described in
ef target="I-D.ietf-capport-architecture" format="default"/> and additionally de <xref target="I-D.ietf-capport-architecture" format="default"/> and
fines the following terms:</t> additionally defines the following terms:</t>
<ul spacing="normal"> <dl newline="true" spacing="normal">
<li>Captive Portal Client: The client that interacts with the Captive Po <dt>Captive Portal Client</dt>
rtal API is typically some application running on the User Equipment that is con <dd>The client that interacts with the Captive
nected to the Captive Network. This is also referred to as the "client" in this Portal API is typically some application running on the user equipment
document.</li> that is connected to the captive network. This is also referred to as
<li>Captive Portal API Server: The server exposing the APIs defined in t the "client" in this document.</dd>
his document to the client. This is also referred to as the "API server" in this <dt>Captive Portal API Server</dt>
document.</li> <dd>The server exposing the APIs defined in
</ul> this document to the client. This is also referred to as the "API
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", server" in this document.</dd>
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and </dl>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 <t>
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"/> when, and only when, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
they appear in all capitals, as shown here.</t> NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
to be interpreted as
described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.
</t>
</section> </section>
<section anchor="workflow" numbered="true" toc="default"> <section anchor="workflow" numbered="true" toc="default">
<name>Workflow</name> <name>Workflow</name>
<t>The Captive Portal Architecture defines several categories of interacti <t>The Captive Portal Architecture defines several categories of
on between clients and Captive Portal systems:</t> interaction between clients and Captive Portal systems:</t>
<ol spacing="normal" type="1"> <ol spacing="normal">
<li>Provisioning, in which a client discovers that a network has a capti <li>Provisioning, in which a client discovers that a network has a
ve portal, and learns the URI of the API server.</li> captive portal and learns the URI of the API server.</li>
<li>API Server interaction, in which a client queries the state of capti <li>API Server interaction, in which a client queries the state of
vity and retrieves the necessary information to get out of captivity.</li> captivity and retrieves the necessary information to get out of
<li>Enforcement, in which the enforcement device in the network blocks d captivity</li>
isallowed traffic.</li> <li>Enforcement, in which the enforcement device in the network blocks
disallowed traffic.</li>
</ol> </ol>
<t>This document defines the mechanisms used in the second category. It is <t>This document defines the mechanisms used in the second category. It
assumed that the location of the Captive Portal API server has been discovered is assumed that the location of the Captive Portal API server has been
by the client as part of Provisioning. A set of mechanisms for discovering the A discovered by the client as part of provisioning. A set of mechanisms
PI Server endpoint is defined in <xref target="I-D.ietf-capport-rfc7710bis" form for discovering the API server endpoint is defined in <xref
at="default"/>.</t> target="RFC8910" format="default"/>.</t>
</section> </section>
<section anchor="api-details" numbered="true" toc="default"> <section anchor="api-details" numbered="true" toc="default">
<name>API Connection Details</name> <name>API Connection Details</name>
<t>The API server endpoint MUST be accessed over HTTP using an https URI < <t>The API server endpoint <bcp14>MUST</bcp14> be accessed over HTTP
xref target="RFC2818" format="default"/>, and SHOULD use the default https port. using an https URI <xref target="RFC2818" format="default"/> and
For example, if the Captive Portal API server is hosted at "example.org", the U <bcp14>SHOULD</bcp14> use the default https port. For example, if the
RI of the API could be "https://example.org/captive-portal/api"</t> Captive Portal API server is hosted at "example.org", the URI of the API
<t>The client SHOULD NOT assume that the URI of the API server for a given could be "https://example.org/captive-portal/api".</t>
network will stay the same, and SHOULD rely on the discovery or provisioning pr <t>The client <bcp14>SHOULD NOT</bcp14> assume that the URI of the API
ocess each time it joins the network.</t> server for a given network will stay the same and <bcp14>SHOULD</bcp14>
<t>As described in Section 3 of <xref target="I-D.ietf-capport-architectur rely on the discovery or provisioning process each time it joins the
e" format="default"/>, the identity of the client needs to be visible to the Cap network.</t>
tive Portal API server in order for the server to correctly reply with the clien <t>As described in <xref target="I-D.ietf-capport-architecture"
t's portal state. If the identifier used by the Captive Portal system is the cli sectionFormat="of" section="3"/>, the identity
ent's set of IP addresses, the system needs to ensure that the same IP addresses of the client needs to be visible to the Captive Portal API server in
are visible to both the API server and the enforcement device.</t> order for the server to correctly reply with the client's portal
<t>If the API server needs information about the client identity that is n state. If the identifier used by the Captive Portal system is the
ot otherwise visible to it, the URI provided to the client during provisioning S client's set of IP addresses, the system needs to ensure that the same
HOULD be distinct per client. Thus, depending on how the Captive Portal system i IP addresses are visible to both the API server and the enforcement
s configured, the URI will be unique for each client host and between sessions f device.</t>
or the same client host.</t> <t>If the API server needs information about the client identity that is
<t>For example, a Captive Portal system that uses per-client session URIs not otherwise visible to it, the URI provided to the client during
could use "https://example.org/captive-portal/api/X54PD39JV" as its API URI.</t> provisioning <bcp14>SHOULD</bcp14> be distinct per client. Thus,
depending on how the Captive Portal system is configured, the URI will
be unique for each client host and between sessions for the same client
host.</t>
<t>For example, a Captive Portal system that uses per-client session
URIs could use "https://example.org/captive-portal/api/X54PD39JV" as its
API URI.</t>
<section anchor="server-auth" numbered="true" toc="default"> <section anchor="server-auth" numbered="true" toc="default">
<name>Server Authentication</name> <name>Server Authentication</name>
<t>The purpose of accessing the Captive Portal API over an HTTPS connect <t>The purpose of accessing the Captive Portal API over an HTTPS
ion is twofold: first, the encrypted connection protects the integrity and confi connection is twofold: first, the encrypted connection protects the
dentiality of the API exchange from other parties on the local network; and seco integrity and confidentiality of the API exchange from other parties
nd, it provides the client of the API an opportunity to authenticate the server on the local network; second, it provides the client of the API an
that is hosting the API. This authentication allows the client to ensure that th opportunity to authenticate the server that is hosting the API. This
e entity providing the Captive Portal API has a valid certificate for the hostna authentication allows the client to ensure that the entity providing
me provisioned by the network using the mechanisms defined in <xref target="I-D. the Captive Portal API has a valid certificate for the hostname
ietf-capport-rfc7710bis" format="default"/>, by validating that a DNS-ID <xref t provisioned by the network using the mechanisms defined in <xref
arget="RFC6125" format="default"/> on the certificate is equal to the provisione target="RFC8910" format="default"/>, by validating
d hostname.</t> that a DNS-ID <xref target="RFC6125" format="default"/> on the
<t>Clients performing revocation checking will need some means of access certificate is equal to the provisioned hostname.</t>
ing revocation information for certificates presented by the API server. Online <t>Clients performing revocation checking will need some means of
Certificate Status Protocol <xref target="RFC6960" format="default"/> (OCSP) sta accessing revocation information for certificates presented by the API
pling, using the TLS Certificate Status Request extension <xref target="RFC6066" server. Online Certificate Status Protocol <xref target="RFC6960"
format="default"/> SHOULD be used. OCSP stapling allows a client to perform rev format="default"/> (OCSP) stapling, using the TLS Certificate Status
ocation checks without initiating new connections. To allow for other forms of r Request extension <xref target="RFC6066" format="default"/>,
evocation checking, especially for clients that do not support OCSP stapling, a <bcp14>SHOULD</bcp14> be used. OCSP stapling allows a client to
captive network SHOULD permit connections to OCSP responders or Certificate Revo perform revocation checks without initiating new connections. To allow
cation Lists (CRLs) that are referenced by certificates provided by the API serv for other forms of revocation checking, especially for clients that do
er. For more discussion on certificate revocation checks, see Section 6.5 of BCP not support OCSP stapling, a captive network <bcp14>SHOULD</bcp14>
195 <xref target="RFC7525" format="default"/>. In addition to connections to OC permit connections to OCSP responders or Certificate Revocation Lists
SP responders and CRLs, a captive network SHOULD also permit connections to Netw (CRLs) that are referenced by certificates provided by the API
ork Time Protocol (NTP) <xref target="RFC5905" format="default"/> servers or oth server. For more discussion on certificate revocation checks, see
er time-sync mechanisms to allow clients to accurately validate certificates.</t <xref target="RFC7525" sectionFormat="of" section="6.5">BCP 195</xref>. I
> n
<t>Certificates with missing intermediate certificates that rely on clie addition to connections to OCSP responders and CRLs, a captive network
nts validating the certificate chain using the URI specified in the Authority In <bcp14>SHOULD</bcp14> also permit connections to Network Time Protocol
formation Access (AIA) extension <xref target="RFC5280" format="default"/> SHOUL (NTP) <xref target="RFC5905" format="default"/> servers or other
D NOT be used by the Captive Portal API server. If the certificates do require t time-sync mechanisms to allow clients to accurately validate
he use of AIA, the captive network MUST allow client access to the host specifie certificates.</t>
d in the URI.</t> <t>Certificates with missing intermediate certificates that rely on
<t>If the client is unable to validate the certificate presented by the clients validating the certificate chain using the URI specified in
API server, it MUST NOT proceed with any of the behavior for API interaction des the Authority Information Access (AIA) extension <xref
cribed in this document. The client will proceed to interact with the captive ne target="RFC5280" format="default"/> <bcp14>SHOULD NOT</bcp14> be used
twork as if the API capabilities were not present. It may still be possible for by the Captive Portal API server. If the certificates do require the
the user to access the network if the network redirects a cleartext webpage to a use of AIA, the captive network <bcp14>MUST</bcp14> allow client
web portal.</t> access to the host specified in the URI.</t>
<t>If the client is unable to validate the certificate presented by
the API server, it <bcp14>MUST NOT</bcp14> proceed with any of the
behavior for API interaction described in this document. The client
will proceed to 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 if the network redirects a cleartext webpage to
a web portal.</t>
</section> </section>
</section> </section>
<section anchor="json-keys" numbered="true" toc="default"> <section anchor="json-keys" numbered="true" toc="default">
<name>API State Structure</name> <name>API State Structure</name>
<t>The Captive Portal API data structures are specified in JavaScript Obje <t>The Captive Portal API data structures are specified in JavaScript
ct Notation (JSON) <xref target="RFC8259" format="default"/>. Requests and respo Object Notation (JSON) <xref target="RFC8259"
nses for the Captive Portal API use the "application/captive+json" media type. C format="default"/>. Requests and responses for the Captive Portal API
lients SHOULD include this media type as an Accept header in their GET requests, use the "application/captive+json" media type. Clients
and servers MUST mark this media type as their Content-Type header in responses <bcp14>SHOULD</bcp14> include this media type as an Accept header in
.</t> their GET requests, and servers <bcp14>MUST</bcp14> mark this media type
<t>The following key MUST be included in the top-level of the JSON structu as their Content-Type header in responses.</t>
re returned by the API server:</t> <t>The following key <bcp14>MUST</bcp14> be included in the top level of
<ul spacing="normal"> the JSON structure returned by the API server:</t>
<li>"captive" (boolean): indicates whether the client is in a state of c <table anchor="tab1">
aptivity, i.e it has not satisfied the conditions to access the external network <thead>
. If the client is captive (i.e. captive=true), it will still be allowed enough <tr>
access for it to perform server authentication (<xref target="server-auth" forma <th>Key</th>
t="default"/>).</li> <th>Type</th>
</ul> <th>Description</th>
<t>The following keys can be optionally included in the top-level of the J </tr>
SON structure returned by the API server:</t> </thead>
<ul spacing="normal"> <tbody>
<li>"user-portal-url" (string): provides the URL of a web portal that MU <tr>
ST be accessed over TLS with which a user can interact.</li> <td>captive</td>
<li>"venue-info-url" (string): provides the URL of a webpage or site tha <td>boolean</td>
t SHOULD be accessed over TLS on which the operator of the network has informati <td>Indicates whether the client is in a state of
on that it wishes to share with the user (e.g., store info, maps, flight status, captivity, i.e, it has not satisfied the conditions to access the
or entertainment).</li> external network. If the client is captive (i.e., captive=true), it
<li>"can-extend-session" (boolean): indicates that the URL specified as will still be allowed enough access for it to perform server
"user-portal-url" allows the user to extend a session once the client is no long authentication (<xref target="server-auth" format="default"/>).
er in a state of captivity. This provides a hint that a client system can sugges </td>
t accessing the portal URL to the user when the session is near its limit in ter </tr>
ms of time or bytes.</li> </tbody>
<li>"seconds-remaining" (number): an integer that indicates the number o </table>
f seconds remaining, after which the client will be placed into a captive state.
The API server SHOULD include this value if the client is not captive (i.e. cap <!-- <dl newline="true" spacing="normal">
tive=false) and the client session is time-limited, and SHOULD omit this value f <dt>"captive" (boolean)</dt>
or captive clients (i.e. captive=true) or when the session is not time-limited.< <dd>This indicates whether the client is in a state of
/li> captivity, i.e, it has not satisfied the conditions to access the
<li>"bytes-remaining" (number): an integer that indicates the number of external network. If the client is captive (i.e., captive=true), it
bytes remaining, after which the client will be in placed into a captive state. will still be allowed enough access for it to perform server
The byte count represents the sum of the total number of IP packet (layer 3) byt authentication (<xref target="server-auth" format="default"/>).</dd>
es sent and received by the client, including IP headers. Captive portal systems </dl>-->
might not count traffic to whitelisted servers, such as the API server, but cli <t>The following keys can be optionally included in the top level of the
ents cannot rely on such behavior. The API server SHOULD include this value if t JSON structure returned by the API server:</t>
he client is not captive (i.e. captive=false) and the client session is byte-lim
ited, and SHOULD omit this value for captive clients (i.e. captive=true) or when <table anchor="tab2">
the session is not byte-limited.</li> <thead>
</ul> <tr>
<t>The valid JSON keys can be extended by adding entries to the Captive Po <th>Key</th>
rtal API Keys Registry (<xref target="iana-section" format="default"/>). If a cl <th>Type</th>
ient receives a key that it does not recognize, it MUST ignore the key and any a <th>Description</th>
ssociated values. All keys other than the ones defined in this document as "requ </tr>
ired" will be considered optional.</t> </thead>
<t>Captive Portal JSON content can contain per-client data that is not app <tbody>
ropriate to store in an intermediary cache. Captive Portal API servers SHOULD se <tr>
t the Cache-Control header field in any responses to "private", or a more restri <td>user-portal-url</td>
ctive value such as "no-store" <xref target="RFC7234" format="default"/>.</t> <td>string</td>
<t>Client behavior for issuing requests for updated JSON content is implem <td>Provides the URL of a web portal that MUST be accessed over TLS with
entation-specific, and can be based on user interaction or the indications of se which a user can interact.</td>
conds and bytes remaining in a given session. If at any point the client does no </tr>
t receive valid JSON content from the API server, either due to an error or due <tr>
to receiving no response, the client SHOULD continue to apply the most recent va <td>venue-info-url</td>
lid content it had received; or, if no content had been received previously, pro <td>string</td>
ceed to interact with the captive network as if the API capabilities were not pr <td>Provides the URL of a webpage or site that SHOULD be accessed over
esent.</t> TLS 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 entertai
nment).</td>
</tr>
<tr>
<td>can-extend-session</td>
<td>boolean</td>
<td>Indicates that the URL specified
as "user-portal-url" allows the user to extend a session once the
client is no longer in a state of captivity. This provides a hint that
a client system can suggest accessing the portal URL to the user when
the session is near its limit in terms of time or bytes.
</td>
</tr>
<tr>
<td>seconds-remaining</td>
<td>number</td>
<td>An integer that indicates the number
of seconds remaining, after which the client will be placed into a
captive state. The API server <bcp14>SHOULD</bcp14> include this value
if the client is not captive (i.e., captive=false) and the client
session is time-limited and <bcp14>SHOULD</bcp14> omit this value for
captive clients (i.e., captive=true) or when the session is not
time-limited.
</td>
</tr>
<tr>
<td>bytes-remaining</td>
<td>number</td>
<td>An integer that indicates the number of bytes remaining, after
which the client will be placed into a captive state. The byte
count represents the sum of the total number of IP packet (layer 3)
bytes sent and received by the client, including IP headers. Captive
Portal systems might not count traffic to whitelisted servers, such as
the API server, but clients cannot rely on such behavior. The API
server <bcp14>SHOULD</bcp14> include this value if the client is not
captive (i.e., captive=false) and the client session is byte-limited
and <bcp14>SHOULD</bcp14> omit this value for captive clients
(i.e., captive=true) or when the session is not byte-limited.
</td>
</tr>
</tbody>
</table>
<!--
<dl newline="true" spacing="normal">
<dt>"user-portal-url" (string)</dt>
<dd>This provides the URL of a web portal that <bcp14>MUST</bcp14> be
accessed over TLS with which a user can interact.</dd>
<dt>"venue-info-url" (string)</dt>
<dd>This provides the URL of a webpage or site
that <bcp14>SHOULD</bcp14> be accessed over TLS 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).</dd>
<dt>"can-extend-session" (boolean)</dt>
<dd>This indicates that the URL specified
as "user-portal-url" allows the user to extend a session once the
client is no longer in a state of captivity. This provides a hint that
a client system can suggest accessing the portal URL to the user when
the session is near its limit in terms of time or bytes.</dd>
<dt>"seconds-remaining" (number)</dt>
<dd>This is an integer that indicates the number
of seconds remaining, after which the client will be placed into a
captive state. The API server <bcp14>SHOULD</bcp14> include this value
if the client is not captive (i.e., captive=false) and the client
session is time-limited and <bcp14>SHOULD</bcp14> omit this value for
captive clients (i.e., captive=true) or when the session is not
time-limited.</dd>
<dt>"bytes-remaining" (number)</dt>
<dd>This is an integer that indicates the number of bytes remaining, afte
r
which the client will be in placed into a captive state. The byte
count represents the sum of the total number of IP packet (layer 3)
bytes sent and received by the client, including IP headers. Captive
Portal systems might not count traffic to whitelisted servers, such as
the API server, but clients cannot rely on such behavior. The API
server <bcp14>SHOULD</bcp14> include this value if the client is not
captive (i.e., captive=false) and the client session is byte-limited
and <bcp14>SHOULD</bcp14> omit this value for captive clients
(i.e., captive=true) or when the session is not byte-limited.</dd>
</dl>
-->
<t>The valid JSON keys can be extended by adding entries to the Captive
Portal API Keys Registry (<xref target="iana-field-reg"
format="default"/>). If a client receives a key that it does not
recognize, it <bcp14>MUST</bcp14> ignore the key and any associated
values. All keys other than the ones defined in this document as
"required" will be considered optional.</t>
<t>Captive Portal JSON content can contain per-client data that is not
appropriate to store in an intermediary cache. Captive Portal API
servers <bcp14>SHOULD</bcp14> set the Cache-Control header field in any
responses to "private" or a more restrictive value, such as "no-store"
<xref target="RFC7234" format="default"/>.</t>
<t>Client behavior for issuing requests for updated JSON content is
implementation specific and can be based on user interaction or the
indications of seconds and bytes remaining in a given session. If at any
point the client does not receive valid JSON content from the API
server, either due to an error or due to receiving no response, the
client <bcp14>SHOULD</bcp14> continue to apply the most recent valid
content it had received or, if no content had been received previously,
proceed to interact with the captive network as if the API capabilities
were not present.</t>
</section> </section>
<section anchor="example" numbered="true" toc="default"> <section anchor="example" numbered="true" toc="default">
<name>Example Interaction</name> <name>Example Interaction</name>
<t>A client connected to a captive network upon discovering the URI of the <t>Upon discovering the URI of the API server,
API server will query the API server to retrieve information about its captive a client connected to a captive network
state and conditions to escape captivity. In this example, the client discovered will query the API server to retrieve information about
the URI "https://example.org/captive-portal/api/X54PD39JV" using one of the mec its captive state and conditions to escape captivity. In this example,
hanisms defined in <xref target="I-D.ietf-capport-rfc7710bis" format="default"/> the client discovered the URI
.</t> "https://example.org/captive-portal/api/X54PD39JV" using one of the
<t>To request the Captive Portal JSON content, a client sends an HTTP GET mechanisms defined in <xref target="RFC8910"
request:</t> format="default"/>.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <t>To request the Captive Portal JSON content, a client sends an HTTP
GET request:</t>
<sourcecode type="http-message"><![CDATA[
GET /captive-portal/api/X54PD39JV HTTP/1.1 GET /captive-portal/api/X54PD39JV HTTP/1.1
Host: example.org Host: example.org
Accept: application/captive+json Accept: application/captive+json
]]></artwork> ]]></sourcecode>
<t>The server then responds with the JSON content for that client:</t> <t>The server then responds with the JSON content for that client:</t>
<artwork name="" type="" align="left" alt=""><![CDATA[ <sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Cache-Control: private Cache-Control: private
Date: Mon, 02 Mar 2020 05:07:35 GMT Date: Mon, 02 Mar 2020 05:07:35 GMT
Content-Type: application/captive+json Content-Type: application/captive+json
{ {
"captive": true, "captive": true,
"user-portal-url": "https://example.org/portal.html" "user-portal-url": "https://example.org/portal.html"
} }
]]></artwork> ]]></sourcecode>
<t>Upon receiving this information the client will use this information to <t>Upon receiving this information, the client will use it
direct the user to the web portal (as specified by the user-portal-url value) t to direct the user to the web portal (as specified by the
o enable access to the external network. Once the user satisfies the requirement user-portal-url value) to enable access to the external network. Once
s for external network access, the client SHOULD query the API server again to v the user satisfies the requirements for external network access, the
erify that it is no longer captive.</t> client <bcp14>SHOULD</bcp14> query the API server again to verify that
<t>When the client requests the Captive Portal JSON content after gaining it is no longer captive.</t>
external network access, the server responds with updated JSON content:</t> <t>When the client requests the Captive Portal JSON content after
<artwork name="" type="" align="left" alt=""><![CDATA[ gaining external network access, the server responds with updated JSON
content:</t>
<sourcecode type="http-message"><![CDATA[
HTTP/1.1 200 OK HTTP/1.1 200 OK
Cache-Control: private Cache-Control: private
Date: Mon, 02 Mar 2020 05:08:13 GMT Date: Mon, 02 Mar 2020 05:08:13 GMT
Content-Type: application/captive+json Content-Type: application/captive+json
{ {
"captive": false, "captive": false,
"user-portal-url": "https://example.org/portal.html", "user-portal-url": "https://example.org/portal.html",
"venue-info-url": "https://flight.example.com/entertainment", "venue-info-url": "https://flight.example.com/entertainment",
"seconds-remaining": 326, "seconds-remaining": 326,
"can-extend-session": true "can-extend-session": true
} }
]]></artwork> ]]></sourcecode>
</section> </section>
<section anchor="security" numbered="true" toc="default"> <section anchor="security" numbered="true" toc="default">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>One of the goals of this protocol is to improve the security of the com <t>One of the goals of this protocol is to improve the security of the
munication between client hosts and Captive Portal systems. Client traffic is pr communication between client hosts and Captive Portal systems. Client
otected from passive listeners on the local network by requiring TLS-encrypted c traffic is protected from passive listeners on the local network by
onnections between the client and the Captive Portal API server, as described in requiring TLS-encrypted connections between the client and the Captive
<xref target="api-details" format="default"/>. All communication between the cl Portal API server, as described in <xref target="api-details"
ients and the API server MUST be encrypted.</t> format="default"/>. All communication between the clients and the API
<t>In addition to encrypting communications between clients and Captive Po server <bcp14>MUST</bcp14> be encrypted.</t>
rtal systems, this protocol requires a basic level of authentication from the AP <t>In addition to encrypting communications between clients and Captive
I server, as described in <xref target="server-auth" format="default"/>. Specifi Portal systems, this protocol requires a basic level of authentication
cally, the API server MUST present a valid certificate on which the client can p from the API server, as described in <xref target="server-auth"
erform revocation checks. This allows the client to ensure that the API server h format="default"/>. Specifically, the API server <bcp14>MUST</bcp14>
as authority for the hostname that was provisioned by the network using <xref ta present a valid certificate on which the client can perform revocation
rget="I-D.ietf-capport-rfc7710bis" format="default"/>. Note that this validation checks. This allows the client to ensure that the API server has
only confirms that the API server matches what the network's provisioning mecha authority for the hostname that was provisioned by the network using
nism (such as DHCP or IPv6 Router Advertisements) provided, and not validating t <xref target="RFC8910" format="default"/>. Note that
he security of those provisioning mechanisms or the user's trust relationship to this validation only confirms that the API server matches what the
the network.</t> network's provisioning mechanism (such as DHCP or IPv6 Router
Advertisements) provided; it is not validating the security of those
provisioning mechanisms or the user's trust relationship to the
network.</t>
<section anchor="privacy" numbered="true" toc="default"> <section anchor="privacy" numbered="true" toc="default">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>Information passed between a client and the user-facing web portal ma <t>Information passed between a client and the user-facing web portal
y include a user's personal information, such as a full name and credit card det may include a user's personal information, such as a full name and
ails. Therefore, it is important that both the user-facing web portal and the AP credit card details. Therefore, it is important that both the
I server that points a client to the web portal are only accessed over encrypted user-facing web portal and the API server that points a client to the
connections.</t> web portal are only accessed over encrypted connections.</t>
<t>It is important to note that although communication to the user-facin <t>It is important to note that although communication to the
g web portal requires using TLS, the authentication only validates that the web user-facing web portal requires use of TLS, the authentication only
portal server matches the name in the URI provided by the API server. Since this validates that the web portal server matches the name in the URI
is not a name that a user typed in, the hostname of the web site that would be provided by the API server. Since this is not a name that a user typed
presented to the user may include "confusable characters" that can mislead the u in, the hostname of the website that would be presented to the user
ser. See Section 12.5 of <xref target="RFC8264" format="default"/> for a discuss may include "confusable characters", which can mislead the user. See
ion of confusable characters.</t> <xref target="RFC8264" sectionFormat="of" section="12.5"/> for a
discussion of confusable characters.</t>
</section> </section>
</section> </section>
<section anchor="iana-section" numbered="true" toc="default"> <section anchor="iana-section" numbered="true" toc="default">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>IANA is requested to create a registration for an "application/captive+ <t>IANA has registered the
json" media type (<xref target="iana-json" format="default"/>) and a registry fo "application/captive+json" media type (<xref target="iana-json"
r fields in that format (<xref target="iana-field-reg" format="default"/>).</t> format="default"/>) and created a registry for fields in that format (<xre
f
target="iana-field-reg" format="default"/>).</t>
<section anchor="iana-json" numbered="true" toc="default"> <section anchor="iana-json" numbered="true" toc="default">
<name>Captive Portal API JSON Media Type Registration</name> <name>Captive Portal API JSON Media Type Registration</name>
<t>This document registers the media type for Captive Portal API JSON te <t>This document registers the media type for Captive Portal API JSON
xt, "application/captive+json".</t> text, "application/captive+json".</t>
<t>Type name: application</t> <dl newline="false" spacing="normal">
<t>Subtype name: captive+json</t> <dt>Type name:</dt>
<t>Required parameters: N/A</t> <dd>application</dd>
<t>Optional parameters: N/A</t> <dt>Subtype name:</dt>
<t>Encoding considerations: Encoding considerations are identical to tho <dd>captive+json</dd>
se specified for the "application/json" media type.</t> <dt>Required parameters:</dt>
<t>Security considerations: See <xref target="security" format="default" <dd>N/A</dd>
/></t> <dt>Optional parameters:</dt>
<t>Interoperability considerations: This document specifies format of co <dd>N/A</dd>
nforming messages and the interpretation thereof.</t> <dt>Encoding considerations:</dt>
<t>Published specification: This document</t> <dd>Encoding considerations are identical to those specified for the
<t>Applications that use this media type: This media type is intended to "application/json" media type.</dd>
be used by servers presenting the Captive Portal API, and clients connecting to <dt>Security considerations:</dt>
such captive networks.</t> <dd>See <xref target="security" format="default"/></dd>
<t>Fragment identifier considerations: N/A</t> <dt>Interoperability considerations:</dt>
<t>Additional information: N/A</t> <dd>This document specifies format of conforming messages and the
<t>Person and email address to contact for further information: See Auth interpretation thereof.</dd>
ors' Addresses section</t> <dt>Published specification:</dt>
<t>Intended usage: COMMON</t> <dd>RFC 8908</dd>
<t>Restrictions on usage: N/A</t> <dt>Applications that use this media type:</dt>
<t>Author: CAPPORT IETF WG</t> <dd>This media type is intended to be used by servers presenting the
<t>Change controller: IETF</t> Captive Portal API, and clients connecting to such captive
networks.</dd>
<dt>Fragment identifier considerations:</dt>
<dd>N/A</dd>
<dt>Additional Information:</dt>
<dd>N/A</dd>
<dt>Person and email address to contact for further information:</dt>
<dd>See Authors' Addresses section</dd>
<dt>Intended usage:</dt>
<dd>COMMON</dd>
<dt>Restrictions on usage:</dt>
<dd>N/A</dd>
<dt>Author:</dt>
<dd>CAPPORT IETF WG</dd>
<dt>Change controller:</dt>
<dd>IETF</dd>
</dl>
</section> </section>
<section anchor="iana-field-reg" numbered="true" toc="default"> <section anchor="iana-field-reg" numbered="true" toc="default">
<name>Captive Portal API Keys Registry</name> <name>Captive Portal API Keys Registry</name>
<t>IANA is asked to create and maintain a new registry called "Captive P <t>IANA has created a new registry called "Captive
ortal API Keys", which will reserve JSON keys for use in Captive Portal API data Portal API Keys", which reserves JSON keys for use in Captive
structures. The initial contents of this registry are provided in <xref target= Portal API data structures. The initial contents of this registry are
"json-keys" format="default"/>.</t> provided in <xref target="json-keys" format="default"/>.</t>
<t>Each entry in the registry contains the following fields:</t> <t>Each entry in the registry contains the following fields:</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Key:</dt> <dt>Key:</dt>
<dd> <dd>The JSON key being registered in string format.</dd>
The JSON key being registered, in string format.</dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>The type of the JSON value to be stored, as one of the value
The type of the JSON value to be stored, as one of the value types defined in types defined in <xref target="RFC8259" format="default"/>.</dd>
<xref target="RFC8259" format="default"/>.</dd>
<dt>Description:</dt> <dt>Description:</dt>
<dd> <dd>A brief description explaining the meaning of the value, how it
A brief description explaining the meaning of the value, how it might be used, might be used, and/or how it should be interpreted by clients.</dd>
and/or how it should be interpreted by clients.</dd> <dt>Refrence:</dt>
<dt>Specification:</dt> <dd>A reference to a specification that defines the key and explains
<dd> its usage.</dd>
A reference to a specification that defines the key and explains its usage.</d
d>
</dl> </dl>
<t>New assignments for Captive Portal API Keys Registry will be administ <t>New assignments for the "Captive Portal API Keys" registry will be
ered by IANA using the Specification Required policy <xref target="RFC8126" form administered by IANA using the Specification Required policy <xref
at="default"/>. target="RFC8126" format="default"/>. The designated expert is expected
The Designated Expert is expected to validate the existence of documentation des to validate the existence of documentation describing new keys in a
cribing new keys in a permanent permanent, publicly available specification, such as an Internet-Draft
publicly available specification, such as an Internet Draft or RFC. The expert i or RFC. The expert is expected to validate that new keys have a clear
s expected to validate that new keys have a meaning and do not create unnecessary confusion or overlap with
clear meaning and do not create unnecessary confusion or overlap with existing k existing keys. Keys that are specific to nongeneric use cases,
eys. Keys that are specific to particularly ones that are not specified as part of an IETF document,
non-generic use cases, particularly ones that are not specified as part of an IE are encouraged to use a domain-specific prefix.</t>
TF document, are encouraged to
use a domain-specific prefix.</t>
</section> </section>
</section> </section>
<section anchor="thanksall" numbered="true" toc="default">
<name>Acknowledgments</name>
<t>This work in this document was started by Mark Donnelly and Margaret Cu
llen. Thanks to everyone in the CAPPORT Working Group who has given input.</t>
</section>
</middle> </middle>
<back> <back>
<displayreference target="I-D.ietf-capport-architecture" to="CAPPORT-ARCH"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2 <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
119"> ence.RFC.2119.xml"/>
<front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<title>Key words for use in RFCs to Indicate Requirement Levels</tit ence.RFC.8174.xml"/>
le> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<seriesInfo name="DOI" value="10.17487/RFC2119"/> ence.RFC.2818.xml"/>
<seriesInfo name="RFC" value="2119"/> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<seriesInfo name="BCP" value="14"/> ence.RFC.6125.xml"/>
<author initials="S." surname="Bradner" fullname="S. Bradner"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<organization/> ence.RFC.6960.xml"/>
</author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<date year="1997" month="March"/> ence.RFC.6066.xml"/>
<abstract> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<t>In many standards track documents several words are used to sig ence.RFC.5905.xml"/>
nify the requirements in the specification. These words are often capitalized. <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
This document defines these words as they should be interpreted in IETF document ence.RFC.5280.xml"/>
s. This document specifies an Internet Best Current Practices for the Internet <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
Community, and requests discussion and suggestions for improvements.</t> ence.RFC.8259.xml"/>
</abstract> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
</front> ence.RFC.7234.xml"/>
</reference> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8 ence.RFC.8126.xml"/>
174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="BCP" value="14"/>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<date year="2017" month="May"/>
<abstract>
<t>RFC 2119 specifies common key words that may be used in protoco
l specifications. This document aims to reduce the ambiguity by clarifying tha
t only UPPERCASE usage of the key words have the defined special meanings.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC2818" target="https://www.rfc-editor.org/info/rfc2
818">
<front>
<title>HTTP Over TLS</title>
<seriesInfo name="DOI" value="10.17487/RFC2818"/>
<seriesInfo name="RFC" value="2818"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla">
<organization/>
</author>
<date year="2000" month="May"/>
<abstract>
<t>This memo describes how to use Transport Layer Security (TLS) t
o secure Hypertext Transfer Protocol (HTTP) connections over the Internet. This
memo provides information for the Internet community.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc6
125">
<front>
<title>Representation and Verification of Domain-Based Application S
ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
tificates in the Context of Transport Layer Security (TLS)</title>
<seriesInfo name="DOI" value="10.17487/RFC6125"/>
<seriesInfo name="RFC" value="6125"/>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
">
<organization/>
</author>
<author initials="J." surname="Hodges" fullname="J. Hodges">
<organization/>
</author>
<date year="2011" month="March"/>
<abstract>
<t>Many application technologies enable secure communication betwe
en two entities by means of Internet Public Key Infrastructure Using X.509 (PKIX
) certificates in the context of Transport Layer Security (TLS). This document s
pecifies procedures for representing and verifying the identity of application s
ervices in such interactions. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6960" target="https://www.rfc-editor.org/info/rfc6
960">
<front>
<title>X.509 Internet Public Key Infrastructure Online Certificate S
tatus Protocol - OCSP</title>
<seriesInfo name="DOI" value="10.17487/RFC6960"/>
<seriesInfo name="RFC" value="6960"/>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="M." surname="Myers" fullname="M. Myers">
<organization/>
</author>
<author initials="R." surname="Ankney" fullname="R. Ankney">
<organization/>
</author>
<author initials="A." surname="Malpani" fullname="A. Malpani">
<organization/>
</author>
<author initials="S." surname="Galperin" fullname="S. Galperin">
<organization/>
</author>
<author initials="C." surname="Adams" fullname="C. Adams">
<organization/>
</author>
<date year="2013" month="June"/>
<abstract>
<t>This document specifies a protocol useful in determining the cu
rrent status of a digital certificate without requiring Certificate Revocation L
ists (CRLs). Additional mechanisms addressing PKIX operational requirements are
specified in separate documents. This document obsoletes RFCs 2560 and 6277. I
t also updates RFC 5912.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC6066" target="https://www.rfc-editor.org/info/rfc6
066">
<front>
<title>Transport Layer Security (TLS) Extensions: Extension Definiti
ons</title>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
<seriesInfo name="RFC" value="6066"/>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd">
<organization/>
</author>
<date year="2011" month="January"/>
<abstract>
<t>This document provides specifications for existing TLS extensio
ns. It is a companion document for RFC 5246, "The Transport Layer Security (TLS
) Protocol Version 1.2". The extensions specified are server_name, max_fragment
_length, client_certificate_url, trusted_ca_keys, truncated_hmac, and status_req
uest. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5
905">
<front>
<title>Network Time Protocol Version 4: Protocol and Algorithms Spec
ification</title>
<seriesInfo name="DOI" value="10.17487/RFC5905"/>
<seriesInfo name="RFC" value="5905"/>
<author initials="D." surname="Mills" fullname="D. Mills">
<organization/>
</author>
<author initials="J." surname="Martin" fullname="J. Martin" role="ed
itor">
<organization/>
</author>
<author initials="J." surname="Burbank" fullname="J. Burbank">
<organization/>
</author>
<author initials="W." surname="Kasch" fullname="W. Kasch">
<organization/>
</author>
<date year="2010" month="June"/>
<abstract>
<t>The Network Time Protocol (NTP) is widely used to synchronize c
omputer clocks in the Internet. This document describes NTP version 4 (NTPv4),
which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305,
as well as previous versions of the protocol. NTPv4 includes a modified protoco
l header to accommodate the Internet Protocol version 6 address family. NTPv4 i
ncludes fundamental improvements in the mitigation and discipline algorithms tha
t extend the potential accuracy to the tens of microseconds with modern workstat
ions and fast LANs. It includes a dynamic server discovery scheme, so that in m
any cases, specific server configuration is not required. It corrects certain e
rrors in the NTPv3 design and implementation and includes an optional extension
mechanism. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC5280" target="https://www.rfc-editor.org/info/rfc5
280">
<front>
<title>Internet X.509 Public Key Infrastructure Certificate and Cert
ificate Revocation List (CRL) Profile</title>
<seriesInfo name="DOI" value="10.17487/RFC5280"/>
<seriesInfo name="RFC" value="5280"/>
<author initials="D." surname="Cooper" fullname="D. Cooper">
<organization/>
</author>
<author initials="S." surname="Santesson" fullname="S. Santesson">
<organization/>
</author>
<author initials="S." surname="Farrell" fullname="S. Farrell">
<organization/>
</author>
<author initials="S." surname="Boeyen" fullname="S. Boeyen">
<organization/>
</author>
<author initials="R." surname="Housley" fullname="R. Housley">
<organization/>
</author>
<author initials="W." surname="Polk" fullname="W. Polk">
<organization/>
</author>
<date year="2008" month="May"/>
<abstract>
<t>This memo profiles the X.509 v3 certificate and X.509 v2 certif
icate revocation list (CRL) for use in the Internet. An overview of this approa
ch and model is provided as an introduction. The X.509 v3 certificate format is
described in detail, with additional information regarding the format and seman
tics of Internet name forms. Standard certificate extensions are described and
two Internet-specific extensions are defined. A set of required certificate ext
ensions is specified. The X.509 v2 CRL format is described in detail along with
standard and Internet-specific extensions. An algorithm for X.509 certificatio
n path validation is described. An ASN.1 module and examples are provided in th
e appendices. [STANDARDS-TRACK]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8
259">
<front>
<title>The JavaScript Object Notation (JSON) Data Interchange Format
</title>
<seriesInfo name="DOI" value="10.17487/RFC8259"/>
<seriesInfo name="RFC" value="8259"/>
<seriesInfo name="STD" value="90"/>
<author initials="T." surname="Bray" fullname="T. Bray" role="editor
">
<organization/>
</author>
<date year="2017" month="December"/>
<abstract>
<t>JavaScript Object Notation (JSON) is a lightweight, text-based,
language-independent data interchange format. It was derived from the ECMAScri
pt Programming Language Standard. JSON defines a small set of formatting rules
for the portable representation of structured data.</t>
<t>This document removes inconsistencies with other specifications
of JSON, repairs specification errors, and offers experience-based interoperabi
lity guidance.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7234" target="https://www.rfc-editor.org/info/rfc7
234">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
<seriesInfo name="DOI" value="10.17487/RFC7234"/>
<seriesInfo name="RFC" value="7234"/>
<author initials="R." surname="Fielding" fullname="R. Fielding" role
="editor">
<organization/>
</author>
<author initials="M." surname="Nottingham" fullname="M. Nottingham"
role="editor">
<organization/>
</author>
<author initials="J." surname="Reschke" fullname="J. Reschke" role="
editor">
<organization/>
</author>
<date year="2014" month="June"/>
<abstract>
<t>The Hypertext Transfer Protocol (HTTP) is a stateless \%applica
tion- level protocol for distributed, collaborative, hypertext information syste
ms. This document defines HTTP caches and the associated header fields that con
trol cache behavior or indicate cacheable response messages.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
126">
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs
</title>
<seriesInfo name="DOI" value="10.17487/RFC8126"/>
<seriesInfo name="RFC" value="8126"/>
<seriesInfo name="BCP" value="26"/>
<author initials="M." surname="Cotton" fullname="M. Cotton">
<organization/>
</author>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization/>
</author>
<author initials="T." surname="Narten" fullname="T. Narten">
<organization/>
</author>
<date year="2017" month="June"/>
<abstract>
<t>Many protocols make use of points of extensibility that use con
stants to identify various protocol parameters. To ensure that the values in th
ese fields do not have conflicting uses and to promote interoperability, their a
llocations are often coordinated by a central record keeper. For IETF protocols
, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
<t>To make assignments in a given registry prudently, guidance des
cribing the conditions under which new values should be assigned, as well as whe
n and how modifications to existing values can be made, is needed. This documen
t defines a framework for the documentation of these guidelines by specification
authors, in order to assure that the provided guidance for the IANA Considerati
ons is clear and addresses the various issues that are likely in the operation o
f a registry.</t>
<t>This is the third edition of this document; it obsoletes RFC 52
26.</t>
</abstract>
</front>
</reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="I-D.ietf-capport-architecture" target="http://www.iet <!-- draft-ietf-capport-architecture-08: Submitted to IESG for Publication -->
f.org/internet-drafts/draft-ietf-capport-architecture-08.txt"> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml3/refe
<front> rence.I-D.draft-ietf-capport-architecture-08.xml"/>
<title>CAPPORT Architecture</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-capport-architec
ture-08"/>
<author initials="K" surname="Larose" fullname="Kyle Larose">
<organization/>
</author>
<author initials="D" surname="Dolson" fullname="David Dolson">
<organization/>
</author>
<author initials="H" surname="Liu" fullname="Heng Liu">
<organization/>
</author>
<date month="May" day="11" year="2020"/>
<abstract>
<t>This document describes a CAPPORT architecture. DHCP or Router
Advertisements, an optional signaling protocol, and an HTTP API are used to pro
vide the solution. The role of Provisioning Domains (PvDs) is described.</t>
</abstract>
</front>
</reference>
<reference anchor="I-D.ietf-capport-rfc7710bis" target="http://www.ietf.
org/internet-drafts/draft-ietf-capport-rfc7710bis-07.txt">
<front>
<title>Captive-Portal Identification in DHCP / RA</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-capport-rfc7710b
is-07"/>
<author initials="W" surname="Kumari" fullname="Warren Kumari">
<organization/>
</author>
<author initials="E" surname="Kline" fullname="Erik Kline">
<organization/>
</author>
<date month="May" day="23" year="2020"/>
<abstract>
<t>In many environments offering short-term or temporary Internet
access (such as coffee shops), it is common to start new connections in a captiv
e portal mode. This highly restricts what the customer can do until the custome
r has authenticated. This document describes a DHCPv4 and DHCPv6 option and a R
outer Advertisement (RA) option to inform clients that they are behind some sort
of captive-portal enforcement device, and that they will need to authenticate t
o get Internet access. It is not a full solution to address all of the issues t
hat clients may have with captive portals; it is designed to be one component of
a standardized approach for hosts to interact with such portals. While this do
cument defines how the network operator may convey the captive portal API endpoi
nt to hosts, the specific methods of authenticating to, and interacting with the
captive portal are out of scope of this document. This document replaces RFC 7
710. RFC 7710 used DHCP code point 160. Due to a conflict, this document specif
ies 114. [ This document is being collaborated on in Github at: https://github.
com/capport-wg/7710bis. The most recent version of the document, open issues, e
tc should all be available here. The authors (gratefully) accept pull requests.
Text in square brackets will be removed before publication. ]</t>
</abstract>
</front>
</reference>
<reference anchor="RFC7525" target="https://www.rfc-editor.org/info/rfc7
525">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="BCP" value="195"/>
<author initials="Y." surname="Sheffer" fullname="Y. Sheffer">
<organization/>
</author>
<author initials="R." surname="Holz" fullname="R. Holz">
<organization/>
</author>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
">
<organization/>
</author>
<date year="2015" month="May"/>
<abstract>
<t>Transport Layer Security (TLS) and Datagram Transport Layer Sec
urity (DTLS) are widely used to protect data exchanged over application protocol
s such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, severa
l serious attacks on TLS have emerged, including attacks on its most commonly us
ed cipher suites and their modes of operation. This document provides recommend
ations for improving the security of deployed services that use TLS and DTLS. Th
e recommendations are applicable to the majority of use cases.</t>
</abstract>
</front>
</reference>
<reference anchor="RFC8264" target="https://www.rfc-editor.org/info/rfc8
264">
<front>
<title>PRECIS Framework: Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols</title>
<seriesInfo name="DOI" value="10.17487/RFC8264"/>
<seriesInfo name="RFC" value="8264"/>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
">
<organization/>
</author>
<author initials="M." surname="Blanchet" fullname="M. Blanchet">
<organization/>
</author>
<date year="2017" month="October"/>
<abstract>
<t>Application protocols using Unicode code points in protocol str
ings need to properly handle such strings in order to enforce internationalizati
on rules for strings placed in various protocol slots (such as addresses and ide
ntifiers) and to perform valid comparison operations (e.g., for purposes of auth
entication or authorization). This document defines a framework enabling applic
ation protocols to perform the preparation, enforcement, and comparison of inter
nationalized strings ("PRECIS") in a way that depends on the properties of Unico
de code points and thus is more agile with respect to versions of Unicode. As a
result, this framework provides a more sustainable approach to the handling of
internationalized strings than the previous framework, known as Stringprep (RFC
3454). This document obsoletes RFC 7564.</t>
</abstract>
</front>
</reference>
</references>
</references>
</back>
<!-- ##markdown-source:
H4sIAFIr7F4AA8Vca3PjRnb9zl/R4XywVCE5ksaaB7dSWYWSbXlnJEXSxEml
Uqkm0CRhgQCMBqRhVNrfvvfc2w00SEjjxyZx2WOSALpv38e5T8x4PB5USZWa
qZrpokrujbrKy0qn6uTqfKDn89Lc916K8yjTa3osLvWiGiemWowjXRR0x1gX
yfjg/SDWlZkOIvpzmZebqbJVPBgkRTlVVVnb6ujg4MPB0eDObB7yMp6q86wy
ZWaq8SlWHNCPd8syr4ud7flGHVVJng1spbP4v3WaZ0TKxthBkUzVf1Z5NFKW
7i7NwtKnzRof/msw0HW1ysvpQKkx/adUktmpup2oK12nG/5FDnWbr9eb4Ncy
B4dMnFR5yT/k5XKqTooiNURONOHfLG1nqqm6zIy7dKXLO/WTljWipCImzOrC
lFWS5SM6Vpos8jJLtPpwfHD4rdyV11kFbn3OksrE6qYi/lmVL9TJ2pRJpPku
s9ZJSnwsQOGfNTabRPm6e67Tibpd6bu8NMHJTnVp6cfOlf7TzfQ8NR/13HYO
9/74vZrlJIUZfb9Ts6SMUhOc72NeJ/Y+SVNDB7xU7w8Ojt799oPFk0ro+3ME
KlKigs83GI/Hir5UkP9gcLtKrCJNrNcmq1RsbFQmc1pUZ+qH29srKKqihSql
0zR/sCpKE7rRqionDokSqYekWim9rWN2YyuznqifcLXCNrTWqFkgoh3ixEb5
vSnVKn/AiktTqbyucKKIFyN+ECWxWpgqWhED6bxEO26pViYpd7Y01pJK24mc
cp3EMXF28Ar6XuZxLQr//JnVDxtSrVvzpVK3pc7sgki7KnOyhTxVe+DHPqsl
sRor4dqy1Gsxp4WOjNqjM+7/QYbdrgyzPTaLJCMxJ5mwr6F4pa2aG5OB9GSJ
W2jxNekWuKJK80udlGbNu/KzZgd9ymhFGhRVdWnU4+M/n49PJ134CW54epqo
m8JEyYKOnaabEa8IAosyv0+Ihimxm6kWAXWkt/ewMnR/SQahslwoFJbwMXQU
kcxAPy54/Nqn9U7U5+tzrKVVbU05JvYm2VI9mLkq5BTMZajR3OCW+DkNwmIE
WrQl5Eb3QaNMFpWbAt+iPMsMawbhXG2xye3HG0WwEl7C4vOcNVkOj0X6CYPC
3ZpyTQiV5suNenxFp1rbp23FSw2pvl6S4mHNKngCa5OtFgTJEKLXUFaFr4uL
H9cxYRERDok5TZJ9Fjn0EhQzVSQ7QrxtBZmxhKYsVCct5rbXYCsq3KdaxBo6
ZLUpRFvIh6zJZgOjKessw/a5qOZn4qE6I5Ut1u021rNepBruc2Eq+DWYCd1G
/+rU5qT0ZKul3K3loEMhfLhjP5O+E4PuG1OSROTUlj8r86XIWSWc2O3zVuno
lF1/BXnYUXbpI3EAIsixK3h2q4afPt/cDkfyf3VxyZ+vz/718/n12Sk+3/xw
8vFj80HuGNCXy88f3XV8ap+cXX76dHZxKg/Tr2rrp08n/0H/I00aDC+vbs8v
L04+7pKpNOEHDMOIZhSlYfvaUtl/mV0p8s2Pj/9w/d3s6PDwA+mofHl/+O5b
+kIYkfFmpBSkMvx1QEzaQHGMLrEIKRNMOiFhkZ3SFpacRqYIWswEFvcTKcWC
NFs49xLgeWuwbH9YlcOrRFxp0oZGdK7qATjrMRwU9oI2zOhwAn9wn8ADkcaM
QPTDKomA9M6GvL+zzkOoTJRZoNAhlnEwIgxJ6fiZaIzDQw9AojuTwdEkUN6Q
/D4KfqkNH7TqR2vsSDKkW+7dTWSEBNC63NBiBIlrseFnkHYyeDNRZ7gvYv8T
UIC1THuFhHCfRMb7J8+HeZpHdxZ8Yu8Jg6FIlhzPZNdrt5C2NtFKZ4ldW/ED
blFrCERiL97NRJ0zsmhraYlYRID7aE85lWNuDzI4NGgdrxMkLTPfhD6Nbih0
yVwJlYFERGvwzwGxcDF+pQBjvChNFhc5yRNEB6jT5wDKRfTu3eHBPLHkrWEN
WGbWeC91aioKCi25IiQWsXx7ElMJztfsyChDVi3umfblKI0DQvGQ5HVXVVVY
Vkpn2O8P3z89idY6tCFp8KGIeoqyK/cIKJ6o73Kgq14XCHOTr3GeWLDKLYNL
pYbuuQkF2cNRn21QpJzGOMCQt5y+fh088trZ2Vjs7DWxZCiscEJssdIpS6sr
vTbIgtRqSWtmjSo/UAAPExP1sJQ5dFhTGgI65wK9DmwQJBWB2uALx0dGw4QS
oiSp1M8kIhuaDUn8ZAtyb5zg34Dar4cMwkSK5ShGIhhwJ3TsyIyJrYN5kEbZ
xLZT7hEYmVMZO95UrUOlB6OcXGFU0flLUwDufSgh+31jfYDHAEVmuwioWyS0
CFu5M7xePOYQJFzRGd/5FQKjEjpt5czu/uaMJrPwEY3AIbjOY+zzAjZ0gkJ3
SMi5H/BIVOc76iObh/ja5DheBo1ofHyEWDpHYP2Q2A49SdVahAvQ425souK6
dMrVappTyzlrIyXXlKVQKhREMzUxLDYFQYQL3jhne0kAhL6LZEncjFuK2CoQ
r2cJuSJWDtZtnxKQjTP3vOf1GV2rRpBHcDcxtIMkz2RVwrca8qNjjd0CbnVQ
Zh1mALJ+JWi8/vfjb69O33z48d+GwP2k4gwXiwGCX3kYD3IP7PX4SqQ+RiHF
QXBRlxRmsi8WxPXeoMe+clEwBuObIENhlX/IKbyPp2qRlNbpQV+iA9HD9sVI
EDIsS+/+WWqsbToNsABbmy9wXUsSW5mvRfvY23HklDW+NPW49CdeUNzwCMjl
E8ZQGYP16VQ5oxNpB1SdYuUgb+ugiLMCaEDgOV3Urbscd4l4sGePnTvzEgpf
YL9EavfEG2IVylALIc7rJyhCmai1rhaqvGuoG/kGwcBv8PAjLMgkaHd6DiZP
L27G56fOG789PDqmyNqJJaSUGGR+qZE/CyiEhHrqSYFnLuYlcwEuYZ/S3PtQ
KVqZ6I7TXhg0AEwSvbXRme3qcfBUCHGcX7dk0UaEr7Rjy64gyFWXWUrcUbPg
HKh+1batz7hzf3h7QOfeu5zdXO3Dg1DiiWC85TmS+551rokphtDHfKlIN9hS
ZcGDt29pwRYf4XyIIFq/Wd6rmA4UzPFth2mSOgPeE9LyRCSYmYew2EB6nMua
zCaxNKzGrO0Rw0gZixINZ9zMWV91gmrEObsLW7MqdUkfBXmH10931gIViWq7
CMJPk6gKMmpkMrRZyM3rlriP5Eis2ptdf7S+JFYaSYUJlETOWxrg3FWPAgDk
13kpwVItsA0GBFvvcHpET5smFHo7OQb3OBn9cAwjI+m+O4aZUIyRNRUTCVFe
PDPngXSsF5jHaX8/B10FQ90inmvLixeoLorOHX84gPHK2ZnFogKIAMd2k0Uh
cFReVYJKI1lfXRJP0gYnOhiAAuks5DyHYOtEDJZTSMqQku2nRIg+cvXbdYCo
CzVEI8FZa3qIAKyUEts07YQbCgDf8wAeTqQwuHdyfrK/Y5PHR+8PWptEnO5L
gP1BYahILvzqnCvOfdWUr9XiimlrcaHbIubsKOT5VhmTo5idc0pccN4JrQmL
60y7yK2R1DYbX0BGdqu+JiTpAt0m9eWscd5zs9L3SS7BOFfogiJHJ2/oVqHC
+h8Dvd9gp5jdxybEREFKpgs9TyikQLTwQBDAmOSOxrn5mnIlcucSIFI8JCGt
d6yotTrVZlYH/tTt4r9SwJmUHN0Ajw0FKCjoP5h5oZfMaB0Ua5tsmZsp9GdZ
u7L4q59tno3vzMYnyj1KReLS6OvIM5IbdAT/o77XN8TegmB3/jMRpS7ySjR8
78ebywtv8e+Pjj8Ah5wXsq4SA8RBzOqZ0EOCz7GHQY3VB6v/iCMMFdsySrKU
THm37myHAv20jo3Ivb0PstNihET5yuhYUjrpunx/dsv2AkJHLsYTpGJNXKNl
17Oga9nkpDhZNb7Fr+3KzVld6bMtU6MI6usRjtzGpqq8GKOMnnpNB09bgaCW
VZdZn+Fwz2Lo+DRUe/M8J1XJ9qe0dOxR0bUuugaLWmRP7YwsccLpOSJEdrck
Cst6wM+T60gaFxAoMbCtzNqguUWoZkdvWHu0w8R/+yc6pNln+3elBmc5vnJm
srxervxW0KCkE5j4XLUbLO89Pob5ydN+nzysb7vkRdNj+HuLhnsrYqPjukxJ
RPQs7U8S6qQRn68/SpdouzPUX8NC9MeI5QujjCs4jge0CXa/N1ltxohXf/Xm
jC7EZZtULq9oY8ZdGvKwMJqTTHQFN99FMqhSp+zKaQ8EbleGFcmuADkNBPNh
9sxkOaHYp0K4hMdHZJIFWeoiTZarinUX2TzSZpy5IicNuN+fiElkY/a38dil
x89YR1AT+xiAHpG8K7sgBfM4LnvAlIyP5iKzpfhZTgklJZzlc0bnEr5GJlqt
Et9EaoJxVwGAjG29XCLI72bZTmtwDufBmUi0IVzSKRSCIu5GEH6mCSI76Lpx
YTmX54in8w0HWMRKyXztuERLHlUW4mRWr+emJEY6jVs22WzAWNIAvg3LukVU
swgh7qJi8rz6hB4arjPVEdshuzoPHq6YtlXx7XMDFIfUxjvVUBjVM0i0oGDX
7DdVr63iCuoSiFuZY6gFBVXQHEwMNuXUxe3h48se1AObe6WDBnOwF0uB5fHH
ZMBL/AYJkFp8VQhYUyY6UAaVMMj1Zeq1B4Iqh2K2hJxfqUJHd6ZSe6ne0G9v
9h1xlsNQDhoiQ1ttNSZGTsRQeVpE/C7lmbNOy8l3sygVAFCwxJlC14WBeTyg
bJwmXIt3bp+wpgaW2p3gdE5pbjDwgQV9+sCP+MD0/0kvwbr/K70M93I+VapI
7BdDpyrIKBJEUkoiow2lbfds2f0vWODaLEkw5QZePNGZJgTnGB9uHGFFA4lO
SQCYCK+8X4lzI8TS9XyZJf9j2vwiWWa5y4/wCM8YUIahrc2jhMcqmFWkUydk
BHwel7RSoipeDv26Z9vn8BsuCYuHjSUR9llCdjTafKyB3LV7fuZgJHElMxGf
kXkGpV6O1MPiOYXLZV6UnOTCkTpv6TFBEmBiZaSjlZk8n1E2obR18zczPDBG
mFtSWu8iXHKNaSzLb4K4njYeEg33RMSQHbKWIgfdQQKPeEfRQG9hwywfM61D
lzm8O3rzLTf9JLLv5nqU0ddSg3NpBX6si5jl1WEbAlvUuiELDjbGzqVHYhhO
N+eao5hMPGSYRroMxUEoB7qB9+KafhdFxadL08zZiihpxUySRmTYtQiU0zjG
JFun4ML0NgiZhPUwriX5y5Qpy5wHktxPsiDX4fJGOKNwbydibJNkbp0CvSsu
4iLdxxp0oysMe6YiG2gh+U+0J/c6s7y5Bde5pdzgNvkCkl9tMWn1v5ZvI+s9
k+5GOAxKWa/reVDOe+JP35nF2a141UWe7fSx+xulbNaYQdiO+UUMMnjQ0wlL
Ktv1ob5VEeRUxtIdJowNzx3GNM2hUJvaDr4n93e0faS0RcDmz/r7CvrwB7k3
0j6ED5V8FES2RmxLOvNBWk4p1F+bfwa48OJB+PnXh5PDwQ+ky1MVMGAgNYCp
eq68EG7EXq1p0Rif1cfBuFjXXHMXeMl5ulR7mtTRwYG6/Mugg6vIwxg2B6cY
kVafMO5ycKQ+UXh+dHB0oA6Opwfvpm+O1fefbgdhzeGFkwweMUDbFAV4yNqM
+LftjGbary2uprSq1ulw8NRhzWdYSYs0rJjd3K4bRkpdZ/umXEltq5NK4XOQ
/e5hOKrJx1wYuHUA8Sr70gnjAmS3hLlblbj06Rnv6osbEvJ1Rk65p7v1uFu9
D1N70UAv4b5REyVEWbQBSicndHIi4/nJx1xNeOPc3VdMycXxS+eQXqTaUdbV
6D5X+vfW4vfTwzd/SIs5DP7daiwPbtVDguekqDDxj0f5+nWnquAW2M2Fp+rN
0duRo3Wn5iDGt2VD6KlHNfcKZi4wdKEGuupyhRzXZYvHy5wOL1+kTiDNlkTm
sdcoHPjGslvYz77k63Wd+apYdxCQC/wvTQP6MmuTN7m9xYlykFJQ4IwHOZPK
uMvT00GH9YpxubHkce/cckNfYAM+63k2cB3tzGk+PobTYU8Syfczot3INjsF
9utrbw216Hx0W2zuEs7V2cL+hqnL0ZZYHQ4hraFAlfjeFCC3qpy9ceIuOzqV
0Oem4MMju/Cqd0KgU/HzkZXOnm8U+2mGXzO+sDWkqJue2s5cAj/yoO3XBxS+
GrWgl9HQkLSdQC7mUXDMoySojvWRSR4tWnGR3V1zm39ju4NJTUSl9nwOdPrD
7Arh+/nV/Vt1TfEhpmzie/DaihPab3rJkr0g9N3qU3YNHtM3/dtaFTSgiDh+
8QpVDNHWVVJ4n9lO4716pa4A7FEPThVy4QkG0Tp2wIFpx570thU/8woEWma+
RqI9haRQFolyGDm0JRqtFjVGNqALHESjXQZNLGPlTJ+rMaWhhyX/l9wQO/ra
ajP09gxdPZDAz3FS152T2ApeUM5m5emWzHthD6CyTR2POjil1CkGLZarLQwL
arw9pDcY0rwKIqa+hSBMo+/YBhoerLSl6Kwi4HrbD35x4uEmkYhLXiPgkoVq
Ldg1LtBbA1iNukbunBiIadsRD34otu0nh+XuUJeGMN3acmBIdoDskJRqqJpX
btaJTY1udZPIDUYtDo9k1kJmLN4fvcWQvwzJhuMbC9W7DSen5ycXJ7vG0ylq
kfRxU2J9vCcHIoXmBJF+5WpYO25EdP+qLmlTPsOFpyepIDbrCaZyQce9X6U5
kyE5Nw/yVYp1ltJAIzzoccMcNH7iXbkZeh3S687KFGzPvgsh8hqBCekGYc9t
hCb46IXzIwfFGvKOY3DbYHBTz6v2UjfYvHYlOwwC0mVQNVUXr08oCnP1ut0r
Z1mUx+L4Q/lO1TMXGBRkJjHyc2sA7DbJ8V6uc7yd5jedxIP+9s7QXvh7F0My
OhPF3JjjKsruI12ZeFqsVwWn3W50bo2XKJamDZaa92Wa7K80+YJIvKrnKdp7
sV9STrO132AQvIfo4KfJGNsju6cCFeGE0tWXZaTbz834cqZDh+dnIF1B0Jf1
HR7j9ly8zFaBCAb9XamX63aQmae4txnKunHSvLcWui938Yo9m7y/h7dc/VS2
G9mqUB5j46xLLvl1VoCIZdbIfkPhgh/ndmgiAme21JDUVOF1qMsLaLirxXJJ
M/OXhVp5GVrNTq6uLq9v1fnZ7Xfqp+8Hg5kMykaS56V4qwzXnoOCbvXe2X4L
Ii3SaXvXRTliBRIqLndrniNsYApxKt08fGa/4cjFo1xugNBJ/kE3gkvFlt3V
1ydfpIEjE42pz4TbxKuhCZbcOD2OsdspG5TBzjAMjm7HxrvJ9jhS1N9+i1GA
mJJuOtN0IC/v+UOQekv1W/AS0SCtKq18Z6cO9qbKPcpGEk4sSPldTIUL7zFn
CkHNz91BD24V/YLBnsHglFMLxkSQeaLmZWIWLuPgn/GyYepKEQLsWl6UDLYZ
8dg9xWTSoXPmyxb5Oi/9Rbvyrj58LQ/jlmK0QMIOuDBBzWSmlHk78CMIE750
5ZtAjmiZf2fboNUvSA+R4C6ztib0VbX3PR8dE2Q6gYFo1v12iLBDuWr9T05w
uGneKzx6C65Doqf8kjSXac6+4G8O4Alo+uQr2p25O/OFE/KIpevRVoeDcn5e
l42ErQ5jnhqv6g4KgHeE6PWe4Injmg4bgzA8a952Vvy3NSDNIMrFkMzXCNVV
S8NKE1f1gEfdGqWBaNzcr4OKOmvf5ZO4y7VtEGCnupCKFp/fj/lMRELN7K4/
CxEzyMhsl6hc0FfARKT5nRp+HyCqU11ym9cET/NQVDgn4t+UAy8AnJ7dI76d
hJDXeD8aZx9gC4oec4Bd05qCr1okX2SGL7rL8gcCvKWo3OMrNB7v8CKhD6Bk
WHC78Yhc2FaYEmRt+4TptVM4NUw1gY30y5IIqtSMEieT8V8JQQtzGo63tgAF
/j175wfwMiqY+D3+9g2C2Zyzcul1JVlRE+z8DdUDh+U3RAAA
<!-- [rfced] Note that we have updated the reference for
draft-ietf-capport-rfc7710bis to refer to RFC-to-be 8910. We expect to
initiate AUTH48 for RFC 8910 next week.
--> -->
<!-- draft-ietf-capport-rfc7710bis-07: Submitted to IESG for Publication -->
<reference anchor='RFC8910' target="https://www.rfc-editor.org/info/rfc8910">
<front>
<title>Captive-Portal Identification in DHCP / Router Advertisement (RA)</title>
<author initials='W' surname='Kumari' fullname='Warren Kumari'>
<organization />
</author>
<author initials='E' surname='Kline' fullname='Erik Kline'>
<organization />
</author>
<date month='September' year='2020' />
</front>
<seriesInfo name='RFC' value='8910' />
<seriesInfo name="DOI" value="10.17487/RFC8910"/>
</reference>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.7525.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
ence.RFC.8264.xml"/>
</references>
</references>
<section anchor="thanksall" numbered="false" toc="default">
<name>Acknowledgments</name>
<t>This work was started by <contact fullname="Mark
Donnelly"/> and <contact fullname="Margaret Cullen"/>. Thanks to
everyone in the CAPPORT Working Group who has given input.</t>
</section>
</back>
</rfc> </rfc>
 End of changes. 37 change blocks. 
843 lines changed or deleted 489 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/