Skip to main content

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

Yes

(Ted Hardie)

No Objection

(Bill Fenner)
(Dan Romascanu)
(David Kessens)
(Jari Arkko)
(Jon Peterson)
(Magnus Westerlund)
(Mark Townsley)
(Ross Callon)
(Russ Housley)
(Sam Hartman)

Recuse

(Cullen Jennings)
(Lisa Dusseault)

No Record


Note: This ballot was opened for revision 18 and is now closed.

Ted Hardie Former IESG member
Yes
Yes () Unknown

                            
Bill Fenner Former IESG member
No Objection
No Objection () Unknown

                            
Brian Carpenter Former IESG member
No Objection
No Objection (2007-03-05) Unknown
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).
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Kessens Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
No Objection
No Objection (2007-03-06) Unknown
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.
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
(was Discuss, No Objection) No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
Recuse
Recuse () Unknown

                            
Lisa Dusseault Former IESG member
Recuse
Recuse () Unknown

                            
Chris Newman Former IESG member
No Record
No Record (2007-03-08) Unknown
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.