DeltaV minutes from IETF-50

Current status

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

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

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.