[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [AVT] RTP MIDI: I-D updates, Request for Last Call

On 29 Apr 2004, at 02:13, John Lazzaro wrote: 
        Sent off the updated versions of the RTP MIDI payload
format document (draft-ietf-avt-rtp-midi-format-04.txt) and
implementation guide (draft-ietf-avt-rtp-midi-guidelines-04.txt)
to internet-drafts at ietf.org today.  You can pick up a copy now
on the Berkeley mirror:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-rtp-midi.txt
http://www.cs.berkeley.edu/~lazzaro/sa/pubs/txt/current-guide.txt

	No normative changes in this release -- just a few editorial
clarifications, described in the document Change Logs.

I've worked my way through most of the payload format draft, and have a number of comments:

The IETF IPR rules have changed since these drafts were submitted. Could you please update the copyright and IPR boilerplate according to RFCs 3667 and 3668?

In Section 2.1, top of page 7, can you check that the parameter mentioned is "srate" rather than "rate"?

In Section 2.1, consider starting the second paragraph on page 7 "Timestamps of consecutive packets do not..."

In Section 2.2, 3rd paragraph on page 8, mentions that senders MAY transmit an RTP stream with missing or out-of-order packets in some circumstances. Doing this will disrupt RTCP statistics, so unless there's a pressing need to allow this, I suggest it is disallowed.

Section 3 lists the P bit in the header, but it's not defined until Section 3.2. It might be clearer if Section 3 mentioned the P bit, giving a forward pointer to its definition. Please also check the appendices for similar issues.

The "Checkpoint Packet Seqnum" is defined on page 19, but there is no mention of the required byte order. Please specify that this field is network byte order.

The SDP examples include spaces between the "a=rtpmap:" and "a=fmtp:" keywords and their parameters. White space is not permitted here, and the examples need to be updated to reflect this. Note also that all MIME parameters should be specified on a single "a=fmtp:" line, rather than on multiple lines.

The text refers to "fmtp parameters" throughout. The usual term is "MIME parameters".

Section 8 "Congestion Control" should reference the discussion in the RTP specification and (for example) the A/V profile. It's important to specify that, when using UDP, the sender should monitor packet loss to ensure that it competes approximately fairly with TCP.

In Section A.1, 2nd paragraph, maybe clarify that the reference is to a "previous" packet with sequence number C?

Appendix C defines a number of MIME parameters, which affect the operation of the system. It's not clear which parameters are mandatory to implement, which are optional, and which features are required for all implementations or optional. Could you consider adding a table to summarize this? I'm a little concerned that there'll be interoperability issues due to the large number of parameters and options, unless the draft is very clear on what is intended.

Does the ABNF in appendix D validate according to http://www.apps.ietf.org/abnf.html?

The security considerations section should reference the RTP specification and any applicable RTP profile (e.g. AVP, SRTP).

Finally, please read http://www.ietf.org/ID-Checklist.html and check that all the issues noted are addressed in the drafts.

	A new sfront release (first in 14 months ...) came out over
the weekend -- this release supports the MIDI payload format
defined in draft-ietf-avt-rtp-midi-format-04.txt.  Pick it up at:

http://www.cs.berkeley.edu/~lazzaro/sa/index.html

	I believe it is time to request Last Call for these documents.
Together, they are a bit over 150 pages -- and so, a review of
these documents entails a non-trivial time commitment.  Given
the commercial importance MIDI ring-tones have had in the
cellular industry, and the long-standing role MIDI has played
on stage and in the recording studio, I'm hoping at least one of
our 1000 AVT subscribers can justify spending the time to do the
review that will kick the documents into Last Call.  Thanks in
advance.

I'd like to see a review of the payload format by a MIDI expert, before we advance the draft. Understanding the recovery journal semantics requires a lot of MIDI-specific knowledge, and I'd like confirmation that makes sense (I don't doubt that it does, but I don't know enough about MIDI to validate it myself).

Cheers,
Colin


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt