RE: Review of ordering draft, version 05

> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: Saturday, February 15, 2003 1:28 AM
> To: 'Julian Reschke'; 'Webdav WG'
> Subject: RE: Review of ordering draft, version 05
>
>
>
>
> > 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

I assume that's a typo :-)

> *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.

OK.

> 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

Because 501 means:

	"The server does not support the functionality required to fulfill the
request. This is the appropriate response when the server does not recognize
the request method and is not capable of supporting it for any resource."

In general I'm sympathic to allow DAV:error response bodies for *any* failed
request (I think I actually proposed this a while back on this list).

> 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)?

We can't simple return a 404 because the Request-URI identified a collection
which in fact *does* exist. The request failed because we tried to
manipulate the state of the collection in a way that failed because one of
the bindings we tried to position did not exist. We did *not* try to
manipulate the resource identified by that internal member name at all.

>  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?

Yes, and I think that's something that should be possibly fixed in RFC3253.
Failure to meet a postcondition (after all preconditions were verified)
always is a server bug and thus would belong into the 5xx range. The main
question is: which spec should fix that? I'd really like to see RFC2518bis
to pick up (and clarify) this kind of error typing (maybe in a way that
makes it optional?).

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Saturday, 15 February 2003 04:41:29 UTC