I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-webdav-rfc2518bis-17.txt
Reviewer: Elwyn Davies
Review Date: 30/01/2007
IETF LC End Date: 21/01/2007
IESG Telechat date: (if known) -

Summary: Apologies for the late review - I missed the aassignment somehow.
This document is almost ready for the IESG.  There are a couple of 
issues which need a little clarification IMO and the IANA considerations 
are suffering from 'a standard problem' - RFC 2518 defined most of 
things claimed to be needing registration as a result of this document 
so they are not actually new, but RFC 2518 didn't actually have explicit 
IANA considerations.  Consequently the IANA considerations need to be 
rephrased to clarify that these are updated definitions rather than 
new.  There are also some minor editorial nits that could get fixed 
during the update. Caveat: I have not made a detailed check of the 
syntax/semantics of the examples.

Comments:
Issues:

s4.3, para 2: 'Older clients will not break when they encounter 
extensions because they will still have the data specified in the 
original schema and MUST ignore elements they do not understand.'  This 
specification cannot enforce compliance retrospectively! s/MUST/were 
required to/.

s6.6, para 3: 'notifications should be sent': Is this supposed to be a 
function of webdav?  This is the only mention of lock notifications in 
the document.

Potential security implications of lockdiscovery:  s6.8 requires a 
compliant server to support lockdiscovery and expects the response to 
this request to include the names of principals and potentially the lock 
tokens for locks being held on a resource.  The privacy implications of 
this are discussed in the Security Considerations but it does not appear 
to be allowed to restrict or deny this request purely on security 
grounds.  It is likely that some organizations might consider the 
ability to determine who holds locks is a sensitive matter beyond just 
issues of privacy, and the responses to lockdiscovery might be mediated 
by access controls.

s9.1: PROPFIND method: It is probably not a big deal, but the ability of 
'new' servers to deny depth-infinity PROPFIND requests interacts with 
the suggestion that they should treat client requests without a Depth 
header as depth-infinity requests.  This may result in a different 
response from a fully compliant new server as compared with a legacy RFC 
2518 server.  Is this likely to cause severe disruption to legacy clients?

Treatment of 'allprop':  I believe that the various statements about 
which live properties will be returned by 'allprop' are not fully 
consistent.  In the third bullet of s9.1 it is stated that allprop gets 
you 'property values for those properties defined in this specification' 
and offers the 'include' element as a way to increase the set of values 
returned. This interpretation is repeated in the examples (especially 
s9.1.6) and s14.2. However, the paragraph next but one after the bullets 
(split across the  page 40/41 page boundary) states 'For a live property 
defined elsewhere, that definition can specify whether that live 
property would be returned in 'allprop' requests or not.'  Finally 
Appendix F.1 states that the allprop semantics 'have been relaxed so 
that servers *may* [My emphasis] leave out live properties defined in 
other specifications'.  So it appears that there are three different 
possibilities here - some clean up is needed.

s21 IANA Considerations:
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.

Editorial
=======

general: Check the capitalization of headings (e.g., s7.5.2).

s1, paras 9/10: s/new/extra/ (2 places) - they certainly aren't new in 
this specification.

s1, para 11: s/request and response/requests and responses/, s/all 
all/all/, move cross-ref to Section 17 to end of sentence.

s4.3, para 3: s/undefined), not multiple values/undefined); it does not 
have multiple values/

s6.1, item 4: This is the first appearance of the 'depth' concept and it 
isn't defined previously.  I think something could be usefully added to 
the terminology section to introduce depth, and specially infinite depth.

general: various forms are used to refer to requests with 'Depth: 
infinite' attributes.  'infinite depth', 'Depth: infinite' and 
'depth-infinite'.  It would be good to be consistent.

s6.1, item 5: It would be good to clarify that locks (or at least their 
id's) are *globally* unique here.

s6.1, ietm 7: It would be helpful to quote If in this paragraph ("If") 
as this is the first occurrence of the term and it is a little confusing 
on first reading.

s6.2: s/Email/email/ (I think this is now the approved form).

s7.4, para 2: s/a write lock/any write lock/ (I was not sure initially 
if we were still talking about infinite-depth locks).

s8.6.2, para 2: For the less well-informed, it would be useful to 
explain the difference between weak and string Etags at the start of 
this discussion(or at least give an immediate reference).  As is clear 
from the later words, finding a definition elsewhere is not simple!

s8.7:  The use of DeltaV here is obscure.  I understand it was a design 
team name.

s9.2: I think I know what 'document order' means but it isn't actually 
defined.

s9.6.1: I think it would be helpful to explicitly list which properties 
are not returned because of the way allprop is defined.

s10.7: The abbreviation LWS is not expanded until later.

s13, item 1: s/excecution/execution/






_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf