When scheduling with an "Attendee", there are two types of status information that can be returned during the operation. The first type of status information is a "delivery" status that indicates whether the scheduling message from the "Organizer" to the "Attendee" was delivered or not, or what the current status of delivery is. The second type of status information is a "reply" status corresponding to the "Attendee's" own "REQUEST-STATUS" information from the scheduling message reply that is sent back to the "Organizer".
Similarly, when an "Attendee" sends a reply back to the "Organizer", there will be "delivery" status information for the scheduling message sent to the "Organizer". However, there is no "REQUEST-STATUS" sent back by the "Organizer", so there is no equivalent of the "reply" status as per scheduling messages to "Attendees".
The "delivery" status information on an "ORGANIZER" or "ATTENDEE" iCalendar property is conveyed in the "SCHEDULE-STATUS" property parameter value (Section 7.3). The status code value for "delivery" status can be one of the following:
+----------+--------------------------------------------------------+ | Delivery | Description | | Status | | | Code | | +----------+--------------------------------------------------------+ | 1.0 | The scheduling message is pending. That is, the | | | server is still in the process of sending the message. | | | The status code value can be expected to change once | | | the server has completed its sending and delivery | | | attempts. | | | | | 1.1 | The scheduling message has been successfully sent. | | | However, the server does not have explicit information | | | about whether the scheduling message was successfully | | | delivered to the recipient. This state can occur with | | | "store and forward" style scheduling protocols such as | | | iMIP [RFC6047] (iTIP using email). | | | | | 1.2 | The scheduling message has been successfully | | | delivered. | | | |
| 3.7 | The scheduling message was not delivered because the | | | server did not recognize the calendar user address as | | | a valid calendar user. Note that this code applies to | | | both "Organizer" and "Attendee" calendar user | | | addresses. | | | | | 3.8 | The scheduling message was not delivered due to | | | insufficient privileges. Note that this code applies | | | to privileges granted by both the "Organizer" and | | | "Attendee" calendar users. | | | | | 5.1 | The scheduling message was not delivered because the | | | server could not complete delivery of the message. | | | This is likely due to a temporary failure, and the | | | originator can try to send the message again at a | | | later time. | | | | | 5.2 | The scheduling message was not delivered because the | | | server was not able to find a way to deliver the | | | message. This is likely a permanent failure, and the | | | originator ought not try to send the message again, at | | | least without verifying/correcting the calendar user | | | address of the recipient. | | | | | 5.3 | The scheduling message was not delivered and was | | | rejected because scheduling with that recipient is not | | | allowed. This is likely a permanent failure, and the | | | originator ought not try to send the message again. | +----------+--------------------------------------------------------+
The status code for "reply" status can be any of the valid iTIP [RFC5546] "REQUEST-STATUS" values.
The 1.xx "REQUEST-STATUS" codes are new. This specification modifies item (2) of Section 3.6 of [RFC5546] by adding the following restriction:
For a 1.xx code, all components MUST have exactly the same code.
Definition of the new 1.xx codes is as follows: