Re: new issue: Updates 3253 (DAV:error)

Lisa Dusseault schrieb:
> Thanks for pointing this out.  I'm trying to wrap my head around this to 
> figure out just how incompatible this is and how to describe the change.
> 
> First, I'm not at all sure that the WG intended to update RFC3253.  We 
> could leave all updating of RFC3253 to a separate effort.

I agree that updating DeltaV in general is a separate effort.

In this case, RFC2518bis takes a feature from RFC3253 (DAV:error), but 
in an incompatible way (yes, it's an edge case of the whole DAV:error 
handling, but anyway...).

An implementor who implements RFC3253 and RFC2518bis either will miss 
that change (probably implementing the RFC3253 behavior), or will have 
to decide which way to go. That's a problem. Minimally, we should make 
implementors aware of that issue (by stating it in RFC2518bis, and by 
making sure that the RFC database shows that relation).

> Second, is it incompatible?  The server could put the DAV:error element 
> in both places if it's a RFC3253 server and if it's not sure whether 
> it's seeing a versioning request.

Putting it in both places is incompatible with both specs, because it 
would break the extension model (DAV:error is not an extension element 
with respect to WebDAV's extensibility model).

Also, I would argue that making this depend on the type of request would 
be an extremely bad idea. Keep in mind that all or almost all subsequent 
RFCs (ordering, ACLs, redirects, ...) adopt RFC3253's definition, so 
it's not about versioning only.

> Third, is it implemented?  Are there RFC3253 servers which put the 
> DAV:error element in DAV:responsedescription today?

I know about at least one, because I wrote it (the WebDAV stack in SAP's 
Netweaver KM product).

> If we do intend to update RFC3253, should we indicate whether the server 
> SHOULD include the "DAV:error" element inside the 
> "DAV:responsedescription" element as well as the "DAV:response" element 
> for backwards compatibility, or alternatively whether clients SHOULD 
> look in both places because there might be updated as well as 
> non-updated servers.

As far as I recall, the reason the format was changed is because the 
format in RFC3253 is harder to express in the DTD. If RFC2518bis states 
that servers SHOULD do both, we'll need to change the DTD as well, in 
which case the question would be why to make that change at all.

> If you can suggest specific language, perhaps that would be best.

The change is incompatible. We should either just document it (hoping 
that people switch to the "new" format when applicable), or just undo 
that change, staying compatible to RFC3253.

My personal preference is slightly towards the former.

Best regards, Julian

Received on Saturday, 27 January 2007 11:14:41 UTC