- From: Judith Slein <slein@wrc.xerox.com>
- Date: Thu, 11 Jun 1998 10:18:35 PDT
- To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
- Cc: Judith Slein <slein@wrc.xerox.com>, Jim Davis <jdavis@parc.xerox.com>, w3c-dist-auth@w3.org, frystyk@w3.org, paulle@microsoft.com, lawrence@agranat.com
Thanks for the explanations and advice. The changes I would make based on your comments are: 1. to specify a new ADDREF method for adding referential members to collections. 2. to get rid of all mentions of M-PUT, M-COPY, and M-MOVE that are currently scattered through the spec, and instead add an implementation note for clients suggesting that they use the Mandatory Extensions Spec for cases where they want to be sure that the request fails if the headers are not understood. --Judy At 07:16 PM 6/10/98 PDT, Roy T. Fielding wrote: >My opinion is that either > > 1) adding a referential member is exactly equivalent to creating > a resource with no content, in which case you don't need M-PUT > (just use PUT); or > > 2) adding a referential member is not creating a resource with no > content; it is instead creating a resource that exists as a > namespace indirection for some other resource, in which case > using PUT would not be appropriate at all. > >It seems to me that the latter is what you intend, so defining ADDREF >is the appropriate action. > >Neither case requires the use of the Mandatory draft's extension mechanism. > >>So what about the Position header? We could just get rid of it, and make >>clients do a separate PROPPATCH operation to place a new collection member >>where they want it in an ordering. >> >>If we keep the Position header, we need something like Mandatory to insure >>that the request will fail if the header is not recognized. > >Not necessary for ADDREF. If the header is not recognized, then ADDREF >will not be allowed either. Besides, the chances that an application would >want the server to reject the request in this case are nonexistant -- >ordering is always at the discretion of the server and there is no >alternative if the server doesn't even understand the Position header. > >>There is one other case, not currently in the collections spec, that might >>need Mandatory. We may decide that we need a way to specify, at the time a >>collection is created, that it be an ordered collection. If we introduce a >>new Ordered header for use with MKCOL to accomplish this, we need a way to >>make the request fail if the server doesn't comply with the ordered >>collections part of WebDAV. > >Again, such usage is only necessary if the client actually wants the >server to fail the request. That is rarely the case for namespace >operations (so rare, in fact, that I know of no application area that >would ever want such functionality). > >In any case, the Mandatory syntax allows such a requirement to be >defined independently of your own extensions, so define the protocol as >if you know the server will support the extension (which will be true >for all but the very first interaction with that server) and then just >remind the reader that they can use the Mandatory prefix if desired. >The only thing you need to define is the URI for the semantics, which >in this case would be the RFC of your eventual standard (or any ><DAV:thingy> you might prefer). > >....Roy > > Name: Judith A. Slein E-Mail: slein@wrc.xerox.com Internal Phone: 8*222-5169 Fax: (716) 422-2938 MailStop: 105-50C Web Site: http://www.nde.wrc.xerox.com/users/Slein/slein.htm
Received on Thursday, 11 June 1998 13:13:07 UTC