W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > July to September 1998

Re: Direct and Indirect References

From: Roy T. Fielding <fielding@kiwi.ics.uci.edu>
Date: Thu, 23 Jul 1998 02:15:49 -0700
To: Judith Slein <slein@wrc.xerox.com>
cc: John Stracke <francis@netscape.com>, w3c-dist-auth@w3.org
Message-ID: <9807230216.aa02943@paris.ics.uci.edu>
>One question to ask is whether we gain any significant functionality by
>requiring support for direct as well as indirect references.
>Another is what sorts of references are supported by the file systems and
>DMSs that are likely to stand behind WebDAV servers.  How easy or difficult
>will it be for these systems to map their referencing to what WebDAV
>provides?  If we can count an most having support for indirect references,
>there is less reason to provide direct references in WebDAV.  If
>significant numbers of these systems support only direct references, then
>maybe there is good reason for WebDAV to support direct references.

I can describe what Apache already does using configuration files,
which won't go away even after WebDAV is implemented.  I'd like to
have all three forms of names (direct, indirect, and actual) available
for manipulation via WebDAV.

The goal of a direct reference (what Apache terms an internal redirect)
is to provide the same source at multiple names in the namespace.
The most frequent use of this is for content negotiation, where a request
on a basename automatically creates a mapping to all other names in
that directory with the same basename.  Likewise, we can do the same
thing with derived content.  A less often used purpose, though
more applicable to WebDAV, is to maintain separate resource trees so
that access can be more easily controlled by URL.  For example, by
placing all of the writable resources (the source) under one URL tree
and all the read-only handles for those resources under a different
URL tree, it is easier to maintain the ACLs.  Of course, this isn't
an ideal way to implement WebDAV for these resources, but it is one
that works on systems where per-URL ACLs are inconvenient.

Note that this functionality cannot be implemented by external
redirects (indirect references) because the actual destination
resource may be under different access restrictions than the direct
reference handle.

Regarding terminology, "direct reference" brings to mind a normal URL,
whereas "indirect reference" is using one URL to access another resource
indirectly (what you are terming a direct reference).  Since that is
very confusing, I suggest instead that they be referred to as
externally-redirecting names and internally-redirecting names.

Received on Thursday, 23 July 1998 05:17:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:17 UTC