- From: Lisa Dusseault <lisa@xythos.com>
- Date: Fri, 14 Feb 2003 16:28:26 -0800
- To: "'Julian Reschke'" <julian.reschke@gmx.de>, "'Webdav WG'" <w3c-dist-auth@w3c.org>
> The current ordering draft tries to adopt the more precise approach of > RFC3253. In particular, by inheriting from RFC3253 it gets > > - (IMHO) a better error marshalling as RFC2518, > - precise definitions of what must happen upon executing a method > (pre/postconditions). Actually, I agree that RFC2518 has a better error marshalling mechanism *and* that precise definitions of what must happen upon executing a method are all good things. I think the concept of preconditions and postconditions is a good concept and helps make a specification more complete. But, here's what I definitely don't want to *lose* in the process. - the ability of a specification reader to digest a piece of the specification, and basically "get it" - the clarity of the standard MUST, MAY, SHOULD language I think we're in agreement on this now and I look forward to seeing your revised language-- I will review it all to see if it all makes sense to me then. A couple more subtle topics now... 1. I'm a little worried that we're starting to lose the richness of having error codes from 100 to 999 available by using only 403/409. For example, when ordered collections aren't supported in a given location, why aren't we using 501? If a segment listed in the ordering is not found, why would the server return 409 with (DAV:segment-must-identify-member) rather than a 404 Not Found response code (either on its own or in a body)? 2. Are we possibly making things confusing by introducing a postcondition "code" like (DAV:ordering-type-set) for something that MUST be done? It makes it seem like the server might choose not to set the ordering type, create the collection anyway, and respond with 409 containing <DAV:ordering-type-set/>. Wouldn't a total failure to do some required behavior normally be defined as a 500 response? Thanks, Lisa
Received on Friday, 14 February 2003 19:28:24 UTC