[BXXPwg] Extensible trailers

Marshall Rose mrose@dbc.mtview.ca.us
Sat, 16 Sep 2000 13:24:27 -0700


all - just skip to "***" to get to the heart of the matter; otherwise...


greg - with respect, it would be easier for us to communicate if there
weren't so many generalities. statements like:


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

are really just one person's opinion in the absence of:

    - usage restrictions (e.g., "we will primarily use BEEP for moving
textual data containing space-separated words")

    - empirical evidence (e.g., "we've been running packet traces for the
last 3 months and X% of the traffic looks like textual data containing...")

    - or the ability to predict the future!

now maybe i'm being dense in having missed one of these, and if so i
apologize.


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

well, even BGP carries payload, it's called routing information. if there's
some reference work that has a protocol taxonomy that includes terms like
"payload-oriented", then i'm certainly under-educated. the standard
references, viz., the Comer series, don't seem to make that distinction.


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

again, this is just one person's opinion. i think it would be perfectly fine
for someone to define an optional extension that is a payload checksum...and
for the reason i suggested in my previous message. (or maybe because they
think that TCP's checksum is too weak--yes, those folks do exist...


***

however, you seem to have missed the olive branch in my last message,
specifically,

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

and, in comparing

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

with

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

one can probably argue that the latter is also slightly more elegant,
although taste is a matter of choice.

more importantly, i think there's neither much benefit nor bother to using
the latter syntax.


accordingly, i can't get too worked up about picking one over the other. so,
let's go with the latter syntax and move on.

any comments anyone?

thanks,

/mtr