Subject: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt

From: [email-masked]
Date: Thu, 06 Mar 2003 06:29:16 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF.

	Title		: HTTP Extensions for Distributed Authoring - WebDAV 
                          RFC2518 bis
	Author(s)	: Y. Goland et al.
	Filename	: draft-ietf-webdav-rfc2518bis-03.txt
	Pages		: 90
	Date		: 2003-3-5
	
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, namespace 
manipulation, and resource locking (collision avoidance). 
RFC2518 was published in February 1998, and this draft makes only 
minor revisions mostly due to interoperability experience.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-webdav-rfc2518bis-03.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-webdav-rfc2518bis-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-webdav-rfc2518bis-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 13 Mar 2003 16:50:27 +0100

Hi,

I just reviewed the current draft, checking the issues I raised for draft 02
in September 2002:

	http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0372.html

Unfortunately, it seems that almost all the issues I raised haven't been
addressed. Below is an updated list:

1) References to RFC2616

References have been updated to point to RFC2616 rather than RFC2068, but it
seems that all (most?) section numbers still need to be updated.

2) Section 4.4

Replace "MUST not" by "MUST NOT"

4) Section 6.3, p1

Replace

"A lock token is returned by every successful LOCK operation in the
lockdiscovery property in the response body, and can also be found through
lock discovery on a resource."

by

"A lock token is returned by every successful LOCK operation in the
lock-token header of the response, and can also be found through lock
discovery on a resource"

5) Section 6.3, p3

Replace

"However resources are free to return any URI scheme so long as it meets the
uniqueness requirements."

by

"However servers are free to use any IETF-registered URI scheme so long as
it meets the uniqueness requirements."

(If it's not IETF-registered, I don't see how it can possibly meet the
uniqueness criterium).

6) Section 8.1.1 (use of XML)

Replace

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML].  All XML used in either requests or responses
MUST be, at minimum, well formed.  If a server receives ill-formed XML in a
request it MUST reject the entire request with a 400 (Bad Request)."

by

"Some of the following new HTTP methods use XML as a request and response
format.  All DAV compliant clients and resources MUST use   XML parsers that
are compliant with [REC-XML] and [REC-XML-NAMES].  All XML used in either
requests or responses MUST be, at minimum, well formed and
namespace-well-formed.  If a server receives ill-formed XML in a request it
MUST reject the entire request with a 400 (Bad Request)."

7) Section 8.1.2 (required bodies)

says...: "In cases where a request body is present but would be ignored by a
server, the server MUST reject the request with 415 (Unsupported Media
Type)."

I don't understand this requirement. If a body isn't defined, it should be
ignored, right? (isn't MKCOL a special case?)

8) Section 8.1.4 (required headers)

"Note that HTTP 1.1 requires the Date header in all responses." -> not
true - clockless origin servers are treated as a special case

9) Section 8.2

"URLs for collections appearing in the results MUST end in a '/'
character." -> I don't think we have consensus on this.

Furthermore, this section seems to attempt to define a subset of relative
URI resolution -- I think this is a VERY bad idea. Clients should properly
resolve URIs against the request URI -- if we must, we can simplify this
requirement by restricting the set of allowed relative URIs to those
starting with an absolute path.

10) Section 8.2.2

"The resource http://www.foo.bar/container/index.html, a member of the
"container" collection, has nine properties defined on it,
http://www.foo.bar/boxschema/bigbox, DAV:creationdate, DAV:displayname,
DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, DAV:getlastmodified,
DAV:resourcetype, and DAV:supportedlock." -> bad syntax for property names.

Also: the example for propfind/allprop is missing.

11) Section 8.3

"All DAV compliant resources MUST support the PROPPATCH method and MUST
process instructions that are specified using the propertyupdate, set, and
remove XML elements of the DAV schema" -> What is the "DAV schema"???

Also, replace

"Instruction processing MUST occur in the order instructions are received
(i.e., from top to bottom)"

by

"Instruction processing MUST occur in document order" (standard XML
processing term)

12) Section 8.7

Replace

"424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi-Status)."

by

"424 (Failed Dependency) errors SHOULD NOT appear in the 207
(Multi-Status)."

13) Section 8.11, refreshing locks

"A locks is refreshed by sending a new LOCK request to the resource which is
the root of the lock."

Question: does it really need to be the root?

14)  Section 8.11, The Effect of Locks on Properties and Collections

"This means that if a collection is locked, its lock-token is required in
all these cases:
-	DELETE a collection's direct  internal member
-	MOVE a member out of the collection
-	MOVE a member into the collection, unless it overwrites a pre-existing
member"

I think the latter is not really consistent with RFC3253.

15) Section 8.11, Locking unmapped URLs

"A server MUST respond successfully to a GET request to an empty resource,
either by using a 204 No Content response, or by using 200 OK with a
Content-Length header indicating zero length and an server-determined
Content-Type."

Do not mention the content type at all. No content type is fine as well.

16) Section 8.11.2

Replace

"Lock-Token: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>)"

by

"Lock-Token: <opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>"

17) Section 8.12

Replace

"A successful response to an UNLOCK method does not mean that the resource
is unlocked."

by

"A successful response to an UNLOCK method does not mean that there are no
locks left on the resource."

(at least I think this is the intent of the sentence, otherwise it needs to
be rephrased differently)

18) Section 9.1

I'd like to see the rational for the "extend" production.

19) Section 9.3

Language describing the process of relative URI resolution should go.

21) Section 11.4

Replace

" - The server does not ever accept this method on this kind of resource.
For example, a PUT is not accepted on a collection."

by

" - The server does not ever accept this method on this kind of resource.
For example, if a PUT is not accepted on a collection."

22) Section 11.5

I think that there are *many* more cases that can cause a 409 (see RFC3253)

23) Section 12

Again, an attempt to define relative URI resolution. Don't do that, just
refer to RFC2396 and say that URIs in a multistatus response are resolved
against the request URI.

24) Section 12.1

Proposal: add an example.

25) Section 13.4 (lockroot)

Proposal: only require it for deep locks.

26) Section 13.6

Replace:

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST have this value"

by

"Identifies the associated resource as a collection. The resourcetype
property of a collection resource MUST contain this element."

27) Section 13.16

Remove

"May contain additional elements not defined in this document."

That's true for *all* XML in request/response bodies (also reccurs in other
places)

28)  Section 13.24

Replace

"Language tagging information in the property's value (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."

by

"Language tagging information in scope of the property (in the "xml:lang"
attribute, if present MUST be persistently stored along with the property,
and MUST be subsequently retrievable using PROPFIND."

29) Section 13.26

Replace

"The allprop XML element specifies that all property names  and values on
the resource are to be returned."

by

"The allprop XML element specifies that all names and values of all dead
properties and the live properties defined by this document on the resource
are to be returned."

30) Section 14.7

"A change in a property SHOULD NOT cause the last-modified date to change,
because clients MAY rely on the last-modified date to know when to overwrite
the existing body."

I think this is a new requirement that hasn't been discussed. BTW: it's
inconsistent with the attempt to make ETags a MUST -- if you have Etags, you
don't have to rely on the last modified date anyway.

31) Section 18.6, Reduction of Security due to Source Link

can be removed

32) Section 19, IANA consideration (old text)

"URIs are used for both names, for several reasons. Assignment of a URI does
not require a request to a central naming authority, and hence allow WebDAV
property names and XML elements to be quickly defined by any WebDAV user or
application.  URIs also provide a unique address space, ensuring that the
distributed users of WebDAV will not have collisions among the property
names and XML elements they create"

This is wrong. Properties are NOT identified by URIs. They are identified by
XML QNames.

33) Editorial note

I think that removing the section numbers from the 3rd-level section names
is a bad idea.

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 13 Mar 2003 10:30:25 -0800

> MUST reject the entire request with a 400 (Bad Request)."

Please note that use of an XML-compliant parser for an Internet protocol
will introduce a simple and well-known denial-of-service problem 
involving
recursive entity declarations.

....Roy

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 13 Mar 2003 20:39:36 +0100

Roy,

known issue.

RFC2518bis specifically allows rejection  of requests using external
entities (this should take care of the "one million laughs" attach).

Julian

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Roy T. Fielding
> Sent: Thursday, March 13, 2003 7:30 PM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: Re: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt
>
>
>

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 13 Mar 2003 11:51:50 -0800

> known issue.

Good, but that sentence you quoted contradicts it.  XML doesn't
allow subsetting.

> entities (this should take care of the "one million laughs" attach).

Recursive entity declarations are internal entities.  :(

....Roy

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 13 Mar 2003 22:05:30 +0100

> From: Roy T. Fielding [mailto:[email-masked]]
> Sent: Thursday, March 13, 2003 8:52 PM
> To: Julian Reschke
> Cc: [email-masked]

Do you have a proposal how we can refer to the specs, and still allow
subsetting (allowing rejection of internal entities)?

> Recursive entity declarations are internal entities.  :(

Indeed.

So I must take back what I said: the problem is known but has *not* been
considered yet in the draft.

Jason, Lisa: we badly need to add this to the issues list and fix it in the
next draft.

(the issue being: recursive entity declarations can be used for effective
DOS attacks, and thus WebDAV MUST allow servers to reject these kind of
requests, even though they may be well-formed).

Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 13 Mar 2003 13:38:19 -0800

> subsetting (allowing rejection of internal entities)?

Not a good one.  The TAG has discussed it, and SOAP 1.2 has its own
wording, but there is no general agreement on how it should be spec'd.
SOAP disallows any form of internal DTD-style declaration.

   http://www.w3.org/2001/tag/ilist#xmlProfiles-29

....Roy

---

From: "Julian Reschke" <[email-masked]>
Date: Tue, 18 Mar 2003 13:51:43 +0100

Here's a set of both -bis03 and generic RFC2518 comments:

Content:

03-C01

Paragraph 1: “A DTD is provided…” -> “An informational DTD is provided…”

03-C02

4.4: “…or when they may be shown to a human user and hence require encoding
in…”

I’m not sure what the requirement “may be shown to a human user” is supposed
to mean here. Proposal: just write:

“…or when they require encoding in…”

03-C03

4.4: “Note that the use of a new top-level URI identifier as a namespace is
considered by many to be a bad thing…”

Rewrite as:

“Note that both defining a new URI scheme just for the purpose of
identifying protocol elements, and using just the scheme name as a namespace
name is to be considered a bad practice, and should not be copied”.

03-C04

4.5: “The value of a property when expressed in XML MUST be well formed.”

The value of a property always is expressed in XML (or more precisely: an
XML fragment). XML by definition is well-formed.

03-C05

4.5: “The value of a property appears inside the property name element.  The
value may be any text, including valid XML.  When the value is  structured
as XML, namespaces that are in scope for that part of the  XML document
apply within the property value as well, and MUST be  preserved in server
storage for retransmission later. Namespace prefixes need not be preserved
due to the rules of prefix declaration in XML.”

1)	I think this needs to rephrased to use proper XML terminology, also
2)	I think that namespace prefixes within the property value do need to be
round.tripped.

Proposal:

“The value of a property appears inside the property name element and may be
any kind of well-formed XML content, including both text-only and mixed
content. When the property value contains further XML elements, namespaces
and namespace prefixes that are in scope for that part of the XML document
apply within the property value as well, and MUST be preserved in server
storage for retransmission later.”

03-C06:

6.3: “A lock token is returned by every successful LOCK operation in the
lockdiscovery property in the response body, and can also be found through
lock discovery on a  resource. Each lock has only one unique lock token.”

Change to:

“A lock token is returned by every successful LOCK operation in the
lock-token header, and can also be found through lock discovery on a
resource. Each lock has exactly one unique lock token.”

03-C07:

6.4: “All resources MUST recognize the opaquelocktoken scheme and, at
minimum, recognize that the lock token does not refer to an outstanding lock
on the resource.”

(old text) I think this is misleading. Any resource must recognize any valid
URI. If a URI uses a scheme it doesn’t know of, this simply means it doesn’t
identify any particular lock assigned by this server. So I’d recommend to
get rid of this sentence, and possibly add a clarification to 6.3 instead.

03-C08:

7.4: “However, interoperability and compliance problems have been found with
lock-null resources.  Therefore, they are deprecated.  WebDAV servers
compliant with this document SHOULD create regular locked empty resources,
which behave in every way as if they were a normal resource.”

This sort of suggests that lock-null resources indeed are still something
different than a normal resource, which isn’t true.

03-C09:

7.4: “Can be downloaded, deleted, moved, copied, and in all ways behave as a
regular resource, not a lock-null resource.”

I think the term “downloaded” is misleading here. From a WebDAV protocol
p.o.v., it probably should be “read”.

03-C10:

7.4.: “SHOULD default to a content-type of "application/octet-stream". “

No. I don’t think there’s consensus for that, and requiring a specific
content type seems to have no value at all to clients (see also 8.11,
“Locking Unmapped URLs”).

03-C11:

7.8: “If an error is received in response to a refresh LOCK request the
client SHOULD assume that the lock was not refreshed.”

I think we should make that a “MUST”.

03-C12:

8.1.1.: “Some of the following new HTTP methods use XML as a request and
response format.  All DAV compliant clients and resources MUST use  XML
parsers that are compliant with [REC-XML].”

Add “…and [REC-XMLNS]”.

We also need allow servers and clients to rejects a certain set of
request/response that are indeed well-formed, in particular:

-	when it exceeds some predefined size or
-	when expansion of internal entities may cause a denial of service.

03-C13:

8.1.2: “Some of these new methods do not define bodies.  Servers MUST
examine all requests for a body, even when a body was not expected.  In
cases where a request body is present but would be ignored by a  server, the
server MUST reject the request with 415 (Unsupported  Media Type).  This
informs the client (which may have been attempting to use an extension) that
the body could not be processed as they intended.”

I’d like to understand whether this affects methods other than MKCOL.

03-C14:

8.1.3: “When the Location header is used in a response, it is used by the
server to indicate the preferred address for the target resource of  the
request.  Whenever the server has a preferred address, it should  use that
address consistently.  This means that when a response contains a Location
header, all the URLs in the response body (e.g. a Multi-Status) should be
consistent.”

If we keep this paragraph, we’ll have to define what “consistent” means
here.

03-C15:

8.1.4.: “Note that HTTP 1.1 requires the Date header in all responses.”

That’s not true. HTTP 1.1 specifically supports clockless servers.

03-C16:

8.1.5: “If ETags are supported for a resource, the server MUST return the
ETag header in all PUT and GET responses to that resource, as well as
provide the same value for the 'getetag'  property.”

Note that this breaks the “etag promotion” strategy used both by IIS and
Moddav (PUT usually returns weak etags which later are promoted to strong
etags when there was no other change to that resource within a specific time
window). Therefore I’d make that a SHOULD (at least for PUT).

03-C17:

8.1.5.: “Because clients may be forced to prompt users or throw away changed
content if the ETag changes, a WebDAV server MUST not change the  ETag (or
getlastmodified value) for a resource when only its property values change.”

Some servers do, and I don’t think we can change that. Therefore I think
this change at least needs explicit consensus on the mailing list.

03-C18:

8.1.6: “HTTP and WebDAV did not use the bodies of most error responses until
DeltaV introduced a mechanism to include more specific information in the
body of an error response (section 1.6 of [RFC3253]).”

That’s not really true. HTTP indeed recommends to send error descriptions in
the response bodies as well.

03-C19:

General comment re: 8.1.6: I really like that change (actually, I like it so
much that I’d like to have condition names for all frequently signalled
problems….). However, if it uses the same format as RFC3253, it should be
consistent with it. In particular, the names should identify conditions that
must be met. For instance, use “allow-external-entities” rather than
“forbid-internal-entities”. We may also want to note that one DAV:error
element can hold multiple elements identifying failed conditions.

03-C20:

8.2.: “DAV compliant servers MUST support the "0", "1" and "infinity"
behaviors.”

Change to:

“DAV compliant servers MUST support the "0" and "1" behaviors and MAY
support the "infinity" behavior.”

03-C21:

8.2.: “Note that ‘allprop’ does not return values for all properties.”

Change to:

“Note that ‘allprop’ does not return values for all live properties.”

03-C22:

8.2: “URLs for collections appearing in the results MUST end  in a slash
character.”

I don’t think we have consensus for this being a MUST.

03-C23:

8.2: “Note that URLs and URIs in XML must always be fully legal URIs. For
example, it is illegal to use a space character or double-quote in a  URI
[RFC2396].  URL-escaping is commonly used (e.g. replace a space with a
sequence such as %20). The URI must not appear in XML "unescaped", it must
be in its legal URI format.”

This is misleading. Of course URIs must conform to the URI syntax – that’s
the whole point, right? In particular, there’s no such thing as a “unescaped
form” of a URI. URIs do not allow the space character, and therefore a URI
never ever contains a space character.

What we should say here is how servers should behave when their internal
implementation model of collections allow member names that aren’t legal URL
path segments (answer: encode as UTF-8 octet stream, then URI-escape).

03-C24:

8.2.2: “This example also demonstrates the use of XML namespace scoping, and
the default namespace.  Since the "xmlns" attribute does not contain  an
explicit "shorthand name" (prefix) letter, the namespace applies by default
to all enclosed elements.  Hence, all elements which do not explicitly state
the namespace to which they belong are members  of the "DAV:" namespace
schema.”

Change to:

“This example also demonstrates the use of XML namespace scoping, and  the
default namespace.  Since the "xmlns" attribute does not contain a prefix,
the namespace applies by default to all non-prefixed enclosed elements.
Hence, all elements which do not explicitly state the namespace to which
they belong are members  of the "DAV:" namespace.”

(Actually I’d rather prefer to get rid of this. RFC2518bis shouldn’t try to
give XML lessons).

03-C25:

8.7: “If the DELETE method is issued to a non-collection resource whose
URIs are an internal member of one or more collections, then during  DELETE
processing a server MUST remove any URI for the resource identified by the
Request-URI from collections which contain it as a member.”

I think we want to get rid of this statement. Does anybody implement this
right now?

03-C26:

8.11: “The LOCK request may have a Timeout  header.”

“may” -> “MAY”.

03-C27:

8.11, “Interaction with other Methods”: “However, independent of lock type,
a successful DELETE  of a resource MUST cause all of its locks to be
removed.”

(old text) I think this is misleading. A DELETE on a resource only removes
those locks that aren’t inherited.

03-C28:

8.12: “A successful response to an UNLOCK method does not mean that the
resource is unlocked.  At most, it means that the specified token no longer
identifies a lock on the resource.”

Change to:

“A successful response to an UNLOCK method does not mean that the resource
is unlocked.  At most, it means that the specified token no  longer
identifies a lock on any resource.”

03-C29:

9.1 (DAV header) allows coded URLs in the DAV header. I’d like to see the
rationale for that.

03-C30:

9.4 (force-authenticate): is this the consensus we reached in January?
Ilyas, did you take notes?

03-C31:

9.5 defines “<no-lock>” as a new special state token. I think this is
unneeded – any URI which is known not to identify a lock MUST work as well,
so we can simply recommend using something like “<DAV:no-lock>” (which is
something that RFC2518-compliant servers already support).

03-C32:

(old text) The example in 9.5.2 uses an invalid lock token (the URI scheme
“locktoken” isn’t IETF-registered, so it can’t claim conformance to the
uniqueness requirements). Just use a sample token using the
 “opaquelocktoken” scheme instead).

03-C33:

9.5.5: “The not production is used to reverse that value.”

Change to:

“The ‘Not’ production is used to reverse that value.”

03-C34:

Section 13: XML element definitions

I don’t like the syntax change in the DTDs. For instance, activelock now is
defined as:

   <!ELEMENT activelock ANY>
   ANY value: Any number of elements, including one of each of
   (lockscope, locktype, depth, owner, timeout, locktoken, lockroot)

It used to be:

   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
   locktoken?) >

For consistency with RFC2518, RFC3253 and the ACL spec we really should stay
with the old notation.

03-C35:

Section 17: “which has explicit provisions for character set tagging and
encoding, and requires that XML processors read XML elements encoded, at
minimum, using the UTF-8 [UTF-8] encoding of the ISO  10646 multilingual
plane.”

Unless we get rid of this section, we’ll have to add UTF-16.

03-C36:

Section 17: “Names used within this specification fall into three
categories:  names of protocol elements such as methods and headers, names
of XML elements, and names of properties.”

We may want to add a new category (condition names).

Editorial notes:

03-E01

Expiry date is wrong.

03-E02

IETF wants a maximum of 5 authors.

03-E03

Paragraph 1: “marshall”  -> “marshal”

03-E04

There are many places where example URLs do not use the set of example host
names allowed by the IETF.

03-E05

8.1.5 uses the term “etag”. HTTP uses “etag” only as header names, and talks
about “entity tags” everywhere else. So should we.

03-E06

8.2.2 uses the term “progeny”, which I haven’t seen before in this context.
Maybe replace by something more common, such as “members”.

03-E07:

8.2.2. still uses concatenation of namespace names and element names to
identify property names.