I have the feeling that the current trend of basing the new protocol
on NNTP violates that requirement. I like the idea of borrowing
response and data formats from the FTP/SMTP/NNTP family of protocols,
with suitable extensions for 8-bit data paths. However I don't like
it if compatibility with NNTP forces us to have an extra round trip
just so that the server can give its welcome message.
Also, I don't like the fact that you must parse the RFC822/MIME header
to find out how many bytes are to be expected. This seems to be
mixing two levels of protocols: MIME assumes that the end of the
message is already known, and the MIME headers then tell you what to
do with it.
As I see it, there are two possible ways of using MIME in HTTP+. We
can either support MIME as the *only* data format (implementing any
extensions we need as new MIME content types or subtypes or additional
headers), or we we support MIME as one of the possible data formats.
In both cases we need a way to indicate how much data follows; if all
we ever send is MIME, all that is needed is a header indicating the
byte count, otherwise a type identifier is needed as well.
--Guido van Rossum, CWI, Amsterdam <guido@cwi.nl>
"The plumage don't enter into it. He's stone dead!"