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

[Christer Holmberg <[e-mail]>]

The pull request:

https://github.com/cdh4u/draft-datachannel-t140/pull/32

Regards,

Christer

On 17/09/2019, 18.27, "mmusic on behalf of Paul Kyzivat" <[e-mail] on behalf of [e-mail]> wrote:

    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
    
    _______________________________________________
    mmusic mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/mmusic