- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 27 Jun 2002 20:32:22 +0200
- To: "Jason Crawford" <ccjason@us.ibm.com>, "Clemm, Geoff" <gclemm@Rational.Com>
- Cc: "'Webdav WG \(E-mail\)'" <w3c-dist-auth@w3c.org>
1) This is clearly server-defined. I can imagine all kinds of mechanisms for *creating* a dynamic resource, for instance PUTting an empty resource with a specific content type, then setting a few server-specific live properties. However, I can't imagine how RFC2518 could possibly define a method that can be applied to all types of servers. 2) DAV:source 3) Whether the change of the source resource(s) is reflected immediately again clearly is implementation specific. 4) The URL they want to delete. Whether this is allowed and has the desired effect again is implementation specific. 5) Yes. 6) Yes. Now I hear people saying: "if all of this is implementation specific -- where's interoperability"? That's basically asking RFC2518 to define a complete protocol for authoring dynamic content on *any* type of server -- and this clearly isn't realistic at all. The DAV:source property (when fixed :-) is clearly useful as defined. It doesn't *need* to solve all these other problems. If people are interested in working on a draft that defines authoring of dynamic content on *specific* servers, that's *also* an interesting project, but it doesn't belong in RFC2518bis (no more than in RFC2616). Julian -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford Sent: Monday, June 24, 2002 7:57 PM To: Clemm, Geoff Cc: 'Webdav WG (E-mail)' Subject: RE: Issue: SOURCE_PROPERTY_UNDERSPECIFIED I've spent some time trying to list the questions brought up in this discussion and the answers offered. I can post that list later. In building the list I found Lisa's questions interesting. For the most part the questions in the first half of Lisa's note [1] seem to be answered, but Lisa's later questions about mapping did not seem to be. The mapping issues seem to be an important issue for the source property, and the answer can vary from server to server. Are answers also hinted that the client has to know how the server does mappings, as they do now, but if that is our answer, then I'm not sure why we are defining the DAV:source property. [1] http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0170.html Can everyone do a mental reset and review why we have a source property? I assume the following questions (and perhaps more) need to be answered (by the DAV:source property). I don't think it's acceptable to say that the answer varies and that the client just know the mapping function. I've explained why above. I think we need to perhaps admit that the answer will vary from server to server, but that some aspect of WebDAV (presumably the DAV:source property) tells the client how to get the job done. 1) An author wants to create a dynamic web page using an implementation he has. The URL where he wants the dynamic content served is currently unmapped. Where does he PUT the implementation to create the mapping? (I'm assuming an automatic mapping process.) 2) An author wants to browse the code he submitted as an implementation of a resource. At what URL does the author do the GET? (I think we answer this with DAV:source.) 3) A dynamic page is being served at a given URL. The author wants to update the implementation of that dynamic resource. Where does he PUT the updated implementation? (I think we've answered the basic form of this question via the dav:source propety. Questions like whether the update will be refelcted immediately can be answered later.) 4) An author wants to no longer serve dynamic content at a specific URL. What URL does the author DELETE? 5) Make sure the answers to the above question still work in concept for resources that would list multiple DAV:source resources. 6) Make sure the answers to the questions above don't cause problems for servers that require explicit client controlled mapping operations. I'm sure I've missed some other fundamental questions, but the 4+2 above seem like a good easy to understand start. I do think it's acceptable to say that DAV:source only solves 2 & 3 and we'll solve the other questions later. In doing so, in the spec we can clarify what DAV:source is NOT doing so that it doesn't get misused. We also should mentally envision how we'd solve the other problems to insure that what we are doing now will not prevent us from solving the remaining problems later. J. ------------------------------------------ Phone: 914-784-7569, ccjason@us.ibm.com
Received on Thursday, 27 June 2002 14:32:54 UTC