Re: New draft of RFC2518bis

OK.

I just went through my existing issues list, and reviewed the diffs to 
the previous drafts:

- none of the issues that I have reported for draft 06 (and earlier 
drafts) have been addressed (I have updated BugZilla accordingly)

- draft 07 contains lots of changes that do not seem to be related to 
any open issue, nor have been discussed over here

If we want to make RFC2518bis a success, changing the spec without 
notice and prior discussion really should be avoided.

That being said, here are the new issues that I found (most but not all 
related to changes between 06 and 07). As soon as we agree on a single 
issue tracking, I'll resubmit them in whatever format needed.

Best regards,

Julian

--

07-E01, Section 8.11
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=87

Broken XML source (invalid list style)

Draft:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.11>


07-E02, Section 8.11.5
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=88

Typo:

"h 400 (Bad Request), with 'request-uri-must-match-lock-token' 
precondition - The LOCK request was made with a Lock-Token header, 
indicating that the client wishes to refresh the given lock. However, 
the Request-URI did not fall within the scope of the lock identified by 
the token. The lock may have a scope that does not include the 
Request-URI, or the lock could have disappeared, or the token may be 
invalid."

Draft:
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.11.5>


07-E04, hyphenated words
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=89

There seem to be places in the XML source where whitespace was 
introduced inside hyphenated terms, such as in "Coded- URLs".


07-E05, RFC2277 ref is broken
http://ietf.cse.ucsc.edu:8080/bugzilla/show_bug.cgi?id=90

Broken reference to RFC2277 
(<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.18>)

"<xref target="RFC2616">RFC2277</xref>".


07-E06, lock tokens in examples

8.11.6:

"Note that the locktoken and lockroot href elements would not contain 
any whitespace. The line return appearing in this document is only for 
formatting."

I'd prefer to have the XML examples be valid. Such as:

         <D:locktoken>
           <D:href
 >opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4</D:href>
         </D:locktoken>

Draft: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.11.6>


07-E07, 8.7 DELETE vs LOCKs

The first sentence of the description of DELETE now says:

"Locks rooted on a resource MUST be destroyed in a successful DELETE of 
that resource."

This is correct, but it's certainly not the right way to start the 
description of DELETE.

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.7>


07-E08, 8.9 COPY

Newly states:

"The state of the resource to be copied is fixed at	the point the server 
begins processing the COPY request."

Why this change, and what problem does it solve?

Draft: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.9>


07-E09, 8.9.3 COPY for Collection Resources

Now says:

"A COPY of depth infinity instructs that the collection resource 
identified by the Request-URI is to be copied to the location identified 
by the URI in the Destination header, and all its internal member 
resources are to be copied to a location relative to it, recursively 
through all levels of the collection hierarchy. Servers should of course 
avoid infinite recursion, and can do so by copying the source resource 
as it existed at the point where processing started."

The last sentence was added. I'm not sure why. Of course servers never 
should run in an infinite loop, but that applies to all Depth-related 
operations. I'm not sure why it's stated here, and furthermore I don't 
understand what the suggested workaround is.

Draft: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.9.3.p.2>


07-E10, 8.9.4, COPY and the Overwrite Header

	 	 Interoperability testing has shown that some clients expect a	
			collection COPY to actually do a merge if a destination collection	
			exists. That behavior is appropriate for file system folders but not	
			necessarily for other data objects modelled as collections. Thus,	
			implementors are urged to comply with the standard language above,	
			and leave clients to perform a manual merge if that's the expected	
			behavior when copying a collection over another collection.

May be a useful remark, but I think it should either clearly marked as a 
comment, or moved into an appendix (away from normative text)

Draft: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.8.9.4>


07-E11, 10.1 102 Processing

I note that în draft 05, the "status-uri" response header was removed 
(see <http://greenbytes.de/tech/webdav/rfc2518.html#rfc.section.9.7>), 
but the "102 Processing" status was left in.

Either we have implementations and interoperability - then we need both 
- or we should remove both.

Draft: 
<http://greenbytes.de/tech/webdav/draft-ietf-webdav-rfc2518bis-07.html#rfc.section.10.1>

Received on Monday, 3 October 2005 15:33:32 UTC