draft-ietf-avt-rfc4695-bis-09.txt   draft-ietf-avt-rfc4695-bis-10.txt 
AVT J. Lazzaro AVT J. Lazzaro
Internet-Draft J. Wawrzynek Internet-Draft J. Wawrzynek
Obsoletes: 4695 (if approved) UC Berkeley Obsoletes: 4695 (if approved) UC Berkeley
Intended status: Standards Track December 17, 2010 Intended status: Standards Track January 24, 2011
Expires: June 17, 2011 Expires: July 24, 2011
RTP Payload Format for MIDI RTP Payload Format for MIDI
<draft-ietf-avt-rfc4695-bis-09.txt> <draft-ietf-avt-rfc4695-bis-10.txt>
Abstract Abstract
This memo describes a Real-time Transport Protocol (RTP) payload This memo describes a Real-time Transport Protocol (RTP) payload
format for the MIDI (Musical Instrument Digital Interface) command format for the MIDI (Musical Instrument Digital Interface) command
language. The format encodes all commands that may legally appear on language. The format encodes all commands that may legally appear on
a MIDI 1.0 DIN cable. The format is suitable for interactive a MIDI 1.0 DIN cable. The format is suitable for interactive
applications (such as network musical performance) and content- applications (such as network musical performance) and content-
delivery applications (such as file streaming). The format may be delivery applications (such as file streaming). The format may be
used over unicast and multicast UDP and TCP, and it defines tools for used over unicast and multicast UDP and TCP, and it defines tools for
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 July 24, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 34, line 15 skipping to change at page 34, line 15
The session description that follows defines a unicast UDP RTP session The session description that follows defines a unicast UDP RTP session
(via a media ("m=") line) whose sole payload type (96) is mapped to a (via a media ("m=") line) whose sole payload type (96) is mapped to a
minimal mpeg4-generic RTP MIDI stream. This example uses the General minimal mpeg4-generic RTP MIDI stream. This example uses the General
MIDI Audio Object Type under Synthesis Profile @ Level 2. MIDI Audio Object Type under Synthesis Profile @ Level 2.
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24 c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100 a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12; a=fmtp:96 streamtype=5; mode=rtp-midi; profile-level-id=12;
config=7A0A0000001A4D546864000000060000000100604D54726B0000 config=7A0A0000001A4D546864000000060000000100604D54726B0000
000600FF2F000 000600FF2F000
(The a=fmtp line has been wrapped to fit the page to accommodate memo (The a=fmtp line has been wrapped to fit the page to accommodate memo
formatting restrictions; it comprises a single line in SDP.) formatting restrictions; it comprises a single line in SDP.)
The fmtp attribute line codes the four parameters (streamtype, mode, The fmtp attribute line codes the four parameters (streamtype, mode,
profile-level-id, and config) that are required in all mpeg4-generic profile-level-id, and config) that are required in all mpeg4-generic
skipping to change at page 99, line 29 skipping to change at page 99, line 29
cm_unused to specify complex behaviors. cm_unused to specify complex behaviors.
The example session description below illustrates the use of the stream The example session description below illustrates the use of the stream
subsetting parameters: subsetting parameters:
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24 c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__ a=fmtp:96 cm_unused=ACGHJKNMPTVWXYZ; cm_used=__7F_00-7F_01_01__
The session description configures the stream for use in clock The session description configures the stream for use in clock
applications. All voice channels are unused, as are all System Commands applications. All voice channels are unused, as are all System Commands
except those used for MIDI Time Code (command-type F, and the Full Frame except those used for MIDI Time Code (command-type F, and the Full Frame
SysEx command that is matched by the string assigned to cm_used), the SysEx command that is matched by the string assigned to cm_used), the
System Sequencer commands (command-type Q), and System Reset (command- System Sequencer commands (command-type Q), and System Reset (command-
type B). type B).
skipping to change at page 112, line 10 skipping to change at page 112, line 10
chapter parameter assignments described earlier in this section. chapter parameter assignments described earlier in this section.
The example session description below illustrates the use of the chapter The example session description below illustrates the use of the chapter
inclusion parameters: inclusion parameters:
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24 c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ; a=fmtp:96 j_update=open-loop; cm_unused=ABCFGHJKMQTVWXYZ;
cm_used=__7E_00-7F_09_01.02.03__; cm_used=__7E_00-7F_09_01.02.03__;
cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64; cm_used=__7F_00-7F_04_01.02__; cm_used=C7.64;
ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N; ch_never=ABCDEFGHJKMQTVWXYZ; ch_never=4.11-13N;
ch_anchor=P; ch_anchor=C7.64; ch_anchor=P; ch_anchor=C7.64;
ch_anchor=__7E_00-7F_09_01.02.03__; ch_anchor=__7E_00-7F_09_01.02.03__;
ch_anchor=__7F_00-7F_04_01.02__ ch_anchor=__7F_00-7F_04_01.02__
(The a=fmtp line has been wrapped to fit the page to accommodate (The a=fmtp line has been wrapped to fit the page to accommodate
skipping to change at page 116, line 19 skipping to change at page 116, line 19
into a buffer upon receipt. The sender polls the buffer 1000 times a into a buffer upon receipt. The sender polls the buffer 1000 times a
second, extracts all complete commands from the buffer, and places the second, extracts all complete commands from the buffer, and places the
commands in an RTP packet. This session description describes the commands in an RTP packet. This session description describes the
transcoding: transcoding:
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24 c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=sendonly a=sendonly
a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44 a=fmtp:96 tsmode=buffer; linerate=320000; octpos=last; mperiod=44
The mperiod value of 44 is derived by dividing the clock rate specified The mperiod value of 44 is derived by dividing the clock rate specified
by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate by the rtpmap attribute (44100 Hz) by the 1000 Hz buffer sampling rate
and rounding to the nearest integer. Command timestamps might not and rounding to the nearest integer. Command timestamps might not
increment by exact multiples of 44, as the actual sampling period might increment by exact multiples of 44, as the actual sampling period might
not precisely match the nominal mperiod value. not precisely match the nominal mperiod value.
skipping to change at page 119, line 16 skipping to change at page 119, line 16
parameter value. In this case, senders SHOULD use the lowest minimum parameter value. In this case, senders SHOULD use the lowest minimum
sending rate that satisfies the congestion control requirements. sending rate that satisfies the congestion control requirements.
Below, we show a session description that uses the guardtime parameter. Below, we show a session description that uses the guardtime parameter.
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5004 RTP/AVP 96 m=audio 5004 RTP/AVP 96
c=IN IP6 2001:DB80::7F2E:172A:1E24 c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 rtp-midi/44100 a=rtpmap:96 rtp-midi/44100
a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0 a=fmtp:96 guardtime=44100; rtp_ptime=0; rtp_maxptime=0
C.5. Configuration Tools: Stream Description C.5. Configuration Tools: Stream Description
As we discussed in Section 2.1, a party may send several RTP MIDI As we discussed in Section 2.1, a party may send several RTP MIDI
streams in the same RTP session, and several RTP sessions that carry streams in the same RTP session, and several RTP sessions that carry
MIDI may appear in a multimedia session. MIDI may appear in a multimedia session.
By default, the MIDI name space (16 channels + systems) of each RTP By default, the MIDI name space (16 channels + systems) of each RTP
stream sent by a party in a multimedia session is independent. By stream sent by a party in a multimedia session is independent. By
skipping to change at page 120, line 39 skipping to change at page 120, line 39
In this appendix, we show how to express that specific RTP MIDI streams In this appendix, we show how to express that specific RTP MIDI streams
in a multimedia session are not independent but instead are related in in a multimedia session are not independent but instead are related in
one of the three ways defined above. We use two tools to express these one of the three ways defined above. We use two tools to express these
relations: relations:
o The musicport parameter. This parameter is assigned a o The musicport parameter. This parameter is assigned a
non-negative integer value between 0 and 4294967295. It non-negative integer value between 0 and 4294967295. It
appears in the fmtp lines of payload types. appears in the fmtp lines of payload types.
o The FID grouping attribute [RFC3388] signals that several RTP o The FID grouping attribute [RFC5888] signals that several RTP
sessions in a multimedia session are using the musicport sessions in a multimedia session are using the musicport
parameter to express an inter-session relationship. parameter to express an inter-session relationship.
If a multimedia session has several payload types whose musicport If a multimedia session has several payload types whose musicport
parameters are assigned the same integer value, streams using these parameters are assigned the same integer value, streams using these
payload types share an "identity relationship" (including streams that payload types share an "identity relationship" (including streams that
use the same payload type). Streams in an identity relationship share use the same payload type). Streams in an identity relationship share
two properties: two properties:
o Identity relationship streams sent by the same party o Identity relationship streams sent by the same party
skipping to change at page 121, line 37 skipping to change at page 121, line 37
musicport value of 3, MIDI voice channel 0 in stream B is considered to musicport value of 3, MIDI voice channel 0 in stream B is considered to
be voice channel 16 in the larger MIDI space formed by the relationship. be voice channel 16 in the larger MIDI space formed by the relationship.
Note that it is possible for streams to participate in both an identity Note that it is possible for streams to participate in both an identity
relationship and an ordered relationship. relationship and an ordered relationship.
We now state several rules for using musicport: We now state several rules for using musicport:
o If streams from several RTP sessions in a multimedia o If streams from several RTP sessions in a multimedia
session use the musicport parameter, the RTP sessions session use the musicport parameter, the RTP sessions
MUST be grouped using the FID grouping attribute MUST be grouped using the FID grouping attribute
defined in [RFC3388]. defined in [RFC5888].
o An ordered or identity relationship MUST NOT o An ordered or identity relationship MUST NOT
contain both native RTP MIDI streams and contain both native RTP MIDI streams and
mpeg4-generic RTP MIDI streams. An exception applies mpeg4-generic RTP MIDI streams. An exception applies
if a relationship consists of sendonly and recvonly if a relationship consists of sendonly and recvonly
(but not sendrecv) streams. In this case, the sendonly (but not sendrecv) streams. In this case, the sendonly
streams MUST NOT contain both types of streams, and the streams MUST NOT contain both types of streams, and the
recvonly streams MUST NOT contain both types of streams. recvonly streams MUST NOT contain both types of streams.
o It is possible to construct identity relationships o It is possible to construct identity relationships
skipping to change at page 123, line 45 skipping to change at page 123, line 45
a=mid:2 a=mid:2
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12; a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=12;
musicport=12 musicport=12
(The a=fmtp lines have been wrapped to fit the page to accommodate (The a=fmtp lines have been wrapped to fit the page to accommodate
memo formatting restrictions; they comprise single lines in SDP.) memo formatting restrictions; they comprise single lines in SDP.)
Recall that Section 2.1 defines rules for streams that target the same Recall that Section 2.1 defines rules for streams that target the same
MIDI name space. Those rules, implemented in the example above, require MIDI name space. Those rules, implemented in the example above, require
that each stream resides in a separate RTP session, and that the that each stream resides in a separate RTP session, and that the
grouping mechanisms defined in [RFC3388] signal an inter-session grouping mechanisms defined in [RFC5888] signal an inter-session
relationship. The "group" and "mid" attribute lines implement this relationship. The "group" and "mid" attribute lines implement this
grouping mechanism. grouping mechanism.
A variant on this example, whose session description is not shown, would A variant on this example, whose session description is not shown, would
use two streams in an identity relationship driving the same MIDI use two streams in an identity relationship driving the same MIDI
renderer, each with a different transport type. One stream would use renderer, each with a different transport type. One stream would use
UDP and would be dedicated to real-time messages. A second stream would UDP and would be dedicated to real-time messages. A second stream would
use TCP [RFC4571] and would be used for SysEx bulk data messages. use TCP [RFC4571] and would be used for SysEx bulk data messages.
In the next example, two mpeg4-generic streams form an ordered In the next example, two mpeg4-generic streams form an ordered
relationship to drive a Structured Audio decoder with 32 MIDI voice relationship to drive a Structured Audio decoder with 32 MIDI voice
channels. Both streams reside in the same RTP session. channels. Both streams reside in the same RTP session.
v=0 v=0
o=lazzaro 2520644554 2838152170 IN IP6 first.example.net o=lazzaro 2520644554 2838152170 IN IP6 first.example.net
s=Example s=Example
t=0 0 t=0 0
m=audio 5006 RTP/AVP 96 97 m=audio 5006 RTP/AVP 96 97
c=IN IP6 2001:DB80::7F2E:172A:1E24 c=IN IP6 2001:DB8::7F2E:172A:1E24
a=rtpmap:96 mpeg4-generic/44100 a=rtpmap:96 mpeg4-generic/44100
a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; a=fmtp:96 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13;
musicport=5 musicport=5
a=rtpmap:97 mpeg4-generic/44100 a=rtpmap:97 mpeg4-generic/44100
a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13; a=fmtp:97 streamtype=5; mode=rtp-midi; config=""; profile-level-id=13;
musicport=6; render=synthetic; rinit="audio/asc"; musicport=6; render=synthetic; rinit="audio/asc";
url="http://example.com/cardinal.asc"; url="http://example.com/cardinal.asc";
cid="azsldkaslkdjqpwojdkmsldkfpe" cid="azsldkaslkdjqpwojdkmsldkfpe"
(The a=fmtp lines have been wrapped to fit the page to accommodate (The a=fmtp lines have been wrapped to fit the page to accommodate
skipping to change at page 165, line 20 skipping to change at page 165, line 20
fixed by this document. In this section, we list the error fixes. 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 In Section 3 of RFC 4695, the bitfield format shown in Figure 3 is
inconsistent with the normative text that (correctly) describes the inconsistent with the normative text that (correctly) describes the
bitfield. Specifically, Figure 3 in RFC 4695 incorrectly states 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 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 this document corrects this error. To our knowledge, this error did not
result in incorrect implementations of RFC 4695. result in incorrect implementations of RFC 4695.
The remaining errors are in Appendices C and D, and concern session The remaining errors are in Appendices C and D, and concern session
configuration parameters. The numbered list ([1] through [8]) below configuration parameters. The numbered list ((1) through (8)) below
describes these errors in detail, in order of appearance in the describes these errors in detail, in order of appearance in the
document. To our knowledge, there are no interoperability issues document. To our knowledge, there are no interoperability issues
associated with these errors, as implementation activity has so far associated with these errors, as implementation activity has so far
focused on an application domain that does not use SDP for session focused on an application domain that does not use SDP for session
management. management.
[1] In Appendix C.1 and Appendix C.2.3 of RFC 4695, an ABNF rule (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: related to System Chapter X is incorrectly defined as:
<parameter> = "__" <h-list> ["_" <h-list>] "__" <parameter> = "__" <h-list> ["_" <h-list>] "__"
The correct version of this rule is: The correct version of this rule is:
<parameter> = "__" <h-list> *( "_" <h-list> ) "__" <parameter> = "__" <h-list> *( "_" <h-list> ) "__"
[2] In Appendix C.6.3 of RFC 4695, the URIs permitted to be assigned (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" to the "url" parameter are not stated clearly. URIs assigned to "url"
MUST specify either HTTP or HTTP over TLS transport protocols. MUST specify either HTTP or HTTP over TLS transport protocols.
In Appendix C.7.1 and C.7.2 of RFC 4695, the transport In Appendix C.7.1 and C.7.2 of RFC 4695, the transport
interoperability requirements for the "url" parameter are not stated 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 clearly. For both C.7.1 and C.7.2, HTTP is REQUIRED and HTTP over TLS
is OPTIONAL. is OPTIONAL.
[3] Both fmtp lines in both session description examples in Appendix (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 C.7.2 of RFC 4695 contain instances of the same syntax error (a
missing ";" at a line wrap after a cm_used assignment). missing ";" at a line wrap after a cm_used assignment).
[4] In Appendix D of RFC 4695, all uses of "*ietf-extension" in rules (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, are in error, and should be replaced with "ietf-extension". Likewise,
all uses of "*extension" are in error, and should be replaced with all uses of "*extension" are in error, and should be replaced with
"extension". This bug incorrectly lets the null token be assigned to "extension". This bug incorrectly lets the null token be assigned to
the j_sec, j_update, render, smf_info, and subrender parameters. the j_sec, j_update, render, smf_info, and subrender parameters.
[5] In Appendix D of RFC 4695, the definitions of the <command-type> (5) In Appendix D of RFC 4695, the definitions of the <command-type>
and <chapter-rules> incorrectly allow lowercase letters to appear in and <chapter-rules> incorrectly allow lowercase letters to appear in
these strings. The correct definitions of these rules appear below: these strings. The correct definitions of these rules appear below:
command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M] command-type = [A] [B] [C] [F] [G] [H] [J] [K] [M]
[N] [P] [Q] [T] [V] [W] [X] [Y] [Z] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K] chapter-list = [A] [B] [C] [D] [E] [F] [G] [H] [J] [K]
[M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z] [M] [N] [P] [Q] [T] [V] [W] [X] [Y] [Z]
A = %x41 A = %x41
skipping to change at page 166, line 38 skipping to change at page 166, line 38
N = %x4E N = %x4E
P = %x50 P = %x50
Q = %x51 Q = %x51
T = %x54 T = %x54
V = %x56 V = %x56
W = %x57 W = %x57
X = %x58 X = %x58
Y = %x59 Y = %x59
Z = %x5A Z = %x5A
[6] In Appendix D of RFC 4695, the definitions of <four-octet>, (6) In Appendix D of RFC 4695, the definitions of <four-octet>,
<nonzero-four-octet>, and <midi-chan> are incorrect. The correct <nonzero-four-octet>, and <midi-chan> are incorrect. The correct
definitions of these rules appear below: definitions of these rules appear below:
nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT)) nonzero-four-octet = (NZ-DIGIT 0*8(DIGIT))
/ (%x30-33 9(DIGIT)) / (%x30-33 9(DIGIT))
/ ("4" %x30-31 8(DIGIT)) / ("4" %x30-31 8(DIGIT))
/ ("42" %x30-38 7(DIGIT)) / ("42" %x30-38 7(DIGIT))
/ ("429" %x30-33 6(DIGIT)) / ("429" %x30-33 6(DIGIT))
/ ("4294" %x30-38 5(DIGIT)) / ("4294" %x30-38 5(DIGIT))
/ ("42949" %x30-35 4(DIGIT)) / ("42949" %x30-35 4(DIGIT))
skipping to change at page 167, line 12 skipping to change at page 167, line 12
/ ("4294967" %x30-31 2(DIGIT)) / ("4294967" %x30-31 2(DIGIT))
/ ("42949672" %x30-38 (DIGIT)) / ("42949672" %x30-38 (DIGIT))
/ ("429496729" %x30-34) / ("429496729" %x30-34)
four-octet = "0" / nonzero-four-octet four-octet = "0" / nonzero-four-octet
midi-chan = DIGIT / ("1" %x30-35) midi-chan = DIGIT / ("1" %x30-35)
DIGIT = %x30-39 DIGIT = %x30-39
NZ-DIGIT = %x31-39 NZ-DIGIT = %x31-39
[7] In Appendix D of RFC4695, the rule <hex-octet> is (7) In Appendix D of RFC4695, the rule <hex-octet> is
incorrect. The correct definition of this rule appears below. incorrect. The correct definition of this rule appears below.
hex-octet = %x30-37 U-HEXDIG hex-octet = %x30-37 U-HEXDIG
U-HEXDIG = DIGIT / A / B / C / D / E / F U-HEXDIG = DIGIT / A / B / C / D / E / F
; DIGIT as defined in [6] above ; DIGIT as defined in (6) above
; A, B, C, D, E, F as defined in [5] above ; A, B, C, D, E, F as defined in (5) above
[8] In Appendix D of RFC4695, the rules <base64-unit> and (8) In Appendix D of RFC4695, the rules <base64-unit> and
<base64-pad> are defined unclearly. The rewritten rules <base64-pad> are defined unclearly. The rewritten rules
appear below: appear below:
base64-unit = 4(base64-char) base64-unit = 4(base64-char)
base64-pad = (2(base64-char) "==") / (3(base64-char) "=") base64-pad = (2(base64-char) "==") / (3(base64-char) "=")
References References
Normative References Normative References
skipping to change at page 169, line 15 skipping to change at page 169, line 15
2002. 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3388] Camarillo, G., Eriksson, G., Holler, J., and H. [RFC5888] Camarillo, G. and H. Schulzrinne, "The Session
Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP) Grouping Framework",
Description Protocol (SDP)", RFC 3388, December 2002. RFC 5888, June 2010.
[RP015] MIDI Manufacturers Association. "Recommended Practice [RP015] MIDI Manufacturers Association. "Recommended Practice
015 (RP-015): Response to Reset All Controllers", 11/98. 015 (RP-015): Response to Reset All Controllers", 11/98.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December Registration Procedures", BCP 13, RFC 4288, December
2005. 2005.
[RFC4855] Casner, S., "MIME Type Registration of RTP
Payload Formats", RFC 4855, February 2007.
Informative References Informative References
[NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network [NMP] Lazzaro, J. and J. Wawrzynek. "A Case for Network
Musical Performance", 11th International Workshop on Musical Performance", 11th International Workshop on
Network and Operating Systems Support for Digital Audio Network and Operating Systems Support for Digital Audio
and Video (NOSSDAV 2001) June 25-26, 2001, Port and Video (NOSSDAV 2001) June 25-26, 2001, Port
Jefferson, New York. Jefferson, New York.
[GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical [GRAME] Fober, D., Orlarey, Y. and S. Letz. "Real Time Musical
Events Streaming over Internet", Proceedings of the Events Streaming over Internet", Proceedings of the
skipping to change at page 171, line 23 skipping to change at page 171, line 23
John Wawrzynek John Wawrzynek
UC Berkeley UC Berkeley
CS Division CS Division
631 Soda Hall 631 Soda Hall
Berkeley CA 94720-1776 Berkeley CA 94720-1776
EMail: johnw@cs.berkeley.edu EMail: johnw@cs.berkeley.edu
Full Copyright Statement Full Copyright Statement
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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.
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2011 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.
 End of changes. 27 change blocks. 
33 lines changed or deleted 30 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/