Subject: [AVT] RTP MIDI I-Ds updated to -03.txt

From: "John Lazzaro" <[email-masked]>
Date: Thu, 15 Apr 2004 17:04:22 -0700

Hi everyone,

         Just sent -03.txt versions of the RTP MIDI I-Ds
off to [email-masked], you can download them
now from 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

         The Change Log is short so I'll post it at the end of
this message.  These changes offer tools for senders
who wish to transmit short SysEx commands with low
latency, but whose SDP does not contract it to send
longer SysEx commands over the stream (a SysEx
command can be a few bytes or a few MBytes, with
no way for a transcoding sender to tell upfront).

	I believe I've received comments back from most of
the people who were planning to read the I-Ds pre-Last-Call,
so I'll wait a week or two for any last-minute feedback, and
if there are no surprises it may be time to request Last Call,
on these -03.txt I-Ds or a cosmetic -04.txt revision.

----

M.  Change Log for <draft-ietf-avt-rtp-midi-format-03.txt>

The changes below reflect comments on the candidate Last Call documents.

   o  In Section 3.2, text describing the P bit has been
      rewritten for clarity.

   o  In Section 3.2, the "prohibition" against inserting
      non-System-Realtime commands between SysEx command
      sections has become a "default behavior" that can
      be overridden with a fmtp parameter (described below).
      This change supports UDP implementations that wish
      to transfer a large bulk SysEx command in an incremental
      fashion, without "stalling" the transmission of timely
      commands.  To do such a transfer, a sender sends a
      few SysEx fragments (which are protected by a recovery
      journal Chapter X "list" entry), and awaits normally-timed
      RTCP feedback that indicates all receivers has seen the
      fragments.  The sender then sends the next few fragments
      in the same way, until the entire SysEx command is sent.

   o  In Figure 5 of Section 3.2, the "cancel" sublist has
      been added to the legal types of SysEx command segments.
      This feature lets senders cancel the transmission of SysEx
      commands that are in progress, as described in new text
      in Section 3.2.  Command cancellation is permitted by default;
      an fmtp parameter may be used to prohibit the use of
      cancellation in a stream.

   o  In Appendix A.1, the definition of finished/unfinished
      commands has been changed to include the cancel sublist.

   o  Chapter X of the System Journal (Appendix B.5) has been
      modified to reflect the Section 3.2 changes described above.
      The DATA field can be configured to protect a sliding window
      of SysEx data octets, so that a long SysEx command can be
      sent in chunks without expanding Chapter X; the FIRST field
      configures the sliding window.  In addition, the log can be
      tagged as protecting an unfinished, normally finished,
      cancelled, or "dropped F7 finished" command.

   o  In the fmtp parameter definitions for the journalling system,
      (Appendix C.1.3), chapter and field lists for Chapter X have been
      added, so that session descriptions can specify (1) the use
      of the cancellation feature, (2) permission for arbitrary
      commands to occur between SysEx segments, and (3) the size of
      SysEx commands.  The ABNF of fmtp parameters (Appendix D) has
      been updated to reflect these changes.

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

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt