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

Christer Holmberg <> Wed, 15 April 2015 09:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EADED1B33DE for <>; Wed, 15 Apr 2015 02:38:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6iOVetcRVW2n for <>; Wed, 15 Apr 2015 02:38:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A80311B33DA for <>; Wed, 15 Apr 2015 02:38:46 -0700 (PDT)
X-AuditID: c1b4fb30-f79996d000006ebb-76-552e31a4c99e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9D.07.28347.4A13E255; Wed, 15 Apr 2015 11:38:44 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Wed, 15 Apr 2015 11:38:44 +0200
From: Christer Holmberg <>
To: Ben Campbell <>
Thread-Topic: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08
Thread-Index: AdB0YZrD1UZTCkzGSwKoMQ0d3L+1AACkdxEAABiprTA=
Date: Wed, 15 Apr 2015 09:38:44 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMLMWRmVeSWpSXmKPExsUyM+Jvje4SQ71Qg5YuE4v5nafZLbZs38tk cfXVZxYHZo8lS34yecza+YTF48vlz2wBzFFcNimpOZllqUX6dglcGR/uXWAt+CBYMW/JaZYG xi2CXYwcHBICJhLb1vB1MXICmWISF+6tZ+ti5OIQEjjKKLGvvYsNJCEksIRR4sF/I5B6NgEL ie5/2iBhEQEliefNW1lA6pkFJjBKND9byQqSEBZwl5j6dQI7RJGHxJL2VcwQtpXE4fbtYDNZ BFQl2g4sYwKxeQV8Jbq2zWKF2NXEKPFogy6IzSlgL3Fs5xlGEJsR6Ljvp9aA1TMLiEvcejKf CeJoAYkle84zQ9iiEi8f/2OF+EtRYnm/HIjJLKApsX6XPkSnosSU7ofsEFsFJU7OfMIygVFs FpKhsxA6ZiHpmIWkYwEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwFg6uOW3wQ7Gl88d DzEKcDAq8fAqHNMNFWJNLCuuzD3EKM3BoiTOa2d8KERIID2xJDU7NbUgtSi+qDQntfgQIxMH p1QDI8+53JAn6vu/TDx43OXVgWyFbkvDNJtPou9mzbl2d5O95POED7mGrK5LC5IK/j28PF1z sqH2d8ek0Edn19SvXSlYPdFp8x07aZ85jLIxGx+c23C/4vu210uaXU67Jb0UXHj9kJ/81uJO bu8okamM3Hv/O+T9Oz93lab9PcPIy6FrZssV5a3KW6HEUpyRaKjFXFScCAA21zxDhgIAAA==
Archived-At: <>
Cc: "" <>, "" <>
Subject: Re: [Gen-art] Gen-ART review of draft-ietf-payload-rtp-opus-08
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Apr 2015 09:38:49 -0000


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

After all my years of taking drafts through the IETF publication process, I have learned that there is no such thing as consistency :)

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

I can live without any changes.