Skip to content

Update Issues/TODOs #161

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
May 9, 2019
Merged

Update Issues/TODOs #161

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
b4f2c7b
Update Issues/TODOs
markafoltz May 9, 2019
f215da5
Rebase
markafoltz May 9, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
100 changes: 55 additions & 45 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -28,9 +28,12 @@ Markup Shorthands: markdown yes, dfn yes, idl yes
is available.
</p>

<!-- TODO: Add short names to Presentation API spec,
so that BS autolinking works as designed. -->
<!-- TODO: Can autolinks to HTML51 be automatically generated? -->
Issue: Add short names to Presentation API spec, so that BS autolinking works as designed.


Issue: 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
Expand Down Expand Up @@ -58,6 +61,10 @@ urlPrefix: https://www.w3.org/TR/html51/single-page.html; type: dfn; spec: HTML5
text: media element
</pre>

<pre class="link-defaults">
spec:html; type:method; text:postMessage(message, targetOrigin, transfer)
</pre>

<h2 class='no-num no-toc no-ref' id='status'>Status of this document</h2>

This specification was published by the [Second Screen Community
Expand Down Expand Up @@ -126,6 +133,7 @@ For additional terms and idioms specific to the [[PRESENTATION-API|Presentation
API]] or [[REMOTE-PLAYBACK|Remote Playback API]], please consult the respective
specifications.

Issue(144): Receiver/Controller/Agent terminology

Requirements {#requirements}
============================
Expand Down Expand Up @@ -251,6 +259,8 @@ Discovery with mDNS {#discovery}
Agents may discover one another using [[RFC6763|DNS-SD]] over [[RFC6762|mDNS]].
To do so, agents must use the service name "_openscreen._udp.local".

Issue(107): Define suspend and resume behavior for discovery protocol

Advertising Agents must use an instance name that is a prefix of the agent's
display name. If the instance name is not the complete display name (if it has
been truncated), it must be terminated by a null character. It is prefix so
Expand All @@ -275,15 +285,15 @@ keys and values:
All agents must support the following hash functions: "sha-256", "sha-512".
Agents must not support the following hash functions: "md2", "md5".

<!-- TODO: include cross references to the specs for these hash functions. -->
Issue: Include cross references to the specs for these hash functions.

: mv
:: An unsigned integer value that indicates that
metadata has changed. The advertising agent must update it to a greater
value. This signals to the listening agent that it should connect to the
advertising agent to discover updated metadata.

<!-- TODO: Add examples of sample mDNS records. -->
Issue: Add examples of sample mDNS records.


Future extensions to this QUIC-based protocol can use the same metadata
Expand Down Expand Up @@ -349,13 +359,14 @@ If a client agent wishes to send messages to a server agent, the client
agent can connect to the server agent "on demand"; it does not need to
keep the connection alive.

The agent-info-response 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,
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
to easily extend this message.
Issue(108): Define suspend and resume behavior for connection protocol

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, 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 to easily extend this message.

Messages delivery using CBOR and QUIC streams {#messages}
========================================================
Expand Down Expand Up @@ -389,6 +400,8 @@ 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.

Issue(139): Clarify scoping/uniqueness of request IDs

Authentication {#authentication}
================================

Expand Down Expand Up @@ -499,9 +512,10 @@ protocol messages defined in this section.
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 -->
Issue(123): Add a capability that indicates support for the presentation protocol


Issue(160): Refinements to Presentation API protocol

To learn which receivers are [=available presentation displays=] for a
particular URL or set of URLs, the controller may send a
Expand All @@ -520,6 +534,7 @@ presentation-url-availability-request message with the following values:
to. The controller must choose a value that is unique across all
presentation URL availability watches to the same receiver.

Issue(145): Watch ID Uniqueness

In response, the receiver should send one presentation-url-availability-response
message with the following values:
Expand Down Expand Up @@ -590,8 +605,6 @@ response must include the following:
the message receiver chooses the connection-id, it may keep the ID unique
across connections, thus making message demuxing/routing easier.

<!-- TODO: Add optional HTTP response code to the response? -->

To send a presentation message, the controller or receiver may send a
presentation-connection-message with the following values:

Expand Down Expand Up @@ -626,10 +639,6 @@ message contains the following values:
: reason
:: The reason the presentation was terminated.

<!-- TODO: Split up reason into reason and whether it was triggered by the user
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:
Expand Down Expand Up @@ -662,6 +671,7 @@ values:
: connection-id
:: The ID of the connection to close.

Issue(124): Is a Presentation close/terminate from a controller a request/response or event?

The receiver should, upon receipt of a presentation-connection-close-request,
send back a presentation-connection-close-response message with the following
Expand All @@ -670,6 +680,8 @@ values:
: result
:: If the close succeed or failed, and if it failed why it failed.

Issue(138): Remove presentation-connection-close-response message

The receiver may also close a connection without a request from the controller
to do so and without terminating a presentation. If it does so, it should send
a presentation-connection-close-event to the controller with the following
Expand All @@ -685,11 +697,6 @@ values:
:: A debug message suitable for a log or perhaps presented to
the user with more explanation as to why it was closed.

<!-- TODO: Why does the Presentation API spec not mention the use of the close
message? -->

<!-- TODO: Specify message ordering groups. -->


Presentation API {#presentation-api}
---------------------------------------------
Expand All @@ -716,8 +723,8 @@ browsing context with D, presentationUrl, and I as parameters.", U (the
(the receiver), with I for the presentation identifier and presentationUrl for
the selected presentation URL.

<!-- TODO: Once the Presentation API has text about reconnecting via an
implementation specific mechanism, quote that here and map it to a message -->
Issue: Once the Presentation API has text about reconnecting via an
implementation specific mechanism, quote that here and map it to a message.

When [[PRESENTATION-API#sending-a-message-through-presentationconnection|section
6.5.2]] says "Using an implementation specific mechanism, transmit the contents
Expand Down Expand Up @@ -759,12 +766,13 @@ defined in this section.
For all messages defined in this section, see Appendix A for the full
CDDL definitions.

<!-- TODO: Add a capability that indicates support for the
remote playback protocol.
See https://github.com/webscreens/openscreenprotocol/issues/123 -->
<!-- TODO: Frequency to update current-time (HtmlMediaElement does every 250ms?) -->
<!-- TODO: extended mime types in source tag? -->
<!-- TODO: media queries replacing URLs? -->
Issue(123): Add a capability that indicates support for the remote playback protocol


Issue(148): Make a required/default remote playback state table


Issue(159): Refinements to Remote Playback protocol

To learn which receivers are [=compatible remote playback device=]s (also called
available [=remote playback devices=]) for a particular URL or set of URLs, the
Expand All @@ -774,7 +782,8 @@ following values:
: urls
:: A list of [=media resources=]. Must not be empty.

<!-- TODO: Should we allow different headers for different URLs? -->
Issue(146): Remote Playback HTTP headers

: headers
:: headers that the receiver should use to fetch the
urls. For example,
Expand Down Expand Up @@ -851,6 +860,7 @@ values:
ignore them and the controller will learn that it does not support them from
the remote-playback-start-response message.

Issue(147): Remote playback ID uniqueness

When the receiver receives a remote-playback-start-request message, it should
send back a remote-playback-start-response message. It should do so quickly,
Expand Down Expand Up @@ -1037,8 +1047,7 @@ intentionally mirror settable attributes and methods of the
if a cue ID is invalid (removing an un-added ID or adding an ID twice, for example),
the receiver may reject the text track change.

<!-- TODO: Add a table for whether it's required and what the default is -->

Issue: Add a table for whether it's required and what the default is.

The states sent by the receiver include the following individual state values,
each of which is optional. This allows the receiver to update the controller
Expand Down Expand Up @@ -1215,9 +1224,7 @@ based on changes to the local media element and receive
remote-playback-modify-response and remote-playback-state-event messages to
change the local media element based on changes to the remote playback state.

<!-- TODO: Have a very descriptive, precise algorithm for what messages to send
when the local media element changes and what changes to make to the remote
media element when controls are received? -->
Issue(158): Algorithm for what messages to send when local/remote media element changes

When
[[REMOTE-PLAYBACK#establishing-a-connection-with-a-remote-playback-device|section
Expand Down Expand Up @@ -1370,8 +1377,7 @@ UI of the user agent during the display selection or display authentication
process. It can be an implementation choice whether the user agent clears or
retains this data when the user clears browsing data.

Issue(132): [Privacy] Fate of metadata / authentication history when clearing
browsing data
Issue(132): Fate of metadata / authentication history when clearing browsing data

### Other Considerations ### {#other-considerations}

Expand Down Expand Up @@ -1409,6 +1415,8 @@ The Open Screen Protocol addresses these considerations by:
{{PresentationConnection|PresentationConnections}} so that agents can track
the number of active connections.

Issue(143): Notify endpoints when new connection is created

Remote Playback API Considerations {#remote-playback-considerations}
----------------------------------

Expand All @@ -1433,7 +1441,7 @@ before user-mediated authentication takes place.
Passive attackers may also attempt timing attacks to learn the
cryptographic parameters of the TLS 1.3 QUIC connection.

Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
Issue(130): Review attack and mitigation considerations for TLS 1.3

### Local active network attackers ### {#local-active-mitigations}

Expand Down Expand Up @@ -1462,6 +1470,8 @@ Flagging means that the user is notified of the attempt at impersonation. In
the last case, the user should be required to re-authenticate to the
already-trusted agent to verify its identity.

Issue(118): UI guidelines for pairing and trusted/untrusted data

The second is through management of the low-entropy secret during mutual
authentication:

Expand All @@ -1476,7 +1486,7 @@ The active attacker may also attempt to disrupt data exchanged over the QUIC
connection by injecting or modifying traffic. These attacks should be mitigated
by a correct implementation of TLS 1.3.

Issue(130): [Security] Review attack and mitigation considerations for TLS 1.3
Issue(130): Review attack and mitigation considerations for TLS 1.3

### Remote active network attackers ### {#remote-active-mitigations}

Expand All @@ -1485,7 +1495,7 @@ Protocol agents, because a misconfigured firewall or NAT could expose a
LAN-connected agent to the broader Internet. Open Screen Protocol agents
should be secure against attack from any Internet host.

Issue(131): [Security] Mitigations for remote network attackers
Issue(131): Mitigations for remote network attackers

### Denial of service ### {#denial-of-service-mitigations}

Expand Down
Loading