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
|