Re: FPIs to URNs

> From: bosak@atlantic-83.Eng.Sun.COM (Jon Bosak)
> . . .
> 
> Ron followed up with the message below, which I quote with permission.
> . . .
> 
> ========================================================================
> 
> Date: Fri, 22 Nov 1996 13:42:04 -0700
> From: Ron Daniel <rdaniel@acl.lanl.gov>
> Subject: FPIs and URNs - resolution possibility
> 
> . . .
>
> 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 IANA-registered MIME media type for SGML Open catalogs is:
	Application/SGML-Open-Catalog
as opposed to the "application/socat" shown above.

> 
> 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).

(Pretty close, though each of the two arguments to the DELEGATE entry
should be quoted.)

> 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?

While it has not been discussed and is therefore not out of the
question, I suspect SGML Open would have resource problems and
perhaps jurisdiction problems doing this.  Since the GCA is in
line to be endorsed as the Owner Identifier Registrar, they may
be a more obvious choice.

However, I question why the design requires one "big catalog".  With
the use of DELEGATE and CATALOG entry types (both of which are *not* in
the current TR9401:1995, though both of which are extensions currently
supported by SP and both on the list of things currently being
considered for the next amendment to TR9401), a hierarchy of smaller
potentially distributed (and possibly mirrored) catalogs would seem
feasible, more effective, and more manageable.  Given that "distributed
processing and distributed resources" is one of the key models of the
internet, it seems only reasonable to adopt this model for FPI
resolution too.  (I do admit to lack of experience and expertise in the
area of web-wide FPI resolution, so I welcome statements of proof that,
in fact, large monolithic catalogs are required and/or desirable.)

> 
> 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).

I'm not entirely sure I understand the %!uri bit.  While I can
certainly appreciate the power of grep and regexp like things
happening in catalogs, as the person most responsible for trying
to get all SGML Open members to support our Resolutions, I'm also
quite nervous about adding complexity to things.  If we can avoid
these sorts of complexity, it will be much more likely that we can
get a timely amendment to TR9401 passed and that there will be a
greater level of support of it in the SGML vendor community.

In short, though it's certainly not my call alone, for me to be
able to support %!uri in SO catalogs, I'd need to be convinced
its need is crucial and undeniable and that its implementation
will be supported by a majority of vendors.  If we can live 
without it, I'd probably want to live without it.

> 
> Case 3: SOCAT-unaware, URN-savvy client
> =======================================
> 
> . . .
> 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 Wednesday, 4 December 1996 11:34:06 UTC