Strategy for merging NIR applications

Tim Berners-Lee <>
Date: Tue, 10 Nov 92 16:42:26 +0100
From: Tim Berners-Lee <>
Message-id: <>
To: Dan Connolly <>
Subject: Strategy for merging NIR applications
At the end are some condensed thoughts about directions for merging  

|  Date: Tue, 03 Nov 92 14:08:54 CST
|  From: Dan Connolly <>

|  >> Dan:
|  >>     Should WAIS clients grok URLs? I don't see any need.  Similarly for
|  >>     gopher clients.
|  > Tim:
|  >	If you want to keep the WAIS and Gopher worlds totally distinct,
|  >	then no.  But who wants to have all these separate clients around?
|  >	Noone: that is the big user puzzlement with NIR now -- why so
|  >	many systems when they all do the same thing? The first step
|  >	toward merging existing systems, *AND* allowing for future systems
|  >	smarter than the ones we have thought of now, is the URL.
|  Dan:
|  Well, you took the bait, but you didn't run with it very far.
|  "The first step towards merging..." -- so you _do_ have a deployment
|  strategy in mind. You just didn't put it in the RFC.

(Can you punt bait?)

The RFC is to define one piece of the whole. It is most important to
keep the peices distinct, or the whole thing will be too rigid. I suppose we  
could propose "All the world should use W3 and we should all discuss what W3  
should be like next" but that would never fly. We see that URLs are essential  
to allow communication between applications and different environments and for  
the introduction of new namespaces.

|  I'd like to see more motivation in the form of a strategy or at
|  least a vision for how this whole thing comes together. I'm trying
|  to piece it together myself, but I'm not having much luck.

That may be because the bits aren't available.  Like a global solid reliable
directory system, for example, and a global payment mechanism or two, and  
athentication systems to support it.  These just aren't globally deployed yet  
so we will have to wait for them and then plug them in.  What we do have is the  
internet, TCP/IP and DNS and we have to put hooks for everything else.

|  For example, I really don't see why different protocols should
|  share addressing schemes, or why the sheme:path syntax should
|  go any further than the WWW project.

It is the scheme:path syntax which allows the bridge. It need not be used
in closed applications, but in open applications it is needed. W3 will be able
to incrementally move to new name spaces. If other apps don't, too bad.
But I think they do.

|  >	Yes. Certainly a useful aspect of URLs. But not the only.
|  >	What about the URL pasteboard type? To allow "cut reference"
|  >	and "paste link" to work between applications?

|  I've been trying to work out a design for this, and URLs don't seem
|  to help much. If you copy a WAIS URL and paste it into another
|  client, that client has to grok WAIS protocol in order to use it.

Or have access to any WAIS engine. There are 100 ways of keeping a
register for a user for what applications can handle what kinds of
namespace.  This will probably be something which is more difficult
to standardize on, as NeXT and Windows and Motif etc will all have different  
schemes for registering application capabilities, and different  
inter-application messaging techniques.

There is some analogy between capabilities to deal with UDIs and capabilities  
to deal with data formats here ... Mark Litwack (are you there, Mark?)
had a scheme in which the two merged.

|  Or it has to use a gateway. If it uses a gateway, it has to translate
|  the WAIS name into something suitable to that gateway, which is
|  something you said you didn't think was practical.

I don't think the client has to translate anything necessarily.
The http protocol allows one to send over a URL including the
prefix, which need not be http:.  For a protocol which does not deal
in generic URLs, some translation would be necessary.

|  Anyway, if you're
|  going to define a gateway system, then define a gateway system, not
|  just an addressing syntax.

The gateway system is a time differential of the set of protocols used.
It will always change to reflect the movements between protocols. I agree
that the HTTP protocol could perhaps have something in the spec to point out  
that the full UDI may be sent to a gateway.

|  I'm trying to figure out how URLs complete the picture, but I don't
|  see it.

There will be a few things in the picture. URLs are the most important next  
step now, a timely requeirement for commonality. That's all. They will not  
solve all the problems.

You want a merging strategy. Suppose it is as follows, off the top of my head.


The metastrategy fro developing strategies is to first, make a model of
a superset of the functionality of the various systems, then design protocols  
to implement them, then make applications which use both old and new. Beware  
that merging all the applications onto one is only one as seen from the user,  
hopefully there would be separately developed products on there with messaging  
between them. 

	Merging WWW and WAIS and Z39.50:

A new HTTP2 protocol is defined, back-compatible with the current one.
It involves sending a request which is a particular format. There are MIME-like  
formats defined for a simple document request, a basic WAIS-like query, and if  
necessary other Z39.50 queries. This means establishing a mapping between the  
Z39.50 parameters and an ASCII internet-mail-like format. We make the set of  
query types as open as the set of document format types and encoding methods,  
and allow for a registery of names like IANA.  The formats acceptable to the  
client are sent with the request [as mail header lines or in the body?].
The query types acceptable to a server are returned by the server when a  
queryable object is referenced.

We look at the parameters necessary for this process and add them to the WAIS  
protocol, so that Z39.50++ becomes a binary (and therefore perhaps more  
efficient) version of HTTP2. The binary and telnet-style versions run  
side-by-side, with fairly simple table-driven interfaces. The telnet version  
will be useful becasue of all those perl servers which will be eth leading  

	Merging with SQL:

This model will engulf query/retrieve systems, including e.g. SQL queries,
and allow for upgrade for new ideas of remote operations. In fact, the
query type will generalize to a typed set of input parameters for a arbitrary  
operation [method] on a remote object with the given URL, and so in principle  
can access a globally distributed OODB. In order to get a more manipulable  
version of the results of an SQL query or arbitrary OO operation, we will  
probably need a data tagging system [maybe ASN/1 based?] for structured  
[alpha]numeric data such as SQL handles, but this is just another data format,  
not our problem now. The question of converting data formats on parts of  
multipart messages [structures] will be addressed, nothing uinsurmountable. We  
would obviously like to see a mapping from any OOP's identifier space into URL  

	Merging with Mail and News:

Now look at what we have. The presentation part of the W3 client is just the  
presentation part of MIME, with an added hypertext data class. MIME really  
should have picked HTML instead of text/richtext, but that we can add.
Now we address the intruiging area of the merging of mail, news, and NIR.
The same application must obviously be able to handle all of these, and they  
should all look the same to the user. That is, if you link an article to a list  
of articles, post it to a newsgroup, or mail it to a mailbox, the operation  
(adding message to list of messages) is beasically the same, and should be sen  
as such. Note that MIME has to be augmented with the addition of query type  
registration, there needs to be a format for the summarizing of capabilities  
(mailcap information) in with requests. The mailcap information needs some  
extension. A spinoff is that the HTTP protocol should run over mail too, which  
though excruciatingly slow is neat as a lot of people still use mail servers  
;-).  This occured to me when implementing
the W3 server.

The mechanisms underneath are currently many and varied in order to be optimal  
in the extreme cases of personal messaging, news broadcasting, and archive  
serving. However, as cache coherency protocols are added to HTTP, the functions  
like "give me a list of what is new in the following domain" will approach NNTP  
functions.  Within time it will become a decision made on the fly by the system  
as to whether a document [message, article] is held, sent, or broadcast. So I  
expect the protocols to converge.  An important issue here will be  
charactization of basic operations on sets [maillistarchives, newsgroups,  
directories].  The engines which speak the new combined protocol will have to  
speak the old ones too for back-compatibilty for a few years. This is
a smooth trasnsition strategy. We're not talking about vast librares, just  
supporting SMTP and NNTP and HTTP for a while (they are very similar) as well  
as a superset protocol.


What else do we want to merge in?  Name servers of course are just HTTP2
servers which return "forward" results. File systems, I expect, too, will veer  
in the general direction. Alex-like systems will map the retrieval subset onto  
the subset. Maybe soft links could generalise to URLs. Maybe some smart  
manufacturers will allow a soft link to be a URL.  If not, file suffix which  
indicates a query or just .MIME would be enough to indicate that the document  
contains type information and could be a pointer or a query. However, there is  
basic functionality which the file sysyem does not support (That is, anything  
other than open, read write and close: no arbitrary methods here) so we will  
never map everything to fopen(). But by that time we'l all be using our  
favorite OO systems anyway. The exciting part will be to see whether the GUI  
builders will get to the point that the whole OO application can by built  
graphically, bridging the gap between the app builders and real programs (Can  
you imagine progamming in perl with a mouse? in Eiffel?)


Tim Berners-Lee             
World Wide Web initiative             (NeXTMail is ok)	
CERN                                  Tel: +41(22)767 3755
1211 Geneva 23, Switzerland           Fax: +41(22)767 7155