Rebase

index.bs

@@ -23,6 +23,7 @@ A human-readable <a href="http://www.w3.org/community/about/agreements/cla-deed/
 <!-- TODO: Can autolinks to HTML51 be automatically generated? -->
 <pre class="anchors">
 urlPrefix: https://w3c.github.io/presentation-api/#dfn-; type: dfn; spec: PRESENTATION-API
+    text: available presentation display
     text: controller
     text: controlling user agent
     text: controlling browsing context
@@ -256,7 +257,7 @@ display name before showing the user a verified display name.
 Advertising agents must include DNS TXT records with the following
 keys and values:
 
--   key "fp" with value of the certificate fingerpint of the advertising agent.
+-   key "fp" with value of the certificate fingerprint of the advertising agent.
     The format of the fingerprint is defined by [RFC 8122 section
     5](https://tools.ietf.org/html/rfc8122#section-5), excluding the
     "fingerprint:" prefix and including the hash function, space, and hex-encoded
@@ -293,7 +294,7 @@ unverified (such as indicating to a user that a display name of an
 unauthenticated agent is unverified).
 
 To learn further metadata, an agent may send an agent-info-request
-message (see Appendix A) and receive back an agent-info-response message.  The
+message (see [[#appendix-a]]) and receive back an agent-info-response message.  The
 messages may contain the following information with the following meaning:
 
 -   display-name: (required) The display name of the responding agent intended
@@ -333,7 +334,7 @@ keep the connection alive.
 
 The agent-info-response message and agent-status-response
 messages may be extended to include additional information not defined
-in this spec.  If done ad hoc by applications and not in future specs,
+in this spec.  If done ad-hoc by applications and not in future specs,
 keys should be chosen to avoid collision, such as by choosing large
 integers or long strings.  Agents must ignore keys in the
 agent-info-message that it does not understand to allow agents
@@ -352,11 +353,11 @@ is used.
 For each message, the sender must write to the QUIC stream the following:
 
 1.  A type key representing the type of the message, encoded as a variable-length
-    integer (see Appendix A for type keys)
+    integer (see [[#appendix-a]] for type keys)
 
 2.  The message length encoded as a variable-length integer
 
-3.  The messge encoded as CBOR (whose length must match the value in step 2)
+3.  The message encoded as CBOR (whose length must match the value in step 2)
 
 If an agent receives a message for which it does not recognize a
 type key, it must close the QUIC connection with an application error
@@ -377,30 +378,26 @@ Authentication {#authentication}
 
 Issue(102): Incorporate material from the \[J-PAKE](j-pake.md) document.
 
-Control Protocols {#control}
+Control Protocols {#control-protocols}
 ============================
 
-Issue(77): Describe CBOR based mechanism for
-exchanging control messages, results, and events.
-
-
 Presentation Protocol {#presentation-protocol}
 ---------------------------------------------
 
 This section defines the use of the Open Screen Protocol for starting,
-stopping, and controlling presenetations as defined by
+stopping, and controlling presentations as defined by
 [[PRESENTATION-API|Presentation API]].  A subsequent section will
 define how APIs in [[PRESENTATION-API|Presentation API]] map to the
 protocol messages defined in this section.
 
-For all messages defined in this section, see Appendix A for the full
+For all messages defined in this section, see [[#appendix-a]] for the full
 CDDL definitions.
 
 <!-- TODO: Add a capability that indicates support for the
 presentation protocol.
 See https://github.com/webscreens/openscreenprotocol/issues/123 -->
 
-To learn which receivers are [=available presentation display=]s for a
+To learn which receivers are [=available presentation displays=] for a
 particular URL or set of URLs, the controller may send a
 presentation-url-availability-request message with the following values:
 
@@ -463,7 +460,7 @@ consist of at least 16 ASCII characters.
 
 When the receiver receives the presentation-start-request, it should send back a
 presentation-start-response message after either the presentation URL has been
-feteched and loaded, or the receiver has failed to do so. If it has failed, it
+fetched and loaded, or the receiver has failed to do so. If it has failed, it
 must respond with the appropriate result (such as invalid-url or timeout).  If
 it has succeeded, it must reply with a success result.  Additionally, the
 response must include the following:
@@ -719,17 +716,18 @@ Mitigation Strategies {#security-mitigation}
 --------------------------------------------
 
 
-Appending A: Messages
-=====================
+Appendix A: Messages {#appendix-a}
+====================
+
 The following messages are defined with [[CDDL]]. When
 integer keys are used, a comment is appended to the line to indicate
 the name of the field. Each root message (one that can be put into a
-QUIC stream without being inclosed by another message) has a comment
+QUIC stream without being enclosed by another message) has a comment
 indicating the message type key.
 
 Smaller numbers should be reserved for message that will be sent more
 frequently or are very small or both and larger numbers should be
-reserved for messsages that are infrequently sent or large or both
+reserved for messages that are infrequently sent or large or both
 because smaller type keys encode on the wire smaller.
 
 <!-- TODO: Make a bikeshed formatter CDDL -->

index.html

@@ -1214,7 +1214,7 @@
 </style>
   <meta content="Bikeshed version a816d78e14132d4d4d2ee44ccaf1b8bc90ac75d5" name="generator">
   <link href="https://webscreens.github.io/openscreenprotocol/" rel="canonical">
-  <meta content="7d6057c4f01337bc8587be49103d692e8763f904" name="document-revision">
+  <meta content="675ca5260156b7e1fd42b55a771f1ff655f048bc" name="document-revision">
 <style>/* style-md-lists */
 
 /* This is a weird hack for me not yet following the commonmark spec
@@ -1403,7 +1403,7 @@
   <div class="head">
    <p data-fill-with="logo"></p>
    <h1 class="p-name no-ref" id="title">Open Screen Protocol</h1>
-   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2018-12-28">28 December 2018</time></span></h2>
+   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Editor’s Draft, <time class="dt-updated" datetime="2019-01-02">2 January 2019</time></span></h2>
    <div data-fill-with="spec-metadata">
     <dl>
      <dt>This version:
@@ -1418,7 +1418,7 @@ <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="cont
     </dl>
    </div>
    <div data-fill-with="warning"></div>
-   <p class="copyright" data-fill-with="copyright"> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2018 the Contributors to the Open Screen Protocol Specification, published by the <a href="https://www.w3.org/community/webscreens/">Second Screen Community Group</a> under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>.
+   <p class="copyright" data-fill-with="copyright"> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2019 the Contributors to the Open Screen Protocol Specification, published by the <a href="https://www.w3.org/community/webscreens/">Second Screen Community Group</a> under the <a href="https://www.w3.org/community/about/agreements/cla/">W3C Community Contributor License Agreement (CLA)</a>.
 A human-readable <a href="http://www.w3.org/community/about/agreements/cla-deed/">summary</a> is available. </p>
    <hr title="Separator for header">
   </div>
@@ -1447,7 +1447,7 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
     <li><a href="#control"><span class="secno">5</span> <span class="content">Messages delivery using CBOR and QUIC streams</span></a>
     <li><a href="#authentication"><span class="secno">6</span> <span class="content">Authentication</span></a>
     <li>
-     <a href="#control①"><span class="secno">7</span> <span class="content">Control Protocols</span></a>
+     <a href="#control-protocols"><span class="secno">7</span> <span class="content">Control Protocols</span></a>
      <ol class="toc">
       <li><a href="#presentation-protocol"><span class="secno">7.1</span> <span class="content">Presentation Protocol</span></a>
       <li><a href="#presentation-api"><span class="secno">7.2</span> <span class="content">Presentation API</span></a>
@@ -1466,7 +1466,7 @@ <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
       <li><a href="#security-data"><span class="secno">8.8</span> <span class="content">Data to be secured</span></a>
       <li><a href="#security-mitigation"><span class="secno">8.9</span> <span class="content">Mitigation Strategies</span></a>
      </ol>
-    <li><a href="#appending-a-messages"><span class="secno">9</span> <span class="content">Appending A: Messages</span></a>
+    <li><a href="#appendix-a"><span class="secno"></span> <span class="content">Appendix A: Messages</span></a>
     <li><a href="#conformance"><span class="secno"></span> <span class="content"> Conformance</span></a>
     <li>
      <a href="#index"><span class="secno"></span> <span class="content">Index</span></a>
@@ -1658,7 +1658,7 @@ <h2 class="heading settled" data-level="3" id="discovery"><span class="secno">3.
 keys and values:</p>
    <ul>
     <li data-md>
-     <p>key "fp" with value of the certificate fingerpint of the advertising agent.
+     <p>key "fp" with value of the certificate fingerprint of the advertising agent.
 The format of the fingerprint is defined by <a href="https://tools.ietf.org/html/rfc8122#section-5">RFC 8122 section
 5</a>, excluding the
 "fingerprint:" prefix and including the hash function, space, and hex-encoded
@@ -1685,7 +1685,7 @@ <h2 class="heading settled" data-level="4" id="transport"><span class="secno">4.
 unverified (such as indicating to a user that a display name of an
 unauthenticated agent is unverified).</p>
    <p>To learn further metadata, an agent may send an agent-info-request
-message (see Appendix A) and receive back an agent-info-response message.  The
+message (see <a href="#appendix-a">Appendix A: Messages</a>) and receive back an agent-info-response message.  The
 messages may contain the following information with the following meaning:</p>
    <ul>
     <li data-md>
@@ -1720,7 +1720,7 @@ <h2 class="heading settled" data-level="4" id="transport"><span class="secno">4.
 keep the connection alive.</p>
    <p>The agent-info-response message and agent-status-response
 messages may be extended to include additional information not defined
-in this spec.  If done ad hoc by applications and not in future specs,
+in this spec.  If done ad-hoc by applications and not in future specs,
 keys should be chosen to avoid collision, such as by choosing large
 integers or long strings.  Agents must ignore keys in the
 agent-info-message that it does not understand to allow agents
@@ -1736,11 +1736,11 @@ <h2 class="heading settled" data-level="5" id="control"><span class="secno">5. <
    <ol>
     <li data-md>
      <p>A type key representing the type of the message, encoded as a variable-length
-integer (see Appendix A for type keys)</p>
+integer (see <a href="#appendix-a">Appendix A: Messages</a> for type keys)</p>
     <li data-md>
      <p>The message length encoded as a variable-length integer</p>
     <li data-md>
-     <p>The messge encoded as CBOR (whose length must match the value in step 2)</p>
+     <p>The message encoded as CBOR (whose length must match the value in step 2)</p>
    </ol>
    <p>If an agent receives a message for which it does not recognize a
 type key, it must close the QUIC connection with an application error
@@ -1755,17 +1755,15 @@ <h2 class="heading settled" data-level="5" id="control"><span class="secno">5. <
 request they are associated with.</p>
    <h2 class="heading settled" data-level="6" id="authentication"><span class="secno">6. </span><span class="content">Authentication</span><a class="self-link" href="#authentication"></a></h2>
    <p class="issue" id="issue-7d8c18ff"><a class="self-link" href="#issue-7d8c18ff"></a> Incorporate material from the <a href="j-pake.md">J-PAKE</a> document. <a href="https://github.com/webscreens/openscreenprotocol/issues/102">&lt;https://github.com/webscreens/openscreenprotocol/issues/102></a></p>
-   <h2 class="heading settled" data-level="7" id="control①"><span class="secno">7. </span><span class="content">Control Protocols</span><a class="self-link" href="#control①"></a></h2>
-   <p class="issue" id="issue-35428ee4"><a class="self-link" href="#issue-35428ee4"></a> Describe CBOR based mechanism for
-exchanging control messages, results, and events. <a href="https://github.com/webscreens/openscreenprotocol/issues/77">&lt;https://github.com/webscreens/openscreenprotocol/issues/77></a></p>
+   <h2 class="heading settled" data-level="7" id="control-protocols"><span class="secno">7. </span><span class="content">Control Protocols</span><a class="self-link" href="#control-protocols"></a></h2>
    <h3 class="heading settled" data-level="7.1" id="presentation-protocol"><span class="secno">7.1. </span><span class="content">Presentation Protocol</span><a class="self-link" href="#presentation-protocol"></a></h3>
    <p>This section defines the use of the Open Screen Protocol for starting,
-stopping, and controlling presenetations as defined by <a data-link-type="biblio" href="#biblio-presentation-api">Presentation API</a>.  A subsequent section will
+stopping, and controlling presentations as defined by <a data-link-type="biblio" href="#biblio-presentation-api">Presentation API</a>.  A subsequent section will
 define how APIs in <a data-link-type="biblio" href="#biblio-presentation-api">Presentation API</a> map to the
 protocol messages defined in this section.</p>
-   <p>For all messages defined in this section, see Appendix A for the full
+   <p>For all messages defined in this section, see <a href="#appendix-a">Appendix A: Messages</a> for the full
 CDDL definitions.</p>
-   <p>To learn which receivers are <a data-link-type="dfn">available presentation display</a>s for a
+   <p>To learn which receivers are <a data-link-type="dfn" href="https://w3c.github.io/presentation-api/#dfn-available-presentation-display" id="ref-for-dfn-available-presentation-display">available presentation displays</a> for a
 particular URL or set of URLs, the controller may send a
 presentation-url-availability-request message with the following values:</p>
    <ul>
@@ -1823,7 +1821,7 @@ <h3 class="heading settled" data-level="7.1" id="presentation-protocol"><span cl
 consist of at least 16 ASCII characters.</p>
    <p>When the receiver receives the presentation-start-request, it should send back a
 presentation-start-response message after either the presentation URL has been
-feteched and loaded, or the receiver has failed to do so. If it has failed, it
+fetched and loaded, or the receiver has failed to do so. If it has failed, it
 must respond with the appropriate result (such as invalid-url or timeout).  If
 it has succeeded, it must reply with a success result.  Additionally, the
 response must include the following:</p>
@@ -2034,15 +2032,15 @@ <h3 class="heading settled" data-level="8.8" id="security-data"><span class="sec
     <li data-md>
    </ol>
    <h3 class="heading settled" data-level="8.9" id="security-mitigation"><span class="secno">8.9. </span><span class="content">Mitigation Strategies</span><a class="self-link" href="#security-mitigation"></a></h3>
-   <h2 class="heading settled" data-level="9" id="appending-a-messages"><span class="secno">9. </span><span class="content">Appending A: Messages</span><a class="self-link" href="#appending-a-messages"></a></h2>
-    The following messages are defined with <a data-link-type="biblio" href="#biblio-cddl">[CDDL]</a>. When
+   <h2 class="heading settled" id="appendix-a"><span class="content">Appendix A: Messages</span><a class="self-link" href="#appendix-a"></a></h2>
+   <p>The following messages are defined with <a data-link-type="biblio" href="#biblio-cddl">[CDDL]</a>. When
 integer keys are used, a comment is appended to the line to indicate
 the name of the field. Each root message (one that can be put into a
-QUIC stream without being inclosed by another message) has a comment
-indicating the message type key. 
+QUIC stream without being enclosed by another message) has a comment
+indicating the message type key.</p>
    <p>Smaller numbers should be reserved for message that will be sent more
 frequently or are very small or both and larger numbers should be
-reserved for messsages that are infrequently sent or large or both
+reserved for messages that are infrequently sent or large or both
 because smaller type keys encode on the wire smaller.</p>
 <pre>; type key 10
 agent-info-request = {
@@ -2385,6 +2383,12 @@ <h2 class="no-num no-ref heading settled" id="index"><span class="content">Index
     <li><a href="#ref-for-presentationconnection">2.1. Presentation API Requirements</a> <a href="#ref-for-presentationconnection①">(2)</a>
    </ul>
   </aside>
+  <aside class="dfn-panel" data-for="term-for-dfn-available-presentation-display">
+   <a href="https://w3c.github.io/presentation-api/#dfn-available-presentation-display">https://w3c.github.io/presentation-api/#dfn-available-presentation-display</a><b>Referenced in:</b>
+   <ul>
+    <li><a href="#ref-for-dfn-available-presentation-display">7.1. Presentation Protocol</a>
+   </ul>
+  </aside>
   <aside class="dfn-panel" data-for="term-for-dfn-controlling-browsing-context">
    <a href="https://w3c.github.io/presentation-api/#dfn-controlling-browsing-context">https://w3c.github.io/presentation-api/#dfn-controlling-browsing-context</a><b>Referenced in:</b>
    <ul>
@@ -2460,6 +2464,7 @@ <h3 class="no-num no-ref heading settled" id="index-defined-elsewhere"><span cla
     <a data-link-type="biblio">[PRESENTATION-API]</a> defines the following terms:
     <ul>
      <li><span class="dfn-paneled" id="term-for-presentationconnection" style="color:initial">PresentationConnection</span>
+     <li><span class="dfn-paneled" id="term-for-dfn-available-presentation-display" style="color:initial">available presentation display</span>
      <li><span class="dfn-paneled" id="term-for-dfn-controlling-browsing-context" style="color:initial">controlling browsing context</span>
      <li><span class="dfn-paneled" id="term-for-dfn-controlling-user-agent" style="color:initial">controlling user agent</span>
      <li><span class="dfn-paneled" id="term-for-dfn-presentation-display" style="color:initial">presentation display</span>
@@ -2505,8 +2510,6 @@ <h2 class="no-num no-ref heading settled" id="issues-index"><span class="content
   <div style="counter-reset:issue">
    <div class="issue"> Requirements for Remote Playback API <a href="https://github.com/webscreens/openscreenprotocol/issues/3">&lt;https://github.com/webscreens/openscreenprotocol/issues/3></a><a href="#issue-a1f35a95"> ↵ </a></div>
    <div class="issue"> Incorporate material from the <a href="j-pake.md">J-PAKE</a> document. <a href="https://github.com/webscreens/openscreenprotocol/issues/102">&lt;https://github.com/webscreens/openscreenprotocol/issues/102></a><a href="#issue-7d8c18ff"> ↵ </a></div>
-   <div class="issue"> Describe CBOR based mechanism for
-exchanging control messages, results, and events. <a href="https://github.com/webscreens/openscreenprotocol/issues/77">&lt;https://github.com/webscreens/openscreenprotocol/issues/77></a><a href="#issue-35428ee4"> ↵ </a></div>
    <div class="issue"> Propose control protocol for Remote
 Playback API. <a href="https://github.com/webscreens/openscreenprotocol/issues/12">&lt;https://github.com/webscreens/openscreenprotocol/issues/12></a><a href="#issue-eaed3698"> ↵ </a></div>
   </div>