Notes on Advanced Collections from IETF 46

Here are my notes on the advanced collections discussions from the IETF
meetings.  There were 2 unofficial breakout sessions devoted entirely to
review of the advanced collections specifications, as well as an hour
devoted to the redirect references specification in the official WebDAV
working group meeting.  (These are *not* the official minutes of the WebDAV
working group meeting.)
Advanced Collections
First Breakout
Present: Rohit Khare, Tyson Chihaya, Jason Crawford, Peter Carlson, Geoff
Clemm, Judy Slein, Yaron Goland, James Hunt, Jim Whitehead, Kevin Wiggen,
Jim Amsden
1	Bindings
1.1	Abstract
Y: Don't mention the other specifications.  Say more about what is in this
specification.
1.2	Introduction
Y: It's very difficult to understand the difference between bindings and URI
mappings, and the motivation for distinguishing between them.  It's
difficult to understand how you would create a new URI mapping.
Y: It's not clear why this is all presented as having something especially
to do with collections.
G: Adding a new binding to a collection allows you to add mappings to all
children without an individual operation for each child
Y: The spec makes assumptions about how things are implemented.  This is
bad.  It should concern only what a client would perceive. 
G: We don't make assumptions about implementation.  We do present a semantic
model of bindings.  This is needed to help you make sense of the protocol
elements.
Agreement that the model should be developed from the client point of view.
G: A client needs to know what objects it needs lock in order to perform a
given operation.  For example, to MOVE /a/x.html, what object needs to be
locked?  It's the model that makes this clear.
1.2.1	Bindings and URI Mappings
G: The state of a namespace is captured by collections; the states of the
collections determine the namespace.
Y: No. DAV allows a resource not to be a member of a collection. Only if an
/a/ and /a/x.html are dav-compliant are they required to be collection /
child.
G: The bindings spec allows that mappings don't have to be induced by
bindings.  There can be mappings that are not induced by bindings. But
bindings give you a way to control those mappings that are induced by
bindings.
Y: Wants a way to create mappings to anything, unrelated to collections.
G: For versioning, it's not acceptable to have to lock the entire namespace
in order to perform operations like MOVE.  Also, you need a model where
managing URI mappings is done through resources, because only resources can
be checked out (a name is not a resource, and doesn't have state, and can't
be checked out). You need a way to track the history of the namespace and
get back to a previous state.  There has to be some resource whose state
captures the namespace state at a previous time.
Y:  The binding spec shouldn't force people to pay the price of versioning
needs if they don't intend to support versioning.
Y: It's not possible to implement the binding protocol on a file system.
The applications that care most about bindings are document management
systems and configuration management systems.  Do file systems care?  Yes,
because they have links and need some way to model links.  Bindings are
similar to hard links in Unix.
EJW: We could define a MAP method. We could also make it to automatically
create the bindings we want if it's operating in a dav consistent namespace.
EJW:  The relation could be stored on the container or on the containee or
neither.
Y: The dav spec doesn't take a position on this.
G: We need to know for versioning, in order to know what object to lock when
we want to do a MOVE or DELETE.
Consider the case where we want to delete one mapping to a single simple
resource. 
Do we want to version the namespace or version the resource? Both.
Versioning selection rules make it too complicated to try to track all the
mappings to a resource over time.  Direct refs are inherently unreliable. So
we arrive at bindings, which are reliable and can be reasonably tracked
because they are part of the state of a collection.  To do a delete, you
have to check out the collection.
How do you version the root collection? You would have to create a versioned
collection there.  You would have to put "/" under version control.
Versioning isn't compatible with inconsistent namespaces.  You can't version
a free-floating resource.  If you deleted such a resource, you wouldn't be
able to get back to a state of the namespace where the resource was present,
because it's too difficult to track the state of the entire namespace.
Y: Make it so that mappings induce mappings, as bindings do according to the
current spec, if you are in a DAV consistent namespace, otherwise not. 
Geoff ok with that, though would make the protocol more complicated.  We'd
have to assess that.
Moment of enlightenment about the difference between mappings and bindings:
With bindings you are guaranteed that if /a1/ and /a2/ are bound to the same
collection C, then if you DELETE /a1/x.html, then /a2/x.html will no longer
be mapped to that resource.  On the mapping model if you are in an
inconsistent namespace this is not the case.  If all you have are mappings,
then the mapping of /a1/ is completely independent of the mapping of
/a1/x.html.  Even if /a1/ and /a2/ are mapped to the same collection C,
there is no reason to expect that /a1/x.html and /a2/x.html are mapped to
the same resource. If you PUT to /a1/x.html, you won't necessarily see the
result at /a2/x.html.
Y: There should be 2 separate specs, one for consistent namespaces, one for
inconsistent namespaces.  State explicitly that the binding spec is only for
consistent namespaces.  The other spec, for creating new mappings in
inconsistent namespaces can be left TBD. 
G: Supporting non-versioned resources in versioned collections would require
mapping semantics rather than binding semantics.
Y: The explanation of why a straight mapping spec was not adequate needs to
be written down in a separate document (rationale spec, for example), and
make sure it beocmes an RFC.
1.3	Terminology
Y: Definition of "resource": At the moment, the binding spec references the
URI draft's definition.  It should instead reference the HTTP spec's
definition, which is more specific and is the one we (as an extension to
HTTP) should reference. 
We'll look into this.
1.4	Section 6 (DELETE)
Y:  Don't make it look like the DELETE definition in HTTP was stupid.  State
clearly in the introduction that we are changing the definition of DELETE.
Our definition is different from the one in HTTP and the one in 2518. Change
the last sentence of Section 6 to say that servers that support bindings
MUST NOT follow the definition in RFC 2518.
1.5	BIND Status Codes
Y: Don't use new error codes - Only rely exclusively on the error code if a
proxy server would have to look at it.
But it's harder for a client to have to look at the entity response body as
well as the code.
EJW: We are far from exhausting status codes, and we don't need to address a
general error code extension mechanism for HTTP.  We would have to address
the problem of different errors at source / destination, and some generic
approach to depth operations.  This is a Pandora's box.
Y: There is not enough information in HTTP error codes for clients to do
anything useful with it
JA: Just use status codes, and let SOAP take care of this.
Needs more discussion.
1.6	Loops
Do we need the 507 Loop Forbidden status code (or equivalent)?
Loops can be useful in some scenarios.  They are needed for versioning.  
We'll say that servers MUST allow loops to be created.
Any server that can support bindings to collections would support loops.
The server would always allow creation of a loop, but it might have to fail
some operations if it encounters a loop.
1.7	The All-Bindings Header
The client doesn't know the state of the resource after the All-Bindings
header has been applied.  It's not the client's business whether or when
garbage collection takes place. If  the client can't see it, that's the end
of it from client's point of view.  
The server doesn't know whether the intent was to get rid of all dav
bindings or whether the client wanted to destroy the resource.
G: Opposes All-Bindings. If the client wants to delete them all, it should
be required to iterate through them all deleting one at a time.  If we have
All-Bindings, after a DELETE there could still be other mappings that were
not dependent on any binding.
HTTP and 2518 said DELETE would delete the resource, but we've changed the
definition so that we don't have that any more.  Some of us would like a way
to get rid of the resource altogether, but it seems impossible to specify
that.  So the closest we could come to that is to say "Delete all the
bindings".
There are also security implications of All-Bindings.  You should only be
able to delete the bindings you are authorized to see.
Agreed: Get rid of the All-Bindings header.
1.8	Atomicity of DELETE
We say that DELETE is atomic, even when a collection is being deleted,
because it is just the removal of a single binding.
Y: An atomic DELETE can't be implemented on the Microsoft file systems. 
K: It turned out to be a lot of work for a transactioning system to
implement it non-atomically. 
G: You could implement the atomicity in a layer above the file system.
Y: This would be too complex and too costly in performance.
Servers may make DELETE atomic if they like.
Clients want delete and move to be atomic.
G: We could say that DELETE SHOULD be atomic, as a statement of intent for
servers, but admit that we couldn't do what clients want.
We could include an Implementation Note: If the server can DELETE
atomically, it should feel free to do so.
1.9	DELETE, access control, and locks
Somewhere we need to say that acls and locks need to be checked.  So even
though DELETE is just removing a binding, when you are deleting a collection
you have to check all the child nodes for access control and locks.
Whether to say this in the spec, or just refer to access control and locking
discussions elsewhere.  Or maybe don't say anything here, but have an
implementer's guide or other document that discusses the interactions
between the WebDAV specifications. 
1.10	Atomicity of MOVE
Same as for DELETE. 
What should happen if you attempt a MOVE on a collection that contains
bindings you are not authorized to know about? 
1.11	Implementation Note on DELETE
Y: Talking about copy + fixup + delete will just raise lots of unnecessary
discussion.
Agreed: Remove this section.  It could be preserved somewhere else, either
on the mailing list or in an implementer's guide.
1.12	Locking
Y: Locks do not survive a MOVE.
G: Can we say that a MOVE must fail if the resource is locked? 
Y: This is not really an issue about bindings. There needs to be a separate
locking draft.  Sections 8.2 and 9 should be removed.
JA: It won't be possible to implement the binding spec if we don't
understand the behavior of bindings with locks. 
[More discussion of locking models in general] 
JS: We addressed locks here because of our MOVE definition.  Since we
redefined MOVE to be rename, it was clear that you have the same resource
before and after the move, so it should have the same state before and
after.  The lockdiscovery property is part of that state, and so the
resource should still be locked after the MOVE. 
Agreed: Locking is a high priority issue, but shouldn't be addressed in this
spec.  Whatever is decided in general about locking, the implications for
bindings should just fall out of that.
1.13	Section 10 Bindings and Other Methods
Qualify what is said here.  It applies only to successful operations.
1.14	DAV:guid
Change the name of this property to something more informative, like
DAV:resourceid.  For the URI Scheme, copy the language from the UUID draft,
not from RFC 2518.
1.15	DAV:bindings
There is a potential security problem here.   The client must only be able
to see bindings it is authorized to know about.
1.16	Loop Detection
Y: What if a resource is dynamic, and counts the number of requests against
it? And the server applies a request to it multiple times before deciding
that it's in a loop? Can we require servers to execute only once in a loop?
No, this is too severe a constraint.
1.17	Loop Header
This header is not needed.  If you encountered a loop, you would be getting
a multistatus response.
1.18	Capability Discovery
Get rid of the "MUST". A resource is not required to advertise its
capabilities.
1.19	IANA Considerations
Add the new URI scheme to IANA considerations.
1.20	Acknowledgements
Add James Hunt, Peter Carlson.
2	Redirect References
Y: This specification has nothing to do with collections, so change the
parts of the abstract and introduction that make it sound as if it does.
WebDAV Working Group Meeting
2.1	MKRESOURCE
K: If there's a resource at the location already and Overwrite: T, you have
to delete the existing resource first.  If the entire operation cannot be
completed, you have to roll back.  This is different (maybe) from the
Overwrite behavior in RFC 2518.  A file system might not be able to roll
back.
EJW: It was the intent of RFC 2518 that you would have to roll back if you
couldn't create the new resource successfully.
What should the response code be if you couldn't do the delete? 5xx? 4xx?
207?
Y: It was the intent of RFC 2518 that the operation not be atomic.  You
could leave the file system in a state, e.g., where you had deleted the
existing resource but not been able to create the new resource.
K: MKRESOURCE should be consistent with MKCOL as to its body.
K: The XML used in MKRESOURCE should be analogous to what you get in a
response from a redirect reference.  You provide DAV:resourcetype and
DAV:reftarget in MKRESOURCE, but a 302 response has DAV:location and
DAV:resourcetype.  Maybe in both cases have the value of DAV:resourcetype be
structured:
<resourcetype>
   <redirect/>
   <location> . . . </location>
</resourcetype>
There are several things going on here.  What you put in are the properties
of the redirect reference resource to be created, so they are what you get
back if you do PROPFIND with Passthrough: F.  What you get back without the
Passthrough header is a 302 response, and that's different.  It tells you
how to reach the target resource, and it's structured to be analogous to a
normal HTTP 302 response.
We wouldn't want to make location part of the resourcetype property, because
when you change the location you are not changing the resource type.
Location and reftarget are separate because we want reftarget to allow
relative URIs, but location is defined in HTTP to be an absolute URI.
2.2	PUT and POST for Redirect References
Y: PUT should succeed on a redirect reference (with Passthrough: F).  It
should be allowed for a redirect reference to have a body.
Y: POST should also be allowed on a redirect reference with Passthrough: F.
2.3	Location Header
Y: We need to allow multiple values in the location header.  He has defined
(in some internet draft) an AL header that is similar to location, but
allows multiple values.  The order of the values is significant.  Use that
instead of location.
2.4	509 (Dangling References Forbidden)
EJW: Remove the 509 (Dangling References Forbidden) status code.  Agreed.
2.5	Redirect References to Collections
EJW: We need to think about whether redirect references to collections are
reasonable to implement.
We need to think about potential problems of redirect references to dynamic
resources.
2.6	Passthrough Header
JA: The behavior for Passthrough: T should be to pass the request on to the
target resource.
G: No, we want redirect references to be simple to implement.  We don't want
a server to have to have proxy capabilities to support redirect references.
Besides, that would be to mix the characteristics of direct and redirect
references.
JS: We could change the name of the header. "Passthrough" came from the days
when we planned to specify direct references.  We could call the header
"Apply-To-Redirect" and make its semantics specific to redirect references.
Agreed.
Second Breakout
Present: Kevin Wiggen, Yaron Goland, Chris Kaler, Lisa Dusseault, Jim
Whitehead, Geoff Clemm, Judy Slein
3	Ordered Collections
3.1	Locks and Collection Ordering
Since the ordering is part of the state of the collection, it can't be
changed while the collection is locked unless you are the lock owner.
3.2	Depth infinity PROPFIND and collection orderings
K: Is there any requirement about what order you have to return things if
you are doing a Depth: infinity PROPFIND and some of the collections in the
hierarchy are ordered? Do you have to go depth first, or breadth first, or
something else?  Kevin implemented the first of each collection, then the
second of each collection, etc., just for a lark.  Is this compliant?
Kevin's ordering is the most efficient for his implementation.  It's
certainly not what clients would want.
We don't want to do anything that would require a server to spool all the
results before sending them.  No matter what we require, there will probably
be some server implementation that will be forced to spool.
Leave it up to the server, and if a client really cares, it should do Depth:
1 PROPFINDs.
3.3	Server-Maintained Orderings
K: Server-maintained orderings are pointless.  A client won't be able to
pick a useful one unless client is designed for that server.  Someone may
standardize some orderings someday, and then it would be useful to support
server-maintained orderings.  We don't want to make it impossible to support
server-maintained orderings if that ever happens, but for now we should not
specify the support.
Raise this again on the mailing list. 
3.4	Including Ordering Semantics with All PROPFIND Responses
K: The spec says that PROPFIND on an ordered collection SHOULD return
ordering semantic.  Make this MUST.
If you cared, you would ask for that information.
Make it either MUST or eliminate it.
Clients often reorder unless they know the collection was ordered at the
server.
Y:  Favors MUST. Windows Explorer would use the server's ordering if it knew
the response was ordered.  Otherwise it reorders in its own standard way.
Explorer would not be willing to request DAV:orderingtype on every PROPFIND
explicitly.  
We might want to provide a way to ask for a clump of special features - say
"this is for display" -- that gets you a set of special features including
the ordering semantics, what icon to use, etc.
G: Don't return random stuff that you think should be interesting to a
client without the client's asking for it.
If it's to be useful, response must indicate that the collection is ordered.
We may want a way to let a client turn off ordering for optimization.
Discuss on mailing list.
3.5	Section 13.2 - 13.3 Body for OPTIONS
Both the ordering spec and the versioning spec define ways to get additional
information about capabilities using request / response bodies.  This work
needs to be coordinated so that both specs do it the same way.
3.6	Section 10.2 Position Header
K: The spec wants before or after a Generic-Coded-url, but it would be
better just to use the final path segment.
Y: If you do that, you need language specifying how to resolve the segment
to an absolute URI.
Agreed.


Judith A. Slein
Xerox Corporation
jslein@crt.xerox.com
(716)422-5169
800 Phillips Road 105/50C
Webster, NY 14580

Received on Friday, 12 November 1999 17:25:29 UTC