Issue 11 control protocol #44
Conversation
|
This looks very good and well documented! One thing that we already discussed in the past (although I'm not clear we came to a conclusion) is that, if I understand correctly, the suggested "Presentation Display Availability Request" will leak presentation request URLs to discovered receivers at a stage where the user has not yet given her consent to use any specific receiver, that is before the user selects the receiver. Now this approach has the advantage of allowing any kind of suport logic in receivers. Any alternative would be much less flexible, as it would require a declarative mechanism that receivers would use to explain what types of URLs they support, and which the controller would in turn use to decide whether a given receiver is likely compatible with a given URL. PS: FWIW, there are a few typos here and there. I'll try to point them out when I have more time available. |
|
Great draft! You may complete the rest of the message definitions. How confident we are at this point after completing the evaluation of QUIC #9 and RTCDataChannel #10 (aka Mozilla's proposal) that these two transports are the ones this control protocol is to be layered on top off, and not others? I've understood for both of these transports, there's implementers' interest, which is a good sign. Is anyone thinking of using HTTP/2, WebSockets, or a custom protocol anymore? The sooner we're able to nail down the set of transports to target, the easier it will be to make progress on the control protocol. So I'm wondering if we could nail down the supported transports now to ensure the constraints in protocol design would be known upfront. |
control_protocol.md
Outdated
| other party, intact and in-order. | ||
|
|
||
| The RTCDataChannel does support variable length messages (**TODO:** find a spec | ||
| for it!), although there are |
There was a problem hiding this comment.
If I understand correctly, draft-ietf-rtcweb-data-channel-13 defines the message limits of data channels. Section 4 defines the requirements:
Req. 8: The data channel transport protocol should support unbounded-length "messages" (i.e., a virtual socket stream) at the application layer, for such things as image-file-transfer; Implementations might enforce a reasonable message size limit.
On the other hand, Section 6.6 illustrates message interleaving to avoid monopolization of data channel:
The SCTP base protocol specified in [RFC4960] does not support the interleaving of user messages. Therefore sending a large user message can monopolize the SCTP association. To overcome this limitation, [I-D.ietf-tsvwg-sctp-ndata] defines an extension to support message interleaving, which SHOULD be used. As long as message interleaving is not supported, the sender SHOULD limit the maximum message size to 16 KB to avoid monopolization.
There was a problem hiding this comment.
Thanks. I think I was looking for SCTP as the layer that provides message framing.
control_protocol.md
Outdated
| 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 |
There was a problem hiding this comment.
A starting point for the investigation: https://en.wikipedia.org/wiki/Variable-length_quantity. Includes links to particular encodings, e.g, Protocol Buffers. Should we raise as a separate issue for discussion?
There was a problem hiding this comment.
Good idea. Filed #45 and will link from this TODO.
|
The draft looks great! A minor comment: One of my interests is how to pass preferred locale through the control protocol. I expect that such kind of parameters could optionally be attached to appropriate request messages (e.g. Presentation Initiation Request). Is it correct? |
|
This is great, thank you Mark! @anssiko said:
This is something we should discuss with the Media and Entertainment IG, in relation to TV industry second screen protocols. For example, the companion screen protocol in HbbTV 2.0 uses WebSockets (with SSDP and DIAL) but also UDP for messages involved in synchronising content between screens. |
|
@tidoust Yes, the ability to "pre-filter" receivers by presentation URL is not included in this first draft. #21 suggests that this could be done in discovery, or later after a control protocol is established, and the exact filtering mechanism isn't decided yet. I will add a TODO referencing that issue near the presentation availability request definition. |
|
@anssiko @chrisn No evaluation has yet taken place of HTTP/2 or WebSockets as potential transports. From my point of view, I won't be proposing them unless they provide a capability missing from QUIC or RTCDataChannel that can't be addressed at the control protocol level. It would be helpful to reach out to the M&E IG on this. If they are invested in these mechanisms and want to pursue them for open screen, we can attempt a deeper dive. |
|
@tomoyukilabs Good point - this was missed in the initial definition of the presentation initiation request. Will update in the next commit. |
I tried to move this discussion to the mailing list https://lists.w3.org/Archives/Public/public-secondscreen/2017Aug/0063.html and asked if @chrisn could bring this topic to the M&E IG. Agreed that the first good step for M&E IG participants interested in other transports would be to do similar evaluation that has been done already for QUIC #9 and RTCDataChannel #10. |
| [interleave messages](https://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-13#section-6.6) | ||
| for fairness. | ||
|
|
||
| Meanwhile, QUIC is stream-oriented and not message oriented, so a message |
There was a problem hiding this comment.
Since QUIC is stream-oriented, it'll have hand-of-line blocking issue while transmitting large message. Maybe we can introduce additional out-of-band channel, this can be discussed in another issue.
There was a problem hiding this comment.
QUIC is designed to prevent this from happening by multiplexing among streams between two endpoints. The proposal submitted here suggests assigning one stream to each PresentationConnection, so a message sent on one connection shouldn't block a message sent on another. This is something we can collect data on as well.
control_protocol.md
Outdated
| - `NUM_URLS` is an unsigned positive 16-bit integer that is identical to | ||
| `NUM_URLS` in the corresponding Presentation Display Availability Request. | ||
| - Each `AVAILABILITY_RESULT` is an unsigned 8-bit integer containing the | ||
| availability result for the Nth URL in the request. The results are as follows: |
There was a problem hiding this comment.
Receiver side might have its own preference of the compatible URLs. We can extend this message by sending a list of (index, result) tuples.
There was a problem hiding this comment.
Good point, however, the current algorithm for starting presentation allows the controller to determine the URL priority:
https://w3c.github.io/presentation-api/#dfn-start-a-presentation-connection, step 5.
Meaning, if the page creates PresentationRequest([URL1, URL2]), and the receiver reports [URL2, URL1] as compatible, the page must still initiate presentation with URL1.
However, I could see an argument for allowing the receiver to influence this priority, for example preferring pre-installed apps for some URLs. So I'll add this enhancement in case we update the controller algorithms.
control_protocol.md
Outdated
| Values shorter than 128 bytes should be zero-byte padded. | ||
| - `URL_LENGTH` is an unsigned positive 32-bit integer with the length, in bytes, | ||
| of the presentation URL. | ||
| - `URL_CONTENT` is the presentation URL, encoded according to RFC 3986. |
There was a problem hiding this comment.
Do we want to allow arbitrary HTTP header to be override, i.e. make receiver send particular cookie as sender to simplify the authentication procedure?
There was a problem hiding this comment.
That seems like a reasonable enhancement, although the API spec doesn't call for it now. Done.
|
Thanks for the feedback @schien. I uploaded a commit with a couple of your suggested changes, and will now merge as I think everyone has provided feedback. This is a working document so everyone should feel free to make further comments/suggestions on GH. |
PTAL @schien @anssiko @tidoust @chrisn
This is a draft of a wire format for the control protocol for the Presentation API. It defines a generic message format supporting commands, events, and request/response pairs. It should be possible to layer it on top of QUIC or an RTCDataChannel (with a few modifications in either case).
I define a few example messages using this format for presentation screen availability and presentation initiation. I'll take any feedback on this draft and fill out the rest of the message definitions in another pull request.
If the feedback asks for major changes, then I will recommend that the author submit a separate side-by-side proposal :-)