[ih] Internet analyses (Was Re: IPv8...)

[Brian E Carpenter]

Thanks Larry, just three further comments:

> forms and file upload  wasn't a major performance issue (in the same way that IMG did)

Absolutely, it was images that dramatically increased the quantity of traffic.

> There isn't a <POST/> HTML element

Of course, sorry about the brain glitch.

> rather than, say, building on expanding XNS Courier remote procedure call)

You do realise that Tim's day job when he designed HTTP was implementing RPC
for CERN physics experiments? I have no doubt he knew of Courier, but he
rolled his own. I don't know the exact sequence of events, but I had Bruce
Nelson's PARC CSL-81-9 on my bookshelf in those days. Robert Cailliau and I
implemented a homebrew RPC at CERN a few years before, in the group where Tim
worked in 1980, on the same machine where Tim implemented Enquire. RPC was
definitely present at the birth of the Web.

Incidentally, Tim credited his choice of TCP/IP as the substrate for both
his RPC and HTTP to the existence of Wollongong TCP/IP, since the physics
user community was split at that time between VAX/VMS and various Unix
flavours and he needed a common network layer. No Wollongong, no Web?

Regards/Ngā mihi
    Brian Carpenter

On 18-May-26 06:19, Larry Masinter wrote:
> ((sitting as a draft in my mailbox for too long))
> 
> Adding forms and file upload didn't cause significant complexity to the network protocol part of the web or additional server load.
> 
> Although update and user editing were part of the early vision of the web, most of the complexity fell on the user interface.
> 
> There isn't a <POST/> HTML element. You could do a POST (HTTP method) via HTTP and build a UI to submit one via <FORM/>.  And RFC 1967 was (I think) the first to add the "file upload" capability
> https://datatracker.ietf.org/doc/html/rfc1867 <https://datatracker.ietf.org/doc/html/rfc1867>
> 
> but forms and file upload  wasn't a major performance issue (in the same way that IMG did) because it still would be one network connection per user mouse-click.
> 
> Web complexity grew because the functionality was split between HTML and HTTP with separate workflows for producing and deploying each.
> 
> That HTTP proceeded to build what it needed on top of TCP rather than, say, building on expanding XNS Courier remote procedure call) might be thought of as another cause -- the "plumbers" who were in charge of network infrastructure didn't give the HTTP use cases seriously (until HTTP/3.0?)
> 
> --
> https://LarryMasinter.net <https://LarryMasinter.net> https://interlisp.org <https://interlisp.org>
> 
> 
> On Thu, Apr 30, 2026 at 7:06 PM Brian E Carpenter <brian.e.carpenter at gmail.com <mailto:brian.e.carpenter at gmail.com>> wrote:
> 
>     Larry, I agree that <IMG/> made a big difference but surely it was <POST/>
>     that really made HTML/HTTP different?
> 
>     Regards/Ngā mihi
>          Brian
> 
>     On 29-Apr-26 09:59, Larry Masinter via Internet-history wrote:
>      >> Gopher was (is?) a similar cautionary tale. It was a good design and
>      >> although it was a lot less flexible than the web, it was also a lot
>      >> easier to implement and loaded the servers less.
>      >
>      > http 0.9 was essentially gopher: open a connection, GET the document in one
>      > exchange, close the connection. One transaction per document/directory
>      > list.  The complexity came from using multiple connections for a single
>      > document with many embedded images rather than portable compound document
>      > formats, moving the format complexity into the protocol.
>      >
>      > As. a side note, adding  M. McCahill, University of Minnesota, (RFC 1436)
>      > as an editor of RFC 1738 (URL) helped show the gopher community how to
>      > preserve their investment in gopher servers while migrating to the web.
>