Subject: RE: Ordered collections and versioned collections

From: "Clemm, Geoff" <[email-masked]>
Date: Sun, 6 Apr 2003 15:17:02 -0400

From: Julian Reschke [mailto:[email-masked]]

   > From:  Clemm, Geoff
   >
   >    From: Lisa Dusseault [mailto:[email-masked]]
   >
   >    It seems from draft-ietf-webdav-ordering-protocol-07 that only
   >    version-controlled resources are part of the ordering of
   >    version-controlled collections (Section 9: "for compatibility with
   >    RFC3253, only the ordering of version-controlled members needs to
   >    be maintained")
   >
   >    Does that mean there's no way to order versioned and unversioned
   >    resources together within a version-controlled collection?
   >
   > That is correct.  The issue is that when you UPDATE a
   > version-controlled collection with a new version, it can change the
   > set of version-controlled members, and there would not be a way to
   > define what the ordering of the existing non-version-controlled
   > members should be wrt the new version-controlled members.

   For instance, we can define that the UPDATE operation does not
   define the ordering of those members (that is, the server (a) may
   insert them in arbitrary places or (b) must insert them at the
   end). Currently the postcondition is:

   "(DAV:update-version-controlled-collection-members-ordered): If the
   request modified the DAV:checked-in version of a version-controlled
   collection and the DAV:ordering-type for the checked-in version is
   not unordered ("DAV:unordered"), the version-controlled members
   MUST be ordered according to the checked-in version's
   DAV:version-controlled-binding-set property."

   How about adding:

   "Members that are not version-controlled MUST be moved to the end of the
   ordering (in no particular order)."

   This behaviour would be consistent with section 6.1 (setting the position
   when no ordering information was specified).

That would be fine with me, or just saying that the order of the
non-version-controlled members is server-defined following the UPDATE.

Cheers,
Geoff

---

From: "Lisa Dusseault" <[email-masked]>
Date: Sun, 6 Apr 2003 13:08:34 -0700

Is the position of a newly-defined resource in an ordered collection
treated the same way by all servers?   It would be nice to be specific
about how new resources are added to an ordered collection.

I assume that sub-collections are orderable as well? That is, if I have
an ordered collection containing several sub-collections, I assume I can
define an ordering that includes all sub-collections along with all
other children.  I believe this is already clear through the term
"member" even though none of the examples show a sub-collection.

Other questions
 - If I MOVE a resource within the same collection, must the server
preserve its ordering position wrt other resources?
 - If I COPY a resource within the same collection, where is the new
resource placed in the ordering -- next to the old resource (closely
preserving its ordering semantics), or at the end, or arbitrary?
 - If I MOVE or COPY a resource into a collection, overwriting a
resource that has an ordering position, is that ordering position (of
the destination) preserved?
 - If I DELETE a resource, must the server preserve the ordering other
than that deleted resource?  Section 4 could be more explicit that if
resource C is after B is after A, then the deletion of B means that C
must be after A rather than destroying the ordering relationship.  This
is worth making explicit because server implementors must either
maintain their orderings in a format that is irrelevant to what
resources exist (absolute), or relative orderings must be fixed up when
a resource is deleted.

Note that the answers to the MOVE/COPY questions are particularly
important if WebDAV clients do "Safe-save" operations -- e.g. a client
that PUTs an new resource then uses COPY to overwrite the existing
resource after finding that the PUT worked.  There are many other
variations in safe-save algorithms, some using MOVE.

Lisa

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Clemm, Geoff
> Sent: Sunday, April 06, 2003 12:17 PM
> To: Webdav WG
> Subject: RE: Ordered collections and versioned collections
> 
> 
>

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 7 Apr 2003 14:11:31 +0200

> [mailto:[email-masked]]On Behalf Of Lisa Dusseault
> Sent: Sunday, April 06, 2003 10:09 PM
> To: 'Clemm, Geoff'; 'Webdav WG'
> Subject: More on ordered collections
>
>
>

Yes.

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

> define an ordering that includes all sub-collections along with all

Nope. Ordering is a property of the internal (!) members of a collection, so
it doesn't automatically affect child collections:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#rfc.section.4.p.4>

> preserve its ordering position wrt other resources?

That depends on the Position header:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

> preserving its ordering semantics), or at the end, or arbitrary?

Same:

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-07.htm
l#SECTION.SETTING>

> the destination) preserved?

Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE the
target.

> resources exist (absolute), or relative orderings must be fixed up when

I think this follows from the definition of "ordering" (repeatability of
PROPFIND result element ordering).

> variations in safe-save algorithms, some using MOVE.

Those servers will need to set the Position header accordingly if they want
the resulting resource to be in the "original" position.

Julian

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

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 7 Apr 2003 19:04:57 +0200

> [mailto:[email-masked]]On Behalf Of Clemm, Geoff
> Sent: Sunday, April 06, 2003 9:17 PM
> To: Webdav WG
> ...

Agreed (resolved as "server-defined"):

<http://greenbytes.de/tech/webdav/draft-ietf-webdav-ordering-protocol-latest
.html#rfc.issue.9.4-UPDATE-non-version-controlled-members>

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 7 Apr 2003 10:40:19 -0700

Sorry, I must not have been sufficiently clear in my questions.  I'm
mostly discussing operations without the Position header -- operations
with clients that aren't aware of ordering.

> > about how new resources are added to an ordered collection.

So this meant, how are resources added to a client-ordered collection
when the Position header is missing? Must servers add them to the end of
the ordering or can they be put at the beginning or anywhere?

> it doesn't automatically affect child collections:

Again I was unclear.  I meant direct sub-collections, or collections
which are direct children of the ordered collection. These are ordered
together with regular child resources, correct?  There are no examples
of this but I believe this is what the spec says.

> That depends on the Position header:

What happens if the Position header is not present?  Must servers
preserve the ordering or lose it?

> > preserving its ordering semantics), or at the end, or arbitrary?
 
And here, what happens if the COPY method has no Position header?

> Usually not, as RFC2518 defines an Overwrite to be implicitly DELETE
the

No, I disagree with this.  Overwriting a regular resource does not reset
all the live properties.  For example, it would be pretty disastrous for
the ACL property to be reset every time a resource is overwritten.
Besides, the ordering is a property of the parent, not the resource
being overwritten.  I would expect that ordering would be preserved, but
the spec ought to say one way or another.

> PROPFIND result element ordering).

Then why not make it explicit in the specification?

> the resulting resource to be in the "original" position.

It is not the servers doing "safe save" operation, it's the clients, and
these may be clients that are unaware of ordering or choose not to set
the Position header.

It's important to consider how a server with an ordered collection
interacts with ordinary clients (ones that do not use the Position
header). Otherwise, an author that tries to keep their collection
ordered may frequently find the ordering  unecessarily "messed up" after
resources are added, deleted, renamed, or overwritten by non-ordering
client software (e.g. Office).

Lisa

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 7 Apr 2003 20:16:43 +0200

> Sent: Monday, April 07, 2003 7:40 PM
> To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG'
> Subject: RE: More on ordered collections
>
>
>
> > > treated the same way by all servers?   It would be nice to  > be
specific
> the ordering or can they be put at the beginning or anywhere?

At the end. See:

l#rfc.section.6.1.p.2>

> of this but I believe this is what the spec says.

Sure. Collections are resources. If a collection appears as a direct member
of an ordered collection, it behaves (ordering-wise) just like a plain
resource.

> preserve the ordering or lose it?

It must order it at the end. See above.

> And here, what happens if the COPY method has no Position header?

See above.

> the ACL property to be reset every time a resource is overwritten.

If you do that using a MOVE? I *really strongly* disagree. ACLs are
properties of a resource, not of it's binding/URL. MOVEing a resource MUST
move it's ACL with it, overwriting the target resource's ACLs. Please take
this to the ACL list if you feel this needs to be discussed.

> the spec ought to say one way or another.

It says:

"If the request is replacing an existing resource, the server MUST preserve
the present ordering.
If the request is adding a new internal member URI to the collection, the
server MUST append the new member to the end of the ordering."

So the ordering spec basically delegates the decision to the server
implementor (it depends how overwrite operations are implemented
internally) -- I'm not sure we can be more precise here because it might be
impossible or very expensive to implement in some cases.

> Then why not make it explicit in the specification?

I think it *is* explicit (by definition).

> these may be clients that are unaware of ordering or choose not to set

Correct. This means that these clients will lose the original order
position.

> client software (e.g. Office).

I agree that this is the case, but it's unclear how we can prevent this. A
server usually doesn't have the required context to decide what the intent
of a sequence of operations is.

Note that Office isn't an issue here because it indeed edits
(LOCK/GET/PUT/UNLOCK) a single URL. Also note that a similar problem exists
with RFC3253-style autoversioning. The best way to avoid these issues is to
use a client which behaves properly (by consistently using the same URL).

Julian

---

From: Ted Hardie <[email-masked]>
Date: Mon, 7 Apr 2003 11:37:58 -0700

Process question:  what is the ACL list, and why is conversation
on a decision to be made by the working group moving to it?
If this is a design team, pleae note the IESG's statement
on the work of design teams at:

http://www.ietf.org/IESG/STATEMENTS/Design-Teams.txt

Thanks for filling me in,
					regards,
							Ted Hardie

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 7 Apr 2003 20:47:06 +0200

> [mailto:[email-masked]]On Behalf Of Ted Hardie
> Sent: Monday, April 07, 2003 8:38 PM
> To: Julian Reschke
> Cc: Lisa Dusseault; 'Webdav WG'
> Subject: Re: More on ordered collections
>
>
>

See info at: <http://www.webdav.org/acl/>

> Thanks for filling me in,

I was suggesting to take the question to the ACL mailing list, because it
affects mainly the WebDAV ACL spec, not the ordering spec (which is
discussed here on the "generic" WebDAV mailing list) -- the WebDAV ACL
mailing list simply is a better place to resolve open issues regarding the
behaviour of ACLs upon COPY/MOVE.

Julian

---

From: "Lisa Dusseault" <[email-masked]>
Date: Mon, 7 Apr 2003 11:52:20 -0700

OK, this answers a lot of my questions.

> It must order it at the end. See above.

I think this is the wrong behavior.  A MOVE within a collection is
simply a rename.  A server ought at least to be able to preserve the
ordering if Office/Web Folders does a rename.  Otherwise this
unnecessarily disturbs the author's ordering.  If we don't say "a server
MUST retain the relative position of a member when it is moved within
the same ordered collection without an explicit Position header", then
it should at least be a SHOULD.

> this to the ACL list if you feel this needs to be discussed.

ACL isn't the issue -- it was just an illustration.  

If you COPY some content into an ordered collection, overwriting an
existing resource, what is the right thing to do?  I think the right
thing to do is to preserve the target resource's position.  Suggested
language:

  "When COPY is used to overwrite a member of an ordered collection
without an explicit Position header, the server MUST maintain the
original members position, just as when PUT is used."

If you MOVE some content this is a little more difficult.  Perhaps you
could say "When a resource is moved from outside the ordered collection
into the ordered collection and overwriting a pre-existing member
(without an explicit Position header), the server SHOULD preserve the
pre-existing member's position.  When a resource is moved within the
ordered collection and overwites another internal member (without an
explicit Position header) the server MAY preserve either the source or
the destination's position but MUST NOT arbitrarily reorder the moved
resource to the end of the order."

> > > > resources exist (absolute), or relative orderings must 
> be fixed up
> when
> > > > a resource is deleted.
> >

Sorry, how can this possibly be explicit in the definition of the
PROPFIND response?  Unless the spec is clear, what's to stop the server
from arbitrarily reordering the collection (losing some or all of the
ordering information) when a resource is deleted?  After all, any other
write operation in an ordered collection may change the ordering, so the
definition which mentions the PROPFIND response obviously is dependent
on the behavior of write operations in between.

Lisa

> > > Those servers will need to set the Position header 
> accordingly if they
> want

---

From: "Julian Reschke" <[email-masked]>
Date: Mon, 7 Apr 2003 21:27:17 +0200

> Sent: Monday, April 07, 2003 8:52 PM
> To: 'Julian Reschke'; 'Webdav WG'

OK, you got me there :-)

The default of "end-of-ordering" in the absence of the Position header is
specified for the case where a new collection member is *added*. A MOVE can
be seen both as

1) removing a binding and adding a new binding or
2) renaming a binding.

Depending on which point of view you take, you are or you aren't adding a
new collection member. The ordering spec currently is silent on how a
collection-internal MOVE needs to work, and I'm not sure that it would be a
good idea to get into the business of  defining this

> simply a rename.  A server ought at least to be able to preserve the

I disagree here -- a MOVE within a collection *can* be implemented as a
simple rename, but no spec currently forces servers to behave that way.
RFC2518 defines COPY/DELETE semantics, the binding spec (I think) sees it as
BIND/UNBIND.

> it should at least be a SHOULD.

This would definitively be useful for the average client. Does anybody have
a problem with making this a SHOULD?

> ACL isn't the issue -- it was just an illustration.

It was a *good* illustration. This is a very important issue where I think
you are wrong (because the ACL spec clearly says that MOVEing a resource
must preserve it's access rights). You really should raise this on the ACL
list.

> original members position, just as when PUT is used."

It depends on the same question as above: is a new collection member added
or not? I don't think the ordering spec should get into the business of
defining this (RFC2518bis possibly should).

> resource to the end of the order."

Again, the ordering spec defines the behaviour based on the condition of
whether new internal members are added or not. I think it's consistent in
this regard. Mandating a specific behaviour here won't fly -- if we really
want to make this consistent between specific implementations, we should try
to clarify this in RFC2518bis (the behaviour for ordered collections will
then follow automatically).

> ordering information) when a resource is deleted?  After all, any other

It follows from the definition of ordering. Removing an element from a fully
ordered set doesn't affect the ordering of the remaining elements. If "a"
was "before" "c" before the DELETE of "b", it still will be before it after
the operation.

> on the behavior of write operations in between.

No, that is not the case. No write operation will have side-effects to the
ordering of existing members. A newly added member is simply inserted at a
specific position in the ordering, but the ordering of the previously
present elements will still be the same.

Julian

---

From: "Jim Whitehead" <[email-masked]>
Date: Tue, 8 Apr 2003 10:16:53 -0700

The ACL list can be loosely viewed as a design team. I say loosely, since
design teams are normally small and closed, and this list is open and free
for all to subscribe. It emerged as a way to prevent the main DAV list from
being occasionally swamped by ACL discussion.

Operationally, actively working members of the DAV WG are subscribed to both
the main DAV list and the ACL list, and so the ACL list serves as a
convenient partitioning and filtering mechanism for ACL discussions.

Of course, all drafts discussed on the ACL list are brought to the main DAV
list for WG last call, and for official decisions on consensus. See for
example:

http://lists.w3.org/Archives/Public/w3c-dist-auth/2001AprJun/0313.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002AprJun/0088.html

- Jim