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

RE: GULP vs RFC2518bis

From: Lisa Dusseault <lisa@xythos.com>
Date: Sat, 8 Mar 2003 10:19:53 -0800
To: "'Julian Reschke'" <julian.reschke@greenbytes.de>, "'WebDAV'" <w3c-dist-auth@w3.org>
Message-ID: <067001c2e59f$512a1b70$bb01a8c0@xythoslap>

Here's some initial feedback on the latest GULP.

I much prefer replacing the "bindings" terminology with the "internal
member" terminology.  That said, I'm still thinking about the model.  I
think it's worth considering carefully.

"An UNLOCK request deletes the lock with the specified lock token.
  The request-URL of the request MUST identify a resource that
  is either directly or indirectly locked by that lock.
  After a lock is deleted, no resource is locked by that lock."

Do we really want to allow an UNLOCK to an indirectly-locked resource to
remove the lock on the directly locked parent?  I'd like to know whether
implementations either already support this or are willing to add
support for this. I don't have time to verify WFS at the moment but I'm
assuming it's better to send a partial response now than a more complete
response later when I dig myself out from a large amount of work.

"A lock token is "submitted" in a request when it appears in an If
  header tagged-list whose tag is the lock-root of the lock."

This doesn't mention untagged-list syntax in If header.  Is a corollary
of this proposal that we remove the untagged-list syntax? Or was the
omission of untagged-list accidental?  I'd prefer to keep the untagged
list syntax, so I believe this should read:
 "A lock token is "submitted" in a request when it appears in an If
  header."

Then this paragraph, with the substitution to "internal member" made as
Julian suggested...

  "If a request would modify the content for a locked resource, a dead
  property of a locked resource, a live property that is defined to be
  lockable for a locked resource, or a member URL in a locked
collection,
  the request MUST fail unless the lock-token for that lock is
  submitted in the request."

Being picky here, this sentence is conditional on a request modifying "a
member URL" in a locked collection. Isn't it any modifications to the
internal member, not just the URL?  E.g. this definition must encompass
a PUT to a indirectly locked internal member, as well as a MOVE.

Lisa


> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Julian Reschke
> Sent: Friday, March 07, 2003 6:24 AM
> To: 'WebDAV'
> Subject: GULP vs RFC2518bis
> 
> 
> 
> Hi.
> 
> I'd really like to see some progress regarding this issue. In
> 
http://lists.w3.org/Archives/Public/w3c-dist-auth/2003JanMar/0281.html

I have tried to rephrase GULP so that it doesn't require the term
"binding"
anymore. This should address the concerns of those who fear that a
dependency on the BIND spec is introduced.

To those who did object to GULP being part of RFC2518bis *please* review
this?

Julian

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Received on Saturday, 8 March 2003 13:19:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:44:03 GMT