RE: Raw meeting notes from WebDAV WG meeting

Here are the slides, to go along with the minutes
http://www.sharemation.com/~milele/public/dav/presentations/WebDAV-IETF5
6.ppt

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org 
> [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Jim Whitehead
> Sent: Tuesday, March 18, 2003 6:08 PM
> To: WebDAV
> Subject: Raw meeting notes from WebDAV WG meeting
> 
> 
> 
> 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 Wednesday, 19 March 2003 16:30:28 UTC