RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 3 records.

Status: Verified (2)

RFC 4695, "RTP Payload Format for MIDI", November 2006

Note: This RFC has been obsoleted by RFC 6295

Source of RFC: avt (rai)

Errata ID: 17
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: John Lazzaro
Date Reported: 2007-01-18

 

In this errata, we briefly summarize several errata to RFC 4695,
reported by Alfred Hoenes. The listed errata either fix normative
problem in RFC 4695, or describe editorial errata that may be
particularly confusing to the implementor.

The presentation below is brief. See the main text of
<draft-ietf-avt-rfc4695-bis-00.txt> for a bis version of RFC 4695 that
integrates the fixes listed below in a more-complete way, and also
includes many other editorial fixes.

John Lazzaro, lazzaro@eecs.berkeley.edu

---

[1] In Appendix C.1 and Appendix C.2.3 of RFC 4695, an ABNF rule
related to System Chapter X is incorrectly defined as:

       <parameter> = "__" <h-list> ["_" <h-list>] "__"

The correct version of this rule is:

       <parameter> = "__" <h-list> *( "_" <h-list> ) "__"

[2] In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned
to the "url" parameter are not stated clearly.  URIs assigned to "url"
MUST specify either HTTP or HTTP over TLS transport protocols.

In Appendix C.7.1 and C.7.2 of RFC 4695, the transport
interoperability requirements for the "url" parameter are not stated
clearly.  For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS
is OPTIONAL.

[3] Both fmtp lines in both session description examples in Appendix
C.7.2 of RFC 4695 contain instances of the same syntax error (a
missing ";" at a line wrap after "cm_used=2M0.1.2").

[4] In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules
are in error, and should be replaced with "ietf-extension".  Likewise,
all uses of "*extension" are in error, and should be replaced with
"extension".  This bug incorrectly lets the null token be assigned to
the j_sec, j_update, render, smf_info, and subrender parameters.

[5] In Appendix D of RFC 4695, the definitions of the <command-type>
and <chapter-rules> incorrectly allow lowercase letters to appear in
these strings. The correct definitions of these rules appear below:
    command-type =   [A] [B] [C] [F] [G] [H] [J] [K] [M]
                    [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]

   chapter-list =   [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
                    [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]

   A        = %x41
   B        = %x42
   C        = %x43
   D        = %x44
   E        = %x45
   F        = %x46
   G        = %x47
   H        = %x48
   J        = %x4A
   K        = %x4B
   M        = %x4D
   N        = %x4E
   P        = %x51
   Q        = %x52
   T        = %x54
   V        = %x56
   W        = %x57
   X        = %x58
   Y        = %x59
   Z        = %x5A

[6] In Appendix D of RFC 4695, the definitions of the <four-octet>,
<nonzero-four-octet>, and <midi-chan> are incorrect.  The correct
definitions of these rules appear below:
    nonzero-four-octet =  (NZ-DIGIT 0*8(DIGIT))
                       / (%x30-33 9(DIGIT))
                       / ("4" %x30-31 8(DIGIT))
                       / ("42" %x30-38 7(DIGIT))
                       / ("429" %x30-33 6(DIGIT))
                       / ("4294" %x30-38 5(DIGIT))
                       / ("42949" %x30-35 4(DIGIT))
                       / ("429496" %x30-36 3(DIGIT))
                       / ("4294967" %x30-31 2(DIGIT))
                       / ("42949672" %x30-38 (DIGIT))
                       / ("429496729" %x30-34)

   four-octet        = "0" / nonzero-four-octet
   midi-chan         = DIGIT / ("1" %x30-35)
   DIGIT             = %x30-39
   NZ-DIGIT          = %x31-39

[7] In Appendix D of RFC4695, the rule <hex-octet> is
incorrect.  The correct definition of this rule appears below.
    hex-octet   = %x30-37 U-HEXDIG
   U-HEXDIG    = DIGIT / A / B / C / D / E / F

   ; DIGIT as defined in [5] above
   ; A, B, C, D, E, F as defined in [4] above

[8] In Appendix D of RFC4695, the rules <base64-unit> and
<base64-pad> are defined unclearly.  The rewritten rules
appear below:
    base64-unit = 4(base64-char)
   base64-pad  = (2(base64-char) "==") / (3(base64-char) "=")


Errata ID: 2673
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: John Lazzaro
Date Reported: 2010-12-18
Verifier Name: Robert Sparks
Date Verified: 2011-02-07

Section 3 says:

   If the LEN header field is nonzero, the MIDI list has the structure
   shown in Figure 3.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 0     (1-4 octets long, or 0 octets if Z = 1)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 0   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 1     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 1   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time N     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command N   (0 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3 -- MIDI list structure

It should say:

   If the LEN header field is nonzero, the MIDI list has the structure
   shown in Figure 3.

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 0     (1-4 octets long, or 0 octets if Z = 0)     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 0   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time 1     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command 1   (1 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                              ...                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  Delta Time N     (1-4 octets long)                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  MIDI Command N   (0 or more octets long)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 3 -- MIDI list structure

Notes:

The sole change here is in the parenthesized text that follows
the "Delta Time 0" name in the first bitfield shown in Figure 3.
RFC 4695 has "1-4 octets long, or 0 octets if Z = 1". This
does not match the definition of Z in the main text. The corrected
figure text is: "1-4 octets long, or 0 octets if Z = 0". Thankfully, all
known implementations follow the main text in this
regard, so this bug should not have resulted in interoperability
issues. This bug has been fixed in the bis I-D intended to
obsolete RFC 4695 that is currently in Last Call in AVT.

Status: Held for Document Update (1)

RFC 4695, "RTP Payload Format for MIDI", November 2006

Note: This RFC has been obsoleted by RFC 6295

Source of RFC: avt (rai)

Errata ID: 861
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT

Reported By: Alfred Hoenes
Date Reported: 2007-02-28
Held for Document Update by: Robert Sparks

Appendix A

[[From the lines in the modified ABNF]]

   P        = %x51
   Q        = %x52

It should say:

   P        = %x50
   Q        = %x51

Notes:

ASCII, `man ascii` on any UNIX system, RFC 20, et al.
(There must have been some EBCDIC spirit pouring into the ASCII world.)

from pending

Report New Errata



Advanced Search