Merge branch 'gh-pages' into issue-13

README.md

@@ -1,9 +1,11 @@
 ## Open Screen Protocol
 
-This repository is used to incubate and develop specifications of network
-protocols that implement the
-[Presentation API](https://w3c.github.io/presentation-api/) and
-[Remote Playback API](https://w3c.github.io/remote-playback/).
+This repository is used to incubate and develop the
+[Open Screen Protocol](https://webscreens.github.io/openscreenprotocol/),
+which is a suite of network protocols that allow user agents to
+implement the [Presentation API](https://w3c.github.io/presentation-api/)
+and [Remote Playback API](https://w3c.github.io/remote-playback/)
+in an interoperable fashion.
 
 This work is in scope for the
 [W3C Second Screen Community Group](https://www.w3.org/community/webscreens/)
@@ -27,7 +29,8 @@ submitted:
   - [QUIC](quic.md)
   - [WebRTC Data Channel](datachannel.md)
 - [Control Protocol](control_protocol.md)
-- Authentication ([Issue #13](../../issues/13))
+- Authentication
+  ([Issue #13](https://github.com/webscreens/openscreenprotocol/issues/13))
 
 ### Background Information
 

benchmarks/discovery.md

@@ -22,7 +22,7 @@ network discovery protocols proposed for Open Screen:
   * Time to find all devices
   * Time to discover that a device has been connected
   * Time to discover that a device has been disconnected
-  
+
 # Test Environment
 
 ## Hardware and Operating System
@@ -149,7 +149,8 @@ to revisit this by designing power benchmarks that can be run on mobile phones a
 mobile OSes (Android, iOS).  As a first approximation we can allow discovery to run
 to a steady state and look at the resulting battery level.
 
-[Issue #72: Investigate power consumption measurement](issues/72)
+[Issue #72](https://github.com/webscreens/openscreenprotocol/issues/72):
+Investigate power consumption measurement
 
 ### SSDP
 

benchmarks/transport.md

@@ -25,7 +25,7 @@ network trasnport protocols proposed for Open Screen:
   * Time to initiate a new connection
   * Time to transmit a control message (from first byte sent to last byte received)
   * Time to transmit an application message (from first byte sent to last byte received)
-  
+
 # Test Environment
 
 ## Hardware and Operating System
@@ -70,7 +70,8 @@ same command line flags as the QUIC driver will need to be written.  The driver
 will include the WebRTC library and a client and server for the bootstrap
 channel.
 
-[Issue #73](../issues/73): Define boostrap mechanism for RTCDataChannel.
+[Issue #73](https://github.com/webscreens/openscreenprotocol/issues/73): Define
+boostrap mechanism for RTCDataChannel.
 
 WebRTC exposes byte level statistics for individual data channels through its
 [API](https://w3c.github.io/webrtc-stats/#dcstats-dict*), although not
@@ -134,7 +135,7 @@ baseline data.
 
 ## Mobile Device Benchmarking
 
-See [Issue #72](../issues/72).
+See [Issue #72](https://github.com/webscreens/openscreenprotocol/issues/72).
 
 ## Multi-receiver cases
 

biblio.json

@@ -0,0 +1,26 @@
+{
+    "CDDL": {
+        "authors": [
+            "H. Birkholz",
+            "C. Vigano",
+            "C. Bormann"
+        ],
+        "href": "https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/",
+        "title": "Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures",
+        "status": "Internet Draft",
+        "publisher": "IETF"
+    },
+    "QUIC": {
+        "authors": [
+            "J. Iyengar",
+            "M. Thomson"
+        ],
+        "date": "23 October 2018",
+        "href": "https://tools.ietf.org/html/draft-ietf-quic-transport-16",
+        "title": "Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures",
+        "status": "Internet Draft",
+        "publisher": "IETF"
+    }
+}
+
+

control_protocol.md

@@ -126,7 +126,8 @@ The content of the `MESSAGE_BODY` is not constrained by the generic message
 structure, and must be interpreted according to the `MESSAGE_TYPE`.
 
 **TODO:** Investigate variable length integers for `MESSAGE_LENGTH`,
-`SEQUENCE_ID` to save bytes for short messages.  See [Issue #45](issues/45).
+`SEQUENCE_ID` to save bytes for short messages.  See
+[Issue #45](https://github.com/webscreens/openscreenprotocol/issues/45).
 
 ### Protocol ID
 
@@ -311,7 +312,8 @@ presentation.  An alternative mechanism would allow the controlling user agent
 to retrieve URL patterns from a receiver that match the URLs supported by that
 receiver.
 
-**TODO**: Add messages for this based on conclusion to [Issue #21](issues/21).
+**TODO**: Add messages for this based on conclusion to
+[Issue #21](https://github.com/webscreens/openscreenprotocol/issues/21).
 
 Note that the URLs sent by the Presentation Availability Request may contain
 custom (non-https) schemes.  Please review [Schemes and Open Screen
@@ -771,8 +773,9 @@ Byte Offset
 - `FRIENDLY_NAME_CONTENT` is a valid UTF-8 encoded string with the friendly name
   of the presentation display.  It is exactly `FRIENDLY_NAME_LENGTH` bytes in
   length.
-
-**TODO:** [Representation of BCP-47 language tags](issues/47)
+
+**TODO:**
+[Representation of BCP-47 language tags](https://github.com/webscreens/openscreenprotocol/issues/47)
 
 ### Presentation Info
 
@@ -832,8 +835,8 @@ controller knows not to attempt reconnection with just the origin.
 
 ## Remote Playback API Control Protocol
 
-**TODO:** Fill in when Remote Playback requirements are known. See [Issue
-#3](issues/3).
+**TODO:** Fill in when Remote Playback requirements are known. See
+[Issue #3](https://github.com/webscreens/openscreenprotocol/issues/3).
 
 ## Design Discussion
 

datachannel.md

@@ -94,15 +94,15 @@ For receiver initiated termination:
 The WebRTC framework supports media codec negotiation and real-time media
 transport.
 
-[Issue #3](../../issues/3): Fill in
+[Issue #3](https://github.com/webscreens/openscreenprotocol/issues/3): Fill in
 when Remote Playback requirements are known.
 
 # Reliability
 
 WebRTC is designed to be operated in a heterogeneous network environment, using
 ICE for address discovery and built-in negotiation/re-negotiation mechanism.
 
-[Issue #30](../../issues/30):
+[Issue #30](https://github.com/webscreens/openscreenprotocol/issues/30):
 Get reliability data.
 
 # Latency to establish a new connection
@@ -113,7 +113,7 @@ There are three sources of latency:
 3. Adding an additional Data Channel on top of an existing peer-to-peer
    connection.
 
-[Issue #31](../../issues/31):
+[Issue #31](https://github.com/webscreens/openscreenprotocol/issues/31):
 Get connection latency data.
 
 # Latency to transmit a message
@@ -122,7 +122,7 @@ Data Channel is based on SCTP, which allows for out of order packet delivery and
 may improve the latency to deliver presentation connection messages on a
 congested or lossy network.
 
-[Issue #31](../../issues/31):
+[Issue #31](https://github.com/webscreens/openscreenprotocol/issues/31):
 Get supporting data.
 
 # Ease of implementation / deployment
@@ -151,14 +151,14 @@ Data Channel depends on SCTP over UDP, which is supported for both IPv4 and IPv6
 Major desktop, laptop, and high-end mobile phone should be able to create single
 RTC connection since major browser on desktop and mobile already ship WebRTC.
 
-[Issue #32](../../issues/32):
+[Issue #32](https://github.com/webscreens/openscreenprotocol/issues/32):
 Obtain data on hardware requirements.
 
 # Network and power efficiency
 
 Maintaining a long-lived Data Channel might not be power efficient.
 
-[Issue #33](../../issues/33):
+[Issue #33](https://github.com/webscreens/openscreenprotocol/issues/33):
 Obtain data on network and power efficiency.
 
 # Standardization status