Re: I-D: How Roy would Implement URNs and URCs Today

Daniel LaLiberte (
Tue, 18 Jul 95 17:00:27 CDT

Date: Tue, 18 Jul 95 17:00:27 CDT
From: (Daniel LaLiberte)
Message-Id: <>
To: Roy Fielding <>
Cc: (Daniel LaLiberte),
Subject: Re: I-D: How Roy would Implement URNs and URCs Today 
In-Reply-To: <>

This discussion, though it is getting rather philosophical, is actually
very relevant to the working group, so I'll continue.

Roy Fielding writes:
 > Yikes [*sound of train derailing in background*]... a URL is not
 > an expression, because it does not "result in some resource".  

Expressions don't have to "result in some resource".  Expressions can
be transformed into other expressions, hashed, compiled, interpreted,
or many other things.

 > An expression is obtained only when the URL is combined with an
 > Action (aka Method) like GET.  If you change the action (e.g., PUT),
 > the expression changes, but not the URL.

There is an implicit GET that goes along with most URL resolution, and
we agree that the combination is an expression.  In fact, we need a
way to represent the full combination of the method, the URL, and any
additional parameters that were used in resolving to the result, if
that is what is being done.  This full expression would be useful in
identifying the result for caching purposes, for example.

But expressions may have components that are expressions, and in this
case, a URL is an expression, I am arguing, that is interpreted partly
by the client (to pull out the DNS name if any of the server to
contact) and partly by the server, to find the resource on the server.

 > Identity and behavior are two orthogonal issues, and they must be
 > kept separate.  If an identifier implies behavior, then the resource
 > cannot be referenced independent of the desired action.

It's not so simple.  An identifier that implies absolutely nothing
would be useless - you would have no way to interpret it to find out
what it refers to.  There is a very good argument by Tim B.L. on this
subject at:
The conclusion is that a name is like an address if it helps you look
it up.  Otherwise, if you have a very abstract name that does not help
you look it up, searching for it becomes expensive at the very least.

An identifier with structure in it *may* be used to help look it up,
and in that sense the identifier is an expression and an address.  But
you could do anything else with the structured identifier too, either
ignoring the structure or using it in some other way.  The structure
of the identifier does *not* necessarily imply any particular
behavior.  With no structure, the identifier would be just an
amorphous blob and all you could do would be to search for something
identical to it somewhere.

(For the benefit of other readers:) Keep in mind that having a
structured identifier that is associated with some behavior to help
look it up (and therefore it acts partly like an address) does not
necessarily mean it would fail as a name.  Some indirection is
required in the resolution of a name to the physical location of the
referenced resource.  But the indirection could be present either as
an explicit result of the resolution or as in implicit part of the
resolution process.

 > As a crude example, let's consider a baseball bat.  You can identify
 > it via a name [Louisville slugger #26287635], 

How would such an identifier help you look it up amongst all
identifiers?  There is some structure that would help you.  All
identifiers might be subdivided into those that have "Louisville
slugger" in them and those that do not.  The number might be looked up
in a tree in which each level corresponds to a digit.  These ways to
look up the identifier are different behaviors made possible by the
structure in the identifier.

 > you can identify it via
 > a location [the third from the left, in the stack marked illegal], 

It should be obvious that this more specific location is strongly
associated with a procedure for finding the bat.  I.e. find the stack
marked illegal and then starting from the left, count out three bats.

 > and you can identify it via characteristics [yeah, the corked one].
 > Some methods are less useful than others, but they all allow you
 > to identify the intended resource.

The more abstract the description, as in describing the
characteristics, the more the lookup becomes a search.

 > In contrast, you can't identify a bat by describing the rules of
 > baseball.  You also can't identify a bat by pantomiming the swinging 
 > motion of a batter.  

These would obviously be inappropriate descriptions, too abstract to
be useful for an automatic lookup.  But not impossible.  One would
have to search through game rules and videos clips of games and do
complex reasoning to figure out what is being referred to.  A person
(suitably indoctrinated in American culture) could do it fairly

 > You can identify the concept (or class) of a
 > bat in this way, but not the actual resource.  

Ah, if you want a specific bat, you would have to do more pantomiming
and the resolver would have to do alot more library research.  OK,
we've stretched that one far enough.

 > Similarly, it is unsafe
 > to use an action specification as a means of identification -- imagine,
 > if you will, a murder trial where the only way to identify the
 > murder weapon is to make use of it in the same way as the murderer.

It is one thing to describe something by an action that was used to
create it, and another thing to use the very same description but not
reinvoke the same action.  In fact, a description of a knife used in a
famous murder, for example, invokes in the minds of imaginative
readers the scene of the crime, not that the murder takes place each

Daniel LaLiberte (
National Center for Supercomputing Applications