File: rfc8908.html

package info (click to toggle)
doc-rfc 20201128-1
links: PTS, VCS
area: non-free
in suites: bullseye
size: 1,307,124 kB
file content (1966 lines) | stat: -rw-r--r-- 77,130 bytes
parent folder | download | duplicates (2)
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 8908: Captive Portal API</title>
<meta content="Tommy Pauly" name="author">
<meta content="Darshak Thakore" name="author">
<meta content="
       This document describes an HTTP API that allows clients to interact
      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. 
    " name="description">
<meta content="xml2rfc 3.1.1" name="generator">
<meta content="8908" name="rfc.number">
<link href="rfc8908.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8908" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-capport-api-08" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 8908</td>
<td class="center">Captive Portal API</td>
<td class="right">September 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Pauly &amp; Thakore</td>
<td class="center">Standards Track</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8908" class="eref">8908</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-09" class="published">September 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">T. Pauly, <span class="editor">Ed.</span>
</div>
<div class="org">Apple Inc.</div>
</div>
<div class="author">
      <div class="author-name">D. Thakore, <span class="editor">Ed.</span>
</div>
<div class="org">CableLabs</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8908</h1>
<h1 id="title">Captive Portal API</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes an HTTP API that allows clients to interact
      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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc8908">https://www.rfc-editor.org/info/rfc8908</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2020 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-terminology" class="xref">Terminology</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-workflow" class="xref">Workflow</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-api-connection-details" class="xref">API Connection Details</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-server-authentication" class="xref">Server Authentication</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-api-state-structure" class="xref">API State Structure</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-example-interaction" class="xref">Example Interaction</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-privacy-considerations" class="xref">Privacy Considerations</a><a href="#section-toc.1-1.7.2.1.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-captive-portal-api-json-med" class="xref">Captive Portal API JSON Media Type Registration</a><a href="#section-toc.1-1.8.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-captive-portal-api-keys-reg" class="xref">Captive Portal API Keys Registry</a><a href="#section-toc.1-1.8.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-references" class="xref">References</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="compact toc ulEmpty">
<li class="compact toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="compact toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="compact toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">This document describes a HyperText Transfer Protocol (HTTP)
      Application Programming Interface (API) that allows clients to interact with
      a Captive Portal system. The API defined in this document has been
      designed to meet the requirements in the Captive Portal Architecture
      <span>[<a href="#I-D.ietf-capport-architecture" class="xref">CAPPORT-ARCH</a>]</span>. Specifically, the API provides:<a href="#section-1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-2.1">The state of captivity (whether or not the client has access to
 the Internet).<a href="#section-1-2.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.2">A URI of a user-facing web portal that can be used to get out of
 captivity.<a href="#section-1-2.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-2.3">Authenticated and encrypted connections, using TLS for connections
 to both the API and user-facing web portal.<a href="#section-1-2.3" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="terms">
<section id="section-2">
      <h2 id="name-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
      </h2>
<p id="section-2-1">This document leverages the terminology and components described in
      <span>[<a href="#I-D.ietf-capport-architecture" class="xref">CAPPORT-ARCH</a>]</span> and
      additionally defines the following terms:<a href="#section-2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-2-2">
        <dt id="section-2-2.1">Captive Portal Client</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.2">The client that interacts with the Captive
 Portal API is typically some application running on the user equipment
 that is connected to the captive network. This is also referred to as
 the "client" in this document.<a href="#section-2-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-2-2.3">Captive Portal API Server</dt>
        <dd style="margin-left: 1.5em" id="section-2-2.4">The server exposing the APIs defined in
 this document to the client. This is also referred to as the "API
 server" in this document.<a href="#section-2-2.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-2-3">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>", 
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as 
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="workflow">
<section id="section-3">
      <h2 id="name-workflow">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-workflow" class="section-name selfRef">Workflow</a>
      </h2>
<p id="section-3-1">The Captive Portal Architecture defines several categories of
      interaction between clients and Captive Portal systems:<a href="#section-3-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3-2">
        <li id="section-3-2.1">Provisioning, in which a client discovers that a network has a
 captive portal and learns the URI of the API server.<a href="#section-3-2.1" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.2">API Server interaction, in which a client queries the state of
 captivity and retrieves the necessary information to get out of
 captivity<a href="#section-3-2.2" class="pilcrow">¶</a>
</li>
        <li id="section-3-2.3">Enforcement, in which the enforcement device in the network blocks
 disallowed traffic.<a href="#section-3-2.3" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-3-3">This document defines the mechanisms used in the second category. It
      is assumed that the location of the Captive Portal API server has been
      discovered by the client as part of provisioning. A set of mechanisms
      for discovering the API server endpoint is defined in <span>[<a href="#RFC8910" class="xref">RFC8910</a>]</span>.<a href="#section-3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="api-details">
<section id="section-4">
      <h2 id="name-api-connection-details">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-api-connection-details" class="section-name selfRef">API Connection Details</a>
      </h2>
<p id="section-4-1">The API server endpoint <span class="bcp14">MUST</span> be accessed over HTTP
      using an https URI <span>[<a href="#RFC2818" class="xref">RFC2818</a>]</span> and
      <span class="bcp14">SHOULD</span> use the default https port. For example, if the
      Captive Portal API server is hosted at "example.org", the URI of the API
      could be "https://example.org/captive-portal/api".<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">The client <span class="bcp14">SHOULD NOT</span> assume that the URI of the API
      server for a given network will stay the same and <span class="bcp14">SHOULD</span>
      rely on the discovery or provisioning process each time it joins the
      network.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">As described in <span><a href="https://tools.ietf.org/html/draft-ietf-capport-architecture-08#section-3" class="relref">Section 3</a> of [<a href="#I-D.ietf-capport-architecture" class="xref">CAPPORT-ARCH</a>]</span>, 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 set of IP addresses, the system needs to ensure that the same
      IP addresses are visible to both the API server and the enforcement
      device.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">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 <span class="bcp14">SHOULD</span> 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.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">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.<a href="#section-4-5" class="pilcrow">¶</a></p>
<div id="server-auth">
<section id="section-4.1">
        <h3 id="name-server-authentication">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-server-authentication" class="section-name selfRef">Server Authentication</a>
        </h3>
<p id="section-4.1-1">The purpose of accessing the Captive Portal API over an HTTPS
 connection is twofold: first, the encrypted connection protects the
 integrity and confidentiality of the API exchange from other parties
 on the local network; second, it provides the client of the API an
 opportunity to authenticate the server that is hosting the API. This
 authentication allows the client to ensure that the entity providing
 the Captive Portal API has a valid certificate for the hostname
 provisioned by the network using the mechanisms defined in <span>[<a href="#RFC8910" class="xref">RFC8910</a>]</span>, by validating
 that a DNS-ID <span>[<a href="#RFC6125" class="xref">RFC6125</a>]</span> on the
 certificate is equal to the provisioned hostname.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Clients performing revocation checking will need some means of
 accessing revocation information for certificates presented by the API
 server. Online Certificate Status Protocol <span>[<a href="#RFC6960" class="xref">RFC6960</a>]</span> (OCSP) stapling, using the TLS Certificate Status
 Request extension <span>[<a href="#RFC6066" class="xref">RFC6066</a>]</span>,
 <span class="bcp14">SHOULD</span> be used. OCSP stapling allows a client to
 perform revocation checks without initiating new connections. To allow
 for other forms of revocation checking, especially for clients that do
 not support OCSP stapling, a captive network <span class="bcp14">SHOULD</span>
 permit connections to OCSP responders or Certificate Revocation Lists
 (CRLs) that are referenced by certificates provided by the API
 server. For more discussion on certificate revocation checks, see
 <span><a href="https://www.rfc-editor.org/rfc/rfc7525#section-6.5" class="relref">Section 6.5</a> of BCP 195 [<a href="#RFC7525" class="xref">RFC7525</a>]</span>. In
 addition to connections to OCSP responders and CRLs, a captive network
 <span class="bcp14">SHOULD</span> also permit connections to Network Time Protocol
 (NTP) <span>[<a href="#RFC5905" class="xref">RFC5905</a>]</span> servers or other
 time-sync mechanisms to allow clients to accurately validate
 certificates.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">Certificates with missing intermediate certificates that rely on
 clients validating the certificate chain using the URI specified in
 the Authority Information Access (AIA) extension <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> <span class="bcp14">SHOULD NOT</span> be used
 by the Captive Portal API server. If the certificates do require the
 use of AIA, the captive network <span class="bcp14">MUST</span> allow client
 access to the host specified in the URI.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">If the client is unable to validate the certificate presented by
 the API server, it <span class="bcp14">MUST NOT</span> 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.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="json-keys">
<section id="section-5">
      <h2 id="name-api-state-structure">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-api-state-structure" class="section-name selfRef">API State Structure</a>
      </h2>
<p id="section-5-1">The Captive Portal API data structures are specified in JavaScript
      Object Notation (JSON) <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>. Requests and responses for the Captive Portal API
      use the "application/captive+json" media type. Clients
      <span class="bcp14">SHOULD</span> include this media type as an Accept header in
      their GET requests, and servers <span class="bcp14">MUST</span> mark this media type
      as their Content-Type header in responses.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">The following key <span class="bcp14">MUST</span> be included in the top level of
      the JSON structure returned by the API server:<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="tab1">
<table class="center" id="table-1">
        <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Key</th>
            <th class="text-left" rowspan="1" colspan="1">Type</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">captive</td>
            <td class="text-left" rowspan="1" colspan="1">boolean</td>
            <td class="text-left" rowspan="1" colspan="1">Indicates whether the client is in a state of
        captivity, i.e, it has not satisfied the conditions to access the
        external network. If the client is captive (i.e., captive=true), it
        will still be allowed enough access for it to perform server
        authentication (<a href="#server-auth" class="xref">Section 4.1</a>).
      </td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-5-4">The following keys can be optionally included in the top level of the
      JSON structure returned by the API server:<a href="#section-5-4" class="pilcrow">¶</a></p>
<div id="tab2">
<table class="center" id="table-2">
        <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Key</th>
            <th class="text-left" rowspan="1" colspan="1">Type</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">user-portal-url</td>
            <td class="text-left" rowspan="1" colspan="1">string</td>
            <td class="text-left" rowspan="1" colspan="1">Provides the URL of a web portal that <span class="bcp14">MUST</span> be accessed over TLS with
      which a user can interact.</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">venue-info-url</td>
            <td class="text-left" rowspan="1" colspan="1">string</td>
            <td class="text-left" rowspan="1" colspan="1">Provides the URL of a webpage or site that <span class="bcp14">SHOULD</span> 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).</td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">can-extend-session</td>
            <td class="text-left" rowspan="1" colspan="1">boolean</td>
            <td class="text-left" rowspan="1" colspan="1">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 class="text-left" rowspan="1" colspan="1">seconds-remaining</td>
            <td class="text-left" rowspan="1" colspan="1">number</td>
            <td class="text-left" rowspan="1" colspan="1">An integer that indicates the number 
        of seconds remaining, after which the client will be placed into a 
        captive state. The API server <span class="bcp14">SHOULD</span> include this value
        if the client is not captive (i.e., captive=false) and the client
        session is time-limited and <span class="bcp14">SHOULD</span> omit this value for
        captive clients (i.e., captive=true) or when the session is not
        time-limited.
      </td>
          </tr>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">bytes-remaining</td>
            <td class="text-left" rowspan="1" colspan="1">number</td>
            <td class="text-left" rowspan="1" colspan="1">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 <span class="bcp14">SHOULD</span> include this value if the client is not
        captive (i.e., captive=false) and the client session is byte-limited
        and <span class="bcp14">SHOULD</span> omit this value for captive clients
        (i.e., captive=true) or when the session is not byte-limited.
      </td>
          </tr>
        </tbody>
      </table>
</div>
<p id="section-5-6">The valid JSON keys can be extended by adding entries to the Captive
      Portal API Keys Registry (<a href="#iana-field-reg" class="xref">Section 8.2</a>). If a client receives a key that it does not
      recognize, it <span class="bcp14">MUST</span> ignore the key and any associated
      values. All keys other than the ones defined in this document as
      "required" will be considered optional.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">Captive Portal JSON content can contain per-client data that is not
      appropriate to store in an intermediary cache. Captive Portal API
      servers <span class="bcp14">SHOULD</span> set the Cache-Control header field in any
      responses to "private" or a more restrictive value, such as "no-store"
      <span>[<a href="#RFC7234" class="xref">RFC7234</a>]</span>.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">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 <span class="bcp14">SHOULD</span> 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.<a href="#section-5-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="example">
<section id="section-6">
      <h2 id="name-example-interaction">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-example-interaction" class="section-name selfRef">Example Interaction</a>
      </h2>
<p id="section-6-1">Upon discovering the URI of the API server, 
      a client connected to a captive network
      will query the API server to retrieve information about
      its captive state and conditions to escape captivity. In this example,
      the client discovered the URI
      "https://example.org/captive-portal/api/X54PD39JV" using one of the
      mechanisms defined in <span>[<a href="#RFC8910" class="xref">RFC8910</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">To request the Captive Portal JSON content, a client sends an HTTP
      GET request:<a href="#section-6-2" class="pilcrow">¶</a></p>
<div id="section-6-3">
<pre class="sourcecode lang-http-message">
GET /captive-portal/api/X54PD39JV HTTP/1.1
Host: example.org
Accept: application/captive+json
</pre><a href="#section-6-3" class="pilcrow">¶</a>
</div>
<p id="section-6-4">The server then responds with the JSON content for that client:<a href="#section-6-4" class="pilcrow">¶</a></p>
<div id="section-6-5">
<pre class="sourcecode lang-http-message">
HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 02 Mar 2020 05:07:35 GMT
Content-Type: application/captive+json

{
   "captive": true,
   "user-portal-url": "https://example.org/portal.html"
}
</pre><a href="#section-6-5" class="pilcrow">¶</a>
</div>
<p id="section-6-6">Upon receiving this information, the client will use it
      to direct the user to the web portal (as specified by the
      user-portal-url value) to enable access to the external network. Once
      the user satisfies the requirements for external network access, the
      client <span class="bcp14">SHOULD</span> query the API server again to verify that
      it is no longer captive.<a href="#section-6-6" class="pilcrow">¶</a></p>
<p id="section-6-7">When the client requests the Captive Portal JSON content after
      gaining external network access, the server responds with updated JSON
      content:<a href="#section-6-7" class="pilcrow">¶</a></p>
<div id="section-6-8">
<pre class="sourcecode lang-http-message">
HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 02 Mar 2020 05:08:13 GMT
Content-Type: application/captive+json

{
   "captive": false,
   "user-portal-url": "https://example.org/portal.html",
   "venue-info-url": "https://flight.example.com/entertainment",
   "seconds-remaining": 326,
   "can-extend-session": true
}
</pre><a href="#section-6-8" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="security">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-7-1">One of the goals of this protocol is to improve the security of the
      communication between client hosts and Captive Portal systems. Client
      traffic is protected from passive listeners on the local network by
      requiring TLS-encrypted connections between the client and the Captive
      Portal API server, as described in <a href="#api-details" class="xref">Section 4</a>. All communication between the clients and the API
      server <span class="bcp14">MUST</span> be encrypted.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">In addition to encrypting communications between clients and Captive
      Portal systems, this protocol requires a basic level of authentication
      from the API server, as described in <a href="#server-auth" class="xref">Section 4.1</a>. Specifically, the API server <span class="bcp14">MUST</span>
      present a valid certificate on which the client can perform revocation
      checks. This allows the client to ensure that the API server has
      authority for the hostname that was provisioned by the network using
      <span>[<a href="#RFC8910" class="xref">RFC8910</a>]</span>. Note that
      this validation only confirms that the API server matches what the
      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.<a href="#section-7-2" class="pilcrow">¶</a></p>
<div id="privacy">
<section id="section-7.1">
        <h3 id="name-privacy-considerations">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
        </h3>
<p id="section-7.1-1">Information passed between a client and the user-facing web portal
 may include a user's personal information, such as a full name and
 credit card details. Therefore, it is important that both the
 user-facing web portal and the API server that points a client to the
 web portal are only accessed over encrypted connections.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2">It is important to note that although communication to the
 user-facing web portal requires use of TLS, the authentication only
 validates that the web portal server matches the name in the URI
 provided by the API server. Since this is not a name that a user typed
 in, the hostname of the website that would be presented to the user
 may include "confusable characters", which can mislead the user. See
 <span><a href="https://www.rfc-editor.org/rfc/rfc8264#section-12.5" class="relref">Section 12.5</a> of [<a href="#RFC8264" class="xref">RFC8264</a>]</span> for a
 discussion of confusable characters.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="iana-section">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-8-1">IANA has registered the
      "application/captive+json" media type (<a href="#iana-json" class="xref">Section 8.1</a>) and created a registry for fields in that format (<a href="#iana-field-reg" class="xref">Section 8.2</a>).<a href="#section-8-1" class="pilcrow">¶</a></p>
<div id="iana-json">
<section id="section-8.1">
        <h3 id="name-captive-portal-api-json-med">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-captive-portal-api-json-med" class="section-name selfRef">Captive Portal API JSON Media Type Registration</a>
        </h3>
<p id="section-8.1-1">This document registers the media type for Captive Portal API JSON
 text, "application/captive+json".<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.1-2">
          <dt id="section-8.1-2.1">Type name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.2">application<a href="#section-8.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.3">Subtype name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.4">captive+json<a href="#section-8.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.5">Required parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.6">N/A<a href="#section-8.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.7">Optional parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.8">N/A<a href="#section-8.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.9">Encoding considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.10">Encoding considerations are identical to those specified for the
 "application/json" media type.<a href="#section-8.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.11">Security considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.12">See <a href="#security" class="xref">Section 7</a><a href="#section-8.1-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.13">Interoperability considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.14">This document specifies format of conforming messages and the
 interpretation thereof.<a href="#section-8.1-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.15">Published specification:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.16">RFC 8908<a href="#section-8.1-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.17">Applications that use this media type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.18">This media type is intended to be used by servers presenting the
 Captive Portal API, and clients connecting to such captive
 networks.<a href="#section-8.1-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.19">Fragment identifier considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.20">N/A<a href="#section-8.1-2.20" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.21">Additional Information:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.22">N/A<a href="#section-8.1-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.23">Person and email address to contact for further information:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.24">
            <br>See Authors' Addresses section<a href="#section-8.1-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.25">Intended usage:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.26">COMMON<a href="#section-8.1-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.27">Restrictions on usage:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.28">N/A<a href="#section-8.1-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.29">Author:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.30">CAPPORT IETF WG<a href="#section-8.1-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.31">Change controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.32">IETF<a href="#section-8.1-2.32" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="iana-field-reg">
<section id="section-8.2">
        <h3 id="name-captive-portal-api-keys-reg">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-captive-portal-api-keys-reg" class="section-name selfRef">Captive Portal API Keys Registry</a>
        </h3>
<p id="section-8.2-1">IANA has created a new registry called "Captive
 Portal API Keys", which reserves JSON keys for use in Captive
 Portal API data structures. The initial contents of this registry are
 provided in <a href="#json-keys" class="xref">Section 5</a>.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">Each entry in the registry contains the following fields:<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.2-3">
          <dt id="section-8.2-3.1">Key:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-3.2">The JSON key being registered in string format.<a href="#section-8.2-3.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-3.3">Type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-3.4">The type of the JSON value to be stored, as one of the value
   types defined in <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>.<a href="#section-8.2-3.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-3.5">Description:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-3.6">A brief description explaining the meaning of the value, how it
   might be used, and/or how it should be interpreted by clients.<a href="#section-8.2-3.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-3.7">Reference:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-3.8">A reference to a specification that defines the key and explains
   its usage.<a href="#section-8.2-3.8" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-8.2-4">New assignments for the "Captive Portal API Keys" registry will be
 administered by IANA using the Specification Required policy <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>. The designated expert is expected
 to validate the existence of documentation describing new keys in a
 permanent, publicly available specification, such as an Internet-Draft
 or RFC. The expert is expected to validate that new keys have a clear
 meaning and do not create unnecessary confusion or overlap with
 existing keys. Keys that are specific to nongeneric use cases,
 particularly ones that are not specified as part of an IETF document,
 are encouraged to use a domain-specific prefix.<a href="#section-8.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2818">[RFC2818]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"HTTP Over TLS"</span>, <span class="seriesInfo">RFC 2818</span>, <span class="seriesInfo">DOI 10.17487/RFC2818</span>, <time datetime="2000-05" class="refDate">May 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2818">https://www.rfc-editor.org/info/rfc2818</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5280">[RFC5280]</dt>
        <dd>
<span class="refAuthor">Cooper, D.</span><span class="refAuthor">, Santesson, S.</span><span class="refAuthor">, Farrell, S.</span><span class="refAuthor">, Boeyen, S.</span><span class="refAuthor">, Housley, R.</span><span class="refAuthor">, and W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5905">[RFC5905]</dt>
        <dd>
<span class="refAuthor">Mills, D.</span><span class="refAuthor">, Martin, J., Ed.</span><span class="refAuthor">, Burbank, J.</span><span class="refAuthor">, and W. Kasch</span>, <span class="refTitle">"Network Time Protocol Version 4: Protocol and Algorithms Specification"</span>, <span class="seriesInfo">RFC 5905</span>, <span class="seriesInfo">DOI 10.17487/RFC5905</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5905">https://www.rfc-editor.org/info/rfc5905</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6066">[RFC6066]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Transport Layer Security (TLS) Extensions: Extension Definitions"</span>, <span class="seriesInfo">RFC 6066</span>, <span class="seriesInfo">DOI 10.17487/RFC6066</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6125">[RFC6125]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and J. Hodges</span>, <span class="refTitle">"Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 6125</span>, <span class="seriesInfo">DOI 10.17487/RFC6125</span>, <time datetime="2011-03" class="refDate">March 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6125">https://www.rfc-editor.org/info/rfc6125</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6960">[RFC6960]</dt>
        <dd>
<span class="refAuthor">Santesson, S.</span><span class="refAuthor">, Myers, M.</span><span class="refAuthor">, Ankney, R.</span><span class="refAuthor">, Malpani, A.</span><span class="refAuthor">, Galperin, S.</span><span class="refAuthor">, and C. Adams</span>, <span class="refTitle">"X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"</span>, <span class="seriesInfo">RFC 6960</span>, <span class="seriesInfo">DOI 10.17487/RFC6960</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6960">https://www.rfc-editor.org/info/rfc6960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7234">[RFC7234]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor">, Nottingham, M., Ed.</span><span class="refAuthor">, and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Caching"</span>, <span class="seriesInfo">RFC 7234</span>, <span class="seriesInfo">DOI 10.17487/RFC7234</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7234">https://www.rfc-editor.org/info/rfc7234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span><span class="refAuthor">, Leiba, B.</span><span class="refAuthor">, and T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
      <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="I-D.ietf-capport-architecture">[CAPPORT-ARCH]</dt>
        <dd>
<span class="refAuthor">Larose, K.</span><span class="refAuthor">, Dolson, D.</span><span class="refAuthor">, and H. Liu</span>, <span class="refTitle">"CAPPORT Architecture"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-capport-architecture-08</span>, <time datetime="2020-05-11" class="refDate">11 May 2020</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-ietf-capport-architecture-08">https://tools.ietf.org/html/draft-ietf-capport-architecture-08</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7525">[RFC7525]</dt>
        <dd>
<span class="refAuthor">Sheffer, Y.</span><span class="refAuthor">, Holz, R.</span><span class="refAuthor">, and P. Saint-Andre</span>, <span class="refTitle">"Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">BCP 195</span>, <span class="seriesInfo">RFC 7525</span>, <span class="seriesInfo">DOI 10.17487/RFC7525</span>, <time datetime="2015-05" class="refDate">May 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7525">https://www.rfc-editor.org/info/rfc7525</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8264">[RFC8264]</dt>
        <dd>
<span class="refAuthor">Saint-Andre, P.</span><span class="refAuthor"> and M. Blanchet</span>, <span class="refTitle">"PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols"</span>, <span class="seriesInfo">RFC 8264</span>, <span class="seriesInfo">DOI 10.17487/RFC8264</span>, <time datetime="2017-10" class="refDate">October 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8264">https://www.rfc-editor.org/info/rfc8264</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8910">[RFC8910]</dt>
      <dd>
<span class="refAuthor">Kumari, W.</span><span class="refAuthor"> and E. Kline</span>, <span class="refTitle">"Captive-Portal Identification in DHCP and Router Advertisement (RA)"</span>, <span class="seriesInfo">RFC 8910</span>, <span class="seriesInfo">DOI 10.17487/RFC8910</span>, <time datetime="2020-09" class="refDate">September 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8910">https://www.rfc-editor.org/info/rfc8910</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="thanksall">
<section id="section-appendix.a">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="section-appendix.a-1">This work was started by <span class="contact-name">Mark       Donnelly</span> and <span class="contact-name">Margaret Cullen</span>. Thanks to
      everyone in the CAPPORT Working Group who has given input.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Tommy Pauly (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">Apple Inc.</span></div>
<div dir="auto" class="left"><span class="street-address">One Apple Park Way</span></div>
<div dir="auto" class="left">
<span class="locality">Cupertino</span>, <span class="region">CA</span> <span class="postal-code">95014</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:tpauly@apple.com" class="email">tpauly@apple.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Darshak Thakore (<span class="role">editor</span>)</span></div>
<div dir="auto" class="left"><span class="org">CableLabs</span></div>
<div dir="auto" class="left"><span class="street-address">858 Coal Creek Circle</span></div>
<div dir="auto" class="left">
<span class="locality">Louisville</span>, <span class="region">CO</span> <span class="postal-code">80027</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:d.thakore@cablelabs.com" class="email">d.thakore@cablelabs.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>