I like the idea of a finger URL. I also made a simple implementation
and found it useful "In Real Life". In general, the syntax seems OK,
but it raises a more global issue:
Should temporal or site-specific information be encoded in a URL syntax ?
I am refering to the "type" and think in general that this is trouble.
1. Similar syntax is not generally used for other protocols. Skipping
the new Gopher, the only other is FTP. However its type is critical
to obtaining uncorrupted data, and can be specified by the author.
2. It opens the door for other temporal- and site-specific items such
as "If-Modified-Since", and other "Accept" items like quality, etc.
which I think are beyond the scope of URL's and also cannot be known
by the author.
3. The author cannot know how to publish such a URL. Thus, it must always
be published without such information and hence its value is questionable.
4. The data stream conversion will have to be done by the client or the
proxy. If the former, then the URL syntax doesn't help as the client
can do this (better) without it being in the URL. If the latter, then we
are propogating the need for (yet another) filter in proxies. How will
this be controlled ? What if there's a URL with "text/html" but I
don't want it converted ?
It seems that URL's are trying to grow beyond a global object reference
and are expanding into the realm of wanting to define a virtual access
protocol.
There is clearly a need for information such as "Content-Type" at some level
in the access process, but perhaps not in the URL syntax which must be
useful to authors.
I would propose:
A. finger return MIME type "application/x-finger"
B. Content-Type in general not be made part of URL's
C. we think harder about how to specify filtering/conversion during the
access process in more general terms (including the conversion of
"application/x-finger" into "text/html" with hyperlinks, etc.). Some
ideas....
1. assume you always have a proxy and use HTTP protocol syntax,
where "Accept: text/html" really works and will convert
the fingerd output to what you want; and
"Accept: application/x-finger" gives you the raw output.
2. define a virtual access protocol that contains HTTP-like
items (with maybe even an API) that can be translated
into a best fit on the protocol specified in the URL.
This could actually be HTTP, just filtered/translated
mapped in the protocol module.
Mike
p.s. Reed - Sorry about using your finger proposal for this point, but
seemed like the right opportunity.
-----------------------------------------------
Michael A. Dolan <mailto:miked@cerf.net>
TerraByte Technology (619) 445-9070, FAX -8864