Subject: Updates to iTIP/iMIP RFCs

From: [email-masked] (Steve Mansour)
Date: Thu, 10 Aug 2000 14:52:24 -0700

Folks,

I'm going to update the iTIP / iMIP RFCs based on some problems that
people have reported over the last year or so.  Below is the list of
problems and proposed solutions.

If you have any comments on the proposals, please reply.  PLEASE respond
to issue #2 and let us know which of the two proposals you like best.

Also, if you are aware of any other issues, please let me know about
them now and we should be able to get them into the revisions.

--------------------------------

1. Overloading iTIP REQUEST:

     Problem: Currently, the REQUEST method is used for invite,
     reschedule, update, confirm, reply to refresh. A reschedule
     and/or update are semantically different than a confirm or a
     reply to REFRESH.

     Proposal: Add a new method: CONFIRM. It would be used to (a)
     reply to a REFRESH and (b) notify participants of any changes
     to ATTENDEE or ORGANIZER.  All other "reschedule" or "update"
     changes MUST use REQUEST method.

2. Identify sender of iTIP COUNTER:

     Problem: You can't identify which Attendee a COUNTER message
     came from because all of the Attendees will appear in the
     component.

     Proposal 1:  Restrict the COUNTER message so that it can only
     specify the ORGANIZER and countering ATTENDEE.

     Note: You can still forward (party crashing, remember? :-) or
     delegate a REQUEST to change participants. However, only the
     ORGANIZER can remove a participant.  The down side to this
     approach is that you can't change the Attendees. This removes
     functionality.  The up side is that it requires no changes to
     iCalendar.

     Proposal 2: Add a new parameter to the ATTENDEE property:
     ATTCOUNTER.  It can only be specified (a) when the component
     method is COUNTER and (b) for the one Attendee who issued the
     COUNTER.

     Note: The good news is that no functionality is lost -- you
     can suggest a different attendee list.  The down side is that
     we have to update iCalendar with a new parameter.

3. Adding/deleting ATTENDEEs

     Problem: If the Organizer adds or deletes an ATTENDEE, do they
     really have to send the reschedule to all of the other
     ATTENDEEs?  The iTIP specification is not clear on this point.

     Proposal: No, the Organizer can send the REQUEST w/the new
     ATTENDEE info to just the new ATTENDEE.  It is up to the CUA.
     It is an implementation dependent issue if the SEQUENCE number
     needs to be incremented when you add/delete an ATTENDEE.
     iCalendar does not require an updated SEQUENCE number if a new
     ATTENDEE is added so this won't break iCalendar as it stands
     today.

4. Intolerant iMIP receivers.

     Problem: MIP specifies numerous MIME encapsulations for
     iCal/iTIP msgs.  It doesn't require that an implementation
     MUST be able to receive each of them.  This is leading to
     interop problems.

     Proposal: A conforming iMIP implementation MUST be able to
     receive each of the MIME encapsulations shown in the iMIP
     examples.;  It does not have to GENERATE them, but it must be
     able to RECEIVE them.

---

From: Eric Busboom <[email-masked]>
Date: Thu, 10 Aug 2000 21:46:36 -0700 (PDT)

> them now and we should be able to get them into the revisions.

Um, Recurrence rules?

I send this mail to Doug Royer this morning, but I think it is worth
posting to the list again. The problems with recurrence rules were
summarized best by Damon Chaplin in
http://www.imc.org/ietf-calendar/mail-archive/msg03656.html, reposted (
and edited) here:

o The BYDAY modifier is ambiguous. In a YEARLY frequency with BYMONTH
and/or BYWEEKNO set, does the BYDAY modifier apply to the year day, the
month day, or the week day? 

o Should BYWEEKNO and BYMONTH be mutually exclusive? They make no sense
together. (This would also avoid part of the previous problem.)

o Is it possible to use BYMONTHDAY in a WEEKLY frequency, or BYYEARDAY in
a MONTHLY or WEEKLY frequency? 

o BYSETPOS is limited to 366 values (or maybe 999 values if the comment
doesn't count as part of the spec!), yet a complete expansion for every
second in every day of the year would result in much larger sets. 

o The algorithm to calculate the first week in the year may be awkward,
since some people/countries may be used to other numbering schemes. 

I proposed this text (in
http://www.imc.org/ietf-calendar/mail-archive/msg03512.html )to solve some
of these problems:

-------------------- 

There are two types of BYxxx rules; date BYxxx rule parts that specify
time periods equal to or longer than a day, and time BYxxx rule parts that
specify the time within a day. The day BYxxx rule parts are : BYMONTH,
BYWEEKNO, BYYEARDAY, BYMONTHDAY and BYDAY. The time BYxxx rule parts are
BYHOUR, BYMINUTE, and BYSECOND. BYSETPOS is neither a date rule part nor a
time rule part.

Not all date BYxxx rule parts can appear simultaneously in a single
recurrence rule. Date BYxxx rule part restrictions are:

  If the BYYEARDAY appears, no other date rule part may appear.

  BYWEEKNO and BYMONTH rule parts may not both appear. 

Furthermore, not all date rule parts may be used with all recurrence
intervals.

  For MONTHLY recurrences (FREQ=MONTHLY) neither BYYEARDAY nor BYWEEKNO
  may appear.

  For WEEKLY recurrences (FREQ=WEEKLY) neither BYMONTHDAY nor BYYEARDAY
  may appear.
 
There are no restrictions regarding use of date rule parts and time rule
parts. There are no restrictions with using any combination of time rule
parts

-----------------------

The complete list of emails I know about for this topic are: 

From Damon Chaplin:
        http://www.imc.org/ietf-calendar/mail-archive/msg03656.html
 
From Bruce:
        http://www.imc.org/ietf-calendar/mail-archive/msg03549.html
        http://www.imc.org/ietf-calendar/mail-archive/msg03510.html
 
From me:
        http://www.imc.org/ietf-calendar/mail-archive/msg03507.html
        http://www.imc.org/ietf-calendar/mail-archive/msg03507.html
        http://www.imc.org/ietf-calendar/mail-archive/msg03549.html

eric.

---

From: [email-masked] (Steve Mansour)
Date: Thu, 10 Aug 2000 22:10:55 -0700

> > them now and we should be able to get them into the revisions.

...

right. But this would be an iCalendar update.  Pat is working on signing up a
responsible party for iCalendar. I was referring specifically to iTIP and
iMIP.

-Steve

---

From: John Stracke <[email-masked]>
Date: Fri, 11 Aug 2000 12:11:38 -0400

Steve Mansour wrote:

>      Proposal: Add a new method: CONFIRM. It would be used
>      to (a) reply to a REFRESH and (b) notify participants
>      of any changes to ATTENDEE or ORGANIZER.  All other
>      "reschedule" or "update" changes MUST use REQUEST
>      method.
>
Is this really necessary? Since there are some deployed iMIP
implementations (right?), it would require us to support both
modes.

> method is COUNTER and (b) for the one Attendee who issued the

I favor this approach.

>      Note: The good news is that no functionality is lost
>      -- you can suggest a different attendee list.
>
Plus, it's really easy to support both versions: you take the old
code that had to guess, and make it check ATTCOUNTER before it
guesses.

>      The down side is that we have to update iCalendar
>      with a new parameter.
>
Yeah, but we've got procedures for that.  Better to find out how
well they work now than later.  :-)

--
/==============================================================\
|John Stracke    | http://www.ecal.com |My opinions are my own.|
|Chief Scientist |=============================================|
|eCal Corp.      |"The Reality Check's in the mail." --L. Peter|
[email-masked]|Deutsch                                      |
\==============================================================/

---

From: Eric Busboom <[email-masked]>
Date: Mon, 28 Aug 2000 14:30:29 -0700 (PDT)

>      changes MUST use REQUEST method.

I understand using CONFIRM for the reply to a REFRESH, but it seems odd to
use it to change ATTENDEEs or the ORGANIZER, while other types of changes
still fall under REQUEST. 

As long as we are breaking up the REQUEST method, I'd like to see the
reschedule and update tasks broken out with a new METHOD, say UPDATE. This
would mirror the conceptual difference between a new request and a change
to a scheduled meeting. Then, case (b) above would fall under UPDATE

Also, new methods would make the components easier for a human to
understand. Some of the utility of having a human readable component is
lost because a human can't look at a request message and figure out what
it is really for. An UPDATE method would make the purpose of the component
more clear.  ( Er, or does SEQUENCE != 0 always imply UPDATE? ) 

eric.