- From: Yaron Goland <yarong@microsoft.com>
- Date: Thu, 20 Mar 1997 02:09:33 -0800
- To: "'masinter@parc.xerox.com'" <masinter@parc.xerox.com>
- Cc: w3c-dist-auth@w3.org
1 Content-Nature Header 1.1 Problem Description It is often important to be able to search for content based on data type. For example, "Please find all documents which contains the word "shmoo"". However in HTTP a resource is a resource is a resource. There is no way to tell anything about the resource, such as, is it a document? A collection? A database record? 1.2 Proposal A new HTTP header be introduced called Content-Nature. This header is passed in with a request and is returned in a reply. ContentNature = "Content-Nature" ":" 1#ContentIdentifier ContentIdentifier = URI 1.3 Discussion As for Larry's example, the message would have a content-nature of "email" or "discussion list posting". The same mystical group that will provide us meta-data names and formats would standardize the set of such values. 2 DAV.ResourceLink Link 2.1 Problem Description The proposal before this group for handling structured resources requires that members of the structure use the URI of the structure as the base of their URIs. However there are times when one wishes to include URIs in a structure which do not use the structure's URI as a base. 2.2 Proposal To provide a link type which when defined upon a structure using the LINK method will result in the resource including the URI in the results of a STRUCTURE method. The source of this link is to be the resource the link is defined on. The destination must a URI that does not have the source as its base. The type will be DAV.ResourceLink. 2.3 Discussion I expect that DAV.ResourceLink will end up being handled in two ways. For links pointing to resources on the same server, the entry in the structure result will look like any other entry, including the listing of whatever meta-data the server likes to return in its responses. However, in the case where the resource is on another server I expect that servers will list the URI and leave it at that. If this proposal is accepted we can be completely rid of ADDRESOURCE and REMOVERESOURCE. 3 PropagateLinks Header 3.1 Problem Description A structured resource, by its very definition, recursively applies any methods applied to it, to all of its members who use the URI of the structure as the base for their URI. For sake of clarity I will now refer to these resources as "primary members" of the structure. However DAV.ResourceLink members of the structure require different behavior. For sake of clarity I will now refer to resource which are linked to a structure through a DAV.ResourceLink as "secondary members". The secondary members are not normally considered in recursive operations. For example, a MOVE on a structure does not cause secondary members to be moved. Rather the links pointing to the secondary members are moved. However, there are times, when it is desirable for secondary members to be effected by methods executed on the resource . For example, a client could very well desire that a LOCK on a structure effect both primary and secondary members. 3.2 Proposal Introduce the PropagateLinks header. This header will be included in requests on structures. Certain methods may not allow this header, such as COPY and MOVE, because it is impossible to determine appropriate behavior. In that case the method should return a 412 Precondition Failed. 3.3 Discussion This header is meant as a replacement for the PropagateLevel header. That header really only existed to help differentiate when a method applied to secondary members as opposed to primary members. It is a remnant and no longer necessary. I would also like to comment on why PropagateLinks can not be used with COPY and MOVE. When copying a structure whose members use the structure's URI as their base, it is possible to concisely define where the members of the structure should be copied. Just take the Request-URI and use it as the new base. However secondary members do not use the structure's URI as their base so it isn't clear exactly where they should be copied. I know that some will argue that we need PropagateLevel so that it is possible to say things like "Just copy the first 3 levels." However such scenarios are rare and when they do appear, they tend to be more complicated involving orders such as "Just copy the following members". PropagateLevel only provides a crude tool. I feel it is better to provide a clean but more limited tool in the form of PropagateLinks and have the client formulate their requests by executing STRUCTURE and multiple copies. 4 COPY Method Now it is my turn to be confused. Would the request body of the PUT contain a URI? If so, why not just use my proposed Source header in conjunction with PUT? I agree that this would effectively rid us of COPY. 5 DELETE Method I believe that referential integrity constraints are out of scope for this group. Any time you go down this road you will end up either with MOVEHEAD and COPYHEAD or you will end up specifying server to server functionality. The *HEAD methods show up because we will realize we have no hope of specifying server to server functionality so in a desperate bid to provide something, we will try to provide these sorts of predictive methods. The server to server functionality shows up when we try to provide concrete answers to what happens to references when they are moved from one server to another. Either solution is a dead end. I believe we will have to accept the compromise now used on every file system I am aware of. If you copy, delete, whatever, within the server you will get fully service, including link maintaince and other goodies. If you copy between servers, you are roling the dice. The only thing that can be guaranteed is that an entity will be transfered. This is especially true as I expect most servers to implement COPY as a PUT. 6 UNDELETE Method The UNDELETE method is logically equivalent to UNCHECKOUT for a CHECKOUT. The client performed a DELETE and now they want to undo it. Sometimes it works, sometimes it doesn't. The system is inherently asynchronous so such behavior must be expected. As such, in what way Larry, do you feel that this method would be non-interoperable? 7 Atomic Header I keep thinking of how servers would actually implement Atomic and I come to the conclusion that the introduced complexity is not worth the small bandwidth savings. As such I remove my proposal for the Atomic header. Yaron > -----Original Message----- > From: Larry Masinter [SMTP:masinter@parc.xerox.com] > Sent: Wednesday, March 19, 1997 9:24 PM > To: Yaron Goland > Cc: w3c-dist-auth@w3.org > Subject: Re: Distributed Authoring Proposals > > In a previous life, I used to work on another standard where my > greatest > contribution to the standards effort, I claimed, was designing the > form > you had to fill out in order to get a change to the language > considered. > > The form had several fields, and mainly what I did (as chair of one of > the working groups) was to get people to fill out the form correctly. > > One of the most important features of the form is that it started with > the section > > "Problem Description" > > and you were required to define "what problem are you solving" before > you could go on to the next section, which is > > > "Proposal" > > where you described what you were proposing. > > Your recent mail on "Distributed Authoring Proposals" is missing > the "Problem Description" sections for each proposal, and it > is a little difficult to guess exactly what problem you're solving. > > 1. Content-Nature: The nature of this message is that the subject > is "Re: Distributed Authoring Proposals", but is it the true nature > of this message, or just another attribute? > > 2. I cannot guess what Dav.ResourceLinks means from your message. > > 3. COPY method > > I suggest considering eliminating COPY and instead using > PUT, but when the value being PUT is Content-Type: > message/external-body, then the server can copy the data > from the original source. > > Copying structures and other more complex objects can be > accomplished in the same way, or by PUTing other document > types (e.g., multipart/related where some of the parts > are message/external-body). > > There's no point in inventing a new method when an old one > will do fine. > > 5. DELETE > > The issue with Delete is exactly that of the referential > integrity constraints. If you delete a container, what happens > to the things contained? I think DELETE is the right vehicle > to explore this issue. "PropagateLevel" is really unsatisfactory, > since the required scope of deletion rarely corresponds to > "this level down 3 levels", even in file systems. > > 6. UNDELETE > > I think this is so completely non-interoperable that it > doesn't belong in the standard. > > The Atomic header, while looking nice, is voodoo. Is there an > interoperable client that would actually use this against > arbitrary servers? > > Regards, > > Larry
Received on Thursday, 20 March 1997 05:09:30 UTC