Replace GitHub issue relative URLs with absolute URLs

README.md

@@ -29,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
 

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

index.bs

@@ -187,53 +187,53 @@ Non-Functional Requirements {#requirements-non-functional}
 2.  It should be possible to implement an Open Screen controlling user agent on a
     low-end smartphone. See the [Device Specifications](device_specs.md) document
     for expected controlling user agent hardware specifications.
- 
+
 3.  The discovery and connection protocols should minimize power consumption,
     especially on the controlling user agent which is likely to be battery
     powered.
- 
+
 4.  The protocol should minimize the amount of information provided to a passive
     network observer about the identity of the user, activity on the controlling
     user agent and activity on the receiver.
- 
+
 5.  The protocol should prevent passive network eavesdroppers from learning
     presentation URLs, presentation IDs, or the content of presentation messages
     passed between controllers and presentations.
- 
+
 6.  The protocol should prevent active network attackers from impersonating a
     display and observing or altering data intended for the controller or
     presentation.
- 
+
 7.  The controlling user agent should be able to discover quickly when a
     presentation display becomes available or unavailable (i.e., when it connects
     or disconnects from the network).
- 
+
 8.  The controlling user agent should present sensible information to the user
     when a protocol operation fails.  For example, if a controlling user agent is
     unable to start a presentation, it should be possible to report in the
     controlling user agent interface if it was a network error, authentication
     error, or the presentation content failed to load.
- 
+
 9.  The controlling user agent should be able to remember authenticated
     presentation displays.  This means it is not required for the user to
     intervene and re-authenticate each time the controlling user agent connects
     to a pre-authenticated display.
- 
+
 10.  Message latency between the controller and a presentation should be minimized
     to permit interactive use.  For example, it should be comfortable to type in
     a form in the controller and have the text appear in the presentation in real
     time.  Real-time latency for gaming or mouse use is ideal, but not a
     requirement.
- 
+
 11. The controlling user agent initiating a presentation should communicate its
     preferred locale to the receiver, so it can render the presentation content
     in that locale.
- 
+
 12. It should be possible to extend the control protocol (above the discovery and
     transport levels) with optional features not defined explicitly by the
     specification, to facilitate experimentation and enhancement of the base
     APIs.
- 
+
 
 Discovery with mDNS {#discovery}
 ===============================
@@ -290,7 +290,7 @@ learn further metadata about it, it initiates a [[!QUIC]] connection to
 the IP and port from the SRV record.  Prior to authentication, a message may be
 exchanged (such as further metadata), but such info should be treated as
 unverified (such as indicating to a user that a display name of an
-unauthenticated agent is unverified).  
+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
@@ -370,7 +370,7 @@ transport section
 Many messages are requests and responses, so a common format is defined for
 those.  A request and a response includes a request ID which is an unsigned
 integer chosen by the requester.  Responses must include the request ID of the
-request they are associated with.  
+request they are associated with.
 
 Authentication {#authentication}
 ================================
@@ -397,8 +397,8 @@ 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-->
+presentation protocol.
+See https://github.com/webscreens/openscreenprotocol/issues/123 -->
 
 To learn which receivers are [=available presentation display=]s for a
 particular URL or set of URLs, the controller may send a
@@ -509,11 +509,11 @@ or not? -->
 
 To accept incoming connections requests from controller, a receiver
 must receive and process the presentation-connection-open-request
-message which contains the following values: 
+message which contains the following values:
 
 -   presentation-id: The ID of the presentation to connect to.
 
-- url: The URL of the presentation to connect to. 
+- url: The URL of the presentation to connect to.
 
 
 The receiver should, upon receipt of a
@@ -564,11 +564,11 @@ Presentation API {#presentation-api}
 ---------------------------------------------
 
 This section defines how [[PRESENTATION-API|Presentation API]] uses
-the messages defined in the previous sections.  
+the messages defined in the previous sections.
 Non-browser agents can also send and receive the same messages defined here.
 If so, a non-browser agent must follow the same restrictions for the
 presentation-id as the a does, as defined by [[PRESENTATION-API|Presentation
-API]] section 6.1 (at least 16 ASCII characters).  
+API]] section 6.1 (at least 16 ASCII characters).
 
 When [[PRESENTATION-API|Presentation API]] [section
 6.4.2](https://www.w3.org/TR/presentation-api/#sending-a-message-through-presentationconnection)
@@ -741,7 +741,7 @@ presentation-start-request = {
   request
   1: text ; presentation-id
   2: text ; url
-  3: [* http-header] ; headers 
+  3: [* http-header] ; headers
 }
 
 http-header = [

mdns.md

@@ -180,7 +180,8 @@ Describe how the discovery protocol meets functional requirements for the Remote
 Playback API.
 
 **TODO:** Fill in when Remote Playback requirements are
-known. See [Issue #3](../../issues/3).
+known. See
+[Issue #3](https://github.com/webscreens/openscreenprotocol/issues/3).
 
 # Reliability
 
@@ -223,7 +224,8 @@ operation.  Users may not even be aware of the situation, and it can be
 difficult or impossible for user agents to determine what component is blocking
 mDNS; users will just be unable to discover any presentation displays.
 
-[Issue #37](../../issues/37): Get reliability data.
+[Issue #37](https://github.com/webscreens/openscreenprotocol/issues/37): Get
+reliability data.
 
 ## Record caching
 
@@ -257,7 +259,8 @@ able to transmit a goodbye packet, listeners must wait for the expiration of
 their cached records to show the display as unavailable.  This depends on the
 TTL set with these records.
 
-[Issue #69](../../issues/69): Collect data on latency of discovery.
+[Issue #69](https://github.com/webscreens/openscreenprotocol/issues/69): Collect
+data on latency of discovery.
 
 # Network and power efficiency
 
@@ -273,7 +276,8 @@ The network utilization of mDNS depends on several factors including:
 Because mDNS behavior is specified, it should be possible to construct a model
 of network activity given assumptions about the factors above.
 
-[Issue #38](../../issues/38): Get network and power efficiency data.
+[Issue #38](https://github.com/webscreens/openscreenprotocol/issues/38): Get
+network and power efficiency data.
 
 # Ease of implementation / deployment
 
@@ -287,7 +291,7 @@ Windows 10 via
 [advertisement](https://docs.microsoft.com/en-us/uwp/api/Windows.Networking.ServiceDiscovery.Dnssd)
 and
 [device enumeration](https://docs.microsoft.com/en-us/uwp/api/windows.devices.enumeration)
-APIs. It is also supported in Chrome OS for Chrome apps via 
+APIs. It is also supported in Chrome OS for Chrome apps via
 [chrome.mdns](https://developer.chrome.com/apps/mdns).
 
 ## Open source implementations

quic.md

@@ -39,7 +39,8 @@ allow individual messages to be extracted, similar to how
 [HTTP/2 resources](https://tools.ietf.org/html/draft-ietf-quic-http-00)
 are mapped to Streams.
 
-[Issue #62](../../issues/62): If WebSockets are possible on QUIC, investigate how it is done.
+[Issue #62](https://github.com/webscreens/openscreenprotocol/issues/62): If
+WebSockets are possible on QUIC, investigate how it is done.
 
 With this outline, once connection was established, the requirements could be
 met as follows:
@@ -94,21 +95,24 @@ TBD once remote playback API requirements are set.
 
 # Reliability
 
-[Issue #63](../../issues/63): Get reliability data.
+[Issue #63](https://github.com/webscreens/openscreenprotocol/issues/63): Get
+reliability data.
 
 # Latency to establish a new connection
 
 QUIC is designed to minimize the number of round trips needed to establish or
 re-establish connections.
 
-[Issue #66](../../issues/66): Get connection latency data.
+[Issue #66](https://github.com/webscreens/openscreenprotocol/issues/66): Get
+connection latency data.
 
 # Latency to transmit messages
 
 QUIC allows for out of order packet delivery, which may improve the latency to
 deliver presentation connection messages on a congested or lossy network.
 
-[Issue #66](../../issues/66): Get message transmission latency data.
+[Issue #66](https://github.com/webscreens/openscreenprotocol/issues/66): Get
+message transmission latency data.
 
 # Ease of implementation / deployment
 
@@ -125,8 +129,8 @@ By relying on UDP, the IP addresses of both endpoints are visible to network
 observers.  The plaintext portions of the authentication handshake are also
 visible to observers.
 
-Once authentication is established, the current [QUIC
-crypto](https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit)
+Once authentication is established, the current
+[QUIC crypto](https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit)
 implementation encrypts full datagrams including all QUIC stream framing
 information.
 
@@ -136,11 +140,13 @@ QUIC depends only on UDP, which is supported for both IPv4 and IPv6.
 
 # Hardware requirements
 
-[Issue #64](../../issues/64): Obtain data on hardware requirements
+[Issue #64](https://github.com/webscreens/openscreenprotocol/issues/64): Obtain
+data on hardware requirements
 
 # Network and power efficiency
 
-[Issue #65](../../issues/65): Obtain data on network and power efficiency
+[Issue #65](https://github.com/webscreens/openscreenprotocol/issues/65): Obtain
+data on network and power efficiency
 
 # Standardization status