- From: Jim Whitehead <ejw@cse.ucsc.edu>
- Date: Tue, 18 Mar 2003 18:08:13 -0800
- To: "WebDAV" <w3c-dist-auth@w3.org>
WebDAV Working Group Meeting San Francisco IETF, March 18 Co-Chairs: Lisa Dusseault, Jim Whitehead Notetaker: Jim Whitehead ----------- A meeting of the IETF WebDAV Working Group was held at IETF-56, held in San Francisco. Approximately 25 people attended the meeting over its duration. Lisa Dusseault began by going over the agenda. She noted that DASL discussion was dropped since there were not enough people present to discuss the issues in depth. Lisa then led a discussion of 2518bis. * Discussion of locking issues in 2518bis. Slide "Agreed text so far" - Discussion of the content type of the resource created by a LOCK when the content type doesn't exist. One thought: pick one type. Another choice: do whatever a server does when you send a PUT with no Content-Type header, and a non-empty body. Rough consensus: be silent on the issue (most likely defaulting to what happens when a PUT with no Content-Type header). * Discussion of the definition of a collection. Should we use binding terminology in 2518bis, or keep internal member terminology. Tempest in a teakettle over internal member terminology. In the end, decided to keep using internal member term. * Discussion of "First problem" slide. What should be the behavior on a LOCK on an indirectly locked resource? Should the lock remove the entire depth lock, or should it be redirected, or should it fail? Rough consensus for failure, error code to be determined later. * Discussion of "Second problem" slide. When an If header is submitted against a depth locked resource, must a client use the lockroot URL, or is any URL in the locked tree OK? If the untagged If header's referred to resource is the same as the request URL, will this break any existing clients? One approach is to better identify interoperability failures in lock token handling. Need to make the text in the specification in 2518bis on the If header more clear. No consensus. Lisa will write a message to the mailing list summarizing both sides of the issue, and explicitly solicit feedback from Dan Brotsky, Julian Reschke, and Max Dunn on this, as well as generally from the mailing list. * Discussion of "what is locked" draft. Discussed effect of locks on live properties. Agreement of lock affecting dead properties. Also tentative agreement that a lock should affect all PROPPATCH operations on all properties, live and dead. Briefly noted that locks do not prevent live properties from updating their values (e.g., getcontentlength updating after a PUT -- this is OK, even when the resource is locked). * The "Last Piece" slide. No disagreement. Refined lock-root to "lock root URL" to avoid ambiguity over what "mapping" means. * "Allprop replacement proposal." Agreement in the room that the proposal listed on the slide was fine. Some concern over interoperability implications of adding new XML tag into PROPFIND prop requests to ask for all dead properties. * Discussion on whether there should be an additional 4xx or 5xx status code for multistatus cases. Several viewpoints. Aesthetic: 207 is for complete success, while a 207 can have 4xx inside it, so this is a contradiction. Interoperability: clients may not know how to correctly handle a new 4xx that expresses a multistatus case, or only use the new 4xx for cases where it is OK for the client to treat the entire response as a failure. Functional: some tools may not understand WebDAV, but still come into contact with 207 responses. An example is an HTTP logging tool that might be trying to tally success and failure, and won't properly handle 207. Rough consensus to *not* make any changes to 2518bis. Keep current semantics of 207, do not add new status codes. Main motivation is to not break current implementations, or add a new status code that might cause interoperability problems. * Discussion of entity tags, and support level. Not strong support for moving to SHOULD. Roy Fielding argued that there is already strong motivation for supporting entity tags, since they provide significant caching benefits. But, there is experience that many DAV servers do not support entity tags at all, and hence interoperability might benefit from language in the specification recommending, or giving a SHOULD level requirement on support of entity tags. Some agreement that use of entity tags should be RECOMMENDED (defined in 2119 to be the same strength as SHOULD) on all PUTable resources. Also makes sense to add an implementation note providing rationale for why entity tags are a good thing to implement. ----------- Brian Korver, discussion of Quota specification. Brian began with an overview of the latest draft of the quota specification. Some questions on the semantics of the new properties. Brian mentioned that the definitions were taken from the definition of the NSF quota system. The quota properties are strictly live. Quotas are defined on resources -- there is no mechanism to ask about the quota for a particular user. People who volunteered to read and review the specification. Jim Whitehead, a grad. student of Jim's. Jim stated that the specification is close to WG last call, look for this in a few months, after a few people in the WG have read and provided feedback on the quota specification. ----------- Brief discussion of the ordering specification. Geoff Clemm overviewed recent changes. Jim asked whether there were any objections to moving this to a working group last call. None surfaced. ----------- Geoff Clemm then led discussion on the binding protocol. Geoff began with a brief overview of the binding protocol. Discussion of copy language in the binding specification. No objections on the language in the specification. Some discussion on Copy, Depth infinity case. *** Need to add description of the behavior of Copy, Depth infinity case, since it's not currently covered in the specification. Discussion of delete and bindings. Will take this to the list -- raised the issue. Binding specification is at a point where, if you have issues with the specification, they should be surfaced now. Will work to resolve open issues soon, want to drive specification to closure in the near future. --------- Geoff then led a brief discussion of the ACL protocol. Brief review of IESG feedback on the recent last call. There is a new draft in preparation, and will submit this as an I-D in the near future. Like binding specification, want to quickly move to closure on this. --------- *** End of Meeting ***
Received on Tuesday, 18 March 2003 21:11:39 UTC