Using error response bodies for more information

There have been a number of discussions about using the error response 
body, as DeltaV and ACL do, in RFC2518bis. Some of the cases where this 
has been suggested:
  - If the XML sent to the server refers to external entities, the 
server would respond with 403 Forbidden with 'forbid-external-entities' 
in the body.
  - A 423 Locked response could include the lockdiscovery property value 
in the response body (including the lock token, timeout, owner, etc for 
client use)
  - A LOCK refresh or UNLOCK request was addressed to a Request-URI 
which did not fall in the scope of the lock identified by the 
Lock-Token header.
  - An UNLOCK request not containing a lock token at all
  - Clarify 409 error to PUT or MKCOL saying that the parent collection 
does not exist.
  - MOVE error response when the source and destination URLs are on 
different servers or different subnamespaces on a single server

I would like to confirm that we want to go down this path, because it 
involves new specification writing, more decisions, more changes, and 
an effort to maintain consistency with conflicting examples. For 
example, should the new requirements be consistent with DeltaV and ACL 
in using only 403 and 409 with precondition/postcondition responses, or 
should they be consistent with RFC2518 original status codes and 
include bodies with errors like 423 Locked and 400 Bad Request?   Would 
these be SHOULD requirements or MUST (in order to allow clients to rely 
on the additional information more quickly)?

Please respond with your opinion and further discussion,
thanks,
Lisa

Received on Sunday, 11 July 2004 15:02:31 UTC