Re: [rtcweb] data channel protocol comments and potential agenda topic

[Harald Alvestrand <[e-mail]>]

On 07/20/2012 09:10 AM, Ejzak, Richard P (Richard) wrote:
>
> I don't see any conflict between our positions, Harald.  You are 
> arguing that we need a generic data transfer capability that can be 
> used by any application for any purpose, which can be achieved by 
> specifying raw data transfer, and I fully support this.  I am arguing 
> that it would be advantageous to be able to have the option to specify 
> an underlying protocol on a data channel so that we can develop 
> interoperable applications.  These capabilities are not mutually 
> exclusive.
>
> An example might be MSRP.  If we would like to use MSRP between 
> endpoints then we could specify that browsers need to support MSRP 
> natively and specify a new API to access it.  Or we could allow an 
> application to send MSRP over a data channel without impacting the 
> browser.  This would potentially allow browsers running different 
> communications applications to use MSRP in addition to audio and video 
> media for communication, even if other application specific uses of 
> data channel are not interoperable.
>
Noted - we may not be in disagreement, only arguing terminology.

In my terminology, MSRP is not a purpose, it's a protocol.
It's clear to me that if applications need to standardize a way to use 
MSRP over the data channel, they need to be able to signal that this is 
what they're going to do, and have reasonable assurcance that nothing 
else is going to interfere with that purpose. There are many ways to 
achieve this purpose through signalling ("I want to do MSRP over the 
data channel named "msrp""; "OK with using "msrp"") is a typical 
signalling sequence that would accomplish the purpose), API extensions 
that can access the setup protocol in ways that the current API cannot, 
or other ways.

The discussion of that belongs, I think, in the discussion of 
standardizing MSRP over data channel, not in the discussion of the data 
channel itself.

> I'm not arguing that we should standardize MSRP over data channel -- 
> just that this approach gives us the potential to define interoperable 
> data channel applications in the future.
>
> It would also be a good idea to reserve a range of ppid values for 
> proprietary use.  Then when two browsers are communicating with the 
> same application, the application can signal the purpose behind a new 
> block of data with the choice of proprietary ppid value.  An 
> application might use one value to signal gaming control information 
> and another value to signal display information.  This approach would 
> save a typical application from exchanging signaling just to set up 
> channels so that it can begin to use them.
>
My personal opinion is that this is not a good use of PPID.

But if I understand correctly, PPID values are IANA registered. Feel 
free to make the proposal.

http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xml#sctp-parameters-25




>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb