Message-Id: <9310271255.AA26999@mocha.bunyip.com>
To: Mitra <mitra@path.net>
Subject: Re: Thumbnail Sketch of the UR* Arena
In-Reply-To: Your message of Tue, 26 Oct 1993 23:17:47 -0700.
<9310262317.aa04093@pandora.sf.ca.us>
Date: Wed, 27 Oct 1993 08:55:47 -0400
From: John Curran <jcurran@nic.near.net>
--------
] From: Mitra <mitra@path.net>
] Subject: Re: Thumbnail Sketch of the UR* Arena
] Date: Tue, 26 Oct 1993 23:17:47 PDT
]
] Peter,
]
] Without type information, its not much good putting a URN in a pointer.
] Because unless something will tell me what type of object it is, then
] I dont know whether to pass it to "xv" or "less".
]
] Some protocols - e.g. Gopher, already pass the type information around,
] and they could start using URL's immediately, but others arent
] going to be able to handle URN's on their own.
Folks,
There is no reason that people cannot begin using URN's, even in the
absence of standardized URL and URN meta-information. Each protocol
has its own needs for meta-information, and I do not recommend rushing
into the definition of such.
For example, folks may want the size of a resource pointed to by a URL:
URN-x
[App] -----> [ URN/URL service]
/
<----/
URL-a, size=62843, ...
URL-b, size=1248, ...
...
The problem, of course, is that it may also be desirable to pass the
attribute into the resolution service to refine which URL responses
are desired:
URN-x ; size < 32000
[App] -----> [ URN/URL service]
/
<----/
URL-b, size=1248, ...
...
The same requirement (metainformation associated with each result AND
metainformation associated with the initial input) exists at the level
which returns URNs (the resource discovery level?). For example, give
me all URN's which pertain to topic JKL, or give me all URNs pertaining
to JKL _which are of type text/*_.
The act of encoding meta-information will either require us to specify
the "appropriate" metainformation for URLs vs URNs vs URx's, or will
require that we allow arbitrary metainformation elements at any level.
The former is very difficult to reach agreement on [reader exercise:
where does resource _type_ go? how about _cost_?] and the latter requires
that we fully specify how unknown metainformaton types are handled.
Either way, this is a non-trivial task, and one which requires serious
consensus building.
In the interim, folks should use the metainformation field that their
favorite protocol (gopher, WWW, WAIS, email to reference librarian) allows,
and employ "heuristic algorithms" (i.e. code which guesses :-) to extract
metainformation from otherwise defenseless URLs.
Yes, I admit that it will be a serious pain to add the "standard"
metainformation support into the clients and servers after the fact,
but in all honestly, I see an extremely small chance that we could put
any support in at this time which would not end up being changed in the
near future.
Apologies for length,
/John