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

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

Richard,

What is the status of this work?
Are you planning on a new version?

Also, these naming issues extend to draft-ietf-rtcweb-data-channel-06.
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: Tue, 04 Feb 2014 11:31:43 -0500

(I changed the draft reference below)

Richard,

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

---

From: Mary Barnes <[email-masked]>
Date: Tue, 4 Feb 2014 10:51:46 -0600

This discussion should be on the MMUSIC WG mailing list.  We dispatched
this document at IETF-88:  http://trac.tools.ietf.org/wg/dispatch/trac/wiki

Thanks,
Mary.