Subject: Review of RFC2518bis pre-draft

From: Julian Reschke <[email-masked]>
Date: Fri, 09 Dec 2005 20:35:22 +0100

...as of today; as seen at 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-latest.txt>. 
This review mainly covers minor changes compared to -08 which 
(hopefully) do not need a BugZilla entry. Please try to fix those before 
submitting a new draft.

3. Terminology

Inconsistent typography (":" vs "-")

"A URI mapping can be thought of as a URL pointing to a resource."

I'm not sure what this is supposed to mean. Please remove it or clarify.

7.6  Write Locks and Unmapped URLs

    A successful lock request to an unmapped URL MUST result in the
    creation of an locked resource with empty content.  Subsequently, a
    successful PUT request (with the correct lock token) provides the
    content for the resource, and the server MUST also use the content-
    type and content-language information from this request.

Making this a MUST creates a conflict with an upcoming TAG finding by 
Roy Fielding.

8.2.6 Example - Using 'allprop' to Retrieve Dead Properties and RFC2518 
Properties

Nits:

- move it back where it was in RFC2518
- avoid the term RFC2158 properties in the title
- XML in example to be fixed, for instance whitespace in D:getlastmodified
- intra-doc reference to Section 13 is incorrect

Obviously this has been copied verbatim from RFC2518 without any sanity 
checks.

8.3.1

    200 (OK) - The property set or change succeeded.  Note that if this
    appears for one property, it MUST appear for every property in the
    response, due to the atomicity of PROPPATCH.

(2nd sentence) Again, this is correct, but

a) doesn't really need to be mentioned,

b) but if is mentioned, then using MUST is incorrect here. This is imply 
an observation based on normative text somewhere else, not a new interop 
requirement.

8.7  DELETE

    WebDAV adds some requirements to DELETE handling.  Locks rooted on a
    resource MUST be destroyed in a successful DELETE of that resource.

This is still a lame way to introduce DELETE. Please move the second 
sentence somewhere else, potentially a subsection (see also 
<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=103#c2>).

8.9.5  Status Codes

    403 (Forbidden) - The operation is forbidden.  A special case for
    COPY could be that the source and destination resources are the same
    resource.

Confusing. Servers may treat this as a nop, just returning 200. Just be 
silent about it.

8.10.4  Status Codes

    204 (No Content) - The source resource was successfully moved to
    overwrite pre-existing destination resource.

Sentence broken compared to -08.

    403 (Forbidden) - In addition to general reasons for forbidding a
    MOVE operation, it could be that the source and destination resources
    are the same.

And being source and destination identical would be a problem exactly why?

12.1  Response headers

    Use of the Location header with the Multi-Status response is
    intentionally undefined.  The server MAY always redirect the entire
    request by responding with a 300 level status response instead of a
    Multi-Status response.

This section doesn't provide any useful information. In particular, the 
second sentence seems to be completely out of context.

12.2  URL handling

    When a Multi-Status body is returned in response to a PROPFIND or
    another request with a single scope (no Destination header), it can
    contain one or more 'response' element with an 'href' element for the
    URL of the resource described in that 'response' element.  Each of

And in the other case this is not true?

    these response URLs MUST be equal to or inside the Request-URI.  The
    response URLs MAY be absolute or relative references but MUST NOT
    include "." or ".." as path elements.

URLs never are relative references. There is no such thing as an 
absolute reference.

    If a response URL is relative reference, it MUST be resolved against
    the Request-URI.  A relative reference MUST be an absolute path (note
    that clients are not known to support relative paths).

May I again recommend to just use the text I proposed earlier? It uses 
the proper terminology from RFC3986.

    URLs for collections appearing in the results SHOULD end in a '/'
    character.

And the rule does not apply if it's not a URL, such as a relative reference?

    If a server allows resource names to include characters that aren't
    legal in HTTP URL paths, these characters must be URI-escaped on the

Again, terminology. It's called "Percent-Encoding", and we should refer 
to the exact section in RFC3986.

    wire.  For example, it is illegal to use a space character or double-
    quote in a URI.  URIs appearing in PROPFIND or PROPPATCH XML bodies
    (or other XML marshalling defined in this specification) are still
    subject to all URI rules, including forbidden characters.

12.3  Handling redirected child resources

    Redirect responses (300-303, 305 and 307) defined in HTTP 1.1
    normally take a Location header to indicate the new URI for the
    single resource redirected from the Request-URI.  Multi-Status
    responses contain many resource addresses, but the original
    definition in RFC2518 did not have any place for the server to
    provide the new URI for redirected resources.  This specification
    does define a 'location' element for this information (see
    Section 13.9).  Servers MAY use this new element or MAY stick with
    the original syntax.

Sounds like "We don't care what servers do".

19.7  Risks Connected with Lock Tokens

    This specification encourages the use of "A Universally Unique
    Identifier (UUID) URN Namespace" ([RFC4122]) for lock tokens
    Section 6.3, in order to guarantee their uniqueness across space and
    time.  The security considerations for UUIDs do not apply because
    WebDAV does not assume that lock tokens are supposed to be hard to
    ...

Wow! They don't apply? Why can't we just stick with what RFC2518 said,
just updating what needs to be updated, and leaving the rest alone?
Proposed text:

    This specification, in Section 6.3, encourages the use of Universal
    Unique Identifiers (UUIDs) in lock tokens, in order to guarantee
    their uniqueness across space and time.  Version 1 UUIDs, as defined
    in Section 4 of [RFC4122], may contain a "node" field which "consists
    of an IEEE 802 MAC address, usually the host address.  For systems
    with multiple IEEE 802 addresses, any available one can be used".
    Since a WebDAV server will issue many locks over its lifetime, the
    implication is that it may also be publicly exposing its IEEE 802
    address.

    There are several risks associated with exposure of IEEE 802
    addresses.  Using the IEEE 802 address:

    o  It is possible to track the movement of hardware from subnet to
       subnet.

    o  It may be possible to identify the manufacturer of the hardware
       running a WebDAV server.

    o  It may be possible to determine the number of each type of
       computer running WebDAV.

    This risk only applies to host address based UUID versions.  Section
    4 of [RFC4122] describes several other mechanisms for generating
    UUIDs that do involve the host address and therefore do not suffer
    from this risk.

22.1 Normative References

[2518] still appears under "normative".

Best regards, Julian

---

From: Elias Sinderson <[email-masked]>
Date: Fri, 09 Dec 2005 14:46:07 -0800

> Inconsistent typography (":" vs "-")

Fixed.

> I'm not sure what this is supposed to mean. Please remove it or clarify.

Removed.

> Making this a MUST creates a conflict with an upcoming TAG finding by 

Discussion needed; created new bugzilla issue.

> 8.2.6 Example - Using 'allprop' to Retrieve Dead Properties and 
> RFC2518 Properties
>
> Nits:

Renamed; brief explanatory note added.

> - XML in example to be fixed, for instance whitespace in 

Fixed the example. However, since DAV:get* properties are based upon 
definitions made in rfc2616, LWS may be found in some implementations -- 
explanatory text added to section 14.

> - intra-doc reference to Section 13 is incorrect

Fixed.

> 8.3.1 [...] (2nd sentence) Again, this is correct, but
> b) but if is mentioned, then using MUST is incorrect here. [...]

2nd sentence left in, with MUST removed.

> 8.7  DELETE [...] This is still a lame way to introduce DELETE.  [...]

> 8.9.5  Status Codes [...] 403 (Forbidden) [...] Confusing. Servers may 
> treat this as a nop, just returning 200. Just be silent about it.

Discussed this but left the text in, as the semantics were defined in 
2518 (see similar comment below).

> 8.10.4  Status Codes
>    204 (No Content) - [...] Sentence broken [...]

Rewrote text to clarify 204 and 201.

>    403 (Forbidden) [...] And being source and destination identical 
> would be a problem exactly why?

Semantics defined in 2518, left alone as a change could compromise 
resource identity (e.g. creation date may change, corruption of version 
history, etc.).

> 12.1  Response headers [...] This section doesn't provide any useful 
> information. In particular, the second sentence seems to be completely 
> out of context.

Rewrote this section (originally added following discussion of issue 
47). Second sentence has been removed.

> 12.2  URL handling [...]

Rewrote most of this section, incorporating some of your proposed text, 
and paying attention to RFC3986 language -- please review.

> 12.3  Handling redirected child resources [...]  Sounds like "We don't 
> care what servers do".

After some discussion, we now care and have rewritten the last sentence.

> 19.7  Risks Connected with Lock Tokens [...]

Proposed text inserted with a couple of tweaks (title of RFC, version / 
variant language, and minor wordsmithing introducing the list).

> 22.1 Normative References [...]

Reference to 2518 moved to informative references.

Cheers,
Elias

---

From: Julian Reschke <[email-masked]>
Date: Sat, 10 Dec 2005 16:03:16 +0100

>> Inconsistent typography (":" vs "-")

Thanks.

>> I'm not sure what this is supposed to mean. Please remove it or clarify.

Thanks.

> Discussion needed; created new bugzilla issue.

Done: <http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=205>

> Renamed; brief explanatory note added.

It would be nice if it also could be moved back to where it was in 
RFC2518 in order to avoid needless diffs.

> explanatory text added to section 14.

a) the date doesn't use rfc1123 syntax

b) I object to that change, LWS is not part of the value of the header, 
that is whitespace is not allowed here (any evidence of a server adding 
this???). Do I need to open an issue for that?

>> - intra-doc reference to Section 13 is incorrect

Thanks.

> 2nd sentence left in, with MUST removed.

Thanks.

> 2518 (see similar comment below).

Well, it was mentioned, but the spec never contained a requirement for 
servers to reject this.

> Rewrote text to clarify 204 and 201.

Thanks.

> resource identity (e.g. creation date may change, corruption of version 

I don't buy that rational, because that would just mean that the server 
did what the client told him to do. In particular, the version history 
would not be corrupted nor removed (see RFC3253 COPY semantics).

> 47). Second sentence has been removed.

It now says:

    HTTP defines the Location header to indicate a preferred URL for the
    resource that was addressed in the Request-URI (e.g. in response to
    successful PUT requests or in redirect responses).  However, use of
    this header creates ambiguity when there are URLs in the body of the
    response, as with Multi-Status.  Thus, use of the Location header
    with the Multi-Status response is intentionally undefined.

I still don't understand this. How does the presence of a Location 
header create an ambiguity here? The URLs in the response mean exactly 
what this spec defines them to mean, and there is absolutely no 
ambiguity here.

I'd also like to point out that we've been wasting an incredible amount 
of time undoing a change that was meant to talk about the 
"Content-Location" header, not "Location". As far as I can tell, nobody 
has asked questions about "Location" until I asked why it was put in 
without prior discussion, and I fail to see how this addition makes this 
a better spec. Please remove it.

> and paying attention to RFC3986 language -- please review.

Now says:

12.2  URL Handling

    A Multi-Status body contains one or more 'response' elements.  Each

Zero or more.

    response element describes a resource, and has an 'href' element
    identifying the resource.  The 'href' element MUST contain an
    absolute URI or relative reference.  It MUST NOT include "." or ".."
    as path elements.

It would be helpful if this would refer to the sections of RFC3986 
defining this terms. In particular, I fail to see why we are now 
restricted to "absolute-URI" instead of "URI". Also note that 
"URI-reference" means "URI / relative-ref", so we could use just that.

    If a 'href' element contains a relative reference, it MUST be
    resolved against the Request-URI.  A relative reference MUST be an
    absolute path (note that clients are not known to support relative
    paths).

Again, a reference to the right places in RFC3986 grammar seems to be 
useful.

    Identifiers for collections appearing in the results SHOULD end in a
    '/' character.

    If a server allows resource names to include characters that aren't
    legal in HTTP URL paths, these characters must be percent-encoded on

Why restrict to HTTP URL?

    the wire (see [RFC3986], section 2.1).  For example, it is illegal to
    use a space character or double-quote in a URI.  URIs appearing in
    PROPFIND or PROPPATCH XML bodies (or other XML marshalling defined in
    this specification) are still subject to all URI rules, including
    forbidden characters.

The last sentence doesn't seem to be useful; what we're saying here 
applies to all uses of multistatus bodies, including error responses, or 
extensions (REPORT...).

> After some discussion, we now care and have rewritten the last sentence.

Great. It now says:

    Redirect responses (300-303, 305 and 307) defined in HTTP 1.1
    normally take a Location header to indicate the new URI for the
    single resource redirected from the Request-URI.  Multi-Status
    responses contain many resource addresses, but the original
    definition in RFC2518 did not have any place for the server to
    provide the new URI for redirected resources.  This specification
    does define a 'location' element for this information (see
    Section 13.9).  Servers MUST use this new element with redirect
    responses in Multi-Status.

I think the last two sentences belong into the Changes appendix, not here.

> variant language, and minor wordsmithing introducing the list).

Still :-)

1) Says "Variant x UUID" when it should say "Version x UUID"

2) Misses the statement "Since a WebDAV server will issue many locks 
over its lifetime, the implication is that it may also be publicly 
exposing its IEEE 802 address.". Why?

> Reference to 2518 moved to informative references.

Thanks. I just noted that the XML Infoset reference appears under 
"informative", but that is indeed normative. But we're still discussing 
the "property value" proposal, based on what's in BugZilla 
(<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=10>), right?

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Mon, 12 Dec 2005 11:15:55 -0800

> RFC2518 in order to avoid needless diffs.

Seems like a minor issue, so we left the example in its current  
location.

>> Fixed the example. However, since DAV:get* properties are based  
>> upon definitions made in rfc2616, LWS may be found in some  
>> implementations -- explanatory text added to section 14.
>

Um, my understanding is that we haven't decided to change the format  
of DAV:getlastmodified, which still uses rfc1123 date format.

That said, I do have a preference for the RFC 2518 style of  
representing the value of properties by explicitly referencing the  
same production in RFC 2616 that the actual header uses.

> b) I object to that change, LWS is not part of the value of the  
> header, that is whitespace is not allowed here (any evidence of a  
> server adding this???). Do I need to open an issue for that?

Well, the issue here is what to do concerning these statements in RFC  
2616, section 4.2:

    The field value MAY be preceded by any amount of LWS, though a  
single SP is preferred.

    field-value    = *( field-content | LWS )

So, if you view the contents of a header as anything to the right of  
the colon, then the LWS is part of the value, and we need to state  
something about it.

Another position we could take is to state that the property values  
only include the field-content:

  field-content  = <the OCTETs making up the field-value
                         and consisting of either *TEXT or combinations
                         of token, separators, and quoted-string>

This is a stronger statement. However, it seemed to me that some  
server, somewhere, is bound to accidentally put in some LWS either  
before or after the field-content. As a result, the more  
interoperable approach was to put in the text stating that LWS might  
appear, and to be prepared to handle it. That said, the use of the  
word "value" in:

For properties defined based on HTTP GET response headers (DAV:get*),
     the value could include LWS as defined in <xref target="RFC2616"/ 
 >, section 4.2.

Is ambiguous. A better approach would be to say:

For properties defined based on HTTP GET response headers (DAV:get*),  
the value of the property is intended to be the field-content (as  
defined in Section 4.2 of RFC2616) of the corresponding header.  
However, RFC 2616 does permit the protocol octet stream prior to the  
field-content to contain by LWS, and after the field-content to have  
LWS. As a result, server implementations SHOULD use just the field- 
content, and clients MUST be prepared to strip LWS.

>>> 8.9.5  Status Codes [...] 403 (Forbidden) [...] Confusing.  
>>> Servers may treat this as a nop, just returning 200. Just be  
>>> silent about it.
>> Discussed this but left the text in, as the semantics were defined  
>> in 2518 (see similar comment below).
>
> Well, it was mentioned, but the spec never contained a requirement  
> for servers to reject this.

I'm not following your reply. What is "this"?

>
>>>    403 (Forbidden) [...] And being source and destination  
>>> identical would be a problem exactly why?
>> resource identity (e.g. creation date may change, corruption of  
>> version history, etc.).
>
> I don't buy that rational, because that would just mean that the  
> server did what the client told him to do. In particular, the  
> version history would not be corrupted nor removed (see RFC3253  
> COPY semantics).

This is just mirroring the semantics found in RFC 2518. Seems like  
we'd need to do an interop check on this condition before making any  
changes here.

>
>>> 12.1  Response headers [...] This section doesn't provide any  
>>> useful information. In particular, the second sentence seems to  
>>> be completely out of context.
>> Rewrote this section (originally added following discussion of  
>> issue 47). Second sentence has been removed.
>
> It now says:
>
> header create an ambiguity here? The URLs in the response mean  
> exactly what this spec defines them to mean, and there is  
> absolutely no ambiguity here.

As we have discussed in prior teleconferences, the potential  
ambiguity comes from this: When there is just the Request-URI, there  
is only ever one resource being discussed in the request or response.  
With the multistatus response, there are potentially may resources  
being discussed in the response.

>
> I'd also like to point out that we've been wasting an incredible  
> amount of time undoing a change that was meant to talk about the  
> "Content-Location" header, not "Location".

Agreed, although I'll note that you're the one raising concerns about  
LWS handling in properties :-) *ducks*

Let's discuss this briefly in the next telecon. If there is no  
consensus there, I recommend asking Cullen to declare consensus. I  
agree we should close this and move on.

>
>>> 12.2  URL handling [...]
>> Rewrote most of this section, incorporating some of your proposed  
>> text, and paying attention to RFC3986 language -- please review.
>
> Now says:
>
> 12.2  URL Handling
>
> restricted to "absolute-URI" instead of "URI".

OK, adding section references to RFC 3986 seems like a good idea to me.

It seemed to be that using absolute URI (section 4.3) captured the  
intent of the WG. That is, we either want a fully qualified URL (i.e,  
not a relative URL) or we want a relative reference without ""." or  
"..".

As far as I can tell, the only difference between URI (section 3):

       URI         = scheme ":" hier-part [ "?" query ] [ "#" fragment ]

  and absolute-URI (section 4.3):

    absolute-URI  = scheme ":" hier-part [ "?" query ]

Is the optional ["#" fragment] part. While I don't see an immediate  
use case for including the fragment, I also don't see a compelling  
reason to forbid it, so I'm fine with using "URI" instead of  
"absolute-URI".

> Also note that "URI-reference" means "URI / relative-ref", so we  
> could use just that.

Ah, good find. I agree that we should use this instead.

> Again, a reference to the right places in RFC3986 grammar seems to  
> be useful.

OK.

> Why restrict to HTTP URL?

Agreed -- this is too restrictive. The percent encoding rules apply  
to all URIs.

> applies to all uses of multistatus bodies, including error  
> responses, or extensions (REPORT...).

I disagree. We're making it clear that, just because a URI appears in  
XML, doesn't mean existing rules don't apply to it.

>> Proposed text inserted with a couple of tweaks (title of RFC,  
>> version / variant language, and minor wordsmithing introducing the  
>> list).
>
> Still :-)
>

Ah. I misread the specification when we were editing last Friday. I  
agree it should be changed back to Version.

>
> 2) Misses the statement "Since a WebDAV server will issue many  
> locks over its lifetime, the implication is that it may also be  
> publicly exposing its IEEE 802 address.". Why?

I don't recall. I'm fine with putting this back in.

> "informative", but that is indeed normative. But we're still  
> discussing the "property value" proposal, based on what's in  
> BugZilla (<http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi? 
> id=10>), right?

I think so -- 10 is still open, I believe.

I'm fine with moving XML Infoset into the normative category.

- Jim

---

From: Julian Reschke <[email-masked]>
Date: Mon, 12 Dec 2005 21:55:59 +0100

Jim Whitehead wrote:

>>> definitions made in rfc2616, LWS may be found in some implementations 
>>> -- explanatory text added to section 14.
>>
> Um, my understanding is that we haven't decided to change the format of 
> DAV:getlastmodified, which still uses rfc1123 date format.

Yes, but the example doesn't use it.

> That said, I do have a preference for the RFC 2518 style of representing 
> the value of properties by explicitly referencing the same production in 
> RFC 2616 that the actual header uses.

Of course.

>    The field value MAY be preceded by any amount of LWS, though a single 
> SP is preferred.
> 
> So, if you view the contents of a header as anything to the right of the 
> colon, then the LWS is part of the value, and we need to state something 
> about it.
> 
> Another position we could take is to state that the property values only 
> include the field-content:
> 
> This is a stronger statement. However, it seemed to me that some server, 
> somewhere, is bound to accidentally put in some LWS either before or 
> after the field-content. As a result, the more interoperable approach 
> was to put in the text stating that LWS might appear, and to be prepared 
> to handle it. That said, the use of the word "value" in:
> 
>     the value could include LWS as defined in <xref target="RFC2616"/>, 
> section 4.2.
> 
> defined in Section 4.2 of RFC2616) of the corresponding header. However, 
> RFC 2616 does permit the protocol octet stream prior to the 
> LWS. As a result, server implementations SHOULD use just the 
> field-content, and clients MUST be prepared to strip LWS.

Do we have evidence of servers putting in LWS, and clients ignoring it? 
Otherwise I'd prefer to stick with the most simple approach (forbidding 
the LWS).

>>>> 8.9.5  Status Codes [...] 403 (Forbidden) [...] Confusing. Servers 
>>>> may treat this as a nop, just returning 200. Just be silent about it.

This = rejecting MOVE / COPY requests where source and destination are 
the same.

>> server did what the client told him to do. In particular, the version 
>> history would not be corrupted nor removed (see RFC3253 COPY semantics).
> 
> This is just mirroring the semantics found in RFC 2518. Seems like we'd 
> need to do an interop check on this condition before making any changes 
> here.

As far as I can tell, there's no interoperability to worry about. A 
server just must make sure that kind of request does not unintentionally 
destroy the resource (which could happen with a naive implementation 
that DELETEs the destination first). Telling servers what to do exactly 
is micro-managing the issue. If people are concerned about this problem, 
just warn implementors that requests like that may occur, and that the 
server must be prepared for them.

>>>> information. In particular, the second sentence seems to be 
>>>> completely out of context.
> As we have discussed in prior teleconferences, the potential ambiguity 
> comes from this: When there is just the Request-URI, there is only ever 
> one resource being discussed in the request or response. With the 
> multistatus response, there are potentially may resources being 
> discussed in the response.

HTTP says 
(<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.30>):

"The Location response-header field is used to redirect the recipient to 
a location other than the Request-URI for completion of the request or 
identification of a new resource. For 201 (Created) responses, the 
Location is that of the new resource which was created by the request. 
For 3xx responses, the location SHOULD indicate the server's preferred 
URI for automatic redirection to the resource."

I'm not sure how anybody could come to the assumption that things are 
different in case of a multistatus.

> LWS handling in properties :-) *ducks*

Ahem. I did raise a concern because of a *change* in the spec that I 
think isn't required, and makes life harder for clients. Again, for 
these types of changes it would be really good to understand what 
problem we're actually trying to fix.

> Let's discuss this briefly in the next telecon. If there is no consensus 
> there, I recommend asking Cullen to declare consensus. I agree we should 
> close this and move on.

Fine with me.

>> applies to all uses of multistatus bodies, including error responses, 
>> or extensions (REPORT...).
> 

I'm not against making that cleat (thus the example in the text proposed 
by me in 
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-rfc2518bis-latest.html#rfc.section.12.1.1>), 
I just find the current wording confusing. The rule applies to *any* 
method (not only PROPFIND or PROPPATCH), and to all kinds of XML (not 
only multistatus).

Best regards, Julian

---

From: Jim Whitehead <[email-masked]>
Date: Wed, 14 Dec 2005 09:37:26 -0800

Julian and I discussed the remaining issues during the 12/14/2005  
teleconference. Resolution marked below.

On Dec 12, 2005, at 12:55 PM, Julian Reschke wrote:

>> Um, my understanding is that we haven't decided to change the  
>> format of DAV:getlastmodified, which still uses rfc1123 date format.
>

Agreed. The example in Section "Example - Using 'allprop'", in the  
propfind response, has a getlastmodified header returned. This header  
does not use the rfc1123 date format. I agree this should be modified  
to use the correct date format.

>> Well, the issue here is what to do concerning these statements in  
>> RFC 2616, section 4.2:
>> So, if you view the contents of a header as anything to the right  
>> of the colon, then the LWS is part of the value, and we need to  
>> state something about it.
>> Another position we could take is to state that the property  
>> values only include the field-content:
>> interoperable approach was to put in the text stating that LWS  
>> might appear, and to be prepared to handle it. That said, the use  
>> of the word "value" in:
>>     the value could include LWS as defined in <xref  
>> target="RFC2616"/>, section 4.2.
>> For properties defined based on HTTP GET response headers  
>> (DAV:get*), the value of the property is intended to be the field- 
>> content (as defined in Section 4.2 of RFC2616) of the  
>> corresponding header. However, RFC 2616 does permit the protocol  
>> octet stream prior to the field-content to contain by LWS, and  
>> after the field-content to have LWS. As a result, server  
>> implementations SHOULD use just the field-content, and clients  
>> MUST be prepared to strip LWS.
>
> Do we have evidence of servers putting in LWS, and clients ignoring  
> it? Otherwise I'd prefer to stick with the most simple approach  
> (forbidding the LWS).

Julian and I agreed to include language along the lines of servers  
SHOULD just use the field-content as the value of the property, and  
SHOULD NOT put LWS before or after the field-content as the value of  
the property. We decided that no statement about client behavior was  
needed (they'll strip the LWS if they ever see it anyway).

>>>> Discussed this but left the text in, as the semantics were  
>>>> defined in 2518 (see similar comment below).
>>>
>>> Well, it was mentioned, but the spec never contained a  
>>> requirement for servers to reject this.
> This = rejecting MOVE / COPY requests where source and destination  
> are the same.

Julian and I agreed to change the language from RECOMMENDED use of  
403 to "MAY occur"  (MOVE - section 8.10.4). The section for COPY  
appears to be fine.

>>> I still don't understand this. How does the presence of a  
>>> Location header create an ambiguity here? The URLs in the  
>>> response mean exactly what this spec defines them to mean, and  
>>> there is absolutely no ambiguity here.
>> ambiguity comes from this: When there is just the Request-URI,  
>> there is only ever one resource being discussed in the request or  
>> response. With the multistatus response, there are potentially may  
>> resources being discussed in the response.
>
> HTTP says (<http://greenbytes.de/tech/webdav/ 
> rfc2616.html#rfc.section.14.30>):
>
> "The Location response-header field is used to redirect the  
> recipient to a location other than the Request-URI for completion  
> of the request or identification of a new resource. For 201  
> (Created) responses, the Location is that of the new resource which  
> was created by the request. For 3xx responses, the location SHOULD  
> indicate the server's preferred URI for automatic redirection to  
> the resource."
>
> I'm not sure how anybody could come to the assumption that things  
> are different in case of a multistatus.
>

Julian and I agreed to keep the draft as-is on this issue. We agreed  
that there was a misunderstanding about the original issue (Content- 
Location vs Location), but that this confusion did lead us to make a  
clarification that at least Jim thought was a good idea.

>>> The last sentence doesn't seem to be useful; what we're saying  
>>> here applies to all uses of multistatus bodies, including error  
>> I disagree. We're making it clear that, just because a URI appears  
>> in XML, doesn't mean existing rules don't apply to it.
>
> I'm not against making that cleat (thus the example in the text  
> proposed by me in <http://greenbytes.de/tech/webdav/draft-reschke- 
> webdav-rfc2518bis-latest.html#rfc.section.12.1.1>), I just find the  
> current wording confusing. The rule applies to *any* method (not  
> only PROPFIND or PROPPATCH), and to all kinds of XML (not only  
> multistatus).

The text in section (12.2 - "URL Handling")

URIs appearing in PROPFIND or PROPPATCH
    XML bodies (or other XML marshalling defined in this specification)
    are still subject to all URI rules, including forbidden characters.

Change to:

URIs appearing in all XML elements are still subject to all URI  
rules, including forbidding characters (this applies to PROPFIND and  
PROPPATCH, among many methods).

Agreed that we should include the example from Julian's draft in  
section 12.1.1, which clearly shows these rules in action.

- Jim