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

From: Julian Reschke <[email-masked]>
Date: Mon, 22 Jan 2007 11:15:49 +0100

Hi,

RFC2518bis updates parts of RFC3253 (DAV:error below DAV:response) in an
incompatible way, and thus should note it in the front matter ("Updates: 
3253") and mention it as a change near the Changes Appendix.

(see <http://ietf.osafoundation.org:8080/bugzilla/show_bug.cgi?id=258>)

Best regards, Julian

---

From: Lisa Dusseault <[email-masked]>
Date: Fri, 26 Jan 2007 13:39:01 -0800

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.

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.

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

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.

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

thx again,
Lisa

On Jan 22, 2007, at 2:15 AM, Julian Reschke wrote:

> incompatible way, and thus should note it in the front matter  
> ("Updates: 3253") and mention it as a change near the Changes  
> Appendix.
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 27 Jan 2007 12:14:33 +0100

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.

> 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