RE: RFC3080 MSG/RPY Window

Thanks to all for helping me understand and your patience. I think I
finally understood. I am just summing it up in this mail so that it can
a) proove if I really understood ;) and b) (if I did) serve as a
reference for others with the same question.

There are two advancing "message ids" in BEEP. One is the seqno, the
other is the msgno. 

Msgno is used at the application layer to correlate requests and
responses. A peer may issue many MSGs without necessarily receiving
RPYs, but the remote peer MUST send RPYs in the same sequence that it
received MSGs for. This is detailled under  "Asynchrony" in RFC3080,
2.6. 

Msgno is NOT intended to be used for flow control. Hence, there is no
and must no window be defined for it.

In contrast, seqno is the one used for actual flow control. Windowing is
defined in RFC3081 and carried out via SEQ frames.

So if I implement a BEEP-based server AND I need to limit the amount of
data that an application sends to me, I do not do this via MSG/RPY but
via SEQ only. So it is vital that a robust server design includes some
type of communication of the upper app layers with the lower 3081 layers
so that the later will receive feedback from the upper layers when it is
time to stop sending SEQs. The good thing about this is that flow
control follows a single paradigm, no matter if MSG/RPY or MSG/ANS
semantics are used.

I hope this understanding is right now. I will implement it this way.
Thanks again for your patience. You saved the world at least one partial
incompliant implementation ;)

Rainer