- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Wed, 12 Sep 2012 00:38:49 -0400
- To: public-webrtc@w3.org
On 9/11/2012 8:30 PM, Ejzak, Richard P (Richard) wrote: > Hi Randell, > 1. I do not think it is necessary to address the use of different protocols over an entire SCTP/DTLS association at this time. This may be useful for some applications but not necessary for many others. It would certainly need browser support and require significant new API work, which I am not advocating. > > 2. I do think it would be useful to allow JS negotiation of different protocols on individual DataChannels (that share a single association). I agree that your proposal has some support for this but a few small but important things are missing. > > 3. It should be possible to negotiate the characteristics of a set of DataChannels using SDP so that the application (which may support multiple variants) can negotiate a particular configuration of data channels all at once (alternative 2a). This is not important if all users download the exact same app, but is crucial in supporting a community of apps that support different (but partly overlapping) sets of capabilities. I understand your thought, though down that road eventually lies an m= line for each datachannel, with full O/A negotiation of each one, and years of work defining how each of these protocols is layered on top of SCTP/DTLS DataChannels. I may be exaggerating, but that's the logical conclusion of going in that direction - and to an extent, that's actually a superset of the problems SDP O/A was designed to solve. Basically, the cases we have are a) the single-domain case - both apps are the same or are written by the same entity and can be expected to know how to interoperate - what the labels mean, what the data transferred is, etc, and b) the federated case, where the two apps talking to each other are from different developers. That's the only case where extra info defining the meaning of a DataChannel gets you much. There was extensive discussion over months (starting 11 months ago, and more last winter through early spring) to arrive at this general design - and in fact I had advocated for a simpler solution that exposed more of the raw sctp interface - unidirectional channels, etc to the level where a protocol wasn't even needed, not even labels. But I was persuaded this was a better approach, and one far more usable by the primary target community (Web/WebApp developers); doubly so since it mirrors an existing API (WebSockets). This interchangeability with WebSockets is a major advantage for developers - they can take WebSockets code, change how they obtain the channel, and the rest of it should just work with DataChannel in place of WebSockets. You'll note that WebSockets does no protocol or other definition of the data within the WebSocket stream. In IETF land we tend to have tediously ( ;-) ) defined specs for wireline protocols since the assumption is based around every device having it's own implementation - and this would be the case for classic network elements and endpoints. In W3 land, the assumption is that the site controls both the servers and the JS code that accesses them, and "legacy" code and heterogeneous server/client setups are the (rare) exception and not the rule. WebRTC/RTCWEB straddles both worlds. Even labels goes beyond what's in WebSockets, but they make sense since they serve as an identifier to the side receiving the open what the stream is. > > 4. The only support you have for identifying the function of an individual channel is the "label". There is no mechanism to reserve labels for any specific meaning across applications. It also means that if two channels of the exact same type are needed then multiple labels need to be understood to imply the same function. It should be possible to specify a protocol name and protocol ID for use by each channel in addition to the label. If a proprietary application understands the label and a generic protocol identifier is sufficient, then nothing more is needed (the current proposal). But if the app wants to both create a label for a channel and describe the function desired of the channel, it should be able to do so. Neither of these needs to be vetted by the browser since it is for negotiation only between the JS apps. The browser simply inserts the agreed Protocol ID into each transmitted SCTP packet. These two items are added to the API and the SDP so that they can be negotiated between apps. Well, the PPID's are already used by the DataChannel protocol to identify strings vs binary (blob/arraybuffer) data. Thus far we've avoided any inline framing data; the PPIDs provide all we need. The question is what do we really gain in practice by doing this; what are the real-world usecases (almost by definition federation cases), and what are the alternatives available within the current design. (And what's the cost, in code and complexity?) > That's all that I think is needed. There has already been discussion of 2a, and it seems that the addition of the protocol name and id fields (which could be optional) would be small. Adding a second protocol string (or MIME type) would be easy. What to do with the string (other than make it available to the other side) is tougher. The ID fields would actually have a significant negative impact. -- Randell Jesup randell-ietf@jesup.org
Received on Wednesday, 12 September 2012 04:40:13 UTC