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

[Gunnar Hellström <[e-mail]>]

Juergen,
Accepted as commented below,
Den 2015-10-09 kl. 17:22, skrev Juergen Stoetzer-Bradler:
> 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."
>
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."


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


>
>>
>> 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)?
>
Yes, looks good.

Thanks,

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