Notes for WAC hour

CalDAV design/draft

Past:

• iCalendar compatibility choices
• Reliance on DASL SEARCH (unfinished draft) gone
• Status summary: now implementable

Future:

• Compatibility testing between Oracle, Mozilla and Mulberry -- next week
• Next draft probably before next IETF meeting
• polish up nits

iCalendar Simplification work

Stalled

• No traffic on standards list
• No WG formed or requested to be formed (Ned Freed dropped ball)
• No draft-author chosen
• Doug Royer published a proposal but no support for his work has shown up
• Perhaps Calconnect will kick start this again (meeting next week). Or is Calconnect actually drawing support away from the standards process by seeming to provide an alternative?

WebDAV/CalDAV/iCalendar"> Chandler WebDAV/CalDAV/iCalendar implementation work

Past: Solid implementation progress

• Building framework that will handle WebDAV + CalDAV + import/export
• Model for WebDAV-based sharing now more similar to CalDAV
• VObject Library for iCalendar parsing -- now published as independent Open Source project, supported by OSAF developers

Future:

• Ability to import/export iCalendar files soon
• 0.5 release will have calendar sharing and iCalendar support

CalDAV Server Implementation plans

Plan of record:

• Start from Slide implementation (much more acceptable already, than mod_dav)
  • Java-based, acceptable performance, decent use of ETags (support for synchronization)
  • ACL support already exists
• Add CalDAV support to Slide
• Add ticket support to Slide (allows faster, simpler ad-hoc sharing)
• Add functionality to make Slide easier to install
• Work with existing open source team whenever possible; support core Slide project, submit enhancements back into Slide or related projects

Progress:

• Slide developers actively looking at CalDAV features and iCalendar library selection
• Hiring progress: search underway for Chandler server lead developer to contribute to Slide

Review of HTTP response signature proposal

draft

Problems:

• This repeats a lot of the work of S/MIME (why not just use S/MIME?)
• It doesn't protect against hacking the site any better than SSL does already -- the author may be confused about how browsers actually handle certs, etc. Thus, it would suffer from the same problem of browsers accepting new certificates, not accepting self-signed certs, etc.