iTIP defines what the [ref to impl guide] calls the grammar book of scheduling. It allows you to talk with others about your calendar data. You can have conversations with it like the following
Person A: “Hey B and C, let's have lunch tomorrow at noon.”
Person B: “Ok.”
Person C: “Can't we have it an hour later?”
A: “Ok, let's have it at one then.”
C: “Great, count me in.”
B: “Again, fine with me.”
In the example conversation above, you can see three different things happening. The first one is A requesting to have lunch with B and C. The second one is B replying to accept the request, and the last is C countering the request with one of his own.
The iTIP document consists of specifications of the semantics for these sort of scheduling methods. The list of methods that are specified is:
This lets you tell other people about events without requiring any action from them. For example, if you wanted to send a message to all your contacts to let them know when your birthday is, you would use the PUBLISH method.
Requests are also to make people aware of an event (or a todo). But now you're sending the message to a certain group of people that have to know about the event. For example, you would send a REQUEST to the friends you want to invite to your birthday party.
Unsurprisingly, your guests would use this method for a message to tell you whether they will be able to make it to your party.
In the example conversation we started with, person A asked about one specific lunch date. Now suppose you have a lunch date with someone every friday at noon. But the restaurant you're normally having lunch is closed because of holidays. You then could use this method to change the location information of this specific instance of the recurring lunchdate event.
Or suppose your boss decided she and you are having lunch friday at noon to discuss some things. In that case you would use the CANCEL method to cancel your appointment with your friend.
REFRESH is used to ask the organizer for the latest version of an event. You would use this to make sure you didn't miss any ADD or CANCEL messages.
If, like person C above you can't make it on the scheduled time in a REQUEST, you can send a message with this method to the organizer to see if they are ok with rescheduling it.
Person A was ok with it, so he would have sent a new REQUEST message with the new time. If on the other hand, the event can't be rescheduled, the organizer would send a DECLINECOUNTER message to reject the proposed change.