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 Tuesday, 18 March 2003 21:11:39 UTC