# Re: How paf is implementing URNs and URCs today

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

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Dirk.vanGulik: "Re: URN Proposals: What they have in common"
- Previous message: Leslie Daigle: "yet a further other revision of the URI charter (proposed)"
- In reply to: Patrik Faltstrom: "How paf is implementing URNs and URCs today"

    Message-Id: <199507172023.QAA22893@beach.w3.org>

    To: Patrik Faltstrom <paf@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)

- Next message: Dirk.vanGulik: "Re: URN Proposals: What they have in common"
- Previous message: Leslie Daigle: "yet a further other revision of the URI charter (proposed)"
- In reply to: Patrik Faltstrom: "How paf is implementing URNs and URCs today"