|>Rick Troth <troth@rice.edu> wrote:
|>> I don't think he really meant to limit packets to 64K,
|>> rather, segments (yeah ... that's the word ... yeah "segments").
|>
|>Yeah; "segment" is a better word than "packet".
OK so we are on segments.
|>I thought a 2-byte segment length was reasonable because
|>typically a server process is going to use a small (< 64K)
|>buffer *anyway* as it's sending data over the network -- a
|>program that reads a 4 megabyte file into memory and writes
|>it back out with only two system calls is going to have
|>problems -- and this also provides a reasonable maximum
|>buffer size for clients to allocate.
I thought that 4Gb was a bit low myself. 4Mb fills are well within the
range of what I would want to do now.
|>> I have reasons that would make me prefer the 2-byte length.
|>> But the suggestion en-whole (zero length segment terminates, 2-byte
|>> length, all of it) solves exactly >one< problem. Were we to add
|>> real structure to the stream, we'd need something more complete.
|>
|>My first thought was to use a 3 part tag-length-value
|>encoding for segments/packets, but I couldn't think of any
|>uses for the tag field.
I agree this has more potential. Perhaps we should take the discussion
off onto www-http? Nobody seems to have said anything on it yet.
|>This scheme is only trying to solve one problem --
|>how to provide an in-band end-of-message indicator for
|>multipart MIME messages without "spreading social diseases
|>like base64 encoding around" :-) What other structure do you
|>have in mind?
The session stuff is good except that maybe we don't need it. The multipart
mime can give that functionality. Are we trying to replace the multipart
stuff as well?
I think we should continue to work within the framework of RFC 822 until we
have the code in such a manner as we can create a binary correspondence of the
protocol. I do not want to have two divergent specs. We want one spec with two
flavours - RFC-822 and a binary (ASN.1) equivalent. The binary spec would
start off being used as a client/proxy protocol but could spread to
more widespread use gradually.
-- Phillip M. Hallam-BakerNot Speaking for anyone else.