File: rfc8752.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (2466 lines) | stat: -rw-r--r-- 124,794 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 8752: Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)</title>
<meta content="Martin Thomson" name="author">
<meta content="Mark Nottingham" name="author">
<meta content="
       The Exploring Synergy between Content Aggregation and the Publisher Ecosystem
(ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in
July 2019. This report summarizes its significant points of discussion and
identifies topics that may warrant further consideration. 
       Note that this document is a report on the proceedings of the 
workshop.  The views and positions documented in this report are 
those of the workshop participants and do not necessarily reflect IAB 
views and positions. 
    " name="description">
<meta content="xml2rfc 2.40.1" name="generator">
<meta content="web" name="keyword">
<meta content="security" name="keyword">
<meta content="origin" name="keyword">
<meta content="packaging" name="keyword">
<meta content="bundle" name="keyword">
<meta content="8752" name="rfc.number">
<link href="rfc8752.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;
  }

}
/* Avoid wrapping of URLs in references */
@media screen {
  .references a {
    white-space: nowrap;
  }
}
/* 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: 0 0 0.25em 0;
  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;
  }
}
/*
  The margin-left: 0 on <dd> removes all distinction
  between levels from nested <dl>s.  Undo that.
*/
dl.olPercent > dd,
dd {
  margin-left: revert;
}
/* 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; }
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8752" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-iab-escape-report-00" 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 8752</td>
<td class="center">ESCAPE Workshop Report</td>
<td class="right">March 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Thomson &amp; Nottingham</td>
<td class="center">Informational</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 Architecture Board (IAB)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc8752" class="eref">8752</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-03" class="published">March 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">M. Thomson</div>
</div>
<div class="author">
      <div class="author-name">M. Nottingham</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8752</h1>
<h1 id="title">Report from the IAB Workshop on Exploring Synergy between Content Aggregation and the Publisher Ecosystem (ESCAPE)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">The Exploring Synergy between Content Aggregation and the Publisher Ecosystem
(ESCAPE) Workshop was convened by the Internet Architecture Board (IAB) in
July 2019. This report summarizes its significant points of discussion and
identifies topics that may warrant further consideration.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">Note that this document is a report on the proceedings of the 
workshop.  The views and positions documented in this report are 
those of the workshop participants and do not necessarily reflect IAB 
views and positions.<a href="#section-abstract-2" 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 document is not an Internet Standards Track specification; it is
            published for informational purposes.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            This document is a product of the Internet Architecture Board
            (IAB) and represents information that the IAB has deemed valuable
            to provide for permanent record.  It represents the consensus of the Internet
            Architecture Board (IAB).  Documents approved for publication
            by the IAB are not candidates for any level of Internet Standard; see
            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/rfc8752">https://www.rfc-editor.org/info/rfc8752</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.<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="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><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>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-mention-of-specific-entitie" class="xref">Mention of Specific Entities</a><a href="#section-toc.1-1.1.2.1.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-use-cases" class="xref">Use Cases</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-instant-navigation" class="xref">Instant Navigation</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-offline-content-sharing" class="xref">Offline Content Sharing</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-other-use-cases" class="xref">Other Use Cases</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.2.2.3.2.1">
                    <p id="section-toc.1-1.2.2.3.2.1.1"><a href="#section-2.3.1" class="xref">2.3.1</a>.  <a href="#name-book-publishing" class="xref">Book Publishing</a><a href="#section-toc.1-1.2.2.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.2.2.3.2.2">
                    <p id="section-toc.1-1.2.2.3.2.2.1"><a href="#section-2.3.2" class="xref">2.3.2</a>.  <a href="#name-web-archiving" class="xref">Web Archiving</a><a href="#section-toc.1-1.2.2.3.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-interactions-between-web-pu" class="xref">Interactions between Web Publishers and Aggregators</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-incentives-for-web-packages" class="xref">Incentives for Web Packages</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-operational-costs" class="xref">Operational Costs</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-content-regulation" class="xref">Content Regulation</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-web-performance" class="xref">Web Performance</a><a href="#section-toc.1-1.3.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="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-systemic-effects" class="xref">Systemic Effects</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="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-consolidation" class="xref">Consolidation</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.1">
                    <p id="section-toc.1-1.4.2.1.2.1.1"><a href="#section-4.1.1" class="xref">4.1.1</a>.  <a href="#name-consolidation-of-power-in-l" class="xref">Consolidation of Power in Linking Sites</a><a href="#section-toc.1-1.4.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.2">
                    <p id="section-toc.1-1.4.2.1.2.2.1"><a href="#section-4.1.2" class="xref">4.1.2</a>.  <a href="#name-consolidation-of-power-in-p" class="xref">Consolidation of Power in Publishers</a><a href="#section-toc.1-1.4.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.1.2.3">
                    <p id="section-toc.1-1.4.2.1.2.3.1"><a href="#section-4.1.3" class="xref">4.1.3</a>.  <a href="#name-consolidation-of-user-prefe" class="xref">Consolidation of User Preferences</a><a href="#section-toc.1-1.4.2.1.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-effect-on-web-security" class="xref">Effect on Web Security</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-privacy-of-content" class="xref">Privacy of Content</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="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-amp-issues-unrelated-to-web" class="xref">AMP Issues Unrelated to Web Packaging</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-amp-governance" class="xref">AMP Governance</a><a href="#section-toc.1-1.5.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-constraints-on-the-amp-form" class="xref">Constraints on the AMP Format</a><a href="#section-toc.1-1.5.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-performance" class="xref">Performance</a><a href="#section-toc.1-1.5.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-implementation-of-paywalls" class="xref">Implementation of Paywalls</a><a href="#section-toc.1-1.5.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="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-venues-for-future-discussio" class="xref">Venues for Future Discussion</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
<li class="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>
</li>
<li class="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-informative-references" class="xref">Informative References</a><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-appendix.a" class="xref">Appendix A</a>.  <a href="#name-about-the-workshop" class="xref">About the Workshop</a><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-a.1" class="xref">A.1</a>.  <a href="#name-agenda" class="xref">Agenda</a><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1.2.1">
                    <p id="section-toc.1-1.9.2.1.2.1.1"><a href="#section-a.1.1" class="xref">A.1.1</a>.  <a href="#name-thursday-2019-07-18" class="xref">Thursday 2019-07-18</a><a href="#section-toc.1-1.9.2.1.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.1.2.2">
                    <p id="section-toc.1-1.9.2.1.2.2.1"><a href="#section-a.1.2" class="xref">A.1.2</a>.  <a href="#name-friday-2019-07-19" class="xref">Friday 2019-07-19</a><a href="#section-toc.1-1.9.2.1.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-a.2" class="xref">A.2</a>.  <a href="#name-workshop-attendees" class="xref">Workshop Attendees</a><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.b" class="xref">Appendix B</a>.  <a href="#name-web-packaging-overview" class="xref">Web Packaging Overview</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
<ul class="toc ulEmpty">
<li class="toc ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-b.1" class="xref">B.1</a>.  <a href="#name-authority-in-https" class="xref">Authority in HTTPS</a><a href="#section-toc.1-1.10.2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-b.2" class="xref">B.2</a>.  <a href="#name-authority-in-web-packaging" class="xref">Authority in Web Packaging</a><a href="#section-toc.1-1.10.2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-b.3" class="xref">B.3</a>.  <a href="#name-applicability" class="xref">Applicability</a><a href="#section-toc.1-1.10.2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.10.2.4">
                <p id="section-toc.1-1.10.2.4.1"><a href="#section-b.4" class="xref">B.4</a>.  <a href="#name-the-amp-format-google-searc" class="xref">The AMP Format, Google Search Results, and Web Packaging</a><a href="#section-toc.1-1.10.2.4.1" class="pilcrow">¶</a></p>
</li>
</ul>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.c" class="xref"></a><a href="#name-iab-members-at-the-time-of-" class="xref">IAB Members at the Time of Approval</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
<li class="toc ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-appendix.d" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.12.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">The Internet Architecture Board (IAB) holds occasional workshops 
designed to consider long-term issues and strategies for the 
Internet, and to suggest future directions for the Internet 
architecture.  This long-term planning function of the IAB is 
complementary to the ongoing engineering efforts performed by working 
 groups of the Internet Engineering Task Force (IETF).<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The IAB convened the ESCAPE Workshop to examine some proposed changes to the Internet
and the Web, and their potential effects on the Internet publishing landscape.
Of particular interest was the Web Packaging proposal from Google, under
consideration in the IETF, the W3C's Web Incubator Community Group (WICG), and
the Web Hypertext Application Technology Working Group (WHATWG).<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">In considering these proposals, we heard about both positive effects of Web
Packaging and concerns that it could have significant effects on the
relationship between publishers (e.g., news web sites) and content aggregators
(e.g., search engines and social networks). As such, our focus was primarily on
this relationship, rather than technical discussion.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Online publishers do not regularly participate in standards activities
directly. A workshop format was used to solicit input from them. The workshop
had 27 participants from a diverse set of backgrounds, including a small number
of attendees from publishers, one aggregator (Google), plus representatives from
browsers, the Accelerated Mobile Pages (AMP) community, Content Distribution Networks (CDNs), 
network operators, academia, and standards
bodies. See the workshop call for papers <span>[<a href="#CFP" class="xref">CFP</a>]</span> for more information
and a complete listing of submissions.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">As intended, the workshop was primarily a forum for discussion, so it did not
reach definite conclusions. Instead, this report is the primary output of the
workshop, as a record of that discussion.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">This report documents the use cases discussed in <a href="#usecase" class="xref">Section 2</a> and explains the
interactions between publishers and aggregators that might be affected by it in
<a href="#tension" class="xref">Section 3</a>. <a href="#workshop-details" class="xref">Appendix A</a> includes more details about the workshop
itself. For those unfamiliar with Web Packaging, <a href="#overview" class="xref">Appendix B</a> provides a summary
as background material.<a href="#section-1-6" class="pilcrow">¶</a></p>
<div id="mention-of-specific-entities">
<section id="section-1.1">
        <h3 id="name-mention-of-specific-entitie">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-mention-of-specific-entitie" class="section-name selfRef">Mention of Specific Entities</a>
        </h3>
<p id="section-1.1-1">Participants agreed to conduct the workshop under the Chatham House Rule
<span>[<a href="#CHATHAM-HOUSE" class="xref">CHATHAM-HOUSE</a>]</span>, so this report does not attribute statements to individuals
or organizations without express permission. Submissions to the workshop were
public and thus attributable; they are used here to provide substance and
context.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="usecase">
<section id="section-2">
      <h2 id="name-use-cases">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-use-cases" class="section-name selfRef">Use Cases</a>
      </h2>
<p id="section-2-1">Much of the workshop concentrated on discussion of the validity and relative
merits of the use cases that might be enabled by Web Packaging. See
<a href="#overview" class="xref">Appendix B</a> for an overview of Web Packaging.<a href="#section-2-1" class="pilcrow">¶</a></p>
<div id="nav">
<section id="section-2.1">
        <h3 id="name-instant-navigation">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-instant-navigation" class="section-name selfRef">Instant Navigation</a>
        </h3>
<p id="section-2.1-1">The largest use of Web Packaging so far is in Google Search, where packages are
intended to improve the perceived performance of navigation to pages that are
linked from search results when "clicked".<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">To enable this, when a linking (or referring) web page includes links to pages
on another site, it also provides the browser with a packaged copy of the target
content, signed by the origin of the target content. In effect, the referring
page provides a cache for the target page's content. If navigation to one of
those links occurs, having the Web Package gives a browser the assurance that
the cache didn't change the content, so it can treat that content as if it were
acquired directly from the server for the target page -- even though it came from
a different server. In many cases, this results in significantly lower perceived
delay in displaying the target page.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">A vital characteristic of this technique is that the browser does not contact
the target site before navigation. The browser does not make any requests to
sites until after navigation occurs, and only then if the site requires
additional content or makes a request directly.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1-4">Similar improvements could also be realized by downloading content (packaged or
otherwise) directly from the target site through a technique called
"prefetching". However, doing so would reveal information about the user's
activity on the linking page to those sites -- even when the user never actually
navigates to it.<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<aside id="section-2.1-5">
          <p id="section-2.1-5.1">Note: This technique that uses Web Packaging is also referred to as
"privacy-preserving prefetch". This document avoids that term as there was
some contention at the workshop about which aspects of privacy might be
preserved by the technique.<a href="#section-2.1-5.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-2.1-6">Sites bundled with Web Packaging can additionally be constructed in a way that
ensures that they render without needing any additional network access. This
makes it possible to provide near-instantaneous navigation. The proposed changes
to web navigation in support of loading Web Packages is designed to support this
use case.<a href="#section-2.1-6" class="pilcrow">¶</a></p>
<p id="section-2.1-7">Workshop participants recognized the value of web performance for usability, as
well as for business metrics like retention and bounce rates. Such improvements
were seen as a valuable goal, but publishers raised questions about whether they
justified the cost of supporting an additional format, while others raised
concerns about different aspects of the Web Packaging proposal.<a href="#section-2.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="offline">
<section id="section-2.2">
        <h3 id="name-offline-content-sharing">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-offline-content-sharing" class="section-name selfRef">Offline Content Sharing</a>
        </h3>
<p id="section-2.2-1">Another primary use case discussed was the ability to share web content between
devices where neither has an active connection to the Internet. One of the
stated goals of Web Packaging is to enable sharing of content offline.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2">Several participants reported that in areas where Internet access is expensive,
slow, or intermittent, the use of direct peer-to-peer file exchange (e.g.,
"saving a website and sharing it on a USB stick") is commonplace. Most web
browsers already have some affordances for this, but these are recognized as in
need of improvements.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
<p id="section-2.2-3">In the discussion, several rejected an assumed requirement of this
 use case -- that there be no difference between the treatment of a "normal" web page and
that of one loaded from an offline Web Package.<a href="#section-2.2-3" class="pilcrow">¶</a></p>
<p id="section-2.2-4">The ability for a Web Package to provide clear attribution for content was seen
as valuable by some participants for a range of reasons. However, reservations
were expressed about the subtleties of the properties that signatures provide
and the effect of this on web security; see also Sections <a href="#web-sec" class="xref">4.2</a> and <a href="#archive" class="xref">2.3.2</a>.<a href="#section-2.2-4" class="pilcrow">¶</a></p>
<p id="section-2.2-5">Many participants pointed out that using "unsigned bundles" -- that is, Web
Packages without signed exchanges -- could be adequate for this use case, since
most users don't need cryptographic proof of the site's identity.  However, some
expressed concerns that this might worsen the propagation of falsehood.<a href="#section-2.2-5" class="pilcrow">¶</a></p>
<p id="section-2.2-6">Some suggested that the value of signed exchanges was not realized in
small-scale interpersonal exchange of information but in the building of
systems for content delivery that might include capabilities like discovery and
automated distribution. The contention here was that effective use of digital
signatures in offline distribution of content implied considerably more
infrastructure than was described in current proposals.<a href="#section-2.2-6" class="pilcrow">¶</a></p>
<p id="section-2.2-7">No definite conclusions about offline sharing were reached during the workshop.<a href="#section-2.2-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="other-use-cases">
<section id="section-2.3">
        <h3 id="name-other-use-cases">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-other-use-cases" class="section-name selfRef">Other Use Cases</a>
        </h3>
<p id="section-2.3-1">A session on the second morning concentrated on two other significant potential
use cases for Web Packages: book publishing and Web archiving. These were not
seen as "primary" by the proponents of Web Packaging; the original intent was
not to spend significant time on these subjects, but there was considerable
interest from attendees.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<div id="book-publishing">
<section id="section-2.3.1">
          <h4 id="name-book-publishing">
<a href="#section-2.3.1" class="section-number selfRef">2.3.1. </a><a href="#name-book-publishing" class="section-name selfRef">Book Publishing</a>
          </h4>
<p id="section-2.3.1-1">The potential application of a packaging format to book publishing was
discussed, with particular reference to ways that books differ from web
content. Specialists from that industry pointed out that book delivery can vary
greatly from typical web content delivery.<a href="#section-2.3.1-1" class="pilcrow">¶</a></p>
<p id="section-2.3.1-2">Workshop participants briefly explored existing solutions. PDF was seen as
particularly challenging for this use case, due to its limitations, and EPUB
has constraints that also make it challenging for publishers.<a href="#section-2.3.1-2" class="pilcrow">¶</a></p>
<p id="section-2.3.1-3">Although Web Packaging might help to address this use case, the question of how
to identify book content was not resolved. The use of signed exchanges in this
context might offer means of tying content in books to a website, but several
limitations inherent in doing that were identified.<a href="#section-2.3.1-3" class="pilcrow">¶</a></p>
<p id="section-2.3.1-4">In particular, book publication specialists represented that books don't have
the same requirements for timeliness or currency as web pages. For instance,
Dave Cramer's submission <span>[<a href="#CRAMER" class="xref">CRAMER</a>]</span> observed that Moby Dick was published
over 61,000 days ago, which is considerably longer than the proposed limit of 7
days for signed exchanges. The limited length of time that a Web Package can be
considered valid was discussed at some length.<a href="#section-2.3.1-4" class="pilcrow">¶</a></p>
<p id="section-2.3.1-5">Additionally, the risk of a publisher going out of business during the lifetime
of a book is significant, because books -- at least successful ones -- often span
generations in their applicability. To that end, having a means of attributing
content to a publisher was considered less practical and potentially
undesirable (much like the discussion above regarding "unsigned bundles").<a href="#section-2.3.1-5" class="pilcrow">¶</a></p>
<p id="section-2.3.1-6">There were other aspects of book publication that participants saw as
challenging for packaging. For example, it is currently not understood what it
means to refer to distinct parts of a book. Participants saw this as an area where
providing stable references for bundles of content might offer possibilities,
but nothing concrete came from that discussion.<a href="#section-2.3.1-6" class="pilcrow">¶</a></p>
<p id="section-2.3.1-7">The potential for active content in a bundle to use web APIs to enrich content
or enable new features was considered valuable. Models for enabling paywalls
were discussed at some length (see <a href="#paywalls" class="xref">Section 5.4</a>).<a href="#section-2.3.1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="archive">
<section id="section-2.3.2">
          <h4 id="name-web-archiving">
<a href="#section-2.3.2" class="section-number selfRef">2.3.2. </a><a href="#name-web-archiving" class="section-name selfRef">Web Archiving</a>
          </h4>
<p id="section-2.3.2-1">Web archiving is a complicated discipline that is made more difficult by the
complex nature of the Web itself.<a href="#section-2.3.2-1" class="pilcrow">¶</a></p>
<p id="section-2.3.2-2">From an archival standpoint, the potential for web content to be provided in a
self-contained form was viewed positively. Several improvements to the
structure of Web Packaging were considered, such as providing complete sets of
content and the use of Memento <span>[<a href="#RFC7089" class="xref">MEMENTO</a>]</span>.<a href="#section-2.3.2-2" class="pilcrow">¶</a></p>
<p id="section-2.3.2-3">Though there were potential applications of a packaging scheme, many challenges
were recognized as requiring additional work on the part of content producers to
be fully effective. For example, JavaScript is needed to render some archived
content faithfully, but attributing that content to an origin in all scenarios
is challenging.<a href="#section-2.3.2-3" class="pilcrow">¶</a></p>
<p id="section-2.3.2-4">If packaging were to be widely deployed, it might improve the situation for
archival replay. In particular, the speculation is that there would be less "live
leakage" as packaged content might be less likely to refer to live resources
that currently tend to "leak" into views of archives. It was also noted that
subresources might also be more likely to be packaged, especially those that are
needed for deferred representations (i.e., after JavaScript execution on the
page or some user interactions).  Other potential applications and enhancements
are discussed in <span>[<a href="#ALAM" class="xref">ALAM</a>]</span>.<a href="#section-2.3.2-4" class="pilcrow">¶</a></p>
<p id="section-2.3.2-5">Participants discussed the use of a signature for non-repudiation at some
length. In one case related to the Internet Archive, a public figure disputed the
accuracy of archived content, asserting that the original content was
modified either at the source or in the archive.<a href="#section-2.3.2-5" class="pilcrow">¶</a></p>
<p id="section-2.3.2-6">Some participants initially saw digital signatures as a way to address such
issues of provenance. As similar problems exist in other areas, such as in book
publication, medical research, and news, a solution to this problem was
considered to have broad applicability.<a href="#section-2.3.2-6" class="pilcrow">¶</a></p>
<p id="section-2.3.2-7">However, the discussion ultimately concluded that providing non-repudiation in
retrospect is challenging. Signing keys are not expected to remain secure for
long periods. If keys are leaked afterwards, an attacker could retroactively
generate fraudulent signatures. Alternative solutions were discussed, such as
providing independent archives for the same data, using consensus protocols, or
using an append-only construct like a Haber-Stornetta log
<span>[<a href="#AOLOG" class="xref">AOLOG</a>]</span>, all of which can be used to increase the
difficulty of altering or misrepresenting established archives.<a href="#section-2.3.2-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="tension">
<section id="section-3">
      <h2 id="name-interactions-between-web-pu">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-interactions-between-web-pu" class="section-name selfRef">Interactions between Web Publishers and Aggregators</a>
      </h2>
<p id="section-3-1">A significant motivation for holding the workshop was to provide a forum where
publishers could discuss the impact of Web Packaging on the online publishing
ecosystem. Of primary interest was whether Web Packages might effectively enable
a transfer of power from publishers to aggregators.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Both publishers and aggregators at the workshop expressed the importance of
maintaining a positive relationship. Publishers in particular expressed the
need to be able to trust that aggregators won't misrepresent their work or
de-emphasize it for reasons unrelated to quality and perceived value to the
user.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">One key question from <span>[<a href="#BERJON" class="xref">BERJON</a>]</span> was discussed:<a href="#section-3-3" class="pilcrow">¶</a></p>
<blockquote id="section-3-4">
      Web Packaging has other uses, but it is primarily seen by a large proportion
  of its stakeholders as a solution to problems that AMP created. Before we agree
  to solve those issues, should we not ask if AMP was a useful approach in the
  first place -- and useful to whom?<a href="#section-3-4" class="pilcrow">¶</a>
</blockquote>
<p id="section-3-5">In examining this issue, discussion focused on the current incentive model
offered by aggregators. The costs that publishers incur for participation in
that system were considered. Considerable time was spent on AMP; a summary of
that discussion can be found in <a href="#conflation" class="xref">Section 5</a>.<a href="#section-3-5" class="pilcrow">¶</a></p>
<p id="section-3-6">We also considered the question of whether standardizing Web Packaging confers
credibility to aggregators exercising unwelcome control over publisher content
or whether the technical safeguards Web Packaging provides could allow
aggregators to relax their restrictions on the kinds of content they're willing
to cache and serve. No conclusions were drawn.<a href="#section-3-6" class="pilcrow">¶</a></p>
<div id="incentives-for-web-packages">
<section id="section-3.1">
        <h3 id="name-incentives-for-web-packages">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-incentives-for-web-packages" class="section-name selfRef">Incentives for Web Packages</a>
        </h3>
<p id="section-3.1-1">Submissions to the workshop indicated that the use of inducements involving
better placement and formatting of links to publisher content had a significant
effect on the uptake of related technology. For example, in <span>[<a href="#DEPUYDT-NELSON" class="xref">DEPUYDT-NELSON</a>]</span>:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<blockquote id="section-3.1-2">
        [...] The Washington Post has always placed a great deal of trust in Google to
  represent its content--and their reward for doing so is more traffic, which
  positively impacts the business.<a href="#section-3.1-2" class="pilcrow">¶</a>
</blockquote>
<p id="section-3.1-3">During the workshop, several online publishers indicated that if it weren't for
the privileged position in the Google Search carousel given to AMP content,
they would not publish in that format.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">Publishers that do produce AMP said they see a non-trivial increase in traffic
as a result of deploying AMP content. For example, Yahoo Japan reported a 60%
increase in traffic as a result of deploying AMP on Yahoo Travel <span>[<a href="#OTSU" class="xref">OTSU</a>]</span>.
There was no data presented as to whether this increase was due to better
placement in Google Search results, the inherent benefits of the AMP Cache,
or the use of the AMP format.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">Anecdotal evidence was offered by another large publisher that saw a 10% drop
in traffic as a result of accidentally disabling AMP content. However,
increases in traffic might not result in similarly proportioned increases in
revenue, as observed in <span>[<a href="#BREWSTER" class="xref">BREWSTER</a>]</span>.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="operational-costs">
<section id="section-3.2">
        <h3 id="name-operational-costs">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-operational-costs" class="section-name selfRef">Operational Costs</a>
        </h3>
<p id="section-3.2-1">Several participants pointed out that introducing a new, parallel
        format for Web content incurs operational costs. In particular,
        supporting any new format -- such as Web Packaging, Apple News, or
        Facebook Instant Articles -- requires not only initial development of
        tooling (some generic and some specific to a site's requirements) but
        also an ongoing investment in maintaining its operability. Some
        participants expressed concern about the impact upon small publishers
        with limited technical and financial resources, especially in the
        current publishing climate.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">Increased exposure from new formats might not always justify the added expense
of providing articles in that format <span>[<a href="#BREWSTER" class="xref">BREWSTER</a>]</span>.  However, a standardized
format might help publishers reduce the cost of maintaining multiple formats.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="content-regulation">
<section id="section-3.3">
        <h3 id="name-content-regulation">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-content-regulation" class="section-name selfRef">Content Regulation</a>
        </h3>
<p id="section-3.3-1">The use of Web Packaging as a tool for avoiding censorship was not a
significant topic of discussion, except to note that publishers often have
regulatory requirements regarding removal or correction of content.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">Reference was made to the desire to remove videos of a recent shooting
<span>[<a href="#CHRISTCHURCH" class="xref">CHRISTCHURCH</a>]</span> and the potential difficulty in doing so if content were
available as Web Packages. Legal requirements to remove content come from
multiple angles: copyright violations, illegal content, editorial corrections or
errors, and right to erasure provisions in the European Union General Data
Protection Regulation <span>[<a href="#GDPR" class="xref">GDPR</a>]</span> were mentioned.  One participant speculated that
making it more difficult to remove material in this way might discourage
regulators from censoring content.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">In this context, participants observed that it would be difficult to create
mechanisms to track and control content served as a Web Package without compromising the stated
goal of censorship resistance.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="web-performance">
<section id="section-3.4">
        <h3 id="name-web-performance">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-web-performance" class="section-name selfRef">Web Performance</a>
        </h3>
<p id="section-3.4-1">Understanding the effect that Web Packaging might have on web performance was a
matter of some contention.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.4-2">Some informal analysis from the Google Search deployment was presented (later
published in <span>[<a href="#AMP-PERF" class="xref">AMP-PERF</a>]</span>) that showed significant performance improvements in
metrics related to navigation time resulting from the combination of prefetch,
prerendering, and the AMP format.  These results are suggestive of a possibility
that Web Packaging could provide some of that improvement on its own, but no
data was presented that apportioned the improvement among the three components.<a href="#section-3.4-2" class="pilcrow">¶</a></p>
<p id="section-3.4-3">Though data was presented to demonstrate potential rather than be a definitive
result, discussions raised a number of questions that suggest the need for
further study. Attendees suggested that future measurements consider the effect
of signed bundles distinct from the enhancements derived from the AMP
format. Future research in this area might also consider the effectiveness of
different strategies on devices with varying capabilities, bandwidth, power
consumption requirements, or network conditions.<a href="#section-3.4-3" class="pilcrow">¶</a></p>
<p id="section-3.4-4">Of particular interest is the additional work required to fetch and render
multiple web pages in preparation for navigation.  This might ultimately use fewer
connections but comes with an increased network and CPU cost for clients. Some
participants pointed out that different clients or applications might require
different tuning -- for example, when users have limited (or expensive) bandwidth
or for sites with less clear knowledge about the use of outbound links.<a href="#section-3.4-4" class="pilcrow">¶</a></p>
<p id="section-3.4-5">Workshop participants also expressed interest in learning about the effect of
Web Packages on subsequent navigations within the target site.<a href="#section-3.4-5" class="pilcrow">¶</a></p>
<p id="section-3.4-6">In discussion, some participants suggested that their experience supported a
theory that operating a cache at the linking site was most effective and the
additional work done prior to navigation in terms of fetching and preparing
content was what provided the most gains; others suggested that the benefits
inherent in the AMP format was a dominant factor.<a href="#section-3.4-6" class="pilcrow">¶</a></p>
<p id="section-3.4-7">Understanding the complete effect of Web Packaging on web performance will
require further work.<a href="#section-3.4-7" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="systemic-effects">
<section id="section-4">
      <h2 id="name-systemic-effects">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-systemic-effects" class="section-name selfRef">Systemic Effects</a>
      </h2>
<p id="section-4-1">It is not straightforward to estimate how a proposed technology change might
affect all of the parts of a system -- including not only other components, but
also things like end-user rights and the balance of power between parties --
ahead of time. To date, when evaluating proposals, the IETF has generally
focused on more immediate concerns, such as interoperability and security.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">Moreover, people often find new uses for successful standards
<span>[<a href="#RFC5218" class="xref">SUCCESS</a>]</span> after they are deployed. It is rarely possible to
accurately predict all applications of a protocol or format, whether they are
harmful or beneficial. Refusing standardization only impedes both outcomes.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">With the understanding that predictions are difficult to make, there was
considerable speculation at the workshop about the possible effect of Web
Packaging on the Web. Some of that speculation is informed by experience, but
that experience is necessarily limited in scope. This section attempts to
capture that discussion.<a href="#section-4-3" class="pilcrow">¶</a></p>
<div id="consolidation">
<section id="section-4.1">
        <h3 id="name-consolidation">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-consolidation" class="section-name selfRef">Consolidation</a>
        </h3>
<p id="section-4.1-1">Concerns about the consolidation of power on the Internet have significantly
increased lately, as a result of several factors. While the IAB, the Internet
Society, and others are examining this phenomenon to understand it better, it is
nevertheless prudent to consider whether proposals for changes to how the
Internet works favors or counters consolidation. Favoring entities with existing
advantages -- like resources, size, or market share -- is not necessarily a factor
that disqualifies a new proposal, but it needs to be considered as a cost of
enabling that technology.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2">Although the outcomes of adopting Web Packaging are unclear, 
the workshop revealed several concerns for consolidation risks for all
involved parties: users, publisher sites, linking sites, and services they each
rely on.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<div id="consolidation-of-power-in-linking-sites">
<section id="section-4.1.1">
          <h4 id="name-consolidation-of-power-in-l">
<a href="#section-4.1.1" class="section-number selfRef">4.1.1. </a><a href="#name-consolidation-of-power-in-l" class="section-name selfRef">Consolidation of Power in Linking Sites</a>
          </h4>
<p id="section-4.1.1-1">Several participants noted that Web Packaging's enabling of instant navigation
(<a href="#nav" class="xref">Section 2.1</a>) might advantage larger linking sites -- such as social networks or
search engines -- over smaller ones in the same industry because doing so
requires careful selections of which links to optimize, so as not to create
unneeded traffic.<a href="#section-4.1.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1.1-2">For example, a news article often has many links, but not all of them are
equally likely to be followed. Deciding which ones to prefetch requires
considerable data collection and engineering, so this technique might not be
feasible for smaller entities. Additionally, some participants noted that this
technique favors sites that have a linear set of ranked links, like search
results; it is more difficult to apply to a page of news (for example) because
predicting what link a user will follow is less obvious.<a href="#section-4.1.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1.1-3">This technique also requires access to a cache with terms of use compatible
with the requirements of the site. It was pointed out that the Google AMP Cache
has policies that might be acceptable to many, and there are other caches.
Sites operated by entities other than Google already use this cache, though it
was observed that a site that does not host its own cache suffers a minor
performance degradation.<a href="#section-4.1.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="consolidation-of-power-in-publishers">
<section id="section-4.1.2">
          <h4 id="name-consolidation-of-power-in-p">
<a href="#section-4.1.2" class="section-number selfRef">4.1.2. </a><a href="#name-consolidation-of-power-in-p" class="section-name selfRef">Consolidation of Power in Publishers</a>
          </h4>
<p id="section-4.1.2-1">Participants seemed to agree that if performance is a strong enough
differentiator, the effective use of Web Packaging might turn out to be a
condition for success for online publishers. Google Search's choice to
privilege content that is served using HTTPS was pointed out as showing that
this sort of influence can be effective. Equally, it is not necessarily the
case that standardization of new capabilities will affect such policies
materially, as noted in <span>[<a href="#YASSKIN" class="xref">YASSKIN</a>]</span>:<a href="#section-4.1.2-1" class="pilcrow">¶</a></p>
<blockquote id="section-4.1.2-2">
          It seems unlikely that any decisions we make in a packaging or distribution
  system will affect the considerations aggregators use when deciding how to rank
  recommendations or the power this gives them over publishers.<a href="#section-4.1.2-2" class="pilcrow">¶</a>
</blockquote>
<p id="section-4.1.2-3">The most common concern raised in the discussion was the effect of this
technology on smaller publishers who might be less able to optimize the packages
they produce, where their primary differentiation in the market has previously
been the quality of their content.<a href="#section-4.1.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="consolidation-of-user-preferences">
<section id="section-4.1.3">
          <h4 id="name-consolidation-of-user-prefe">
<a href="#section-4.1.3" class="section-number selfRef">4.1.3. </a><a href="#name-consolidation-of-user-prefe" class="section-name selfRef">Consolidation of User Preferences</a>
          </h4>
<p id="section-4.1.3-1">In typical operation of the Web, servers have an opportunity to tailor content
to the needs of their users. In contrast, a static Web Package has few options
for individualization, as the content is generated once and used by many.<a href="#section-4.1.3-1" class="pilcrow">¶</a></p>
<p id="section-4.1.3-2">As a result, publishers noted that AMP provides less opportunity to customize
content for their customers. Their concerns included not only personalizing
content based on what they know about the user but also optimizing the package
for specific browsers. Other participants observed in relation to this that Web
Packaging might also have a consolidating effect in the browser market.<a href="#section-4.1.3-2" class="pilcrow">¶</a></p>
<p id="section-4.1.3-3">Some participants brought up the possibility of customization by providing
multiple packages, including multiple variants of resources in a single package,
or performing customization after the package was loaded.  However, other
participants pointed out that all of these options have negative side effects,
either in complexity or reduced performance arising from larger bundles or
delayed customization.<a href="#section-4.1.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="web-sec">
<section id="section-4.2">
        <h3 id="name-effect-on-web-security">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-effect-on-web-security" class="section-name selfRef">Effect on Web Security</a>
        </h3>
<p id="section-4.2-1">One session explored the impact of introducing a new security model for the
Web. Currently, sites rely on connection-oriented security (provided by TLS
<span>[<a href="#RFC8446" class="xref">TLS</a>]</span>), but Web Packaging adds a limited form of object security.
That is, the package protects the integrity of a message, rather than providing
integrity and confidentiality for its delivery. Object security is not a new
concept in the context of the Web; designs like SHTTP <span>[<a href="#RFC2660" class="xref">SHTTP</a>]</span> are as
old as HTTPS. Though the intent is for Web Packaging to have a far more narrow
applicability, it provides fewer security guarantees than HTTPS, since it
provides only authentication, no confidentiality with respect to the cache, and
no assurance of liveness.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">Object-based security -- such as proposed in Web Packaging -- allows the use of
content regardless of how it is obtained; some participants noted that third
parties gain greater control over the distribution of content, reducing the
ability of publishers to retract or alter content over the validity period of
signed content.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">Another topic of discussion was composition attacks. In its proposed form, Web
Packaging only provides authentication of independent resources, not a web page
as a single unit, allowing an attacker to control the composition of resources.
This weakness was acknowledged as a known shortcoming of the current proposal
that would be addressed.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<p id="section-4.2-4">The issue of managing the trade-off between control and performance in caches
arose. While participants recognized that problems with resource composition
already occur by accident -- for example, when a cache stores different versions
of resources -- Web Packaging allows an attacker more direct control over what
resources are available to clients.<a href="#section-4.2-4" class="pilcrow">¶</a></p>
<p id="section-4.2-5">For example, an attacker might be able to cause content with a security flaw to
be used up to a week past the time that the defect was fixed.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
<p id="section-4.2-6">As an example of how Web Packaging might change the risk profile for sites,
participants discussed recovery from cross-site scripting attacks. It is already
the case that a brief exposure to this class of attack can result in an attacker
gaining persistent access, but mechanisms exist that can be used to avoid or
correct issues, like cache validation and Clear Site Data <span>[<a href="#CLEAR-DATA" class="xref">CLEAR-DATA</a>]</span>. These
measures are not available to clients unless they connect to the site.<a href="#section-4.2-6" class="pilcrow">¶</a></p>
<p id="section-4.2-7">The discussion pointed out that these concerns are not new or uniquely enabled
by Web Packaging. However, it was pointed out that new features are routinely
subject to higher security and privacy expectations. In an example unrelated to
Web Packaging but with similar trade-offs, shared compression of multiple
resources has significant performance benefits. The risk with shared compression
is the potential for exposing encrypted information through
side channels. Though sites can use shared compression without this exposure,
shared compression will likely only be enabled once it is clear that measures to
prevent accidental information exposure are understood to be effective in a
broad set of deployments.<a href="#section-4.2-7" class="pilcrow">¶</a></p>
<p id="section-4.2-8">The discussion also addressed the question of whether concerns might equally
apply to the typical use of a CDN as a
third-party provider of the content. Some participants concluded that CDNs are
typically in a contractual relationship with the sites they serve and so are
more likely to have their interests aligned.<a href="#section-4.2-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy-of-content">
<section id="section-4.3">
        <h3 id="name-privacy-of-content">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-privacy-of-content" class="section-name selfRef">Privacy of Content</a>
        </h3>
<p id="section-4.3-1">Discussion and submissions raised concerns regarding how serving content using
Web Packages might adversely affect privacy of individuals. There are
challenges here, but the very narrow applicability of Web Packaging to what is
effectively static content limits the privacy risk. The conclusion was that,
provided sufficient care is taken in implementation, the use of Web Packages does
not substantially increase the information that an aggregator gains about what
content is consumed.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">Concretely, an aggregator knows what content it serves in anticipation of
navigation. This is -- at least in theory -- substantially the same as the
content that the aggregator might receive if it performed the navigation
itself. Assuming that content is stripped of personalization, the aggregator
gains no new information.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="conflation">
<section id="section-5">
      <h2 id="name-amp-issues-unrelated-to-web">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-amp-issues-unrelated-to-web" class="section-name selfRef">AMP Issues Unrelated to Web Packaging</a>
      </h2>
<p id="section-5-1">On multiple occasions, discussion at the workshop concentrated on problems that
arise as a result of constraints on the AMP format or details of its inclusion
in Google Search. For instance, the requirement to make pages expose their
metadata is unlikely to be affected by any standardization of a
packaging format as that requirement is independent of the process of
delivering content.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">This section provides some detail on aspects of the discussion that touched on
AMP more generally in this way. Some treatment of these points is considered
relevant as some of the discussion at the workshop, even under the remit of
discussing Web Packaging, concentrated on the effect of AMP on the ecosystem.<a href="#section-5-2" class="pilcrow">¶</a></p>
<aside id="section-5-3">
        <p id="section-5-3.1">Note: Of the four formats mentioned in the workshop call for papers
        <span>[<a href="#CFP" class="xref">CFP</a>]</span>, only AMP sent representatives
        to the workshop. The discussion was therefore concentrated around AMP;
        this section should not be read to imply anything about other
        formats.<a href="#section-5-3.1" class="pilcrow">¶</a></p>
</aside>
<p id="section-5-4">Discussion and submissions referred to a commitment <span>[<a href="#AMP-LESSONS" class="xref">AMP-LESSONS</a>]</span> to allow
publishers to use content that met specific criteria to access privileged
positions in search results, regardless of their adoption of AMP. Participants
felt that this approach might address some of these concerns if it were adopted
and durable. For instance, the use of Web Packaging might be sufficient to
remove some constraints on active content on the basis that the active content
would be attributed to the publisher and not the AMP Cache.<a href="#section-5-4" class="pilcrow">¶</a></p>
<div id="amp-governance">
<section id="section-5.1">
        <h3 id="name-amp-governance">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-amp-governance" class="section-name selfRef">AMP Governance</a>
        </h3>
<p id="section-5.1-1">There was interest from workshop participants in the governance model used for
AMP. In particular, the question of how independent the AMP project would be of
Google and Google Search arose.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<p id="section-5.1-2">Three of the seven members of the AMP Technical Steering Committee, the body
that governs AMP, are Google employees, which gives Google considerable
influence over the project. It was asserted that the governance structure was
intended to be more independent of Google over time. The understanding was that
any consumer of the format, such as Google Search, would make an independent
assessment about whether to use or require different aspects of the AMP project
products.<a href="#section-5.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="constraints-on-the-amp-format">
<section id="section-5.2">
        <h3 id="name-constraints-on-the-amp-form">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-constraints-on-the-amp-form" class="section-name selfRef">Constraints on the AMP Format</a>
        </h3>
<p id="section-5.2-1">Sites often implement AMP by creating a separate set of content in parallel to
their regular HTML content. Publishers noted this as a high cost, particularly
for smaller sites. It was pointed out that websites can serve AMP-compliant
content exclusively. However, several publishers referred to limitations in the
format that made it unsuitable for their needs.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">Many cited reasons for this duplication were related to the necessity of
running arbitrary active content (typically, JavaScript). For example:<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<ul>
<li id="section-5.2-3.1">AMP provides a framework for supporting user authentication, but publishers
asserted that using this framework was not considered practical.<a href="#section-5.2-3.1" class="pilcrow">¶</a>
</li>
<li id="section-5.2-3.2">AMP content does not support rendering of certain content, which can affect
the ability of publishers to innovate content production.<a href="#section-5.2-3.2" class="pilcrow">¶</a>
</li>
<li id="section-5.2-3.3">The AMP model for the implementation of paywalls (<a href="#paywalls" class="xref">Section 5.4</a>) was claimed
to be inimical to some publisher business models.<a href="#section-5.2-3.3" class="pilcrow">¶</a>
</li>
</ul>
<p id="section-5.2-4">More broadly, they considered AMP's constraints on the use of active content as
problematic, since they prevent the use of capabilities that are provided on
equivalent non-AMP pages. Reference was made to a proposed &lt;amp-script&gt;
element -- which has since been made fully available -- that seeks to provide
limited access to some dynamic content.<a href="#section-5.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="performance">
<section id="section-5.3">
        <h3 id="name-performance">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-performance" class="section-name selfRef">Performance</a>
        </h3>
<p id="section-5.3-1">Publishers observed that using the AMP format does not provide any guarantee of
performance gains and, in some cases, could contribute to performance
degradation. It was suggested that this was most problematic for sites that are
already well-tuned for performance.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="paywalls">
<section id="section-5.4">
        <h3 id="name-implementation-of-paywalls">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-implementation-of-paywalls" class="section-name selfRef">Implementation of Paywalls</a>
        </h3>
<p id="section-5.4-1">The use of paywalls by web publishers to control access to content in return
for payment is increasingly common. One popular approach is to offer a limited
number of articles without payment while insisting on a paid subscription to
access further articles.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<p id="section-5.4-2">On several occasions, participants expressed dissatisfaction with the difficulty
of integrating paywall authorization when using AMP. In particular, they said
AMP encourages publishers to include an article's full content, hidden by
default but easily accessible to motivated users. 
The discussion extended to workarounds like cookie syncing <span>[<a href="#COOKIE-SYNC" class="xref">COOKIE-SYNC</a>]</span>,
which is used as part of authorization and is a consequence of having cached content hosted on the 
   linking site rather than the target site.<a href="#section-5.4-2" class="pilcrow">¶</a></p>
<p id="section-5.4-3">The same topic came up concerning book publication, where publishers indicated
that having a means of enabling different methods of distribution without also
facilitating unconstrained copying of book content was necessary.<a href="#section-5.4-3" class="pilcrow">¶</a></p>
<p id="section-5.4-4">This conflation of AMP issues with those addressed by Web Packaging was
recurrent in the discussion. As observed in <span>[<a href="#DAS" class="xref">DAS</a>]</span>, these concerns might be
addressed by linking to a signed bundle.<a href="#section-5.4-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="venues-for-future-discussion">
<section id="section-6">
      <h2 id="name-venues-for-future-discussio">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-venues-for-future-discussio" class="section-name selfRef">Venues for Future Discussion</a>
      </h2>
<p id="section-6-1">Web Packaging work continues in multiple forums. Questions about the
      core format and signatures are being discussed on the <a href="https://www.ietf.org/mailman/listinfo/wpack">wpack@ietf.org
      mailing list</a>. Changes to web browsers as proposed in <span>[<a href="#LOADING" class="xref">LOADING</a>]</span> will be discussed on the <a href="https://github.com/whatwg/fetch/issues/784">Fetch specification
      repository</a>.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<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">Proposals discussed at the workshop might have a significant security impact,
and these topics were discussed in some depth; see <a href="#web-sec" class="xref">Section 4.2</a>.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-8">
      <h2 id="name-informative-references">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
      </h2>
<dl class="references">
<dt id="ALAM">[ALAM]</dt>
<dd>
<span class="refAuthor">Alam, S.</span><span class="refAuthor">, Weigle, M.</span><span class="refAuthor">, Nelson, M.</span><span class="refAuthor">, Klein, M.</span><span class="refAuthor">, and H. Van de Sompel</span>, <span class="refTitle">"Supporting Web Archiving via Web Packaging"</span>, <time datetime="2019-06-06">6 June 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf">https://www.iab.org/wp-content/IAB-uploads/2019/06/sawood-alam-2.pdf</a>&gt;</span>. </dd>
<dt id="AMP-LESSONS">[AMP-LESSONS]</dt>
<dd>
<span class="refAuthor">Ubl, M.</span>, <span class="refTitle">"Standardizing lessons learned from AMP"</span>, <time datetime="2018-03-08">8 March 2018</time>, <span>&lt;<a href="https://blog.amp.dev/2018/03/08/standardizing-lessons-learned-from-amp/">https://blog.amp.dev/2018/03/08/standardizing-lessons-learned-from-amp/</a>&gt;</span>. </dd>
<dt id="AMP-PERF">[AMP-PERF]</dt>
<dd>
<span class="refAuthor">Steinlauf, E.</span>, <span class="refTitle">"The Speed Benefit of AMP Prerendering"</span>, <time datetime="2019-08-14">14 August 2019</time>, <span>&lt;<a href="https://developers.googleblog.com/2019/08/the-speed-benefit-of-amp-prerendering.html">https://developers.googleblog.com/2019/08/the-speed-benefit-of-amp-prerendering.html</a>&gt;</span>. </dd>
<dt id="AOLOG">[AOLOG]</dt>
<dd>
<span class="refAuthor">Haber, S.</span><span class="refAuthor"> and W. Stornetta</span>, <span class="refTitle">"How to time-stamp a digital document"</span>, <span class="refContent">Journal of Cryptology, Vol. 3, Issue 2, pp. 99-111</span>, <span class="seriesInfo">DOI 10.1007/bf00196791</span>, <time datetime="1991">1991</time>, <span>&lt;<a href="https://doi.org/10.1007/bf00196791">https://doi.org/10.1007/bf00196791</a>&gt;</span>. </dd>
<dt id="BERJON">[BERJON]</dt>
<dd>
<span class="refAuthor">Berjon, R.</span>, <span class="refTitle">"ESCAPE: The New York Times Position"</span>, <time datetime="2019-07-09">9 July 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/07/NYT-ESCAPE.pdf">https://www.iab.org/wp-content/IAB-uploads/2019/07/NYT-ESCAPE.pdf</a>&gt;</span>. </dd>
<dt id="BREWSTER">[BREWSTER]</dt>
<dd>
<span class="refAuthor">Brewster, A.</span>, <span class="refTitle">"ESCAPE Position / Patch.com"</span>, <time datetime="2019-06-06">6 June 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/06/patch.pdf">https://www.iab.org/wp-content/IAB-uploads/2019/06/patch.pdf</a>&gt;</span>. </dd>
<dt id="I-D.yasskin-wpack-bundled-exchanges">[BUNDLE]</dt>
<dd>
<span class="refAuthor">Yasskin, J.</span>, <span class="refTitle">"Bundled HTTP Exchanges"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-yasskin-wpack-bundled-exchanges-02</span>, <time datetime="2019-09-26">26 September 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-02">https://tools.ietf.org/html/draft-yasskin-wpack-bundled-exchanges-02</a>&gt;</span>. </dd>
<dt id="CFP">[CFP]</dt>
<dd>
<span class="refAuthor">Internet Architecture Board</span>, <span class="refTitle">"Exploring Synergy between Content Aggregation and the Publisher Ecosystem Workshop 2019"</span>, <time datetime="2019-05-03">3 May 2019</time>, <span>&lt;<a href="https://www.iab.org/activities/workshops/escape-workshop/">https://www.iab.org/activities/workshops/escape-workshop/</a>&gt;</span>. </dd>
<dt id="CHATHAM-HOUSE">[CHATHAM-HOUSE]</dt>
<dd>
<span class="refAuthor">Chatham House</span>, <span class="refTitle">"Chatham House Rule"</span>, <span>&lt;<a href="https://www.chathamhouse.org/chatham-house-rule">https://www.chathamhouse.org/chatham-house-rule</a>&gt;</span>. </dd>
<dt id="CHRISTCHURCH">[CHRISTCHURCH]</dt>
<dd>
<span class="refAuthor">Stevenson, R.</span><span class="refAuthor"> and J. Anthony</span>, <span class="refTitle">"'Thousands' of Christchurch shootings videos removed from YouTube, Google says"</span>, <time datetime="2019-03-16">16 March 2019</time>, <span>&lt;<a href="https://www.stuff.co.nz/business/111330323/facebook-working-around-the-clock-to-block-christchurch-shootings-video">https://www.stuff.co.nz/business/111330323/facebook-working-around-the-clock-to-block-christchurch-shootings-video</a>&gt;</span>. </dd>
<dt id="CLEAR-DATA">[CLEAR-DATA]</dt>
<dd>
<span class="refAuthor">West, M.</span>, <span class="refTitle">"Clear Site Data"</span>, <span class="refContent">W3C Working Draft</span>, <time datetime="2017-11-30">30 November 2017</time>, <span>&lt;<a href="https://www.w3.org/TR/clear-site-data/">https://www.w3.org/TR/clear-site-data/</a>&gt;</span>. </dd>
<dt id="COOKIE-SYNC">[COOKIE-SYNC]</dt>
<dd>
<span class="refAuthor">Acar, G.</span><span class="refAuthor">, Eubank, C.</span><span class="refAuthor">, Englehardt, S.</span><span class="refAuthor">, Juarez, M.</span><span class="refAuthor">, Narayanan, A.</span><span class="refAuthor">, and C. Diaz</span>, <span class="refTitle">"The Web Never Forgets"</span>, <span class="refContent">CSS '14: Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, pp. 674-689</span>, <span class="seriesInfo">DOI 10.1145/2660267.2660347</span>, <time datetime="2014">2014</time>, <span>&lt;<a href="https://doi.org/10.1145/2660267.2660347">https://doi.org/10.1145/2660267.2660347</a>&gt;</span>. </dd>
<dt id="CRAMER">[CRAMER]</dt>
<dd>
<span class="refAuthor">Cramer, D.</span>, <span class="refTitle">"Packaging Books"</span>, <time datetime="2019-06-02">2 June 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/06/cramer-position-paper.pdf">https://www.iab.org/wp-content/IAB-uploads/2019/06/cramer-position-paper.pdf</a>&gt;</span>. </dd>
<dt id="DAS">[DAS]</dt>
<dd>
<span class="refAuthor">Das, S.</span>, <span class="refTitle">"The Implication of Signed Exchanges on E-Commerce"</span>, <time datetime="2019-06-07">7 June 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/06/IAB-Position-Paper_-Signed-Exchanges.pdf">https://www.iab.org/wp-content/IAB-uploads/2019/06/IAB-Position-Paper_-Signed-Exchanges.pdf</a>&gt;</span>. </dd>
<dt id="DEPUYDT-NELSON">[DEPUYDT-NELSON]</dt>
<dd>
<span class="refAuthor">DePuydt, M.</span><span class="refAuthor"> and M. Nelson</span>, <span class="refTitle">"Signed Exchanges and The Importance of Trust in Aggregator/Publisher relationships"</span>, <time datetime="2019-06-04">4 June 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/06/washpost.pdf">https://www.iab.org/wp-content/IAB-uploads/2019/06/washpost.pdf</a>&gt;</span>. </dd>
<dt id="GDPR">[GDPR]</dt>
<dd>
<span class="refAuthor">European Union</span>, <span class="refTitle">"General Data Protection Regulation"</span>, <span class="refContent">EU Regulation 2016/679</span>, <time datetime="2016-04-27">27 April 2016</time>, <span>&lt;<a href="https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&amp;from=EN#d1e2606-1-1">https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32016R0679&amp;from=EN#d1e2606-1-1</a>&gt;</span>. </dd>
<dt id="RFC7230">[HTTP]</dt>
<dd>
<span class="refAuthor">Fielding, R., Ed.</span><span class="refAuthor"> and J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing"</span>, <span class="seriesInfo">RFC 7230</span>, <span class="seriesInfo">DOI 10.17487/RFC7230</span>, <time datetime="2014-06">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7230">https://www.rfc-editor.org/info/rfc7230</a>&gt;</span>. </dd>
<dt id="LOADING">[LOADING]</dt>
<dd>
<span class="refAuthor">Yasskin, J.</span>, <span class="refTitle">"Loading Signed Exchanges"</span>, <time datetime="2019-09-04">4 September 2019</time>, <span>&lt;<a href="https://wicg.github.io/webpackage/loading.html">https://wicg.github.io/webpackage/loading.html</a>&gt;</span>. </dd>
<dt id="RFC7089">[MEMENTO]</dt>
<dd>
<span class="refAuthor">Van de Sompel, H.</span><span class="refAuthor">, Nelson, M.</span><span class="refAuthor">, and R. Sanderson</span>, <span class="refTitle">"HTTP Framework for Time-Based Access to Resource States -- Memento"</span>, <span class="seriesInfo">RFC 7089</span>, <span class="seriesInfo">DOI 10.17487/RFC7089</span>, <time datetime="2013-12">December 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7089">https://www.rfc-editor.org/info/rfc7089</a>&gt;</span>. </dd>
<dt id="RFC6454">[ORIGIN]</dt>
<dd>
<span class="refAuthor">Barth, A.</span>, <span class="refTitle">"The Web Origin Concept"</span>, <span class="seriesInfo">RFC 6454</span>, <span class="seriesInfo">DOI 10.17487/RFC6454</span>, <time datetime="2011-12">December 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6454">https://www.rfc-editor.org/info/rfc6454</a>&gt;</span>. </dd>
<dt id="OTSU">[OTSU]</dt>
<dd>
<span class="refAuthor">Ohtsu, S.</span>, <span class="refTitle">"Deployment Experience of Signed HTTP Exchanges with AMP as a Publisher"</span>, <time datetime="2019-06-04">4 June 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/06/shigeki-ohtsu.pdf">https://www.iab.org/wp-content/IAB-uploads/2019/06/shigeki-ohtsu.pdf</a>&gt;</span>. </dd>
<dt id="RFC2660">[SHTTP]</dt>
<dd>
<span class="refAuthor">Rescorla, E.</span><span class="refAuthor"> and A. Schiffman</span>, <span class="refTitle">"The Secure HyperText Transfer Protocol"</span>, <span class="seriesInfo">RFC 2660</span>, <span class="seriesInfo">DOI 10.17487/RFC2660</span>, <time datetime="1999-08">August 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2660">https://www.rfc-editor.org/info/rfc2660</a>&gt;</span>. </dd>
<dt id="RFC5218">[SUCCESS]</dt>
<dd>
<span class="refAuthor">Thaler, D.</span><span class="refAuthor"> and B. Aboba</span>, <span class="refTitle">"What Makes for a Successful Protocol?"</span>, <span class="seriesInfo">RFC 5218</span>, <span class="seriesInfo">DOI 10.17487/RFC5218</span>, <time datetime="2008-07">July 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5218">https://www.rfc-editor.org/info/rfc5218</a>&gt;</span>. </dd>
<dt id="I-D.yasskin-http-origin-signed-responses">[SXG]</dt>
<dd>
<span class="refAuthor">Yasskin, J.</span>, <span class="refTitle">"Signed HTTP Exchanges"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-yasskin-http-origin-signed-responses-08</span>, <time datetime="2019-11-04">4 November 2019</time>, <span>&lt;<a href="https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-08">https://tools.ietf.org/html/draft-yasskin-http-origin-signed-responses-08</a>&gt;</span>. </dd>
<dt id="TAG-DC">[TAG-DC]</dt>
<dd>
<span class="refAuthor">Betts, A., Ed.</span>, <span class="refTitle">"Distributed and syndicated content"</span>, <span class="refContent">W3C TAG Finding</span>, <time datetime="2017-07-27">27 July 2017</time>, <span>&lt;<a href="https://www.w3.org/2001/tag/doc/distributed-content/">https://www.w3.org/2001/tag/doc/distributed-content/</a>&gt;</span>. </dd>
<dt id="RFC8446">[TLS]</dt>
<dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dt id="YASSKIN">[YASSKIN]</dt>
<dd>
<span class="refAuthor">Yasskin, J.</span>, <span class="refTitle">"Chrome's position on the ESCAPE workshop"</span>, <time datetime="2019-06-06">6 June 2019</time>, <span>&lt;<a href="https://www.iab.org/wp-content/IAB-uploads/2019/06/chrome.html">https://www.iab.org/wp-content/IAB-uploads/2019/06/chrome.html</a>&gt;</span>. </dd>
</dl>
</section>
<div id="workshop-details">
<section id="section-appendix.a">
      <h2 id="name-about-the-workshop">
<a href="#section-appendix.a" class="section-number selfRef">Appendix A. </a><a href="#name-about-the-workshop" class="section-name selfRef">About the Workshop</a>
      </h2>
<p id="section-appendix.a-1">The ESCAPE Workshop was held on 2019-07-18 and the morning of 2019-07-19 at
Cisco's facility in Herndon, Virginia, USA.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
<p id="section-appendix.a-2">Workshop attendees were asked to submit position papers. These papers
are published on the IAB website <span>[<a href="#CFP" class="xref">CFP</a>]</span>.<a href="#section-appendix.a-2" class="pilcrow">¶</a></p>
<p id="section-appendix.a-3">The workshop was conducted under the Chatham House Rule <span>[<a href="#CHATHAM-HOUSE" class="xref">CHATHAM-HOUSE</a>]</span>, meaning that statements
      cannot be attributed to individuals or organizations without explicit
      authorization.<a href="#section-appendix.a-3" class="pilcrow">¶</a></p>
<div id="agenda">
<section id="section-a.1">
        <h2 id="name-agenda">
<a href="#section-a.1" class="section-number selfRef">A.1. </a><a href="#name-agenda" class="section-name selfRef">Agenda</a>
        </h2>
<p id="section-a.1-1">This section outlines the broad areas of discussion on each day.<a href="#section-a.1-1" class="pilcrow">¶</a></p>
<div id="thursday-2019-07-18">
<section id="section-a.1.1">
          <h3 id="name-thursday-2019-07-18">
<a href="#section-a.1.1" class="section-number selfRef">A.1.1. </a><a href="#name-thursday-2019-07-18" class="section-name selfRef">Thursday 2019-07-18</a>
          </h3>
<dl class="dlParallel" id="section-a.1.1-1">
            <dt id="section-a.1.1-1.1">Web Packaging Overview:</dt>
<dd id="section-a.1.1-1.2">
  A technical summary of Web Packaging was provided, plus a longer discussion
of a range of use cases.<a href="#section-a.1.1-1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-a.1.1-1.3">Web Packaging and Aggregators:</dt>
<dd id="section-a.1.1-1.4">
  The use of Web Packaging from the perspective of a content aggregator was
given.<a href="#section-a.1.1-1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-a.1.1-1.5">Web Packaging and Publishers:</dt>
<dd id="section-a.1.1-1.6">
  After a break, presentations from web publishers talked about the benefits
and costs of Web Packaging. This included some discussion of the effect of
developing AMP-conformant versions of content from a publisher perspective.<a href="#section-a.1.1-1.6" class="pilcrow">¶</a>
</dd>
<dt id="section-a.1.1-1.7">Web Packaging and Security:</dt>
<dd id="section-a.1.1-1.8">
  This session concentrated on how the Web Packaging proposal might affect the
web security model.<a href="#section-a.1.1-1.8" class="pilcrow">¶</a>
</dd>
<dt id="section-a.1.1-1.9">Alternatives to Web Packaging:</dt>
<dd id="section-a.1.1-1.10">
  This session looked at alternative technologies, including those that were
attempted in the past and some more recent ideas for addressing the use case of
making web navigations more performant.<a href="#section-a.1.1-1.10" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
<div id="friday-2019-07-19">
<section id="section-a.1.2">
          <h3 id="name-friday-2019-07-19">
<a href="#section-a.1.2" class="section-number selfRef">A.1.2. </a><a href="#name-friday-2019-07-19" class="section-name selfRef">Friday 2019-07-19</a>
          </h3>
<dl class="dlParallel" id="section-a.1.2-1">
            <dt id="section-a.1.2-1.1">Web Archival:</dt>
<dd id="section-a.1.2-1.2">
  This session talked about the potential application of a technology like Web
Packaging in addressing some of the myriad problems faced by web archival
systems.<a href="#section-a.1.2-1.2" class="pilcrow">¶</a>
</dd>
<dt id="section-a.1.2-1.3">Book Publishing:</dt>
<dd id="section-a.1.2-1.4">
  The effect of technologies for bundling and distribution of
books was discussed.<a href="#section-a.1.2-1.4" class="pilcrow">¶</a>
</dd>
<dt id="section-a.1.2-1.5">Conclusions:</dt>
<dd id="section-a.1.2-1.6">
  A wrap-up session attempted to capture key takeaways from the workshop.<a href="#section-a.1.2-1.6" class="pilcrow">¶</a>
</dd>
</dl>
</section>
</div>
</section>
</div>
<div id="workshop-attendees">
<section id="section-a.2">
        <h2 id="name-workshop-attendees">
<a href="#section-a.2" class="section-number selfRef">A.2. </a><a href="#name-workshop-attendees" class="section-name selfRef">Workshop Attendees</a>
        </h2>
<p id="section-a.2-1">Attendees of the workshop are listed with their primary affiliation as it
appeared in submissions. Attendees from the program committee (PC), the
Internet Architecture Board (IAB), and the Internet Engineering Steering Group
(IESG) are also marked.<a href="#section-a.2-1" class="pilcrow">¶</a></p>
<ul>
<li id="section-a.2-2.1">
            <p id="section-a.2-2.1.1"><span class="contact-name">Sawood Alam</span>, Old Dominion University<a href="#section-a.2-2.1.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.2">
            <p id="section-a.2-2.2.1"><span class="contact-name">Jari Arkko</span>, Ericsson (IAB)<a href="#section-a.2-2.2.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.3">
            <p id="section-a.2-2.3.1"><span class="contact-name">Richard Barnes</span>, Cisco<a href="#section-a.2-2.3.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.4">
            <p id="section-a.2-2.4.1"><span class="contact-name">Robin Berjon</span>, New York Times (PC)<a href="#section-a.2-2.4.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.5">
            <p id="section-a.2-2.5.1"><span class="contact-name">Zack Bloom</span>, Cloudflare<a href="#section-a.2-2.5.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.6">
            <p id="section-a.2-2.6.1"><span class="contact-name">Abraham Brewster</span>, Patch.com<a href="#section-a.2-2.6.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.7">
            <p id="section-a.2-2.7.1"><span class="contact-name">Alissa Cooper</span>, Cisco (IESG, IAB)<a href="#section-a.2-2.7.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.8">
            <p id="section-a.2-2.8.1"><span class="contact-name">Dave Cramer</span>, Hachette Book Group<a href="#section-a.2-2.8.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.9">
            <p id="section-a.2-2.9.1"><span class="contact-name">Melissa DePuydt</span>, Washington Post<a href="#section-a.2-2.9.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.10">
            <p id="section-a.2-2.10.1"><span class="contact-name">Levi Durfee</span>, AMP Advisory Committee<a href="#section-a.2-2.10.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.11">
            <p id="section-a.2-2.11.1"><span class="contact-name">Rudy Galfi</span>, Google<a href="#section-a.2-2.11.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.12">
            <p id="section-a.2-2.12.1"><span class="contact-name">Joseph Lorenzo Hall</span>, Center for Democracy &amp; Technology (PC)<a href="#section-a.2-2.12.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.13">
            <p id="section-a.2-2.13.1"><span class="contact-name">Matthew Nelson</span>, Washington Post<a href="#section-a.2-2.13.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.14">
            <p id="section-a.2-2.14.1"><span class="contact-name">Michael Nelson</span>, Old Dominion University<a href="#section-a.2-2.14.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.15">
            <p id="section-a.2-2.15.1"><span class="contact-name">Mark Nottingham</span>, Fastly (IAB, PC)<a href="#section-a.2-2.15.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.16">
            <p id="section-a.2-2.16.1"><span class="contact-name">Shigeki Ohtsu</span>, Yahoo<a href="#section-a.2-2.16.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.17">
            <p id="section-a.2-2.17.1"><span class="contact-name">Eric Rescorla</span>, Mozilla<a href="#section-a.2-2.17.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.18">
            <p id="section-a.2-2.18.1"><span class="contact-name">Adam Roach</span>, Mozilla (IESG)<a href="#section-a.2-2.18.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.19">
            <p id="section-a.2-2.19.1"><span class="contact-name">Rich Salz</span>, Akamai Technologies<a href="#section-a.2-2.19.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.20">
            <p id="section-a.2-2.20.1"><span class="contact-name">Wendy Seltzer</span>, W3C<a href="#section-a.2-2.20.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.21">
            <p id="section-a.2-2.21.1"><span class="contact-name">David Strauss</span>, Pantheon (PC)<a href="#section-a.2-2.21.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.22">
            <p id="section-a.2-2.22.1"><span class="contact-name">Chi-Jiun Su</span>, Hughes<a href="#section-a.2-2.22.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.23">
            <p id="section-a.2-2.23.1"><span class="contact-name">Ralph Swick</span>, W3C<a href="#section-a.2-2.23.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.24">
            <p id="section-a.2-2.24.1"><span class="contact-name">Martin Thomson</span>, Mozilla (IAB, PC)<a href="#section-a.2-2.24.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.25">
            <p id="section-a.2-2.25.1"><span class="contact-name">Jeffrey Yasskin</span>, Google<a href="#section-a.2-2.25.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.26">
            <p id="section-a.2-2.26.1"><span class="contact-name">Dan York</span>, Internet Society<a href="#section-a.2-2.26.1" class="pilcrow">¶</a></p>
</li>
<li id="section-a.2-2.27">
            <p id="section-a.2-2.27.1"><span class="contact-name">Benjamin Young</span>, John Wiley &amp; Sons<a href="#section-a.2-2.27.1" class="pilcrow">¶</a></p>
</li>
</ul>
</section>
</div>
</section>
</div>
<div id="overview">
<section id="section-appendix.b">
      <h2 id="name-web-packaging-overview">
<a href="#section-appendix.b" class="section-number selfRef">Appendix B. </a><a href="#name-web-packaging-overview" class="section-name selfRef">Web Packaging Overview</a>
      </h2>
<p id="section-appendix.b-1">Web Packaging is comprised of two separate technologies: resource bundling
<span>[<a href="#I-D.yasskin-wpack-bundled-exchanges" class="xref">BUNDLE</a>]</span> and signed exchanges
<span>[<a href="#I-D.yasskin-http-origin-signed-responses" class="xref">SXG</a>]</span>.<a href="#section-appendix.b-1" class="pilcrow">¶</a></p>
<p id="section-appendix.b-2">In both the submissions and workshop discussion, the most controversial aspect
of the technology is the use of signed exchanges as an alternative means of
providing authority over a particular resource, for a few different reasons.<a href="#section-appendix.b-2" class="pilcrow">¶</a></p>
<p id="section-appendix.b-3">This appendix explains how authority works on the Web and how Web Packaging
proposes to change that.<a href="#section-appendix.b-3" class="pilcrow">¶</a></p>
<div id="authority-in-https">
<section id="section-b.1">
        <h2 id="name-authority-in-https">
<a href="#section-b.1" class="section-number selfRef">B.1. </a><a href="#name-authority-in-https" class="section-name selfRef">Authority in HTTPS</a>
        </h2>
<p id="section-b.1-1">The Web currently uses HTTPS <span>[<a href="#RFC7230" class="xref">HTTP</a>]</span> to establish a server's
authority -- that is, to give an assurance that the content came from where the
URL implies. The combination of URI scheme (https), domain name (or host), and
port number are formed into a single identifier, the origin <span>[<a href="#RFC6454" class="xref">ORIGIN</a>]</span>
to which content is attributed.<a href="#section-b.1-1" class="pilcrow">¶</a></p>
<p id="section-b.1-2">Web browsers use the certificate offered as part of a TLS connection
<span>[<a href="#RFC8446" class="xref">TLS</a>]</span> to servers in determining whether a server is authoritative
for that origin; see <span>[<a href="#RFC6454" class="xref">ORIGIN</a>]</span> and 
<span><a href="https://www.rfc-editor.org/rfc/rfc7230#section-9.1" class="relref">Section 9.1</a> of [<a href="#RFC7230" class="xref">HTTP</a>]</span>.
Content is attributed to a given URL only if it is received from a connection
to a server that is authoritative for the associated origin.<a href="#section-b.1-2" class="pilcrow">¶</a></p>
<p id="section-b.1-3">As an example, a web browser seeking to load <code>https://example.com/index.html</code>
makes a TLS connection to a server. As part of the TLS connection
establishment, the server offers a certificate for the name <code>example.com</code>. If
the browser accepts the certificate, it will then make requests for URLs on the
<code>https://example.com</code> origin on that connection and consider any answers from the
server to be authoritative.<a href="#section-b.1-3" class="pilcrow">¶</a></p>
<p id="section-b.1-4">This notion of authority is a crucial property of web security: only content
that is attributed to the same web origin can access all information in that
origin, including the content of most resources as well as state associated
with the origin, such as cookies. This separation ensures that sites can keep
secrets from each other, even when they are both loaded in the same browser.<a href="#section-b.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authority-in-web-packaging">
<section id="section-b.2">
        <h2 id="name-authority-in-web-packaging">
<a href="#section-b.2" class="section-number selfRef">B.2. </a><a href="#name-authority-in-web-packaging" class="section-name selfRef">Authority in Web Packaging</a>
        </h2>
<p id="section-b.2-1">Web Packaging, through the use of signed exchanges, aims to provide an
alternative means of establishing authority. A signed exchange is an expression
of an HTTP request and response (an exchange) with certain information stripped
and a digital signature applied.<a href="#section-b.2-1" class="pilcrow">¶</a></p>
<p id="section-b.2-2">The signature is made with a similar certificate to the one a server might
offer in HTTPS -- that certificate can also be used for HTTPS -- but it includes
a special attribute that denotes its suitability for signed exchanges.<a href="#section-b.2-2" class="pilcrow">¶</a></p>
<p id="section-b.2-3">A web browser that has been provided with a signed exchange can verify the
signature and, if the signature is valid and the certificate is acceptable,
use the content from the signed exchange. Critically, the web browser does not
make an HTTPS connection to a server to get the content or to verify the
signature.<a href="#section-b.2-3" class="pilcrow">¶</a></p>
<p id="section-b.2-4">In effect, Web Packaging moves from a model where authority is derived from the
delivery method (i.e., TLS) to an object security model, where authority is
derived from a signature on objects. In doing so, it aims to render the means
of delivery irrelevant to determinations of security.<a href="#section-b.2-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="applicability">
<section id="section-b.3">
        <h2 id="name-applicability">
<a href="#section-b.3" class="section-number selfRef">B.3. </a><a href="#name-applicability" class="section-name selfRef">Applicability</a>
        </h2>
<p id="section-b.3-1">Web Packaging does not claim to supplant the authority model of the Web
completely, but it does provide an alternative that might be used under certain
narrow conditions. In particular, Web Packaging is intended for use with
content that is not secret from an entity that is aware of the existence of
that content.<a href="#section-b.3-1" class="pilcrow">¶</a></p>
<p id="section-b.3-2">In aid of this goal, Web Packaging does not include information
   from exchanges that is related to the process of acquiring content
   nor does it include any information that is related to individual requests.
For instance, use of the
Set-Cookie header field is expressly forbidden, as it often contains
information that is related to a particular user.<a href="#section-b.3-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-amp-format-google-search-results-and-web-packaging">
<section id="section-b.4">
        <h2 id="name-the-amp-format-google-searc">
<a href="#section-b.4" class="section-number selfRef">B.4. </a><a href="#name-the-amp-format-google-searc" class="section-name selfRef">The AMP Format, Google Search Results, and Web Packaging</a>
        </h2>
<p id="section-b.4-1">The relationship between the AMP Project <span>&lt;<a href="https://amp.dev/">https://amp.dev/</a>&gt;</span> and Web Packaging is
complicated. The AMP Project, sponsored by Google, establishes a profile of HTML
with a stated goal of providing support for the best practices for the format,
with a strong emphasis on performance. The format tightly constrains the use of
HTML features but also offers a library of components that provide sanitized
implementations of many commonly used capabilities.<a href="#section-b.4-1" class="pilcrow">¶</a></p>
<p id="section-b.4-2">The connection to Web Packaging is bound up in the way that Google Search
treats AMP content specially. AMP content provides two properties that Google
Search exploits: metadata exposure and static analysis of active content.<a href="#section-b.4-2" class="pilcrow">¶</a></p>
<p id="section-b.4-3">AMP content provides metadata in a form that can be reliably extracted, using
the microformats defined by the Schema.org project <span>&lt;<a href="https://schema.org/">https://schema.org/</a>&gt;</span>. This
aspect of AMP has no effect on the discussion, except to the extent that this
relates to Google Search and their use of this metadata in populating the
carousel.<a href="#section-b.4-3" class="pilcrow">¶</a></p>
<p id="section-b.4-4">Constrained use of active content -- such as JavaScript -- in AMP makes it
possible to analyze content to verify that actions taken are narrowly limited.
This static analysis assures that AMP content can be served without affecting
other content on the same site. For Google Search, this is what enables the
loading of AMP content alongside search content and other AMP resources.<a href="#section-b.4-4" class="pilcrow">¶</a></p>
<p id="section-b.4-5">To provide preloading, Google operates the Google AMP Cache
<span>&lt;<a href="https://developers.google.com/amp/cache/">https://developers.google.com/amp/cache/</a>&gt;</span>, from which AMP content is served.
As a consequence, browsers attribute the content to the origin
<span>[<a href="#RFC6454" class="xref">ORIGIN</a>]</span> of the AMP Cache and not the publisher, creating some
confusion about how content is attributed, as discussed in the W3C finding on
distributed content <span>[<a href="#TAG-DC" class="xref">TAG-DC</a>]</span>.<a href="#section-b.4-5" class="pilcrow">¶</a></p>
<p id="section-b.4-6">An important goal of Web Packaging is to attribute content loaded from a cache,
such as the Google AMP Cache, to the publisher that created that content. For more on
this, see <a href="#nav" class="xref">Section 2.1</a>.<a href="#section-b.4-6" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-appendix.c">
      <h2 id="name-iab-members-at-the-time-of-">
<a href="#name-iab-members-at-the-time-of-" class="section-name selfRef">IAB Members at the Time of Approval</a>
      </h2>
<p id="section-appendix.c-1">Internet Architecture Board members at the time this document was approved
for publication were:<a href="#section-appendix.c-1" class="pilcrow">¶</a></p>
<ul class="ulEmpty">
<li class="ulEmpty" id="section-appendix.c-2.1">
          <p id="section-appendix.c-2.1.1"><span class="contact-name">Jari Arkko</span><a href="#section-appendix.c-2.1.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.2">
          <p id="section-appendix.c-2.2.1"><span class="contact-name">Alissa Cooper</span><a href="#section-appendix.c-2.2.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.3">
          <p id="section-appendix.c-2.3.1"><span class="contact-name">Stephen Farrell</span><a href="#section-appendix.c-2.3.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.4">
          <p id="section-appendix.c-2.4.1"><span class="contact-name">Wes Hardaker</span><a href="#section-appendix.c-2.4.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.5">
          <p id="section-appendix.c-2.5.1"><span class="contact-name">Ted Hardie</span><a href="#section-appendix.c-2.5.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.6">
          <p id="section-appendix.c-2.6.1"><span class="contact-name">Christian Huitema</span><a href="#section-appendix.c-2.6.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.7">
          <p id="section-appendix.c-2.7.1"><span class="contact-name">Zhenbin Li</span><a href="#section-appendix.c-2.7.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.8">
          <p id="section-appendix.c-2.8.1"><span class="contact-name">Erik Nordmark</span><a href="#section-appendix.c-2.8.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.9">
          <p id="section-appendix.c-2.9.1"><span class="contact-name">Mark Nottingham</span><a href="#section-appendix.c-2.9.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.10">
          <p id="section-appendix.c-2.10.1"><span class="contact-name">Melinda Shore</span><a href="#section-appendix.c-2.10.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.11">
          <p id="section-appendix.c-2.11.1"><span class="contact-name">Jeff Tantsura</span><a href="#section-appendix.c-2.11.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.12">
          <p id="section-appendix.c-2.12.1"><span class="contact-name">Martin Thomson</span><a href="#section-appendix.c-2.12.1" class="pilcrow">¶</a></p>
</li>
<li class="ulEmpty" id="section-appendix.c-2.13">
          <p id="section-appendix.c-2.13.1"><span class="contact-name">Brian Trammell</span><a href="#section-appendix.c-2.13.1" class="pilcrow">¶</a></p>
</li>
</ul>
</section>
<div id="authors-addresses">
<section id="section-appendix.d">
      <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">Martin Thomson</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mt@lowentropy.net" class="email">mt@lowentropy.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Mark Nottingham</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:mnot@mnot.net" class="email">mnot@mnot.net</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>