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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 09 October 2015 18:43 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B0A1B49F7 for <mmusic@ietfa.amsl.com>; Fri, 9 Oct 2015 11:43:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1
X-Spam-Level:
X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_14=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXHo26C437zg for <mmusic@ietfa.amsl.com>; Fri, 9 Oct 2015 11:42:47 -0700 (PDT)
Received: from bin-vsp-out-01.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E242E1B49FA for <mmusic@ietf.org>; Fri, 9 Oct 2015 11:42:46 -0700 (PDT)
X-Halon-ID: 882016c3-6eb5-11e5-8a4e-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-01.atm.binero.net (Halon Mail Gateway) with ESMTPSA for <mmusic@ietf.org>; Fri, 9 Oct 2015 20:42:45 +0200 (CEST)
To: mmusic@ietf.org
References: <56177062.9030705@omnitor.se> <5617DBCC.4080003@alcatel-lucent.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <56180A9F.5090404@omnitor.se>
Date: Fri, 9 Oct 2015 20:42:39 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <5617DBCC.4080003@alcatel-lucent.com>
Content-Type: multipart/alternative; boundary="------------020206080202090002090105"
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/RIKyujPC9pz2ldQWIvqcqQa9T9s>
Subject: Re: [MMUSIC] Comments on mmusic-data-channel-sdpneg-05
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 18:43:11 -0000

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
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic