[BXXPwg] Extensible trailers

Marshall Rose mrose+mtr.netnews@dbc.mtview.ca.us
Fri, 15 Sep 2000 22:25:29 -0700


greg - the confusion lies in the use of the phrase "as accurately".

specifically, i can come up with lots of examples in which an erroneous
octet count can still be undetected regardless of whether extensions are
placed at the beginning, the end, or are simply absent. for example, all i
need to do is to include "END" CRLF in the payload and have an unfortunately
wrong octet count. so, the argument could be simplified to: are we more
likely to see "END" CRLF or <directive>'s in the payload of frames that have
an erroneous octet count? hopefully you will agree that this isn't a very
interesting question.

i will admit that your proposal

> trailer = END CR LF *(directive CR LF) CR LF

has an advantage over the original proposal

> trailer = *(directive CR LF) "END" CR LF

in that your proposal always has a fixed string at both the beginning and
end of the trailer, with a modest additional cost.


things can probably be done more "accurately" if we used dot-stuffing
instead of octet-counting. however, that was rejected early on due to
performance considerations.

a better alternative is to include a checksum that is run over the payload
(and put that in the trailer). if the octet count is off, but the payload is
formed in such a way as to "fool" the parser, then the error can be caught
using the checksum.


finally, in terms of:

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

i'm not sure what a "payload-oriented" protocol is, although i suspect the
term is redundant. regardless, protocols aren't something that were
discovered within the last few years, and while HTTP and SMTP certainly get
a lot of usage and are prototypical of many things, there are other
interesting examples. for amusement, you may want to look into how
ethernet/802 packets are framed... something about putting a checksum at the
end... hmmm...

/mtr