Bundling iTIP REQUESTs

When conveying information about a recurring VEVENT or VTODO, iTIP REQUEST messages usually take one of two forms:

Either they contain a full calendar object, i.e. master + exceptions (from RFC2446-bis):

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:2
      RDATE:19980304T180000Z
      RDATE:19980311T160000Z
      RDATE:19980315T180000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980304T180000Z
      DTEND:19980304T200000Z
      DTSTAMP:19980303T193000Z
      LOCATION:Conference Room A
      STATUS:CONFIRMED
      END:VEVENT
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:2
      RECURRENCE-ID:19980311T160000Z
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980311T160000Z
      DTEND:19980304T180000Z
      DTSTAMP:19980306T193000Z
      LOCATION:The Small conference room
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

or they contain a single instance:

      BEGIN:VCALENDAR
      METHOD:REQUEST
      PRODID:-//Example/ExampleCalendarClient//EN
      VERSION:2.0
      BEGIN:VEVENT
      UID:123456789@example.com
      SEQUENCE:1
      RECURRENCE-ID:19980311T180000Z
      ORGANIZER:mailto:a@example.com
      ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com
      ATTENDEE;RSVP=TRUE:mailto:b@example.com
      SUMMARY:Review Accounts
      DTSTART:19980311T160000Z
      DTEND:19980311T180000Z
      DTSTAMP:19980306T193000Z
      LOCATION:The Small conference room
      STATUS:CONFIRMED
      END:VEVENT
      END:VCALENDAR

That is at least my observation. I'm having trouble finding out whether:

  • this is just me making assumptions,
  • this is mandated by iTIP/iTIP-bis (but where ?), or by some unwritten convention,
  • this is an artifact of how calendar clients interaction usually works (typically the user can change either all instances or one single instance).

Sending only the master or the master + just a few exceptions could only be interpreted on the attendee side as meaning that the missing exceptions are no longer exceptions (?...). This does not make much sense.

But what about sending multiple instances with different RECURRENCE-ID in one single REQUEST ? For example, one could well change the description of one instance, and reschedule another instance by changing its DTSTART. Bundling those 2 instances into a single REQUEST could make sense. Another scenario is one where an attendee is added to only 3 instances of a recurring event. It seems natural to group those 3 instances into one REQUEST when sending the invitation to this attendee.

But is it legal to do so ? And, more importantly, are clients ready to consume this type of message ?

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About

arnaudq

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today
Bookmarks