RE: Yaron.Redirect.Sec4LastPar

In a number of your comments, you suggest that we use the expression "blind
response" to characterize the 302 that you get back from a redirect
reference resource.  Can you say more about what you are trying to convey
with "blind"?  In this message, it looks as if it is supposed to contrast
with the 302 you would get back from a non-redirect-reference-resource.  How
is one of these responses more blind than the other? Or perhaps I'm just off
on the wrong track altogether.
 
Thanks.
 
--Judy

-----Original Message-----
From: Yaron Goland [mailto:yarong@Exchange.Microsoft.com]
Sent: Friday, February 11, 2000 2:47 AM
To: 'w3c-dist-auth@w3.org'
Subject: Yaron.Redirect.Sec4LastPar



The last paragraph of section 4 currently reads: 

Since a redirect reference resource is a resource, it can have its own 
properties and body, and methods can be applied to the reference 
resource as well as to its target resource.  The Apply-To-Redirect-Ref 
request header (defined in Section 11.2 below) is provided so that 
referencing-aware clients can control whether an operation is applied to 
the redirect reference resource or to its target resource.  The Apply- 
To-Redirect-Ref header can be used with most requests to redirect 
reference resources.  This header is particularly useful with PROPFIND, 
to retrieve the reference resource's own properties. 

Given the numerous changes I request in my comments the previous description
is no longer accurate. I also felt that it didn't provide a sufficiently
broad overview of the total functionality provided by redirect resources.
Below I provide several paragraphs that I suggest replace the previous one:

Redirect resources are resources and thus have their own state. However the
default response of a redirect resource to all methods is a 302 (Found). A
mechanism is needed that instructs the redirect resource to handle a method
directly rather than blindly responding to it with a 302 (Found). The
Apply-To-Redirect-Ref request header (defined in Section 11.2 below)
provides such a mechanism. 

For example, if a user issues a PUT request without the
Apply-To-Redirect-Ref request header then the redirect resource will respond
with a 302 (Found). However, if the redirect resource supports PUT and if
the requestor is properly authorized then a PUT issued to a redirect
resource with a Apply-To-Redirect-Ref header will result in the body of the
PUT request being stored for future response to a GET request, assuming the
GET has a Apply-To-Redirect-Ref header.

Please note that it is perfectly legal for the response to a request to a
redirect reference resource with the Apply-To-Redirect-Ref header to result
in a 302 (Found). In this case the 302 (Found) will not be a blind response
but rather will be the correct result of the method. Also note that such a
response would not include a redirect-ref header.

Received on Monday, 21 February 2000 14:33:25 UTC