Re: [MMUSIC] draft-ejzak-mmusic-msrp-usage-data-channel

[Paul Kyzivat <[e-mail]>]

IMO this document is important even to those who don't care about MSRP, 
because it will set a precedent for how to map existing protocols on top 
of data channels.

A few comments:

* Section 4.3:

Instead of rewriting the transport rule from 4975, why not just extend 
it? I.e.,

	transport =/ "dc"

* Section 5.1.1.1

The following seems overly stringent:

    The SDP answer shall include the exact same attribute line to
    indicate acceptance of the data channel instance.

This seems to require a byte-by-byte copy. That precludes independently 
generating an equivalent attribute. ISTM it is sufficient to require the 
attribute in the answer to meet the same requirements as that in the 
offer, and to have the same channel number. (And label???)

* Section 5.1.5

    ... Closing an MSRP
    session should trigger an SDP negotiation where the SDP attributes
    for each affected data channel are removed.

I don't know how to interpret this - what does the "should" mean? Is it 
SHOULD, MUST, MAY? What if it isn't done? Which end is responsible for 
initiating this O/A? Or does this just mean that the SDP should be 
updated to reflect the closure the next time there is need to do an O/A?

Suppose the intent is to close one MSRP session and immediately open a 
new one. Is it permissible to simply update the SDP to describe the new 
MSRP session, reusing the channel number, without first doing an O/A to 
confirm the closure of the old one?

* General

There are a couple of places that refer to an attribute "within the m 
line". That isn't quite right. A better way to say that would be "within 
the media description" or "associated with the m-line".

The inclusion of a=sctp-port in the examples throughout is an 
unnecessary distraction. It isn't necessary because it has a default. (I 
don't see *any* currently planned uses for webrtc-datachannel where 
there is need to specify the sctp port.)

	Thanks,
	Paul

On 10/23/14 7:56 AM, DRAGE, Keith (Keith) wrote:
> I have just posted an updated version of the MSRP document that gives one mapping for usage MSRP over draft-ejzak-mmusic-data-channel-sdpneg-01
>
> The group (if any) that should handle this usage document is still as I went back and reread the dispatch minutes in regard to draft-ejzak-mmusic-data-channel-sdpneg and it is unclear to me whether one or both documents were dispatched to MMUSIC. I will try and get this clarified offline.
>
> In any case, I have submitted it with an MMUSIC label as I think the MMUSIC folks are the next people who should be looking at it.
>
> Regards
>
> Keith
>
>
> A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-00.txt
> has been successfully submitted by Keith Drage and posted to the IETF repository.
>
> Name:		draft-ejzak-mmusic-msrp-usage-data-channel
> Revision:	00
> Title:		MSRP over SCTP/DTLS data channels
> Document date:	2014-10-23
> Group:		Individual Submission
> Pages:		11
> URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-00.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-00
>
>
> 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).
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
> 	
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>