draft-ietf-avt-rfc4695-bis-08.txt   draft-ietf-avt-rfc4695-bis-09.txt 
INTERNET-DRAFT J. Lazzaro AVT J. Lazzaro
July 26, 2010 J. Wawrzynek Internet-Draft J. Wawrzynek
Expires: January 26, 2011 UC Berkeley Obsoletes: 4695 (if approved) UC Berkeley
Intended Status: Proposed Standard Intended status: Standards Track December 17, 2010
Expires: June 17, 2011
RTP Payload Format for MIDI RTP Payload Format for MIDI
<draft-ietf-avt-rfc4695-bis-08.txt> <draft-ietf-avt-rfc4695-bis-09.txt>
Abstract
This memo describes a Real-time Transport Protocol (RTP) payload
format for the MIDI (Musical Instrument Digital Interface) command
language. The format encodes all commands that may legally appear on
a MIDI 1.0 DIN cable. The format is suitable for interactive
applications (such as network musical performance) and content-
delivery applications (such as file streaming). The format may be
used over unicast and multicast UDP and TCP, and it defines tools for
graceful recovery from packet loss. Stream behavior, including the
MIDI rendering method, may be customized during session setup. The
format also serves as a mode for the mpeg4-generic format, to support
the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds
Level 2, and Structured Audio.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on June 17, 2011.
This Internet-Draft will expire on January 26, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents (http://trustee.ietf.org/license-info) Relating to IETF Documents (http://trustee.ietf.org/license-info)
in effect on the date of publication of this document. Please in effect on the date of publication of this document. Please
review these documents carefully, as they describe your rights and review these documents carefully, as they describe your rights and
restrictions with respect to this document. Code Components restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License extracted from this document must include Simplified BSD License
text as described in Section 4.e of the Trust Legal Provisions and text as described in Section 4.e of the Trust Legal Provisions and
are provided without warranty as described in the Simplified BSD are provided without warranty as described in the Simplified BSD
License. License.
Abstract
This memo describes a Real-time Transport Protocol (RTP) payload
format for the MIDI (Musical Instrument Digital Interface) command
language. The format encodes all commands that may legally appear on
a MIDI 1.0 DIN cable. The format is suitable for interactive
applications (such as network musical performance) and content-
delivery applications (such as file streaming). The format may be
used over unicast and multicast UDP and TCP, and it defines tools for
graceful recovery from packet loss. Stream behavior, including the
MIDI rendering method, may be customized during session setup. The
format also serves as a mode for the mpeg4-generic format, to support
the MPEG 4 Audio Object Types for General MIDI, Downloadable Sounds
Level 2, and Structured Audio.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
1.2. Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6 1.2. Bitfield Conventions . . . . . . . . . . . . . . . . . . . 6
2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Packet Format . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2. MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. MIDI Payload . . . . . . . . . . . . . . . . . . . . . . . 12
3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 14 3. MIDI Command Section . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1. Timestamps . . . . . . . . . . . . . . . . . . . . . . . . 15
skipping to change at page 2, line 42 skipping to change at page 2, line 43
5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 26 5. Recovery Journal Format . . . . . . . . . . . . . . . . . . . . . 26
6. Session Description Protocol . . . . . . . . . . . . . . . . . . 30 6. Session Description Protocol . . . . . . . . . . . . . . . . . . 30
6.1. Session Descriptions for Native Streams . . . . . . . . . 31 6.1. Session Descriptions for Native Streams . . . . . . . . . 31
6.2. Session Descriptions for mpeg4-generic Streams . . . . . . 33 6.2. Session Descriptions for mpeg4-generic Streams . . . . . . 33
6.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 35 6.3. Parameters . . . . . . . . . . . . . . . . . . . . . . . . 35
7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 37 7. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . . . 37
8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 38 8. Congestion Control . . . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 39 9. Security Considerations . . . . . . . . . . . . . . . . . . . . . 39
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 40 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 40
11.1. rtp-midi Media Type Registration . . . . . . . . . . . . 41 A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 41
11.1.1. Repository Request for "audio/rtp-midi" . . . . . 43 A.1. Recovery Journal Definitions . . . . . . . . . . . . . . . 41
11.2. mpeg4-generic Media Type Registration . . . . . . . . . . 45 A.2. Chapter P: MIDI Program Change . . . . . . . . . . . . . . 46
11.2.1. Repository Request for Mode rtp-midi for A.3. Chapter C: MIDI Control Change . . . . . . . . . . . . . . 47
mpeg4-generic . . . . . . . . . . . . . . . . . . 48 A.3.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 47
11.3. asc Media Type Registration . . . . . . . . . . . . . . . 49 A.3.2. Controller Log Format . . . . . . . . . . . . . . . 49
A. The Recovery Journal Channel Chapters . . . . . . . . . . . . . . 52 A.3.3. Log List Coding Rules . . . . . . . . . . . . . . . 51
A.1. Recovery Journal Definitions . . . . . . . . . . . . . . . 52 A.3.4. The Parameter System . . . . . . . . . . . . . . . 54
A.2. Chapter P: MIDI Program Change . . . . . . . . . . . . . . 57
A.3. Chapter C: MIDI Control Change . . . . . . . . . . . . . . 58 A.4. Chapter M: MIDI Parameter System . . . . . . . . . . . . . 56
A.3.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 58 A.4.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 57
A.3.2. Controller Log Format . . . . . . . . . . . . . . . 60 A.4.2. Log Coding Rules . . . . . . . . . . . . . . . . . 59
A.3.3. Log List Coding Rules . . . . . . . . . . . . . . . 62 A.4.2.1. The Value Tool . . . . . . . . . . . . . . . 60
A.3.4. The Parameter System . . . . . . . . . . . . . . . 65 A.4.2.2. The Count Tool . . . . . . . . . . . . . . . 64
A.4. Chapter M: MIDI Parameter System . . . . . . . . . . . . . 67 A.5. Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . 65
A.4.1. Log Inclusion Rules . . . . . . . . . . . . . . . . 68 A.6. Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 66
A.4.2. Log Coding Rules . . . . . . . . . . . . . . . . . 70 A.6.1. Header Structure . . . . . . . . . . . . . . . . . 67
A.4.2.1. The Value Tool . . . . . . . . . . . . . . . 71 A.6.2. Note Structures . . . . . . . . . . . . . . . . . . 68
A.4.2.2. The Count Tool . . . . . . . . . . . . . . . 75 A.7. Chapter E: MIDI Note Command Extras . . . . . . . . . . . 70
A.5. Chapter W: MIDI Pitch Wheel . . . . . . . . . . . . . . . 76 A.7.1. Note Log Format . . . . . . . . . . . . . . . . . . 71
A.6. Chapter N: MIDI NoteOff and NoteOn . . . . . . . . . . . . 77 A.7.2. Log Inclusion Rules . . . . . . . . . . . . . . . . 71
A.6.1. Header Structure . . . . . . . . . . . . . . . . . 78 A.8. Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 72
A.6.2. Note Structures . . . . . . . . . . . . . . . . . . 79 A.9. Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . 73
A.7. Chapter E: MIDI Note Command Extras . . . . . . . . . . . 81 B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 75
A.7.1. Note Log Format . . . . . . . . . . . . . . . . . . 82 B.1. System Chapter D: Simple System Commands . . . . . . . . . 75
A.7.2. Log Inclusion Rules . . . . . . . . . . . . . . . . 82 B.1.1. Undefined System Commands . . . . . . . . . . 76
A.8. Chapter T: MIDI Channel Aftertouch . . . . . . . . . . . . 83 B.2. System Chapter V: Active Sense Command . . . . . . . . . . 79
A.9. Chapter A: MIDI Poly Aftertouch . . . . . . . . . . . . . 84 B.3. System Chapter Q: Sequencer State Commands . . . . . . . . 80
B. The Recovery Journal System Chapters . . . . . . . . . . . . . . 86 B.3.1. Non-compliant Sequencers . . . . . . . . . . . 82
B.1. System Chapter D: Simple System Commands . . . . . . . . . 86 B.4. System Chapter F: MIDI Time Code Tape Position . . . . . . 83
B.1.1. Undefined System Commands . . . . . . . . . . 87 B.4.1. Partial Frames . . . . . . . . . . . . . . . . . . 85
B.2. System Chapter V: Active Sense Command . . . . . . . . . . 90 B.5. System Chapter X: System Exclusive . . . . . . . . . . . . 87
B.3. System Chapter Q: Sequencer State Commands . . . . . . . . 91 B.5.1. Chapter Format . . . . . . . . . . . . . . . . 87
B.3.1. Non-compliant Sequencers . . . . . . . . . . . 93 B.5.2. Log Inclusion Semantics . . . . . . . . . . . 90
B.4. System Chapter F: MIDI Time Code Tape Position . . . . . . 94 B.5.3. TCOUNT and COUNT Fields . . . . . . . . . . . 92
B.4.1. Partial Frames . . . . . . . . . . . . . . . . . . 96 C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 94
B.5. System Chapter X: System Exclusive . . . . . . . . . . . . 98 C.1. Configuration Tools: Stream Subsetting . . . . . . . . . . 95
B.5.1. Chapter Format . . . . . . . . . . . . . . . . 98 C.2. Configuration Tools: The Journalling System . . . . . . . 99
B.5.2. Log Inclusion Semantics . . . . . . . . . . . 101 C.2.1. The j_sec Parameter . . . . . . . . . . . . . . . . 100
B.5.3. TCOUNT and COUNT Fields . . . . . . . . . . . 103 C.2.2. The j_update Parameter . . . . . . . . . . . . . . 101
C. Session Configuration Tools . . . . . . . . . . . . . . . . . . . 105 C.2.2.1. The anchor Sending Policy . . . . . . . . . 102
C.1. Configuration Tools: Stream Subsetting . . . . . . . . . . 106 C.2.2.2. The closed-loop Sending Policy . . . . . . . 102
C.2. Configuration Tools: The Journalling System . . . . . . . 110 C.2.2.3. The open-loop Sending Policy . . . . . . . . 106
C.2.1. The j_sec Parameter . . . . . . . . . . . . . . . . 111 C.2.3. Recovery Journal Chapter Inclusion Parameters . . . 108
C.2.2. The j_update Parameter . . . . . . . . . . . . . . 112 C.3. Configuration Tools: Timestamp Semantics . . . . . . . . . 113
C.2.2.1. The anchor Sending Policy . . . . . . . . . 113 C.3.1. The comex Algorithm . . . . . . . . . . . . . . . . 113
C.2.2.2. The closed-loop Sending Policy . . . . . . . 113 C.3.2. The async Algorithm . . . . . . . . . . . . . . . . 114
C.2.2.3. The open-loop Sending Policy . . . . . . . . 117 C.3.3. The buffer Algorithm . . . . . . . . . . . . . . . 115
C.2.3. Recovery Journal Chapter Inclusion Parameters . . . 119 C.4. Configuration Tools: Packet Timing Tools . . . . . . . . . 117
C.3. Configuration Tools: Timestamp Semantics . . . . . . . . . 124 C.4.1. Packet Duration Tools . . . . . . . . . . . . . . . 117
C.3.1. The comex Algorithm . . . . . . . . . . . . . . . . 124 C.4.2. The guardtime Parameter . . . . . . . . . . . . . . 118
C.3.2. The async Algorithm . . . . . . . . . . . . . . . . 125 C.5. Configuration Tools: Stream Description . . . . . . . . . 120
C.3.3. The buffer Algorithm . . . . . . . . . . . . . . . 126 C.6. Configuration Tools: MIDI Rendering . . . . . . . . . . . 126
C.4. Configuration Tools: Packet Timing Tools . . . . . . . . . 128 C.6.1. The multimode Parameter . . . . . . . . . . . . . . 127
C.4.1. Packet Duration Tools . . . . . . . . . . . . . . . 128 C.6.2. Renderer Specification . . . . . . . . . . . . . . 127
C.4.2. The guardtime Parameter . . . . . . . . . . . . . . 129 C.6.3. Renderer Initialization . . . . . . . . . . . . . . 130
C.5. Configuration Tools: Stream Description . . . . . . . . . 131 C.6.4. MIDI Channel Mapping . . . . . . . . . . . . . . . 132
C.6. Configuration Tools: MIDI Rendering . . . . . . . . . . . 137 C.6.4.1. The smf_info Parameter . . . . . . . . . . . 132
C.6.1. The multimode Parameter . . . . . . . . . . . . . . 138
C.6.2. Renderer Specification . . . . . . . . . . . . . . 138
C.6.3. Renderer Initialization . . . . . . . . . . . . . . 141
C.6.4. MIDI Channel Mapping . . . . . . . . . . . . . . . 143
C.6.4.1. The smf_info Parameter . . . . . . . . . . . 143
C.6.4.2. The smf_inline, smf_url, and smf_cid C.6.4.2. The smf_inline, smf_url, and smf_cid
Parameters . . . . . . . . . . . . . . . . . 145 Parameters . . . . . . . . . . . . . . . . . 134
C.6.4.3. The chanmask Parameter . . . . . . . . . . . 146 C.6.4.3. The chanmask Parameter . . . . . . . . . . . 135
C.6.5. The audio/asc Media Type . . . . . . . . . . . . . 147 C.6.5. The audio/asc Media Type . . . . . . . . . . . . . 136
C.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 149 C.7. Interoperability . . . . . . . . . . . . . . . . . . . . . 138
C.7.1. MIDI Content Streaming Applications . . . . . . . 149 C.7.1. MIDI Content Streaming Applications . . . . . . . . 138
C.7.2. MIDI Network Musical Performance Applications . . . 152 C.7.2. MIDI Network Musical Performance Applications . . . 141
D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 161 D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 150
E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 168 E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 157
E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 170 E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 159
E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 170 E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 159
E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 171 E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 160
E.4. AudioSpecificConfig Templates for MMA Renderers . . . . . 171 E.4. AudioSpecificConfig Templates for MMA Renderers . . . . . 160
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 F. Changes from RFC 4695 . . . . . . . . . . . . . . . . . . . . . . 165
Normative References . . . . . . . . . . . . . . . . . . . . . 176 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Informative References . . . . . . . . . . . . . . . . . . . . 177 Normative References . . . . . . . . . . . . . . . . . . . . . 168
Change Log for <draft-ietf-avt-rfc4695-bis-08.txt> . . . . . . . . . 180 Informative References . . . . . . . . . . . . . . . . . . . . 169
1. Introduction 1. Introduction
The Internet Engineering Task Force (IETF) has developed a set of The Internet Engineering Task Force (IETF) has developed a set of
focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261] focused tools for multimedia networking ([RFC3550] [RFC4566] [RFC3261]
[RFC2326]). These tools can be combined in different ways to support a [RFC2326]). These tools can be combined in different ways to support a
variety of real-time applications over Internet Protocol (IP) networks. variety of real-time applications over Internet Protocol (IP) networks.
For example, a telephony application might use the Session Initiation For example, a telephony application might use the Session Initiation
Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would Protocol (SIP, [RFC3261]) to set up a phone call. Call setup would
include negotiations to agree on a common audio codec [RFC3264]. include negotiations to agree on a common audio codec [RFC3264].
skipping to change at page 15, line 6 skipping to change at page 15, line 6
If the J header bit is set to 1, a journal section MUST appear after the If the J header bit is set to 1, a journal section MUST appear after the
MIDI command section in the payload. If the J header bit is set to 0, MIDI command section in the payload. If the J header bit is set to 0,
the payload MUST NOT contain a journal section. the payload MUST NOT contain a journal section.
We define the semantics of the P header bit in Section 3.2. We define the semantics of the P header bit in Section 3.2.
If the LEN header field is nonzero, the MIDI list has the structure If the LEN header field is nonzero, the MIDI list has the structure
shown in Figure 3. shown in Figure 3.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 0 (1-4 octets long, or 0 octets if Z = 1) | | Delta Time 0 (1-4 octets long, or 0 octets if Z = 0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 0 (1 or more octets long) | | MIDI Command 0 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time 1 (1-4 octets long) | | Delta Time 1 (1-4 octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MIDI Command 1 (1 or more octets long) | | MIDI Command 1 (1 or more octets long) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time N (1-4 octets long) | | Delta Time N (1-4 octets long) |
skipping to change at page 40, line 10 skipping to change at page 40, line 10
under certain circumstances. Normally, these values are randomly chosen under certain circumstances. Normally, these values are randomly chosen
for each stream in a session, to make plaintext guessing harder to do if for each stream in a session, to make plaintext guessing harder to do if
the payloads are encrypted. Thus, Section 2.1 weakens this aspect of the payloads are encrypted. Thus, Section 2.1 weakens this aspect of
RTP security. RTP security.
10. Acknowledgements 10. Acknowledgements
We thank the networking, media compression, and computer music community We thank the networking, media compression, and computer music community
members who have commented or contributed to the effort, including Kurt members who have commented or contributed to the effort, including Kurt
B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow, B, Cynthia Bruyns, Steve Casner, Paul Davis, Robin Davies, Joanne Dow,
Tobias Erichsen, Nicolas Falquet, Dominique Fober, Philippe Gentric, Tobias Erichsen, Roni Even, Nicolas Falquet, Dominique Fober, Philippe
Michael Godfrey, Chris Grigg, Todd Hager, Alfred Hoenes, Michel Jullian, Gentric, Michael Godfrey, Chris Grigg, Todd Hager, Alfred Hoenes, Michel
Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer, Colin Jullian, Phil Kerr, Young-Kwon Lim, Jessica Little, Jan van der Meer,
Perkins, Charlie Richmond, Herbie Robinson, Larry Rowe, Eric Scheirer, Colin Perkins, Charlie Richmond, Herbie Robinson, Larry Rowe, Eric
Dave Singer, Martijn Sipkema, William Stewart, Kent Terry, Magnus Scheirer, Dave Singer, Martijn Sipkema, William Stewart, Kent Terry,
Westerlund, Tom White, Jim Wright, Doug Wyatt, and Giorgio Zoia. We Magnus Westerlund, Tom White, Jim Wright, Doug Wyatt, and Giorgio Zoia.
also thank the members of the San Francisco Bay Area music and audio We also thank the members of the San Francisco Bay Area music and audio
community for creating the context for the work, including Don Buchla, community for creating the context for the work, including Don Buchla,
Chris Chafe, Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron Chris Chafe, Richard Duda, Dan Ellis, Adrian Freed, Ben Gold, Jaron
Lanier, Roger Linn, Richard Lyon, Dana Massie, Max Mathews, Keith Lanier, Roger Linn, Richard Lyon, Dana Massie, Max Mathews, Keith
McMillen, Carver Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave McMillen, Carver Mead, Nelson Morgan, Tom Oberheim, Malcolm Slaney, Dave
Smith, Julius Smith, David Wessel, and Matt Wright. Smith, Julius Smith, David Wessel, and Matt Wright.
11. IANA Considerations 11. IANA Considerations
This section makes a series of requests to IANA. The IANA has completed This document does not change any of the registrations in RFC 4695.
registration/assignments of the below requests. Therefore, this document does not require any IANA actions, apart from
updating the references to RFC 4695 to point to this document.
The sub-sections that follow hold the actual, detailed requests. All
registrations in this section are in the IETF tree and follow the rules
of [RFC4288] and [RFC4855], as appropriate.
In Section 11.1, we request the registration of a new media type:
"audio/rtp-midi". Paired with this request is a request for a
repository for new values for several parameters associated with
"audio/rtp-midi". We request this repository in Section 11.1.1.
In Section 11.2, we request the registration of a new value ("rtp-
midi") for the "mode" parameter of the "mpeg4-generic" media type. The
"mpeg4-generic" media type is defined in [RFC3640], and [RFC3640]
defines a repository for the "mode" parameter. However, we believe we
are the first to request the registration of a "mode" value, so we
believe the registry for "mode" has not yet been created by IANA.
Paired with our "mode" parameter value request for "mpeg4-generic" is a
request for a repository for new values for several parameters we have
defined for use with the "rtp-midi" mode value. We request this
repository in Section 11.2.1.
In Section 11.3, we request the registration of a new media type:
"audio/asc". No repository request is associated with this request.
11.1. rtp-midi Media Type Registration
This section requests the registration of the "rtp-midi" subtype for the
"audio" media type. We request the registration of the parameters
listed in the "optional parameters" section below (both the "non-
extensible parameters" and the "extensible parameters" lists). We also
request the creation of repositories for the "extensible parameters";
the details of this request appear in Section 11.1.1, below.
Media type name:
audio
Subtype name:
rtp-midi
Required parameters:
rate: The RTP timestamp clock rate. See Sections 2.1 and 6.1
for usage details.
Optional parameters:
Non-extensible parameters:
ch_anchor: See Appendix C.2.3 for usage details.
ch_default: See Appendix C.2.3 for usage details.
ch_never: See Appendix C.2.3 for usage details.
cm_unused: See Appendix C.1 for usage details.
cm_used: See Appendix C.1 for usage details.
chanmask: See Appendix C.6.4.3 for usage details.
cid: See Appendix C.6.3 for usage details.
guardtime: See Appendix C.4.2 for usage details.
inline: See Appendix C.6.3 for usage details.
linerate: See Appendix C.3 for usage details.
mperiod: See Appendix C.3 for usage details.
multimode: See Appendix C.6.1 for usage details.
musicport: See Appendix C.5 for usage details.
octpos: See Appendix C.3 for usage details.
rinit: See Appendix C.6.3 for usage details.
rtp_maxptime: See Appendix C.4.1 for usage details.
rtp_ptime: See Appendix C.4.1 for usage details.
smf_cid: See Appendix C.6.4.2 for usage details.
smf_inline: See Appendix C.6.4.2 for usage details.
smf_url: See Appendix C.6.4.2 for usage details.
tsmode: See Appendix C.3 for usage details.
url: See Appendix C.6.3 for usage details.
Extensible parameters:
j_sec: See Appendix C.2.1 for usage details. See
Section 11.1.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Section 11.1.1 for repository details.
render: See Appendix C.6 for usage details. See
Section 11.1.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Section 11.1.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Section 11.1.1 for repository details.
Encoding considerations:
The format for this type is framed and binary.
Restrictions on usage:
This type is only defined for real-time transfers of MIDI
streams via RTP. Stored-file semantics for rtp-midi may
be defined in the future.
Security considerations:
See Section 9 of this memo.
Interoperability considerations:
None.
Published specification:
This memo and [MIDI] serve as the normative specification. In
addition, references [NMP], [GRAME], and [RFC4696] provide
non-normative implementation guidance.
Applications that use this media type:
Audio content-creation hardware, such as MIDI controller piano
keyboards and MIDI audio synthesizers. Audio content-creation
software, such as music sequencers, digital audio workstations,
and soft synthesizers. Computer operating systems, for network
support of MIDI Application Programmer Interfaces. Content
distribution servers and terminals may use this media type for
low bit-rate music coding.
Additional information:
None.
Person & email address to contact for further information:
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
COMMON.
Author:
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
IETF Audio/Video Transport Working Group delegated
from the IESG.
11.1.1. Repository Request for "audio/rtp-midi"
For the "rtp-midi" subtype, we request the creation of repositories for
extensions to the following parameters (which are those listed as
"extensible parameters" in Section 11.1).
j_sec:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1
of this memo describes appropriate registrations for this
repository.
Initial values for this repository appear below:
"none": Defined in Appendix C.2.1 of this memo.
"recj": Defined in Appendix C.2.1 of this memo.
j_update:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.2
of this memo describes appropriate registrations for this
repository.
Initial values for this repository appear below:
"anchor": Defined in Appendix C.2.2 of this memo.
"open-loop": Defined in Appendix C.2.2 of this memo.
"closed-loop": Defined in Appendix C.2.2 of this memo.
render:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in the preamble of Appendix C.6 for details
(the paragraph that begins "Other render token ...").
Initial values for this repository appear below:
"unknown": Defined in Appendix C.6 of this memo.
"synthetic": Defined in Appendix C.6 of this memo.
"api": Defined in Appendix C.6 of this memo.
"null": Defined in Appendix C.6 of this memo.
subrender:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text Appendix C.6.2 for details (the paragraph
that begins "Other subrender token ...").
Initial values for this repository appear below:
"default": Defined in Appendix C.6.2 of this memo.
smf_info:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in Appendix C.6.4.1 for details (the
paragraph that begins "Other smf_info token ...").
Initial values for this repository appear below:
"ignore": Defined in Appendix C.6.4.1 of this memo.
"sdp_start": Defined in Appendix C.6.4.1 of this memo.
"identity": Defined in Appendix C.6.4.1 of this memo.
11.2. mpeg4-generic Media Type Registration
This section requests the registration of the "rtp-midi" value for the
"mode" parameter of the "mpeg4-generic" media type. The "mpeg4-
generic" media type is defined in [RFC3640], and [RFC3640] defines a
repository for the "mode" parameter. We are registering mode rtp- midi
to support the MPEG Audio codecs [MPEGSA] that use MIDI.
In conjunction with this registration request, we request the
registration of the parameters listed in the "optional parameters"
section below (both the "non-extensible parameters" and the "extensible
parameters" lists). We also request the creation of repositories for
the "extensible parameters"; the details of this request appear in
Appendix 11.2.1, below.
Media type name:
audio
Subtype name:
mpeg4-generic
Required parameters:
The "mode" parameter is required by [RFC3640]. [RFC3640] requests
a repository for "mode", so that new values for mode
may be added. We request that the value "rtp-midi" be
added to the "mode" repository.
In mode rtp-midi, the mpeg4-generic parameter rate is
a required parameter. Rate specifies the RTP timestamp
clock rate. See Sections 2.1 and 6.2 for usage details
of rate in mode rtp-midi.
Optional parameters:
We request registration of the following parameters
for use in mode rtp-midi for mpeg4-generic.
Non-extensible parameters:
ch_anchor: See Appendix C.2.3 for usage details.
ch_default: See Appendix C.2.3 for usage details.
ch_never: See Appendix C.2.3 for usage details.
cm_unused: See Appendix C.1 for usage details.
cm_used: See Appendix C.1 for usage details.
chanmask: See Appendix C.6.4.3 for usage details.
cid: See Appendix C.6.3 for usage details.
guardtime: See Appendix C.4.2 for usage details.
inline: See Appendix C.6.3 for usage details.
linerate: See Appendix C.3 for usage details.
mperiod: See Appendix C.3 for usage details.
multimode: See Appendix C.6.1 for usage details.
musicport: See Appendix C.5 for usage details.
octpos: See Appendix C.3 for usage details.
rinit: See Appendix C.6.3 for usage details.
rtp_maxptime: See Appendix C.4.1 for usage details.
rtp_ptime: See Appendix C.4.1 for usage details.
smf_cid: See Appendix C.6.4.2 for usage details.
smf_inline: See Appendix C.6.4.2 for usage details.
smf_url: See Appendix C.6.4.2 for usage details.
tsmode: See Appendix C.3 for usage details.
url: See Appendix C.6.3 for usage details.
Extensible parameters:
j_sec: See Appendix C.2.1 for usage details. See
Section 11.2.1 for repository details.
j_update: See Appendix C.2.2 for usage details. See
Section 11.2.1 for repository details.
render: See Appendix C.6 for usage details. See
Section 11.2.1 for repository details.
subrender: See Appendix C.6.2 for usage details. See
Section 11.2.1 for repository details.
smf_info: See Appendix C.6.4.1 for usage details. See
Section 11.2.1 for repository details.
Encoding considerations:
The format for this type is framed and binary.
Restrictions on usage:
Only defined for real-time transfers of audio/mpeg4-generic
RTP streams with mode=rtp-midi.
Security considerations:
See Section 9 of this memo.
Interoperability considerations:
Except for the marker bit (Section 2.1), the packet formats
for audio/rtp-midi and audio/mpeg4-generic (mode rtp-midi)
are identical. The formats differ in use: audio/mpeg4-generic
is for MPEG work, and audio/rtp-midi is for all other work.
Published specification:
This memo, [MIDI], and [MPEGSA] are the normative references.
In addition, references [NMP], [GRAME], and [RFC4696] provide
non-normative implementation guidance.
Applications that use this media type:
MPEG 4 servers and terminals that support [MPEGSA].
Additional information:
None.
Person & email address to contact for further information:
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
COMMON.
Author:
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
IETF Audio/Video Transport Working Group delegated
from the IESG.
11.2.1. Repository Request for Mode rtp-midi for mpeg4-generic
For mode rtp-midi of the mpeg4-generic subtype, we request the creation
of repositories for extensions to the following parameters (which are
those listed as "extensible parameters" in Section 11.2).
j_sec:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.1
of this memo describes appropriate registrations for this
repository.
Initial values for this repository appear below:
"none": Defined in Appendix C.2.1 of this memo.
"recj": Defined in Appendix C.2.1 of this memo.
j_update:
Registrations for this repository may only occur
via an IETF standards-track document. Appendix C.2.2
of this memo describes appropriate registrations for this
repository.
Initial values for this repository appear below:
"anchor": Defined in Appendix C.2.2 of this memo.
"open-loop": Defined in Appendix C.2.2 of this memo.
"closed-loop": Defined in Appendix C.2.2 of this memo.
render:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in the preamble of Appendix C.6 for details
(the paragraph that begins "Other render token ...").
Initial values for this repository appear below:
"unknown": Defined in Appendix C.6 of this memo.
"synthetic": Defined in Appendix C.6 of this memo.
"null": Defined in Appendix C.6 of this memo.
subrender:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in Appendix C.6.2 for details (the paragraph
that begins "Other subrender token ..." and
subsequent paragraphs). Note that the text in
Appendix C.6.2 contains restrictions on subrender
registrations for mpeg4-generic ("Registrations
for mpeg4-generic subrender values ...").
Initial values for this repository appear below:
"default": Defined in Appendix C.6.2 of this memo.
smf_info:
Registrations for this repository MUST include a
specification of the usage of the proposed value.
See text in Appendix C.6.4.1 for details (the
paragraph that begins "Other smf_info token ...").
Initial values for this repository appear below:
"ignore": Defined in Appendix C.6.4.1 of this memo.
"sdp_start": Defined in Appendix C.6.4.1 of this memo.
"identity": Defined in Appendix C.6.4.1 of this memo.
11.3. asc Media Type Registration
This section registers "asc" as a subtype for the "audio" media type.
We register this subtype to support the remote transfer of the "config"
parameter of the mpeg4-generic media type [RFC3640] when it is used with
mpeg4-generic mode rtp-midi (registered in Appendix 11.2 above). We
explain the mechanics of using "audio/asc" to set the config parameter
in Section 6.2 and Appendix C.6.5 of this document.
Note that this registration is a new subtype registration and is not an
addition to a repository defined by MPEG-related memos (such as
[RFC3640]). Also note that this request for "audio/asc" does not
register parameters, and does not request the creation of a repository.
Media type name:
audio
Subtype name:
asc
Required parameters:
None.
Optional parameters:
None.
Encoding considerations:
The native form of the data object is binary data,
zero-padded to an octet boundary.
Restrictions on usage:
This type is only defined for data object (stored file)
transfer. The most common transports for the type are
HTTP and SMTP.
Security considerations:
See Section 9 of this memo.
Interoperability considerations:
None.
Published specification:
The audio/asc data object is the AudioSpecificConfig
binary data structure, which is normatively defined in [MPEGAUDIO].
Applications that use this media type:
MPEG 4 Audio servers and terminals that support
audio/mpeg4-generic RTP streams for mode rtp-midi.
Additional information:
None.
Person & email address to contact for further information:
John Lazzaro <lazzaro@cs.berkeley.edu>
Intended usage:
COMMON.
Author:
John Lazzaro <lazzaro@cs.berkeley.edu>
Change controller:
IETF Audio/Video Transport Working Group delegated
from the IESG.
A. The Recovery Journal Channel Chapters A. The Recovery Journal Channel Chapters
A.1. Recovery Journal Definitions A.1. Recovery Journal Definitions
This appendix defines the terminology and the coding idioms that are This appendix defines the terminology and the coding idioms that are
used in the recovery journal bitfield descriptions in Section 5 (journal used in the recovery journal bitfield descriptions in Section 5 (journal
header structure), Appendices A.2 to A.9 (channel journal chapters) and header structure), Appendices A.2 to A.9 (channel journal chapters) and
Appendices B.1 to B.5 (system journal chapters). Appendices B.1 to B.5 (system journal chapters).
skipping to change at page 176, line 5 skipping to change at page 165, line 5
This string is assigned to the "config" parameter in the minimal This string is assigned to the "config" parameter in the minimal
mpeg4-generic General MIDI examples in this memo (such as the example in mpeg4-generic General MIDI examples in this memo (such as the example in
Section 6.2). Expressing this string in Base64 [RFC2045] yields: Section 6.2). Expressing this string in Base64 [RFC2045] yields:
egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA egoAAAAaTVRoZAAAAAYAAAABAGBNVHJrAAAABgD/LwAA
This string is assigned to the "inline" parameter in the General MIDI This string is assigned to the "inline" parameter in the General MIDI
example shown in Appendix C.6.5. example shown in Appendix C.6.5.
F. Changes from RFC 4695
This document fixes errors found in RFC 4695 by reviewers. We thank
Alfred Hoenes and Roni Even for reporting the errors. To our knowledge,
there are no interoperability issues associated with the errors that are
fixed by this document. In this section, we list the error fixes.
In Section 3 of RFC 4695, the bitfield format shown in Figure 3 is
inconsistent with the normative text that (correctly) describes the
bitfield. Specifically, Figure 3 in RFC 4695 incorrectly states the
dependence of the Delta Time 0 field on the Z header bit. Figure 3 in
this document corrects this error. To our knowledge, this error did not
result in incorrect implementations of RFC 4695.
The remaining errors are in Appendices C and D, and concern session
configuration parameters. The numbered list ([1] through [8]) below
describes these errors in detail, in order of appearance in the
document. To our knowledge, there are no interoperability issues
associated with these errors, as implementation activity has so far
focused on an application domain that does not use SDP for session
management.
[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 a cm_used assignment).
[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 = %x50
Q = %x51
T = %x54
V = %x56
W = %x57
X = %x58
Y = %x59
Z = %x5A
[6] In Appendix D of RFC 4695, the definitions of <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 [6] above
; A, B, C, D, E, F as defined in [5] 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) "=")
References References
Normative References Normative References
[MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0 [MIDI] MIDI Manufacturers Association. "The Complete MIDI 1.0
Detailed Specification", 1996. Detailed Specification", 1996.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
skipping to change at page 180, line 4 skipping to change at line 7237
are provided without warranty as described in the Simplified BSD are provided without warranty as described in the Simplified BSD
License. License.
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
Acknowledgement Acknowledgement
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Change Log for <draft-ietf-avt-rfc4695-bis-08.txt>
This I-D is a modified version of RFC 4695. For every error found to
date in RFC 4695, the I-D has been modified to fix the error.
Below, we list the errors found in RFC 4695 that are most likely to
confuse implementors. The fixes to Appendix D ABNF errors listed
below are presented without comments; see Appendix D to see the
commented rule in context. The list below includes the fixes for all
normative errors; most fixes for other types of errors are not listed.
However, the I-D itself contains fixes for all known errors.
03-08.txt changes:
No errata has been reported for RFC 4695 in the past year.
Apart from updates in the document name and expiration dates,
03-08.txt contains no changes from 02.txt
02.txt changes:
No errata has been reported for RFC 4695 in the past six months.
Apart from updates in the document name and expiration dates,
02.txt contains no changes from 01.txt
01.txt changes:
A typo was fixed in the Appendix D ABNF. P and Q are now
correctly defined as:
P = %x50
Q = %x51
Thanks to Alfred Hoenes for these changes.
00.txt changes:
Thanks to Alfred Hoenes for these changes.
[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 = %x50 ; correct as shown, these values were
Q = %x51 ; incorrect in the -00.txt I-D version
T = %x54
V = %x56
W = %x57
X = %x58
Y = %x59
Z = %x5A
[5] 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
[6] 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
[7] 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) "=")
 End of changes. 11 change blocks. 
603 lines changed or deleted 227 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/