Subject: [AVT] MWPP status report for IETF53

From: John Lazzaro <[email-masked]>
Date: Tue, 5 Mar 2002 15:09:04 -0800

Hi everyone,

The latest revision of MWPP is out:

>        Title           : The MIDI Wire Protocol Packetization (MWPP)
>        Author(s)       : J. Lazzaro, J. Wawrzynek
>        Filename        : draft-ietf-avt-mwpp-midi-rtp-02.txt
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-mwpp-midi-rtp-02.txt

New items include resiliency support for all MIDI Control Change
controllers (including RPN and NRPN), reset semantics for the recovery
journal system, and clarified delta-time semantics for pseudo-wire
emulation.

Unfortunately, I'm not going to be making the trip to Minneapolis,
below is the status report I would have presented ... comments welcome.

---

In Salt Lake, audience concerns were summed up as two questions:

Q1: What is normative and what is not?
Q2: What is MPEG-specific and what is not?

The versions of draft-ietf-avt-mwpp-midi-rtp released since Salt Lake
provide these answers:

Q1: What is normative and what is not?

A1: The format of the bits on wire, and the optional adherence to
    a sending policy that guarantees "graceful recovery" from packet
    loss, are the essential normative parts of MWPP -- these
    elements remain from the document presented at Salt Lake.

    The rest of the Salt Lake document -- most notably, the detailed
    sending and receiving algorithms -- do not need to be normative.
    These were stripped out of the draft-ietf-avt-mwpp-midi-rtp series.

Q2: What is MPEG-specific and what is not?

A2: MPEG's requirement for mpeg4-generic support is the only 
    MPEG-specific text left in draft-ietf-avt-mwpp-midi-rtp.
    The MPEG 4 Structured Audio document is no longer a normative 
    reference.

After releasing the first post-Salt-Lake document, developers from
several applications areas contacted me, who thought an IETF-approved
MIDI protocol would be potentially interesting for:

  *  MIDI pseudo-wire emulation, to augment MIDI cables with Cat 5 on
     stage or in a studio.

  *  Resiliently streaming standard MIDI files, rather than the 
     current practice of downloading the whole performance first.

But MWPP was only a starting point, and needed additional functionality
to work in these contexts. Some of these features were added into
draft-ietf-avt-mwpp-midi-rtp versions, including:

  *  A payload format that can carry many commands per packet, with
     a delta time system suitable for use in both pseudo-wire emulation
     and streaming MIDI file application domains.

  *  A payload section that can (non-resiliently) code the entire MIDI
     wire protocol, including support for embedded System Realtime 
     commands, arbitrarily-large System Exclusive commands, and 
     System Exclusive commands that code information in the relative
     timing of internal data octets.

  *  Resiliency support for all 128 MIDI Control Change numbers, 
     including the MIDI RPN and NRPN systems, and semantics for
     the entire resiliency system in the case of MIDI reset 
     events.

The main focus going forward is to complete the list of additions MWPP
needs to be a general MIDI transport. Work items include:

  *  Resiliency support for all MIDI System commands (including MIDI
     System Exclusive commands) where it makes sense to do so -- i.e.
     commands sufficiently short and real-time oriented that the 
     recovery journal mechanism makes sense.

  *  For bulk-data MIDI Systems commands, where the recovery
     journal mechanisms are not appropriate, define an alternative
     mechanism (as simple as "protect messages X Y and Z by other means",
     or perhaps something more detailed).

-------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt