RE: Bodies of redirect reference resources

I was just looking back at my notes from the November 1999 IETF meeting.
This change was made in response to comments there that we should make
redirect references analogous to collections with respect to an entity-body.
It should be allowed.  Someone might find a use for it in some application
even if we haven't thought of one.  This would mean that PUT and GET (and,
it was suggested, POST) would work with Apply-To-RR.

My own preference would be to return to our earlier position that redirect
references cannot have content.  GET and PUT must fail with Apply-To-RR.  I
think this would be less confusing.

--Judy

> -----Original Message-----
> From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
> Sent: Sunday, January 30, 2000 11:45 PM
> To: w3c-dist-auth@w3.org
> Subject: Re: Bodies of redirect reference resources
> 
> 
>    From: Joe Orton <joe@orton.demon.co.uk>
> 
>    To me, the "reference resource" should be a resource in 
> its own right: a
>    conceptual thingy which say "No, go to URI Y instead", 
> when you apply HTTP
>    methods to it.
> 
> I agree.
> 
>    If you are trying to store an entity-body at URI X along
>    with this RR, then that is two separate resources, one 
> which has the "No,
>    go to URI Y instead" semantics, and one which has the 
> standard "I can
>    store an entity-body with PUT and give it back with GET" semantics.
> 
> The presence of properties makes this a bit more ambiguous.  
> If you try
> to get the properties of X, it will say "no, go to URI Y 
> instead".  But
> the RR X does have properties of its own, that you can obtain with the
> Apply-To-RR header.  By analogy, it would be reasonable for X to have
> an entity-body that you can obtain with the Apply-To-RR header. 
> This doesn't convince me that RR resources should have entity-bodies,
> but it is argument that it is reasonable to do so.
> 
>    Unix symlinks have precedent again here: you can't store a 
> file in a
>    symlink. Windows shortcuts are the same, I expect.
> 
> Yes.  I think this is a good argument against giving them a body ...
> people will find this confusing, and experience in other 
> domains indicate
> that an entity body is not needed or appropriate for references.
> 
>    >    Is there a need to store an extra resource along with every RR
>    >    resource?
>    > 
>    > The extra resource is minimally needed to store the 
> information about
>    > what other resource to redirect to. 
> 
>    What "information about the other resource" do you want to 
> store? Why
>    can't you store it in the properties of the RR? To me the 
> only vital
>    information you want to store in the RR is the target of 
> the reference,
>    which you have as the DAV:reftarget property.
> 
> I misunderstood you the first time.  By "extra resource", I meant the
> RR resource itself.  You were talking about an extra resource 
> *in addition*
> to the RR resource.  I agree that there is no need for an 
> extra resource
> beyond the RR resource.  But the RR resource could have an 
> entity body,
> in addition to its properties.
> 
>    > We could do any of:
>    > - get rid of the "an RR resource can have a body" statement
>    > - get rid of this statement and change the example to say
>    >   the PUT MUST fail.
>    > - keep the statement, and change the example to say the PUT
>    >   updates the body  of the RR resource.
> 
>    > That's one vote for choice #3.  Anyone else?
> 
>    Either you misunderstood, or miscounted :)
> 
> Neither ... mistyped (:-).
> 
>    I vote #2: get rid of any mention of "resource body",
>    and have PUT + GET fail with 4xx if the Apply-To-RR header 
> is included.
> 
> So we've got a vote for *2*.  Anyone else?
> 
> Cheers,
> Geoff
>

Received on Tuesday, 1 February 2000 11:07:26 UTC