[BXXPwg] Extensible trailers

Greg Hudson ghudson@MIT.EDU
Wed, 13 Sep 2000 19:44:05 -0400


> err, the proposal i forwarded doesn't have the properties you suggest.

Okay, one of us is confused.  The two properties I suggested are:

	1. The trailer can't as accurately determine whether the
	   byte count in the header is wrong.  Consider:

		MSG 1 1 . 0 68
		Content-Type: text/plain

		Now is the time for all men to come
		to the aid of their country
		END

	   where "72" (which gets you to "aid") should have been "94"
	   (which gets you to "END").  Because "to the aid of their
	   country" could be part of an extensible trailer, the
	   implementation can't detect this error.

	   If the count in the header is too large, things get even
	   worse: the entire next frame could be silently ignored, as
	   long as the contents look like atoms or quoted strings
	   separated by spaces.

	2. It is harder to locate the end of a frame when reading a
	   BXXP protocol trace by hand.  Actually, I should have said
	   it's harder to locate the end of a frame's payload.
	   Consider:

		MSG 1 1 . 0 77
		Content-Type: application/i-process-a-list-of-word-pairs

		foo bar
		baz quux
		MAC 88e77
		END

	   Only the byte count of 77 will tell you that "MAC 88e77" is
	   part of the trailer and not part of the payload.

So, how am I wrong here?

> the reason the extra information goes in the trailer rather than the
> header is probably a matter of taste, although there probably is
> something to be said for having optional stuff show up at the end
> rather than the beginning...

Can you name any precedent for a payload-oriented protocol putting
extension material after the payload?  The ones I can think of (HTTP
and SMTP) certainly don't do that.