[AVT] RE: RTP MIDI I-D updates ...

[lazzaro <lazzaro at eecs.berkeley.edu>]

On Sun, 24 Apr 2005 21:40:18 -0700 John Lazzaro wrote:
>         Just sent off RTP MIDI I-D updates
> to internet-drafts, you can download them
> now from the Berkeley mirror site:
>
> 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
>
>         Until May 15th, I'll be busy wrapping up
> the course I'm teaching this semester [...]

Teaching responsibilities ended a few days early.
So, if anyone has comments they've been holding
back sending to the list, now is a good time to send.

A good first step might be to classify which of the
responses for the 43 issues are considered resolved
and which ones are contentious.  I could then release
a document with a more manageable change log, that
listed the still-open issues.  This could also let me slip
in some errata that implementors have passed along
in the past few weeks ...

Also, one note from my earlier posting:

>         C.6.2 is interesting because I did my best
> to push RTSP as hard as I could to handle the
> full range of stage and studio products. In the process,
> I basically had to bend RTSP until it (almost) broke,
> and I still didn't quite get all the semantics I need
> to get the functionality pro audio folks will expect.
> See C.6.2 for details; for those short on time, read the
> preamble, then skip to the examples in C.6.2.3.
>
>         There are many paths possible on this issue.
> Ideally, there's a way to keep the stage and studio
> material in the RTP MIDI I-Ds, use RTSP as is, and
> fully solve the problem.  But maybe that's not possible.
> If so, we'll have to think outside the box.

I'm starting to believe that the right thing to do is to
accept that the IETF has mature session management
protocols and frameworks that are a good match to the
VoIP-like Network Musical Performance application
for RTP MIDI (namely, SIP) and for content-streaming
RTP MIDI work (namely, RTSP).

But, getting a good fit for the "stage and studio" applications
from an IETF session management protocol (RTSP, as I
tried to do in C.6.2, or SIP, which I have sketched out
informally in the past) is going to take real work that
is more appropriately done somewhere else than AVT.

So, it may be wise to limit the scope of the I-Ds to cover
the two mature applications, and limit references to
"stage and studio" to the introduction, where we would
note that the protocol was designed to be useful in
those domains, but that the I-D focuses on applications
for which the upper layers of the IETF stack is ready to go.

I think this particularly makes sense because many
stage and studio devices (particularly video devices)
won't be using MIDI at all, but yet will face the same
issues that the examples in C.6.2 do.

One could imagine reworking C.6.2 to be less MIDI specific,
and spinning it off into an MMUSIC document ... or, one could
imagine leaving session management for stage and studio to
a standards organization that specializes in the pro world,
rather than leaving it in the IETF ...

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


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