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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Fri, 09 October 2015 07:44 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 0A4E71A6FE9 for <mmusic@ietfa.amsl.com>; Fri, 9 Oct 2015 00:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.001
X-Spam-Level:
X-Spam-Status: No, score=-1.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 CSHCfZhl_EvL for <mmusic@ietfa.amsl.com>; Fri, 9 Oct 2015 00:44:44 -0700 (PDT)
Received: from bin-vsp-out-05.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 6E3871A6FE8 for <mmusic@ietf.org>; Fri, 9 Oct 2015 00:44:43 -0700 (PDT)
X-Halon-ID: 97a6fa3f-6e59-11e5-b53c-005056916f53
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.48] (unknown [77.53.228.139]) by bin-vsp-out-05.atm.binero.net (Halon Mail Gateway) with ESMTPSA for <mmusic@ietf.org>; Fri, 9 Oct 2015 09:44:37 +0200 (CEST)
To: "mmusic (E-mail)" <mmusic@ietf.org>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <56177062.9030705@omnitor.se>
Date: Fri, 9 Oct 2015 09:44:34 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/LOfoFvAZI09tNNP5qi4qs-ZCNXo>
Subject: [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 07:44:46 -0000

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