Partially address #342 and #343. by markafoltz · Pull Request #378 · w3c/openscreenprotocol

markafoltz · 2026-10-29T19:27:53Z

This PR partially addresses issues in the application protocol specification after the split from the network specification.

After the split there are two main areas to fix.

The spec needs a message transport between agents, but does not define what it is.
The spec contains many references to QUIC implementation details.

To decouple the application protocol from QUIC, this PR defines an OSP transport, OSP stream, and an OSP message. It lists some requirements to be an OSP transport and then rewrites other places in the spec to refer to these concepts instead of QUIC.

w3c#342) Builds on w3c#378. Replaces direct references to mDNS, DNS-SD, and TLS-secured QUIC in the Presentation API and Remote Playback API discovery sections and in the security and privacy sections with references to the discovery guidelines, OSP connections, and transport requirements.

Builds on w3c#378. Rewrites the video, data, and feedback frame sections, the request and watch ID note, protocol extensions, and Appendix A to use OSP message streams and OSP connections. Moves the QUIC keep-alive details that w3c#378 removed from the application spec into the network spec.

baylesj · 2026-10-29T21:16:52Z

+who are in phyiscal proximity to both agents (i.e., browser and receiver
+device).  For that reason, discovery mechanisms that rely on phyical proximity
+such as WiFi or the display of a QR Code are good candidates to implement these
+mechanisms.  If an [=OSP agent=] is discovered by another solely by communicaiton


Nit: spelling (communicaiton).

baylesj · 2026-10-29T21:17:09Z

+provides one such implementation using multicast DNS (mDNS).
+
+[=OSP agents=] are intended to support interactive media experiences to users
+who are in phyiscal proximity to both agents (i.e., browser and receiver


Nit: spelling

baylesj · 2026-10-29T21:17:53Z

+Application Protocol should meet the following functional requirements:
+
+1.  Support the bi-directional sending and receiving of [=OSP messages=].
+1.  Support the simultaneous and bi-directional [=OSP message streams=].  There


Nit: "the" is superfluous in this first sentence IIUC.

baylesj · 2026-10-29T21:35:23Z

-Screen Network Protocol, which provides a way for browsers and devices to
-discover, connect, and authenticate each other on a local area network.
+connection technologies between browsers and devices.  There are guidelines on
+how allow browsers and devices should discover one another, and requirements


Typo:

Suggested change

how allow browsers and devices should discover one another, and requirements

how browsers and devices should discover one another, and requirements

baylesj · 2026-10-29T21:35:25Z


-Issue(342): Define Discovery Requirements
+Discovery mechanisms between [=OSP agents=] should provide sufficient information to
+initiate an network data transport between them, typically by obtaining an IP


Suggested change

initiate an network data transport between them, typically by obtaining an IP

initiate a network data transport between them, typically by obtaining an IP

baylesj · 2026-10-29T21:35:36Z

+connection alive for the purposes of sending or receiving messages, the
+connection should be closed.
+
+In order to keep a [=OSP connection=] alive, an agent may send an


Suggested change

In order to keep a [=OSP connection=] alive, an agent may send an

In order to keep an [=OSP connection=] alive, an agent may send an

baylesj · 2026-10-29T21:35:38Z

+[=agent-status-request=] message, and any agent that receives an
+[=agent-status-request=] message should send an [=agent-status-response=]
+message. Such messages should be sent with enough frequency to prevent the
+underlying transport from closing from inactivity.


The QUIC-specific parts removed here (close with error code 5139, 25 s idle_timeout transport parameter, do not use QUIC PING frames, reset the idle timer on every stream write) are not in network.bs. network.bs lines 393-395 only say "periodically sending data". Can these move to the Network Protocol so implementers still have them?

baylesj · 2026-10-29T21:35:39Z

+underlying transport from closing from inactivity.
+
+Note: An idle timeout of 25 seconds is recommended.  If an [=OSP agent=] does
+not send or receive a message within that period, it shoul send an an


Suggested change

not send or receive a message within that period, it shoul send an an

not send or receive a message within that period, it should send an

baylesj · 2026-10-29T21:35:39Z

+If an [=OSP agent=] suspends its [=OSP connections=] (e.g. for power saving
+reasons), it should attempt to resume [=OSP connections=] to the [=OSP agents=]
+to which it was previously connected when possible.  Once reconnected, it should
+send `agent-status-request` messages to those agents.


Suggested change

send `agent-status-request` messages to those agents.

send [=agent-status-request=] messages to those agents.

baylesj · 2026-10-29T21:35:40Z

+[=OSP messages=] in order, they must be sent in one [=OSP message stream=].
+Independent groups of [=OSP messages=] (with no ordering dependency across
+groups) should be sent in different [=OSP message streams=].  In order to put
+multiple CBOR-serialized messages into the the same [=OSP message stream=], the


Suggested change

multiple CBOR-serialized messages into the the same [=OSP message stream=], the

multiple CBOR-serialized messages into the same [=OSP message stream=], the

backkem · 2026-10-29T22:11:19Z

Some notes, beyond the points @baylesj raised:

Ordering groups. Could the spec say which messages must share an OSP message stream? Presentation connection messages need per-connection ordering, and a connection message shouldn't overtake the presentation-start-response / presentation-connection-open-response that carries its connection ID. Relatedly: is a transport with a single ordered stream (e.g. one data channel) conforming, or are concurrent streams required?
Errors. With the 404 close code gone, should the transport carry an error code and reason, or should the protocol define an error message? What's expected for malformed CBOR, recognized-but-unsupported messages (e.g. streaming messages to an agent without that capability), and requests nobody handles? Closing the whole connection on an unknown type key also seems harsh for extensions.
Peer identity. The transport requirements cover message authentication and confidentiality, but not a stable, authenticated peer identity. The application protocol relies on one for request ID scoping, reconnects and trusting agent-info. Could that be a transport requirement?
ID scope across reconnects. What is the scope of request IDs (and watch IDs and presentation connection IDs): one OSP connection, or the agent pair across reconnects? This matters more now that connections can be suspended and resumed. The streaming section also still refers to a state-token rule that neither spec defines.

backkem · 2026-10-29T22:19:25Z

FWIW, I happened to do an experimental version of the Application Protocol in TypeScript over DataChannels/WebTransport earlier (note: that's before I saw this PR): https://github.com/backkem/go-lp2p/tree/main/osp-app#osp-app . It's just meant as a testing ground. If there is interest we could make it more rigorous.

markafoltz added 3 commits October 29, 2026 12:18

Address #342 and #343

6797ea7

Add Issue #346

e6fea43

Correct issue #

6b8d9fa

markafoltz requested review from baylesj and tidoust October 29, 2026 19:27

This was referenced Oct 29, 2026

Remove remaining QUIC references from message delivery #370

Open

Use generic discovery and transport terms in API and security sections #371

Open

baylesj reviewed Oct 29, 2026

View reviewed changes

Navigation Menu

Repository navigation

Partially address #342 and #343. - #378

Partially address #342 and #343.#378
markafoltz wants to merge 3 commits into
mainfrom
osp-app-issues-1

markafoltz commented Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

baylesj Oct 29, 2026

Uh oh!

backkem commented Oct 29, 2026

Uh oh!

backkem commented Oct 29, 2026 •

edited

Loading

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

	how allow browsers and devices should discover one another, and requirements
	how browsers and devices should discover one another, and requirements

	initiate an network data transport between them, typically by obtaining an IP
	initiate a network data transport between them, typically by obtaining an IP

	In order to keep a [=OSP connection=] alive, an agent may send an
	In order to keep an [=OSP connection=] alive, an agent may send an

	not send or receive a message within that period, it shoul send an an
	not send or receive a message within that period, it should send an

	send `agent-status-request` messages to those agents.
	send [=agent-status-request=] messages to those agents.

	multiple CBOR-serialized messages into the the same [=OSP message stream=], the
	multiple CBOR-serialized messages into the same [=OSP message stream=], the

Conversation

markafoltz commented Oct 29, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

backkem commented Oct 29, 2026

Uh oh!

backkem commented Oct 29, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

backkem commented Oct 29, 2026 •

edited

Loading