Subject: GULP vs RFC2518bis

From: "Julian Reschke" <[email-masked]>
Date: Fri, 7 Mar 2003 15:23:41 +0100

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

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 7 Mar 2003 17:22:41 +0100

I think GULP should, with the proposed changes, go into RFC2518 bis.

LOCKing semantics need to be defined in 2518bis and not in any
side-track specification (sorry Goeff ;).

//Stefan

Am Freitag, 07.03.03, um 15:23 Uhr (Europe/Berlin) schrieb Julian

---

From: Elias <[email-masked]>
Date: Fri, 07 Mar 2003 10:33:40 -0800

I agree, the specification should clearly define all of the WebDAV 
methods such that referring to a secondary text is not necessary. The 
proposed changes to remove the references to bindings don't seem to 
affect GULP semantics so I would support adding the revised version to 
2518bis.

Elias

---

From: Brian Korver <[email-masked]>
Date: Fri, 7 Mar 2003 11:59:52 -0800

> To those who did object to GULP being part of RFC2518bis *please* 

Julian,

I plan to review GULP ASAP.

-brian
[email-masked]

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sat, 8 Mar 2003 10:19:53 -0800

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Julian Reschke
> Sent: Friday, March 07, 2003 6:24 AM
> To: 'WebDAV'
> Subject: GULP vs RFC2518bis
> 
> 
> 
> Hi.
> 

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.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Sat, 8 Mar 2003 20:02:21 +0100

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Saturday, March 08, 2003 7:20 PM
> To: 'Julian Reschke'; 'WebDAV'
> Subject: RE: GULP vs RFC2518bis
>
>
>

RFC2518 says about UNLOCK:

"The UNLOCK method removes the lock identified by the lock token in the
Lock-Token request header from the Request-URI, and all other resources
included in the lock. If all resources which have been locked under the
submitted lock token can not be unlocked then the UNLOCK request MUST fail.
"

So I think GULP only repeats what RFC2518 has been saying all the time (BTW:
this is issue UNLOCK_WHAT_URL on the open issues list).

>  "A lock token is "submitted" in a request when it appears in an If

I'd prefer

"when it appears in an If header tagged-list whose tag is the lock-root of
the lock, or if it appears in an untagged list and the request-URL is the
lock-root of the lock".

>   lockable for a locked resource, or a member URL in a locked collection,

No. The *shallow* lock on a collection locks it's member URLs. If the lock
on the collection isn't deep, you can modify internal members without the
lock token, as long as you don't change their name (affecting the state of
the collection itself).