Lightning implementing RFC6638: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
Line 6: Line 6:


The properties which have been identified and selected to be updated are displayed in the table below.
The properties which have been identified and selected to be updated are displayed in the table below.
== Properties that will be addressed ==


{| class="standard-table" border="1" style="border-collapse: collapse"
{| class="standard-table" border="1" style="border-collapse: collapse"
Line 11: Line 13:
! ID  
! ID  
! Change(Property)  
! Change(Property)  
! Description
! Section in RFC  
! Section in RFC  
! Comments
! Comments
Line 17: Line 18:
| 1
| 1
| min-date-time
| min-date-time
| Defined on scheduling Outbox collection
| [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 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 value can be in a calendar object resource.
Line 23: Line 23:
| 2
| 2
| max-date-time
| max-date-time
| Defined on scheduling Outbox collection
| [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 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 value can be in a calendar object resource.
Line 29: Line 28:
| 3
| 3
| max-attendees-per-instance
| max-attendees-per-instance
| Defined on scheduling Outbox collection
| [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.9 RFC 4791] which describes the latest value can be in a calendar object resource.
| First defined in the [http://tools.ietf.org/html/rfc4791#section-5.2.9 RFC 4791] which indicates the maximum number of attendees can have for an instance of any calendar object resource
|-
| 4
| SCHEDULE-FORCE-SEND
| [http://tools.ietf.org/html/rfc6638#section-7.2 section-7.2]
| This can be defined on both Organizer and Attendee calendar types to out.
|-
| 5
| Schedule-Tag
| [http://tools.ietf.org/html/rfc6638#section-3.2.10 section-3.2.10]
| Works along with If-Schedule-Tag-Match property when merging changes.
|-
| 5
| If-Schedule-Tag-Match
| [http://tools.ietf.org/html/rfc6638#section-8.3 section-8.3]
| This will replace the HTTP etag based property IF-MATCH.
|-
| 6
| schedule-default-calendar-URL
| [http://tools.ietf.org/html/rfc6638#section-4.3 section-4.3]
| Specifies whether a calendar user has a default calendar collection to save calendar object resources.
| -
| 7
| calendar-user-type
| [http://tools.ietf.org/html/rfc6638#section-2.4.2 section-2.4.2]
| Defined to use on attendee types available (individual,group,room). Analogous to CUTYPE in calendar user type.
| -
| 8
| MKCALENDAR
| [http://tools.ietf.org/html/rfc4791#section-5.3.1 rfc4791]
| This has been defined in RFC 4791 first to allow calendar users to create several remote calendars on servers.
|-
| 9
| Allowed attendee changes
| [http://tools.ietf.org/html/rfc6638#section-3.2.2.1 section-3.2.2.1]
| Attendees are allowed to do minor changes in attendee object resources. Such as Transparent property.
|-
|-
|
|
|}
|}



Revision as of 07:06, 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 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 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 calendar types to out.
5 Schedule-Tag section-3.2.10 Works along with If-Schedule-Tag-Match property when merging changes.
5 If-Schedule-Tag-Match section-8.3 This will replace the HTTP etag based property IF-MATCH.
6 schedule-default-calendar-URL section-4.3 Specifies whether a calendar user has a default calendar collection to save calendar object resources. - 7 calendar-user-type section-2.4.2 Defined to use on attendee types available (individual,group,room). Analogous to CUTYPE in calendar user type. - 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

Testing

Releases