Lightning implementing RFC6638

This page shows the overview implementation of Bug 100390 for Google Summer of Code 2014.

Abstract

This page specifies improve Lightning scheduling system by implementing latest CalDav features described in RFC 6638 and writing mozmill tests to cover various invitation scenarios. Also, this project requires identify where Lightning code-base lags behind RFC 6638 and update to newly introduced properties.

The properties which have been identified and selected to be updated are displayed in the table below.

Properties that will be addressed

ID	Change(Property)	Section in RFC	Comments
1	min-date-time	section-2.1	First defined in the RFC 4791 which describes the earliest date/time value can be in a calendar object resource.
2	max-date-time	section-2.1	First defined in the RFC 4791 which describes the latest date/time value can be in a calendar object resource.
3	max-attendees-per-instance	section-2.1	First defined in the RFC 4791 which indicates the maximum number of attendees can have for an instance of any calendar object resource
4	SCHEDULE-FORCE-SEND	section-7.2	This can be defined on both organizer and attendee to send forced invitations without affecting to the original object resources, whenever the server reluctant to send normal scheduling messages.
5	Schedule-Tag	section-3.2.10	Works along with If-Schedule-Tag-Match property when merging changes.
6	If-Schedule-Tag-Match	section-8.3	This will replace the HTTP etag based property IF-MATCH.
7	schedule-default-calendar-URL	section-4.3	Specifies whether a calendar user has a default calendar collection to save calendar object resources.
8	MKCALENDAR	rfc4791	This has been defined in RFC 4791 first to allow calendar users to create several remote calendars on servers.
9	Allowed attendee changes	section-3.2.2.1	Attendees are allowed to do minor changes in attendee object resources. Such as Transparent property.

TODOs

Property	Description	Header text
Example	Example	Example
Example	Example	Example
Example	Example	Example