Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel

[Christian Groves <[e-mail]>]

Like Christer, I also think the mechanism would be useful. Actually I 
think its essential when it comes to endpoints (especially gateways) 
supporting multiple protocols in a data channel. So I hope that MMUSIC 
does accept the draft. If it does become a general mechanism I think we 
have to consider it in our CLUE work.

Christian

On 28/10/2014 6:05 AM, Mary Barnes wrote:
> When we discussed this at IETF-90, we said that we would consider it 
> if the updated document was submitted no later than September 1st (per 
> the minutes).  Of course, that date wasn't met.  My suggestion is that 
> if there is consensus to adopt this as an MMUSIC WG deliverable, we 
> could add a reference. BUT, I would still be concerned about delays in 
> that work that would result in CLUE documents sitting in the RFC 
> editor's queue waiting for that document.
>
> As an individual, considering the overall pace of the work on that 
> document thus far, I would be quite worried about adding that as a 
> dependency.
>
> Regards,
> Mary.
>
> On Mon, Oct 27, 2014 at 1:26 PM, Christer Holmberg 
> <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     FYI,
>
>     Keith has submitted a new version of the SDP-data-channel-neg draft.
>
>     Personally I think the mechanism would be useful, but I think it
>     would be good to have a "CLUE opinion" also. Currently we only
>     have an editor's note saying that we may consider the mechanism
>     depending on how it progresses. But, as we know, nothing
>     progresses by itself in IETF, so the question is whether we shall
>     say "CLUE has an interest in this mechanism, and would like it to
>     move forward".
>
>     Regards,
>
>     Christer
>
>
>     -----Original Message-----
>     From: mmusic [mailto:[e-mail]
>     <mailto:[e-mail]>] On Behalf Of DRAGE, Keith (Keith)
>     Sent: 27 October 2014 16:39
>     To: [e-mail] <mailto:[e-mail]>
>     Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and
>     draft-ejzak-mmusic-msrp-usage-data-channel
>
>     Based on the discussion on list over the last few days, I have
>     submitted revised versions of the two SDP negotiation over data
>     channel drafts as follows:
>
>     A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt
>     has been successfully submitted by Keith Drage and posted to the
>     IETF repository.
>
>     Name:           draft-ejzak-mmusic-data-channel-sdpneg
>     Revision:       02
>     Title:          SDP-based "SCTP over DTLS" data channel negotiation
>     Document date:  2014-10-27
>     Group:          Individual Submission
>     Pages:          22
>     URL:
>     http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.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-02
>     Diff:
>     http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02
>
>     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.
>
>
>     A new version of I-D,
>     draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
>     has been successfully submitted by Keith Drage and posted to the
>     IETF repository.
>
>     Name:  draft-ejzak-mmusic-msrp-usage-data-channel
>     Revision:       01
>     Title:          MSRP over SCTP/DTLS data channels
>     Document date:  2014-10-27
>     Group:          Individual Submission
>     Pages:          11
>     URL:
>     http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
>     Status:
>     https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/
>     Htmlized:
>     http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01
>     Diff:
>     http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01
>
>     Abstract:
>        This document specifies how the Message Session Relay Protocol
>     (MSRP)
>        can be instantiated as a data channel sub-protocol, using the
>     the SDP
>        offer/answer exchange-based external negotiation defined in
>        [I-D.ejzak-mmusic-data-channel-sdpneg].  Two network configurations
>        are documented: a WebRTC end-to-end configuration (connecting two
>        MSRP over data channel endpoints), and a gateway configuration
>        (connecting an MSRP over data channel endpoint with an MSRP
>     over TCP
>        endpoint).
>     _______________________________________________
>     mmusic mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>
>     _______________________________________________
>     clue mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/clue
>
>
>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue