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

RE: Direct and Indirect References

From: Slein, Judith A <JSlein@crt.xerox.com>
Date: Fri, 24 Jul 1998 11:10:07 -0400
Message-ID: <201BB34B3A73D1118C1F00805F1582E8B76BEB@x-wb-0128-nt8.wrc.xerox.com>
To: "'Roy T. Fielding'" <fielding@kiwi.ics.uci.edu>
Cc: John Stracke <francis@netscape.com>, w3c-dist-auth@w3.org
Thanks for the information about Apache.

The new collections requirements draft has new text related to direct
references.  We've stayed with the direct / indirect terminology because
internal / external already has a different meaning attached to it in
WebDAV:

Here are the definitions:

        Direct Reference
           A reference that has the property that operations on it are
           passed through to its target
        Indirect Reference
           A reference that has the property that operations on it do
           not affect its target

Some rationale:

	  Similarly, both indirect and direct references may be useful.
Each
        of these types of references is implemented in existing systems.
        Existing HTTP servers are capable of supporting both types of
        references.  In effect, indirect references give clients access
to
        the reference itself, and allow the reference to bear
properties.
        Direct references, once created, simplify access to the target
        resource by hiding from clients the fact that there is a
reference
        mediating between the client and the target resource.  Although
it
        is desirable for WebDAV to support both indirect and direct
        references, the difficulties of supporting direct references
make
        it unlikely that they will be supported in the short term.

And 3 new requirements that explain how direct references differ from
indirect references.

     3.1.15 Operations on a direct reference, except for creation and
            deletion of the reference itself, are passed through to its
            target resource.

        This requirement is really a restatement of the definition of
        a direct reference.  There are several reasons for wanting to
        support this sort of resource.
        Direct references simplify operations for clients, hiding from
them
        the fact that a reference is mediating between their requests
and
        the target resource.

        Many existing systems, including HTTP servers, implement direct
        references.

        Supporting direct references does introduce issues that make it
        unlikely that WebDAV will support them in the short term.
Passing
        operations through to the target resource exposes servers to the
        risks of circular references and long chains of references that
        refer to other references.  In addition, passing operations
through
        to the target resource can be problematic if the referential
        resource and the target resource are on different servers.
Issues
        about what credentials to use would need to be addressed.

     3.1.16 For any resource, it is possible to discover whether it is a
            direct reference.

        Since the behavior of direct references is radically different
from
        the behavior of indirect references, it is important for clients
        to be able to discover whether they are operating on a direct
        reference.  The client must have a way of finding out whether
the
        properties it sets will be stored on the reference or on its
        target, etc.
 
     3.1.17 It is not possible for a client to set or view properties of
            a direct reference, distinct from those of its target.

        Again, this follows from the definition of a direct reference.
        Since all operations except creating the reference and deleting
        the reference are passed through to the target, the client can
        operate only on properties of the target.

Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580


> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@kiwi.ics.uci.edu]
> Sent: Thursday, July 23, 1998 5:16 AM
> To: slein@wrc.xerox.com
> Cc: John Stracke; w3c-dist-auth@w3.org
> Subject: Re: Direct and Indirect 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.
> 
> ....Roy
> 
Received on Friday, 24 July 1998 11:11:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:47 GMT