Re: IETF Last Call review: changes suggested

Lisa Dusseault schrieb:
> 
> I received the following comments from an outside reviewer:
> 
>> The text should not state a MUST requirement (section 7.3, paragraph 
>> 3) and then later revoke that requirement by permiting servers to 
>> implement the original behavior.  It seems that locking an unmapped 
>> URL MAY (or SHOULD, but not MUST) result in the creation of a 
>> non-collection result with empty content, but that regardless the 
>> indicated URL MUST be locked.
> 
> I'm fine with making this change if others agree.  I could argue that 
> any server claiming compliance with "bis" can be required to implement 
> the new locking behavior and we don't need to make the old behavior a 
> specific option, but I think it's also reasonable to make the old 
> behavior a specific option.

The trick thing here is that the current draft tries to allow two 
different approaches, with a slight preference to the new, simpler 
approach. However, the BCP14 terminology doesn't capture that correctly.

A simple fix would be just to allow one behavior (the new one), but that 
would make some existing servers non-compliant, and my recollection was 
that we didn't want that (and I still think this is the right decision).

Basically, Lock-Null-Resources (LNRs) work fine, but their specific 
behavior is non-trivial and in some cases is extremely hard or 
impossible to implement, while providing little additional value to clients.

>> It would help if there was descriptions of how clients should perform 
>> actions portably given that MAY.  For example:
>> - if a client locks an unmapped URL and then decides to COPY or MOVE
>>   another resource to that name, it needs to include an "Overwrite: T"
>>   header in the COPY/MOVE

It needs that with the new approach, and it seems to me it was undefined 
with LNRs. Do we have any evidence of interoperability issues here?

>> - similarly, if it changes its mind and decided to not create the
>>   resource, it needs to use DELETE instead of UNLOCK

No, it doesn't.

>> - if a client wants to creat a new, empty collection and lock it, the
>>   client should not pipeline a MKCOL and LOCK but rather do the MKCOL and
>>   only send a LOCK if it succeeds.  Pipelining them can result in the
>>   client locking a collection that someone else created or even the
>>   locking of something other than a collection.  (Or maybe I'm
>>   overlooking something here...)

I'd say that by not pipelining them the client actually increases the 
chance of locking a collection created by somebody else. But - thinking 
of it - why is that a problem anyway? It really doesn't matter who 
created the collection, as long as it's there and locked after the two 
requests, right? It's not as if *two* clients can succeed in locking them.

> I agree with the reviewer that this would be useful guidance to client 
> implementors, and propose to add a subsection to Appendix D (Lock-Null 
> resources) that is non-normative.

I'm not opposed to adding something here, but first we need to agree 
here what that is...

Best regards, Julian

Received on Wednesday, 17 January 2007 13:18:12 UTC