SEQ frames and MIME entity headers

everyone--

Another minor thing that might be helpful to carry around until the IETF 
decides to revise RFC 3080 and/or RFC 3081:

I think BEEP peers should not send SEQ frames to acknowledge processing 
of incomplete MIME entity headers.  It would be better, to my mind, if 
BEEP peers were required to buffer the entire MIME entity header of a 
message before sending a SEQ frame to acknowledge it.

As I read RFC 3080 and 3081, BEEP peers are *permitted* to do this, but 
I can't think of a good reason why an application should expect that its 
BEEP core framework be able to present it with an incomplete entity 
header.  If your application *really* wants to receive a 
Content-Description field that can potentially be larger than the RFC 
3081 window for your channel, then it seems to me it can enlarge the 
window.

One of the reasons I bring this up: if I *do* send SEQ frames 
acknowledging incomplete MIME entity headers, then I have a problem when 
a malicious peer sends an initial greeting message with a 
Content-Description field of infinite length.  Plus, it complicates the 
programming interface for application profiles to have to support 
pathologically long MIME entity headers, and I'd rather just place the 
onus on the application to make sure all its headers fit through the 
transport mapping channel window.

Anyway, this seems like another one of those interoperability "corner 
case" issues that we should be tracking at this stage of the game.  
Would anyone care to add a comment to this?


--
j h woodyatt <[email protected]>