Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

[Harald Alvestrand <[e-mail]>]

On 03/11/2013 07:51 PM, MARCON, JEROME (JEROME) wrote:
> Randell,
>
> Assuming that some day a spec defines the transport of T.140 (or whatever similar protocol) over RTCWeb data channels
> - with a registered subprotocol
> - with multiple reliability options supported
> - requiring some new data channel properties
> - of which some are assymetric between the endpoints (like the "characters per second" defined in [RFC4103].
>
> Then (in the current version of your proposal) it seems to me that
> * Because current DATA_CHANNEL_OPEN syntax is not extensible:
> - it is not possible to carry these new properties in DATA_CHANNEL_OPEN
>
> * Because the successful response to an open data channel request does not exist:
> - it is not possible to agree on assymetric property values
>
> * Because the error response to an open data channel has no payload (error):
> - an endpoint cannot easily know if this subprotocol is supported or which reliability properties are supported. Unless it sends as many DATA_CHANNEL_OPEN
>   messages as there are combinations of {subprotocol, property variants}

Is there any reason why the app that desires to use such a protocol over 
a data channel shouldn't send a new message (defined in the protocol) 
after the DATA_CHANNEL_OPEN saying what the desired properties are, and 
with an accept/reject message on the return channel?

One of the desirable properties of DATA_CHANNEL_OPEN is that it's 
simple. I'd like to keep it that way.