|>The binary-segmented encoding addresses cases where
|>the server doesn't know in advance how large the
|>object is. It lets the server send data one chunk
|>at a time instead of having to buffer the whole thing.
OK that will do for `functional requirements'
|>[It might also be used to allow clients to prematurely
|>terminate transmission of an object without shutting
|>down the entire session, but I don't know if that's
|>really an issue.]
|>----
|>
|>To summarize: In order to implement an MGET
|>method, or to keep HTTP connections open for multiple
|>requests, there must be an in-band mechanism to delimit
|>the end of a transmitted object. Some options:
|>
|>1. Use multipart/* and BASE64 encoding.
|>2. Use multipart/* and BINARY encoding, and
|> send an accurate content length in the header.
|>3. Use multipart/* and a new, binary, self-delimiting encoding.
|>4. Throw out MIME altogether and use ASN.1 over BER or PER.
|>5. Throw out MIME altogether and use something totally new.
|>
|>(1) is believed to be expensive in terms of CPU and network
|> transmission time.
It would also make Tim B-L very very unhappi. The whole point of HTTP is
to exploit being 8 bit clean. We do not want the smallest toehold for the
people who would start running 7 bit only transports.
|>(2) requires that the server know the content length before
|> it begins transmitting.
|>(3) has not been invented yet.
|>(4) adds a lot of extra complexity for very little payoff.
|> (Before I get flamed for this: ASN.1 is great for complex
|> data structures, but the data on the web just isn't that
|> complex. MIME content-types have been sufficient so far,
|> and probably will be in the future.)
ASN.1 has a different place, for sending raw data arroung for later analysis.
But there are some bits that look usefull.
|>I'm in favor of (3).
Seconded.
How about a compromise on the length. We start out with a four byte length
field BUT we reserve one whole byte of it. Then we can add in session
m'larkey at a later date in any manner we chose. :-
Byte 0: Tag byte
Case byte 0 is 0:
Byte 1: B1 MSB
Byte 2: B2
Byte 3: B3 LSB
< B1 * 256^2 + B2 * 256 + B3 Bytes>
Case byte 0 is not 0
Byte 1: Stream id } Semantics defined by byte 0
Byte 2: Stream id }
Byte 3: Length of header block
Byte 4:
Byte 5:
Byte 6:
Byte 7:
< B3 Bytes of header >
< B4 * 256 ^3 + B5 * 256^2 + B6 * 256 + B7 Bytes>
The semantics of the B1 and B2 fields would be determined by context. For
most cases B3 would be 0 and there would be no `object header'. 16 bits
for a stream tag sounds OK. There can be up to 255 stream modes, the
streams may have data object attachments and there isn't a base 64
encoding anywhere.
I would propose that an area of the byte 0 field be reserved for development
and an area be allowed for experimental use 0 to 191 reserved OK?
BTW on the subject of Base 64 am I in any danger if I include <STDlib.h>
in my programs?
-- Phillip M. Hallam-BakerNot Speaking for anyone else.