Notes taken by John Stracke.
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).
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.
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.
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.