SEQs after channel close request?

Here we go again. :-)

This is similar to a complaint I had last year regarding
synchronization for TLS negotation, where I was shouted down for
constructing overly obscure scenarios.  This is less obscure, and
actually a problem I'm running into, but I'm not sure how to best fix.

While adding some functionality to PermaBEEP, we encountered a bug we
hadn't noticed before.  PermaBEEP will not send SEQ frames for a
channel once it has processed a locally-initiated request to close for
that channel.

It doesn't want to generate any further outbound traffic on the
channel after the close request, because as soon as the remote side
accepts, the remote side considers the channel to be closed.  Once
the remote peer has processed the close, if it saw a SEQ for the
channel in response to it's 'ok' response, it would terminate the
connection as per RFC 3081, 3.1.3:

   When a SEQ frame is received, if any of the channel number,
   acknowledgement number, or window size cannot be determined or is
   invalid, then the BEEP session is terminated without generating a
   response, and it is recommended that a diagnostic entry be logged.

(The channel would be closed and thus invalid.)

So, the local peer isn't going to be sending any new MSGs after it's
made a close request, however RFC 3080, 2.3.1.3:

   NOTE WELL: until a positive reply to the request to close the channel
   is received, the BEEP peer must be prepared to process any "MSG"
   messages that it receives on that channel.

This means that once the local peer has sent a close, it must be
prepared to process and respond to additional MSGs from the remote
peer, and respond to them (with RPY, ANS, or ERR frames).

Sending these frames isn't a problem because the remote peer isn't
going to accept the close until after it's received complete replies
to its outstanding MSGs, so those RPY, ANS, and ERR frames won't ever
be received on a channel that the remote peer believes is closed.


HOWEVER, because the local peer must still be prepared to handle
incoming MSGs after it has sent a close request, the local peer MUST
continue sending SEQs or else the channel will stall as the incoming
MSG data is not acknowledged.  But, the local client has know way of
knowing when the remote peer is done sending MSGs and has processed
and accepted the close request, so may send a SEQ after the remote
peer believes the channel is closed.


Any ideas how to resolve this?  Two thoughts I've had:
  - Do not consider SEQ frames for a recently closed channel to be
    an error. (This requires some definition of 'recently closed'.)

  - On the local peer, after sending a close request, the last frame
    sent on a channel must not be a SEQ frame.  If we are receiving
    incoming MSGs then we can happily send SEQs until we have sent the
    final frame of the response for all known incoming MSGs.

I think the latter item there will work but, well, it seems overly
complicated.  What have other implementors done?

--Jered