WebDAV: Agenda

Find someone to record minutes Open issues in the ACL specification Reviving DASL Improved status reporting (Dusseault) Moving RFC 2518 to Draft status

Process for moving forward Discussion of issues list items

Open Issues in ACL Specification

Null resources and ACLs Does a null resource, and a lock null resource have an

ACL? Is it possible to use ldap scheme URLs for

principal identifiers? Either ldap-URL property, or not allowed

ACL properties returned by a PROPFIND allprop None, some, all? MAY/SHOULD/MUST? View on list: MUST NOT return any ACL properties on

PROPFIND allprop (room agrees)

ACLs

What URIs schemes should be allowed for identifying principals? Limited set http(s), ldap(s) http(s) defined in ACL spec. – others must be

explicitly defined by an additional specification Or, a URL that identifies a “WebDAV” principal resource

Anything (no constraints) closest to sense ot the room Anything, but servers

SHOULD use http(s), which is a privileged scheme that points to resources that SHOULD have additional properties

ACLs (2)

Should principal resources have an optional property “alternateURL” that can point off to, e.g., an LDAP accessible network resource? Sense of the room is, yes. Need to provide information in the specification on

how, exactly, a client might make use of this feature to provide a richer user experience.

Document likely URL schemes (ldap, mailto) that may appear in here.

ACLs (2.5)

Provisionally (subject to list discussion), can eliminate the authentication-id property. The AlternateURL property can cover many of the use cases envisioned for authentication-id. Or, make sure that the use of each principal

property (Displayname, authentication-id, etc.) is known, agreed to, and considered important enough to justify the property.

ACL (3)

Isprincipal property Use case: clients can use this property to decide how

to display the resource in a UI (I.e., choice of icon for the principal resource)

Sense of the room (with some objection) Leave as isprincipal property

Put type info into resourcetype property Get rid of this altogether Not super strong sentiment either way.

Also need to add info to RFC 2518 for what to put into resourcetype when adding interfaces/new typed objects – record interfaces in resourcetype

ACL (4)

Add a note that certain methods (GET, PUT, etc.) are intentionally left undefined on principal resources

PROPFIND allprop

Should PROPFIND allprop be the default behavior of PROPFIND Sense of the room: move away from this

Should PROPFIND allprop be eliminated alltogether? Deprecate this behavior, then hopefully eliminate this

when going to Standard Long-term process (~10 years) In RFC 2518 revision, need to document the reasons for why

this is being deprecated (significant performance issues) Only return dead properties, not live ones.

Reviving DASL DASL specification has been dormant for some time As Chair, I would like feedback on:

Who is interested in seeing this specification completed? A few hands

When (relative to other WebDAV and DeltaV activities) this specification should be completed?

Look at synergy/interactions between DASL and XML-Query – give XML-Query info that DASL exists, should be part of their design space.

Sentiment that, since it is the same group of people working on DAV/DeltaV specifications, DASL should remain dormant

Who is willing to work on this specification? Move existing DASL specification to Informational/Experimental

– add note that Xythos has implemented? Sense of the room

Moving RFC 2518 to Draft

Four-part process: Resolve Issues List items on mailing list

Goal: handle 2 a week Document solutions with pros/cons

Hold face-to-face interoperability bake-off Flush out new issues Develop test plan document on mailing list Aim for late May/June

Moving RFC 2518 to Draft

Process (cont’d) Develop an online form to gather initial

implementation and testing data Used successfully for HTTP/1.1

Create a farm of significant server implementations for ongoing interop testing

I can host and administer machines at UC Santa Cruz (on the open Internet), but I cannot afford the machines/software

Donations needed