- From: Juergen Reuter <reuterj@ira.uka.de>
- Date: Mon, 07 Feb 2000 14:50:31 +0100
- To: WebDAV WG <w3c-dist-auth@w3.org>
- cc: reuterj@ira.uka.de, jjh@ira.uka.de
Following the working group's last call for comments, below is the first part of a review of the Redirect Reference Resources Protocol. It covers the abstract, tabe of contents and chapters 1 to 6 of the protocol. ******** > Abstract > ... > The related specification, RFC xxxx, defines bindings, and the BIND > method for creating them. The problem of circularity in cross-refencing other specifications has already been discussed for the bindings protocol and, as far as I understand, holds true for this protocol as well. > Creating a new binding to a resource > indirectly creates one or more new URIs mapped to that resource, which > can then be used to access it. Servers are required to insure the > integrity of any bindings that they allow to be created. IMHO, issues that refer to the bindings protocol should not appear in this protocol and not at all in the abstract, unless they are needed for clarification of the definition of redirect reference resources in contrast to bindings. To avoid circular cross-references, this can only have informational character to the reader, but no specificational character. If, nevertheless, the contrast to bindings is to be revealed, it should be made obviously using language like "while bindings are useful for ..., redirect references are nice when ...", or "unlike bindings, which ..., redirect references do ...". Anyway, the above section is too specific to appear in an abstract. What I am missing are some introductional notes on redirect references themselves; that they have already been specified long ago in HTTP/1.0 (or even before?) and are today frequently used throughout present HTTP servers' configuration capabilities (this is probably what the specification calls "ordinary HTTP 1.1 redirect"); but that until now, there is no standardized way for a client to remotely create, modify and delete redirect references on a server; that this protocol claims redirect references to be viewed as WebDAV resources of a new resource type; and that this protocol provides new DAV:properties and a new method to create, modify and delete redirect reference resources in a proper and standardized manner. > Table of Contents > > 1 Notational Conventions........................................3 > 2 Introduction..................................................3 As Roy pointed out for the bindings protocol, the section "Notational Conventions" should not appear before the introduction. This should also hold true for this specification. > 16.4 Private Locations May Be Revealed............................23 Personally, I would not expect a complete sentence as header line. > Slein et al. Page 2 For the bindings protocol Roy pointed out that a working draft in that status should not be formatted, even if the internet official protocol standards track tells something different. This should also hold true for this specification. > 2 Introduction The first three sections of this chapter are identical to those of the bindings protocol; hence the general discussion made for the corresponding sections of the bindings protocol should also hold true for this specification. > A redirect > reference resource is a resource in one collection whose purpose is to > forward requests to another resource (its target), usually in a > different collection. I move "usually" be replaced by "possibly". > The companion specification, RFC xxxx, This may result in yet another circular cross-reference. > defines the BIND method, a > different mechanism for allowing clients to create alternative access > paths to existing WebDAV-compliant resources. The BIND method lets > clients associate a new URI with an existing WebDAV resource. This URI > can then be used to submit requests to the resource. Since URIs of > WebDAV-compliant resources are hierarchical, and correspond to a > hierarchy of collections in resource space, the BIND method also has the > effect of adding the resource to a collection. As new URIs are > associated with the resource, it appears in additional collections. Could the above section be dropped? To reveal the differences between bindings and redirect reference resources, the next but one section ("By contrast, ...") should suffice. > 3 Terminology > Reference Resource > ... > bindings (defined in [B]) Once again a reference to bindings. > Direct Reference Resource > Direct Reference Resources are out of scope for this > specification, but are defined here for contrast with redirect > reference resources. Does it really make sense to define terms that are out of scope? Direct Reference Resources as defined here are only a single example for something that is not a redirect reference resource, but one probably could define an arbitrary number of other things that are as well "in contrast"; it just depends on what particular attribute the contrast refers to. Anyway, this definition probably should require that a direct reference resource be a reference resource. > 4 Overview of Redirect Reference Resources > ... > It is also what insures that redirect reference resources > will be simple to implement and that cross-server references will be > possible. It may *help* that redirect reference resources will be simple to implement, but it can not ensure it, unless you implicitly make assumptions about the implementation, which should not be made in this specification. > If the client is aware that it is operating on a redirect reference > resource, it can resolve the reference by retrieving the reference > resource's DAV:reftarget property (defined in Section 12.1 below), whose > value contains the URI of the target resource. It can then submit > requests to the target resource. Why not using the HTTP Location header field to resolve the reference? This can be (and usually is) done even by clients that are unaware of the above. The true reason for introducing a DAV:reftarget property seems to be the possibility to *modify* the URI of the target resource rather than resolving the reference. > A redirect reference resource is a new type of resource. To distinguish > redirect reference resources from non-reference resources, a new value > of the DAV:resourcetype property (defined in [WebDAV]), DAV:redirectref, > is defined in Section 13.1 below. Just wondering: is there a standardized registration procedure for new DAV:resourcetype property values, e.g. something like MIME registration procedures as defined in RFC 2048? If not, that might substantially impair interoperability. > 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. When I read this, I first thought you were going to specify something that behaves like a direct reference resource, which however was declared to be out of scope for this specification. Having a look at section 6.2, it then (hopefully) became clear to me what you really wanted to say in this section. Hence I move to modify the wording, e.g. as follows: "While the basically intended behaviour of a redirect reference resource is to redirect a client to a different location, a different behaviour of the server is expected when creating, modifying or deleting the redirect reference resource itself. To let the server distinguish between these two fashions of behaviour, the Apply-To-Redirect-Ref request header (defined in Section 11.2 below) is provided so that a referencing-aware client can tell the server that it does not want to be redirected, but that the requested operation is to be applied to the redirect reference resource itself." > 5 Creating a Redirect Reference Resource > > The MKRESOURCE method is used to create new redirect reference > resources. I propose that "the MKRESOURCE method" should better read "the new MKRESOURCE method", as the method seems to be newly introduced in this specification. > It creates a new binding between the new redirect reference resource > and the last path segment of the Request-URI. The new binding is > added to its parent collection, identified by the Request-URI minus > its trailing slash (if present) and final segment. So, this protocol does not just informally refer to the bindings protocol, but really depends on it? Does this imply a specific implementation of redirect reference resources using bindings? Or is the meaning of the word "binding" not the same as defined in the bindings protocol? > 5.1 MKRESOURCE > > The MKRESOURCE method requests the creation of a resource and > initialization of its properties. It allows resources other than > standard data containers and collections to be created and their > properties initialized in one atomic operation. N.b.: the more general concept of MKRESOURCE has the potential of replacing the more specific concept of MKCOL, if it allowed a DAV:collection value for the DAV:resourcetype property. > The body of the new resource is empty. What is the body of a resource? For standard data containers, the intended meaning seems to be clear, but what is the meaning for other resource types? In this case, this probably should read "The entity body of a response returned from a GET request on the new resource MUST be empty.", or the term "body of a resource" should be defined somewhere else. (N.b.: WebDAV also uses the term "body of a resource" in sections 8.10.2 and 17.5 without prior definition). Anyway, for clients that do not support automatic redirection, it is sensible to provide some text/html response body to be returned from a GET request that can be shown to the user. Hence, I move to take away the restriction that the body must be empty. > The properties of the new resource are as specified by the > DAV:propertyupdate request body, using PROPPATCH semantics. I had to read this sentence again and again to understand the meaning. I move to choose a different wording, e.g. as follows: "The MKRESOURCE request MAY contain a DAV:propertyupdate request body to initialize resource properties. Herein, the semantics is the same as when sending a MKRESOURCE request without request body, followed by a PROPPATCH with the DAV:propertyupdate request body." This leads to a new question: is MKRESOURCE atomic (from all WebDAV client's perspective)? Or can another client access the new resource's properties before they fully have been initialized? If an error is encountered while initializing the properties, that means that some properties may have been initialized, while others still are undefined; atomicity would at least in that case be broken. However, if MKRESOURCE could atomically create and (read & write) lock a resource, this would prevent other clients from accessing the newly created resource until the creator decides to remove the lock. Hence, I would like to put up for discussion the following question: Should a MKRESOURCE request may contain a DAV:lockinfo XML element and those request headers defined for the LOCK method in order to request atomic creation and locking of a new resource? > If the response status code is not 201, then a new resource is not > created ... "is not created" should probably read "was not created", making it consistent with the status codes description a few lines below (or is deferred creation allowed for an implementation of MKRESOURCE?). > Response Marshalling: > > Responses from a MKRESOURCE request SHOULD NOT be cached, as MKRESOURCE > has non-idempotent semantics. I move that if MKRESOURCE has non-idempotent semantics, then responses MUST NOT be cached unless the client and the server agree on some cache protocol outside of the scope for this specification. > 6 Operations on Redirect Reference Resources > > Although non-referencing-aware clients cannot create reference > resources, I move that "non-referencing-aware clients" be replaced with "clients not aware of this protocol". > A reference-aware WebDAV client can act on this response in one of two > ways. It can, like a non-referencing client, resubmit the request to > the URI in the Location header in order to operate on the target > resource. Alternatively, it can resubmit the request to the URI of the > redirect reference resource with the Apply-To-Redirect-Ref header in > order to operate on the reference resource itself. A client can act on this response not only in one of these two ways, but in any way it chooses. I suppose you just want to present two examples of typical behaviour that a client may choose. > If the Apply-To-Redirect-Ref header is present, the request MUST be > applied to the reference resource itself, Here is the same wording problem as in chapter 4, where the wording sounds as if direct references were addressed. > A reference-aware client may know before submitting its request that the > Request-URI identifies a redirect reference resource. In this case, if > the client wants to apply the method to the reference resource, it can > save the round trip caused by the 302 response by using an Apply-To- > Redirect-Ref header in its initial request to the URI. Strictly spoken, this is redundant information and hence should be dropped. But it may be worth to be mentioned in an example. > When > Apply-To-Redirect-Ref is used with GET or HEAD, the Redirect-Ref entity > header MUST be returned, along with all HTTP headers that make sense for > reference resources (for example, Cache-Control, Age, ETag, Expires, and > Last-Modified). As all HTTP headers that make sense for reference resource MUST be returned, I would expect a precise definition of which headers do make sense rather than just listing some examples. Or "MUST" should be replaced with "SHOULD" for these HTTP headers; then just giving some examples seems ok. > A redirect reference resource MAY have a body, though none is defined > for it in this specification. The PUT method can be used, with Apply- > To-Redirect-Ref, to create or replace the body of a redirect reference > resource. Once again, this sounds as if you are assuming that a resource having a body means that the body is stored in a standard data container associated with the redirect reference resource. But, in fact, the specification does not state that a GET will return the same body that was PUT onto the server. Hence I move the behaviour be concretized, using terms such as "request body", "entity body" and "response body". Perhaps it may appropriate to state: "A PUT with Apply-To-Redirect-Ref MAY contain a request body. The semantics of the request body is out of scope for this specification; in particular, this specification does not require the same body to be returned in the response of a subsequent GET with Apply-To-Redirect-Ref header." > Since MKCOL and MKRESOURCE fail when applied to existing resources, if > the client attempts to resubmit the request to the target resource, the > request MUST fail (unless the reference resource is a dangling > reference). Similarly, if the client attempts to resubmit the request > to the reference resource with an Apply-To-Redirect-Ref header, the > request MUST fail. Once again, I move this paragraph be moved into an example section. > Since ORDERPATCH applies only to collections, an ORDERPATCH request with > an Apply-To-Redirect-Ref header on a redirect reference resource MUST > fail. What is ORDERPATCH? Where is it specified? > 6.1 Example: GET on a Redirect Reference Resource > ... > The Redirect-Ref header informs a reference-aware client > ... I move that "reference-aware client" be replaced with "client aware of this protocol". > 6.2 Example: PUT on a Redirect Reference Resource with Apply-To- > Redirect-Ref > ... See the above discussion on the "resource body" issue. ... to be continued ... Juergen Reuter
Received on Monday, 7 February 2000 08:50:51 UTC