WEBDAV working group meeting minutes

WEBDAV working group meeting minutes
Lisa Dusseault, acting WG chair
Dec 13, 2000 3:30-5:00 PM, San Diego
Notes taken by Larry Masinter

Agenda:

25 min: improved status reporting (Lisa)
50 minutes: Open issues & review of Access control
40 minutes: DeltaV report on things of general interest

Advanced Status Reporting
-------------------------

presentation by Lisa Dusseault [see separate posting to list
for contents of presentation]

The group discussed 
 (1) is there a problem with adding bodies to responses?
     Sense of the group was probably not, since IIS5 and apache 
     already do.
     Sense of the group was also that clients should advertise
     their support for advanced status reporting so that server
     can be sure not to send back unwanted information.
 (2) A discussion of whether the XML response should replace
    HTML bodies or be added to it
    To be taken to list.
 (3) response-detail could be added to 207 Multi-status body
 (4) add language tag to <user-text> was agreed to be necessary
 (5) discussion of registry of message codes & tags, and
     whether there's a registry, what clients that don't
     understand details could do besides presenting user
     text.
 (6) consortia could get together and define user tags
 (7) syntax of lang tag is wrong in example
 (8) suggestion to use "application/xml" in the examples
    instead of "text/xml"
    sense of the group _seemed_ to be to continue in the model 
    established by webDAV (text/xml) but further comments welcome
 (9) Some servers translate status codes to HTML. 
    Roy suggested that HTML could be augmented by adding an 
    XML island inside the html.
    On the other hand, Sean pointed out, it's not trivial to 
    locate an xml island within HTML.
    Lisa pointed out that if clients can ask for advanced error
    reporting rather than the default, they likely prefer straight
    HTML and will construct their own presentation therefrom.
 (10) 207 gets used for a wide variety of things
     latest proposal adds to 207
 (11) Whether status-codes should be marked with error-level, e.g.
    fatal vs. warning vs. informational
    Group consensus: no, because such information is already in the
    error code used in the header of the response (100-level 
    informational, 200-level success at least partial, others are
    probably fatal)

ACL Open Issues & Review
------------------------

Led by Eric Sedlar, Oracle

First gathered an issue list, then tackled issues one by one as
follows:

Authentication ID and general use thereof
 - Could we use the "Authentication ID" as principle for dealing
   with locking & discovery?
   Response: write a draft. Nobody saw any reason why one coudln't
    reuse "Principle URL"  (but don't use authentication ID. It's 
    a common piece of information, a GUI might throw it up in a 
    common way.  However, it's outside the scope of ACL draft.
    * Question about why have Authentication ID at all

Principle collection set as a new property
 - Why have it? Answer: the principle URLs will live in a
     certain location, so it might be useful way of dealing
     with users. Discussion about whether WebDAV is being used
     for LDAP. Presumption that the 'principle collection'
     could be used to find users who could be associated.
     Hint to browser about which set of principals that might
     be useful to set in an ACL. 
 - Clarified that there can be more than one such principle
     collection set. 
 - Clarified that the URLs in this could be LDAP URLs.
 - The "principal resources" in the principle collection set
     might allow propfind or might not,
     so sometimes principal is just a URI and sometimes it
     has properties associated with it.  At any rate it's 
     intended to be read-only for the purposes of this draft.
 - DAV:owner is already defined
 - Proposed: marshal principal-collection-set via OPTIONS
 - Principle usage should be consistent (hrefs vs. a principal
   element & subelement

OPTIONS usage w/ACLs (brought up by Barry Lind)
 - Currently draft: Read priv does not control OPTIONS method
 - Native web servers don't do this: OPTIONS
 - Proposed to strike requirement that READ doesn't control OPTIONS
 - Proposed: <dav:read> should be able to cover OPTIONS

Matching current user with a principal
   Anne raised issue on section 5.4.1. Must supply unique ID...?
   Text may need to be clarified.

Standard ACL privs
 - Should <readacl> apply to <current-user-priv set>?
 - Access to ACL property vs. current user priv sites: 
  (current user privileges lists the privilegs I am currently
   granted on the resource) Access to entire ACL is different 
   than "what I can do". It's likely a calculated property.
 - Not enough uniformity to make this a standard?
 - Maybe we should specify these separate operations, not 
   both gated by <readacl> right?
 - Or should access to another user's privileges on a 
   resource be governed by a separate privilege instead?
 - <dav:readacl> only applies to ACL property (not
     current-user-priv-set).
 - Will be moved to list.

Priv extensibility
 - Anne asked since Read & readacl are separate, but maybe I 
    could define something else entirely?  What's the point
    of having a standard list of privileges if some of them 
    don't have to be supported?
 - Eric explained, a conforming application will have to support 
    all of these privileges, but some may be abstract.
 - The client can discover which privileges are abstract
    by querying the server for the privilege tree.  
 - A priv that's abstract is one that can't be sent by client. 
    Abstract is just a way of saying that you
    can't set it with that. 
 - Sean pointed out that the client will always have to
    parse the privilege tree in order to parse ACLs. 
    This changes how you're going to be thinking about things,
    it might affect client GUI design. 
 - Abstract is useful for clients for only
    this... 
 - Geoff Clemm is convinced of something by this discussion.
 - Eric promised to summarize on list.

Getting <current-user-priv-set> for users other than current user?
 - Of limited usefulness? Admins can already look at the ACLs.
 - Maybe this would be useful, but not useful enough.
 - Common servers don't let you do this.
 - This is hard to implement, even current-user-priv-set.
    

ACL semantics (or, should we have a UNIX-style token)
 - currently have tokens to inform client that the max number
   of ACEs the server supports is 3.  Currently draft also has
   tokens to inform client what order they must be in.  However,
   there aren't enough tokens, or of enough flexibility, to 
   make client understand the limited UNIX-style permission set
   of rwx (read/write/execute) for self, group and public.  
 - We could have tokens that indicate the ACL can only name 
   1 group and 1 user. 
 - Or, we could have a token that basically says "UNIX-style".
   If we did this, where do we stop? A token for every 
   unique ACL system?
 - Geoff suggested rather that there were a set of common 
   constraints that you might expect several varieties of ACL
   systems to have.  
 - Needs further discussion, but general feeling seemed to be 
   to stick with the "constraints" tokens rather than move to
   "platforms" tokens.
    
Separate priv. for write-owner and write-ACL
  [Does somebody remember how this turned out?]

Properties vs. Methods
 - Discussion at last webdav meeting seemed to end with the 
   ACL property would be set with a custom method, but read
   with PROPFIND.  This was a compromise to make everyone shut 
   up. 
 - Why would one want to set ACLs via a proppatch since it's  
   less flexible than a custom method?
 - Proxy support/blocking arguments ruled out of scope by Lisa.
 - Existing DAV APIs use PROPPATCH. Much easier for a client
   to support a new standard property with PROPFIND and PROPPATCH
   than to support a custom method.
 - Why not do both? Why not allow PROPPATCH? Argument for
     method... could introduce 'update' part of property method.
 - Against using properties: clients that want to do caching
       of property values could screw up with live properties
 - Round-trip argument was made for read. Two round-trips 
   (or more)in order to get both live properties and dead
   properties seemd pointless.
 - Also it's very handy to get live properties for many resources
   using tree PROPFIND.
 - But setting properties is still hard. So ACL so batch
 - Jim pointed out that Versioning on/off is done with a method 
   because it's very hard to make something versioned and at the
   same time (due to atomic nature of PROPPATCH) make other 
   property changes.
 - Lisa suggested that the transactability argument is bogus,
   because one could always just specify that certain live  
   properties could be specified as "must be proppatched
       alone", and this would have the same properties.

 - In other situations, trying to do something, would
       put burden on server. Lisa questions whether that's
       what clients want.
     Client would have to know about updating access control
       entry.
 - Pointed out that updating live properties has side effects,
   whereas proppatching dead properties doesn't, but the client
   can't tell the difference between having set a live property
   and a dead one.
 - Might want to stick with current proposal, but wait for 
      implementation experience to decide whether writing
      properties is good.
 - As a server implementor, rely on APIs.

Roy: no 'resource' model for ACLs.  Resources & properties.
   ACLs are like properties, but they're not.
   Properties could be resources too, handled with the same
   methods, but they're not.

The name "right" vs. "privilege" & "permission"
   will be discussed offline

"DeltaV report on things of general interest,"
---------------------------------------------

Geoff Clemm, Jim Amsden

(1) "Comment" and "creator display name" properties have been
   added in DeltaV
   
(2) "Update: yes" vs. "Overwrite: yes" vs. "Overwrite: update"
    Propose modification to 2582, versioning protocol
    define Update: T, replace overwrite

(3)  New response bodies on 403 and 409 

(4) Options request now takes a body: Roy pointed out it's 
   supposed to.

(5)  Report method: already discussed
     Report functionality: intent was rather than using POST,
     have a set of requests that are required to be read-only,
     (don't update visible server), but unlike PROPFIND
     but rather have done parameterized PROPFIND: ask the
     server to agregate a bunch of information...
     Not a DAV resource?
     Squeeze into parameter string? POST?

Received on Friday, 15 December 2000 22:36:38 UTC