From Cornell University there was Steve Worona. Steve had a lot of useful input, playing devil's advocate in querying the common assuptions of the UPenn and W3 teams.
Tim McGovern of MIT's Distributed Computing and Communications Services (DCCS) joined us when he could. His group are involved in a number of projects in the area, including TechnInfo, Libraries, WAIS. Tim sees the TechInfo system standing alone until things have settled down in a few years: He guessed that in 10 years things might look more rational, and was in no rush to see TechnInfo join any other projects. Tim watches the migration path from MIT/LCS to the real Athena World from a distance.
Karen Sollins (MIT/LCS) joined us for some of the time.
From the University of Pennsilvania, there was a whole team from the Data Comminications and Computing Services: Mark Litwack organised the meeting, and had spent many months on analysis of needs, and had drawn up a protocol specification which we discussed in the afternoon. (See notes on Argo). Linda ...... had already some experience attempting (!) to intsall W3 software. John Hagan had a clear view of user needs and timescales for the project. Jerzy Sliwinsky even broke into a vacation on Orchard Beach to join us.
These groups had all been involved in an earlier attempt at homologation of CWIS protocols, the "CWISP" group. This group had downed tools when W3, WAIS, and Gopher came on the scene.
Our agenda was to make contact, and establish joint requirements list, and decide how we could each contribute a solution meeting these requirements.
The Upenn team all showed great enthusiasm for W3, and said lots of nice things about it. :-)
Things which came up as individual requirements for the system during the meeting (and aren't in the current W3 world) included
Technically, my feeling was that we should separate the document format infomation in the document from the access information stuff. This is not just a technical decision, it is also a project management issue that the two things must be decoupled and a "flexibility point" introduced between them.
The forms idea is a very useful one, which should be either decoupled from the hypertext or, ideally, made an extension of the hypertext format so that tags in common are used. I would suggest that we look at an SGML form of the forms syntax for acceptability in a wide community.
The address syntax for remote access is a tricky area, as it goes from the basic UDI into a full query/scripting language without a clear line drawable between them.
I suggest we draw the line in the following way. We need UDIs to encompass everything which the current W3 handles for back-compatabiity. I would not extend UDIs to contain telnet session scripts, so I would suggest that we adopt a scripting language from argo which will cover the telnet case as well as xlogin and launching of arbitrary applications. This scripting language, if it can't be anything standard, should be defined, made public, and a data format be defined for it, and registered with MIME for example. I would suggest W3 migrate toward use of such scripts for decribing telnet sessions.
The UDI will therefore describe just the address of an object in some network namespace. It won't have complicated algorithms. It won't contain SQL. We will allow it to contain the simple W3/WAIS style text user input. Aything more complicated will have to go via an intermediate (named) document. [I'm not sure that this is right. I think that when a really cool script lnguage is developed which is generally accepted and complete and everything, then we might allow a special UDI which is an expression in that language, for completelness. That will be "scripts under buttons" which people want often, without intermediate files. In the mean time, we need more experience of scripting language candidates before we allow people to quote a bunch of script as a reference)].
The actual format of UDIs wil be discussed in a wider group than this meeting (www-talk plus the ietf nir groups, basically).
There a few minor differences betwwen the "dip" access specifications and UDIs as in W3 now, which we can iron out with time, but they are minor.
We should separately check whether there are any things in the "dip" document format which should be taken into HTML. Like "expires" for example is a good one. I'm not sure about icons and portability.
We should therefore end up with three items: