W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2001

Re: Status reporting comments

From: <Tim_Ellison@uk.ibm.com>
Date: Fri, 9 Feb 2001 10:09:26 +0000
To: ietf-dav-versioning@w3.org
Message-ID: <802569EE.0037C32B.00@d06mta07.portsmouth.uk.ibm.com>

Jim wrote:
> At present, the DeltaV specification leaves it up
> to implementors to determine whether to return a
> 403 or a 409 for precondition and postcondition
> errors.  Since the specification doesn't provide
> explicit guidance on this topic, it seems likely
> that this will lead to different implementations
> making different decisions.  Since these status
> codes do have slightly different semantics (one
> the client might want to resubmit (409), the
> other the client should not resubmit(403)), this
> is unfortunate, since it will lead clients to
> lump 403 and 409 together, presumably never
> attempting to resubmit since the resubmit
> semantics of 403/409 cannot be depended upon.

I tried this for an earlier revision of the spec., but didn't get any
support for it.

> One way to rectify this is to explicitly note which
> of the status codes should be returned next to the
> precondition/postcondition XML element name, when
> it is possible to determine that only one status
> code will ever apply.  In cases where it could
> depend, both 403/409 could be indicated.

We can give it a shot and I'm happy to provide my updated list, but I'm
reluctant to getting into a big discussion about whether/why a particular
condition is a 403 or 409 or either.

> Also, I think the specification should explicitly
> note that the IETF controls the namespace of error
> XML elements, and that implementations are NOT free
> to create these XML elements willy-nilly if they
> encounter error conditions not forseen by the specification.

I disagree.  I think it is sufficient to reserve the DAV: namespace, and if
I choose to return
as a reason for not doing something, then I don't see that it will be
detrimental to other clients.

Received on Friday, 9 February 2001 05:11:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:46 UTC