On Saturday 26 January 2002 11:06 pm, Paul Prescod wrote:
>  That's still the central idea of the Web and its most impressive
>  feature. So I stand by my claim that the Web that we have is exactly
>  a subset of what Tim Berners-Lee dreamed of back then.

I'm basing my opinion on what I've read, and what I saw in the very early days of the WWW. P
erhaps Tim was down-playing the grand vision then... 

>  As far as what HTTP was designed to support:
. . .
>   * http://www.ietf.org/rfc/rfc1945.txt

1996. HTTP1.0 [3] HTTP2 [2] or HTTP 0.9 [1] also make good reading.
Note in HTTP 1.1 [4] section 1.4 and the section claiming backward compatibility with HTTP/1
.0.

>  http://www1.ics.uci.edu/~fielding/pubs/dissertation/web_arch_domain.
> htm

Well I lived through some of the history you quoted, and I don't remember it being quite so 
organized... more like HTTP 0.9 wasn't enough, HTTP2 was too much, splintering, some consoli
dation, then the IETF working groups. While Roy may claim to have spearheaded HTTP developme
nt, I don't remember him emerging until somewhat later in the play (Dan, Larry et al. all pl
ayed a huge role too).... though from late '94 on, his presence was certainly (and increasin
gly) felt.

>  "The next chapter introduces and elaborates the Representational
>  State Transfer (REST) architectural style for distributed hypermedia
>  systems, as it has been developed to represent the model for how the
>  modern Web should work.
. . . 
>  "Since 1994, the REST architectural style has been used to guide the
>  design and development of the architecture for the modern Web. 
. . .
>  Well either you weren't watching closely enough or Fielding is
>  engaging in revisionism. Insofar as I read the HTTP and URI
>  specifications and I see evidence of design and architecture exactly
>  as he describes it, I am inclined to believe him when he claims that
>  it isn't there by accident.

I'm not claiming that HTTP 1.1 and the later URI specs don't represent REST principles or Ro
y's thinking. That said, I don't think Roy had formulated them in 1994, and certainly didn't
 articulate them. One way or another, I  certainly don't think he led HTTP development based
 on consistent application of those principals. Many others were involved.... the http maili
ngs lists [5][6] show that much at least (and many of the older lists are incomplete anyway)
.

>  So you're saying that it is okay to say: "XML can be used for
>  purchase orders" but incorrect to say "XML supports purchase
>  orders." I consider those two statements to be logically equivalent.

I don't. It's kind of like reification, where you start using a label  as though it represen
ted the thing itself. Saying "my car can be used for bulldozing" and "my car supports bulldo
zing" aren't the same thing (should see the damage a deer did to it ;-)). Saying "HTTP can b
e used for <whatever> " is not the same as saying "HTTP is/supports <whatever>". Maybe I'm ju
st being overly-sensitive, but to me "supports"  implies "intrinsically", or "is designed fo
r" or "is suitable for". Anyway, I'd encourage you to be explicit when talking about *applic
ations* of the protocol, vs. the protocol itself.

>  Funny. Neither does the SMTP spec. In what sense is SMTP
>  asynchronous? You connect to a server. You set up a socket. You talk
>  back and forth on it. Just like HTTP. In fact, SMTP has more
>  syncronization points in a connection than does HTTP.

SMTP is store-and-forward (different from asychronicity per se., I agree. We might say "mess
age transfer is asychronous" perhaps). The early HTTP specs were pretty much explicitly not 
store-and-forward, and indeed, pretty much explicity synchronous in the request/response *an
d* message transfer [1][2][4] and HTTP/1.1 claimed/claims backward compatability to HTTP/1.0
.

(I remember someone categorizing HTTP as "an American protocol" because "you shake hands, do
 your business, and then say goodbye!")

I think the loosening of interpretation to be a good thing (always good to review things in 
a new light), but I also think it an entirely modern phenomena.

>  When did anyone say that HTTP billed itself as a replacement for
>  SMTP, SNMP or RPC? All that's been said is that it was designed to
>  be generic which means it could be used as a replacement for those
>  things.

...and people are claiming it not only *can* but *should* be. Again though, it's not HTTP so
 much as *applications* of it... which obviously *can* replace the other protocols (all you 
need is GET/POST after all). This distinction is critically important, so again, I'd beg you
r indulgence in making the difference explicit when you send out messages.

Whether it *makes sense* to use HTTP is another question... I'm open minded on this one.

>  > To me, there is HTTP 0.9, and a number of revisions.... HTTP 1.1,
>  > to me, is a vastly more complicated, and slightly improved version
>  > of HTTP 0.9.
> 
>  This:
> 
>   * http://www.w3.org/Protocols/rfc2616/rfc2616.html
> 
>  Is a slight improvement over this:
> 
>   * http://www.w3.org/Protocols/HTTP/AsImplemented.html
> 
>  Are you kidding? 

No. On a number of axis, they appear largely the same philosophically/architecturally, espec
ially when you see [2]  as well. Ultimately, to the end-user, they offer similar functionali
ty (get me some content), and largely the same system model.

>  In what sense are 7 new methods, persistent
>  connections, a completely new data model, support for intermediaries
>  like caches,  etc. a "slight improvement"?

Functionally, yes. HTTP/1.1 is vastly more complicated than 0.9, but there are (significant)
 parts of it that aren't used much (methods, headers, etc). Bloat doesn't make a good spec.

>  Roy Fielding has documented how and why HTTP 1.1 is radically
>  different from HTTP 0.9. He and Tim B-L have described the design of
>  the architecture of the Web that you claim was not designed. 

Yeah, yeah. It's nice to keep a notebook. Reality is borne out in the mailing lists, in runn
ing code, and in politics. I don't see any mention of REST, or it's codified principles anyw
here there... at least not until fairly recently. Also, it's easy to codify something *after
* it's running. That's evolution, not design. Maybe the general principals (like URI's) were
 there, but the rest happened organically.

One last thing: it's entirely possible that I don't remember perfectly, but on the other han
d, I *am* going from memory of events I watched or participated in...

---
[1]http://www.w3.org/Protocols/HTTP/AsImplemented.html
[2]http://www.w3.org/Protocols/HTTP/HTTP2.html
[3]http://www1.ics.uci.edu/pub/ietf/http/history/draft-fielding-http-spec-00.txt
[4]http://www1.ics.uci.edu/pub/ietf/http/history/draft-ietf-http-v11-spec-00.txt
[5] http://www1.ics.uci.edu/pub/ietf/http/hypermail/
[6] http://groups.yahoo.com/group/http-wg


-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>