Re: How paf is implementing URNs and URCs today

Roy Fielding (fielding@beach.w3.org)
Mon, 17 Jul 1995 16:23:56 -0400


Message-Id: <199507172023.QAA22893@beach.w3.org>
To: Patrik Faltstrom <paf@bunyip.com>
Cc: uri@bunyip.com
Subject: Re: How paf is implementing URNs and URCs today 
In-Reply-To: Your message of "Sun, 09 Jul 1995 19:00:21 EDT."
             <v02110106ac260aceb613@[192.197.208.4]> 
Date: Mon, 17 Jul 1995 16:23:56 -0400
From: Roy Fielding <fielding@beach.w3.org>

I meant to respond to this last week, but it was stranded instead.

Patrik mentioned:

>The problem I see with Roys proposal is that it entirely uses
>the idea that the URC is a document and that you have to send
>it using the content-type header. I think the content-type header
>is necessary (but I think it should be names application/urc
>instead of being a new major type, but this is a different topic)
>when sending a URC with mail etc.

You don't have to -- you simply *can* do so.  That ability allows
you to separate URC indirection from the URN resolution mechanism.
Limiting URCs to a single media type assumes a single standard format,
which I do not think is desirable (or even possible, given the way
the world works).

>...
>I think you will attac the URC from two different angels:
>
>(1) You have a URN and want to have "the best URL".
>(2) You don't know anything but "...this latest chinese
>    chuisine I heard about...wounder if I can find
>    a URC for that...".
>
>(1) Can be solved with my proposal by using a scheme for the URN
>which as fast as possible makes you know the Whois++ server that
>have the URC on-line. This can be several servers sometimes.
>Because the centroid/referral idea might be too slow sometimes,
>we register publisher-IDs in DNS by using some scheme, for example
>what Michael Mealling have proposed, i.e. an inverted OID-number.
>When you have found the correct server, issue a normal Whois++
>query and you get the record back.
>
>The query can look like (on one line)
>
>template=urc and
>urn=URN\:OID\:1.3.6.1.4.1.1375.2\:931E7004E10819FCC5932944242A8DA41
>

Yes, that is one way to do a URN resolution.  In fact, you can do
exactly the same using the architecture I proposed:

PREFIX    REPLACEMENT                           AUTHORITATIVE
oid:      whois++:/template=urc/urn=oid:        Yes

Note that the only difference is where you bind the URN syntax
to the URN resolution service.  Your proposal binds it in the
specification; mine binds it in a client configuration table.

>(2) Can be solved by issuing a whois++ query somewhere in the
>whois++ mesh and using the normal Whois++ navigation techniques.
>A query might look like:
>
>template=urc and keywords=chinese and keywords=cuisine.
>

(2) can be "solved" using any query technique, assuming there exists
some database somewhere that holds the answer.  Thus, (2) is just
another URL scheme:

   whois++:/template=urc/keywords=chinese+cuisine

[note that I am using a fictional syntax -- any URL mapping will do].


 ....Roy T. Fielding  Department of ICS, University of California, Irvine USA
                      Visiting Scholar, MIT/LCS + World-Wide Web Consortium
                      (fielding@w3.org)                (fielding@ics.uci.edu)