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

From: Jason Crawford <[email-masked]>
Date: Thu, 13 Mar 2003 19:26:14 -0500

> 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,   [email-masked]
I do not check [email-masked]

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 14 Mar 2003 15:15:55 +0100

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jason Crawford
> Sent: Friday, March 14, 2003 1:26 AM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-ietf-webdav-rfc2518bis-03.txt
>
>
> ...
>
> > 5) Section 6.3, p3
> >
> > Replace
> >
the
as
> I'd vote for leaving the old text.

Hmmm.

Do we disagree on

a) the fact that it must be registered, or

b) whether or not it needs to be stated?

For a), my answer is that unless it is registered, it by definition can't
meed the uniqueness requirements.

For b), my answer is that I've seen servers inventing their "ad hoc"
schemes, and this is exactly I want to warn about.

See also:

<http://www.w3.org/TR/webarch/#URI-scheme>:

"While "myscheme:blort" is a URI that satisfies the syntactic constraints of
[RFC2396], if "myscheme" is not registered, you are not guaranteed that
somebody else isn't already using it for something else."

> ...

Regards, Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 14 Mar 2003 15:19:59 +0100

pre-existing
protection.  This
> should say that lock protection is for write locks or just locks.

Maybe this gets resolved by the adoption of GULP. I just wanted to clarify
that a MOVE into a collection A overwriting a member *does* modify the state
of the collection.

> at that URI until the lock is removed via UNLOCK or until an  operation
with the
insures
resource at the
> Feel free to offer a better wording.

I think the way to go is to get agreement on the current or a revised
version of GULP, and use that in a single place within the spec.

Julian

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

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 14 Mar 2003 15:25:38 +0100

reference to
> a single place in the same document is fine with me.

OK,

no matter what we do, there should only be *one* place in the spec
describing it.

The choices that I see are

1) we just define that RFC2396-defined relative URI resolution takes place
(also defining what the base URL is in each case),

2) 1) + descriptive text or

3) something different that is compatible to 1), but disallows some specific
cases.

I'd vote for 1) (because that's what RFC2518 says and I haven't seen any
convincing reason to change it yet).

> ..

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 14 Mar 2003 15:32:51 +0100

sort of thing
> any more, but even to me it seems obvious.

:-) My point was that if there's no description of a source link in the
document, we don't need to discuss it's security risk as well.

Julian

---

From: "Julian Reschke" <[email-masked]>
Date: Fri, 14 Mar 2003 15:21:51 +0100

resource,
> Interesting.  Has this been discussed and resolved?  (It just seems a bit

I think it's odd to require the server to invent a content type if there
actually isn't any content. I don't see how this would help any existing
client.

Julian