[BXXPwg] Extensible trailers
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
Now is the time for all men to come
to the aid of their country
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.
MSG 1 1 . 0 77
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.