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

From: Gunnar Hellström <[email-masked]>
Date: Fri, 9 Oct 2015 09:44:34 +0200

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.

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.
------------------------------------------------------------------

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.

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.

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."

/Gunnar

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 9 Oct 2015 17:22:52 +0200

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:
> There are left-overs from when it was MSRP-specific that is confusing for a reader now.
> Suggestions:
>

[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."

> 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:

[Juergen] Agree.

> 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).

> 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:

[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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 9 Oct 2015 20:42:39 +0200

Juergen,
Accepted as commented below,
Den 2015-10-09 kl. 17:22, skrev Juergen Stoetzer-Bradler:
> [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."
>
Yes, or like this to avoid the paranthesis:
"Thus in the example above from MSRP, 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 MSRP subprotocol being transported on the SCTP association using 
the data channel with stream id 2 accepts plain text files."

>> 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
>> 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.
> value would actually be sufficient. This specific case should probably 
> be described in draft-schwarz-mmusic-t140-usage-data-channel.
>
> 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).
>
Yes, I reread RFC 4566 and realized that the "-" is a syntactically 
correct <fmt>.
So, I accept that draft-schwarz-mmusic-t140-usage-data-channel should 
specify the specific mapping cases to RFC 4102 and RFC 4103.

>> 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:
> [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
Yes, looks good.

Thanks,

Gunnar