Lightning implementing RFC6638: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 19: Line 19:
| min-date-time
| min-date-time
| [http://tools.ietf.org/html/rfc6638#section-2.1 section-2.1]
| [http://tools.ietf.org/html/rfc6638#section-2.1 section-2.1]
| First defined in the [http://tools.ietf.org/html/rfc4791#section-5.2.6 RFC 4791] which describes the earliest date/time value can be in a calendar object resource.
| First defined in the [http://tools.ietf.org/html/rfc4791#section-5.2.6 RFC 4791] which describes the earliest date/time value can be in a calendar object resource in a certain calendar collection.
|-  
|-  
| 2
| 2
| max-date-time
| max-date-time
| [http://tools.ietf.org/html/rfc6638#section-2.1 section-2.1]
| [http://tools.ietf.org/html/rfc6638#section-2.1 section-2.1]
| First defined in the [http://tools.ietf.org/html/rfc4791#section-5.2.6 RFC 4791] which describes the latest date/time value can be in a calendar object resource.
| First defined in the [http://tools.ietf.org/html/rfc4791#section-5.2.6 RFC 4791] which describes the latest date/time value can be in a calendar object resource in a certain calendar collection.
|-
|-
| 3
| 3

Revision as of 08:03, 18 May 2014

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 in a certain calendar collection.
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 in a certain calendar collection.
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 Allowed attendee changes section-3.2.2.1 Attendees are allowed to do minor changes in attendee object resources. Such as Transparent property.

TODOs

Each property has to be implemented and tested.

Item Priority Progress Comments
Writing mozmill test to IMIP bar In Progress The test injects a mail containing an invitation to check whether the IMIP bar is loaded and buttons are displayed. Then accept the event and make sure it is added at the correct location in the calendar view. Bug 1010294
Implement min-date-time property
Implement max-date-time property
Test for above properties
Implement max-attendees-per-instance property
Implement SCHEDULE-FORCE-SEND property
Test max-attendees-per-instance and SCHEDULE-FORCE-SEND
Implement Schedule-Tag property Can be tested with available calendar tests.
Implement If-Schedule-Tag-Match property Can be tested with available calendar tests.
Implement schedule-default-calendar-URL property
Implement Allowed attendee changes property
Test for above two properties.

Testing

Releases