# Re: URN/URL model and typing

Mitra (mitra@path.net)
Thu, 3 Jun 1993 16:26:20 GMT

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Keith Moore: "Re: URLs and types: concentrate on FTP"
- Previous message: Larry Masinter: "URLs and types: concentrate on FTP"
- Maybe in reply to: Chris Weider: "URN/URL model and typing"

    From: mitra@path.net (Mitra)

    Subject: Re: URN/URL model and typing

    Date: Thu, 3 Jun 1993 16:26:20 GMT

    Message-Id: <C820Bw.DxJ@pandora.sf.ca.us>

Chris

In the simplest case, a document being available in only one type its
easy. We have a URN, a URL and a Type, and your model works fine.
However in the case of a document being available in multiple types we
have to choose whether a URL refers to the content or the variant.

In the table below I'm using the term variant to mean an instantiation
of a document with a particular type. The same problems may occur with
other variants (e.g. version, coding, language)

URN refers to URL refers to URN dereferenced to Retrieve with
============= ============= =================== =============
a) content content list of URLs {URL,type}
b) content variant list of {URL,Type} {URL}
c) variant variant list of {URL}s {URL}

Case c can probably be ruled out because it removes the ability to
compare documents based on content.

In case a, we would typically find a documents URN, look it up to get a
list of URL's then ask each URL for the types they support, then
retrieve with a URL/Type pair.

In case b, we would find a documents URN, then get back a list of
URL's along with the type information for each URL, then retrieve using
the URL.

Looking at how existing systems do this...

In Gopher, the selector string often contains an implicit type itself
and is always passed from client to server with a type. The client
passes back the Selector string, and does not need to select a variant.

In Gopher+, the selector string refers to the content, and is returned
with a list of types (or in gophereeze "Views"), the client requests
with a {URL,type} pair

In HTTP (WWW's protocol) the URL refers to the content, the client
negotiates its preferred types, and then selects with a URL - the server
chooses which variant to send based upon the negotiation, so this is
still implicitly selecting with a URL,type pair.

In FtP, the URL refers to the variant - i.e. the file.

I believe both schemes are workable, I do not believe we have a workable
solution if we dont know whether a URL refers to a variant or a
collection of variants. If we do it on a name-space basis, then it will
have to be explicitly coded into clients for each name-space, or when we
pass URL's around we will need to be able to specify whether asking for
a list of types is a meaningfull exercise.

- Mitra

- Next message: Keith Moore: "Re: URLs and types: concentrate on FTP"
- Previous message: Larry Masinter: "URLs and types: concentrate on FTP"
- Maybe in reply to: Chris Weider: "URN/URL model and typing"