RFC 2446：
iCalendar Transport-Independent Interoperability Protocol (iTIP)
specifies how calendaring systems use iCalendar objects
to interoperate with other calendar systems. It does so in a general
way so as to allow multiple methods of communication between systems.
Subsequent documents specify interoperable methods of communications
between systems that use this protocol.
iTIP 在描述的是行事曆與行事曆之間利用 iCalendar objects 的溝通方式，
舉例：
A 行事曆的 User PUBLISH 一個 VEVENT 給 B 行事曆的某個 User。
A 行事曆的 User REQUEST 一個 VEVENT 給 B 行事曆的某個 User 更新先前 PUBLISH 的 VEVENT。
B 行事曆的 User COUNTER (改變的建議)一個 VEVENT 給 A 行事曆的召集人。
而這邊的需求比較簡單，我們只需要統一的一個召集人，發出會通知(或更新)給所有參與人即可，
所以只需要用到 VEVENT REQUEST ，
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//RDU Software//NONSGML HandCal//EN
METHOD:REQUEST
BEGIN:VEVENT
DESCRIPTION:描述寫這邊
DTSTART:20121225T080000
DTEND:20121225T170000
DTSTAMP:20121129T093257
SEQUENCE:1
SUMMARY:標題寫這邊
UID:guid
STATUS:CONFIRMED
ORGANIZER:mailto:your@mail
END:VEVENT
END:VCALENDAR
但 PUBLISH 不能更新原有的行事曆，
如果要更新就要用 REQUEST ，用 REQUEST 就要有 ORGANIZER。
要更新一個原有的行事曆，
必須要注意以下幾點：
1. UID:唯一識別代碼，前者和後者要一致
2. DTSTAMP: 產生 ics 的時間後者要比前者大
3. SEQUENCE: 要遞增，一樣後者要比前者大( SEQUENCE 從 1 開始，往後遞增)
4. ORGANIZER: 要填入符合 email 格式的內容
以上四點在 microsoft outlook 2007 中，2 和 3 有檢查後者一定要比前者大，
第 4 項貝沒有檢查一定要一樣(因為可以變更召集人)，
但是一定要有 email 格式的內容，
但是一定要有 email 格式的內容，
這裡要注意召集人如果是自己(沒有設召集人，outlook預設是自己)的話，
就沒辦法更新( 這個超重要，試了很久才試出來 XD )。
就沒辦法更新( 這個超重要，試了很久才試出來 XD )。
METHOD 的部份定義在： http://tools.ietf.org/html/rfc2446#page-7
The ITIP methods
| Method | Description |
| PUBLISH | Used to publish a calendar entry to one or more Calendar Users. There is no interactivity between the publisher and any other calendar user. An example might include a baseball team publishing its schedule to the public. |
| REQUEST | Used to schedule a calendar entry with other Calendar Users. Requests are interactive in that they require the receiver to respond using the Reply methods. Meeting Requests, Busy Time requests and the assignment of VTODOs to other Calendar Users are all examples. Requests are also used by the "Organizer" to update the status of a calendar entry. |
| REPLY | A Reply is used in response to a Request to convey "Attendee" status to the "Organizer". Replies are commonly used to respond to meeting and task requests. |
| ADD | Add one or more instances to an existing VEVENT, VTODO, or VJOURNAL. |
| CANCEL | Cancel one or more instances of an existing VEVENT, VTODO, or VJOURNAL. |
| REFRESH | The Refresh method is used by an "Attendee" to request the latest version of a calendar entry. |
| COUNTER | The Counter method is used by an "Attendee" to negotiate a change in the calendar entry. Examples include the request to change a proposed Event time or change the due date for a VTODO. |
| DECLINECOUNTER | Used by the "Organizer" to decline the proposed counter-proprosal. |
另外關於 content type ，截錄一下rfc2447的說明：
2.4 Content Type
A MIME body part containing content information that conforms to this
document MUST have an [RFC-2045] "Content-Type" value of
"text/calendar". The [RFC-2045] "Content-Type" header field must also
include the type parameter "method". The value MUST be the same as
the value of the "METHOD" calendar property within the iCalendar
object. This means that a MIME message containing multiple iCalendar
objects with different method values must be further encapsulated
with a "multipart/mixed" MIME entity. This will allow each of the
iCalendar objects to be encapsulated within their own "text/calendar"
MIME entity.
