DeltaV minutes from IETF-50

Current status

• Have held multiple WG last calls
• Appears to be consensus on features, but not on packaging/grouping
• Target one more draft before submission to AD

Have talked it over with ADs to see what kind of standard they need to meet before submitting draft to AD; Patrik said it's really down to whether the chair thinks there's consensus. If the AD doesn't find any omissions/flaws, then they'll issue the IESG Last Call. Patrik has already given one approving comment on the doc (he likes server-side workspaces), suggesting that he's been keeping track of deltav well enough that he's probably already spotted major gotchas that might hold it up.

Yesterday's design meeting

• Propose deferring variants
• Propose packages
  • Defined sets of functionality
  • Protocol still reports "features" (a.k.a. options)
  • Labels separate
  • Update separate -- plays against some advanced features

Defer variants; if make it a separate milestone, with a separate design team, might be able to get a new set of people interested.

Packages wouldn't actually change the protocol; but it would say that sets of features go together; if you implement A, you MUST implement B and C. Reduces the combinatorial explosion, helps QA and interop testing. Four proposed packages: Base, File Versioning, Client CM, Server CM. Will have to be hashed out on the list, of course. Issues: should that be "SHOULD implement B and C"; how does the server advertise which packages it support? Larry pointing out that, historically, one thing the IETF doesn't do well is protocols with a lot of independent options; packaging the options like this improves interop a lot.

Mark: that you don't need any of these packages to implement versioning; you could just do automatic versioning, which is in the core. Says we should have a package for the core, so that we could have simple, noninteractive clients. Lisa: an autoversioning client could run against a Base server. Mark: core is "sufficient to be deltav compliant", so it should be permitted. Larry: the smaller subsets are interesting; leaning towards permitting a Core package. Geoff: question is, is the cost of adding checkout and fork control, to be Base, is high enough to deter an implementor from going to Base. JimW: probably not; it's probably under 1000 lines of code. Geoff: right, because autoversioning has to do that checkout anyway, even if it doesn't expose it via deltav. Larry: if all packages have checkout & fork control (proposed definitions do), then why not redefine core to include them, and drop the Base package? Geoff: some people he knows want to expose "core" as a feature, which can advertised. Knows one server for whom it is very important to be core-only. Larry: but is it useful to any client? Geoff: that server does not want to allow non-automatic versioning. Chris trying to get the sense of the room. Larry: what kind of difference would this make to a client? Lisa: not much; but it could well make a big difference for some servers. [...] Geoff: bundling the base features into core gives us less flexibility later; we wouldn't be able to fix it later. Eric: some clients will be perfectly happy to deal with core-level servers. Larry: leaving them separate features is fine with him, but telling implementors it's OK to leave them out.

Separate thread: Update and Label are not in any of the packages; they're to be advertised separately. Geoff: they're not really orthogonal, though; they'd harm Client CM and Server CM. JimW: maybe {Client, Server} CM should imply "MUST NOT support Update, Label". Eric: Label might be harmless, actually. (Larry asking, and Geoff explaining, why Update is harmful.) Eric: so, should File Versioning imply Update? Chris: there are backends where File Versioning would be possible, but Update very difficult. Larry: get rid of Update, maybe? Geoff: let's take it to the list; its defenders aren't here. Larry: so what was it for? Geoff: well, it was needed back before we added some of the more advanced CM capabilities; it might not be needed any more.

Should we cut Label? John Stracke: without Label, it's going to be pretty hard to build on top of CVS, which is important to a lot of people, esp. open-source projects. Discussion over what to do; we might be able to define a simpler degree of CM that CVS could do. One thing that makes Label complex is the Label: header (interacts with GET and PROPFIND; has to be internationalized specially); but maybe we could cut that. Discussion.

Sense of the room: remove the Label: header; possibly remove Update.

JimW: could the simplified Label be rolled into any of these? Geoff: Certainly into {Client, Server} CM.

Open Issues

• Should COPY of collections delete destination elements not in source? That's what 2518 says, but that's not what people expect, and not what filesystems actually implement (they merge into the existing collection). Define a header to request the merge behavior, or update 2518? Larry: if we update 2518, it should be in a separate doc. JimW: the header option is what an early WebDAV draft did, and it succumbed to optionitis. But there might be clients that depend on the current behavior. Action item: JimW will follow up on revving 2518.
• Should we declare that no versioning properties are returned by allprop? JimW: why? Geoff: so that servers can avoid the cost of computing them, particularly since most clients currently doing allprop are not version-aware and won't be able to use the versioning properties. (Side thread about deprecating allprop altogether. The natural issues.) Discussion: what level should this requirement be? Chris: some servers will find it easier to send everything (for one reason or another), and they shouldn't be required to filter. Larry: how is filtering going to be more expensive than generating & sending the XML? ...Chris recording: sense of room: SHOULD NOT, with explanation.
• Should the checkin on unlock create a new version if the resource has not been changed while it was locked? Geoff: the spec for autoversioning says that checkout occurs on update, but not on lock. Chris: let's make it optional, for stores that automatically check out on lock. Geoff: but what if you do a depth lock, just to modify a single resource? It would be really inefficient. Also, clients need predictable behavior. Chris recording: sense of the room: no, because the checkout doesn't occur until a modification is made.
• Add UNVERSION-CONTROL request? JimW: just copy it to a non-version-controlled part of the namespace. Chris: but this is something that'd be done in situ. Lisa: this will destroy too much information. JimW: do you really want to add this new feature right when we're trying to finish up? Chris: somebody asked for it; we should address it. Geoff: yes, we're addressing it; but its utility is so low that it's below the bar for now. Larry: so what was the actual problem to be solved? Lisa: I want a way to take a versioned resource and make it non-versioned. Larry: what's wrong with copying it away and then moving it back? Lisa: it's not in situ, so it doesn't get logged properly. But...it's a reasonable workaround; can we document it? Chris recording: sense of the room: document the workaround.
• Should we get rid of DAV:version-set property of a version history resource? Chris: why? Lisa had pointed out that there were too many ways to get at the version history; thought this one was one we could get rid of; but maybe a different one would be better. Discussion; it comes out that there are only two ways to get the entire history: version-set and a report. Lisa had thought that the predecessor/successor properties had been "all predecessors/all successors". Chris recording: sense of the room: clarify that pred/succ properties are immediate only, maybe add an implementation note for clients on the best way to get history, explain that the different methods are equiv.
• Should the DAV:version-controlled-configuration be on all members of a baseline-controlled collection? Geoff explaining: version-controlled-configuration is the property of a baseline-controlled collection that lets you create new baselines. It's currently on the root; Greg Stein wanted to be able to use it on any member. Chris: was there any dissent when it came upon the list? Geoff: no. Chris: any objection here? No. Chris recording: sense of the room: no objections, but no strong support, either.
• Should the URLs in the DAV:compare-baseline report be version URLs or URLs from the DAV:baseline-collections of the baselines being compared? Geoff explaining. Geoff: Pros and cons of the two approaches are incredibly obscure; current way (version URLs) is a little bit simpler, since there's only a single space of version URLs, which makes them easier to compare. Chris: anybody here have an opinion? JimW: better to return the more canonical URL (version URL). Eric and ? agree; Chris recording that as sense of the room.
• Add a DAV:error node above the 403/409 XML elements? Basically, it makes the DTD easier to write, by isolating all the places where there might be 500 possible errors to specify. Sense of the room: no objections, some limited support, a request to unify with the advanced status reporting stuff.
• Should we create an appendix with all the DTDs? Maybe XML Schema? It's being voted on now, and the vote should take about a month. (JimW: and if Tim B-L vetoes it six months later?) Sense of the room: wait for Schema; create an appendix with schemas; if Schema isn't approved in time, we make the appendix non-normative.

Lisa bringing up a new issue on "version history resource": the introductory paragraph lists some things it can be used for, but doesn't explain how. Geoff explaining; they'll put it in the draft. Also noting that the VHR is a good place to put global (cross-version) properties of a resource.