# RE: Minutes of the "UDI" BOF at the 24th IETF

[The gopher folks are dicussing how to add the "reply" feature from USENET newsreaders to gopher clients. I wish www had that feature too. The "followup" feature is currently beyond the scope of WWW, but...]

[I'm beginning to wish www was a mail user agent and a gopher client and a news reader and a WAIS client all in one. Soon...]

[We need a DTD that models the USENET thread model, with posts, followups, quotes, points, counterpoints, flames, signatures, etc.

Right now, I have to modify a destination document (add an anchor) to link to an element of that document. We should look at what HyTime and the TEI use for references to SGML elements without IDs. I saw a HyTime description that said you could link to non-hyptime documents. Maybe we could use this to reference passages of news articles etc. ]

## Quote

The information one quoted in a reference to an object could comprise many things, among which were possible one unique name, (Unique Resource Number, URN was one acronym), and zero or more addresses (Uniform Resource Locators or URLs) which gave instructions for retrieving the object.

## Response

Cool! The model for global hypertext that swims around in my mind includes references which consist of identifiers and addresses. On the subject of URNs, it sure would be nice to be able to verify that the data mentioned in the link and the data retrieved from the URL are the same.

For instance, I could reference an FTP file, and somebody could write over it. I might look like a fool arguing against old information. If I give a URN in the link, the browser could warn that it doesn't match the URN of the retrieved document.

## Quote

NOT to be discussed were the differences between names and addresses, URN schemes (which are not yet well enough defined), the full set of information to be given in a reference, or IPv7.

## response

I think internet message ID's make great URN's.

## quote

To be discussed were the overall string syntax, including allowed characters and escaping systems for unallowed characters, the order of components (little/big-endian), punctuation characters, the particular prefix to be used to identify each namespace.

## Response

Cool. This makes URLs orthogonal to MIME external body part references. I believe where they are not orthogonal, they should coincide.

## quote

It was pointed out that for WAIS one could imagine a separate name space for databases and for documents. If this was taken futher, a separate prefix would be used for each type of object. It was on balance agreed that this could go too far. One prefix should be used per protocol, but it should be made clear how to determine the type of an object from the URL.

## response

Note how nicely all this coincides with MIME external body part constructs. Such a body part looks like, for example:

    Content-Type: message/external-body;
    	access-type=x-http;
    	host="info.cern.ch";
    	path="/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html"

    Content-Description: Minutes of the "UDI" BOF at the 24th IETF
    Content-Type: text/x-html

In general, a MIME external body part looks like:

    Content-Type: message/external-body;
    	access-type=_type_; /* local-file, anon-ftp, afs, or x-token */
    	_other_parameters_ /* path, host, name, database, etc. */

    Content-ID: _message-id_ /* of external body part */
    Content-Description: here's what you'll get!
    Content-Type: _base_/_subtype_ /* type of data in external body part */

    ghost body goes here. This is _not_ the contents of the body part,
    but it is available to the user agent that's fetching the data.
    It could be used, for example, for the seed-words of a WAIS reference.

It looks like a URL is a condensed version of the MIME external body part headers. The URL scheme:____blah____ syntax maps nicely to MIME access-type=scheme; ___parameters for blah___.

## quote

The class of object you get back should be predictable (--C Lynch). W3 has a real problem with that, since everything is a "document" and handled in a similar way.

## response

I don't agree that "everything is a 'document'" to the W3 browser. The browser knows it's getting gopher directory info from gopher UDI's, for example. I think the type of data it returns can and should be classified by the MIME typing system, even if it does so implicitly.

## quote

Should one use punctuation, or attribute-value pairs? Attribute value pairs get mispelt. (note x.400 vs.internet addresses)

It was decided to use a short string with punctuation rather than an attribute-value pair system.

## response

I have doubts about the ability to be able to encode all this information (scheme, host, path/selector-string, type, etc) in something akin to a phone number that can be written on one line of text with no spaces. I think that within each scheme, folks develop printable syntaxes for making references (ange-ftp, WAIS source files, etc.).

But the scope of URLs is so vast that I wonder if folks will form habits over this whole domain.

I advocate that the W3 format include, at least experimentally, an SGML element for each access type, with the URL pre-parsed into attribute-value pairs. The anchor element could become more complex, including sub-elements for URLs and URNs. Data type information could be included somewhere.

The HTTP access type doesn't require type information: format negociation is part of the HTTP protocol. But WAIS and Gopher references require these types, and it would be nice for FTP references (at least to choose between image and text transfers.)

I'll think it over and work on a DTD that uses these pre-parsed URLs. How do these examples look?

    <A HREF=
    "http://info.cern.ch/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
    Minutes of the "UDI" BOF at the 24th IETF< /A>

    becomes

    <A><HTTP host="info.cern.ch"
     path="/timbl/Public/USTrip1992/IETF-24/UDI_BOF_Minutes.html">
    Minutes of the "UDI" BOF at the 24th IETF< /A>

    and

    <A NAME=gopher
    HREF=gopher://gopher.micro.umn.edu:70/11/Other%20Gopher%20and%20Information%20Servers>
    list of sites< /A>

    becomes

    <A NAME=gopher>
    <Gopher type="text/x-gopher-1"
            host="gopher.micro.umn.edu" port=70
            selector="1/Other Gopher And Information Servers">
    list of sites< /A>

The idea here is that we've got a parser already: the SGML parser. Why not use it to parse the various bits of data we need to reference data located elsewhere?

## quote

A separate issue of whether human or only machine readable. Previously, included issue of printable. This is needed because don't have names now. Question arose of whether once these addresses exist will be replaceable with names - will be presented as new functionality, not replacing existing systems. Agreement on some way of specifying class of objects.

## response

This reminds me of Knowledge-Domain Interoperability & an Open Hyperdocument System by Douglas C. Engelbart in which he gives requirements for his system.

One of them is:

#### Hard-Copy Print Options to Show Addresses of Objects and Address Specification of Links

##### ... so that, besides online workers being able to follow a link-citation path (manually, or via an automatic link jump), people working with associated hard copy can read and iterpret the link-citation, and follow the indicated path to the cited object in the designated hard-copy document.

Also, suppose that a hard-copy worker wants to have a like to a given object established in the online file. By visual inspection of the hard copy, he should be able to determine a valid address path to that object and for instance hand-write an appropriate link specification for later online entry, or dicate it over a phone to a colleague.

That document deserves a thorough reading by the whole comp.infosystems.* community.

## quote

IT WAS AGREED that the context, or namespace, prefix be the first (leftmost) part of the URL, and be separated from the rest of the URL by a colon.

## response

Has anybody given any thought to a syntax with implied schemes so that the ange-ftp style URLs and internet message ID URNs that are out there can be used?

If we reserved a character to _start_ UDIs, then we could try to infer the scheme of strings that don't start with that char. Let's take () for URL schemes and [] for URN schemes.

    For example: host:path == (ANON-FTP)host:path
                 path@host == (ANON-FTP)host:path
                 <message-id@host> == [rfc-822]<message-id@host>

Well, I suppose this type of thing is really akin to the W3 local UDI scheme: it's application specific.

###### Postscript: This document was prepared using emacs with the help of Eric Naggum's sgml-mode, and verified by sgmls-0.8 with the DTD in html.dtd . This is proof of concept that the W3 browser handles conforming SGML. I also wrote a short perl script that will bring many existing HTML files into conformance.