Re: ID: draft-ietf-webdav-bind-05

Julian Reschke wrote:
> 
> Joe Hildebrand wrote:
> 
>>
>> In the interest of trying to get things moving on BIND, I've got some 
>> review comments.  I'm unburdened by knowing where the WG has already 
>> achieved consensus, so please let me know if I step on something 
>> unintentionally.

Hi,

I have updated the latest draft text (see 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-issues.html>) 
as follows:

1) Recorded and resolved those issues for which we agreed upon a 
resolution 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.2.5_language> 
and 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.7.1.1_add_resource_id>).

2) Recorded and resolved as "no change" the issue where the consensus 
seemed to be that we don't need a change 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.1.3_error_negotiation>).

3) Re-added issue 4_LOCK_BEHAVIOUR from the old issues list as 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-bind-latest.html#rfc.issue.4_LOCK_BEHAVIOR> 
(with status "closed").

4) No changes at all where it seems that the explanations provided by 
Geoff and myself seem to have been sufficient.

This leaves us with the perma-issue of locking vs binds:

> ...
>> 4 (and others)
>>  - (DAV:locked-update-allowed) what if the resource is locked?  I understand that this is a property of the resource, not the binding, but since 2518 doesn't say anything about bindings, I think we could use a paragraph at some point that spells this out explicitly.  Perhaps another sub-section in section 2?
> 
> 
> That's incorrect. In particular, <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.8.10.3> says:
> 
> "A resource may be made available through more than one URI. However locks apply to resources, not URIs. Therefore a LOCK request on a resource MUST NOT succeed if can not be honored by all the URIs through which the resource is addressable."
> 
> That being said, a large amount of the open issues raised against RFC2518 are about locking semantics. The authors of the BIND spec feel that it's a bad idea to try to clarify locking semantics in a document that's completely independant and optional. Locking semantics should be fully defined in a single place.
> 
> One way to do this is to wait for RFC2518bis. Another one is to factor out locking from the base protocol, and publish this as "update" to RFC2518 (at "proposed" level), and let the BIND spec refer to that. This is what I'm currently working on (and I'm planning to submit a complete rewrite in time before the IETF meeting).
> 
> I've summarized the issue at <http://lists.w3.org/Archives/Public/w3c-dist-auth/2004AprJun/0049.html>.   So far, I've seen many people agree, and it would be really good if the working group would come to a decision on this matter. 
> ...

It would be nice if we could make some progress on that discussion which 
has now been going on for half a year...

Anyway, unless I people feel there's a problem with that, I'll be 
submitting the latest edits as draft 06 so we have an up-to-date 
published version in due time before the IETF meeting.

Best regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

Received on Wednesday, 30 June 2004 04:24:14 UTC