[BXXPwg] Extensible trailers
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
> > 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,
> 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
> 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?