[BXXPwg] Extensible trailers

Greg Hudson ghudson@MIT.EDU
Sat, 16 Sep 2000 10:37:12 -0400

> specifically, i can come up with lots of examples in which an
> erroneous octet count can still be undetected [...] for example, all
> i need to do is to include "END" CRLF in the payload

"Lots of examples?"  Without extensible trailers, the error will be
detected unless (a) the erroneous octet count takes you to an "END"
CRLF which happens to be in the payload of the current or a future
frame, or (b) it takes you to the end of a frame other than the
current one.  In case (a) the session will be terminated immediately
after the erroneous frame is processed unless the content following
the "END" happens to look like a frame header.

These are very singular cases.  It is much much more likely that an
erroneous count will point to space-separated words leading to the end
of a frame than that it will point to an instance of "END".  Many
things, including BXXP frame headers, look like space-separated words.

> hopefully you will agree that this isn't a very interesting
> question.

Well, either this question is interesting, or "why does BXXP have a
fixed string in the trailer at all?" becomes interesting.  I thought
there was a design goal behind the trailer as it currently stands, and
am now being told that isn't a design goal.  That feels squirmy to me.

> i'm not sure what a "payload-oriented" protocol is, although i
> suspect the term is redundant.

For obvious reasons, I only wanted to consider protocols where a
single part could be can be singled out and called the "payload."  BGP
is a counterexample.

>> Can you name any precedent for a payload-oriented protocol putting
>> extension material after the payload?

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

This is pretty condescending, and it's also not an example of what I
asked for; a checksum is not "extension material" (what I said) or
"optional stuff" (what you said).