[Bug 181] error element

http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=181





------- Additional Comments From julian.reschke@greenbytes.de  2005-12-31 02:57 -------
> I can't follow the reasons for all the changes in that document, so it's hard
> for me to tell what your (Julian's) intent is with the changes.  I don't like
> having all the normative text in section 8.1.5 -- that section was intended to
> be an introduction to the topic and has gotten out of hand.  I'd like to leave
> that as an introduction because section 8.1 is already a large enough digression
> from the actual methods we discuss in the rest of section 8.  Other comments:

If we use preconditions in the subsequent subsections, I believe it would be
better to have the concept explained completely fully in advance.

>  - This text proposed is inconsistent with issues you've raised before, with
> regards to making 403 and 409 the only allowed error codes.

I'm not sure what you're referring to. The text says 

   If a method precondition or postcondition
   for a request is not satisfied and unless specified explicitly
   otherwise, the response status of the request MUST be either 403
   (Forbidden) if the request should not be repeated because it will
   always fail, or 409 (Conflict) if it is expected that the user might
   be able to resolve the conflict and resubmit the request.

which I think reflects WG consensus (the status will be 403 or 409, unless the
spec explicitly says something else).

>  - the last paragraph in your proposal for section 8.1.5 is redundant with
> earlier text

   In this specification, both the HTTP status code and the condition
   name are defined for some failure situations, in which case the XML
   condition element is in the "DAV:" namespace, appears in the "error"
   root element, and SHOULD be returned in a body with the specified
   numeric HTTP status code.

Of this, only the last two parts seem redundant. Feel free to strip those.

>  - Some of the changes (e.g. in section 8.2) are unrelated to this issue

They are related, in that the spec mades inocrrect statements about depth:
infinity requirements for PROPFIND. Should I open a separate bug for that?

>  - The guidance on creating one's own error codes was seemingly removed

Redundant wording (you don't like that as well, right?) was removed. The
proposed text still says:

   However, it does remove the need to define new
   numeric error codes.  The machine-readable codes used for this
   purpose are XML elements classified as preconditions and
   postconditions.  As always, the "DAV:" namespace is reserved for use
   by IETF-chartered WebDAV working groups.

>  - Some of the error code sections (from 8.2 to 8.12) were reorganized but
> others remained organized differently.  I haven't adopted these changes, is
> there some reason for them?

I'd like them to be consistent. I may have not catched all variations. Should we
open a separate ticket?

>  - I don't agree that we should list the preconditions/postconditions without
> suggesting what status code to use with. I find the formatting I've been using
> clearer than that of the proposed change.

IMHO the definition of the condition is independant of a suggested status code.
When specific method descriptions recommend a specific status code to use them
with, that's fine. Having it in both places seems like a bad idea.
 
> I'm making a number of modifications to the draft based on these proposals but
> I'm sure we'll have to iterate.

Yes.

As a matter of fact, it would be nice if people could comment on the proposal as
is, so that the editor has some indication about how to proceed.




------- You are receiving this mail because: -------
You are the QA contact for the bug, or are watching the QA contact.

Received on Saturday, 31 December 2005 10:58:04 UTC