# Re: The URN: wrapper and URLs...

John Curran (jcurran@nic.near.net)
Fri, 15 Oct 1993 21:35:24 -0400

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Rob Raisch, The Internet Company: "Re: The URN: wrapper and URLs..."
- Previous message: Larry Masinter: "Re: The URN: wrapper and URLs..."
- In reply to: Rob Raisch, The Internet Company: "Re: The URN: wrapper and URLs..."
- Next in thread: Peter Deutsch: "Re: The URN: wrapper and URLs..."

    Message-Id: <9310160135.AA02704@mocha.bunyip.com>

    To: "Rob Raisch, The Internet Company" <raisch@internet.com>

    Subject: Re: The URN: wrapper and URLs...

    In-Reply-To: Your message of Fri, 15 Oct 1993 13:29:49 -0700.

                 <Pine.3.03.9310151349.C12629-c100000@hmmm.internet.com>

    Date: Fri, 15 Oct 1993 21:35:24 -0400

    From: John Curran <jcurran@nic.near.net>

--------
] From: "Rob Raisch, The Internet Company" <raisch@internet.com>
] Subject: Re: The URN: wrapper and URLs...
] Date: Fri, 15 Oct 1993 13:29:49 -0700 (PDT)
]
] On Fri, 15 Oct 1993, Michael Mealling wrote:
]
] > Personally the biggest gain I think we stand to get from URL: is that
] > we can come up with new schemes without having to notify everyone's
] > software that this is a URL and not a URN. A good example is this:
]
] But, Michael, we need to inform everyone's software how to retrieve the
] URL from the URN, no?
]
] Both the URL and the URN are fundamentally mechanisms to retrieve
] resources from the network. In the first case, the resource is data, and
] in the second, the resource is a list of URLs.

Good evening all,
I am in favor of explicit labelling of UR* strings. In order to explain
why, I have to create fairly hypothetical situation. (One might even use
the word "contrived"...) Please do not presume that I am busily coding
away on this application:

- For one reason or another, I need to have very simple client code.

- I want these clients to able to access a vast amount of information
which is only available using a variety of access methods.

- Rather than implementing each access method in the client, the clients
talk to a "XYZ server".

- XYZ server, if handed a commonly known URL, will return the appropriate
data stream to the client.
- URN's, on the other hand, are handed to a very different server which
I *pay* for the priviledge of using... different clients use different
sets of URN resolution services based on rather individual criteria.

I have a need of knowing which "strings" are URL's and which are URN's.
Now, if we don't label URL's (but do label URN's), I have the following
choices:
1) Pass all non-URN's to URL server, and spit out "Unknown access method"
when the world starts using URC's or URG's or ... I'd really
rather know it was an "Unknown Uniform Reference", since an unknown
access method can be fixed at the server, yet new uniform references
will almost certainly require significant client support.

2) Keep a table of "known" url access methods, and only give those
to the URL server. Sounds to me like I'm going to be updating
that table quite a bit, and a lot of users are going to skin me
because their client s/w now has to be "tweaked" occasionally.

3) Fight to make sure that nothing more than URLs and URNs ever get
defined...

/John

- Next message: Rob Raisch, The Internet Company: "Re: The URN: wrapper and URLs..."
- Previous message: Larry Masinter: "Re: The URN: wrapper and URLs..."
- In reply to: Rob Raisch, The Internet Company: "Re: The URN: wrapper and URLs..."
- Next in thread: Peter Deutsch: "Re: The URN: wrapper and URLs..."