OSAF, Chandler, WebDAV, CAP, CalDAV

1
OSAF, Chandler, WebDAV, CAP, CalDAV

• Lisa Dusseault
• Open Source Application Foundation

2
Topics

• My background
• OSAF in brief
• Chandler
• Product Vision
• Protocol requirements
• WebDAV introduction
• Properties
• Distributed Authoring
• Advanced features
• CalDAV architecture

3
My background

• IETF
• Chair of WebDAV, XMPP, IMAPEXT WGs
• Participant in CalSch, HTTP, others
• Microsoft Exchange PM
• Calendaring standard architect
• Content indexing
• IRC, instant messaging
• WebDAV
• Xythos Director of Development
• Massively scalable WebDAV server
• OSAF

4
OSAF
Create and gain wide adoption of Open Source
application software of uncompromising quality.

• Founded in 2001 by Mitch Kapor as non-profit
• Currently 20 people (mostly developers)
• Volunteer assistance encouraged

5
Chandler Vision

• New model for personal information organization
• Combine email, tasks, contacts and events
• Easier to clear the table and focus
• Extensible, customizable
• User defines and bookmarks views very easily
• User adds important metadata fields
• 3rd-party plug-ins or parcels
• Share!

6
(No Transcript)
7
(No Transcript)
8
(No Transcript)
9
Traditional PIM
10
Mixed Collections
11
Chandler Protocol Requirements
12
Sharing Functional Requirements

• Synchronize Calendars
• View somebody elses calendar offline
• Add events to shared calendars
• Discuss availability
• Share Views
• Collections of mixed items
• Sorting, columns, other details of view also
• Share/synchronize Contacts, tasks, email
• Sharing circle

13
Sharing Abstract Requirements

• Mutual authentication
• Access control / multiple authors
• Data browsing
• Data synchronization
• Search
• Notifications?
• IM?
• Locate peers dynamically?

14
Existing Standards
Requirement Standards Others
Data browse/synch HTTP/WebDAV, NFS CIFS
Search WebDAV
Access Control WebDAV, NFS CIFS
Locate peers Zeroconf JXTA
Notifications XMPP (Jabber), SIP
Mutual P2P Authentication XMPP PKI
IM XMPP, SIMPLE
15
Modular Protocol Composition
Event server
URLs
MIME
WebDAV
XMPP
SASL
LDAP
SSL
PKI
Directory
16
Silo Protocol Design
CAP
NNTP
IMAP
HTTP

• authenticate
• sessions
• browse
• synch
• acl

• authenticate
• sessions
• browse
• synch

• authenticate
• sessions
• browse
• synch
• acl

• authenticate
• sessions
• browse
• synch
• acl

calendar
newsgrp
folder
directory
event
post
msg
resource
TCP
17
Chandler 1.0 Sharing

• IMAP/POP3/SMTP support for doing mail
• Propose HTTP/WebDAV for sharing
• Between Chandler peers and publish to server
• Browsing, search and synchronization
• To share contacts, tasks, email, calendar data
• To share Chandler views (heterogeneous)
• Use other standards for other pieces
• Possibly PKI for sharing circle trust
  relationships
• Possibly XMPP for chat, peer relationship, event
  notifications

18
Why OSAF Likes WebDAV

• Solves repository access requirements
• Browse, search, synchronize
• Multiple authors (ACL, locking, versioning)
• Provides additional benefits
• HTTP base provides URLs, libraries, fast
  development, simple clients, and extensible
  protocol
• Clear data model for any application semantics
• Properties
• Collections and resources
• Synchronization
• Proven, deployed, open technology

19
WebDAV Topics

• Introduction goals, interoperability, model
• HTTP
• Synchronization via ETags
• WebDAV
• Properties
• Distributed Authoring
• Access Control
• DeltaV

20
WebDAV Goals

• Extend HTTP, preserving semantics
• Edit Web pages
• Use any authoring tool
• Use native URLs for in-place authoring
• Enable applications
• Any document-plus-metadata application
• Clear extensible data model
• Web File System

21
Interoperability
Web Browsers
Web servers
Productivity Applications
Archives

• MS Office
• Adobe tools

WebDAV
Publishing
Document Management
File Explorers
Site and Content Management
Email
22
File system view
23
Workflow model
24
Usage examples

• MS Office/Adobe authoring
• Apache, IIS 5 Web site authoring
• Exchange 2000 email/calendaring
• Apple iCal
• Mac OS/X publish to Web servers
• Xythos WFS file sharing
• Chubb underwriter repository
• Pacific National Labs chemistry repository
• Subversion source control repository
• Excosoft, Interwoven, Vignette, Documentum
  Content management

25
Data model
A collection
http//example.com/hr/
A resource
http//example.com/hr/index.html
A sub-collection
http//example.com/hr/ergonomics/
http//example.com/hr/ergnomics/posture.doc
26
HTTP Model

• Data Model Resources, entities
• Communication model request/response
• Address model
• A URL points to a resource

27
HTTP Features

• Methods
• GET, PUT, DELETE
• POST
• HEAD, TRACE
• ETags
• Intermediary support

28
ETags

• Resources have ETags
• Chosen/published by server
• Remembered by caches

/folder
Cache
doc1.txt
etag1284467
etag1284458
doc2.txt
doc1.txt
doc2.txt
etag1284467
etag8255591
Need to GET
29
Synchronization

• HTTP only
• GET ltresource-urlgt HTTP 1.1
• If-Match etag1088ae32
• Must remember every resource
• Still -- it works

30
Performance

• HTTP designed for low latency
• Size of requests just not an issue
• Pipelining may be important in some applications

31
WebDAV Focus

• URLs, MOVE, COPY, MKCOL
• Properties
• Locks
• Access Control
• DeltaV

32
How WebDAV affects URLs

• MOVE, COPY
• BIND, UNBIND --gt see bindings
• Collection membership
• Can list children of /specs
• Address is determined by parent(s)

33
Properties

• Expose HTTP data in listings
• For each resource in collection etag,
  last-modified, etc
• Expose WebDAV information
• Is this a collection
• Expose custom data
• Invoice , customer ID
• Picture size, date of photo
• To addresses, from address, date received

34
Properties

• PROPFIND
• Get properties for a single resource
• Get properties for all resources inside a
  collection (direct children or recursive)
• Specific list of properties or names of all
  properties
• PROPPATCH
• Operates only on single resource
• Set property values
• Create and delete dead properties

35
Live vs. Dead properties

• Live properties server generates, enforces,
  watches or
• getETag, resourceType
• Dead properties client has complete control
• invoiceID, customerID, description
• Live properties are frequently protected dead
  properties all fall under same access control

36
Examples Directory listing

• ltmultistatusgt
• ltresponsegt
• lthrefgtURL for /specslt/hrefgt
• ltpropstatgtDetails of /specslt/propstatgt
• lt/responsegt
• ltresponsegt
• lthrefgtURL for doc1lt/hrefgt
• ltpropstatgtDetails of doc1lt/propstatgt
• lt/responsegt
• ltresponsegt
• lthrefgtURL for doc2lt/hrefgt
• ltpropstatgtDetails of doc2lt/propstatgt
• lt/responsegt
• lt/multistatusgt

37
Example Text Properties in XML

• ltresponse xmlnsDAVgt
• lthrefgthttp//example.com/folder/doc.txtlt/hrefgt
• ltpropstatgt
• ltpropgt
• ltcreationdategt1997-12-01T174221-0800
• lt/creationdategt
• ltdisplaynamegtProposal for
  Reorglt/displaynamegt
• ltgetetaggte8829107lt/getetaggt
• lt/propgt
• lt/propstatgt
• lt/responsegt

38
Example XML properties in XML

• ltprop xmlnsDAVgt
• ltmauthor xmlnsmietfianaschemeswgmetagt
• ltmfirstnamegtLisalt/mfirstnamegt
• ltmlastnamegtDusseaultlt/mlastnamegt
• lt/mauthorgt
• lt/propgt

39
Synchronization, take 2

• WebDAV
• PROPFIND ltcollection-urlgt HTTP 1.1
• Depth infinity
• lt?xml version1.0?gt
• ltpropfind xmlnsDAVgt
• ltpropgtltgetetaggtlt/propgt
• lt/propfindgt
• Easier to get list of changed and new resources

40
Locks

• Avoid Lost Update problem
• HTTP ETags help but arent sufficient
• Tells who is editing a document
• Widely used
• Adobe clients require support
• Optional feature of base WebDAV spec

41
Lost update problem
42
Lost update with Etags
Client A
Server State
Client B
GET file
GET file
Hello Allison
Change name
Change salutation
PUT file
New ETag assigned
PUT file, check ETag
Hello Alice
B must start over!
GET file
43
Concurrent edit with locks
Client A
Server State
Client B
LOCK file
GET file
Hello Allison
LOCK file fails
Change name
PUT file
UNLOCK file
LOCK file works
Hello Alice
GET file
Change salutation
PUT file UNLOCK file
Dear Alice
44
What locks arent

• Locks dont prevent read operations
• Locks dont create a sandbox
• Locks dont involve a transaction

Read properties
Write properties
Modify entity
Read entity
45
ACLs

• RFC3744
• Three working implementations
• Interoperability work in progress

46
ACLs

• Model
• Each resource has an Access Control List (ACL)
• Each ACL has n Access Control Entries (ACE)
  granting specific permission to specific
  principal
• Permissions similar to NFS read, write
• Principals includes users, groups
• Compatible with popular file systems

47
Versioning

• RFC3253, March 2002
• DeltaV Working Group
• Lots of IBM input
• Implementations of core features proven
• Version history
• Checkin, checkout

48
Version history, URLs
File.doc
http//example.com/file.doc
root-version
v1
http//example.com/?vfile.docn1
successor-set
v2
http//example.com/?vfile.docn2
49
Versioning

• Advanced support for
• Forks, merges
• Server Workspaces
• Activities atomic multi-file checkins,
  multi-file branches
• Baselines
• Versioned collections

50
Calendaring
51
Calendaring Standards Status

• IETF Working group
• been through 5 chairs since 1996
• 8 years of debate over CAP model and design
• Design by committee
• Changing editors
• Changing names CIP, CTP, CAP
• Compare to iCalendar and iMIP focus ? success
• Inventing many things from scratch
• Session control, feature negotiation
• Addressing, hierarchical object access, and
  queries
• Access control, other security design

52
Current CAP problems

• 136 pages and still underspecified
• Complex -- both clients and servers
• Maintains connection between server and client
• No Web addresses defined for calendar items
• Data model poorly defined
• Offline operation undefined
• Not supported by Microsoft, Apple, IBM
• Not yet a standard

53
Data model problems

• Are recurrances first-class items?
• Does a hierarchy imply inheritance?
• Is free-busy information a roll-up?
• Do free-busy ACLs differ from ordinary ACLs?
• What class of thing are VCALSTOREs, VAGENDAs,
  VQUERYs, VTIMEZONEs, VEVENTs, etc.
• Which are the same kinds of things?
• Which are different?

54
Chandler problems with CAP

• Server centric
• What functions can the client perform? Chandler
  wants control
• Hard to make peer-to-peer operation consistent
• Connection-oriented
• Makes servers less scalable
• Client must keep open yet another connection
• Search instead of Synch
• Poor performance
• Many roundtrips, e.g. GENERATE-UID

55
Chandler problems with CAP, cont

• Data access and scheduling mixed
• Alexander Talers mail of 24 May 1999
• But scheduling model doesnt help multiple
  clients work well together
• What if clients want to use XMPP to instantly
  schedule

56
Chandler problems with CAP, cont

• Poor extensibility (IMAP model)
• Chandler wants to annotate and share much more
• How to put a picture like a map along with an
  event?
• No leverage
• Compare to leverage of WebDAV
• BEEP
• More work
• No CAP client libraries exist today (python,
  other)
• IMAP-like model harder for clients more required
  features

57
Too many features

• Dont need searching if using synch
• Dont want scheduling but server MUST support
• Dont want to accept alarms in scheduling
  requests
• Dont want attendees to set own status
• At least not directly

58
Requirements for Calendar Server Access Protocol

• Authenticate to server
• Access control for multiple authors
• Data browsing
• Support for vCalendar data format, including
  free-busy
• Data synchronization
• Search
• Invitations, fan-out?
• Or is this a client function
• Notifications
• Reminders, incoming invitations

59
Where to layer
CalDAV
CAP
WebDAV
BEEP
60
WebDAV -- Application neutral
text
img
vCard
vCal
Data formats
WebDAV
Data access
SSL/TLS
Data privacy
TCP
Transport
Extend classic protocol layering
61
CalDAV overview

• Data model
• Calendars are WebDAV collections
• http//example.com/users/lisa/calendars/karate
• Events are HTTP (WebDAV) resources
• http.../calendars/karate/seminar.ics
• HTTP URLs extremely portable
• Full HTTP backward compatibility
• ETags, last modified date, caching
• Full WebDAV backward compatibility

62
File formats

• HTTP GET should return something useful
• GET ltevent-urlgt
• Returns iCalendar document?
• Returns xCalendar?
• Negotiation is a possibility
• GET ltcalendar-urlgt
• Possible roll-up into large iCalendar file
• Possible entry-point into WebUI
• Note WebDAV doesnt define GET of collections

63
CalDAV and WebDAV Properties

• Any implementor can add custom properties without
  conflict
• XML property format
• conducive to WebUI implementations
• Backward compatibility easier
• Clients only ask for properties they know how to
  display
• IMAP model very difficult to achieve backward
  compatibility

64
Specific properties
ltresponse xmlnscietfwgcalschgt
lthrefgthttp//example.com/lisa/event1.icslt/hrefgt
ltpropstatgt ltpropgt ltcdtstartgt2004-05-01T
1000-0800lt/cdtstartgt ltcdtendgt2004-05-01T
1100-0800lt/cdtstartgt ltctranspgtltcOPAQUE-
NOCONFLICT/gtlt/ctranspgt ltcsummarygtImportant
Meetinglt/csummarygt lt/propgt
ltstatusgtHTTP/1.1 200 OKlt/statusgt
lt/propstatgt lt/responsegt
65
CalDAV and Locks

• Optional feature
• Definitely useful for shared calendars
• Also useful for multiple clients
• PDA and laptop

66
CalDAV and WebDAV ACLs

• Access control could be optional
• A simple system can make calendars readable only
  by owners
• A slightly more complex system can make events
  either private (only owner) or public)
• A high value-add server can have powerful access
  control, e.g. shared calendars

67
CalDAV and DeltaV

• Versioning?
• Definitely optional
• High value-add feature
• Useful to see who changed an event

68
Support for CalDAV

• Apple iCal
• Publish vCalendar document via WebDAV
• Mozilla
• Uses Apple model, supports CalDAV
• MS Exchange - more structured, granular
• Browse calendars via WebDAV
• Use WebDAV properties for appointment information
• Not interoperable with Apple, Mozilla
• Cyrusoft reviewing CalDAV draft

69
Summary

• Chandler is ambitious, open, sharing-oriented
• Combines multiple data types in shared views
• WebDAV is common data access protocol
• Supports versioning, search, access control,
  locking, addressing -- all independent of data
  formats
• WebDAV iCalendar CalDAV
• Internet-Draft (work in progress)
• Working on next version

70
Bonus Slides
71
iMIP, vCalendar and Calendar Servers
SchedulingClient
Attendee
72
Modular Protocol Composition
SSL
URLs
WebDAV
data
DataStore
MIME
events
XMPP
URLs
Direc-tory
SASL
LDAP
73
Permissions

• All
• Read
• Write
• Bind, unbind
• Write-content, write-properties
• Administer
• Read-acl, write-acl
• Unlock (destroy lock)
• Read-current-user-privilege-set

74
Inheritance

• Each resource has inherited-acl-set property
• Can declare which other resource(s) it gets ACLs
  from
• On some systems, a user with write-acl privilege
  could set this property to change inheritance

75
Principals

• Browsable collections of principals
• Each principal is a resource
• Has URL for identification in ACLs
• http//example.com/principals/users/AliceW

/principals
/groups
/users
sales
dev
AliceW
BobR
76
Principals and Directories
LDAP?
WebDAV
transform
Result simpler client
Standard
Implementation-specific
77
(No Transcript)