RE: WebDAV WG minutes

Here's the content of the minutes document (for archival on the mailing
list):

--

Notes for WebDAV WG meeting at IETF 58.  Thanks to Larry Greenfield for
notes/chat transcript.

TOPIC: Agenda bashing
 - no objections

TOPIC: ACL status

 - Security ADs did not approve and did not block.
 - Now in the RFC editor queue.
 - major problem was the unbounded number of rights.
 - security ADs says nothing could be done to make this spec a good spec,
	but weren't willing to make the WG restart.
 - hopefully "application acl workshops" will be held.
 - for future revs, think about "intersection" instead of "union" solutions.

TOPIC: Quota/size properties

Brian Korver
 - draft to let things interoperate with quota implementations.
 - -02 document aligns better with NFS.
 - quota_avail added back in to deal with low disk space condition
 - the thought is that a MAY for including disk space is ok.
 - we could remove from spec and a future application can give disk limits.

Some additional questions on Quota
Q (Reschke): 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)?
A: some memory that WG members had asked for disk limits to be treated as
	quota

Proposal: marshall as separate properties, define distinct
condition codes, so that clients can distinguish both conditions (just like
in
file systems)

Q: (Randy presuhn) Why do you need to know this number?
A: to not attempt operations that would almost assurdly fail.


Suggestion (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.


TOPIC: Redirect draft.

 - issue: Replace MKRESOURCE with MKREDIRECT?
 - issue: allow authoirng 301-type redirects as well as 302-type?
 - issue: How to handle requests that address mutliple resources, including
redirects
 - no comments from attendees.


TOPIC: Interop Report.

 - 4 clients, 6 servers. this is only about 30% of implementors.
 - possible to participate remotely
 - also ongoing interop testing using "always online" test servers
 - Jim Luther @ Apple is maintaing a list of public test accounts


TOPIC: RFC 2518bis issues

Do namespace prefix tags need to be preserved
 - issue is with XML vocabularies that use prefixes in text or attribute
content,
 - such as XSLT or XML Schema
 - "prefix rewriting") would break fragments of these vocabularies appearing
in properties
 -
Requirements for ETag support
 - question for ted: when going to draft standard, how hard do you try to
keep existing implementations compliant?
 - Ted: It's certainly possible that one or more implementations will become
uncompliant.
 - if it changes behavior, then usually you recycle at propose.
 - other things are big changes, too.
 - you can remove features but you cant change features or add features
without recycling at propose.
 - Ted: the standard level isn't a big deal, so don't worry about recycling
at proposed. make the spec as good as possible.

More commentary:
Suggestion (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.

Q (OGeisser): are there any plans for "ptags" = "etags for properties"?
A (Lisa): Yes, or ctags = "ctags for collections": would rather not add
major new design to webdav, just make stronger compliance, simplify
features,
etc.  New features that would be added in new extensions is the thought
here.

(reschke): I certainly dislike the idea of having an RFC2518++ that isn't
supported by Apache.
(Ted): send the source to apache to fix the issue, and that's done.

Issue: Must resources be in collections
 - Consensus is that resources can be standalone.

Issue: Some interest in new writable modification-date property
 - for instance, a backup program could upload stuff to a server and set the
modification-date property from the original.
 - Jim Luther on the filesystem team here at Apple wanted this
property.
 - Changing getlastmodified considered dangerous
 - Note that setting DAV:getlastmodified *back* implies
changing the MIME header last-modified as well, and that may be a bad idea.
 - it could screw up things for intermediaries and caches, unless we
divorced the property value from the header value which might create more
confusion.
 - We may instead want to define a new property that can track modifications
to properties as well (that would resemble more closely a filesystems last
mod date)

TOPIC: PATCH proposal
http://www.sharemation.com/~milele/public/dav/draft-dusseault-http-patch-00.
txt

 - WebDAV use case: would make it easier to make small changes to very large
files.
 - DeltaV use case: small changes to many source files.
 - SIMPLE use case : changing my buddy list or presence document on HTTP
server.
 - Netconf use case: Making changes to large configuration documents.

Q (OGeisser) does the PATCH proposal allow a partial change of a property
value, too (sorry - have not read the proposal)
A: No

Suggestion (Reschke): an alternative would be to model parts of a resource
as indivually addressable sub-resources (with their own URIs)

TOPIC: BIND

Status is at <http://www.webdav.org/bind/bind-issues-list.htm>
Reschke: My understanding is that we want to last-call the spec when the
open issue is resolved.
Lisa has other issues which she will raise on list.

Received on Monday, 17 November 2003 04:27:03 UTC