[rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03

Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 23 February 2014 03:07 UTC

Message-ID: <530965D5.9090105@alum.mit.edu>
Date: Sat, 22 Feb 2014 22:07:01 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/BPouNVYuaTTc2Rgh07eCRXKgMko
Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-03
Precedence: list

A few comments on this draft:

* Section 5.1:

       DATA_CHANNEL_PARTIAL_RELIABLE_TIMED (0x02):  The channel provides
          a partial reliable in-order bi-directional Communication
          channel.  User messages might not be transmitted or
          retransmitted after a specified life-time given in milli-
          seconds in the Reliability Parameter.  This life-time starts
          when providing the user message to the Javascript engine.

The last sentence above is troubling. This protocol won't always be used 
via Javascript. Can we please have a definition that doesn't depend on 
that? Is the timing being done by SCTP, or are you assuming that a data 
channel layer on top of SCTP is doing this? Is it specific to SCEP, or 
is it still applicable when the channel has been established via 
external negotiation?

Does use of this option imply that retransmission continues until this 
time limit is reached? Or might it stop after some implementation 
defined number of retransmissions?

The description of the reliability parameter says:

       This field is ignored if a reliable channel is used.

IMO folk wisdom says that some specific value (e.g., 0) should be 
prescribed to be used in such cases. That makes things more 
deterministic and provides more flexibility in extending the protocol in 
the future.

The name "Protocol" (and "Protocol Length") here is troublesome, because 
it is ambiguous with other sorts of uses. (See my comment about this 
point earlier today wrt draft-ietf-rtcweb-data-channel-07.) Others 
(including draft-ejzak-mmusic-data-channel-sdpneg-00 and websockets) 
call this "subprotocol". Using that would make it a little less confusing.

Also, ISTM that all of these things are applicable to externally 
negotiated channels, and so ought to be defined by 
draft-ietf-rtcweb-data-channel. (But of course their use in the 
DATA_CHANNEL_OPEN message belongs here.)

* Section 8.4:

ISTM there ought to be a template of the minimum information that the 
specification for a registered (sub)protocol MUST (SHOULD?) include. E.g.,

- what Channel Type(s) are valid for this (sub)protocol
- A contact for more information about this protocol

	Thanks,
	Paul

[rtcweb] Comments on draft-ietf-rtcweb-data-proto… Paul Kyzivat
Re: [rtcweb] Comments on draft-ietf-rtcweb-data-p… Michael Tuexen
Re: [rtcweb] Comments on draft-ietf-rtcweb-data-p… Paul Kyzivat
Re: [rtcweb] Comments on draft-ietf-rtcweb-data-p… Michael Tuexen