Создание iCalendar: объяснение RFC 5546

Я столкнулся с несколькими проблемами, связанными с созданием файла ICS, который должен быть совместим с несколькими клиентами, особенно iOS, Gmail, Outlook, Android и Windows Phone. Погуглив, я обнаружил предлагаемый стандарт 2009 года, он же RFC5546. Я прочитал этот документ и нашел очень интересный момент, который потенциально может решить мою проблему. В разделе Методы для компонентов календаря VEVENT объясняются различия между методами REQUEST и PUBLISH. Но есть пара моментов, которые мне не совсем понятны:

  1. Что делать ПУБЛИКАЦИИ? Должен ли он добавить новый календарь? Должен ли он создать новый календарь (например, в Outlook или iOS) или добавить событие в существующий пользовательский календарь (например, в Gmail или Lightning)? РЕДАКТИРОВАНИЕ: обратите внимание на календарь в виде файла, прикрепленного к электронному письму.
  2. Может ли PUBLISH содержать более одного события? Из документа и по логике да, но тогда Gmail добавляет только первое событие из списка. Lightning добавляет только одно событие и выдает ошибку 804a0004.
  3. Как должен работать ЗАПРОС? В документе указано: VEVENT | 1+ | All components MUST have the same UID. что означает, что в календаре может быть более 1 VEVENT, но они должны иметь одинаковый UID. Тогда как я могу клиент различать эти события? И на самом деле ни один клиент, который я пробовал, не может отличить события, сгенерированные с одним и тем же UID, но они добавляют только одно с самой высокой ПОСЛЕДОВАТЕЛЬНОСТЬЮ. По логике вещей, я не хочу отправлять более одного события на одно приглашение, но RFC позволяет мне это сделать (и в моем случае я хочу), так как же?
  4. С ЗАПРОСОМ, забыв оператор VEVENT | 1+ | All components MUST have the same UID., поэтому предоставляя уникальный UID для каждого события в файле ICS, 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

google-calendar-api outlook icalendar lightning ios5
person ThanksForAllTheFish    schedule 15.05.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

О 1) неясно, как вы сообщаете события клиенту: через iMIP (электронная почта) или через URL-адрес HTTP? В любом случае, нет правильного ответа на ваш вопрос: iTIP касается переноса данных iCalendar.

О 2) да, вы можете иметь несколько событий в потоке PUBLISH

Около 3):

iCalendar имеет понятие исключения для повторяющихся встреч. Эти исключения представлены VEVENT с тем же UID и RECURRENCE-ID, указывающим конкретный экземпляр, который следует считать исключением.

Как следствие, ЗАПРОС можно использовать только для передачи одного события (только одного UID), но само это событие может быть выражено как набор VEVENT: один для ведущего (например, собрание каждую пятницу в 10:00) и один для каждое исключение (например, за исключением пятницы 12 декабря, когда это произойдет в 09:00).

См., например, последнее событие в http://tools.ietf.org/html/rfc5546#section-4.4.8

person Arnaud Quillaud    schedule 16.05.2013
comment
Обновил вопрос по пункту 1), все равно календарь высылаю по почте, в виде вложения или встроенного в тело не важно. Что касается пункта 2), означает ли это, что такие клиенты, как Google Calendar или Lightning, содержат ошибки или неполноценны? Тогда ясно, что нет возможности отправить один файл, работающий для нескольких клиентов, я прав? - person ThanksForAllTheFish; 17.05.2013
comment
Вы правы, они ведут себя неправильно. Я подозреваю, что они обрабатывают PUBLISH так же, как REQUEST, и, следовательно, допускают только одно событие (возможно, с исключениями VEVENT), хотя из 4), похоже, что gmail делает прямо противоположное тому, что он должен делать. - person Arnaud Quillaud; 17.05.2013
comment
Насчет 4 я ошибся. Наконец-то я применил более научный подход и готовлю документ, описывающий поведение для некоторых комбинаций количества событий, клиента, UID и метода. Календарь Google добавляет только первое событие. - person ThanksForAllTheFish; 17.05.2013