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

[JM1]
________________________________________
De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Harald Alvestrand [harald@alvestrand.no]
Date d'envoi : lundi 11 mars 2013 20:22
À : rtcweb@ietf.org
Objet : Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

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.

[JM1] All right, this would work in many cases (brand-new protocols, and protocols "adapted" over RTCWeb data channels, which have or can easily integrate capabilities negotiation). In some cases though, that would be challenging: e.g. the character-oriented T.140 protocol.

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb