Subject: RE: rfc2518-bis-04 issues (part 2)

From: Jason Crawford <[email-masked]>
Date: Wed, 30 Jul 2003 12:35:40 -0400

On Wednesday, 07/30/2003 at 03:42 ZE2, "Julian Reschke" 
<[email-masked]> wrote:
> Hi.
> 
> Below is a list of issues I raised against draft 02 which IMHO have not 
been
> adequately addressed in the latest draft (see [1] for the original 
message).
> 
> 
> 02-C05 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).

I'd vote to leave the text as it is.

> C02-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.
Perhaps I misunderstand the existing text, but I also suspect the 
"unless it overwrites..." part is wrong.  If you do a MOVE and it's
actually a different resource in that slot, I think you do need the parent
collection's lock token.  It's only a PUT that doesn't require it.

> C02-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 don't know if we discussed it or not, but the wording that is there 
seems
fine.  I do lack any compelling test cases to drive this issue in a 
particular
direction though.  I will rhetorically ask what non-WebDAV browsers do 
with ETags and lastmoddate.

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 30 Jul 2003 20:23:21 +0200

> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Jason Crawford
> Sent: Wednesday, July 30, 2003 6:36 PM
> To: Julian Reschke
> Cc: [email-masked]
> Subject: RE: rfc2518-bis-04 issues (part 2)
>
> ...
>
> > 02-C05 Section 6.3, p3
> >
> > Replace
> >
the
as
> I'd vote to leave the text as it is.

Again, please help me understand...:

1) Are you suggesting that to for a scheme to be IETF-registered is not a
requirement? In which case I'll argue that by definition there can't be any
uniquess guarantee otherwise.

2) Are you suggesting that this is obvious? I which case I'll have to point
out that there are well-known server implementations doing just that, so
obviously the spec  hasn't been clear enough about that.

> > "This means that if a collection is locked, its lock-token is
> required in
> > all these cases:

Correct.

change,
overwrite
you
seems
particular
> with ETags and lastmoddate.

It's a procedural question. I think *any* change to RFC2518 (and this is a
change) should appear on the issues list, indicating when and why it was
raised as an issue, and what conclusion was reached. As far as I know, this
hasn't happened.

Julian

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

---

From: "Julian Reschke" <[email-masked]>
Date: Wed, 30 Jul 2003 23:05:37 +0200

Here's a set of new issues (that is, issues I didn't raise earlier, they may
have been present for longer or even in RFC2518):

04-C01 attributes on properties

Section 4.5: "Attributes on the property name element may convey information
about the property, but are not considered part of the value."

As far as I can tell, we haven't reached consensus on this. The latest
discussion I'm aware of is at
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0309.html>.

04-C02 lock discovery and tokens

Section 6.3: "Finally, the lockdiscovery property can be queried using
PROPFIND and the token can be discovered that way. Each lock has only one
unique lock token."

- the token can only be discovered this way if there aren't multiple tokens
(due to shared locks)
- clarify "has only one" by "has exactly one"

04-C03 opaquelocktoken syntax

Section 6.4, last p.:

"Extension = path  ; path is defined in section 3.2.1 of [RFC2616]"

...should say "3.3 of RFC2396"

04-C04 sect 6.5, access control

I find the mixing of lock capabilities and access control capabilities
confusing. Maybe we should remove or rewrite this in the light of the ACL
spec.

04-C05 sect 7.4, p2

"The lost-update problem is not an issue for collections because MKCOL can
only be used to create a collection, not to overwrite an existing
collection.  In order to immediately lock a collection upon creation,
clients may attempt to pipeline the MKCOL and LOCK requests together."

There's no guarantee that this will be atomically, thus in the best case, it
just makes a race condition less likely. As you can't rely on this to always
succeed, I'd recommend not to say anything at all.

04-C06 sect 7.4, p3

"A lock request to an unmapped URL should result in the creation of a
resource that is locked.  A subsequent PUT request with the correct lock
token should normally succeed, and provides the content, content-type,
content-language and other information as appropriate."

If this is supposed to be normative text, it should use "SHOULD" instead of
"should" (same problem with many places where text was added). Besides, what
is "should normally succeed" supposed to mean?

04-C07 sect 7.4, p4

"Historically, a lock-null resource: ...
   -  Disappears (becomes once more an unmapped URL) if its lock goes
     away before it is converted to a regular resource.  (This must..."

The lock-null resource becomes unmapped, it doesn't become an unmapped URL.

04-C08, sect 8.1.1

"illformed" isn't defined in REC-XML. Propose to use "non-wellformed".

04-C09, sect 8.1.3

...speaks of "consistent" usage of addresses without precisely defining what
that means.

04-C10, sect 8.1.5

"HTTP 1.1 suggests the use of the ETag header in responses to GET and PUT
requests"

Make this more precise (maybe "recommends"?). Also directly reference the
section in RFC2616.

04-C11, sect 8.1.5 p 2

This requirement will make both IIS and Apache/moddav non-compliant. Before
I can agree to this, I'd like *at least* see the Apache/moddav developers
committing to this change.

04-C11, sect 8.1.5 p 3

This will make IIS non-compliant.

04-C12, sect 8.2 p 2

'A client may submit a Depth header with a value of "0", "1", or "infinity"
with a PROPFIND on a collection resource with internal member URLs.'

Remove "with internal member URLs". It's irrelevant whether the collection
has members.

04-C13, sect 8.2

"Clients expect the fully-qualified URLs of members of a collection to have
a common prefix which is the fully-qualified URL of the parent collection
itself."

If this is meant to define a normative requirement on server behaviour, it
should be worded accordingly.

"URLs in a PROPFIND response body MAY be represented as fully-qualified
URLs, in which case they must all contain the full parent collection URL
(scheme, host, port, and absolute path).   Alternatively, these URLs MAY be
absolute paths (not containing scheme, host or port), but in this case they
must all still contain the full parent collection path."

I'd strongly suggest to remove all of this and to clearly state using the
RFC2396 productions what is allowed.

"URIs appearing in PROPFIND or PROPPATCH XML bodies (or other XML
marshalling defined in this specification) must also be legal URIs."

This somehow suggests that there's something like an "illegal" URI. Either a
text string conforms to the RFC2396 requirements (then it is a URI) or it
doesn't (then it's not a URI at all). Recommend to drop this paragraph, but
do add normative language somewhere else (for instance, when defining legal
contents for DAV:href).

"In the case of allprop and propname, if a principal does not have the right
to know whether a particular property exists then the property should be
silently excluded from the response."

s/should/MAY/

04-C14, sect 8.4

"For example, if a request to create collection /a/b/c/d/ is made, and
either /a/b/ nor /a/b/c/ exists, the request must fail."

I think it must fail if and only if /a/b/c/ does not exist. It's irrelevant
whether /a/b/ exists.

04-C15, sect 8.4 status codes

"The collection or structured resource was created in its entirety."

What is a "structured resource" and where was it defined?

"405 (Method Not Allowed) - MKCOL can only be executed on a
deleted/non-existent resource."

HTTP methods are applied to URLs, not resources. Say "can only be executed
on an unmapped URL"

04-C16, sect 8.7

"Thus, after a successful DELETE operation (and in the absence of other
actions) a subsequent GET/HEAD/PROPFIND request to the target Request-URI
would return 404 (Not Found)".

s/would/MUST/

04-C17, sect 8.9, Copy for properties

"If a property cannot be  copied live, then its value MUST be duplicated,
octet-for-octet, in an identically named, dead property on the destination
resource."

No! That would be a desaster. Make this "SHOULD NOT". Otherwise clients will
see the dead property (such as DAV:checked-in) and make wrong assumptions
about the resource.

04-C18, sect 8.9.3

"Either the source context does not support copying to the destination
context, or the destination context refuses to accept the resource."

If we use the term "context", we'oll have to define it somewhere.

04-C19, sect 8.10

"If a resource exists at the destination, the destination resource will be
DELETEd as a side-effect of the MOVE operation, subject to the restrictions
of the Overwrite header."

s/DELETEd/deleted/

04-C20, sect 8.10.1

"Live properties described in this document MUST be moved along with
   the resource, such that the resource has identically behaving live
   properties at the destination resource, but not necessarily with the
   same values.  If the live properties will not work the same way at
   the destination, the server MUST fail the request (the client can
   perform COPY then DELETE if it wants a MOVE to work that badly).
   This can mean that the server removes a live property if that's the
   most appropriate behavior for that live property at the destination."

The second sentence implies that the MOVE must fail if the live properties
can't be moved as well, while the last sentence says that the server may
remove the live properties.

"A MOVE can be a rename operation, so it's not appropriate to reset
   live properties which are set at resource creation. For example, the
   creationdate property value SHOULD remain the same."

So can a MOVE be something else then a rename operation? If yes, how does
the second sentence then applies? If it doesn't apply always, and the client
won't know, why are we mentioning it?

04-C21, sect 8.11, refreshing LOCKs

"A lock is refreshed by sending a new LOCK request to the resource which is
the root of the lock.  A LOCK request to refresh a lock must specify which
lock to refresh by using the Lock-Token header with a single lock token
(only one lock may be refreshed at a time).  This  request does not contain
a body, but it may contain a Timeout header.  A server MAY accept the
Timeout header to change the  duration remaining on the lock to the new
value."

Replace by

"A lock is refreshed by applying a LOCK request to the URL which is the root
of the lock. This request must specify which lock to refresh by using the
Lock-Token header with a single lock token (only one lock may be refreshed
at a time) and does not contain a body, but it may contain a Timeout header.
A server MAY accept the Timeout header to change the  duration remaining on
the lock to the new value."

04-C22, sect 8.11.1

Fix the XML response by replacing

           <D:href>http://example.com/workspace/webdav
              /proposal.doc</D:href>

by something like

           <D:href
           >http://example.com/workspace/webdav/proposal.doc<
           /D:href>

04-C23, section 9.8

Do we have interoperability for status "102" and the Status-URI header? I
don't think so, so I'd recommend to remove them from the spec.

04-C24, section 11

I think this section doesn't really help. It doesn't seem to say anything
normative, so I'd recommend to drop it, and to improve the sections for the
individual methods.

04-C25, section 12

"When a Multi-Status response does not have a clear scope (e.g. in response
to MOVE or COPY when the scope could be either the source or the
destination), URLs appearing in the response body SHOULD be absolute and
fully-qualified URLs."

Either define "clear scope", or (preferably) improve RFC2518 that there is
no situation where the scope is not "clear".

04-C26, section 13, "lockroot"

"Purpose: The resource where the lock is orootedo, which is the resource
that was addressed in the LOCK request."

This is not purpose. Say

"Purpose: contains the root of the lock, i.e. the URL to which the LOCK
request was applied."

04-C27, section 13, "deadprops"

During the January meeting we agreed upon "dead-props". We already implement
that. Why change it?

04-C28, section 14, displayname

"It MAY be attempted to be set in remote COPY operation."

I'd say: it MUST NOT.

"This property is live and MAY be protected."

What's the use case for it being protected?

04-C29, section 14

Uses the term "remote COPY operation" and "cross-server copy". I think we
need to define what this means.

04-C30, section 14.5

"In a remote COPY operation that is implemented through a GET request, the
GET request must have the appropriate Content-Type header."

I honestly don't understand what this means.

04-C31, section 14.6

"It MUST NOT be set in PROPPATCH during a cross-server copy."

It seems that we assume here that the reader is aware of implementations
that implement cross-sever copies using GET/PROPFIND/PUT/PROPPATCH. If we
want to keep this, we need to expand this (probably in the section about
COPY). Alternatively drop it.

"Refer to RFC2616 for a complete definition of the semantics of an ETag."

Just say: "(see RFC2616, section a.b.c)"

04-C32, section 17

"It is only in the case where the set of properties is not known ahead of
time that an application need display a property name URI to a user"

There is no such thing as a "property name URI", unless we define it.

04-E01 non-ASCII characters

There are many instances of non-ASCII characters in the document, probably
caused by a missing conversion step.

04-E02 usage of sample host names not according to IETF recommendations

For instance:

04-E03 undefined reference

in last paragraph on page 6

04-E04 Numbering of appendices

Each appendix should have it's own section number.
draft-rfc-editor-rfc2223bis-06.txt seems to recommand uppercase letters
(such as "Appendix A").

04-E05 wrong reference

Page 7, 2nd paragraph refers to 13.28, I think this needs to be 14.

04-E06 Terminology

URI/URL: note we should be prepared to update to RFC2396bis when it's ready.

04-E07 usage of property names in surrounding text

I think we should try to use a consistent syntax when referring to DAV:
properties. Currently we have a mix between "foo" and "DAV:foo".

04-E08 section 3: definition of "null resource"

...is gone, yet is still used in later sections.

04-E09 "DAV compliant"

I think we should try to use either "DAV compliant" or "WebDAV compliant"
consistently.

04-E10 sect 7.5, 2nd last para

Closing ")" missing.

04-E11 section 8.1.4

Indentation off.

04-E12 paragraph numbering in sec 9

...is broken. For instance, "Example - No-tag-list If Header" should be a
subsection of "No-tag-list Production".

04-E13 paragraph numbering in sec 13

...is broken. For instance, 13.2 should be a subsection of 13.1

---

From: Elias Sinderson <[email-masked]>
Date: Wed, 30 Jul 2003 21:52:33 -0700

Julian Reschke wrote:

>>><Julian Reschke> 02-C05 Section 6.3, p3
>>>Replace
>>>"However resources are free to return any URI scheme so long as it meets the
>>>      
>>>
>>>"However servers are free to use any IETF-registered URI scheme so long as
>>>      
>>>
>><Jason Crawford> I'd vote to leave the text as it is.
>>    
>>
><Julian Reschke> Again, please help me understand...:
>
<Elias Sinderson> It's a given that any IETF-registered URI scheme will 
meet the stated uniqueness requirements. I don't believe that it is the 
only way to do so, however. For example, private intranets may utilize 
their own, homegrown system to guarantee uniquenes. It's also entirely 
possible that, in the distant future, there may be alternative means to 
accomplish this on the public internet. Perhaps something along the 
lines of the following would be acceptable?

"...are free to use any URI scheme so long as it meets the stated 
uniqueness requirements. One way to accomplish this is to use 
IETF-registered URI schemes."

This language seems specific enough to be unambiguous while flexible 
enough to allow for other mechanisms to ensure uniqueness. The drawback 
of not taking a firmer position on this is that it opens the possibility 
that someone will implement some half-baked idea and it won't meet the 
necessary requirements...

Cheers,
Elias

---

From: "Julian Reschke" <[email-masked]>
Date: Thu, 31 Jul 2003 08:51:12 +0200

> Behalf Of Elias Sinderson
> Sent: Thursday, July 31, 2003 6:53 AM
> To: [email-masked]
> Subject: URI scheme uniqueness (was Re: rfc2518-bis-04 issues (part 2))
>
>
> Julian Reschke wrote:
>
>
the
> <Elias Sinderson> It's a given that any IETF-registered URI  scheme will
meet
> the stated uniqueness requirements. I don't believe that it is  the only
way

That's not a given. For instance, "file:///abc" or "dav:foobar" make very
poor lock tokens, although the URI schemes are IETF-registered.

> to do so, however. For example, private intranets may utilize their own,
> homegrown system to guarantee uniquenes. It's also entirely possible that,

Not true, unless your private intranet indeed isn't (and never will be)
connect to the public internet (in which case I really don't care :-). A
client may talk with two distinct "homegrown" systems at the same time.
RFC2518 requires that it will never ever see the same lock token twice. If
these systems do not use an IETF-registered URI scheme, there's simply no
way to guarantee this.

> in the distant future, there may be alternative means to
> accomplish this on
> the public internet. Perhaps something along the lines of the following
> would be acceptable?
>
> uniqueness
> requirements. One way to accomplish this is to use IETF-registered URI
> schemes."

That's plain and simply wrong. The only way is to use an URI scheme that
*both* is IETF-registered and meets the uniqueness criterium.

> This language seems specific enough to be unambiguous while
> flexible enough
> to allow for other mechanisms to ensure uniqueness. The drawback of not

See, this kind of proves that the spec needs to be enhanced. You and others
seem to read it as a license to come up with "private" URI schemes, which is
plainly wrong and breaks the uniqueness requirements. Therefore the text
should be clarified.

> taking a firmer position on this is that it opens the possibility that
> someone will implement some half-baked idea and it won't meet the
> necessary
> requirements...

Absolutely.

Can you provide an example that wouldn't be "half-baked"? My point being,
unless you register the scheme, nobody is guaranteeing uniqueness, so it is
soft of "half-baked" automatically.

Another question: why are people fighting against this requirement? There
are tons of simply ways to produce lock tokens that meet all the criteria,
one of which is the opaquelocktoken scheme. I really don't see what's so
attractive about inventing new schemes to do the same thing.

Julian