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

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

If we go with this wording, could we include a reference to the section
that
defines what "lock discovery" is.   I did a quick search of the 2518bis and
I don't think that's clear.  We don't need to redefine it, but a pointer to
the
definition we're refering to would be good.


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

I'd vote for leaving the old text.


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

I think Lisa pointed it out, but the spec doesn't talk about URI
protection.  This
section is probably a good place to mention it.   Geoff came up with some
wording that I don't have handy now.  He and I disagreed with whether we
should say that lock protection is for write locks or just locks.
Anyway...

The Effect of Locks on URL Mappings
    The resource located at the request-URI of the LOCK request MUST remain
at that URI until the lock is removed via UNLOCK or until an operation with
the
proper lock-token header alters or destroys that mapping.  This contraint
insures
that the principal that locked the resource will be able to find that
resource at the
same location as long as it holds the lock.

Feel free to offer a better wording.



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

Interesting.  Has this been discussed and resolved?  (It just seems a bit
odd.)


> 19) Section 9.3
>
> Language describing the process of relative URI resolution should go.

I actually like it telling me (the reader) this explicitly.

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

I do agree that it should not be described more than once in 2518.  A
reference to
a single place in the same document is fine with me.

>
>
> 24) Section 12.1
>
> Proposal: add an example.

We might as well also say what 303 is just so that folks don't have to
go searching for it.  "302 (Found) and 303 (whatever)..."



> 25) Section 13.4 (lockroot)
>
> Proposal: only require it for deep locks.

I have no preference... unless we have
a reason to want to know what URI mapping
is protected.  If we do, then it should apply
even to depth 0 locks.

FWIW... there is some sort of quotation
marks around "rooted" in that section on that
html page that don't show up
right on my browsers.


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

I guess this is fine, although I think "this document" might be ambiguous.
Perhaps,
"this spec".


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

I support what Lisa has added until we show that saying this is a bad idea.

> 31) Section 18.6, Reduction of Security due to Source Link
>
> can be removed
I tend to think 18.6 isn't necessary.  I'm not heavily in to a lot of this
sort of thing
any more, but even to me it seems obvious.

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

I tend to think the first part of section 19 is no longer necessary.  It's
not quite
accurate and the information isn't really important and it's well known to
anyone
that has had to deal with XML namespaces... which will be everyone reading
this.


------------------------------------------
Phone: 914-784-7569,   ccjason@us.ibm.com
I do not check nn621779@smallcue.com

Received on Thursday, 13 March 2003 19:28:43 UTC