Re: Gopher+ Considered Harmful

Dan Connolly (
Thu, 10 Dec 92 12:05:02 CST

>I once explained the current HTTP protocol to a local network guru and
>he expressed concern that basing a protocol like this on TCP/IP is a
>great waste of network resources, since you are using a
>session-oriented protocol for what is essentially one remote procedure

Do the WAIS folks know about this? I wonder what they'd say...

> My question "then what would you recommend instead" provoked no
>useful answer (what is needed is *reliable* datagrams, but these are
>not implemented as an IP protocol; UDP requires too much coding for
>time-out, retransmission and fragmentation). Yet, he convinced me
>that a light-weight protocol like this should minimize the number of

I agree.

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

The idea was to use the existing usenet distributed database. But
I guess we should just use plain old NNTP for that.

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

I certainly didn't think it out very carefully, did I?

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

A terminology note here: there is no one "MIME data format." There's
the ubiquitous message/rfc822 format that you can stick anything
inside using MIME techniques. But the basic unit of information
in the MIME spec is an _entity_ -- just an arbitrary stream of bytes.

The question is, when you're sending an entity from one
place to another, how do you know where the end is?