HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
draft-ietf-webdav-rfc2518bis-18

[Ballot comment]
This requires UTF-16 support without a normative definition.  While this can be resolved by an indirect reference through the XML normative reference, the document would be improved by a direct reference to ISO 10646 and mention of the XML requirement to include a BOM at the beginning of a UTF-16 XML document.

[Ballot comment]
This requires UTF-16 support without a normative definition.  While this can be resolved by an indirect reference through the XML normative reference, the document would be improved by a direct reference to ISO 10646 and mention of the XML requirement to include a BOM at the beginning of a UTF-16 XML document.

[Ballot comment]
INTRODUCTION, paragraph 14:
>    RFC2518 was published in February 1999, and this specification makes
>    minor revisions mostly due to interoperability experience.

  Would add a half-sentence saying that this obsoletes 2581.

[Ballot comment]
From Gen-ART review by Elwyn Davies. The first point in particular
should be attended to if the document is updated for other reasons.

Treatment of 'allprop':  Appendix F.1 is now consistent with s9.1 regarding which properties are returned by 'allprop', but the wording of the definition in s14.2 is still inconsistent in that it does not mention properties defined in other documents.  I think that s14.2 should also make a requirement that 'other documents' explicitly say whether a property is to be returned with 'allprop'. The examples in 9.1.5 and s9.1.6 also fail to state the possibility of returning properties defined in other documents - I suggested that the example in s9.1.6 could be used to illustrate this.

s21 IANA Considerations:
I believe that it would be helpful to clarify that this is a formalization of previous registrations spread across RFC 2518, RFC 4229 and RFC 4395.  IANA therefore needs to update the references but not register anything new.

My original comment was:
The various items here do not require new registrations as they were
all registered as a result of RFC 2518 (and RFC 4229). This document
updates the registrations (and in a sense formalizes them since RFC 2518
did not have an IANA Considerations section explicitly). s21.1 should
refer to RFC 4395 which controls the URI Scheme registry. s21.3 should
refer to RFC 4229 which formalized the initial state of the message
header field registrations.  It occurs to me that I did not check if
there are any message headers which were in RFC 2518 but are now dropped
- if so this should probably be recorded here.

Potential security implications of lockdiscovery:  This issue was fixed by a change to s15.8.  I think it would be useful to flag this in s6.8 by adding the phrase "subject to security and privacy constraints" to the end of the first sentence.  Consideration should also be given to changing the title of s20.4 to "Security and Privacy Issues Connected to Locks".

s9.2: I thought that the term 'document order' was going to be removed as it isn't clear what it means.  (It might be clearer to an XML afficionado).

IANA Last Call Comments:

Action #1: (section 21.1)
Upon approval of this document, the IANA will make
the following changes in "Permanent Header Messages"
registry located at

http://www.iana.org/assignments/message-headers/perm-headers.html


OLD:
URI Scheme Description Reference
dav dav [RFC2518]
opaquelocktoken opaquelocktokent [RFC2518]

NEW:
URI Scheme Description Reference
dav dav [RFC-webdav-rfc2518bis-17]
opaquelocktoken opaquelocktokent [RFC-webdav-rfc2518bis-17]


Action #2: (section 21.2 )
No action needed as IANA is explicitly excused from
managing registrations in the XML WebDAV/Dav namespace.

Action #3: (section 2.3.1 - 2.3.7)
Upon approval of this document, the IANA will make the
following changes in "Permanent Header Messages" registry
located at

http://www.iana.org/assignments/message-headers/perm-headers.html

OLD:
Value Protocol Reference
----- ----------------
DAV http [RFC4229]
Depth http [RFC4229]
If http [RFC4229]
Destination http [RFC4229]
Lock-Token http [RFC4229]
Overwrite http [RFC4229]
Timeout http [RFC4229]

NEW:
Value Protocol Reference
----- ---------------
DAV http [RFC-webdav-rfc2518bis-17]
Depth http [RFC-webdav-rfc2518bis-17]
Destination http [RFC-webdav-rfc2518bis-17]
If http [RFC-webdav-rfc2518bis-17]
Lock-Token http [RFC-webdav-rfc2518bis-17]
Overwrite http [RFC-webdav-rfc2518bis-17]
Timeout http [RFC-webdav-rfc2518bis-17]


We understand the above to be the only IANA Actions for
this document.

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!

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

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?


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.

Solicited review one:

Overall opinion: the text in the draft is better than the original.  A number of clear errors have been corrected (ex: 2518 7.1 claimed that write locks blocked LOCK, making shared write locks impossible).  While I think the text would be easier to understand if it was less abstract in places (section 6, paragraph 2, for example), I don't think it needs to be changed.

The change to permit LOCK to create an empty resource if the target doesn't exist is a bit odd: I'm not convinced it makes implementation any easier.  My guess is that it's the result of implementors misreading the original RFC and that the WG decided it wasn't important enough to be worth forcing the issue.  Given how minor the loss is (can't lock a collection before creating it; minor portability tweaks elsewhere), that choice seems reasonable.  However, 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.

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
- similarly, if it changes its mind and decided to not create the
  resource, it needs to use DELETE instead of UNLOCK
- 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...)

Review requested of locking semantics; two reviewers have agreed to check the text against the original locking described in 2518.  We'll then get both together to confirm that their understandings and conclusions are the same.  This is to get fresh eyes on a document section that has been under discussion since the beginning of the bis effort.

Proto writeup

The WebDav working group would like to request publication of the standards-track document draft-ietf-webdav-rfc2518bis-17.txt. A Protocol Shepherd writeup follows:

(1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

The Document Shepherd is Cullen Jennings - I believe it is ready for publication. There are still issues with this document that could be improved by spending more time on it. However, I strongly feel that the rate of possible progress is slow, the number of participants working on it are low, and that publishing the positive aspects of publishing this document now far outweigh the gains that could be achieved by spending another year on this document. This is a vast improvement compared to RFC 2518, which this document updates.

Please keep in mind while reading this document, this is an updated (bis) version of RFC 2518 which has significant successful deployment. This draft tries to reduce interoperability concerns that came up from implementers of RFC 2518 and may not be perfect but is an significant improvement over RFC 2581.


  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

The document has been reviewed in the working group and several people other than the normal contributors to the discussion participated in the WGLC. I do have concerns about the breadth of the reviews that have been performed - it would be nice if more eyes from different perspectives had read this document. That said, I have no concerns about the depth - I feel that every word in this document has had review, debate, discussion, tweaking, and more review by some of the worlds leading experts and leading implementers of this protocol. From a very broad Internet point of view, this protocol has relatively wide deployment today and no issues have some up where it causes harm to the Internet as a whole.


  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization or XML?

I have no concerns beyond 1.b.



  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if those issues have been discussed in the WG and the
          WG has indicated that it still wishes to advance the document,
          detail those concerns here.


There is no way to know if a client will actually interoperate with a server. The servers are not required to actually store any content and the client has no way to find out what types of content a server might store (other than by trial and error). When WebDav is used as a basis of another protocol such as CalDav that specifies what types must be stored this is not a problem. However, when webdav is used as a standalone protocol, this is not the case. The fact that a completely compliant client can not guarantee that it can do even the most basic thing with a completely compliant server bothers me. The WG did consider this and had strong consensus this is the way they want it. I've decided it is no big deal in that if people build useless servers, even if they are complaint with the spec, they will still be useless and the world will ignore them.

Caching of properties is broken as there is no equivalent of ETags for properties. Many applications require caching of properties so they cache them anyway, but it is basically broken.

ETags as a whole are specified in such a way that client implementers are likely to take some short cuts to minimize the number of network transactions. This will result in ETags being slightly broken with some servers. This is really an HTTP issue and there is a draft (informatively referenced) that tries to tackle this. I do believe this draft needs to progress and that solving the problem in this document would be the wrong place to solve the ETag problem.

HTTP proxies and reverse proxies can rewrite the Request-URI, but leave other URIs used by DAV unmodified.  Because of this property, some DAV features may fail in some proxy topologies in unexpected ways. For example, redirects using location elements may fail to go to a valid location.

I believe section 20.1 of security considerations warrants careful review by the security area - particularly on the subject of when it is ok to use Basic style authentication.

The Lock Null Resource has been deprecated. I think this is good and represents WG consensus, but the wording around all this has been much debated and the consensus for the exact wording is very hard to judge as any discussion of it promptly leaves the rat hole and drops into a large snake infested cavern.


  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

Most of the WG supports this draft. A few key individuals have issues with some particular parts of the draft but I believe that there is consensus that this is an improvement to RFC 2518. There is between one and three individuals that may believe that this document should not be published.



  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director. 
(It
          should be in a separate email because this questionnaire will
          be entered into the ID Tracker.)

There are no known indications of discontent that will result in an appeal.


  (1.g)  Has the Document Shepherd verified that the document satisfies
          all ID nits?  (See http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/).  Boilerplate checks are
          not enough; this check needs to be thorough.

The document shepherd read through the document, executed the idnits 1.118 against it, and found no issues.


  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

The references are correctly divided, and all normative references to RFCs are to completed standards-track or BCP documents. There are also three normative references to W3C standards. There are no downward references.


  (1.i)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

          Working Group Summary
            Was there anything in WG process that is worth noting? 
For
            example, was there controversy about particular points or
            were there decisions where the consensus was particularly
            rough?

          Document Quality
            Are there existing implementations of the protocol? 
Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?



Technical Summary:

WebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).

RFC2518 was published in February 1999, and this specification makes minor revisions mostly due to interoperability experience.

Working Group Summary:

After several years of implementation experience with RFC 2518, there was overwhelming consensus within the WebDAV Working Group to clarify under-specified or confusing parts of the specification to make it easier to build interoperable implementations.  A small number of active participants contributed to the development of this document. 
While some of the participants had very different views about the best way to describe a protocol, there is broad consensus about the normative content of the document and rough consensus that the informative and explanatory language in the document improves the quality of the specification and makes it easier for implementors to know what needs to be implemented.  It is easier to understand, makes some simplification to the protocol to  make it easier for implementers, and clarifies under-specified parts of the protocol.

Document Quality:

This specification received a very detailed level of review from several people. Various people have implemented different parts of this specification. A formal matrix has not been formed but it is believed nearly all parts of this specification have been implemented.