RE: webdav feedback

Keith,

This message details the changes made to the WebDAV Distributed Authoring
Protocol specification to address your comments.

> 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

The specification has been changed to use the most recent XML Namespaces
specification publically available from the W3C, "Namespaces in XML",
WD-xml-names-19980916.  This broad change resulted in many modifications to
the specification:

 * Since the W3C has not yet approved XML Namespaces as a Recommendation, it
does not meet IETF criteria for stability of normative references.  As a
result, we are continuing to "copy by value" the XML Namespaces
specification into Appendix 4.  We do not currently expect there to be
significant modifications to the XML Namespaces specification between now
and its final approval.  Therefore, Appendix 4 has been completely replaced
with the normative text from WD-xml-names-19980916.

 * All examples in the specification which contained XML have been modified
to use the new XML Namespace syntax.

 * Section 14, "XML Processing in DAV" has been modified to remove scoping
rules for XML Namespaces, due to the inclusion of scoping rules in
WD-xml-names-19980916.

It is unfortunate that work on XML Namespaces has not yet finished.
However, based on best current knowledge, there will be fewer future
interoperability problems by changing to the new XML Namespace syntax now,
rather than once there is a large installed base of WebDAV applications.
Furthermore, the scoping rules in the new XML Namespace specification should
result in smaller XML messages being transmitted, since they can be used to
default the prefix character (see section 8.1.3 for an example of this).

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

Changed.

> 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.

The document now references RFC 2413.  RFC 2413 was published after the
submission of draft-ietf-webdav-protocol-08.

> 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?

The intent is for every instance of a live property to have the same
semantics, whether on the same server or on different servers.  We added the
following requirement in section 4.1 (4th paragraph) to address this:

"All instances of a give live property MUST comply with the definition
associated that property name."

> 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)

Based on this comment, as well as discussion on the list, we added language
to section 5.1 and 5.2 to clarify the requirements on DAV namespaces.

Section 5.1 reads:

5.1 HTTP URL Namespace Model

   The HTTP URL namespace is a hierarchical namespace where the
   hierarchy is delimited with the "/" character.

   An HTTP URL namespace is said to be consistent if it meets the
   following rule: for every non-null resource A, there exists a non-
   null resource B that is a collection and has resource A as an
   internal member. The root of the namespace is exempt from the
   previous rule.

   Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL
   namespace be consistent.  However, certain WebDAV methods are
   prohibited from producing results that cause namespace
   inconsistencies.


Relevant paragraphs from section 5.2 are:

   For all WebDAV compliant resources A and B for which B is the parent
   of A in the HTTP URL namespace hierarchy, B MUST be a collection
   which has A as an internal member. So, if http://foo.com/bar/blah is
   WebDAV compliant and if http://foo.com/bar/ is WebDAV compliant then
   http://foo.com/bar/ must be a collection and must contain
   http://foo.com/bar/blah as an internal member.

   Collection resources MAY list their non-WebDAV compliant children in
   the HTTP URL namespace hierarchy as internal members but are not
   required to do so. For example, if http://foo.com/bar/blah is not
   WebDAV compliant and http://foo.com/bar/ is a collection then
   http://foo.com/bar/blah may or may not be listed as an internal
   member of http://foo.com/bar/.

   If a WebDAV compliant resource has no WebDAV compliant children in
   the HTTP URL namespace hierarchy then the WebDAV compliant resource
   is not required to be a collection.

   A resource MAY be a collection but not be WebDAV compliant.  That
   is, the resource may comply with all the rules set out in this
   specification regarding how a collection is to behave without
   necessarily supporting all methods that a WebDAV compliant resource
   is required to support.  In such a case the resource may return the
   dav:resourcetype property with the value dav:collection but MUST NOT
   return a DAV header containing the value "1" on an OPTIONS response.

>
> 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.

Section 5.1 now contains a definition for namespace consistency.

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

This is an artifact of using Word to edit the specification.  To generate
IETF formatted documents from Word, it is necessary to print to the
"Generic/Text Printer".  During this printing process, Word adds blank lines
to the output, seemingly at random (perhaps due to quantization errors going
from an internal, floating-point represenation of the page to an integer
representation?).  Anyway, these blank lines need to be detected by hand
using a text editor afterwards, an error-prone process.

> 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...)

Section 6.4 has been changed to reference the ISO RPC specification
(ISO-11578) instead of Paul Leach's UUIDS/GUIDS draft.

To address the security concerns associated with having the IEEE 802 address
in the "node" field of a GUID, an extra section has been added to the
Security Considerations section of the document, section 17.8, "Risks
Connected with Lock Tokens".  Furthermore, section 6.4.1 "Node Field
Generation Without the IEEE 802 Address" has been added, copied from Paul
Leach's draft, to give guidance on how to generate the "node" field without
using an IEEE 802 address.  This two prong approach, highlighting the risks,
and giving a mechanism for avoiding the risks, should give sufficient
information to implementors so they can reasonably handle the security risks
associated with GUIDs.

> 9. [nit] section 6.1
>
> "function independent of the lock"  ->
> "function independently of the lock"

Changed.

> 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.

We have moved the terminology section to the front of the document, section
3, right after the notational conventions.

> [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." ->

Changed.

> 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.

The previous revision of XML Namespaces contained an attribute called "src"
which was intended to give a location (a URL or URN) where an application
might potentially go to retrieve a machine readable description of the
namespace schema.  However, "src", or any "src"-like capability is no longer
in the XML Namespace specification.  I believe your comment addresses this
feature of XML Namespaces.

While it is true that XML Namespaces are expected to regularly be URLs, in
this case URLs are only being used as unique identifiers, and there is no
expectation, need, or requirement that these URLs will ever be used as the
Request-URI of an HTTP (or the argument of another protocol) request.

Since XML Namespaces no longer contain the "src" attribute capability, and
since namespace names never need to be dereferenced, this comment has not
been addressed in the draft.  If we're missing the point, please let us
know.

> 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.

The wording in section 8.8.1 has been modified to clarify this issue.
Basically, the requirement is to duplicate the properties at the destination
if this is at all possible.  However, there is a recognition that this might
not be possible (e.g. the code implementing the live property just might not
be available at the destination).

Section 8.8.1 now reads:

   When the source resource is not a collection the result of the COPY
   method is the creation of a new resource at the destination whose
   state and behavior match that of the source resource as closely as
   possible.  After a successful COPY invocation, 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.  Since the environment at the
   destination may be different than at the source due to factors
   outside the scope of control of the server, such as the absence of
   resources required for correct operation, it may not be possible to
   completely duplicate the behavior of the resource at the
   destination. Subsequent alterations to the destination resource will
   not modify the source resource.  Subsequent alterations to the
   source resource will not modify the destination resource.

> 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.

No -- a live property must behave the same across all instances.  This
comment was addressed by adding the requirement to section 4.1 (4th
paragraph):

"All instances of a give live property MUST comply with the definition
associated that property name."

> 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].

This has been addressed by defining namespace consistency in section 5.1,
and by adding a reference to section 5.1 in section 8.8.3 (6th paragraph).

> 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?

Exactly right.

We added some additional text to section 8.8.3 to clarify this topic:

   When the COPY method has completed processing it MUST have created a
   consistent namespace at the destination (see section 5.1 for the
   definition of namespace consistency).  However, if an error occurs
   while copying an internal member collection, the server MUST NOT
   copy any members of this collection (i.e., the server must skip this
   subtree), as this would create an inconsistent namespace. After
   detecting an error, the COPY operation SHOULD try to finish as much
   of the original copy operation as possible (i.e., the server should
   still attempt to copy other subtrees and their members, that are not
   descendents of an error-causing collection).  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.

> 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.

We changed the language in section 8.10.3 to not use "replicate", instead
discussing the phenomenon in terms of being able to access the same resource
through multiple URLs.

The new text reads:

8.10.3    Locking Replicated Resources

   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.

> 16. [nit] section 8.4.1
>
> "only one" -> "one only"
>
> also, there's an extraneous blank line.

Changed.

> 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)

Text was added to section 17.1 to explicitly state that TLS is only secure
when using secure ciphersuites, and mutual authentication:

   Examples of secure connections include a
   Transport Layer Security (TLS) connection employing a strong cipher
   suite with mutual authentication of client and server, or a
   connection over a network which is physically secure, for example,
   an isolated network in a building with restricted access.


> 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"?

We changed the title to "HTTP Extensions for Distributed Authoring --
WEBDAV"

> 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.

Done.

- Jim

Received on Saturday, 24 October 1998 18:19:47 UTC