RE: Issue: URI_URL, proposed changes

On the off chance that the details of this particular thread 
are probably becoming less interesting to anyone other than 
Julian and myself (:-), I'll just summarize my position:

- We should adhere to the RFC-2396 definitions of URI, URL, and URN,
since no problems with those definitions have been identified.  I do
not consider the fact that many people don't know/use those
definitions to be a problem, since the "commonly held" definitions
incorrectly consider URL and URN as partitioning the URI space
(i.e. problems have been identified with those "commonly held"
definitions).  We could try to make up yet another definition (that
is different from both RFC-2396 and the "commonly held" definitions)
but I see no point in doing so.

- We should use "URL" or "URN" in 2518bis whenever we are defining a URI
that has the semantic properties of a URL or a URN (as defined by 2396).

Specific responses to Julian's most recent comments embedded below.


   From: Julian Reschke []

   >    >    > URL-references).  We also have some URIs which name a
   >    >    > (in particular, lock tokens).  These should be called URNs.
   >    >
   >    >    I disagree. URLs are just a subset of URIs.
   >    >
   >    > We don't disagree there.
   >    RFC2518 has defined that lock tokens are identified by URIs with no
   >    restriction.
   > That is incorrect.  The first line of section 6.4 (that defines a lock
   > token URI) states: "The opaquelocktoken URI scheme is designed to be
   > unique across all resources for all time."  That makes an
   > opaquelocktoken URI a URN, and disallows using non-URN URIs.

   Wrong. Lock tokens are defined in section 6.3.

It is true that I quoted the wrong section.  But if you read section
6.3, it says the same thing, i.e.: "Lock token URIs MUST be unique
across all resources for all time."  That requires all lock token
URIs to satisfy the definition of a URN, which defines each lock 
token URI to be a URN.

   Section 6.4 defines a particular URI scheme that *can* be used to
   identify locks. It doesn't say that you need to use it to represent
   lock tokens :"This specification provides a lock token URI scheme
   called opaquelocktoken that meets the uniqueness
   requirements. However resources are free to return any URI scheme
   so long as it meets the uniqueness requirements."

And "meeting the uniqueness requirements" makes it a URN.

   >    An attempt to restrict lock tokens to specific URI types (are
   >    you trying to do that?)
   > No, I have (several times :-) emphasized that whether or not a URI
   > is a URL or URN does not require that the URI belong to a specific
   > URI type.  A URI in any scheme can be a URL, if it can be used to
   > apply a method to the resource identified by that URI.  A URI in any
   > scheme can be a URN if it satisfies the semantics requirement of a URN.

   I don't have any problem with that definition, however I'm sure
   that 99% of the readers will have the same definitions of URL/URN
   in mind when they read the spec, thus I fear unnecessary confusion.

Then all we have to do is explicitly repeat this definition in the
terminology section of the revised version of 2518, supplemented
with a reference to 2396.

   > This is an excellent example of why we should carefully use URI,
   > URL, and URN in the spec.  The statement in section 13.10 of the spec
   > is potentially ambiguous.  In particular, it states: "there is
   > typically only one destination (dst) of the link, which is the URI
   > where the unprocessed source of the resource may be accessed."  I
   > interpreted the "typically" to just be a qualifier of "only one".  It
   > sounds like you interpreted "typically" to also be a qualifier of the
   > phrase following the comma (while I interpreted it as a definition of
   > "link").  I believe my interpretation is correct, because without
   > that, the source link is basically useless ... "here's is a URI of the
   > source, but you can't use it for anything of interest".

   I have stopped thinking about the current wording for the source property
   long time ago. It doesn't make sense. It defines a resource property
   (DAV:source), which contains the name of the resource itself as an
   (DAV:src). It just doesn't make sense (one of the reasons I raised the
   in the issues document).

I don't see that this needs to be a complicated issue.  The DAV:src
field allows you to indicate that multiple resources depend
on this link, to give the client an indication of all the other
resources that would be affected by authoring the DAV:dst of that
link.  For Web content management, an example of this would be a
"template" resource from which a large number of other resources are
derived.  In this particular example, the number of other resources is
so large that I think it unlikely that a server would ever enumerate
them in the DAV:src field.  Because I think this will commonly be the
case, I'd be happy to deprecate the DAV:src field in the revision of
2518.  I personally would also like to rename the DAV:dst element to
just be a DAV:href element (for interoperation with the
DAV:expand-property REPORT), but that depends on whether any clients
are really using DAV:link and therefore expects DAV:dst (current
indications are that there are no such clients, so it would be
safe to make this change).

   >    Example: I might want to have a source link from
   >    to
   > 	   urn:ietf:rfc:3253
   >    Do you say this is wrong?
   > Yes, it is wrong if urn:ietf:rfc:3253 is not a URL (i.e. cannot be
   > used to apply methods such as GET and PUT to the resource that it
   > identifies).  But of course, urn:ietf:rfc:3253 easily could be a URL,
   > in which case it would be fine.

   I disagree. "urn:ietf:rfc:3253" is a URN for a resource. Actually,
   it is *the* URN endorsed by the IETF to identify the versioning
   spec.  If I want to signal that a document depends on a source
   which is a RFC, it completely makes sense to refer to it this way.

I believe the central value of the DAV:source field is that it allows
the client to perform methods on the resource identified by the
DAV:dst field to cause changes to the content of the resource.  This
value is not provided if the URI in the DAV:dst field is not a URL.
Having a URI that is not a URL would not provide a mechanism for
the client to effectively author the resource, which leads me to 
conclude that the spec should require the DAV:dst field to be a URL.

   BTW: Can you define what "applicable to methods such as GET and
   PUT" means?  Is "mailto:" a URL scheme?

It probably would be valuable to identify a minimal set of methods
that SHOULD be applicable to the DAV:dst URL, in order to provide for
interoperation.  Perhaps: "Either GET/PUT or PROPFIND/PROPPATCH SHOULD
be supported on the DAV:dst URL".

   >    >  "there is typically only one destination (dst) of the link,
   >    >   which is the URI where the unprocessed source of the resource
   >    >   may be accessed."

   ... it probably makes little sense to argue about this paragraph
   unless we can find somebody who can explain what was intended. The
   DAV:source property *as defined* doesn't make sense (see above).

Do you just mean the lack of utility of the DAV:src element?  That's 
easily resolved by deprecating the DAV:src element.  Then we just
rewrite that section as:
"The destination (dst) of the link is the URL where an unprocessed
source of the resource may be accessed.  Typically there is only one
DAV:dst element, but there could be multiple if the resource content
is derived from multiple inputs."

   > Whatever spec is defining the semantics of where that URI appears.  If
   > it is required to have the semantics of a URL, it is a URL.  If it is
   > required to have the semantics of a URN, it is a URN.  This gives the
   > client a vital piece of information about how it can use that URI.

   I agree that it makes sense to give the client this piece of
   information. I don't agree that just saying "URL" or "URN" will
   achieve this goal.

Think of it as a "public service" (:-).  If a large number of people
are using the terms URL and URN in confusing ways, we'll be a shining
example of useful and consistent usage of those terms.  The W3C "URI
interest group" can then focus on debating details of urn: scheme
registration (:-).

   > As Larry indicated, the concepts of a URL and URN have fuzzy
   > boundaries.  If something in theory would allow you to locate
   > something, but you don't have the locator software installed on your
   > machine, is it still a URL?  (I say, yes).  If something in theory

   OK, can you give an example for a URN-typed URI which in *theory* can't
   located by some dictionary mechanism? It's not globally unique by magic
   it usually depends on naming authorities (DNS, phone numbers),
   (urn scheme, ISBN) and the like.

Exactly.  As indicated earlier, something doesn't become a URN or a URL
by some syntactic magic.  It becomes one because the implemented client
and server mechanisms make it one.

   > could be located, but no software has ever been written to locate it
   > using that URI scheme, is it a URL?  (I say, no).  But most cases are
   > clearer.  The point is, what can a client assume.  Can it assume that
   > it should be able to apply methods to the resource through that URI?

   But what is this knowledge good for? Unless the client happens to
   *know* the URI scheme, it won't be able to do anything useful with
   the URI (other than use it as identifier), even if it knows it to
   be a "locator".

Of course a particular client may not have the software to access that
URL, or the server that should be responsible for applying methods to
that resource may not actually do so.  What we are trying to avoid is
having implementors misunderstand the semantics of a particular field.  This
gives the client and server writers essential guidance wrt what kind
of URI they should allow in a particular field.  With the example above,
if we decide that the DAV:dst field should contain a URL, then a server
should not store a urn: URI that they know is not commonly supported
by clients and servers to apply methods to that resource.

   > Neither RFC-2396 nor I have ever maintained that the URI space is
   > *partitioned* into "locatable" (URL) and "naming" (URN).  In each of
   > my messages in this thread, I have emphasized the opposite, i.e. that
   > a URI can be a URL, a URN, both, or neither (and quoted from 2396
   > where it explicitly states that these concepts overlap).

   Yes. However, as the ID mentioned states, people *think* that there
   is a partitioning. That's a problem that RFC2396bis should
   solve. We should stay out of this business.

I disagree.  If some people are using a common term in a confusing and
logically inconsistent way, and if there is a standard (that was
reviewed and accepted by the IETF), then we should just emphasize in
the revision of 2518 that we are using the standardized definitions
(and repeat those definitions in our spec).  An analogy is the term
"or".  In popular culture it is ambiguously used to mean either
"exclusive or" or "inclusive or".  This doesn't mean we can no longer
use the term "or" in formal documents.  It just means that we should
emphasize that we are using the standard formal meaning, not the informal

   > I am using "locate" as it is defined for URL in 2396, and "name" as
   > it is defined for URN is 2396.  These are well defined terms in this
   > context (i.e. "locate" means "can be used to apply a method to the
   > resource identified by the URI", and "name" means "provides a globally
   > unique name for the resource identified by the URI").

   Again: what's the difference between "naming" (URN) and "identifying"

Again: I am just using the terms as they are used in 2396.  All UR*I*s
"identify" a resource.  All UR*N*s "name" a resource.  All UR*L*s "locate"
a resource.  And of course, these are not the universal definitions
of these terms.  They are just how they are used in 2396.

   Can you give an example of a URI that identifies, but not "names" a

Just repeating the example from the previous messsage, identifies a resource,
but does not name ("provide a globally unique name for") that resource,
because I have used MOVE to cause that URI to identify different
resources at different times.

   >    Resources never are *available* at a URI.
   > That will come as a surprise to the authors (and reviewers) of
   > RFC 2518 (:-).  In the section we have been discussing, and which
   > I have been quoting) states: "A resource may be made available
   > through more than one URI."

   Another thing we may want to fix.

If it ain't broke, don't fix it (and in this case, if it ain't broke,
don't break it :-).

   >    *Representations* of resources may be available. I think you are
   >    saying that any URI that can be used to locate a representation of
   >    a resource is a URL.
   > I am just using terminology in the same way it is used in
   > 2518.  One can certainly make the statement more detailed in
   > the way you have above, but I think the 2518 usage is fine.

   Probably not. People may get the impression that WebDAV somehow
   allows to do something HTTP can't (and doesn't attempt to). HTTP's GET
   retrieves *representations* of resources. WebDAV doesn't change that.

But WebDAV isn't just talking about GET ... it also talking about
PROPFIND and others.  Saying that a resource is available says that
there are methods that can be applied to that URI that will not fail.
In particular, some resources that are "available" do not support
GET, so we are not talking about the "availability of the representation".

   For instance, GET/PROPFIND followed by PUT/PROPPATCH is not
   guaranteed to do the same thing as COPY (even when not taking
   versioning/acl into account).

"Availability" says nothing about the semantics of successive operations.
It just says that a method can be applied to that URI and succeed.

   >    That may be technically correct (so *I* can basically turn every
   >    URN into a URL by implementing a resolver for the scheme).
   > And if such a resolver becomes so widespread that a client can
   > reasonably count on it being available, it is a URL.

   Who is the authority I can ask whether a particular URI scheme can
   "now" be considered a URL? Actually, if Microsoft decides not to
   support "gopher:" anymore -- does the gopher URI loose it's

Is indicated earlier, this is not a formally demonstrable property
of a URI (such as its syntax).  It is a qualitative property, and there
will be grey areas.  And yes, if a URI scheme is no longer widely
implemented, the URIs in that scheme are no longer URLs.  And similarly,
if a urn: scheme is widely implemented to not provide globally unique
naming, then a URI in that urn: scheme would not be a URN.  The concepts
of URN and URI are worthless if they just refer to some syntactic
notion (e.g. "has a scheme name that begins with the characters 'u',
'r', and 'n').

   >    If you agree that a HTTP URL can be used to identify a lock token,
   >    thus it *is* both a URN and a URL, could you please give an example
   >    of a HTTP URL that doesn't share these properties (thus *isn't* a
   >    URN)?
   > Sure.  I personally
   > have associated that URL with different resources over time, because
   > of various bad interactions with locking (at least, I think that was
   > the problem).  If that resource had a URN property, such as a
   > DAV:version-history, you would have been able to notice as much.
   > The same is true for most (probably all) resources on
   > (although there are some links to some http
   > URNs in the namespace.

   Well, that's partly a question of how you define a resource. Note
   that even though a HTTP resource is implemented inside a specific
   HTTP server, that doesn't necessarily mean that it changes just
   because internally the implementation of the resource changed.

That is of course true.  Just like the concepts of a URN and URL, the
concept of "object identity" has fuzzy boundaries (in all domains,
not just IETF protocols).  As we introduce more advanced protocol
funtionality (versioning, binding), these boundaries start to get
firmed up though.  In particular, those protocol extensions make it
clear that MOVE associates an existing resource (with a given identity)
with a different URI, while COPY creates a new resource (whose identity
is different from the resource that was the source of the COPY).


Received on Sunday, 14 July 2002 11:46:09 UTC