RE: Issue #2 Definition of the term Referential Resource

RFCs are not written for users.
RFCs are not written for academics.
RFCs are written for implementers.

While I agree that from an academic point of view there is no difference
between direct and indirect references the RFC isn't interested in the
academic point of view. It is strictly interested in good implementation and
the implementation here is crystal clear, 3xx. We need to make that
absolutely clear. Any other distinction makes for a good article in the
Journal of the ACM, not an IETF RFC.

	I'm looking out for the implementers here,


> -----Original Message-----
> From: Jim Davis []
> Sent: Friday, February 26, 1999 10:38 AM
> Subject: Re: Issue #2 Definition of the term Referential Resource
> At 10:36 PM 2/21/99 PST, Yaron Goland wrote:
> >
> >(Issue #2) Section 2- Definition of the term Referential 
> Resource - It
> >should be explicitly pointed out that this is a new resource 
> type. I think
> >this would make the definition clearer.
> Good idea
> >	The term "body" as used in RFC 2068 and 2518 refer 
> exclusively to
> >messages, not resources. Hence the phrase "body of its own" 
> does not have a
> >definition in either spec.
> I agree.
> > First off, I think
> >we need to cease viewing direct references and redirect references as
> >children of the same mother. They are two very different 
> creatures with
> >largely unrelated functionality. It would probably be in 
> everyone's interest
> >if they were given names which shared no common words.
> I am afraid I don't agree, and you are wrong to assume that 
> our inspiration
> comes from file system links.  Indeed, I was more inspired by 
> the ability
> of some Web servers to define aliases by means of suitable 
> statements in
> their configuration files.  The purpose of MKREF is to allow 
> ordinary web
> clients to cause such behavior without having to be superuser 
> on the web
> server.
> From the standpoint of a human using a web client, there's no 
> important
> difference in behavior between
>  GET foo.html
>  GET direct-to-foo.html
>  GET redirect-to-foo.html
> In all three cases, the human ends up seeing the contents of 
> the resource
> foo.html  (in the third case, the client app processes the 
> 302 automatically).
> We have direct references because that's (I claim) what most 
> applications
> want. We have redirect references because in the most general case,
> implementing direct references is either expensive or opens 
> security problems.
> these are differences in the mechanism by which the desired end is
> achieved, not differences in the ends.  We should follow good 
> CS practice,
> and identify these abstractions by their intended purpose, not the
> mechanism by which such purpose is realized.
> [PS thanks for all the thoughtful comments.  I have thus far 
> only answered
> the easy ones.  more on Monday.]

Received on Friday, 26 February 1999 13:52:58 UTC