Design Team Meeting Minutes

WebDAV Design Team Meeting
November 20-21, 1997
Netscape, Mt. View, California

These are the minutes from the WebDAV Design Team meeeting held Nov. 20-21, 
1997, at the offices of Netscape, in Mountain View, California.  In 
attendance were: Steve Carter, Novell; Asad Faizi, Netscape; Yaron Goland, 
Microsoft; Alex Hopmann, Microsoft; Del Jensen, Novell; Howard Palmer, 
Netscape; Jim Whitehead, U.C. Irvine. Ramanathan Guha, Netscape was present 
for the discussion of RDF.   The meeting was chaired and the minutes were 
recorded by Jim Whitehead.

Access Control Discussion

There was general discussion of access control, which identified several 
key design issues.

Discussion of  Dynamic Inheritance: Do local access control directives or 
inherited access control directives take precedence?  I.e., should the 
security administrator's access control directives take precedence over an 
individual's local access control preferences, determined based on the 
needs of a specific project.  For the local setting of ACLs, there is a 
need to be able to specify which ACLs a particular principal can set.

Can you implement a client that has no knowledge of inheritance, and still 
provide a reasonable experience to the user?  What does the user need to 
know about ACLs?

When a client requests ACL information, does it receive only the local ACL, 
or does it receive the local ACL and all of the inherited ACLs?  General 
agreement: The client probably wants both, in a list where the local ACL 
and inherited ACLs are differentiated.

What happens when, while evaluating an operation, you run off the end of 
the list of ACLs without getting either a grant or deny outcome for that 
operation?  What is the default behavior?  Is it default grant, or default 
deny or default ambiguous?  This issue is specific to a particular design 
(ordered list of ACL/ACE, evaluate in order)

The list of access rights has to be extensible, since there will be 
specialized cases where a new right will make lots of sense.  The challenge 
is to develop a short list of canonical access rights which meets the 97% 
case.

Issue: How to specify a principal in an ACE.  DNS matching? User matching?

Issue: Should a client be able to type in some text to identify a user when 
writing up an ACE.  How does a client enter an ACE? What should a principal 
identifier be?  How should a user discover the principal identifier for a 
particular user on a particular server, so they can enter it when creating 
an ACE?  Should it be text of some form. This issue has been encountered 
before, as there is a similarity to the URN problem.  Distinction between 
completely opaque identifiers and opaque text identifiers.  A client can 
throw up on its screen an opaque text (or Unicode) identifier.  What 
algorithm is used to encode various types of binary identifiers into an 
opaque text identifier.  Need to have some means of discovering what 
schemas for principal identifiers are supported by a particular server. 
 Need to have a list of base schemas which are defined.

Observations:
The attempt to do more sophisticated pattern matching on principles will 
slow down acceptance.

Agreement:
Need to have some form of schema discovery to support access controls (used 
as an extensibility mechanism).

Howard Palmer next led a discussion on his initial ideas for access control 
slides to be presented at the Washington IETF meeting.

Issue: should other access control mechanisms be capable of operating in 
parallel?  If so, how do you determine precedence, and resolve conflicts?

Issue: Since access control looks like it will be a lengthy discussion, 
should some support for access control be provided in the WebDAV protocol 
document? Agreement: for the short-term, implement the URI solution.  In 
this solution, a URI will point to a Web page which will allow  a human 
user to perform access control management.  The idea is to have this be a 
property, and this property will become historical once the access control 
protocol draft is done.

There was inconclusive discussion about whether the access control problem 
is large enough to justify forming a separate working group.

Discussion of the proposal in the access control protocol draft was not 
discussed.

RDF Discussion

Ramanathan Guha gave an overview of the RDF data model, and there was 
discussion on whether the WebDAV property model is consistent with the RDF 
data model.  The consensus reached is the WebDAV property data model is 
consistent with the RDF data model.

There was further discussion on whether the WebDAV protocol specification 
should have a reference to the RDF data model, and a discussion of their 
consistency.  There was discussion on having the RDF group separate out 
just the data model into a separate document, so the data model document 
can be shipped on a separate schedule.   This would allow the WebDAV 
protocol specification to reference a completed document, rather than a 
work-in-progress.  This would allow a statement that the WebDAV properties 
adhere to the RDF data model, independent of the progress on serialization 
details.

However, the group agreed that no changes need to be made in the protocol 
specification right now.

Protocol Draft

There was discussion of a number of specific issues in the protocol draft. 
 The draft under discussion is draft-ietf-webdav-protocol-05.

1. www.ietf.org/standards/dav/

Schema discovery group is being formed, and is setting up a schema 
registration service through IANA for registering schemas.  This will be up 
and running by January, 1998.  We should register the DAV schema using this 
mechanism.

2. GUIDS

The draft currently references a GUID draft by Leach, Salz, but this draft 
is expired.  Paul Leach will re-submit his GUID draft, and ask that it 
become a proposed standard.  Alex Hoppman will develop new language for 
Section 5.4 w.r.t GUIDs.

3. 200/204 Problem

It may be more appropriate to use the 204 response than the 200 response 
when there is no entity body in the response. Jim will consult with Roy and 
change spec. where appropriate to use 204 instead of 200.

4. 421 Destination Locked

421 Destination Locked will now become 421 Locked, and will be used 
consistently throughout the spec. for all locked cases.  Where 409 Conflict 
is now used to indicate a locked condition, 421 will be used instead. Jim 
will do this.

5. Mandatory Header reference in Destroy Header

There is a reference to a "Mandatory" header in the discussion of the 
semantics of the Destroy header, yet Mandatory is not defined in the draft. 
Resolution: remove the Destroy header from the WebDAV draft.  It will need 
to be reintroduced in the versioning draft.

6. Enforce-Live-Properties

Omit tag truly does refer to all properties.  Name of header is then 
inconsistent with this behavior.  Resolution: change name of header to 
"Property-Behavior".  Yaron will do this.

7. External Members Copied on Depth 0 copy

Judith raised the question whether we really want to copy external members 
for a Depth 0 copy.  Consensus: yes, since external members are outside the 
Depth scoping mechanism, and can be viewed as a special type of property. 
No change needed.

8. Discussion of Adding Recursive Functionality to PROPFIND, and reducing 
information returned by INDEX, or eliminating INDEX altogether.

Agreement: PROPFIND will have recursive semantics (this is already in the 
-05 draft).  The INDEX method will be removed from the -06 specification, 
since it is simply a specialized recursive property return method.

9. COPY on a Collection: If the copy fails on an internal member collection 
of a hierarchy, what should happen?

At present, the behavior is to create a new internal collection, and then 
keep going.  Agreement: change this so that the copy will cease copying 
that subtree at the first collection copy error in the tree (internal nodes 
of the tree).  Copy errors at the leaf nodes of the containment tree do not 
cause the copy to quit - copy skips the resource, and moves on.

10. MOVE is an  atomic COPY followed by a DELETE, but COPY for collections 
and DELETE for collections isn't atomic.  This is inconsistent.

The definition of MOVE as a COPY, followed by a DELETE, performed 
atomically, only applies to an individual resource, but not to multiple 
DELETEs.

11. MOVE creates intermediate collections to create a consistent namespace, 
even if there are errors creating intermediate nodes.

There is a problem with the language of this method.  Yaron will change the 
language and will fix the example.

12. What happens if you submit XML elements encoded in UCS-2 using the 
default XML Patch method format?

Add a note concerning this to the specification. Resolution: you SHOULD use 
UTF-8.

13. Should PATCH be moved into a separate specification?

Agreement: Yes, PATCH should be moved into a separate specification. PATCH 
should use the gdiff delta encoding, but gdiff isn't in a stable enough 
form to reference in the WebDAV spec. right now.

14. How do TLS authentication and HTTP authentication interact?

Both authentication credentials are valid.  It is a server policy issue how 
to interpret situation where there are multiple authentication credentials 
available.

Del then led a discussion of email sent to the discussion list.

15. Ordered Collections
Jim will summarize the discussion on ordered collections.  There will be 
discussion on this issue at the Washinton IETF meeting.  Jim Davis will be 
encouraged to develop a draft on ordered collections.

16. PUT Atomicity
Jim will send a post to the HTTP-WG list asking for clarification of 
whether the behavior of PUT is atomic. Hopefully this can be an editorial 
change to HTTP/1.1 specification.

17. PROPPATCH on an empty resource
Need to add language to the specification that defining properties on an 
empty resource creates the resource, and performs the PROPPATCH operation.

18. Netscape method name conflict
Due to conflicts with the Netscape Enterprise server, versions 2 and 3, we 
have decided to change the names of  the following methods:  COPY -> DUP, 
MOVE -> RENAME, LOCK ->RESERVE, UNLOCK -> UNRESERVE.  This change will take 
effect in the -06 specification.

Discussion of Versioning

Schedule goals: develop a design document by the end of January
Aim for having a WG last call in June, 1998.

Yaron brought up the issue of the Rollback header, which is used to control 
visibility of the resource being locked.  Rollback header is submitted with 
a lock request.  Outcome: Yaron will write up an I-D, which will be slated 
for Experimental. Header will be called MS-Rollback.

During discussion of versioning, a set of versioning design principles was 
developed.

Versioning Design Principles:
Separation of display URL from storage URL
Use the RDF data model to model the predecessor/successor relationships in 
a version tree.
Server maintains consistency of RDF data model (the version history graph).
Must be possible to use either the Tip version or any member of a version 
history graph as the operand for versioning operations.
Use collections as they are defined in WebDAV protocol specification.
Clients do not get to suggest where versions are stored.
A version history is a directed acyclic graph.

Creating a new version: can do this by value (send an entity body) or by 
reference (send a URL).

Fist step: map version graphs into RDF data model, complete this by 
mid-January.

*** Meeting Adjourned ***

Received on Wednesday, 26 November 1997 20:33:06 UTC