Re: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08

"Ben Campbell" <ben@nostrum.com> Tue, 14 April 2015 22:42 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626DF1B3023 for <gen-art@ietfa.amsl.com>; Tue, 14 Apr 2015 15:42:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, T_RP_MATCHES_RCVD=-0.01] 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 7LeL5jAMVrIS for <gen-art@ietfa.amsl.com>; Tue, 14 Apr 2015 15:42:18 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 795821B3022 for <gen-art@ietf.org>; Tue, 14 Apr 2015 15:42:18 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t3EMg4TN088095 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Apr 2015 17:42:14 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: Ben Campbell <ben@nostrum.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Date: Tue, 14 Apr 2015 17:42:04 -0500
Message-ID: <14C2C001-48AE-4142-8E64-2D066EFC380A@nostrum.com>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D7939BB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1D7939BB@ESESSMB209.ericsson.se>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/gMzH63xqe2FOB4WBbRUjArM7z3Q>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "draft-ietf-payload-rtp-opus.all@tools.ietf.org" <draft-ietf-payload-rtp-opus.all@tools.ietf.org>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Apr 2015 22:42:19 -0000

On 11 Apr 2015, at 8:23, Christer Holmberg wrote:

> Minor Issues: I previously gave the following comment:
>  
> “Regarding SDP, I think it would be good to have the ABNF syntax for 
> the a=fmtp parameter (currently you only have descriptive text of the 
> different parameters). It makes the life for the parser implementers 
> much easier :)”
>  
> I guess one, by reading section 7 and the examples, can figure out how 
> to encode the a=fmtp parameter, but I think it would to explicitly 
> define the syntax.

Hi Christer,

(For the record, I just recently took over responsibility for PAYLOAD, 
so if I'm misinterpreting things, someone please tell me :-)  )

While I can see that as a "might be nice" addition, I don't think it's 
something that we have required of other payload drafts. 
draft-ietf-payload-rtp (in RFC ed queue) says the following about ABNF 
for SDP parameters:

"Not that commonly used in RTP payload formats but may be useful when 
defining Media Type parameters of some complexity."

If I'm reading correctly, the FMTP parameters in this draft fit the 
pretty common "semicolon delimited list of parameter=value pairs", so I 
don't think this rises to the level of "some complexity".

So unless you think the parameters in this draft are more complex than 
average, I don't think we need to add them at this late stage. It might 
be worth discussing whether we should ask authors of future payload 
drafts to include ABNF for this sort of thing.

Thanks!

Ben.