Re: Last Call: draft-ietf-webdav-rfc2518bis (HTTP Extensions for Distributed Authoring - WebDAV) to Proposed Standard

Ted Hardie schrieb:
> The locking issue was raised by Julian prior to last call to me and to Cullen as WG chair.
> It was the subject of a specific question of mine in a solicited review request sent
> prior to making the IETF Last Call.  I have been waiting on permission to forward those
> to the IETF list; lacking that, I have entered the responses in the draft tracker as
> "solicited review one" and "solicited review two".  They can be read here:
> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=8360&rfc_flag=0
> 
> These solicited reviews also recommend changes to the locking text and I expect
> to see updated text discussed on the WG mailing list prior to the document
> going to the IESG. 

Well, one of the comments hasn't been posted here at all, so allow me to 
paste it below (with may own comments in-line).

> Comment:	Solicited review two:
> 
> The newer text is a bit clearer, and adds some
> clarifications that I didn't get from the orignal
> text.  That being said, this RFC reads like a Law
> Review, with "trust sets" and "principals".  It seems
> even more drier than most RFC's!

That's text inherited from RFC2518. Nobody had the energy to rewrite it.

> Some things are still unclear to me, for example in
> section 6.6 "Lock Timeout":
> 
> If the timeout expires...the server SHOULD act as if
> an UNLOCK method was executed by the server...Thus
> logs should be updated...notifications should be sent,
> etc. just as they would be for an UNLOCK request.
> 
> I noticed the "notifications should be sent" and
> thought that there was some means of notifying other
> lock holders, the forgetful owner, etc.  But under the
> "UNLOCK" request, I can find no mention of
> notification.  In fact the word "notification" only
> appears here in section 6.6

Right. These are just examples for things that are out-of-scope. Again, 
that text already exists in RFC2518 
(<http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.8.p.7>). 
Any suggestions for a text change that would make the RFC clearer with 
respect to this?

> Section 8.11 (old) and 9.11 (new) says:
> 
> If all resources which have been locked under the
> submitted lock token can not be unlocked then the
> UNLOCK request MUST fail.
> 
> Yet I am unable to figure out how this could possible
> happen--what would cause a lock to not be unlocked?

I can't give any concrete example here. What the spec tries to say here 
is that partial success is not an option.

> Another thing to note:  This is the first time I've
> ever come across the concept of shared write locks.
> That is very strange to me, and I got very confused at
> first, because I was thinking in terms of the Unix
> "flock(3UCB)" function, and POSIX shared reader/writer
> locks.  I also expected to be able to lock portions of
> a file, and it took me a while to determine this was
> not possible (or if it is, I totally missed it).  I
> would like to see some explict text on the differences
> between WebDAV locking and other locking API's.

1) Not sure about whether we need a comparison to other locking APIs, 
and if so, to which. Feedback appreciated.

2) I never expected the ability of locking file ranges in WebDAV, but 
may that's just me. Also I don't think I've ever seen this mentioned on 
this mailing list since I read it. That being said, if people feel that 
this should be mentioned, I'm not opposed to that.


Best regards, Julian

Received on Wednesday, 17 January 2007 13:34:00 UTC