Subject: RE: Direct References in the Advanced Collections Requirements

From: "Slein, Judith A" <[email-masked]>
Date: Fri, 18 Sep 1998 16:34:10 -0400

We are still wrestling with the terminology for this distinction.  I've had
objections in private correspondence to Client-Side / Server-Side, because
they seem to imply something about the location of the requester that
irrelevant to the distinction we are trying to make.

Here are a couple of other possible pairs of terms:

Transparent Reference (one that the user agent can see) / Opaque Reference
(one that is hidden from the user agent)

Visible Reference / Hidden Reference

Manual Reference (one that the user agent has to dereference) / Automatic
Reference (one that is dereferenced automatically with no action by the user
agent needed)

Or stick with Indirect Reference / Direct Reference

Any preferences among these, or other suggestions?

Judith A. Slein
CR&T/ADSTC
[email-masked]
8*222-5169

> -----Original Message-----
> From:	Slein, Judith A 
> Sent:	Tuesday, September 15, 1998 3:24 PM
> To:	'WebDAV'
> Cc:	Slein, Judith A
> Subject:	Direct References in the Advanced Collections 
> Requirements
> 
> I would like to propose the following changes to the Advanced 
> Collections Requirements.
> 
> 1. The requirements will use the following terminology and 
> definitions instead of the current indirect / direct 
> references terminology:
> 
> Client-Side Reference:  A reference that must be resolved by 
> the client.  Any method applied to a Client-Side Reference 
> affects the reference only, not its target.  To affect the 
> target of a Client-Side reference, the client must resolve 
> the reference and operate directly on its target.
> 
> Server-Side Reference:  A reference whose existence is, in 
> general, hidden from the client.  For the most part, methods 
> applied to a Server-Side Reference affect its target, not the 
> reference itself.  The server resolves the reference and 
> applies the method to its target.
> 
> Rationale:  Roy Fielding has been requesting for some time 
> that we change the terminology.  This is in part an attempt 
> to satisfy his request.  In addition, the current 
> requirements document defines a Server-Side Reference as one 
> for which all operations are passed through to its target.  
> It is clear from the discussion at IETF 42 that this 
> definition is too strong.  It was proposed there that DELETE, 
> COPY, and MOVE are not passed through to the target.  I would 
> like *not* to make a commitment in the requirements about 
> exactly which operations get passed through and which do not, 
> but still express the general intent of Server-Side 
> References.  For most operations, they give a client the 
> impression that it is operating directly on the target, 
> hiding the existence of the reference from the client.
> 
> 2. The requirements will give the following rationale for 
> supporting both sorts of reference.
> 
> Client-Side References provide the basic benefits desired 
> from referencing:  They allow multiple collections, on the 
> same or different servers, to share a single resource, in 
> such a way that any change to the resource will automatically 
> be reflected in the collections that contain it by reference. 
>  They provide this benefit at very low cost to the server, 
> and with no security implications.
> 
> Server-Side References hide the existence of the reference 
> from the client, thus simplifying for the client operations 
> through the reference, and making them more efficient.  Fewer 
> round trips are required to accomplish the same task than 
> with Client-Side References.  Servers already support 
> server-side references, generally through configuration 
> files; exposing this capability through the protocol seems desirable.
> 
> Judith A. Slein
> Xerox Corporation
> [email-masked]
> (716)422-5169
> 800 Phillips Road 105/50C
> Webster, NY 14580
>

---

From: John Stracke <[email-masked]>
Date: Fri, 18 Sep 1998 13:51:33 -0700

> irrelevant to the distinction we are trying to make.

I disagree on this point, actually; in the HTTP conversation, the entity
issuing the request is the client by definition, regardless of where that
entity is running.

> Or stick with Indirect Reference / Direct Reference

I still prefer these two, myself; I'd go along with Client-Side/Server-Side,
but the others seem too contrived.

--
/====================================================================\
|John (Francis) Stracke    |My opinions are my own.|S/MIME supported |
|Software Retrophrenologist|=========================================|
|Netscape Comm. Corp.      | Organ transplants are best left to the  |
[email-masked]      |  professionals.                         |
\====================================================================/
New area code for work number: 650

---

From: "Roy T. Fielding" <[email-masked]>
Date: Fri, 18 Sep 1998 18:16:29 -0700

My problem with Indirect Reference / Direct Reference is that an indirect
reference in the general terms of computer assembly languages means exactly
what WebDAV-AC is calling a Direct Reference, thus reversing the definition
of (what used to be) a commonly understood term.

My preference would be to use terms that correspond to the nature of
the resource being defined.  Oddly enough, the best fit would be

    redirect reference / indirect reference

but I wouldn't be surprised at the confusion that would result from
swapping the association of indirect reference.  That is why I suggested

    reference / alias

since that at least uses two commonly understood names consistently.
I am not concerned with the precise fit with Apache's config language,
since we have many different configuration directives that allow the
definition of the conceptual equivalent of aliases.

Client-Side / Server-Side is a bit confusing since it has more to do
with the effect of accessing the resource than the resource itself,
though I do prefer it over the current definitions.

>Reference (one that is dereferenced automatically with no action by the user

All of these are moving in the wrong direction in terms of understanding
the specification.  I would prefer Reference / Alias over anything that
overemphasized information hiding.

BTW, thanks for organizing the discussion -- it really helps to clarify
the issues.

....Roy