Subject: [MMUSIC] Comments on draft-ejzak-dispatch-webrtc-data-channel-sdpneg-00 (

From: Paul Kyzivat <[email-masked]>
Date: Tue, 04 Feb 2014 11:59:29 -0500

(Trying yet again, this time on the proper list)

Richard,

What is the status of this work?
Are you planning on a new version? (I guess a new one is needed just to 
bind it to mmusic rather than dispatch.)

Also, these naming issues extend to draft-ietf-mmusic-sctp-sdp-05.
Can I get your support in lobbying for naming changes there too?

	Thanks,
	Paul

On 10/28/13 12:08 PM, Paul Kyzivat wrote:
> On 10/28/13 11:07 AM, Ejzak, Richard P (Richard) wrote:
>> Thanks, Paul.
>>
>> I agree that the WebRTC specific aspects need to be clearly separated
>> from the core protocol aspects.  I'll do that in the next version.
>
> Thanks!
>
>> I also agree that "WebRTC" is not needed in either name.  Are you ok
>> with just "DataChannel" and "dcsa" instead of "WebRTC-DataChannel" and
>> "wdcsa"?  I'm not really picky about the names and am open to any
>> reasonable alternative...
>
> Its just an esthetic issue, so I'm not too picky.
>
> DataChannel is better than WebRTC-DataChannel.
> But IMO CamelCase identifiers aren't in stylistic agreement with SDP.
> So perhaps data-channel?
>
> "dcsa" seems reasonable.
>
>      Thanks,
>      Paul
>
>> BR, Richard
>>
>>> -----Original Message-----
>>> From: [email-masked] [mailto:[email-masked]] On
>>> Behalf Of Paul Kyzivat
>>> Sent: Sunday, October 27, 2013 12:48 PM
>>> To: [email-masked]
>>> Subject: [dispatch] Comments on draft-ejzak-dispatch-webrtc-data-
>>> channel-sdpneg-00
>>>
>>> In general I think this document is looking pretty good. It is going in
>>> the right direction from my perspective. And I think its starting to
>>> become clear how to have this be an optional mechanism for webrtc. I'm
>>> starting to see how it could be used for CLUE, with and without webrtc.
>>>
>>> One thing bothers me: this is an ietf document, defining signaling. But
>>> it talks quite a lot about the webrtc API. It is certainly possible to
>>> use this specification in contexts where there are no browsers and no
>>> use of webrtc. ISTM it would be better to segregate all the webrtc
>>> stuff into an annex. Or maybe two documents are needed: one for SDP
>>> negotiation of sctp data channels, and one for webrtc external
>>> negotiation of data channels via the SDP mechanism.
>>>
>>> Esthetically I find the names "webrtc-DataChannel" and "wdcsa" quite
>>> unappealing. In particular, these data channels are usable (and will be
>>> used) in non-webrtc applications, so why do we need "webrtc" in the
>>> name?
>>>
>>>     Thanks,
>>>     Paul
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Feb 2014 15:05:12 -0500

Long ago I made some comments on an earlier version. At least some of 
those were adopted in this version. Now I'm reviewing it again. Here are 
new thoughts:

* General comment about document organization:

IMO there is a muddling of responsibilities among several drafts. I 
suggest that it could be improved, as follows. (This isn't a big change 
from the current situation, but rationalizes the layering.):

- draft-ietf-mmusic-sctp-sdp

SDP for declaration/negotiation of SCTP associations.
Defines a=sctpmap and establishes registry for "app" values.

Defines what the registration of an app must specify. (This is currently 
deficient.)

(Shouldn't register any - the registration of "webrtc-datachannel should 
be removed.)

- draft-ietf-rtcweb-data-channel

Should register an "app" name for data channels. (Preferably a more 
generic name than "webrtc-datachannel".)

Should define (or reference an existing) IANA registry for data channel 
protocols. (This currently isn't done anywhere I can find.)

As now, defines internal and external negotiation of data channels. 
(Should probably have what is now section 4 of this (ejzak) draft.)

As now, specifies that "webrtc-datachannel" implies support for internal 
negotiation via rtcweb-data-protocol.

- this draft (draft-ejzak-dispatch-webrtc-data-channel-sdpneg)

Make it clear that it just specifies a way to do external negotiation of 
data channels for "webrtc-datachannel" SCTP associations.

Shouldn't cover any other kinds of SCTP associations. (Except to explain 
how external negotiation of channels can replace use of multiple sctp 
associations.)

* Section 4

This section should probably be moved to draft-ietf-rtcweb-data-channel.

Section 5.1.1:

The 'maxretr', 'maxtime', and 'unordered' parameters are presumably 
intended to correspond to the Channel Type and Reliability Parameter 
elements in section 5.1 of draft-ietf-rtcweb-data-protocol. This should 
be made clear. (And are all Channel Types covered?)

The 'subprotocol' parameter is presumably intended to be the same thing 
that is called "protocol" in sections 5.1 and 8.4 of 
draft-ietf-rtcweb-data-protocol. These ought to be linked and be 
consistent about naming.

Also, then syntax is:

    subprotocol-attr       =  "subprotocol=" labelstring
    labelstring            =  text
    text                   =  byte-string

(Where labelstring and text are the same as in the syntax of the label 
parameter.) This is misleading. It should probably be:

    subprotocol-attr       =  "subprotocol=" protocol-string
    protocol-string        =  text
    text                   =  byte-string

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Feb 2014 22:03:17 -0500

> protocols. (This currently isn't done anywhere I can find.)

My mistake - is currently done by draft-ietf-rtcweb-data-protocol-03. 
But I think it would make more sense to define the registry in 
draft-ietf-rtcweb-data-channel so that it is known to also be applicable 
to externally negotiated channels.

> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>