Re: SEQ frames and MIME entity headers
james woodyatt <jhw <at> wetware.com>
2002-06-06 18:23:37 GMT
On Thursday, June 6, 2002, at 05:57 AM, Jered Floyd wrote:
> james woodyatt <jhw <at> wetware.com> 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.
> 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.
That's true, but it doesn't have to. Applications that depend on that
feature can define mechanisms in their profiles for doing that. The
core profiles don't have any such mechanism, but then-- they don't need
to send pathologically long entity headers, do they?
>> 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?
All BEEP messages have entity headers. If an application wants to
process entity bodies incrementally and still prevent peers from being