RTP Payload Format for MIDI
RFC 6295

[Ballot comment]
[RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

This reference needs to be Normative. No extra IETF LC is needed to make this change, as this RFC is already in the DownRef registry.


Because this is a -bis document, I am entering the following issues as Comment-level (as opposed to DISCUSS-level), however I would like to ask to serious consider fixing these as well:

D.  Parameter Syntax Definitions

  mime-type          = "audio" / "application"
  mime-subtype      = token
                      ;
                      ; See Appendix C.6.2 for registration
                      ; requirements for rinit type/subtypes.

The mime-subtype definition should be pointing to the definition in RFC 4288, Section 4.2:

4.2.  Naming Requirements

      type-name = reg-name
      subtype-name = reg-name

      reg-name = 1*127reg-name-chars
      reg-name-chars = ALPHA / DIGIT / "!" /
                      "#" / "$" / "&" / "." /
                      "+" / "-" / "^" / "_"


In RFC 4695:

11.3.  asc Media Type Registration

  Media type name:

      audio

  Subtype name:

      asc

[...]

  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.

And there is no registered file extension? I think this is a serious omission
for something which can be stored in a file.

[Ballot discuss]
My apologies for spending so little time to review this document, but the following things caught my attention:

1).
11.  IANA Considerations

This document does not change any of the registrations in RFC 4695.
Therefore, this document does not require any IANA actions, apart from
updating the references to RFC 4695 to point to this document.

I don't think this is Ok. Please correct me if I am wrong, but this document has updated ABNF for various parameters specified in RFC 4695. This clearly updates the MIME type registration.

I think the right thing to do here is to keep the MIME type registration from RFC 4695 in this document.

2). Somewhat related to #1: RFC 4695 registers audio/mpeg4-generic MIME type.

audio/mpeg4-generic MIME type registration on
doesn't point to
RFC 4695 or this draft. This seems to be an omission.
And again, correct me if I am wrong, but it looks like the MIME type registration is implicitly updated due to changes to the ABNF of various MIME type parameters.

[Ballot comment]
In the IANA Considerations Section:

> This document does not change any of the registrations in RFC 4695.
Therefore, this document does not require any IANA actions, apart from
updating the references to RFC 4695 to point to this document.

It looks to me that both documents (this one and RFC 4695) need to be referenced in the IANA pages. The reason is that while this document obsolets RFC 4695 it does not carry the text that refers to the creation of the registries.

[Ballot comment]
Section 1.2

  In this document, the packet bitfields that share a common name often
  have identical semantics.

This left me wondering how I find the cases where they have common names
but different semantics.

[Ballot discuss]
An easy Discuss that can be resolved with just a few words.

idnits points out...
  -- The draft header indicates that this document obsoletes RFC4695,
    but the abstract doesn't seem to mention this, which it should.

It should also be discussed in the Introduction.

I would also say that Appendix F (changes from 4695) should be pulled
back into the body of the document, but this is not important.

(See also the Comment from Russ Housley)

[Ballot comment]
#1) Since this is a bis document, I presume it's been used for a while.  Maybe the tense should change in intro to reflect this? Likewise, the original premise of 4965 was to allow musicians to be in different locations but still jam together - did it work?

[Ballot discuss]
#1) C.6.3 contains the following text:

  The string MUST
  specify either a HyperText Transport Protocol URI (HTTP, [RFC2616]) or
  an HTTP over TLS URI (HTTPS, [RFC2818]).

Can 2616

[Ballot comment]
#1) Since this is a bis document, I presume it's been used for a while.  Maybe the tense should change in intro to reflect this? Likewise, the original premise of 4965 was to allow musicians to be in different locations but still jam together - did it work?

#2)

IANA understands that, upon approval of this document, there is a single
IANA Action that must be completed.

In the MIME Media Type Sub-Parameter Registries located at:

http://www.iana.org/assignments/media-type-sub-parameters

the registrations with references of RFC 4695 will be updated to a
reference pointing to the newly approved document. In addition, the
references in the IANA Matrix will be updated as well.

IANA understands that this is the only action required upon approval of
this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (RTP Payload Format for MIDI) to Proposed Standard


The IESG has received a request from the Audio/Video Transport Payloads
WG (payload) to consider the following document:
- 'RTP Payload Format for MIDI'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-02-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-payload-rfc4695-bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-payload-rfc4695-bis/

**UPDATED**

(1.a) Who is the Document Shepherd for this document? Has the
        Document Shepherd personally reviewed this version of the
        document and, in particular, does he or she believe this
        version is ready for forwarding to the IESG for publication?

The document shepherd is Roni Even. I have reviewed the document, and
believe it is ready for publication.

  (1.b) Has the document had adequate review both from key WG members
        and from key non-WG members? Does the Document Shepherd have
        any concerns about the depth or breadth of the reviews that
        have been performed? 

The document went through a Working Group last call and people had enough
time to review it. Considering that this document is an update to an
existing RFC addressing errata found in implementation the document Shepherd
feels that the review was satisfactory. 

  (1.c) Does the Document Shepherd have concerns that the document
        needs more review from a particular or broader perspective,
        e.g., security, operational complexity, someone familiar with
        AAA, internationalization or XML?

No concerns

  (1.d) Does the Document Shepherd have any specific concerns or
        issues with this document that the Responsible Area Director
        and/or the IESG should be aware of? For example, perhaps he
        or she is uncomfortable with certain parts of the document, or
        has concerns whether there really is a need for it. In any
        event, if the WG has discussed those issues and has indicated
        that it still wishes to advance the document, detail those
        concerns here. Has an IPR disclosure related to this document
        been filed? If so, please include a reference to the
        disclosure and summarize the WG discussion and conclusion on
        this issue.

No Concerns

  (1.e) How solid is the WG consensus behind this document? Does it
        represent the strong concurrence of a few individuals, with
        others being silent, or does the WG as a whole understand and
        agree with it?

This is an update to an existing payload specification. It has consensus of
a few individual who reviewed the draft.

  (1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent? If so, please summarise the areas of conflict in
        separate email messages to the Responsible Area Director. (It
        should be in a separate email because this questionnaire is
        entered into the ID Tracker.)

No

  (1.g) Has the Document Shepherd personally verified that the
        document satisfies all ID nits?(See the Checklist and idnits
        ).Boilerplate checks are
        not enough; this check needs to be thorough. Has the document
        met all formal review criteria it needs to, such as the MIB
        Doctor, media type and URI type reviews?

The idnits tool report some comments and one warning which are OK.
The document does not change the current media subtype registration so there
was no need to review it by .

  (1.h) Has the document split its references into normative and
        informative? Are there normative references to documents that
        are not ready for advancement or are otherwise in an unclear
        state? If such normative references exist, what is the
        strategy for their completion? Are there normative references
        that are downward references, as described in [RFC3967]? If
        so, list these downward references to support the Area
        Director in the Last Call procedure for them [RFC3967].

References are split

  (1.i) Has the Document Shepherd verified that the document IANA
        consideration section exists and is consistent with the body
        of the document? If the document specifies protocol
        extensions, are reservations requested in appropriate IANA
        registries? Are the IANA registries clearly identified? If
        the document creates a new registry, does it define the
        proposed initial contents of the registry and an allocation
        procedure for future registrations? Does it suggest a
        reasonable name for the new registry? See [RFC5226]. If the
        document describes an Expert Review process has Shepherd
        conferred with the Responsible Area Director so that the IESG
        can appoint the needed Expert during the IESG Evaluation?

The IANA consideration section exists and is inline with the body of the
document.

  (1.j) Has the Document Shepherd verified that sections of the
        document that are written in a formal language, such as XML
        code, BNF rules, MIB definitions, etc., validate correctly in
        an automated checker?

Appendix D define the syntax for the RTP MIDI media type parameters in
Augmented Backus-Naur Form. The ABNF was tested using the BAP tool and
returned no errors

  (1.k) The IESG approval announcement includes a Document
        Announcement Write-Up. Please provide such a Document
        Announcement Write-Up? Recent examples can be found in the
        "Action" announcements for approved documents. The approval
        announcement contains the following sections:

    Technical Summary
        Relevant content can frequently be found in the abstract
        and/or introduction of the document. If not, this may be
        an indication that there are deficiencies in the abstract
        or introduction.

"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."

    Working Group Summary
        Was there anything in WG process that is worth noting? For
        example, was there controversy about particular points or
        were there decisions where the consensus was particularly
        rough?

The first version of the document came out in 2007 and the document was
kept alive in order to capture any errata that will be discovered. The
authors now feel that the implementations are stable and that it is time
to publish the update.

    Document Quality
        Are there existing implementations of the protocol? Have a
        significant number of vendors indicated their plan to
        implement the specification? Are there any reviewers that
        merit special mention as having done a thorough review,
        e.g., one that resulted in important changes or a
        conclusion that the document had no substantive issues? If
        there was a MIB Doctor, Media Type or other expert review,
        what was its course (briefly)? In the case of a Media Type
        review, on what date was the request posted?

There are existing implementations and this update for RFC 4695 is based
on issues that were found by implementers. 

(1.a) Who is the Document Shepherd for this document? Has the

Document Shepherd personally reviewed this version of the

document and, in particular, does he or she believe this

version is ready for forwarding to the IESG for publication?



The document shepherd is Roni Even. I have reviewed the document, and
believe it is ready for publication.



(1.b) Has the document had adequate review both from key WG members

and from key non-WG members? Does the Document Shepherd have

any concerns about the depth or breadth of the reviews that

have been performed?



The document went through a Working Group last call and people had enough
time to review it. Considering that this document is an update to an
existing RFC addressing errata found in implementation the document Shepherd
feels that the review was satisfactory.



(1.c) Does the Document Shepherd have concerns that the document

needs more review from a particular or broader perspective,

e.g., security, operational complexity, someone familiar with

AAA, internationalization or XML?



No concerns





(1.d) Does the Document Shepherd have any specific concerns or

issues with this document that the Responsible Area Director

and/or the IESG should be aware of? For example, perhaps he

or she is uncomfortable with certain parts of the document, or

has concerns whether there really is a need for it. In any

event, if the WG has discussed those issues and has indicated

that it still wishes to advance the document, detail those

concerns here. Has an IPR disclosure related to this document

been filed? If so, please include a reference to the

disclosure and summarize the WG discussion and conclusion on

this issue.



No Concerns



(1.e) How solid is the WG consensus behind this document? Does it

represent the strong concurrence of a few individuals, with

others being silent, or does the WG as a whole understand and

agree with it?



This is an update to an existing payload specification. It has consensus of
a few individual who reviewed the draft.



(1.f) Has anyone threatened an appeal or otherwise indicated extreme

discontent? If so, please summarise the areas of conflict in

separate email messages to the Responsible Area Director. (It

should be in a separate email because this questionnaire is

entered into the ID Tracker.)



No

(1.g) Has the Document Shepherd personally verified that the

document satisfies all ID nits?(See the Checklist and idnits
).Boilerplate checks are not enough;
this check needs to be thorough. Has the document met all formal review
criteria it needs to, such as the MIB Doctor, media type and URI type
reviews?



The idnits tool resport some comments and one warning which are OK.

The document does not change the current media subtype registration so there
was no need to review it.



(1.h) Has the document split its references into normative and

informative? Are there normative references to documents that

are not ready for advancement or are otherwise in an unclear

state? If such normative references exist, what is the

strategy for their completion? Are there normative references

that are downward references, as described in [RFC3967]? If

so, list these downward references to support the Area

Director in the Last Call procedure for them [RFC3967].





References are split



(1.i) Has the Document Shepherd verified that the document IANA

consideration section exists and is consistent with the body

of the document? If the document specifies protocol

extensions, are reservations requested in appropriate IANA

registries? Are the IANA registries clearly identified? If

the document creates a new registry, does it define the

proposed initial contents of the registry and an allocation

procedure for future registrations? Does it suggest a

reasonable name for the new registry? See [RFC5226]. If the

document describes an Expert Review process has Shepherd

conferred with the Responsible Area Director so that the IESG

can appoint the needed Expert during the IESG Evaluation?





The IANA consideration section exists and is inline with the body of the
document.



(1.j) Has the Document Shepherd verified that sections of the

document that are written in a formal language, such as XML

code, BNF rules, MIB definitions, etc., validate correctly in

an automated checker?



No such sections



(1.k) The IESG approval announcement includes a Document

Announcement Write-Up. Please provide such a Document

Announcement Write-Up? Recent examples can be found in the

"Action" announcements for approved documents. The approval

announcement contains the following sections:

Technical Summary

Relevant content can frequently be found in the abstract

and/or introduction of the document. If not, this may be

an indication that there are deficiencies in the abstract

or introduction.



"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."



Working Group Summary

Was there anything in WG process that is worth noting? For

example, was there controversy about particular points or

were there decisions where the consensus was particularly

rough?



The first version of the document came out in 2007 and the document was kept
alive in order to capture any errata that will be discovered. The authors
now feel that the implementations are stable and that it is time to publish
the update.







Document Quality

Are there existing implementations of the protocol? Have a

significant number of vendors indicated their plan to

implement the specification? Are there any reviewers that

merit special mention as having done a thorough review,

e.g., one that resulted in important changes or a

conclusion that the document had no substantive issues? If

there was a MIB Doctor, Media Type or other expert review,

what was its course (briefly)? In the case of a Media Type

review, on what date was the request posted?



There are existing implementations and this update for RFC 4695 is based on
issues that were found by implementers.