Re: [MMUSIC] Draft new version: t140-data-channel-usage-03

[Paul Kyzivat <[e-mail]>]

The changes made in -03 seem fine to me.

Then I realized that I have only been looking at diffs for awhile, and 
haven't carefully reviewed the full document for awhile. So I did that, 
and found some other thing that I think are worthy of consideration:

* Section 4:

s/proceudres/procedures/

* Section 4.2:

The subsections 4.2.n describe some specific SDP attributes that may be 
used with T.140 data channels. But it isn't definitive about other 
attributes. I think you should be explict whether other attributes maybe 
included. In any case, I think it would be prudent to specify that if 
other attributes are *received* and are not understood then they are to 
be ignored, in order to be consistent with SDP treatment of attributes.

* Section 4.2.1:

This section is a little hard to follow. The use of fmtp with data 
channels is complicated, since the value part of fmtp is dependent on 
the fmt in the m= line. You do reference RFC4103, but it is still a leap 
to put this all together.

I suggest you first discuss the general use of fmtp with data channels - 
that the value syntax of fmtp is to follow RFC4103.

*Then* you can move on to discuss the use of 'cps'.

It isn't clear to me if there are any other meaningful or permitted fmtp 
parameters. I suggest you make a definitive statement about this.

* Section 5:

These examples are good. But there is no example for CPS, and it would 
be nice to have one. Rather than having a separate example for each, I 
think it would be sufficient to fold multiple attributes into a single 
example.

* Section 5.3:

In the following:

    As described in [T140], buffering can be used to reduce overhead,
    with the maximum buffering time being 500 ms.  It can also be used
    for staying within the maximum character transmission rate
    (Section 4.2), if such has been provided by the peer.

it is unclear to me whether the 500ms max time is applicable when using 
buffering to stay within the max transmission rate. I presume not. Can 
you be more explicit?

* Section 5.4:

It isn't clear to me whether this is talking about failure and 
re-establishment of individual data *channels*, or of the containing 
SCTP association. I guess you mean both. But it would be good to be 
explicit, since the process for doing so is a bit different.

* General:

Perhaps replace the references to RFC4566 throughout with references to 
RFC4566bis. It is already in the editor's queue so shouldn't cause a 
delay. Since you have no dependency on the updates in RFC4566bis this 
isn't an essential change. It is just a nice-to-have.

	Thanks,
	Paul