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.

Jon

========================================================================

Date: Fri, 22 Nov 1996 13:42:04 -0700
From: Ron Daniel <rdaniel@acl.lanl.gov>
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 
  Manual//EN
(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
    for now.
Thus, our example FPI would yield a URN like:
  fpi:-//Sun%20Microsystems::SunSoft//DOCUMENT%20Solaris%20
  2.5%20User%20Manual//EN
(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 
Manual//EN
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:

Accept: application/socat
GET /uri-res/N2C/fpi:-//Sun%20Microsystems::SunSoft//DOCUMENT
    %20Solaris%202.5%20User%20Manual//EN HTTP/1.0
(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:

Content-type: application/socat
DELEGATE  -//Sun Microsystems::SunSoft//  
          http://www.sunsoft.com/sunsoft.socat
DELEGATE -//Sun Microsystems
          http://www.sun.com/suncat.socat
(Not sure of the exact SOCAT format, but the idea should
be clear).
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
	DELEGATE -//  
                 http://bigcat.sgmlopen.org/fullcatalog.socat
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
	DELEGATE -//
                 http://bigcat.sgmlopen.org/uri-res/N2C/%!uri
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:
<A HREF="fpi:-//Sun%20Microsystems//fun%20stuff%20here//EN">
  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 
says:
"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
big catalog.


Comments?


Ron Daniel Jr.                       email: rdaniel@lanl.gov
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"

Received on Tuesday, 3 December 1996 12:09:01 UTC