[AVT] Comments (1) on draft-ietf-avt-mwpp-midi-rtp-02.txt

[Dominique Fober <[e-mail]>]

Hi,

Some questions and comments on draft-ietf-avt-mwpp-midi-rtp-02.txt. 
In order to facilitate reading and discussion, I've split them in 2 messages: the first one (this one) is about the core draft and another one
(should follow) about the appendix.
Best,
----------------------------------------------
Dominique Fober               <[e-mail]>
----------------------------------------------
GRAME - Centre National de Creation Musicale -
9 rue du Garet  69001 Lyon France
tel:[phone] fax:[phone]
http://www.grame.fr/



>3. MIDI Command Section
...

>Other complete MIDI commands may appear between SysEx command
>segments, including verbatim MIDI SysEx commands (for pseudo-wire
>emulation applications, only System Realtime commands may appear between
>SysEx command segments).

I'm not convinced by the usefulness of interleaving MIDI commands into 
SysEx segments. First : what's the time status of such a MIDI command ?
I guess that its delta time is equal to the container SysEx delta time.
As MIDI prevents such interleaving, it means that such a situation shouldn't
be found in a common real-time context. But it may occur if the sender is 
mixing different streams and receiving a MIDI command while a SysEx 
transmission has been started. On receiver side there are 2 solutions to 
play such a stream: 
- waiting for the SysEx completion and playing the SysEx followed by
its possible interleaved commands: in this case interleaving is useless
- or playing the interleaved commands as soon as possible but then, doesn't
it result in a time ordering inversion ?
Another point is that on receiver side and without interleaving, a common
MIDI parser may be applied to the incoming stream otherwise, one have to 
design a more sophisticated parser.
But maybe you have in mind some other use that I don't see.

...

>Only SysEx commands that terminate with an F7 octet may be encoded in
>MWPP. To encode SysEx commands using the dropped F7 construction, insert
>an F7 into the MIDI stream before performing MWPP command encoding. A
>pseudo-wire emulation encoding MAY set the execution time of the MIDI
>command that terminated the original SysEx command to indicate a one-
>octet overlap. Pseudo-wire emulation transcoders MAY recognize the
>execution-time overlap as coding a dropped F7 in the original SysEx
>command, and reproduce the dropped construction on the physical MIDI
>layer.

The question is: how the execution time setting may indicate a one-octet
overlap ? (and how is it recognized by transcoders ?)


>4. The Recovery Journal
...
>If the A bit is set in the recovery journal header, the recovery journal
>is "empty", and contains no channel journals. If the A bit is clear, the
>channel journal list contains (TOTCHAN + 1) channel journals.

You may save the A bit if TOTCHAN (and not TOTCHAN + 1) indicates the number
of channel journals and TOTCHAN = 0 denotes an empty recovery journal.

Note about the R bit: in <draft-lazzaro-avt-mwpp-midi-nmp-00.txt> was a 
general mention about the R bit:
>All reserved bits in this memo are named R: reserved bits MUST be set to 
>zero by senders and ignored by receivers.
It has been removed with the corresponding paragraph and now, it's first
mentionned only in the appendix.


>5. Checkpoint Packet Policy

>(Editors note: MWPP as defined in this version of the memo provides
>resiliency for MIDI Channel commands only; upcoming iterations will add
>partial MIDI Systems resiliency. 

Isn't the TOC size (section 4) a little bit short if you plan to add
resiliency for non-channel messages ?

...

Another question is: shouldn't the sender behavior be more normative 
concerning the recovery journal setup according to the checkpoint packet 
sequence number. Actually, what is a sender supposed to do when it 
advances the sequence number ? is it allowed to drop datas which occured
prior to the checkpoint from the journal ? and in this case, 
how is a receiver informed of this policy ?


[Section removed from  <draft-lazzaro-avt-mwpp-midi-nmp-00.txt>]
>4. Sender Addendum: Guard Packets
I understand that guard packets policy is implementation dependant and
that normative recommendations has been removed. However, apart of the
resiliency goal mentionned in <draft-lazzaro-avt-mwpp-midi-nmp-00.txt>,
guard packets may also be used to ensure that the receiver may compensate 
its clock skew with a good acuracy. In this case, the receiver has to
receive packets at a minimum rate. 
Don't you think that it would be usefull to keep recommendations about 
guards packets at least within the appendix ?




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