的iCalendar創建：RFC 5546的解釋

Question

我面對有關創建以來，已經可與一些客戶，尤其是iOS，Gmail，Outlook，Android和Windows Phone兼容ICS文件的幾個問題。谷歌搜索，我發現了2009年的建議標準，又名RFC5546。我通讀了這篇文檔，發現了一個非常有趣並且可能解決我的問題的觀點。部分Methods for VEVENT Calendar Components解釋了方法REQUEST和PUBLISH之間的區別。但是，有幾點我並不清楚：

1. PUBLISH應該做什麼？它應該添加一個新的日曆嗎？它應該創建一個新的日曆（比如在Outlook或iOS中），還是應該在現有的用戶日曆中添加事件（如在Gmail或Lightning中）？ 編輯：將日曆記錄爲附加到電子郵件的文件。
2. Can PUBLISH可以包含多個事件嗎？從文檔和邏輯上來看，是的，但是Gmail只添加了列表中的第一個事件。閃電只添加一個事件，然後發出804a0004錯誤。
3. REQUEST應該如何工作？該文件指出：VEVENT | 1+ | All components MUST have the same UID.這意味着日曆可能有超過1個VEVENT，但它們必須具有相同的UID。那麼，我該如何區分這些事件呢？事實上，我嘗試過的客戶端無法區分使用相同UID生成的事件，但它們只添加了具有最高SEQUENCE的事件。從邏輯上講，我不想每個邀請發送一個以上的事件，但RFC允許我這樣做（並且在我的案例研究中，我想），那麼如何？
4. 通過REQUEST，忘記VEVENT | 1+ | All components MUST have the same UID.聲明，爲ICS文件中的每個事件提供唯一的UID，Gmail和iOS添加文件中包含的所有事件，而Lightning和Outlook只添加第一個事件。有沒有辦法追求這條道路，或者因爲它不應該被允許我應該找到另一種方式？
5. 基本上，您如何建議繼續在用戶的日曆中爲我提到的平臺添加更多帶有單個ICS文件的事件？

樣品ICS的發佈：

BEGIN:VCALENDAR 
PRODID:-//prodid//product//IT 
VERSION:2.0 
METHOD:PUBLISH 
CALSCALE:GREGORIAN 
BEGIN:VEVENT 
UID:uid1 
DTSTAMP:20130515T121437Z 
DTSTART:20130619T205000 
DTEND:20130619T215000 
DESCRIPTION:Desc 1 
SUMMARY:Sum 1 
LOCATION:location 
ORGANIZER:mailto:organizer@somedomain 
SEQUENCE:1 
STATUS:CONFIRMED 
END:VEVENT 
BEGIN:VEVENT 
UID:uid2 
DTSTAMP:20130515T121437Z 
DTSTART:20130719T205000 
DTEND:20130719T215000 
DESCRIPTION:Desc 2 
SUMMARY:Sum 2 
LOCATION:location 
ORGANIZER:mailto:organizer@somedomain 
SEQUENCE:1 
STATUS:CONFIRMED 
END:VEVENT 
END:VCALENDAR 

樣品的請求：

BEGIN:VCALENDAR 
PRODID:-//prodid//product//IT 
VERSION:2.0 
METHOD:REQUEST 
CALSCALE:GREGORIAN 
BEGIN:VEVENT 
UID:uid1 
DTSTAMP:20130515T121437Z 
DTSTART:20130619T205000 
DTEND:20130619T215000 
DESCRIPTION:Desc 1 
SUMMARY:Sum 1 
LOCATION:location 
ORGANIZER:mailto:organizer@somedomain 
ATTENDEE;RSVP=TRUE;CN=attendee cn:mailto:attendee@email 
SEQUENCE:1 
STATUS:CONFIRMED 
END:VEVENT 
BEGIN:VEVENT 
UID:uid2 
DTSTAMP:20130515T121437Z 
DTSTART:20130719T205000 
DTEND:20130719T215000 
DESCRIPTION:Desc 2 
SUMMARY:Sum 2 
LOCATION:location 
ORGANIZER:mailto:organizer@somedomain 
ATTENDEE;RSVP=TRUE;CN=attendee cn:mailto:attendee@email 
SEQUENCE:1 
STATUS:CONFIRMED 
END:VEVENT 
END:VCALENDAR 

Answer 1

約1）你是如何溝通的事件給客戶並不清楚：這是通過IMIP（電子郵件）還是通過HTTP URL？無論如何，你的問題沒有正確的答案：iTIP是關於傳輸iCalendar數據的。

關於在發佈流2）是的，你可以有多個事件

關於3）：

的iCalendar有例外的定期會議概念。這些例外由具有相同UID的VEVENT和表示特殊實例的RECURRENCE-ID表示，其應被視爲例外。

因此，REQUEST只能用於傳輸單個事件（只有一個UID），但此事件本身可能表示爲一組VEVENT：一個用於主人（例如在每個星期五的10:00 ）和每個例外情況（例如12月12日星期五除外，將在09:00發生）。

見例如http://tools.ietf.org/html/rfc5546#section-4.4.8