Re: SEQ frames and MIME entity headers

james woodyatt <[email protected]> writes:
> 
> 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.

[...]

> 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?

I think this is a poor idea.  As far as I'm concerned, the data format
of a BEEP message should be beyond the abstraction barrier of the
things that the transport code need have knowledge of.  

I also agree that the scenario you describe, in which there are more
headers than the channel window buffer can hold, is a mess, and adds
unnecessary complexity.  You suggest that the sending peer could 
increase the channel window size if it wishes to send a long set
of headers, but BEEP does not currently define a mechanism by which
a sending peer can request an increase in the channel window size.

> 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.

How is this worse than an XML body of infinite length, say filled
with whitespace or comments?  

> Plus, it complicates the programming interface for application
> profiles to have to support pathologically long MIME entity headers,

You applications will often have to support pathologically long
entities, be they MIME headers or not.

--Jered