Subject: Re: [AVT] WGLC on draft-ietf-avt-rfc4695-bis -comments

From: Roni Even <[email-masked]>
Date: Wed, 15 Dec 2010 22:23:32 +0200

Hi,

I reviewed the draft. Since this is an update to RFC4695 I assume that some
of the topics I encountered were discussed before like the ASC subtype name
which is not used as a regular RTP payload subtype.

My comments are on eth current document.

1.       The header is not correct and it also lacks a statement that it
obsolete RFC 4695. This is also true for the header and footer on each page.

2.       The abstract should be on the first page so it should be after the
title.

3.       There is some information that is not really needed in a payload
specification like paragraph 2 and 3 in the introduction but I think it can
stay since it was in RFC4695 and the motivation for having such information
is explained.

4.       I am not sure that the last paragraph of section 2 is correct. I
think that RTP is a session layer protocol. Anyhow I am not sure what is the
value of this paragraph.

5.      In section 2.1 " Timestamps of consecutive packets do not
necessarily increment at a fixed rate, because RTP MIDI packets are not
necessarily sent at a fixed rate.". Is this statement correct how do you
signal the rate. Also the timestamp is of the sampling time and not when it
is sent.

6.       In section 3 after figure 3 "If Z is 0, the Delta Time 0 field is
not present in the MIDI list, and the command coded in the MIDI Command 0
field has an implicit delta time of 0"  but it looks to me that figure 3 has
"1-4 octets long, or 0 octets if Z = 1" can you clarify?

7.       In the second paragraph after figure 3 what is the semantics of the
"z" field.

8.       In the last paragraph of section 6.1 " Thus, apart from providing a
1- to-many forward path and a many-to-1 reverse path, IETF protocols do not
need to provide any special support for MIDI multicast networking." I am not
clear what this sentence mean, which IETF protocols?

9.       In section 11 fourth paragraph " 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." I think you can
delete this sentence.

10.   I think that in general section 11 can say that this document does not
change any of the RFC4695 registrations so there is no real IANA action
needed except to point at this RFC instead of RFC 4695

11.   I suggest to make the change log as an appendix and discuss backward
interoperability issues or say that there are none.

Thanks

Roni Even

 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roni
Even
Sent: Tuesday, November 23, 2010 4:35 PM
To: [email-masked]
Cc: 'DRAGE, Keith (Keith)'; [email-masked]
Subject: [AVT] WGLC on draft-ietf-avt-rfc4695-bis

Hi,

I would like to start a working group last call on
http://tools.ietf.org/html/draft-ietf-avt-rfc4695-bis-08 

RTP Payload Format for MIDI

The WGLC will end on December 15th , 2010

Please review the draft and send comments to the list

This draft has been sitting for a couple of yea rs . Mos fixes  found by
implementers.

Page 180 of the draft list the changes.

Roni Even

AVT co-chair

  _____

---

From: John Lazzaro <[email-masked]>
Date: Sat, 18 Dec 2010 13:30:12 -0800

Hi Roni,

> I reviewed the draft.

Thanks, I appreciate it!  I just uploaded a new version of the I-D,
draft-ietf-avt-rfc4695-bis-09.txt, to address your concerns.  Below,
I go over those concerns point by point.

> 2. The abstract should be on the first page so it should be after the

Both are now fixed.  I followed the formatting that the 3016 bis uses.

> specification like paragraph 2 and 3 in the introduction but I think
> it can stay since it was in RFC4695 and the motivation for having such
> information is explained.

OK. No changes were made in response to this item.

> think that RTP is a session layer protocol. Anyhow I am not sure what
> is the value of this paragraph.

The new-to-networking music-software developers who reviewed the I-Ds
that preceded RFC 4695 were often confused because they believed that
RTP was a peer protocol to TCP and UDP, rather than being a protocol
that gets mapped to UDP or TCP.  The reader-friendly language of this
paragraph was crafted to clear up their misconceptions, and I believe
it should stay as is. I believe the phrase "session layer protocol"
would only cause confusion with the concept of "session management"
protocols such as SIP and RTCP, which are also new concepts for them.

Thus, no changes were made in response to this item.

> necessarily increment at a fixed rate, because RTP MIDI packets are
> not necessarily sent at a fixed rate.". Is this statement correct how
> do you signal the rate. Also the timestamp is of the sampling time and
> not when it is sent.

The bis text is correct. See Appendix C.4 to learn how the rtp_ptime
and rtp_maxptime may be used to signal rate.

A common application of RFC 4695 (described in Sections 4 and 6 of RFC
4696) uses rtp_ptime and rtp_maxptime values of 0 ms (this is
permitted by Appendix C.4). For this application domain, the sampling
time and the sending time are identical. I believe that the way to
introduce the RTP timestamp header semantics in a way that is clear to
those interested in the 0 ms application domain is the way it is
written in RFC 4695.  Thus, I believe the text should remain as it is
written, and so no changes were made in response to this item.

Note that the 0 ms mode is how Apple uses RTP MIDI in OS X and iOS.
Several independent parties have created implementations compatible
with the Apple implementation, aided by reading RFC 4695.  In the
Apple implementation, the use case is for two computers in the same
room, one of which is connected to a MIDI piano keyboard, the other of
which runs an audio music synthesis program which drives a speaker.
The musician hits a note on the keyboard, an RTP MIDI packet is sent
from one computer to the other, the second computer turns the received
MIDI into audio.  The end-to-end latency from note-press to audio out
has to be quite short for the system to work as a musical instrument,
and thus the unique RTP MIDI timestamp semantics you noted in your
comment is needed.  These decisions reached a consensus in AVT during
the development of the I-Ds that lead to RFC 4695's approval.

> not present in the MIDI list, and the command coded in the MIDI
> Command 0 field has an implicit delta time of 0" but it looks to me
> that figure 3 has "1-4 octets long, or 0 octets if Z = 1" can you
> clarify?

The text is correct and the figure is wrong. Thanks very much
for finding this error.  I checked with several of the implementors
of RFC 4695, and they report that their implementations follow the
text and not the figure (as did my reference implemenetation).

I fixed the figure (Z = 1 changes to Z = 0), and will also file an
errata for RFC 4695 on this issue.

> 7. In the second paragraph after figure 3 what is the semantics of the

The Z field only affects the semantics of Delta Time 0, and so the
answer to your question is "the Z field has no influence on the
semantics".  The use of MUST in this paragraph is intended to make
this point clear.  I experimented with adding an extra sentence in
this paragraph to emphasize the irrelevance of the Z bit, but I found
that the addition made the paragraph harder to understand. And so, I
believe the paragraph is best left in its original form, and thus no
changes were made in response to this item.

> 1- to-many forward path and a many-to-1 reverse path, IETF protocols
> do not need to provide any special support for MIDI multicast
> networking." I am not clear what this sentence mean, which IETF
> protocols?

In this case, "IETF protocols" is self-referential (i.e. RFC 4695).
There was some concern that we should add SDP parameters to notate
MIDI party-line multi-tasking.  This sentence is justification for
why it is not necessary to do so.  Therefore, no changes were made
in response to this item.

> 10. I think that in general section 11 can say that this document does
> not change any of the RFC4695 registrations so there is no real IANA
> action needed except to point at this RFC instead of RFC 4695

I replaced the entirety of section 11 with the paragraph:

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.

> 11. I suggest to make the change log as an appendix and discuss
> backward interoperability issues or say that there are none.

The change log became the new Appendix F, and interoperability issues
are now discussed as part of the change log.

Thanks again,

-- 
John Lazzaro
http://www.cs.berkeley.edu/~lazzaro
john [dot] lazzaro [at] gmail [dot] com