[03:02:43] --- reschke has joined
[03:02:53] --- reschke has left: Disconnected
[06:16:15] --- reschke has joined
[07:03:13] --- LOGGING STARTED
[07:05:00] --- LOGGING STARTED
[07:07:59] --- LOGGING STARTED
[07:09:21] --- LOGGING STARTED
[07:11:30] --- LOGGING STARTED
[08:34:19] --- reschke has joined
[11:41:39] --- reschke has left
[11:41:54] --- reschke has joined
[12:00:10] --- reschke has left
[12:56:28] --- csharp has joined
[13:10:16] --- reschke has joined
[13:10:54] <csharp> hi julian
[13:11:38] <reschke> Hi.
[13:26:04] --- csharp has left: Disconnected
[13:40:45] --- csharp has joined
[13:42:23] --- ogeisser has joined
[13:42:33] <ogeisser> hello
[13:42:37] <csharp> hiya
[13:43:07] <ogeisser> which time is it in Minneapolis ?
[13:43:59] <csharp> I am in pacific time and it is 11:46 here
[13:44:38] <ogeisser> mmh - what I mean is: how long till the meeting starts?
[13:45:18] <csharp> It was supposed to start at 3?
[13:45:42] <ogeisser> The WEBDAV Working Group will meet on Thursday, November 13, 2003, from 3:30 to 5:30 PM (Afternoon Sessions II).
[13:45:52] <ogeisser> In Minneapolis
[13:46:34] <csharp> I think that if they are on central time that the meeting would start in 1 hour and 40 minutes?
[13:47:20] <ogeisser> ok - i will leave and be back in 1 hour and 40 minutes - cu
[13:47:55] <csharp> bye
[15:18:09] --- Lisa has joined
[15:18:22] <Lisa> Hi Davvers
[15:18:33] <Lisa> Daviants?
[15:18:44] <reschke> good afternoom
[15:18:55] <reschke> s/m/n/
[15:24:41] --- rjs3 has joined
[15:26:43] <ogeisser> rehi
[15:29:32] --- hardie has joined
[15:29:39] --- leg has joined
[15:29:53] <leg> meeting is starting
[15:30:07] <leg> 8 people in the room. 9 people.
[15:30:55] <leg> not objections to the agenda
[15:30:59] <leg> ACL status
[15:31:11] <leg> Security ADs did not approve and did not block. now in the RFC editor queue.
[15:31:33] <leg> major problem was the unbounded number of rights.
[15:31:45] <leg> "ACLs is done but not over with"
[15:32:22] <leg> question: what does "not approve and not block" mean?
[15:32:34] <leg> ted responding...
[15:33:38] <leg> ted says security ADs says nothing could be done to make this spec a good spec, but weren't willing to make the WG restart.
[15:34:42] <leg> no good example of "good acls" to point WG at. hopefully "application acl workshops" will be held.
[15:35:17] <rjs3> that'd be nice to have for imap too ;)
[15:35:49] <leg> for future revs, think about "intersection" instead of "union" solutions.
[15:37:13] <leg> next up: brian korver on quota and size properties
[15:37:45] <leg> draft to let things interoperate with quota implementations.
[15:38:02] <leg> -02 document aligns better with NFS.
[15:38:54] <reschke> (issues re: latest draft summarized in http://lists.w3.org/Archives/Public/w3c-dist-auth/2003OctDec/0140.html)
[15:39:15] <leg> quota_avail added back in to deal with low disk space condition
[15:40:14] <leg> quota_avail definition slide
[15:40:33] <reschke> Q: why are disk limits treated as quota when (a) NFS behaves differently and (b) making a difference could enhance client error handling (such as mapping to error codes in file system drivers)?
[15:40:50] <leg> are you in the room?
[15:40:59] <reschke> (nope)
[15:41:32] <leg> question asked..
[15:41:50] <leg> brian doesn't know.
[15:42:07] <leg> there's a thought that someone asked for disk space to be included in quota calculation.
[15:42:54] <reschke> Proposal: marshall as separate properties, define distinct condition codes, so that clients can distinguish both conditions (just like in file systems)
[15:43:30] <reschke> I think asking for disk limits marshalled as quota makes only sense if the
[15:43:46] --- anewton has joined
[15:43:49] <reschke> ...there's not better way to handle disk limits.
[15:43:53] <leg> randy presuhn: "why do you need to know this number? it's to not attempt operations that would almost assurdly fail."
[15:45:28] <leg> lisa relates: we only had administrative quota (a la idisk); someone asked "what about low disk space"; "we don't want to add more properties"
[15:46:10] <leg> here in the room the thought is that a MAY for including disk space is ok.
[15:46:45] <reschke> Understood. But I think there are good reasons to distinguish between both (for instance, file system mapping
[15:46:47] <leg> or we can remove from spec and a future application can give hard physical limits.
[15:47:12] <reschke> ...clients such as Xythos/OSX/davfs can benefit from knowing why a request failed (quota or space)
[15:47:19] <leg> including available disk space is more useful for applications, perhaps less useful for users.
[15:48:06] <reschke> If we just borrow NFS property definitions, it's cheap to borrow just two more - can be done in the same spec.
[15:48:41] --- hardie has left: Disconnected
[15:49:13] --- mrose has joined
[15:49:25] <leg> eric: disinclined to make more changes to the spec, but if others think there is additional value we can do that.
[15:50:05] --- rjs3 has left: Replaced by new connection
[15:50:24] --- rjs3 has joined
[15:50:30] <reschke> I think making these changes (align even more closely to RFC3530) will make the spec indeed simpler.
[15:51:15] <leg> ted: users probably want the quota more than disk space.
[15:51:27] <reschke> For instance, we may just define a generic mapping of RFC3530 properies to DAV properties, then apply that mapping to the two quota and the two disk space properties defined there.
[15:51:55] <leg> eric: duly noted.
[15:52:01] <leg> next up: redirect draft.
[15:52:14] <leg> lisa presenting.
[15:52:23] <leg> Replace MKRESOURCE with MKREDIRECT?
[15:52:34] <leg> allow authoirng 301-type redirects as well as 302-type?
[15:52:52] <leg> How to handle requests that address mutliple resources, including redirects
[15:52:55] <reschke> redirect issues list: http://greenbytes.de/tech/webdav/draft-ietf-webdav-redirectref-protocol-issues.html
[15:53:11] <leg> 207 may confuse, HTTP/1.1 says requests to redirects MUST result in 3xx status code.
[15:53:28] <leg> no comments.
[15:53:36] <leg> next up: Interop Report.
[15:53:58] <leg> 4 clients, 6 servers. this is only about 30% of implementors.
[15:54:07] <leg> not enough notification time?
[15:54:22] <reschke> (Lisa's slides at: <http://www.sharemation.com/~milele/public/dav/presentations/webdav-wg-ietf58.ppt>)
[15:54:39] <ogeisser> i#m new to interop tests - is it possible to participate remotely ?
[15:54:51] <reschke> note that there's also ongoing interop testing using "always online" test servers
[15:55:13] <ogeisser> julian: where can i find mor infos about this ?
[15:55:21] <reschke> ogeisser: Jim Luther @ Apple is maintaing a list of public test accounts
[15:55:31] <ogeisser> aha - thank you
[15:55:31] <csharp> Jim Luther at Apple maintains the list of clients/servers for the always online testing
[15:55:40] <leg> lisa: it's always possible to participate remotely, but it's hard to coordinate and you can't do performance tests as well.
[15:56:37] <leg> lisa: it's been harder to coordinate clients to hit a particular server at a particular time for the always-on tests, but they work well for the clients.
[15:56:49] <leg> next up: RFC 2518bis issues
[15:56:51] --- rjs3 has left: Replaced by new connection
[15:56:53] <leg> lisa presenting...
[15:57:03] <leg> Do naemspace prefix tags need to be preserved
[15:57:49] <leg> problem with certain W3C features. i'm a little confused by what the issue is here.
[15:58:01] <reschke> issue is with XML vocabularies that use prefixes in text or attribute content, such as XSLT or XML Schema
[15:58:11] <leg> yes
[15:58:28] <leg> "it's all a real pain" and "i sure wish the w3c didn't do this"
[15:58:36] <reschke> Not preserving prefixes (aka "prefix rewriting") would break fragments of these vocabularies appearing in properties
[15:58:45] <reschke> such as XML Schema instance data
[15:58:53] <leg> next buillet: Requirements for ETag support
[15:59:06] <reschke> Yes, that's a separate discussion.
[15:59:40] <reschke> Fact is, this kind of XML exists, and if we say that prefixes do not need to be preserved, we must be aware that this may cause problems.
[15:59:41] <leg> question for ted: when going to draft standard, how hard do you try to keep existing implementations compliant?
[15:59:56] <leg> [sorry, discussion in room is moving to ETag requirements.]
[16:00:12] <reschke> That's different from saying "prefixes are irrelevant, therefore they do not need to be preserved"
[16:00:38] <leg> ted: it's certainly possible that one or more implementations will become uncompliant. usually it's clarifications. if it changes behavior, then usually you recycle at propose.
[16:00:42] <reschke> Etags: concern is to introduce new requirements that aren't met by both MS IIS and Apache mod_dav
[16:01:16] <leg> lisa: other things are big changes, too.
[16:01:35] <leg> ted: you can remove features but you can't change features or add features without recycling at propose.
[16:02:04] <leg> ted: but the standard level isn't a big deal, so don't worry about recycling at proposed. make the spec as good as possible.
[16:02:06] <ogeisser> a little bit off-topic: are there any plans for "ptags" = "etags for properties"?
[16:02:27] <reschke> Lisa: correct, but these are distinct issues. Adding something trivial may be done in mod_dav in just a few days. Changing the whole etag handling however seems like a possibly hard task.
[16:03:17] <reschke> It would be really good if some of the mod_dav maintainers could state whether they are planning to actually meet the stronger etag requirements.
[16:03:25] <leg> or ctags = "ctags for collections". lisa would rather not add major new design to webdav, just make stronger compliance, simplify features, etc.
[16:03:37] <reschke> I certainly dislike the idea of having an RFC2518++ that isn't supported by Apache.
[16:04:02] <leg> adding ctags, ptags, etc. are cool but maybe shouldn't be added to rfc2518bis.
[16:04:13] <ogeisser> why?
[16:04:17] <leg> ted to reschke: send the source to apache to fix the issue, and that's done.
[16:05:08] <leg> ogeisser: new features that would be added in new extensions is the thought here.
[16:05:15] <leg> next bullet.
[16:05:21] <leg> Must resources be in collections
[16:05:40] <reschke> reschke to ted: as far as I understand the code, it's impossible to change (issue: mod_dav assigns only weak etags that get changed to strong etag state only after a short delay, the reason being timestamp precision on the filesystem)
[16:06:24] <reschke> Must resources be in collections: I'm not sure what the issue is. It seems clear to me that they don't need to.
[16:07:15] <ogeisser> reschke: that's my understanding, too
[16:07:15] <leg> i believe lisa's claim is that existing servers require all things to be in collections. there are some collections not inside of parent collections but do not allow resources not inside of collections.
[16:07:22] <reschke> Q: what would be the benefit in stating that? (assuming that we mean "DAV resource").
[16:07:40] --- mrose has left
[16:07:44] <leg> thought here is that standalone webdav resources (not in collections) will be ok for rfc 2518bis.
[16:07:56] <leg> i'll relay the apache implementation ocmment later.
[16:08:11] <leg> next bullet: Some interest in new <b>writable</b> modification-date property
[16:08:20] --- rjs3 has joined
[16:08:20] <ogeisser> what for?
[16:08:22] <leg> with sub bullet: Whether these change on MOVE
[16:08:26] <reschke> Note that ACL defines WebDAV-compliant resources (principals) that my be childs of DAV collections or not.
[16:09:08] <leg> for instance, a backup program could upload stuff to a server and set the modification-date property from the original.
[16:09:19] <ogeisser> mmh, ok
[16:09:21] <reschke> I guess it's up to the server to allow PROPPATCH om DAV.getlastmodified
[16:09:25] <csharp> Jim Luther on the filesystem team here at Apple wanted this property.
[16:10:04] <reschke> Note that setting DAV:getlastmodified *back* implies changing the MIME header last-modified as well, and that may be a bad idea.
[16:10:09] <leg> it could screw up things for intermediaries and caches, and lisa doesn't think it's "wise".
[16:10:59] <leg> lisa: unless we divorced the property value from the header value which might create more confusion.
[16:11:09] <leg> new slide
[16:11:15] <leg> PATCH proposal
[16:11:21] <leg> Lisa's PATCH proposal.
[16:11:21] <reschke> More general issue: DAV:getlastmodified is just the Last-Modified HTTP header mapped to a WebDAV property. We may instead want to define a new property that can track modifications to properties as well (that would resmble more closely a filesystems last mod date)
[16:11:31] --- hardie has joined
[16:12:03] <leg> lisa's reponse: great.
[16:12:08] <leg> back to PATCH.
[16:12:32] <leg> use case for PATCH method for webdav/http would make it easier to make small changes to very large files.
[16:12:43] <leg> DeltaV: small changes to many source files.
[16:13:02] <leg> SIMPLE: changing my buddy list or presence document on HTTP server.
[16:13:33] <csharp> seems like a great idea to me
[16:13:37] <reschke> I think that would be useful. Should be able to refect HTTP GET Range header behaviour (without being limited to that)
[16:13:52] <csharp> truncating a file is something that I *believe* cannot currently be done
[16:13:54] <leg> Netconf use case? Making changes to large configuration documents.
[16:14:12] <ogeisser> does the PATCH proposal allow a partial change of a property value, too (sorry - have not read the proposal)
[16:14:53] <reschke> Side note: an alternative would be to model parts of a resource as indivually addressable sub-resources (with their own URIs)
[16:15:36] <leg> partial change of a property change: currently not in lisa's prposal.
[16:15:50] <leg> new slide: example with application/gdiff type patch.
[16:16:15] <leg> new slide: example with xml/xpath patch
[16:16:33] <leg> server can advertise what diff formats it supports.
[16:16:53] <leg> lisa has submitted to the repository, will show up soon.
[16:17:11] <Lisa> It's on my sharemation account.
[16:17:34] <leg> new slide: this jabber discussion.
[16:17:49] <leg> question: anything else to discuss?
[16:18:35] <reschke> (PATCH proposal at <http://www.sharemation.com/~milele/public/dav/draft-dusseault-http-patch-00.txt>)
[16:19:13] <reschke> BIND spec?
[16:20:04] <Lisa> what about bind?
[16:20:12] <Lisa> I didn't get any status report
[16:20:15] <Lisa> in time for the agenda
[16:20:48] <reschke> Status is at <http://www.webdav.org/bind/bind-issues-list.htm> and hasn't changed since meeting. Only one open issue (bind loop error marshalling) (it's on the agenda, though)
[16:21:48] <reschke> My understanding is that we want to last-call the spec when the open issue is resolved.
[16:22:48] <leg> complaint about fixed font size on the issue list
[16:23:14] <leg> lisa will go argue about other issues.
[16:23:45] <leg> and we're done
[16:23:47] --- anewton has left
[16:24:00] <hardie> see you later
[16:24:02] --- hardie has left
[16:25:30] --- Lisa has left: Disconnected
[16:25:39] <csharp> later
[16:25:40] --- csharp has left
[16:26:35] <ogeisser> sorry - i was away - is the meeting over?
[16:27:10] <reschke> Yes.
[16:28:26] --- reschke has left
[16:31:03] <ogeisser> Dann gute Nacht nach M√ľnster ;-)
[16:31:13] --- rjs3 has left: Disconnected
[16:31:31] --- ogeisser has left
[16:56:43] --- Lisa has joined
[16:57:04] --- leg has left: Replaced by new connection
[16:57:35] --- mrose has joined
[16:59:08] --- Lisa has left
[17:03:03] --- user has joined
[17:04:31] --- user has left
[17:10:09] --- mrose has left
[18:37:58] --- csharp has joined
[18:38:04] --- csharp has left: Disconnected