Notes taken by John Stracke.



Requirements doc

Presented by Jim Davis; slides should be on the Web shortly after the meeting

We're already in WG Last Call.

Slide: Terminology--definitions taken directly from the Draft

Slide: Overview: changes since LA

Slide: Referential Resources in General. M&AP

Slide: References in Collections

Slide: Indirect References. "Roughly speaking, references that happen on the client side." Larry Masinter saying that he thinks there's a blurring between the URI and the resource/reference; that references should point to resources, not URIs (how?). Jim D. gave him a more precise description, and he said, mmm, mumble, well, go on. Lurking doubts?

Slide: Direct References. Jim points out that most servers won't want them, but he knows at least one commercial system that does (a Xerox product, not being marketed very strongly). Mike Oliver (OpenText) asking if we've considered a hybrid, a references that passes some methods, but not all. Jim asked him to take it up on the list.

Slide: Strong References

Slide: Ordered Collections

Question from John Barr (Motorola): should we be able to retrieve the Nth resource in a collection, or the successor to a resource? Undetermined.

Larry Masinter asking about uniqueness when a resource may have multiple URIs. Jim Whitehead explained (started to) that we're viewing resources differently (I think he meant that we've been thinking that separate URIs are separate resources).

Protocol doc

Jim Davis again

Slide: new issues that have come up recently

Slide: Information (URL for req draft, and authors' addresses).

Slide: WebDAV Collections Protocol

Slide: scope of specification. Expanded after AdvCol BOF and subsequent Thai run.

Slide: Referential Resource. Diagram of properties.

Slide: New HTTP Headers

Slide: New Methods

Slide: New properties

Slide: Weak, Indirect References

Slide: Operations on Indirect Reference. Larry wants us to clarify that these are client-side redirection. Q (Ted Hardie): what's the point of MOVEing an indirect reference? A: for symmetry, so the client can MOVE a resource without knowing what it is.

Slide: Operations on Direct Reference. Q (Yaron): why do we need DELREF? Take it to the list. Q (John Stracke): do we want Location or Content-Location? Jim'll check. Q (Albert Lunde): what about broken (?) clients that would get confused by a Location in a non-3xx response? (Side thread: do we want to care about broken clients? Yaron: yes. Jim: why? Rohe [?]: because he makes one. Much laughter, Yaron says he was about to say the same thing.) Jim explained that a chain of direct refs would yield multiple Locations; someone pointed out that you can't do that; the HTTP syntax doesn't allow it. So we'll come up with a new header. Steve Somebody asking what happens if the target's owner doesn't want to expose the target's location. New requirement: ref creator can hide the target location.

Slide: Creating Referential Resources

Slide: Operations on Target Resources. "MOVE updates direct references" implies that DAV's "MOVE A, B expands to COPY A, B; DELETE A" must be changed to "MOVE A, B expands to COPY A, B; optionally update links; DELETE A". Questioning as to why DELETE on a target DELETEs the direct ref. Somebody thinks that's a mistake because Apache doesn't do that (since Apache does it only via config files).

Slide: Issues

Skipping the ordered collections protocol because out of time.


Lisa Dusseault Lippert

Slide: Agenda

Slide: Background. Draft names, terminology

Slide: File System ACLs

Slide: Other ACLs efforts. Addition: CAT. Common Authentication Technology. New proposal there from Newman, Generic Auth API.

Slide: Scenarios. "Hidden totally invisible" may impact references.

Slide: Goals. Discussion: should we be able to put access controls to properties? Point: are we creating a mechanism to manage underlying, pre-existing ACLs, or are we creating a mechanism to manage DAV-specific ACLs? Answer: probably the latter. Lisa has resigned herself to interoperability/predictability implying that the permissions on the underlying file may let people get around the DAV ACL. Larry Masinter considers this a poor goal; the implementors should not be required to build their own access control system. Keith Moore (?) points out that they're not being required to; anything but accessing via HTTP is out of scope.

Slide: Goals Continued

Slide: Inheritance goals. Jim Davis asks to defer the question of inheritance, so that we can get something done. Questions: do we want to (a) defer inheritance altoghether, (b) define only one mode, or (c) define both?

Slide: Extensibility and Discovery. Addition: right =? permission for (set of) method(s).

Missed a slide

Slide: Encryption

Slide: Out of scope. Adding: sensitivity (levels of how much you can divulge; can probably be layered), delegation. Not discussed; no consensus on what's OOS.

New agenda item: heirarchical URI/heirarchical collection identification

Larry Masinter

Larry: can a resource with two URIs be in two collections? Yaron: yes, sure, that's fine. Jim W.: the model then should be that there are two resources that, under the covers, refer to the same representation. Larry: let's resolve the ambiguity in the spec. Yaron asking again for generic graph operations.


Chris Kaler

Handout: 6 slides

Slide: Versioning Viewpoints

Slide: Common Ground I

Slide: Common Ground II

Slide: Configuration Management

Slide: Next Steps

Yaron: why do we need to support downlevel clients? Why not just make it a server policy on PUT? Answer: we want to make sure the protocol doesn't interfere with that policy. Jim Davis: OK, but please let's not complicate the protocol too far; Chris says, sure, that hasn't been too hard so far. Somebody wants to clarify the "new version with each PUT" bit by saying that you don't get a new version if there are no changes.

Loose ends

Jim W: do we need to do configuration management or not? Previously the WG said no; the versioning design team feels that versioning without CM wouldn't be too useful, so we should do something simple, at least. Jim Davis wants a versioning protocol that can subset to leave out the CM. Larry Masinter says that there's a large percentage of the customers that don't use CM.