RE: FW: Meeting Notes for the 50th IETF Proceedings

The IETF rules say that these notes have to be sent to the
minutes in .txt format, so I figured I'd give JimA a hand and
do some reformatting.  Just in case anyone on the mailing list
prefers the .txt format, I'll post it here as well.

Cheers,
Geoff

--------------------------------------------------------------


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.


** 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 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.

Received on Wednesday, 4 April 2001 17:20:20 UTC