FW: webdav feedback

Keith Moore, our Application Area Director, has gotten back to us with his
comments on the WebDAV Distributed Authoring Protocol specification.  As a
result of these comments, a new draft (-09) will be prepared which addresses
these comments, as well as bugs which have been reported to the mailing
list.

At present, the plan is to submit the -09 I-D later this week, then hold a
brief, 1 week Working Group Last Call for Comments to ensure the changes
haven't introduced any new bugs.  At the end of this Last Call, the draft
will be revised if necessary, then forwarded along to Keith Moore for
consideration by the IESG.  At this time, it does not look like it will be
necessary to hold another IETF-wide last call.

- Jim

-----Original Message-----
From: moore@cs.utk.edu [mailto:moore@cs.utk.edu]
Sent: Friday, October 09, 1998 10:17 PM
To: ejw@ics.uci.edu
Cc: moore@cs.utk.edu; yarong@microsoft.com; asad@netscape.com;
srcarter@novell.com; dcjensen@novell.com; paf@swip.net
Subject: webdav feedback


I'm sorry this has taken so long.  Since Chicago, I've had another
week of meetings, two weeks of badly-needed vacation, a week of
illness, and have spent the rest of the time trying to catch up...and
of course I was already way behind on this one.  If it's any
consolation, I think most (hopefully all) of the changes I'm
requesting are merely editorial in nature and won't break the actual
code.

Please forgive me for mentioning nits along with more substantive
problems.

I'll get this on IESG's agenda as soon as you send in a revised
document.

-Keith

1. Several months ago I received the following note from Tim
Berners-Lee.  I want to make sure that WebDAV's use of XML is
consistent with W3C recommendations, or if not, that (a) the
differences are clearly documented, and (b) the reasons for the
differences are explained and provide good justification.


> From: "Tim Berners-Lee" <timbl@w3.org>
> To: "Keith Moore" <moore@cs.utk.edu>
> Subject: XML change and progression to Proposed Rcommendation
> Date: Fri, 17 Jul 1998 18:12:28 -0400
>
> Keith,
>
> You and I/Dan need to coordinate a bit over XML and WebDAV.
>
> The XML group has been producing a much-awaited (fisrt expected last
> October) namespace draft for mixing XML schemas.  It has a draft,
> and working group consensus, and we put through an informal review
> by other groups. The result was a strong pressure for (a) a change
> to the syntax to use an attriute on an element instead of an XML PI
> for declaring a namespace, and (b) stability of a proposed
> recommendation as soon as possible, as more and more products are
> being coded using XML, and more and more specs are citing
> namespaces.
>
> One concern we received from Jim Whitehead was that there are
> (prototype?)  implementations of WebDAV which use the old format,
> and these are the test suites will have to be rewritten.  I am
> alerting you to this.  I think the change is very much on balance in
> the interests of the community.  I wanted to touch base with you so
> you understand the situation here and you can check if thare are any
> other IETF groups you are aware of which are using XML.
>
> I'm away on vacation and off the net for the next 3 weeks from
> tomorrow - but Dan Connolly should be back in and is on top of this
> if anything comes up.
>
> Tim
>
>
> _____________________
>
> Jon,
>
> Following our telephone conversation today, I understand that
> the working group has a "step1" proposal to move from the use of PIs to
> attributes for namespace declarations.
> http://lists.w3.org/Archives/Member/w3c-xml-wg/1998Jul/0158.html
>
> Following the feedback from several working groups and member companies
> during the informal review of the specification, it is clear that for many
> reasons this attribute-based proposal is likely to find much wider support
> than the PI-based one.
>
> At the same time, many specifications and prototypes written to match the
> current draft will have to be rewritten.  However, that is life: that is
why
> prototypes are made, and why we have working drafts before proposed
> recommendations.
>
> This informal review process has I think been effective in that, because
of
> the review, and because of the group's rapid incorporation of the comments
> received, the consensus on the specification under this (step1) proposal
> will be much larger than before.   On this basis I would be happy in
> principle to pass such a specification on for formal Member review as a
> Proposed Recommendation, whereas I feel that to do so with a PI-based
> solution would only lead to a revisiting of the whole matter during that
> Member review and little likelihood of consensus at that level.
>
> I would like to commend the Working Group for producing a proposal which
> addresses the review comments in a timely fashion.
>
> I also understand that there is a consensus within the working group, and
> reviewers who have expressed an opinion, that both defaulting and local
> scoping will be needed.  I note that, as you say, your proposal is
> consistent with a quite intuitive extension to both defaulting and local
> scoping,
> and this reinforces my confidence in putting the specification to the
> Membership.  I think it should
> be made quite clear that this is (subject to Member review as always) the
> current intent, both with a line in the Status of This Document section,
and
> by the release at the same time or immediately afterward of a working
draft
> including these features.  I would like to see of course a timescale for
the
> discussion and testing of these features and a further Proposed
> recommendation based on steps 2 and 3.
>
> The remaining question is of timing: I know that the Working Group
timescale
> has been delayed by this review and I very strongly encourage you to make
a
> suitable document available for proposed Recommendation as soon as
possible,
> ideally within the next week, if you possibly can.
>
> I would like to thank you for taking us all though this, the working group
> for all the work, and the reviewers and team contacts who have
contributed.
>
> Tim Berners-Lee
> Director, W3C


2. [nit] In section 1, at the bottom of page 1, there should be a
semicolon rather than a comma after "extensibility".

3. [nit] Is the reference for Dublin Core [Weibel et. al.], equivalent
to RFC 2413?  If so, we'd prefer that to just a URL.

4. [question] In section 3.5, second paragraph:

>    Because a property's name is universally unique, clients can depend
>    upon consistent behavior for a particular property across multiple
>    resources, so long as that property is "live" on the resources in
>    question.

I take it this means "multiple resources on the same server"?  Could
different servers enforce different rules, even if the property were
"live" on each server?

5. [clarification request] Section 4.1, 3rd paragraph says: "WebDAV
servers MUST treat HTTP URL namespaces as collections" On reading
this, it wasn't immediately clear to me what it meant.

Does this imply (for instance) that there has to be a single BASE URI
which is common to all resources on a WebDAV server?  (seems a little
odd to prevent a server from providing services for multiple domains)

Also I get the idea that a collection is named by its BASE URI, but
I'm not sure that it's explicitly stated anywhere.  (forgive me for
not going back and looking)

6. [clarification request] Section 4.3 says "DAV compliant resources
MUST maintain the consistency of the HTTP URL namespace" without
really explaining what that means beyond a single example.  This needs
some elaboration, or a reference to a definition to what "consistent
HTTP RUL namespace" means.

7. [nit] Section 5.1.  There is an extraneous blank line in the middle
of the fourth paragraph.

8. We've basically decided not to publish the UUID/GUID draft because
it would define the same thing as an existing ISO document, except in
a slightly different way.  So you need to reference the ISO document's
definition of UUIDs.  (Either that or get Paul to revise the UUID/GUID
draft to point to the ISO document as the authoritative definition.)

There's also a security/privacy problem with UUID/GUIDs - since use of
some flavors of UUIDs/GUIDs can expose information about your hardware
(like the manufacturer and essentially its serial number), an
eavesdropper or authorized listener could use them to track movement
of hardware from place to place, the number of each type of computer
system at a site, etc.  This risk, along with any workarounds (change
your MAC address, use other types of UUIDs that don't rely on MAC
address), needs to be documented somewhere.  It might be better placed
in a separate document (especially if you can get Paul to revise the
UUID/GUID draft - it could go there), since WebDAV isn't the only
protocol that wants to use UUIDs/GUIDs.  (SIP is another one, and it's
also in Last Call).

(Maybe I can find time to write this one up...it should only be a page
or two.  But don't make me critical path for this...)

9. [nit] section 6.1

"function independent of the lock"  ->
"function independently of the lock"

10. [editorial] section 6.3. "null resource" isn't defined prior to
use.  I think it would help to move the terminology section to earlier
in the document.

[nit] also in section 6.3:
"resource the resources ceases to be in the lock-null state." ->
"resource the resource ceases to be in the lock-null state." ->

11. on the use of URLs as XML namespaces: there's a scalability and
reliability issue if any particular URIs used as namespace names are
distributed in products that are widely used, and they may not work if
used on private nets not connected to the Internet.  If there's any
chance that people will hard-wire namespace URLs into WebDAV products,
I would like to see the document mention these issues.

12. [clarification] section 7.8.1.  The first paragraph reads (in part)

>   However, the exact state and behavior of the destination
>   resource depend on what information the source resource is able to
>   provide and what information the destination resource is able to
>   accept.

which seems a bit inconsistent with the third paragraph:

>   All properties on the source resource MUST be duplicated on the
>   destination resource, subject to modifying headers and XML elements,
>   following the definition for copying properties.

13. [question] section 7.8.2 says:

>   Live properties SHOULD be duplicated as identically behaving live
>   properties at the destination resource.  If a property cannot be
>   copied live, then its value MUST be duplicated, octet-for-octet, in
>   an identically named, dead property on the destination resource
>   subject to the effects of the propertybehavior XML element.

Is it possible for the source and destination properties to both be
live, but have different rules?  This would prevent creation of an
identical dead property at the destination.

14. section 7.8.3, 6th paragraph:

>    When the COPY method has completed processing it MUST have created a
>    consistent namespace at the destination.  However, if an error
>    occurs while copying an internal member collection, the server MUST
>    NOT copy any members of this collection.  After detecting an error,
>    the COPY operation SHOULD try to finish as much of the original copy
>    operation as possible.  So, for example, if an infinite depth copy
>    operation is performed on collection /a/, which contains collections
>    /a/b/ and /a/c/, and an error occurs copying /a/b/, an attempt
>    should still be made to copy /a/c/. Similarly, after encountering an
>    error copying a non-collection resource as part of an infinite depth
>    copy, the server SHOULD try to finish as much of the original copy
>    operation as possible.

It would help (again) to have elaboration of what "consistent
namespace" means [or maybe a "(See section x.y)" pointing to the
elaboration].

Similarly for "internal member collection": the words "MUST not copy
any members of this [internal member] collection" appear at first to
be inconsistent with "SHOULD try to finish as much of the original
copy operation as possible".

(If I were to restate this as: "if you can't copy all members of a
particular subdirectory, you shouldn't copy any of them, but you
should still try to copy other parts of the directory tree that you
were asked to copy", it would be clearer to me - part of my confusion
stems from the new terminology.)

At the end of 7.8.3 is a paragraph stating "424 Method Failure errors
SHOULD NOT be returned in the 207 Multi-Status from a COPY method".  I
*think* this is saying "if you can't copy a directory (and you report
that), you shouldn't report the failure to copy its children - that is
assumed.  How close did I get?

15. section 7.10.3

What does "replicate" mean here?  If there are really multiple copies
of a resource that can be updated independently, seems like a look
should only apply to a single one of those resources.  If instead
there are multiple URIs for a single instance of a resource, I agree
that the lock should apply to all of them, but I wouldn't use the word
"replicate" to describe that case.

16. [nit] section 8.4.1

"only one" -> "one only"

also, there's an extraneous blank line.

17. section 16.1:

TLS doesn't inherently provide a secure connection, as TLS allows use
of insecure ciphersuites.  TLS is "secure" only if strong ciphersuites
are used (40 bit ciphersuites are certainly not secure enough for
passwords that might be reused in other contexts), and I believe you
need to have mutual authentication to thwart man-in-the-middle
attacks.  (I might be wrong about the latter - server-to-client
authentication might be sufficient to prevent man-in-the-middle
attacks)

18.  TITLE:  I think it would help to put HTTP in the title.
"World Wide Web" doesn't imply HTTP, at least not to everyone.
Maybe "HTTP Extensions for Distributed Authoring"?

19. Please respond to IANA concerns:

> To:      iesg@ISI.EDU
> cc:      iana@ISI.EDU
> From:    iana@ISI.EDU
> Subject: Re: Last Call: Extensions for Distributed Authoring and
Versioning
>          on the World Wide Web -- WEBDAV to Proposed Standard
> Date:    Mon, 04 May 1998 12:59:09 PDT
>
> IESG:
>
> The IANA has reviewed the following Internet-Draft which is in Last
> Call, draft-ietf-webdav-protocol-08.txt, and has the following
> comments/concerns over the publication of this document.
>
> 1) Do you intend to define: "xml" and "DAV" as approved types
>    by this memo?
>
> 2) There are references to the "UUID" I-D by Leach that are normative.



That's it!

Received on Monday, 12 October 1998 15:27:37 UTC