- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Sat, 22 Oct 2005 20:42:35 +0200
- To: Lisa Dusseault <lisa@osafoundation.org>
- CC: WebDav <w3c-dist-auth@w3.org>, Cullen Jennings <fluffy@cisco.com>
Lisa Dusseault wrote: > > On Oct 22, 2005, at 11:04 AM, Julian Reschke wrote: > >> >> Lisa, it seems that whatever we discuss, you try to turn this into a >> discussion about even more spec text. RFC2518bis doesn't need to say >> anything about it. Whatever RFC2616 already says and a future WebDAV >> REDIRECT spec will say is sufficient. > > > You say that as though it's a bad thing! Whenever we discuss or Yes, as a matter of fact I think it's a bad thing. We are revising RFC2518, which to me means - fixing bugs (examples, typos) - removing stuff nobody does implement (such as DAV:propertybehaviour) - simplify things that were too complex in the first place (lock-null resources come to mind) - removing stuff that's not need today anymore (XML namespace explanations, UUID generation instructions...) - update references - add stuff that we agree was missing (DAV:lockroot...) This may not be complete, but it should cover most cases. Just adding prose without no actual need for it IMHO is a bad idea. Do that in FAQs, Blogs, online resources, implementor guides, books, whatever. > disagree on the mailing list, I find that's a good case for narrowing > down what can be done in implementations of RFC2518bis; to reduce > variety between implementations, improve interoperability and have a > complete spec that doesn't send people running to the mailing list all > too often. "Narrowing down" means a change of the spec. As far as I can tell, there is no need to change the spec. If you feel there is a need, please explain way (interop problem???). > We can at least think and talk about the issue -- if we *do* come to > consensus that Location header is not appropriate in 207 responses (or > other new response codes defined by WebDAV, or new methods defined by > WebDAV) then any of that would be good information to add to the spec. I disagree. RFC2616 defines what the "Location" header is for, and any attempt to go further than that without practical reasons IMHO would be the wrong thing to do. > OTOH if we come to consensus that we shouldn't restrict Location header > use but leave it undefined on most response types, I hope there's a good > reason for that which would come out in a discussion. We can (and will) discuss whatever is raised here. I just dont't see how this discussion helps us in any way revising RFC2518. As a matter of fact, it slows us down, because it distracts us from the things that *are* on the issues list. Best regards, Julian
Received on Saturday, 22 October 2005 18:42:58 UTC