Either that, or introduce state into the protocol to allow for efficient
authentication and compression. Then by all means, keep TCP so that
a single channel can be authenticated once per "session" or "state"
and you can go with it...
> * put authentication and compression in the transport
> layer (ARDP).
>
I think a lot of people are already thinking about this. A lot of
the ideas I'm hearing about have authentication and compression happening
way upstream from the transport layer though. My personal feeling is
that it belongs down in transport, so that the application developers
are not bothered with these notions. Send data from point A to B. Here's
some (optional) authentication (i.e. my public key). I don't care
how it got there and how many bytes it took. Just get it there...
>
> * Allow for replicated servers and objects.
>
Another YES! However, replicated servers require their own management/
coordination transport. You're talking next-generation "super-servers"
who can do this sort of thing without the service providers knowing
about it. As for objects... well, that's a whole other can of worms (;-)
>
> * Separate object names from network locations
>
Agree. However, name->location lookups may begin to constitute the
majority of network traffic. Replicated servers should help localize
that a little. All the URL talk is not going to solve the problem
of location transparency. URN's might, but nothing I've seen up to
now does it. You can't embed location independence in the naming scheme
alone. You need lots of infrastructure (name-servers, agents, etc...)
to make it work.
>
> * Support data authentication (MD5 checksums, digital
> signatures, etc.)
>
This sort of goes with authentication above. Digital signatures would
be necessary only if you start talking privacy and/or billing. If you
start having pay-for-service type activity, you want to know who is
charging and who is being charged. Also, if someone submits trade secret
material into the web, some people may want to know who did it. I am
not a complete proponent of such concepts, but once you embark on the
road to commercial services, authentication is one of those things
you better have lined up WAY ahead of time... It can't be a hack on a
patch on a revision on an option that someone adds later on...
> I don't think we can do all this with HTTP in the short term. In
> the mean time, "Let a thousand flowers bloom."
>
Although an awful lot of folks seem to be trying (;-) And YES! I agree
that more options should be there. If anything, I appreciate that these
issues are being raised.
> The relavance feedback in the WAIS protocol, along with the
> original-server/distributor-server distinctions are features that
> I don't want lost from the web. NNTP has some features we shouldn't
> lose either (though it should be revised to use a request-response
> protocol like ARDP rather than a session based protocol like TCP).
>
> On the other hand, I won't miss FTP or gopher. Not that there's anything
> wrong with them, but their functionality is subsumed by HTTP.
ARDP is a nice transport concept. I'm not sure I would extend it all
the way up to application-level protocols. There are variations on
ARDP out there that have slightly less overhead but with less smarts
in terms of failure recovery. I also personally think ARDP is a million
times more interesting and efficient from an academic perspective than
HTTP. I know they're different beasts, but ARDP has so many things built
in that would make life easier to implement HTTP.
Every new service seems to concentrate the best features of the previous
services and throw a few new things in there. Just like News built on top
of UUCP concepts, gopher goes beyond ftp and WWW goes beyond gopher.
I'm certain the next series of services out there will take the WWW
notion and throw a few unique things of their own...
>
> Dan
>
Good calls, Dan...
Cheers,
R.
-- Ramin Firoozye' rp&A Inc. - San Francisco, California Internet: rpa@netcom.COM - CIS: 70751,252--