W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > January to March 2003

RE: Move and Delete (was: bind draft issues)

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 7 Mar 2003 13:07:53 -0500
Message-ID: <E4F2D33B98DF7E4880884B9F0E6FDEE25ED6EA@SUS-MA1IT01>
To: "'WebDAV'" <w3c-dist-auth@w3.org>

My reading of the consensus of the working group (although certainly
not universal agreement) is that atomic behavior
on the part of the server is preferable when the server is capable of
doing so, especially when multiple bindings to a resource is possible.
But since some servers cannot guarantee atomic behavior, this
was made a "SHOULD" instead of a "MUST".  Similarly, any server implementors
that feel their clients want non-atomic behavior can present non-atomic
behavior and still be compatible with the spec (because it is a SHOULD,
not a MUST).

In addition, I believe there was consensus that allowing the
client to explicitly request atomic behavior was desireable, and this
is achieved through the introduction of UNBIND/REBIND.


-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

> I've posted a revised version of the binding draft to the
> binding web site.  Let me know what you think.
> <http://www.webdav.org/bind/draft-ietf-webdav-bind-01.2.htm>

Sorry to be a pain, but the reason we say that we are splitting in to
because some people claim that clients prefer the non-atomic DELETE
functionality.    But the
new bindings document says that if the server can implement UNBIND, then
DELETE should
be implemented that way.    This leaves me scratching my head.

1) Do users ever want the old DELETE functionality if they can have UNBIND?

2) If we really believe that they do, why do we suggest that the server do
the UNBIND anyway?

It sounds like we really haven't decided (1).   Let's really decide that
and then spec this to match
what we resolve.


Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com
Received on Friday, 7 March 2003 13:59:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:28 UTC