Re: [MMUSIC] Comments on mmusic-data-channel-sdpneg-05

[Juergen Stoetzer-Bradler <[e-mail]>]

Hello Gunnar,

Thanks much for your comments.
I've inserted my replies below.

Thank you,
Juergen

On 09.10.2015 09:44, Gunnar Hellström wrote:
> mmusic-data-channel looks good.
>
> I have some minor comments:
> There are left-overs from when it was MSRP-specific that is confusing for a reader now.
> Suggestions:
>
> 1. In 5.1.2.1, change this:
> ------------------------------------------------------------------------
>
> which specifies that this instance of MSRP
> ---------------------------------------------------
>
> to
> -----------------------------------------------------------------------
>
> which specifies that this instance of the subprotocol
> --------------------------------------------------
> Because before that point there has not been any discussion of MSRP.

[Juergen] Agree. Would you be ok with adding MSRP in parentheses as the "accept-types" parameter is 
MSRP specific? Like
"Thus in the example above, the original attribute line "a=accept- types:text/plain" is represented 
by the attribute line "a=dcsa:2 accept-types:text/plain", which specifies that this instance of the 
subprotocol (here MSRP) being transported on the SCTP association using the data channel with stream 
id 2 accepts plain text files."

>
>
> 2. Move the note about MSRP from 5.1.2.1 to the introduction.
> In 5.1.2.1 there is this note:
> ----------------------------------------------------------
>
>    Note: This document does not provide a complete specification of how
>    to negotiate the use of a data channel to transport MSRP. Procedures
>    specific to each sub-protocol such as MSRP will be documented
>    elsewhere.  The use of MSRP is only an example of how the generic
>    procedures described herein might apply to a specific sub-protocol.
> ------------------------------------------
> It comes late in the document. I suggest to move it to become a paragraph last in the introduction 
> and change it to a regular paragraph saying:
> ----------------------------------------------------------------
>    This document makes use of MSRP in many of the examples. It does not provide a complete 
> specification of how
>    to negotiate the use of a data channel to transport MSRP. Procedures
>    specific to each sub-protocol such as MSRP will be documented
>    elsewhere.  The use of MSRP in some examples is only to show how the generic
>    procedures described herein might apply to a specific sub-protocol.
> ------------------------------------------------------------------

[Juergen] Agree.

>
> 3. What syntax to use for irrelevant positional parameters in mapped RFC 4566 attributes
> We had a discussion about t140-usage-data-channel recently, where the mapping of the a=fmtp: of 
> RFC 4103 and RFC 4102 was discussed.
> The attribute was proposed to be coded as an example:
>     a=dcsa:1 fmtp:- cps=30
>
> that is supposed to follow the syntax rule from sdpneg 5.1.2.1:
>     dcsa-value      = stream-id SP attribute
>     attribute       = <from-RFC4566>
>
> In sdp, this would be represented by something like
> a=fmtp: 102 104/104/104 cps=30
> if the payload type 102 represented red payload
>
> it could also be represented by
> a=fmtp: 99 cps=30
> if the payload type 99 represented t140 payload
>
> Question:
> Is the single "-" sufficient to describe that some parameters are ignored?
>
> Proposal:
> Since a=fmtp is a very common RFC 4566 attribute, describe a syntax for its use explicitly in sdpneg.

[Juergen] In the T.140 over data channel case I assume that "-" as the a=fmtp attribute's "fmt"
value would actually be sufficient. This specific case should probably be described in 
draft-schwarz-mmusic-t140-usage-data-channel.

a=fmtp is indeed a common attribute, which is often used on RTP based SDP media descriptions.
However, I am not sure how many of such RTP based media formats could eventually be also transported 
over a data channel, in addition to T.140.
Would we actually be able to formulate a generic rule covering all potential dcsa encapsulated fmtp 
usage cases?
I would assume that such media format specific RTP to data channel interworking case would be 
described in dedicated documents,
which then would also describe the media format specific encapsulation of the fmtp attribute (if 
this is then still used in case of
data channel transport).


>
> 4. Many subprotocol-unspecific attributes also fit the pattern in 5.1.2
> Section 5.1.2 has the name "subprotocol specific attributes".
> There are many general attributes defined in RFC4566 and elsewhere that apply to many subprotocols.
> It may be subprotocol specific if they are applicable to each subprotocol, but they are not 
> specified in a subprotocol-specific RFC.
> An example is "lang" from RFC 4566 that is right now discussed in the slim group ( as well as its 
> proposed addition "humintlang" ).
>
> Can section 5.1.2 be called "Other media level attributes" in order to surely include these quite 
> generally applicable attributes. Some further adjustments in the text would also be needed.

[Juergen] Agree.

>
> Maybe the last words in 5.1.2.1 before the note is intended to say this, and could be moved up 
> closer to the beginning of 5.1.2 or 5.1.2.1 and adapted to its new place:
> "The same syntax applies to any other SDP attribute required for
>    negotiation of this instance of the sub-protocol."

[Juergen] Yes, agree to moving this sentence up in 5.1.2.1. The first paragraph of 5.1.2.1 
introduces the actual dcsa attribute and outlines its syntax
(before the syntax is then formally defined after that). Would you be ok with moving this sentence 
right after this first paragraph of 5.1.2.1
(before the formal syntax definition)?

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