draft-ietf-avt-rfc4695-bis-02.txt   draft-ietf-avt-rfc4695-bis-03.txt 
INTERNET-DRAFT J. Lazzaro INTERNET-DRAFT J. Lazzaro
August 23, 2007 J. Wawrzynek February 13, 2008 J. Wawrzynek
Expires: February 23, 2008 UC Berkeley Expires: August 13, 2008 UC Berkeley
Intended Status: Proposed Standard Intended Status: Proposed Standard
RTP Payload Format for MIDI RTP Payload Format for MIDI
<draft-ietf-avt-rfc4695-bis-02.txt> <draft-ietf-avt-rfc4695-bis-03.txt>
Status of This Memo Status of This Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79. will be disclosed, in accordance with Section 6 of 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
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 February 23, 2008. This Internet-Draft will expire on August 13, 2008.
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
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 4, line 25 skipping to change at page 4, line 25
C.7.2. MIDI Network Musical Performance Applications . . . 152 C.7.2. MIDI Network Musical Performance Applications . . . 152
D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 161 D. Parameter Syntax Definitions . . . . . . . . . . . . . . . . . . 161
E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 168 E. A MIDI Overview for Networking Specialists . . . . . . . . . . . 168
E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 170 E.1. Commands Types . . . . . . . . . . . . . . . . . . . . . . 170
E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 170 E.2. Running Status . . . . . . . . . . . . . . . . . . . . . . 170
E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 171 E.3. Command Timing . . . . . . . . . . . . . . . . . . . . . . 171
E.4. AudioSpecificConfig Templates for MMA Renderers . . . . . 171 E.4. AudioSpecificConfig Templates for MMA Renderers . . . . . 171
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
Normative References . . . . . . . . . . . . . . . . . . . . . 176 Normative References . . . . . . . . . . . . . . . . . . . . . 176
Informative References . . . . . . . . . . . . . . . . . . . . 177 Informative References . . . . . . . . . . . . . . . . . . . . 177
Change Log for <draft-ietf-avt-rfc4695-bis-02.txt> . . . . . . . . . 181 Change Log for <draft-ietf-avt-rfc4695-bis-03.txt> . . . . . . . . . 181
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
skipping to change at page 40, line 30 skipping to change at page 40, line 30
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 section makes a series of requests to IANA. The IANA has completed
registration/assignments of the below requests. registration/assignments of the below requests.
The sub-sections that follow hold the actual, detailed requests. All The sub-sections that follow hold the actual, detailed requests. All
registrations in this section are in the IETF tree and follow the rules registrations in this section are in the IETF tree and follow the rules
of [RFC4288] and [RFC3555], as appropriate. of [RFC4288] and [RFC4855], as appropriate.
In Section 11.1, we request the registration of a new media type: 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 "audio/rtp-midi". Paired with this request is a request for a
repository for new values for several parameters associated with repository for new values for several parameters associated with
"audio/rtp-midi". We request this repository in Section 11.1.1. "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- 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 midi") for the "mode" parameter of the "mpeg4-generic" media type. The
"mpeg4-generic" media type is defined in [RFC3640], and [RFC3640] "mpeg4-generic" media type is defined in [RFC3640], and [RFC3640]
defines a repository for the "mode" parameter. However, we believe we defines a repository for the "mode" parameter. However, we believe we
skipping to change at page 106, line 25 skipping to change at page 106, line 25
changes during a session well, because the parameters describe changes during a session well, because the parameters describe
heavyweight or stateful configuration that is not easily changed once a heavyweight or stateful configuration that is not easily changed once a
session has begun. Thus, parties SHOULD NOT expect that parameter session has begun. Thus, parties SHOULD NOT expect that parameter
change requests during a session will be accepted by other parties. change requests during a session will be accepted by other parties.
However, implementors SHOULD support in-session parameter changes that However, implementors SHOULD support in-session parameter changes that
are easy to handle (for example, the guardtime parameter defined in are easy to handle (for example, the guardtime parameter defined in
Appendix C.4) and SHOULD be capable of accepting requests for changes of Appendix C.4) and SHOULD be capable of accepting requests for changes of
those parameters, as received by its session management protocol (for those parameters, as received by its session management protocol (for
example, re-offers in SIP [RFC3264]). example, re-offers in SIP [RFC3264]).
Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC4234]) Appendix D defines the Augmented Backus-Naur Form (ABNF, [RFC5234])
syntax for the payload parameters. Section 11 provides information to syntax for the payload parameters. Section 11 provides information to
the Internet Assigned Numbers Authority (IANA) on the media types and the Internet Assigned Numbers Authority (IANA) on the media types and
parameters defined in this document. parameters defined in this document.
Appendix C.6.5 defines the media type "audio/asc", a stored object for Appendix C.6.5 defines the media type "audio/asc", a stored object for
initializing mpeg4-generic renderers. As described in Appendix C.6, the initializing mpeg4-generic renderers. As described in Appendix C.6, the
audio/asc media type is assigned to the "rinit" parameter to specify an audio/asc media type is assigned to the "rinit" parameter to specify an
initialization data object for the default mpeg4-generic renderer. Note initialization data object for the default mpeg4-generic renderer. Note
that RTP stream semantics are not defined for "audio/asc". Therefore, that RTP stream semantics are not defined for "audio/asc". Therefore,
the "asc" subtype MUST NOT appear on the rtpmap line of a session the "asc" subtype MUST NOT appear on the rtpmap line of a session
skipping to change at page 161, line 8 skipping to change at page 161, line 8
In addition, "second" has made several parameter changes: rtp_maxptime In addition, "second" has made several parameter changes: rtp_maxptime
for the sendonly stream has been changed to code 2 ms (441 in clock for the sendonly stream has been changed to code 2 ms (441 in clock
units), and the guardtime for the recvonly stream has been doubled. As units), and the guardtime for the recvonly stream has been doubled. As
these parameter modifications request capabilities that are REQUIRED to these parameter modifications request capabilities that are REQUIRED to
be implemented by interoperable parties, "second" can make these changes be implemented by interoperable parties, "second" can make these changes
with confidence that "first" can abide by them. with confidence that "first" can abide by them.
D. Parameter Syntax Definitions D. Parameter Syntax Definitions
In this appendix, we define the syntax for the RTP MIDI media type In this appendix, we define the syntax for the RTP MIDI media type
parameters in Augmented Backus-Naur Form (ABNF, [RFC4234]). When using parameters in Augmented Backus-Naur Form (ABNF, [RFC5234]). When using
these parameters with SDP, all parameters MUST appear on a single fmtp these parameters with SDP, all parameters MUST appear on a single fmtp
attribute line of an RTP MIDI media description. For mpeg4-generic RTP attribute line of an RTP MIDI media description. For mpeg4-generic RTP
MIDI streams, this line MUST also include any mpeg4-generic parameters MIDI streams, this line MUST also include any mpeg4-generic parameters
(usage described in Section 6.2). An fmtp attribute line may be defined (usage described in Section 6.2). An fmtp attribute line may be defined
(after [RFC3640]) as: (after [RFC3640]) as:
; ;
; SDP fmtp line definition ; SDP fmtp line definition
; ;
skipping to change at page 167, line 14 skipping to change at page 167, line 14
T = %x54 T = %x54
V = %x56 V = %x56
W = %x57 W = %x57
X = %x58 X = %x58
Y = %x59 Y = %x59
Z = %x5A Z = %x5A
NZ-DIGIT = %x31-39 ; non-zero decimal digit NZ-DIGIT = %x31-39 ; non-zero decimal digit
U-HEXDIG = DIGIT / A / B / C / D / E / F U-HEXDIG = DIGIT / A / B / C / D / E / F
; variant of HEXDIG [RFC4234] : ; variant of HEXDIG [RFC5234] :
; hexadecimal digit using uppercase A-F only ; hexadecimal digit using uppercase A-F only
; the rules below are from the Core Rules from [RFC4234] ; the rules below are from the Core Rules from [RFC5234]
BIT = "0" / "1" BIT = "0" / "1"
DQUOTE = %x22 ; " (Double Quote) DQUOTE = %x22 ; " (Double Quote)
DIGIT = %x30-39 ; 0-9 DIGIT = %x30-39 ; 0-9
; external references ; external references
; URI-reference: from [RFC3986] ; URI-reference: from [RFC3986]
skipping to change at page 176, line 41 skipping to change at page 176, line 41
[MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG- [MPEGAUDIO] International Standards Organization. "ISO 14496 MPEG-
4", Part 3 (Audio), 2001. 4", Part 3 (Audio), 2001.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, November 1996.
[DLS2] MIDI Manufacturers Association. "The MIDI Downloadable [DLS2] MIDI Manufacturers Association. "The MIDI Downloadable
Sounds Specification", v98.2, 1998. Sounds Specification", v98.2, 1998.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 5234, January 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol Norrman, "The Secure Real-time Transport Protocol
(SRTP)", RFC 3711, March 2004. (SRTP)", RFC 3711, March 2004.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
skipping to change at page 177, line 26 skipping to change at page 177, line 26
Schulzrinne, "Grouping of Media Lines in the Session Schulzrinne, "Grouping of Media Lines in the Session
Description Protocol (SDP)", RFC 3388, December 2002. Description Protocol (SDP)", RFC 3388, December 2002.
[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.
[RFC3555] Casner, S. and P. Hoschka, "MIME Type Registration of RTP [RFC4855] Casner, S., "MIME Type Registration of RTP
Payload Formats", RFC 3555, July 2003. 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
skipping to change at page 179, line 23 skipping to change at page 179, 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) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors retain contained in BCP 78, and except as set forth therein, the authors retain
all their rights. all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 181, line 5 skipping to change at page 181, line 5
copyrights, patents or patent applications, or other proprietary rights copyrights, patents or patent applications, or other proprietary rights
that may cover technology that may be required to implement this that may cover technology that may be required to implement this
standard. Please address the information to the IETF at ietf- standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
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-02.txt> Change Log for <draft-ietf-avt-rfc4695-bis-03.txt>
This I-D is a modified version of RFC 4695. For every error found to 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. 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 Below, we list the errors found in RFC 4695 that are most likely to
confuse implementors. The fixes to Appendix D ABNF errors listed confuse implementors. The fixes to Appendix D ABNF errors listed
below are presented without comments; see Appendix D to see the below are presented without comments; see Appendix D to see the
commented rule in context. The list below includes the fixes for all commented rule in context. The list below includes the fixes for all
normative errors; most fixes for other types of errors are not listed. normative errors; most fixes for other types of errors are not listed.
However, the I-D itself contains fixes for all known errors. However, the I-D itself contains fixes for all known errors.
-- --
03.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,
03.txt contains no changes from 02.txt
--
02.txt changes: 02.txt changes:
No errata has been reported for RFC 4695 in the past six months. No errata has been reported for RFC 4695 in the past six months.
Apart from updates in the document name and expiration dates, Apart from updates in the document name and expiration dates,
02.txt contains no changes from 01.txt 02.txt contains no changes from 01.txt
-- --
01.txt changes: 01.txt changes:
 End of changes. 15 change blocks. 
17 lines changed or deleted 25 lines changed or added

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