Re: Data API: what is agreed, what is open

Randell Jesup wrote:
> If we're bi-directional, we need to exchange some type of open-time
> metadata (which we probably need for other reasons anyways), so the
> channel type (or default channel type) can be included in that. Even for

That's one route, but I think we have to acknowledge that's a pretty big 
departure from Harald's desire to just reflect the SCTP semantics as 
closely as possible unless we have a reason not to.

> unidirectional, we're talking about sending some sort of metadata, so
> the stream type could be signaled, if it ends up being needed (and I'm
> not sure it will).

I'm not sure what you mean by stream type. If you mean 
reliable/ordered/etc., that gets signaled in every packet, and shouldn't 
need to be negotiated. The sender decides what it wants, and the 
receiver lives with it. If you mean DOMString/Blob/etc., I thought the 
plan was to use the PPID field for that, which again is included in 
every packet, and shouldn't have to be negotiated.

> media streams); any remote party we're connected to *should* follow the
> spec, and so not mix types.

I carefully said "browser" and not "WebRTC client" to imply something 
that conforms to the _protocol_ specifications, but is not constrained 
by the W3C API. If you want to disallow changing the packet flags for a 
channel at the protocol level, I'll be happy to let you write the patch 
for the SCTP stack that rejects them so we don't ship a browser that 
violates your additional restriction on what it is allowed to receive. 
But if you don't constrain the receiver, then the sender _is_ allowed to 
send it, and simply declaring that it MUSTn't when it works perfectly 
fine isn't going to fix that. Only having the most prevalent 
implementations drop the packets on the floor will.

Received on Friday, 10 February 2012 21:53:48 UTC