[AVT] MWPP: The Atlanta Status Report

[John Lazzaro <[e-mail]>]

Hi everyone,

	I won't be in Atlanta next week, but Colin Perkins will be
presenting a few slides on MWPP progress (thanks Colin!). I just sent
the slides along to him, and so I thought I post I textual version of
the presentation here, for folks who won't be in Atlanta ...

						--john lazzaro

---

Part I: Progress Since Yokohama
-------------------------------

The MWPP project now has two I-Ds:

        draft-ietf-avt-mwpp-midi-rtp-05.txt 
        draft-lazzaro-avt-mwpp-coding-guidelines-00.txt

The normative document, draft-ietf-avt-mwpp-midi-rtp, has seen one
major revision since Yokohama (-05.txt, released in late
September). This revision includes extensive changes, to address
concerns from many folks within and outside of the WG. So far, the
comments on -05.txt have been addressing minor points -- hopefully a
sign that the document changes are acceptable to everyone.

The new document, draft-lazzaro-avt-mwpp-coding-guidelines, is an
informative memo that offers guidelines for using MWPP in musical
applications. The main body of the text takes one application of MWPP
-- interactive musical performance between two players over a WAN --
and does a high-level code review of the application. The Appendices
covers special topics: content-streaming, MWPP w/o RTCP, MWPP over
TCP, etc.

The draft-lazzaro-avt-mwpp-coding-guidelines-00.txt has 6 of 8 main
text sections complete (introduction, session management, and sender
design). Left to do are two sections on receiver design, and 5
Appendices.

Part II: The Road Ahead
-----------------------

By San Francisco (March 2003), the (optimistic) goal is to complete
both documents, so that they are ready for Last Call. Here is the
current roadmap for getting there ...

The draft-lazzaro-avt-mwpp-coding-guidelines development path is
straight-forward: the next release should be a complete document, and
should reflect the initial comments we've received on -00.txt.
Subsequent drafts will focus on bugfixes and editorial work.

As expected, the draft-lazzaro-avt-mwpp-coding-guidelines writing
process has had the side effect of expanding the remaining open issues
on the normative draft-ietf-avt-mwpp-midi-rtp-05.txt document. At this
point, there are about 20 open issues: most are minor but a few are
not.

Once a complete draft-lazzaro-avt-mwpp-coding-guidelines version is
released, the focus shifts to completing draft-ietf-avt-mwpp-midi-rtp.
We see it happening in two steps:

   1. Release a -06.txt, whose change log describes each open 
      issue, and whose main text describes one possible resolution
      to the open issue.

   2. Some of these resolutions may be controversial. These will
      be discussed on the list, and hopefully consensus will happen.

   3. Release a -07.txt, that reflects the consensus, and which 
      may be a candidate for Last Call.


Part III: In the Background
---------------------------

Apart from document work, several other items of note:

-- Before the documents described above make to last call, the MWPP
reference code platform (sfront) will be updated, to reality-test
changes made to the packetization over the past year. This coding
probably starts happening in earnest during the -06.txt discussion
period.

-- We've been contacted by representatives (Chris Grigg, and more
recently Charlie Richmond) of the MIDI Manufacturers Association (MMA)
who hold change control for MIDI. A few of the 20 remaining open
issues reflects suggestions that have come out of those talks, and I
expect more to be added.

-- A possible IEEE working group (whose early members include our own
AVT WG participant Phil Kerr) is in formation, to look at direct
transport of MIDI over Ethernet. Phil asked me to join to help ensure
MWPP compatibility. As preparation for this task, I had a question for
the AVT folks:

       Are there standards for using RTP, SDP,  RTSP, SIP 
      ``direct to Ethernet'' without IP? 

I doubt this would be an IETF standard, but maybe some other standards
body has done work in this area ... probably in a domain where (1)
Ethernet is used as an isolated LAN, (2) clients are so thin that
there is no secondary use for the IP stack, and (3) the cost of
supporting the IP stack (ROM, bandwidth) is not tenable. Intercoms, TV
distribution, etc.

Please let me know ... at a minimum, I would think an
mmusic-over-Ethernet sort of standard would need new SDP syntax for
Ethernet addresses, and similar additions to whatever session
management tool is chosen. The actual placement of RTP packets into
Etherframes would be the easy part.

---

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt