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

[Mary Barnes <[e-mail]>]

Okay. So, if folks really want this for CLUE, then we MUST make sure to
support the work on the MMUSIC WG mailing list.   As I said, my primary
concern is timing. If the current author doesn't have the cycles (or needs
help), would anyone here be willing to step in as a co-author (if the doc
is agreed as a WG document) to ensure the work actually gets done?

Thanks,
Mary

On Mon, Oct 27, 2014 at 7:32 PM, Christian Groves <
[e-mail]> wrote:

> 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
>>
>
> _______________________________________________
> clue mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/clue
>