[MMUSIC] Comments on draft-ejzak-mmusic-data-channel-sdpneg-01

[Paul Kyzivat <[e-mail]>]

This is in much better shape now - having caught up with changes in the 
related drafts. Here are a few comments and suggestions:

* Section 5.1.1.1:

Rather than using 'unordered=1' for unordered, and 'unordered=0' for 
ordered, it would be more obvious to simply use 'ordered' and 'unordered'.

Are all combinations of max_retr, max-time, unordered, [ordered] 
allowed? (There are 8 such combinations, but there are only 6 data 
channel types in rtcweb-data-protocol.)

(The syntax for the dcmap attribute suggests that all combinations are 
valid.)

Also, the syntax forces the fields to be entered in a particular order. 
That is likely to be a source of errors.

* Sections 5.1.1.2 & 5.1.1.3

the definition 'text = byte-string' has to be wrong. That will suck up 
the rest of the line, including following ";" separated items. The 
examples show that you mean a quoted string, but 4566 doesn't have a 
definition for that.

* Section 5.1.1.4

The section title (and usage through the document) calls this parameter 
'max_retr", but the syntax defines it as 'maxretr'.

IMO a separator in this is good, but I would prefer it to be "-" rather 
than "_".

I think maxretrvalue could be defined using 'integer' from 4566. That is 
almost the same, but can't start with a zero. It would be good to 
specify the valid range for this this parameter. That could be specified 
by reference to rtcweb-data-protocol.

* Section 5.1.1.5

My comments on 5.1.1.4 apply here as well.

Here is a proposal for updating the syntax to deal with all of the 
above. (Note that I've also changed to use the format I have proposed in 
rfc4566bis.)

    Name: dcmap

    Value: dcmap-value

    Usage Level: media

    Charset Dependent: no

    Syntax:

       dcmap-value     = dcmap-stream-id
                         [ SP dcmap-opt *(";" dcmap-opt) ]
       dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
                         / maxretr-opt / maxtime-opt

       dcmap-stream-id = 1*DIGIT
       ordering-opt    = "ordered" / "unordered"
       subprotocol-opt = "subprotocol=" quoted-string
       label-opt       = "label=" quoted-string
       maxretr-opt     = "max-retr=" maxretr-value
       maxretr-value   = integer
       maxtime-opt     = "max-time=" maxtime-value
       maxtime-value   = integer ; milliseconds

       quoted-string   = DQUOTE *(quoted-char / escaped-char) DQUOTE
       quoted-char     = SP / quoted-visible
       quoted-visible  = %21 / %23-24 / %26-7E ; VCHAR without " or %
       escaped         = "%" HEXDIG HEXDIG
       DQUOTE          = <from-RFC5234>
       integer         = <from-RFC5234>

    Examples:

       a=dcmap:0
       a=dcmap:1 subprotocol="BFCP";max-time=60000
       a=dcmap:2 subprotocol="MSRP";ordered;label="MSRP"
       a=dcmap:3 label="Label 1";unordered;max-retr=5
       a=dcmap:4 label="foo%09bar";ordered;max-time=15000;max-retr=3

Note that I made subprotocol optional, like the others. Also, I defined 
quoted-string so that it can only contain SP and visible ascii 
characters other that " and % as literals. Anything else must be in hex. 
There are lots of other possibilities for how to do that, but at least 
that one is clear when you look at it.

* Section 5.1.2

    Each sub-protocol specific SDP attribute that would normally be used
    to negotiate the subprotocol using SDP is replaced with an attribute
    of the form "a=dcsa:sctp-port:stream-id original-attribute", ...

None of the examples include the sctp-port. I guess this should have 
said: "a=dcsa:stream-id original-attribute".

But that highlights the need for of a formal specification of the dcsa 
attribute. E.g.,

    Name: dcsa

    Value: dcsa-value

    Usage Level: media

    Charset Dependent: no

    Syntax:

       dcsa-value      = stream-id SP attribute
       attribute       = <from-RFC4566>

    Example:

       a=dcsa:2 accept-types:text/plain

* Section 5.2.1

    This specification allows simultaneous use of external and internal
    negotiation.  However, a single stream is managed using one method at
    a time.  Stream ids that are not currently used in SDP can be used
    for internal negotiation.  Stream id determination per external
    negotiation may not align with DTLS based termination.  This could
    cause glare conditions when one side trying to do external
    negotiation on a stream id while the other end trying to open data
    channel on the same stream id using internal negotiation.  To avoid
    these glare conditions this specification recommends that the data
    channel stack user always selects stream ids per SDP offer/answer
    rule even when internal negotiation is used.  To avoid glare
    conditions, it is possible to come up with a different stream id
    allocation scheme, but such schemes are outside the scope of this
    specification

I can't quite grok what the above paragraph is trying to tell me.

	Thanks,
	Paul

On 10/20/14 8:25 AM, DRAGE, Keith (Keith) wrote:
> I have just posted the following which is the revision following the discussion in the London meeting.
>
> Additionally further updates have taken place to align with the latest versions of other MMUSIC drafts.
>
> Regards
>
> Keith
>
>
> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-01.txt
> has been successfully submitted by Keith Drage and posted to the IETF repository.
>
> Name:		draft-ejzak-mmusic-data-channel-sdpneg
> Revision:	01
> Title:		SDP-based "SCTP over DTLS" data channel negotiation
> Document date:	2014-10-20
> Group:		Individual Submission
> Pages:		21
> URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/
> Htmlized:       http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-01
>
> Abstract:
>     The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>     charged to provide protocols to support direct interactive rich
>     communications using audio, video, and data between two peers' web-
>     browsers.  For the support of data communication, the RTCWeb working
>     group has in particular defined the concept of bi-directional data
>     channels over SCTP, where each data channel might be used to
>     transport other protocols, called sub-protocols.  Data channel setup
>     can be done using either the internal in-band band (also referred to
>     as 'internal' for the rest of the document) WebRTC Data Channel
>     Establishment Protocol or some external out-of-band simply referred
>     to as 'external negotiation' in the rest of the document . This
>     document specifies how the SDP offer/answer exchange can be used to
>     achieve such an external negotiation.  Even though data channels are
>     designed for RTCWeb use initially they may be used by other protocols
>     like, but not limited to, the CLUE protocol.  This document is
>     intended to be used wherever data channels are used.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>