Subject: RFC 4695 -- severe ABNF issues

From: Alfred Hönes <[email-masked]>
Date: Tue, 12 Dec 2006 14:14:41 +0100 (MEZ)

Hello,
Last weekend, I quickly browsed through the recently published
RFC 4695 (RTP MIDI) authored by you and John Wawrzynek.
Because you are named as the "(corresponding author)", this note
is only CC'ed to John.

While most of that huge document seems to be very carefully
crafted, I found a few (perhaps distorting) word omissions.
And even worse, unfortunately the (normative) SDP ABNF specified
in Appendix D of RFC 4695 contains a bunch of rules contradicting
the textual descriptions in the body of that memo (and even the
comments included in the ABNF!), and it violates fundamental
rules of the ABNF specification, RFC 4324.

Altogether, the literal SDP ABNF from RFC 4695 apparently does
*not* formalize the SDP attribute grammar described in the text,
and most probably intended as such.  Although, at first glance,
most of the RFC 4695 ABNF pretends to correctly reflect the
latter, intended grammar, plain application of the specific
rules from RFC 4324 shows that it doesn't.

The most fundamental issue is the improper use of the RFC 4324
coding conventions (-- admittedly uncommon and perhaps unexpected
for the non-specialist --) for ABNF terminals (code points),
which makes many RFC 4695 ABNF terminals represent something
quite different than what most probably was intended:
Numerical (in particular, *decimal*) ABNF literals represent code
points (for octets, in this case), and are therefore restricted to
the appropriate value range (i.e. 0..255 for octets); they cannot
be used to represent sequences of (ASCII) characters (digits)
having the intuitive semantical interpretation of a base-c (e.g.,
decimal) representation of (potentially large) numbers; and ABNF
quoted string literals are *not* 'C'-like string literals, they are
explicitely case *in*sensitive ASCII; in ABNF, case sensitive text
literals MUST be represented individually (character by character),
in numerical form!

Due to lack of time, I do not present the details at this time,
but I hope to find the time to study and cross check all that
stuff, and send you detailed comments, including a proposal for
a revised version of Appendix D, until early January 2007.

Best regards,
  Alfred Hönes.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: lazzaro <[email-masked]>
Date: Tue, 12 Dec 2006 11:43:37 -0800

Hi Alfred,

	Thank you for taking the time to read over the
document and find these errors.  Is it OK with you
if I post your email on the Audio-Video Transport
working group?  Since RFC 4695 is a product of that
group, the decision on what to do next (generate
an errata or create a replacement RFC) begins with them,
since the most limited resource in the process is AVT
co-chair attention (AVT runs a lot of documents, and
even with 3 co-chairs there is never enough time in
their schedules).

	Thanks, and I look forward to your more complete
analysis in 2007.

> rules of the ABNF specification, RFC 4324.

---
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
lazzaro [at] cs [dot] berkeley [dot] edu
---