FPIs to URNs
Perhaps this is the place to introduce some information I've been
sitting on for the past couple of weeks.
As I've mentioned, at Sun we've put together a system for using FPIs
from the bottom up as a way to get ad hoc location-independent
document naming on company intranets using SGML Open catalogs with the
proposed DELEGATE extension (which we call "socats" for short). We
like the system a lot and think that others will, too. I've also
promised you a description of that system, which it now appears I
won't be able to get to until this weekend.
I recently had an interesting conversation with Ron Daniel about our
FPI system and how it could tie in with NAPTR. He seemed immediately
to grasp the usefulness of a bottom-up FPI scheme, and suggested that
we view NAPTR as the fallback mechanism for FPI-based links that fail
within our system (none of Sun's will fail if the user is connected to
the Internet, because in our system, all unresolved references to our
own documents will simply fall through to our own Web site, but it is
certainly conceivable that links put in by others might fail). I took
an immediate liking to this proposal in its abstract form, but since I
didn't have a clue about NAPTR mechanics, when Ron got into the
details I just blanked.
Ron followed up with the message below, which I quote with permission.
I confess that I'm still not understanding all the details, but it's
clear that Ron is suggesting that some kind of FPI resolving authority
be built into the NAPTR framework. I would have preferred to hold
onto this until I could put a description of the system that Ron is
referring to in front of you, but he needs feedback in the short term,
and I suspect that there are people on this list who understand his
NAPTR descriptions perfectly.
I will forward all comments on this to Ron.
Date: Fri, 22 Nov 1996 13:42:04 -0700
From: Ron Daniel <firstname.lastname@example.org>
Subject: FPIs and URNs - resolution possibility
As you know, FPIs are one of the namespaces I would like to be
able to handle as URNs. Here are some notes on how we might be
able to do that resolution through a combination of SOCATs
(SGML Open Catalogs), the NAPTR proposal, and HTTP.
First, a note on syntax. When FPI-aware software is using FPIs,
they should have no special encoding and will be strings like:
-//Sun Microsystems::SunSoft//DOCUMENT Solaris 2.5 User
(without the line break, of course)
When FPI-aware software is going to emit an FPI to software
that is URN-aware, but not necessarily FPI-aware, the FPI
should be encoded by:
1) Prepending "fpi:"
2) %encoding any special characters that are illegal
in URNs, such as space.
3) The URN syntax draft is currently being reviewed and
may make additional requirements, but this is close enough
Thus, our example FPI would yield a URN like:
(again, without the line break)
This note addresses three cases. The first case is the ideal
world where we have a client that knows about URNs and
SGML Open Catalogs. The next two cases then look at how the
infrastructure for the ideal world can be used to offer
backward compatability to clients that know SOCAT but not
URNs and vice versa.
Case 1: SOCAT-savvy and URN-savvy client
Assume we have a client attempting to resolve the FPI:
-//Sun Microsystems::SunSoft//DOCUMENT Solaris 2.5 User
It consults the local catalog, but finds no appropriate PUBLIC
or DELEGATE entries. Rather than throwing an error, it tries to
use NAPTR-style URN resolution as a fall-back mechanism. It queries
fpi.urn.net for NAPTR records and gets the response:
fpi.urn.net IN NAPTR 50 50 "A" "http+N2C" "" bigcat.sgmlopen.org
The current drafts for URNs would have the client send a GET
request with the full URN, and a little bit of stuff at the
beginning to say that we are asking for the N2C operation. So,
the client does just that, but uses the Accept: header to ask for
a SOCAT. The request might look like:
(without the line break)
The HTTP daemon at bigcat.sgmlopen.org fires up the N2C
CGI script. The script looks at the Accept: header, and
realizing it is speaking to a SOCAT-savvy client it starts to
build a custom SOCAT on-the-fly by trolling through its huge
catalog and only returning entries that match. This response
might look like:
DELEGATE -//Sun Microsystems::SunSoft//
DELEGATE -//Sun Microsystems
(Not sure of the exact SOCAT format, but the idea should
This new mini-catalog is then processed by the client. It
fetches the SunSoft catalog and procedes as usual.
Actually making this into a reality would require commitment
>from some SGML-affiliated organization, such as SGML
Open or GCA, to try and maintain a big catalog of registered
and unregistered FPIs, and agree to serve that up for the
advancement of the community. I think doing such a thing on
an experimental basis might not be too hard, but committing to
doing so on an ongoing basis is another story. Anyone want to
comment on the liklihood of this scenario?
Case 2: SOCAT-savvy, URN-unaware client
If we have a URN-unaware client, we could modify its catalog
to say something like
This would not require any modifications to the SOCAT-aware
client, but the size of the response is likely to be staggering.
It might be desirable to have a SOCAT version 2 proposal that
allows the magic characters "%!uri" in the URL of a
DELEGATE entry to mean "substitute the full FPI here". The
SOCAT-2 client would then have a catalog entry of
which, as long as the client can specify application/socat in the
Accept: header, would result in the mini-catalog as in Case 1.
(In fact, this SOCAT-2 hack might be used in a new version of
Case 1 so that when the client asks for the catalog from SunSoft,
they could actually ask it for a tailored one. But I digress).
Case 3: SOCAT-unaware, URN-savvy client
This client somehow comes across a FPI URN, perhaps as the
HREF in some HTML:
Fun Stuff at Sun!</A>
Not having a special content handler for the fpi namespace, it
goes to fpi.urn.net and gets the NAPTR record from Case 1.
Since the client does not know about the application/socat
media type, its Accept: header asks for things like text/plain,
text/html, etc. (Or no Accept header is sent). Other than that it
sends the same HTTP request as in Case 1. The script at
SGMLOpen looks at the Accept: header, does the machine
equivalent of a sigh, and sends back an HTML response that
"You should obtain our fine SOCAT Content Handler, but in
the meantime, you are about to be automatically redirected to a
site that may be able to tell you more about the resource you
have requested. If it fails, you must obtain our fine SOCAT
handler to locate that resource". The user is then redirected to
http://www.sunsoft.com/uri-res/N2C/fpi:-//etc.etc.etc. This is
likely to fail.
Alternatively, the script could attempt to assist the SOCAT-
unaware software by doing the SOCAT work itself. It would fetch the
catalog from SunSoft, and follow any PUBLIC and DELEGATE entries
until it obtains the answer. It can then send the answer back to the
user. This imposes a noticible burden on the SGML Open server, but it
has the benefit of automating part of the process of maintaining the
Ron Daniel Jr. email: email@example.com
Advanced Computing Lab voice: +1 505 665 0597
MS B287 fax: +1 505 665 4939
Los Alamos National Laboratory http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM, USA 87545 obscure_term: "hyponym"