Message-Id: <9212100955.AA26659.firstname.lastname@example.org> To: Dan Connolly <email@example.com> Cc: firstname.lastname@example.org Subject: Re: Gopher+ Considered Harmful In-Reply-To: Your message of "Wed, 09 Dec 1992 21:15:36 MET." <9212100315.AA14084@pixel.convex.com> From: Guido.van.Rossum@cwi.nl Date: Thu, 10 Dec 1992 10:55:24 +0100 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 call. 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 round-trips. 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 <email@example.com> "The plumage don't enter into it. He's stone dead!"