diff --git a/application.bs b/application.bs index 41614ed..fb72cf7 100644 --- a/application.bs +++ b/application.bs @@ -1715,13 +1715,11 @@ frame message contains an encoded video frame (an encoded image) at a specific point in time or over a specfic time range (if the duration is known). A series of encoded video frames that share a codec and a timeline form a video encoding. -Issue(343): Rewrite the following to not depend on QUIC specifics. - To allow for video frames to be sent out of order, they may be sent in -separate QUIC streams. If the encoding is a long chain of encoded video frames -dependent on the previous one back until an independent frame, it may make sense -to send them in a single QUIC stream starting at the indepdendent frame and -ending at the last dependent frame. +separate [=OSP message streams=]. If the encoding is a long chain of encoded +video frames dependent on the previous one back until an independent frame, it +may make sense to send them in a single [=OSP message stream=] starting at the +independent frame and ending at the last dependent frame. : encoding-id :: Identifies the media encoding to which this video frame belongs. @@ -1779,11 +1777,9 @@ Media senders may send timed data to media receivers by sending [=data-frame=] m contains an arbitrary payload that can be synchronized with audio and video. A series of data frames that share a data type and timeline form a data encoding. -Issue(343): Rewrite the following to not depend on QUIC specifics. - To allow for data frames to be sent out of order, they may be sent in separate -QUIC streams, but more than one data frame may be sent in one QUIC stream if -that makes sense for a specific type of data. +[=OSP message streams=], but more than one data frame may be sent in one [=OSP +message stream=] if that makes sense for a specific type of data. : encoding-id :: Identifies the data encoding to which this data frame belongs. This can be @@ -1827,10 +1823,8 @@ requests. A video key frame is requested by sending a video-request message with the following keys and values. -Issue(343): Rewrite the following to not depend on QUIC specifics. - -To allow for video frames to be sent out of order, they may be sent in separate -QUIC streams. +To allow for feedback messages to be sent out of order, they may be sent in +separate [=OSP message streams=]. : encoding-id :: The encoding for which the media sender should send a new key frame. @@ -2009,10 +2003,8 @@ Other IDs that must be unique and would cause confusion if one side loses state, such as `streaming-session-id`, `media-session-id`, and `encoding-id` should be treated the same. -Issue(343): Rewrite the following to not depend on QUIC specifics. - -Note: Request and watch IDs are not tied to any particular QUIC connection -between agents. If a QUIC connection is closed, an agent should not discard +Note: Request and watch IDs are not tied to any particular [=OSP connection=] +between agents. If an [=OSP connection=] is closed, an agent should not discard requests, responses, watches, or events related to the other party. This allows agents to save power by closing unused connections. @@ -2049,8 +2041,8 @@ Note: See [[#messages]] for how agents handle unknown message type keys. It is recommended that extension messages are also encoded in CBOR, to simplify implementations and provide an easier path to standardization of extension protocols. However, this is not required; agents that support non-CBOR -extensions must be able to decode QUIC streams that contain a mix of CBOR -messages and non-CBOR extension messages. +extensions must be able to decode [=OSP message streams=] that contain a mix of +CBOR messages and non-CBOR extension messages. Protocol Extension Fields {#protocol-extension-fields} ------------------------- @@ -2286,8 +2278,8 @@ this unusual syntax to reduce the number of bytes-on-the-wire, while maintaining a human-readable name for each key. Integer keys are used instead of object arrays to allow for easy indexing of optional fields. -Each root message (one that can be put into a QUIC stream without being enclosed -by another message) has a comment indicating the message type key. +Each root message (one that can be sent as an [=OSP message=] 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 messages diff --git a/network.bs b/network.bs index 6d9b146..f053b76 100644 --- a/network.bs +++ b/network.bs @@ -393,6 +393,12 @@ before sending further messages. If a listening agent wishes to receive messages from an advertising agent or an advertising agent wishes to send messages to a listening agent, it may wish to keep the QUIC connection alive by periodically sending data on the connection. +Agents should do this by sending `agent-status-request` messages (defined in the +Open Screen Application Protocol) more frequently than the QUIC idle_timeout +transport parameter (see [=Transport Parameter Encoding=] in [[!RFC9000]]), and +QUIC PING frames should not be used. An idle_timeout transport parameter of 25 +seconds is recommended. Once neither side needs to keep the connection alive, +the connection should be closed with an application error code of 5139. If an OSP agent suspends its network connectivity (e.g. for power saving reasons), it should attempt to resume QUIC connections to the OSP agents to