6/15/98 9:15 AM

EJW welcoming remarks

Introductions

6/15/98 9:21 AM

Agenda bashing

6/15/98 9:34 AM

Heads-up: when IESG eventually approves the Proposed Standard, UCI plans to issue a press release; watch the list for an invitation to contribute testimonial quotes from participating organizations

Heads-up: interested in event notification? WISEN, UC Irvine, July 13-14

6/15/98 9:38 AM

"Versioning and Variant Authoring Requirements" presentation by EJW

Discussion of whether "a single resource can participate in multiple version graphs": diverging branches of development; public/private release histories. Whether such versioning info can be stored in resource properties vs. a separate "version graph" resource -- has been debated, expected to be debated again.

Subpoint: if version graphs span servers, then it's unavoidable that resources participate in multiple graphs. (However, the graph itself should be under the physical control of one server, so local links can be maintained (strong) and off-server links will necessarily be weaker.)

If a node has many successors in a branching graph, there should be a distinguished arc (property on arc?) that indicate the primary line of development.

"configuration management (as opposed to) versioning" -- could a collection be used to mark a configuration

EJW: I hear that there is interest in some way of indicating or differentiating lines of development with a version graph.

"default" is different from "the latest one" (and "the latest one on a particular branch") -- and all three are discussed in the draft, but the method in the proposal defines only the first.

Who specifies the "default" policy? EJW: any (authorized) client, using the DEFSET method. Should there be a default default (do nothing, or latest)? I don't know.

Re: slide "Version Graph (3)" -- Since a resource may be in multiple version graphs, it may not be absolutely possible to enumerate all version graphs it belongs to. Strike the MUST.

@@Several comments suggested using XML ID/IDREF and XML Linking (XPointers) to represent version graphs

Is the version graph a resource itself (and, thus, versionable)?

Re: Slide "Graph Navigation". There should be an additional requirement to identify which branch a resource is a member of.

What are the implications of requiring every version graph to have a unique root? There are some repositories (Continuous) that actually support multiple roots, but it seems a reasonable restriction.

Perhaps an arc type/link type for merging two version trees (as opposed to just derived-from)?

[Suppose #3 was a major change slipped in from another development tree -- so you could reach #3 using

successor() from the root, but 3 is not derived-from 2...] @@Bradley to send a personal note to the list on this topic

6/15/98 10:41 AM

20 Minute Break

6/15/98 11:16 AM

What kind of serialization (transactionality) requirements should there be? Can we lock an entire line of development?

Is a version identifier a human-readable field (and thus, guaranteed unique?) A: unique within a version graph. @@need for a label, distinct from a version identifier, intended for humans. Labels must be unique within a version graph. There can be multiple labels per node. [Labels can be reassigned ("are mutable"), but identifiers are fixed]

Comment: it's like a filesystem abstraction of inodes: the primitive, unique identifier can have multiple labels (pathnames)

Comment: what about schema discovery? No, we don't do it in DAV; other groups are solving it more generally for XML (RDF &c)

Ideas for axes of variation: platform-supported. Where to draw the boundary between arc-types HTTP understands for content-negotiation (charset, etc) vs other variants from the SCM literature.

Mention of the other IETF WG on content-negotiation; do we take that on as an external dependency?

Should we strictly limit is-variant-of to being defined on HTTP's built-in? Should we remain silent on HTTP syntax entirely, encoding variants in the version graph and leaving the delivery alone? Should there be an axis for any feature-tag [Masinter, et al]?

@@definite need for multiple axes, which also implies discovery

6/15/98 1:19 PM

Review of EJW's versioning protocol (ulterior message: want to join the authoring group?)

Q: is is-variant-of directed? Clearly is-derived-from has a predecessor and successor, but is it only possible to go from English to French and not back? Consider an international organization in which multiple languages are normative, and the "development path" hopscotches around.

Are variants an array instead of a graph? Content-negotiation has a "simpler" vision of variation (equal substitutes) -- so how to map back and forth to a graph?

Comment: are the arrowheads for is-derived-from in the wrong direction? EJW: I made a sign convention that follows the temporal order of creation.

Scenario: English and French might be equivalent, but when each have PDF versions, that's a "derived variant". What if it takes three revs by the translator to match one rev of the source -- how to synchronize that?

We need a good term for "the three versions" like "line of development" or "branch" or "line of descent"

@@People would like is-variant-of to be symmetric (alternative). Either have the relationship bidirectional, or perhaps investigate another representation entirely.

@@Develop scenarios in order to evaluate above

Vportals should be able to point to a given label, not just an identifier, and exact matches.

YG: why insist on building a parallel namespace for "labels"? We have URIs and they're quite nice...

Sam: we're stretched between versioning and config mgmt: from single documents to collections.

YG: we had this with displayname in WebDAV the first time around, and it's non-normative. Human-readable is also non-unique.

[much debate ensued]

Sam: I'd like to see a @@use case scenario for CM where a tool wants to update versioned data without being otherwise version-aware. Whether optimizing for this drives us to labels or not is subsidiary @@John, Bradley and Sam agreed to submit to the list.

Do arcs have properties?

[Disc: Can't we just use proppatch by mapping arc-id's into http-urls? But then would we want to allow copy or move? ]

EJW: need to consider "node and arcs have properties" in the context of the use-cases. @@Alan to raise this issue on the list within two weeks.

There's a deeper issue of how we want to retrieve vgraph-specific information, like comments: where are they conceptually saved and retrieved; what's stored in the graph or on the resource?

AH: Sentiment to separate out DIFF and PATCH into a generic updating draft destined for the HTTP-EXT group

Will clients be required to always use Checkout/Checkin vs. optimistic clients that just use lock and put -- shouldn't a smart store fixup behind the scenes?

"for a versioned WebDAV repository, DAV methods have additional semantics" or "new methods for versioning semantics"

When the client saves, does it lock or does it write? Check OPTIONS, optimistic, pessimistic? Detecting updates by changed entity-tags. What does LOCK mean on a versioned server?

Argument one: LOCK is really a CO+LOCK and UNLOCK is a CI+UNLOCK

Argument two: it prevents actions involving a merge or even doing your CO while it's locked.

EJW: so you've locked this whole branch and you're in the edit-debug cycle, and you want to update files to a scratch space; is that completely private and unprotected; or is it checked-out and a working copy created?

Is the ci/co on the resource or on the Vportal? Excellent question... Does the Vportal redirect all of its actions to the graph? Will there have to be a Vdelete along with Vcreate. Perhaps like the DAV source mechanism, asking for an URL to manage the Vportal with...

Suppose a downlevel client does a put to the Vportal; the server should do the right magic in the background to assume it's the next version in the sequence and so on.

6/15/98 3:49 PM

Resume for EJW's proposed method walkthrough

Re: GRAPHOP: why not overload PROPPATCH instead? A: the side-effects just keep growing...

Perhaps it should be renamed GRAPHPATCH?

What syntax does GRAPHGET return? RDF, XML, ???

Why not round-trip -- the output of GG should be the input form to GH...

AH: three issues: how to represent, how to get it, and whether the client can manipulate it.

AH argues for using XML and ID/IDREF so our spec has no external dependencies. AH makes a quick demo of how to use that mechanism by labeling <NODE> tags:

<graph>

<node id="foo"> xxxx </node>

<node id="bar"> xxxx <child href="#foo"> </node>

<node id="baz"> xxxx <child href="#foo"> </node>

<noderef href="#foo"/>

</graph>

@@It seems like having an UNCHECKOUT is easier than tracking down the working resource to unlock and delete it.

Note: Checkout locks the new working copy -- it does not lock what you checked out. Implies many principals can have many outstanding checkouts.

JimDavis: out of a sense of minimality: do we even need to lock it? No one else knows it's there... to my taste, we wire artifacts into the version graph at some future time; here policy is wired right into the checkout, jointly creating a resource and wiring it in.

[Lots of policy scenarios proffered in response to Checkout's claim that an "is-derived-from" arc is placed immediately. If branch-creation is implicit on checking-in earlier editions, how to manually force it? How to find out which members of the graph are frozen (to, say, garbage collect)? etc...]

@@There is a requirement to distinguish frozen from working resources

Nifty point: it IS true that the fresh working copy is-derived-from, but not yet successor-of...

@@need to create a new branch at any node, particularly the tip of the line of development

also, if the tip has advanced while a user was editing, if it could not mainline, it might be a warning or error rather than immediately create a branch.

will only-linear repositories get to play? if so, above should allow an error-response.

@@During check-in the URL of the working resource might change

Clarification: working resource must be http resource to be meaningful (even though non-http resources can be part of the version graph)

@@note for the security section: caution DAV server from doing GET on random URL in processing a DIFF (Jim Davis)

question: can you provide parameters to the diff operator?

[Debate over how critical baseline DIFF support is to DAV -- or is it orthogonal to this process and belongs as an HTTP service?]

AH: Perhaps DIFF should be set by another forum. It was noted that HTTP-EXT is not chartered to consider any actual extensions, just the meta-architecture.

@@The packaging of DIFF and PATCH is an open issue; the sentiment in the room is largely for excluding it. Furthermore, if it is included it should be optional.

6/16/98 9:12 AM

The Second Day: Advanced Collections

@@There might be a requirement for discoverability of ref-integrity policy. Later striken from the agenda.

Should a referential-member work outside of a DAV context, too? Can non-DAV clients obtain the URI of the target reference? (using, say the Location: header for HTTP redirects). "Downlevel compatibility consequences should be in the reqt's" was one sentiment. Well, what's the scenario? Perhaps a non-DAV client even gets No Content at this point. Action: if John Stracke can sketch a mechanism, we can consider adding it. (today we don't flow-through methods from down-level gets, etc)

How do chains of strong-references ensure referential integrity of the whole? How do we handle cyclic references? (Depth?) Certainly can emerge for weak-links, i.e. across servers. Should we add an explicit non-requirement? @@yes, servers need not avoid cyclic references (internal or external)

@@proposal that in section 3.1, do we need to call them "ref member of collections" or simply "referential resources"? Judy reminds that references must be created within collections (but of course, so are resources).

"internal member" -> "ordinary resource"

or "referential and non-referential" b/c there may be future types (like vPortal?)

Resolved: rewrite test as "should be possible to discover whether a resource is referential"

around 3.1.13-14: should there be an additional requirement to enumerate all the strong references to a given target? Wording from the chard: It is possible to discover the strong references to a target URI (e.g. when contemplating changing/removing the resource). There is a consequent security/privacy concern to be documented, too: making strong references "notifies" the target.

@@suggestion: strong "trust effort"

@@owner of a target resource should be able to prohibit strong references.

@@countersuggestion: owner has no obligation: it should always be possible to delete the target, regardless of referential integrity.

@@observation: the only difference b/w strong and weak is merely that strong has a live property (whether the target exists), why separate them? Well, strong refs follow when the target moves.

EJW: perhaps the meaning of referential integrity belongs in protocol discussion, rather than abstract requirements space. On the other hand, if this needs to be in the reqt's, I'd make it a priority for today's discussion.

New post-LA IETF claim: only one ordering can be attached to a collection. Affirmative consensus on this point.

Note that servers are bound to maintain orderings, but the client is not mandated to obey it. Really only binds PROPFIND to output in that order.

Diversion: gee, should scalability be a formal requirement? EJW: It's implicit for all Internet scale protocols, IETF requirement and consensus of the meeting. It's motherhood and not mensurable.

Discussion topic: security implications of strong references.

Scenario 1: the DMA specs, nationwide, multiple authors, multiple versions.

For targets of strong references, help prevent/warn on breaking links to target (move, delete, etc).

a) are both ends on the same server or b) different servers

Scenario 2 ("different trust domains"): the IETF specs, where many referenceholders have limited rights to read and rely. Anyone can make a SR to an IETF doc, links are update to track, but you can't prevent IETF from deleting target of SR.

Scenario 3: how do I prevent someone from making an SR to my document? Example: don't want people to track a document as it moves from R&D server to Project implying greater corporate commitment, etc. Or, allowing an SR might imply it will always be there.

Scenario 4: Owner of the target may not be allowed to know who holds SRs. Suppose the DAV spec lives at Irvine and anyone can find out when it changes, but you can't enumerate all the references to it (is it from R&D or Projects?)

Two views of SRs:

1) can't delete the Target or

2) can delete, but then a) ref is deleted too, or b) ref is notified or marked for collection.

3) can delete, but it's like a Unix hard-link (consensus to remove this -- sorry we raised it...)

4) can move, and SR must be updated to track

5) what happens in case of SR or TR holder failure/bugs?

(And for all of these: is it best-effort or guaranteed?)

Principle: no required dependence or prohibition of cross-server communication.

Scenario 5: versioning scenarios say that checked-in resources are frozen; this contradicts a Ref-integrity policy which says they're updated.

6/16/98 11:38 AM

"Does anyone have some alcohol?" -- Jim Davis (for the whiteboard, silly!)

DAV needs policy in general for how (or whether) non-DAV clients can use DAV.

6/16/98 1:04 PM

Restart after a fine and firey Dixie bbq lunch...

Judy presented the AC protocol.

ADDREF as a method of its own bypasses dependency on http-ext's mandatory.

an external reference allows one to rename the imported artifact, btw...

The Referential-Member header specifies that name, but there is consensus sentiment it should be in the Request-URI. One dissent.

On ADDREF, there is no entity-body; the Content-Length must be zero.

Ref-Target should use the codedURI grammar production from WebDAV; use <> to bracket the URL.

Should the values of Ref-Integrity be just T/F or "strong/weak/..." leaving extensibility in? some murmurs for the latter.

Separate issue: GET on a referential member could 1) thunk out as a 3xx redirect for downlevel clients using the downlevel client. Should it? 2) send a 200 body with a human message and a link 3) combine with 1 above. General consensus on option three. (also true for HEAD, and needs to be specified for HEAD)

Note: can't PROPPATCH the reftarget property (it's a readonly prop). [if you want to aim at another location, just do another addref which, like PUT, overwrites Ref-Target.]

Ref-integrity and ref-target are "live properties" per DAV -- so re-ADDREF with new target and integrity can overwrite or change those properties.

Motion to rename ADDREF as MKREF b/c of these new scenarios... general consensus

Discussion of the semantics of ref-integrity upon MOVE or COPY (suppose it's strong moving to a zone only allowing weak). "By default MOVE and COPY allow the server to change ref-Integrity as needed, unless the Ref-Integrity header is explicitly specified, in which case the server must accept that setting or fail."

DELETE can fail if there are outstanding strong references; but there must be some way to force DELETE. We have to compromise strong at some point... A new header for DELETE is Override-Integrity, default to F, if set to T it forces it. That's just a proposal, which depends on further discussion of the requirements for strength.

Debate: should strong integrity survive in this spec; if not, what kind of hook to leave in

Recall the motivation for strong integrity was tracking moves; we should preserve it. Others said it's ref-integrity based on preventing accidental deletes.

If we have a good extensibility story, then it's easier to justify scrapping "strong" per se.

Wide consensus in the room to scrap strong IF there is an extensible form for deferring definition of strong/gazonka/etc levels of integrity.

6/16/98 3:09 PM

Resume with the Ordering part of Advanced Collections

What kind of information do we expect to find at the documentation for a DAV:ordering property? could be text, could be SQL, etc.

Scalability: the ADs criticized DAV's use of namespaces for being a "scalability bottleneck". Mandatory and W3C's Namespaces essay argued this is a red herring; clients will wire-in knowledge of named schemas and only human intervention will follow such links.

Proposal to split orderingtype out to be a separate property; then the ordering becomes a vector of Hrefs.

To the degree we need to modify properties, we can see PROPPATCH as a v1 effort; in the future we could efficiently send XML-diffs rather than doing all the manipulation on the client.

AH: concerned that referential members have their own properties -- as opposed to refmembers having the same properties as the resources they point to. PROPFIND returns the "wrong thing" it seems.

JD: Would you want GET on a refmember to return the original resource, and so on? Also, there are scenarios that MUST manage properties on the reference rather than the target

AH: given that we have sacrificed "strong", I withdraw my objections

Inheritance of properties was discussed in LA, and decreed a Bad Idea for security and manageability

Note: LOCK and MKREF are resource-creating operations which also need the Position operator.

Position should use the Coded-URL BNF production.

Position proposes allowing sequence numbers (starting at 0 or 1? open to debate)

Argument that absolute position is troublesome for datastructures without random access; locking ranges; off-by-one errors. But why make it impossible?

Indexed APIs for asynchronous systems is a bad idea because offsets wander as changes pile up on an unlocked collection.

No consensus reached

Proposed: MKCOL takes a header Ordering: whose value is an ordering type (Coded-URL). When you change your mind later, it's a ?? operation.

Does moving/copying/putting a position'd item to a collection force it to upgrade to Ordered Collection?

Motion to not allow change in Ordered/Unordered status for a collection by AB. Resistance. Claim that unordered is a type of ordering. Killing a collection and restarting just to change an ordering is too much (alpha to num to descending is hard work, but needs it).

proposal: All lists are born Ordered "DAV:arbitrary" (server-controlled) and can be changed at any time using proppatch if the server lets you.

Note: there's only two levels of workload for the server: none (arbitrary) or client-driven (replay in specified order) regardless of how exotic the sorting algorithm is.

Well, technically, that burdens arbitrary orderings to reporting a million-entry dav:ordering entry; so it's better to just say there's unordered and client-ordered as two settings. (Server-side is DASL).

Discussion, but no consensus on whether there needs to be a mechanism in the protocol for setting the ordering on a collection with one network round trip (currently in the spec. there is a mechanism: PROPPATCH on the dav:ordering property.)

6/16/98 4:23 PM

Poll: anyone with an announced WebDAV server? 1 client? 1

Xerox has no plans for a commercial server

Since the client and server side DAV APIs are identical, it can detect a CORBA/ILU server and bypass HTTP entirely... nifty!

The posters Jim Davis filled in...

What is DAV's policy on non-DAV clients in general?

Is there a requirement for the discovery of RI policy?

Is it desirable for non-DAV clients to obtain the URI of a target ref of a r.m.c.

No req to guard against cyclic references

rephrase 3.1.14?

it is possible to discover the strong refs to a target. rationale: enables out-of-band negotiation when changes are contemplated

Privacy concerns rule out ref-accounting scheme

risks in strong refs that cross domains

Security can block strength:

if an SR is locked, it can't be deleted to maintain RI

an owner can request an ability to prohibit SRs

Definitions:

weak: no RI

strong: best-effort; policy undefined

maybe the specific policy in Req of 'always delete'; not leave it open [huh? -RK]

RI could mean that dead links are marked as such -- not deleted. rationale: don't discard metadata on the ref.

It is always possible to delete the Target of an SR irrespective of RI policy management (superuser)

6/17/98 9:21 AM

"The DAV CHMOD Command"

LisaDu's ACL Goals draft (unpublished as yet, expected to replace acreq-01 ?)

Howard Palmer is no longer able to actively edit the ACL goals; JimW requested Lisa's involvement for today's presentation; still actively seeking volunteers.

Examples of flexible ACLs? NTFS lets you add new permission types; DCE spec allows rights-space extensions

Scope? DAV is more than filesystems; could be used to control door locks, etc... A: it's more likely to have inconsistency with existing filesystem security semantics; there's no back-doors to a door-lock system!

Document repositories are yet other bodies of experience with security; different again from filesystems.

AH: There are years of experience describing collection and resource controls for files which should inspire server control.

Paul Leach observed at IETF-LA LDAP that if DAV and LDAP aim at the same space, there needs to be isomorphic security. In LDAP, there's sensitivity levels: a record could be marked confidential or so; this seems restricitive because it lumps together lots and lots of records at the same level.

Document note: IETF likes lots and lots of cross-references indicating informed evaluation of all related proposals. Editor(s) should consider expanding such info.

Nondiscretionary access control: for really confidential systems, users can't "leak" info by arbitrarily manipulating permissions (Orange Book Level B1 and above).

NTFS looks at all the denys, then the grants for users, groups, and alls in turn.

AFS is usually-consistent; denys are ORd, then all the grants are ANDed

Whether the FS checks access to each component of the path (VMS), or just the complete path (NT, Netscape).

Scenario variant: in high-security systems, you shouldn't even reveal the file exists, even if you can read the collection. Furthermore, you can even create another file with the same name; no error is reported ("we can neither confirm nor deny").

Additional scenarios: author (edits own) and editor (edits others' files) roles; there are other analagous roles. [Examples from Notes and WebSiteDirector]

WebDAV already cites that PROPFIND should silently suppress entries not permitted to the users. (it was a nonbinding (lower-case) must).

Discussion to reevaluate "access to any principal from specified hosts" which is commonly used for the web but reevaluated here.

The spec is silent on Administration, but how should groups be modeled? proposal to state explicitly this is out of scope. Furthermore, is there a limit to the number of groups a user can participate in? Recall that HTTP authentication is user-based only; there's no concept of groups to borrow from there. Also, clients or servers may not be able to fully enumerate the membership lists; SDSI does not necc. have a single-point-of-control for this mathematics.

Can there be a resource without an ACL? (i.e. there's no delete ACL, just view+modify)

Does ownership have inherent rights?

Sets of permissions: could be UNIX rwx, AFS rwlidka, NTFS ..., DAV's method set (MKCOL, DELETE, etc.)

However permissions must always map into the fundamental set: DAV methods. (e.g. "how do I prevent PROPPATCH, or just modifying this prop?" may still map onto a different user model of permissions.)

The granularity of access (whole resource vs body vs all properties as a whole vs individual properties) is noted "contentious".

EJW: I think UNIX access control is probably insufficient; DAV access controls may differ from existing FS access controls.

Consensus that property-level access control is a requirement; original propositioner meant something weaker, that otherwise people will go out of band to do it -- didn't mean it's a must-have... How about must apply to resources and should apply to properties?

Disambiguating users by originating domain (a la NT) -- and that's completely separate from HTTP's realm, which attempts to disambiguate subsets of resources access controls apply to.

Can we specify a complete algorithm for composing ACLs in the face of extensibility.

Discussion of how the cube can be sliced: there's the abstract access authorization matrix, which should be sliced into lists attached to each principal, object, or method.

Groups are collections of users

Roles are collections of permissions

Confusion arises because many systems conflate the two

Roles are considered a "should"

It should be easy to block or log ACL management (w/o groveling through XML; easily firewalled might imply new method or headers).

Clarify that the "encryption" discussion is about protecting the ACL as sensitive data -- not to be confused with authentication mechanisms. vague consensus that there should be protection, and it should be acceptable to deny unprotected transactions.

"certificates" are useful for narrowing delegation rights. The mechanism discussed is rather outside the style of access control lists and worries some. Unanimous: DAV is complete without this mechanism.

"predictability" -- much discussion of what static means, what dynamic means, how achievable this is. At the margins, DAV can't be absolutely consistent because it's still built on HTTP and the universe of Web security (payment, rental access, etc) -- still saying nothing about the external world (premises security, sandpaper, etc).

Resolved: Timeout ACLs are out of scope