iCalendar Transport-Independent Interoperability Protocol (iTIP)
draft-ietf-calsify-2446bis-10
The information below is for an old version of the document that is already published as an RFC.
| Document | Type |
This is an older version of an Internet-Draft that was ultimately published as RFC 5546.
|
|
|---|---|---|---|
| Author | Cyrus Daboo | ||
| Last updated | 2020-01-21 (Latest revision 2009-10-04) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | (None) | |
| Document shepherd | (None) | ||
| IESG | IESG state | Became RFC 5546 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | Lisa M. Dusseault | ||
| Send notices to | (None) |
draft-ietf-calsify-2446bis-10
quot; | | | | | | VTODO | 1 | | | ATTENDEE | 1+ | MUST for all attendees | | DTSTAMP | 1 | | | ORGANIZER | 1 | | | SEQUENCE | 1 | MUST echo the original SEQUENCE | | | | number | | UID | 1 | MUST echo original UID | | ATTACH | 0+ | | | CATEGORIES | 0+ | | | CLASS | 0 or 1 | | | COMMENT | 0+ | | | COMPLETED | 0 or 1 | | | CONTACT | 0+ | | | CREATED | 0 or 1 | | | DESCRIPTION | 0 or 1 | | | DTSTART | 0 or 1 | | | DUE | 0 or 1 | If present DURATION MUST NOT be | | | | present | | DURATION | 0 or 1 | If present DUE MUST NOT be | | | | present | | EXDATE | 0+ | | | GEO | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | | | LOCATION | 0 or 1 | | | PERCENT-COMPLETE | 0 or 1 | | | PRIORITY | 0 or 1 | | | RDATE | 0+ | | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | | | of a recurring calendar | | | | component. Otherwise it MUST NOT | | | | be present. | | RELATED-TO | 0+ | | | REQUEST-STATUS | 0+ | | | RESOURCES | 0+ | | | RRULE | 0 or 1 | | Daboo Expires April 7, 2010 [Page 59] Internet-Draft iTIP October 2009 | STATUS | 0 or 1 | MAY be one of | | | | COMPLETED/NEEDS-ACTION/ | | | | IN-PROCESS | | URL | 0 or 1 | | | IANA-PROPERTY | 0+ | | | X-PROPERTY | 0+ | | | | | | | VALARM | 0 | | | | | | | VTIMEZONE | 0+ | MUST be present if any date/time | | | | refers to a timezone | | | | | | IANA-COMPONENT | 0+ | | | X-COMPONENT | 0+ | | | | | | | VEVENT | 0 | | | | | | | VFREEBUSY | 0 | | +--------------------+----------+-----------------------------------+ 3.5. Methods For VJOURNAL Components This section defines the property set for the methods that are applicable to the "VJOURNAL" calendar component. The following summarizes the methods that are defined for the "VJOURNAL" calendar component. +---------+---------------------------------------------------------+ | Method | Description | +---------+---------------------------------------------------------+ | PUBLISH | Post a journal entry. Used primarily as a method of | | | advertising the existence of a journal entry. | | | | | ADD | Add one or more instances to an existing journal entry. | | | | | CANCEL | Cancel one or more instances of an existing journal | | | entry. | +---------+---------------------------------------------------------+ 3.5.1. PUBLISH The "PUBLISH" method in a "VJOURNAL" calendar component has no associated response. It is simply a posting of an iCalendar object that may be added to a calendar. It MUST have an "Organizer". It MUST NOT have "Attendees". The expected usage is for encapsulating an arbitrary journal entry as an iCalendar object. The "Organizer" MAY subsequently update (with another "PUBLISH" method) or cancel Daboo Expires April 7, 2010 [Page 60] Internet-Draft iTIP October 2009 (with a "CANCEL" method) a previously published journal entry. This method type is an iCalendar object that conforms to the following property constraints: +------------------------------------------------+ | Constraints for a METHOD:PUBLISH of a VJOURNAL | +------------------------------------------------+ Daboo Expires April 7, 2010 [Page 61] Internet-Draft iTIP October 2009 +--------------------+----------+-----------------------------------+ | Component/Property | Presence | Comment | +--------------------+----------+-----------------------------------+ | METHOD | 1 | MUST be "PUBLISH" | | | | | | VJOURNAL | 1+ | | | DESCRIPTION | 1 | Can be null. | | DTSTAMP | 1 | | | DTSTART | 1 | | | ORGANIZER | 1 | | | UID | 1 | | | ATTACH | 0+ | | | CATEGORIES | 0+ | | | CLASS | 0 or 1 | | | COMMENT | 0+ | | | CONTACT | 0+ | | | CREATED | 0 or 1 | | | EXDATE | 0+ | | | LAST-MODIFIED | 0 or 1 | | | RDATE | 0+ | | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | | | of a recurring calendar | | | | component. Otherwise it MUST NOT | | | | be present. | | RELATED-TO | 0+ | | | RRULE | 0 or 1 | | | SEQUENCE | 0 or 1 | MUST be present if non-zero. MAY | | | | be present if zero. | | STATUS | 0 or 1 | MAY be one of | | | | DRAFT/FINAL/CANCELLED | | SUMMARY | 0 or 1 | Can be null | | URL | 0 or 1 | | | IANA-PROPERTY | 0+ | | | X-PROPERTY | 0+ | | | ATTENDEE | 0 | | | REQUEST-STATUS | 0 | | | | | | | VALARM | 0+ | | | | | | | VTIMEZONE | 0+ | MUST be present if any date/time | | | | refers to a timezone | | | | | | IANA-COMPONENT | 0+ | | | X-COMPONENT | 0+ | | | | | | | VEVENT | 0 | | | | | | | VFREEBUSY | 0 | | Daboo Expires April 7, 2010 [Page 62] Internet-Draft iTIP October 2009 | | | | | VTODO | 0 | | +--------------------+----------+-----------------------------------+ 3.5.2. ADD The "ADD" method allows the "Organizer" to add one or more new instances to an existing "VJOURNAL" using a single iTIP message without having to send the entire "VJOURNAL" with all the existing instance data, as it would have to do if the "REQUEST" method were used. The "UID" must be that of the existing journal entry. If the "UID" property value in the "ADD" is not found on the recipient's calendar, then the recipient MAY treat the "ADD" as a "PUBLISH". When handling an "ADD" message, the "Attendee" treats each component in the "ADD" message as if it were referenced via an "RDATE"in the main component. There is no response to the "Organizer". This method type is an iCalendar object that conforms to the following property constraints: +--------------------------------------------+ | Constraints for a METHOD:ADD of a VJOURNAL | +--------------------------------------------+ Daboo Expires April 7, 2010 [Page 63] Internet-Draft iTIP October 2009 +--------------------+----------+-----------------------------------+ | Component/Property | Presence | Comment | +--------------------+----------+-----------------------------------+ | METHOD | 1 | MUST be "ADD" | | | | | | VJOURNAL | 1 | | | DESCRIPTION | 1 | Can be null | | DTSTAMP | 1 | | | DTSTART | 1 | | | ORGANIZER | 1 | | | SEQUENCE | 1 | MUST be greater than 0 | | UID | 1 | MUST match that of the original | | | | journal | | ATTACH | 0+ | | | CATEGORIES | 0+ | | | CLASS | 0 or 1 | | | COMMENT | 0+ | | | CONTACT | 0+ | | | CREATED | 0 or 1 | | | LAST-MODIFIED | 0 or 1 | | | RELATED-TO | 0+ | | | STATUS | 0 or 1 | MAY be one of | | | | DRAFT/FINAL/CANCELLED | | SUMMARY | 0 or 1 | Can be null | | URL | 0 or 1 | | | IANA-PROPERTY | 0+ | | | X-PROPERTY | 0+ | | | ATTENDEE | 0 | | | EXDATE | 0 | | | RECURRENCE-ID | 0 | | | REQUEST-STATUS | 0 | | | RDATE | 0 | | | RRULE | 0 | | | | | | | VALARM | 0+ | | | | | | | VTIMEZONE | 0 or 1 | MUST be present if any date/time | | | | refers to a timezone | | | | | | IANA-COMPONENT | 0+ | | | X-COMPONENT | 0+ | | | | | | | VEVENT | 0 | | | | | | | VFREEBUSY | 0 | | | | | | | VTODO | 0 | | +--------------------+----------+-----------------------------------+ Daboo Expires April 7, 2010 [Page 64] Internet-Draft iTIP October 2009 3.5.3. CANCEL The "CANCEL" method in a "VJOURNAL" calendar component is used to send a cancellation notice of an existing journal entry. The message is sent by the "Organizer" of a journal entry. For a recurring journal entry, either the whole journal entry or instances of a journal entry may be cancelled. To cancel the complete range of a recurring journal entry, the "UID" property value for the journal entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be specified in the "CANCEL" method. In order to cancel an individual instance of the journal entry, the "RECURRENCE-ID" property value for the journal entry MUST be specified in the "CANCEL" method. There are two options for canceling a sequence of instances of a recurring "VJOURNAL" calendar component: a. the "RECURRENCE-ID" property for an instance in the sequence MUST be specified with the "RANGE" property parameter value of "THISANDFUTURE" to indicate cancellation of the specified "VTODO" calendar component and all instances after b. individual recurrence instances may be cancelled by specifying multiple "VJOURNAL" components with a "RECURRENCE-ID" property corresponding to one of the instances to be cancelled When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be incremented as described in Section 2.1.4. This method type is an iCalendar object that conforms to the following property constraints: +-----------------------------------------------+ | Constraints for a METHOD:CANCEL of a VJOURNAL | +-----------------------------------------------+ Daboo Expires April 7, 2010 [Page 65] Internet-Draft iTIP October 2009 +--------------------+----------+-----------------------------------+ | Component/Property | Presence | Comment | +--------------------+----------+-----------------------------------+ | METHOD | 1 | MUST be "CANCEL" | | | | | | VJOURNAL | 1+ | All MUST have the same UID | | DTSTAMP | 1 | | | ORGANIZER | 1 | | | SEQUENCE | 1 | | | UID | 1 | MUST be the UID of the original | | | | REQUEST | | ATTACH | 0+ | | | ATTENDEE | 0 | | | CATEGORIES | 0+ | | | CLASS | 0 or 1 | | | COMMENT | 0+ | | | CONTACT | 0+ | | | CREATED | 0 or 1 | | | DESCRIPTION | 0 or 1 | | | DTSTART | 0 or 1 | | | EXDATE | 0+ | | | LAST-MODIFIED | 0 or 1 | | | RDATE | 0+ | | | RECURRENCE-ID | 0 or 1 | Only if referring to an instance | | | | of a recurring calendar | | | | component. Otherwise it MUST NOT | | | | be present. | | RELATED-TO | 0+ | | | RRULE | 0 or 1 | | | STATUS | 0 or 1 | MAY be present, must be | | | | "CANCELLED" if present | | SUMMARY | 0 or 1 | | | URL | 0 or 1 | | | IANA-PROPERTY | 0+ | | | X-PROPERTY | 0+ | | | REQUEST-STATUS | 0 | | | | | | | VALARM | 0 | | | | | | | VTIMEZONE | 0+ | MUST be present if any date/time | | | | refers to a timezone | | | | | | IANA-COMPONENT | 0+ | | | X-COMPONENT | 0+ | | | | | | | VEVENT | 0 | | | | | | | VFREEBUSY | 0 | | Daboo Expires April 7, 2010 [Page 66] Internet-Draft iTIP October 2009 | | | | | VTODO | 0 | | +--------------------+----------+-----------------------------------+ 3.6. Status Replies The "REQUEST-STATUS" property is used to convey status information about a REPLY, COUNTER or DECLINECOUNTER iTIP message. The codes listed in the table below SHOULD be used. If the "REQUEST-STATUS" property is not present in one of these iTIP messages, then a status code of "2.0" (success) MUST be assumed. This specification adds a new IANA registry for REQUEST-STATUS values, as defined in Section 7, which includes a new registration template for defining the specific components of the REQUEST-STATUS value. Additional codes MAY be used provided the process described in Section 8.2.1 of [RFC5545] is used to register them. This specification allows for multiple "REQUEST-STATUS" properties to be returned in iCalendar components in the appropriate iTIP messages. When multiple "REQUEST-STATUS" properties are present, the following restrictions apply: 1. Within any one component, the "top-level" numeric value of the "short return status code" MUST be the same for all REQUEST- STATUS properties. i.e. there cannot be a mixture of e.g., 2.xx and 5.xx codes within a single component. 2. Across all components in the iTIP message, the following applies: A. If any one component would have a 5.xx code, then all components MUST have a code in that range or "REQUEST-STATUS" MUST NOT be present in the other components if a 5.xx code is not appropriate for those components. B. Otherwise, if any one component would have a 3.xx code, then all components MUST have a code in that range or "REQUEST- STATUS" MUST NOT be present in the other components if a 3.xx code is not appropriate for those components. C. 2.xx and 4.xx codes can be used in different components provided that each component follows the restriction in (1) above. The following "REQUEST-STATUS" codes are defined (any "Offending Data" MAY be specified in the "REQUEST-STATUS" value as the extdata field): 3.6.1. Status Code 2.0 Daboo Expires April 7, 2010 [Page 67] Internet-Draft iTIP October 2009 Status Code: 2.0 Status Description: Success. Status Exception Data: None. Description: iTIP operation succeeded. 3.6.2. Status Code 2.1 Status Code: 2.1 Status Description: Success but fallback taken on one or more property values. Status Exception Data: Property name and value MAY be specified. Description: iTIP operation succeeded with fallback on one or more property values. 3.6.3. Status Code 2.2 Status Code: 2.2 Status Description: Success, invalid property ignored. Status Exception Data: Property name MAY be specified. Description: iTIP operation succeeded but a property was ignored. 3.6.4. Status Code 2.3 Status Code: 2.3 Status Description: Success, invalid property parameter ignored. Status Exception Data: Property parameter name and value MAY be specified. Description: iTIP operation succeeded but a property parameter was ignored because it was invalid. 3.6.5. Status Code 2.4 Status Code: 2.4 Status Description: Success, unknown non-standard property ignored. Status Exception Data: Non-standard property name MAY be specified. Description: iTIP operation succeeded but a property parameter was ignored because it was unknown. 3.6.6. Status Code 2.5 Status Code: 2.5 Status Description: Success, unknown non-standard property value ignored. Status Exception Data: Property and non-standard value MAY be specified. Daboo Expires April 7, 2010 [Page 68] Internet-Draft iTIP October 2009 Description: iTIP operation succeeded but a property was ignored because its value was unknown. 3.6.7. Status Code 2.6 Status Code: 2.6 Status Description: Success, invalid calendar component ignored. Status Exception Data: Calendar component sentinel (e.g., BEGIN: ALARM) MAY be specified. Description: iTIP operation succeeded but a component was ignored because it was invalid. 3.6.8. Status Code 2.7 Status Code: 2.7 Status Description: Success, request forwarded to Calendar User. Status Exception Data: Original and forwarded calendar user addresses MAY be specified. Description: iTIP operation succeeded, and the request was forwarded to another calendar user. 3.6.9. Status Code 2.8 Status Code: 2.8 Status Description: Success, repeating event ignored. Scheduled as a single component. Status Exception Data: RRULE or RDATE property name and value MAY be specified. Description: iTIP operation succeeded, but a repeating event was truncated to a single instance. 3.6.10. Status Code 2.9 Status Code: 2.9 Status Description: Success, truncated end date time to date boundary. Status Exception Data: DTEND property value MAY be specified. Description: iTIP operation succeeded, but the end time was truncated to a date boundary. 3.6.11. Status Code 2.10 Status Code: 2.10 Status Description: Success, repeating VTODO ignored. Scheduled as a single VTODO. Daboo Expires April 7, 2010 [Page 69] Internet-Draft iTIP October 2009 Status Exception Data: RRULE or RDATE property name and value MAY be specified. Description: iTIP operation succeeded, but a repeating todo was truncated to a single instance. 3.6.12. Status Code 2.11 Status Code: 2.11 Status Description: Success, unbounded RRULE clipped at some finite number of instances. Status Exception Data: RRULE property name and value MAY be specified. Number of instances MAY also be specified. Description: iTIP operation succeeded, but an unbounded repeating object was clipped to a finite number of instances. 3.6.13. Status Code 3.0 Status Code: 3.0 Status Description: Invalid property name. Status Exception Data: Property name MAY be specified. Description: iTIP operation failed because of an invalid property name. 3.6.14. Status Code 3.1 Status Code: 3.1 Status Description: Invalid property value. Status Exception Data: Property name and value MAY be specified. Description: iTIP operation failed because of an invalid property value. 3.6.15. Status Code 3.2 Status Code: 3.2 Status Description: Invalid property parameter. Status Exception Data: Property parameter name and value MAY be specified. Description: iTIP operation failed because of an invalid property parameter. 3.6.16. Status Code 3.3 Status Code: 3.3 Status Description: Invalid property parameter value. Daboo Expires April 7, 2010 [Page 70] Internet-Draft iTIP October 2009 Status Exception Data: Property parameter name and value MAY be specified. Description: iTIP operation failed because of an invalid property parameter value. 3.6.17. Status Code 3.4 Status Code: 3.4 Status Description: Invalid calendar component sequence. Status Exception Data: Calendar component sentinel MAY be specified (e.g., BEGIN:VTIMEZONE). Description: iTIP operation failed because of an invalid component. 3.6.18. Status Code 3.5 Status Code: 3.5 Status Description: Invalid date or time. Status Exception Data: Date/time value(s) MAY be specified. Description: iTIP operation failed because of an invalid date or time property. 3.6.19. Status Code 3.6 Status Code: 3.6 Status Description: Invalid rule. Status Exception Data: Rule value MAY be specified. Description: iTIP operation failed because of an invalid rule property. 3.6.20. Status Code 3.7 Status Code: 3.7 Status Description: Invalid Calendar User. Status Exception Data: Attendee property value MAY be specified. Description: iTIP operation failed because of an invalid Attendee property. 3.6.21. Status Code 3.8 Status Code: 3.8 Status Description: No authority. Status Exception Data: METHOD and Attendee property values MAY be specified. Description: iTIP operation failed because an Attendee does not have suitable privileges for the operation. #x27;) octets. MAX is the maximum length for each value of any text attribute. However, if an attribute will always contain values whose maximum length is much less than MAX, the definition of that attribute will include a qualifier that defines the maximum length for values of that attribute. For example: the "printer-location" attribute is specified as "printer-location (text(127))". In this case, text values for "printer-location" MUST NOT exceed 127 octets; if supplied with a longer text string via some external interface (other than the protocol), implementations are free to truncate to this shorter length limitation. In this document, all text attributes are defined using the 'text' syntax. However, 'text' is used only for brevity; the formal interpretation of 'text' is: 'textWithoutLanguage | textWithLanguage'. That is, for any attribute defined in this document using the 'text' attribute syntax, all IPP objects and Hastings, et al. Standards Track [Page 79] RFC 2911 IPP/1.1: Model and Semantics September 2000 clients MUST support both the 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes. However, in actual usage and protocol execution, objects and clients accept and return only one of the two syntax per attribute. The syntax 'text' never appears "on- the-wire". Both 'textWithoutLanguage' and 'textWithLanguage' are needed to support the real world needs of interoperability between sites and systems that use different natural languages as the basis for human communication. Generally, one natural language applies to all text attributes in a given request or response. The language is indicated by the "attributes-natural-language" operation attribute defined in section 3.1.4 or "attributes-natural-language" job attribute defined in section 4.3.20, and there is no need to identify the natural language for each text string on a value-by-value basis. In these cases, the attribute syntax 'textWithoutLanguage' is used for text attributes. In other cases, the client needs to supply or the Printer object needs to return a text value in a natural language that is different from the rest of the text values in the request or response. In these cases, the client or Printer object uses the attribute syntax 'textWithLanguage' for text attributes (this is the Natural Language Override mechanism described in section 3.1.4). The 'textWithoutLanguage' and 'textWithLanguage' attribute syntaxes are described in more detail in the following sections. 4.1.1.1 'textWithoutLanguage' The 'textWithoutLanguage' syntax indicates a value that is sequence of zero or more characters encoded in a maximum of 1023 (MAX) octets. Text strings are encoded using the rules of some charset. The Printer object MUST support the UTF-8 charset [RFC2279] and MAY support additional charsets to represent 'text' values, provided that the charsets are registered with IANA [IANA-CS]. See Section 4.1.7 for the definition of the 'charset' attribute syntax, including restricted semantics and examples of charsets. 4.1.1.2 'textWithLanguage' The 'textWithLanguage' attribute syntax is a compound attribute syntax consisting of two parts: a 'textWithoutLanguage' part encoded in a maximum of 1023 (MAX) octets plus an additional 'naturalLanguage' (see section 4.1.8) part that overrides the natural language in force. The 'naturalLanguage' part explicitly identifies the natural language that applies to the text part of that value and that value alone. For any give text attribute, the 'textWithoutLanguage' part is limited to the maximum length defined for that 'text' attribute, and the 'naturalLanguage' part is always Hastings, et al. Standards Track [Page 80] RFC 2911 IPP/1.1: Model and Semantics September 2000 limited to 63 (additional) octets. Using the 'textWithLanguage' attribute syntax rather than the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism and MUST be supported by all IPP objects and clients. If the attribute is multi-valued (1setOf text), then the 'textWithLanguage' attribute syntax MUST be used to explicitly specify each attribute value whose natural language needs to be overridden. Other values in a multi-valued 'text' attribute in a request or a response revert to the natural language of the operation attribute. In a create request, the Printer object MUST accept and store with the Job object any natural language in the "attributes-natural- language" operation attribute, whether the Printer object supports that natural language or not. Furthermore, the Printer object MUST accept and store any 'textWithLanguage' attribute value, whether the Printer object supports that natural language or not. These requirements are independent of the value of the "ipp-attribute- fidelity" operation attribute that the client MAY supply. Example: If the client supplies the "attributes-natural-language" operation attribute with the value: 'en' indicating English, but the value of the "job-name" attribute is in French, the client MUST use the 'textWithLanguage' attribute syntax with the following two values: 'fr': Natural Language Override indicating French 'Rapport Mensuel': the job name in French See the "Encoding and Transport" document [RFC2910] section 3.9 for the encoding of the two parts and Appendix A for a detailed example of the 'textWithLanguage' attribute syntax. 4.1.2 'name' This syntax type is used for user-friendly strings, such as a Printer name, that, for humans, are more meaningful than identifiers. Names are never translated from one natural language to another. The 'name' attribute syntax is essentially the same as 'text', including the REQUIRED support of UTF-8 except that the sequence of characters is limited so that its encoded form MUST NOT exceed 255 (MAX) octets. Also like 'text', 'name' is really an abbreviated notation for either 'nameWithoutLanguage' or 'nameWithLanguage'. That is, all IPP objects and clients MUST support both the 'nameWithoutLanguage' and 'nameWithLanguage' attribute syntaxes. However, in actual usage and Hastings, et al. Standards Track [Page 81] RFC 2911 IPP/1.1: Model and Semantics September 2000 protocol execution, objects and clients accept and return only one of the two syntax per attribute. The syntax 'name' never appears "on- the-wire". Only the 'text' and 'name' attribute syntaxes permit the Natural Language Override mechanism. Some attributes are defined as 'type3 keyword | name'. These attributes support values that are either type3 keywords or names. This dual-syntax mechanism enables a site administrator to extend these attributes to legally include values that are locally defined by the site administrator. Such names are not registered with IANA. 4.1.2.1 'nameWithoutLanguage' The 'nameWithoutLanguage' syntax indicates a value that is sequence of zero or more characters encoded in a maximum of 255 (MAX) octets. 4.1.2.2 'nameWithLanguage' The 'nameWithLanguage' attribute syntax is a compound attribute syntax consisting of two parts: a 'nameWithoutLanguage' part encoded in a maximum of 1023 (MAX) octets plus an additional 'naturalLanguage' (see section 4.1.8) part that overrides the natural language in force. The 'naturalLanguage' part explicitly identifies the natural language that applies to that name value and that name value alone. For any give text attribute, the 'textWithoutLanguage' part is limited to the maximum length defined for that 'text' attribute, and the 'naturalLanguage' part is always limited to 63 (additional) octets. Using the 'textWithLanguage' attribute syntax rather than the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism and MUST be supported by all IPP objects and clients. The 'nameWithLanguage' attribute syntax behaves the same as the 'textWithLanguage' syntax. Using the 'textWithLanguage' attribute syntax rather than the normal 'textWithoutLanguage' syntax is the so-called Natural Language Override mechanism and MUST be supported by all IPP objects and clients. If a name is in a language that is different than the rest of the object or operation, then this 'nameWithLanguage' syntax is used rather than the generic 'nameWithoutLanguage' syntax. If the attribute is multi-valued (1setOf text), then the 'nameWithLanguage' attribute syntax MUST be used to explicitly specify each attribute value whose natural language needs to be overridden. Hastings, et al. Standards Track [Page 82] RFC 2911 IPP/1.1: Model and Semantics September 2000 Other values in a multi-valued 'name' attribute in a request or a response revert to the natural language of the operation attribute. In a create request, the Printer object MUST accept and store with the Job object any natural language in the "attributes-natural- language" operation attribute, whether the Printer object supports that natural language or not. Furthermore, the Printer object MUST accept and store any 'nameWithLanguage' attribute value, whether the Printer object supports that natural language or not. These requirements are independent of the value of the "ipp-attribute- fidelity" operation attribute that the client MAY supply. Example: If the client supplies the "attributes-natural-language" operation attribute with the value: 'en' indicating English, but the "printer-name" attribute is in German, the client MUST use the 'nameWithLanguage' attribute syntax as follows: 'de': Natural Language Override indicating German 'Farbdrucker': the Printer name in German See the "Encoding and Transport" document [RFC2910] section 3.9 for the encoding of the two parts and Appendix A for a detailed example of the 'nameWithLanguage' attribute syntax. 4.1.2.3 Matching 'name' attribute values For purposes of matching two 'name' attribute values for equality, such as in job validation (where a client-supplied value for attribute "xxx" is checked to see if the value is among the values of the Printer object's corresponding "xxx-supported" attribute), the following match rules apply: 1. 'keyword' values never match 'name' values. 2. 'name' (nameWithoutLanguage and nameWithLanguage) values match if (1) the name parts match and (2) the Associated Natural- Language parts (see section 3.1.4.1) match. The matching rules are: a. the name parts match if the two names are identical character by character, except it is RECOMMENDED that case be ignored. For example: 'Ajax-letter-head-white' MUST match 'Ajax-letter-head-white' and SHOULD match 'ajax- letter-head-white' and 'AJAX-LETTER-HEAD-WHITE'. Hastings, et al. Standards Track [Page 83] RFC 2911 IPP/1.1: Model and Semantics September 2000 b. the Associated Natural-Language parts match if the shorter of the two meets the syntactic requirements of RFC 1766 [RFC1766] and matches byte for byte with the longer. For example, 'en' matches 'en', 'en-us' and 'en-gb', but matches neither 'fr' nor 'e'. 4.1.3 'keyword' The 'keyword' attribute syntax is a sequence of characters, length: 1 to 255, containing only the US-ASCII [ASCII] encoded values for lowercase letters ("a" - "z"), digits ("0" - "9"), hyphen ("-"), dot ("."), and underscore ("_"). The first character MUST be a lowercase letter. Furthermore, keywords MUST be in U.S. English. This syntax type is used for enumerating semantic identifiers of entities in the abstract protocol, i.e., entities identified in this document. Keywords are used as attribute names or values of attributes. Unlike 'text' and 'name' attribute values, 'keyword' values MUST NOT use the Natural Language Override mechanism, since they MUST always be US-ASCII and U.S. English. Keywords are for use in the protocol. A user interface will likely provide a mapping between protocol keywords and displayable user- friendly words and phrases which are localized to the natural language of the user. While the keywords specified in this document MAY be displayed to users whose natural language is U.S. English, they MAY be mapped to other U.S. English words for U.S. English users, since the user interface is outside the scope of this document. In the definition for each attribute of this syntax type, the full set of defined keyword values for that attribute are listed. When a keyword is used to represent an attribute (its name), it MUST be unique within the full scope of all IPP objects and attributes. When a keyword is used to represent a value of an attribute, it MUST be unique just within the scope of that attribute. That is, the same keyword MUST NOT be used for two different values within the same attribute to mean two different semantic ideas. However, the same keyword MAY be used across two or more attributes, representing different semantic ideas for each attribute. Section 6.1 describes how the protocol can be extended with new keyword values. Examples of attribute name keywords: "job-name" "attributes-charset" Hastings, et al. Standards Track [Page 84] RFC 2911 IPP/1.1: Model and Semantics September 2000 Note: This document uses "type1", "type2", and "type3" prefixes to the "keyword" basic syntax to indicate different levels of review for extensions (see section 6.1). 4.1.4 'enum' The 'enum' attribute syntax is an enumerated integer value that is in the range from 1 to 2**31 - 1 (MAX). Each value has an associated 'keyword' name. In the definition for each attribute of this syntax type, the full set of possible values for that attribute are listed. This syntax type is used for attributes for which there are enum values assigned by other standards, such as SNMP MIBs. A number of attribute enum values in this document are also used for corresponding attributes in other standards [RFC1759]. This syntax type is not used for attributes to which the administrator may assign values. Section 6.1 describes how the protocol can be extended with new enum values. Enum values are for use in the protocol. A user interface will provide a mapping between protocol enum values and displayable user- friendly words and phrases which are localized to the natural language of the user. While the enum symbols specified in this document MAY be displayed to users whose natural language is U.S. English, they MAY be mapped to other U.S. English words for U.S. English users, since the user interface is outside the scope of this document. Note: SNMP MIBs use '2' for 'unknown' which corresponds to the IPP "out-of-band" value 'unknown'. See the description of the "out-of- band" values at the beginning of Section 4.1. Therefore, attributes of type 'enum' start at '3'. Note: This document uses "type1", "type2", and "type3" prefixes to the "enum" basic syntax to indicate different levels of review for extensions (see section 6.1). 4.1.5 'uri' The 'uri' attribute syntax is any valid Uniform Resource Identifier or URI [RFC2396]. Most often, URIs are simply Uniform Resource Locators or URLs. The maximum length of URIs used as values of IPP attributes is 1023 octets. Although most other IPP attribute syntax types allow for only lower-cased values, this attribute syntax type conforms to the case-sensitive and case-insensitive rules specified in [RFC2396]. See also [IPP-IIG] for a discussion of case in URIs. Hastings, et al. Standards Track [Page 85] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.1.6 'uriScheme' The 'uriScheme' attribute syntax is a sequence of characters representing a URI scheme according to RFC 2396 [RFC2396]. Though RFC 2396 requires that the values be case-insensitive, IPP requires all lower case values in IPP attributes to simplify comparing by IPP clients and Printer objects. Standard values for this syntax type are the following keywords: 'ipp': for IPP schemed URIs (e.g., "ipp:...") 'http': for HTTP schemed URIs (e.g., "http:...") 'https': for use with HTTPS schemed URIs (e.g., "https:...") (not on IETF standards track) 'ftp': for FTP schemed URIs (e.g., "ftp:...") 'mailto': for SMTP schemed URIs (e.g., "mailto:...") 'file': for file schemed URIs (e.g., "file:...") A Printer object MAY support any URI 'scheme' that has been registered with IANA [IANA-MT]. The maximum length of URI 'scheme' values used to represent IPP attribute values is 63 octets. 4.1.7 'charset' The 'charset' attribute syntax is a standard identifier for a charset. A charset is a coded character set and encoding scheme. Charsets are used for labeling certain document contents and 'text' and 'name' attribute values. The syntax and semantics of this attribute syntax are specified in RFC 2046 [RFC2046] and contained in the IANA character-set Registry [IANA-CS] according to the IANA procedures [RFC2278]. Though RFC 2046 requires that the values be case-insensitive US-ASCII [ASCII], IPP requires all lower case values in IPP attributes to simplify comparing by IPP clients and Printer objects. When a character-set in the IANA registry has more than one name (alias), the name labeled as "(preferred MIME name)", if present, MUST be used. The maximum length of 'charset' values used to represent IPP attribute values is 63 octets. Some examples are: 'utf-8': ISO 10646 Universal Multiple-Octet Coded Character Set (UCS) represented as the UTF-8 [RFC2279] transfer encoding scheme in which US-ASCII is a subset charset. 'us-ascii': 7-bit American Standard Code for Information Interchange (ASCII), ANSI X3.4-1986 [ASCII]. That standard Hastings, et al. Standards Track [Page 86] RFC 2911 IPP/1.1: Model and Semantics September 2000 defines US-ASCII, but RFC 2045 [RFC2045] eliminates most of the control characters from conformant usage in MIME and IPP. 'iso-8859-1': 8-bit One-Byte Coded Character Set, Latin Alphabet Nr 1 [ISO8859-1]. That standard defines a coded character set that is used by Latin languages in the Western Hemisphere and Western Europe. US-ASCII is a subset charset. Some attribute descriptions MAY place additional requirements on charset values that may be used, such as REQUIRED values that MUST be supported or additional restrictions, such as requiring that the charset have US- ASCII as a subset charset. 4.1.8 'naturalLanguage' The 'naturalLanguage' attribute syntax is a standard identifier for a natural language and optionally a country. The values for this syntax type are defined by RFC 1766 [RFC1766]. Though RFC 1766 requires that the values be case-insensitive US-ASCII [ASCII], IPP requires all lower case to simplify comparing by IPP clients and Printer objects. Examples include: 'en': for English 'en-us': for US English 'fr': for French 'de': for German The maximum length of 'naturalLanguage' values used to represent IPP attribute values is 63 octets. 4.1.9 'mimeMediaType' The 'mimeMediaType' attribute syntax is the Internet Media Type (sometimes called MIME type) as defined by RFC 2046 [RFC2046] and registered according to the procedures of RFC 2048 [RFC2048] for identifying a document format. The value MAY include a charset, or other, parameter, depending on the specification of the Media Type in the IANA Registry [IANA-MT]. Although most other IPP syntax types allow for only lower-cased values, this syntax type allows for mixed-case values which are case-insensitive. Examples are: 'text/html': An HTML document 'text/plain': A plain text document in US-ASCII (RFC 2046 indicates that in the absence of the charset parameter MUST mean US-ASCII rather than simply unspecified) [RFC2046]. 'text/plain; charset=US-ASCII': A plain text document in US-ASCII [52, 56]. Hastings, et al. Standards Track [Page 87] RFC 2911 IPP/1.1: Model and Semantics September 2000 'text/plain; charset=ISO-8859-1': A plain text document in ISO 8859-1 (Latin 1) [ISO8859-1]. 'text/plain; charset=utf-8': A plain text document in ISO 10646 represented as UTF-8 [RFC2279] 'application/postscript': A PostScript document [RFC2046] 'application/vnd.hp-PCL': A PCL document [IANA-MT] (charset escape sequence embedded in the document data) 'application/pdf': Portable Document Format - see IANA MIME Media Type registry 'application/octet-stream': Auto-sense - see section 4.1.9.1 The maximum length of a 'mimeMediaType' value to represent IPP attribute values is 255 octets. 4.1.9.1 Application/octet-stream -- Auto-Sensing the document format One special type is 'application/octet-stream'. If the Printer object supports this value, the Printer object MUST be capable of auto-sensing the format of the document data using an implementation-dependent method that examines some number of octets of the document data, either as part of the create operation and/or at document processing time. During auto-sensing, a Printer may determine that the document-data has a format that the Printer doesn't recognize. If the Printer determines this problem before returning an operation response, it rejects the request and returns the 'client-error-document-format-not-supported&Daboo Expires April 7, 2010 [Page 71] Internet-Draft iTIP October 2009 3.6.22. Status Code 3.9 Status Code: 3.9 Status Description: Unsupported version. Status Exception Data: VERSION property name and value MAY be specified. Description: iTIP operation failed because the calendar data version is not supported. 3.6.23. Status Code 3.10 Status Code: 3.10 Status Description: Request entity too large. Status Exception Data: Request entity too large. Description: iTIP operation failed because the calendar data was too large. 3.6.24. Status Code 3.11 Status Code: 3.11 Status Description: Required component or property missing. Status Exception Data: Component or property name MAY be specified. Description: iTIP operation failed because the calendar data did not contain a required property or component. 3.6.25. Status Code 3.12 Status Code: 3.12 Status Description: Unknown component or property found. Status Exception Data: Component or property name MAY be specified. Description: iTIP operation failed because the calendar data contained an unknown property or component. 3.6.26. Status Code 3.13 Status Code: 3.13 Status Description: Unsupported component or property found. Status Exception Data: Component or property name MAY be specified. Description: iTIP operation failed because the calendar data contained an unsupported property or component. 3.6.27. Status Code 3.14 Status Code: 3.14 Daboo Expires April 7, 2010 [Page 72] Internet-Draft iTIP October 2009 Status Description: Unsupported capability. Status Exception Data: METHOD or action MAY be specified. Description: iTIP operation failed because the operation is not supported. 3.6.28. Status Code 4.0 Status Code: 4.0 Status Description: Event conflict. Date/time is busy. Status Exception Data: DTSTART and DTEND property name and values MAY be specified. Description: iTIP operation failed because the event overlaps the date and time of another event. 3.6.29. Status Code 5.0 Status Code: 5.0 Status Description: Request not supported. Status Exception Data: METHOD property value MAY be specified. Description: iTIP operation failed because the operation is not supported. 3.6.30. Status Code 5.1 Status Code: 5.1 Status Description: Service unavailable. Status Exception Data: ATTENDEE property value MAY be specified. Description: iTIP operation failed because scheduling is not active. 3.6.31. Status Code 5.2 Status Code: 5.2 Status Description: Invalid calendar service. Status Exception Data: ATTENDEE property value MAY be specified. Description: iTIP operation failed because there is no scheduling capability. 3.6.32. Status Code 5.3 Status Code: 5.3 Status Description: No scheduling support for user. Status Exception Data: ATTENDEE property value MAY be specified. Description: iTIP operation failed because scheduling is not enabled for an Attendee. Daboo Expires April 7, 2010 [Page 73] Internet-Draft iTIP October 2009 3.7. Implementation Considerations 3.7.1. Working With Recurrence Instances iCalendar includes a recurrence grammar to represent recurring events. The benefit of such a grammar is the ability to represent a number of events in a single object. However, while this simplifies creation of a recurring event, meeting instances still need to be referenced. For instance, an "Attendee" may decline the third instance of a recurring Friday event. Similarly, the "Organizer" may change the time or location to a single instance of the recurring event. Since implementations may elect to store recurring events as either a single event object or a collection of discrete, related event objects, the protocol is designed so that each recurring instance may be both referenced and versioned. Hence, implementations that choose to maintain per-instance properties (such as "ATTENDEE" property "PARTSTAT" parameter) may do so. However, the protocol does not require per-instance recognition unless the instance itself must be renegotiated. The scenarios for recurrence instance referencing are listed below. For purposes of simplification a change to an event refers to a "trigger property." That is, a property that has a substantive effect on the meeting itself such as start time, location, due date (for "VTODO" calendar component components) and possibly description. "Organizer" initiated actions: o "Organizer" deletes or changes a single instance of a recurring event o "Organizer" makes changes that affect all future instances o "Organizer" makes changes that affect all previous instances o "Organizer" deletes or modifies a previously changed instance "Attendee" initiated actions: o "Attendee" changes status for a particular recurrence instance o "Attendee" sends event-Counter for a particular recurrence instance An instance of a recurring event is assigned a unique identification, "RECURRENCE-ID" property, when that instance is renegotiated. Negotiation may be necessary when a substantive change to the event or to-do has been made (such as changing the start time, end time, due date or location). The "Organizer" can identify a specific recurrence instance using the "RECURRENCE-ID" property. The property Daboo Expires April 7, 2010 [Page 74] Internet-Draft iTIP October 2009 value is equal to the date/time of the instance. If the "Organizer" wishes to change the "DTSTART", the original unmodified "DTSTART" value of the instance is used as the value "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values reflect the change. 3.7.2. Attendee Property Considerations The "ORGANIZER" property is required on published events, to-dos, and journal entries for two reasons. First, only the "Organizer" is allowed to update and redistribute an event or to-do component. It follows that the "ORGANIZER" property MUST be present in the event, to-do, or journal entry component so that the CUA has a basis for authorizing an update. Second, it is prudent to provide a point of contact for anyone who receives a published component in case of problems. Email addresses that correspond to groups of calendar users could be specified as a mailto: URI [RFC2368] calendar user address. Sending email to such an address results in email being sent to multiple recipients. Such an address may be used as the value of an "ATTENDEE" property. Thus, it is possible that the recipient of a "REQUEST" does not appear explicitly in the list. It is recommended that the general approach to finding a "Calendar User" in an attendee list be as follows: 1. Search for the "Calendar User" in the attendee list where "CUTYPE=INDIVIDUAL" 2. Failing (1) look for attendees where "CUTYPE=GROUP" or 'CUTYPE=UNKNOWN". The CUA then determines if the "Calendar User" is a member of one of these groups. If so, the "REPLY" method sent to the "Organizer" MUST contain a new "ATTENDEE" property in which: 3. * the "TYPE" property parameter is set to INDIVIDUAL * the "MEMBER" property parameter is set to the name of the group 4. Failing (2) the CUA MAY ignore or accept the request as the "Calendar User" wishes. 3.7.3. Extension Tokens To make iCalendar objects extensible, new component, property or property parameters can be used. Two types of extension exist: IANA registered tokens and X- vendor-specific tokens. A client SHOULD save IANA tokens and MAY use them in replies. A client MAY save X- Tokens and MAY use them in replies. When delegating or forwarding messages to other CUs, a client SHOULD include IANA and X- tokens. Daboo Expires April 7, 2010 [Page 75] Internet-Draft iTIP October 2009 4. Examples 4.1. Published Event Examples In the calendaring and scheduling context, publication refers to the one way transfer of event information. Consumers of published events simply incorporate the event into a calendar. No reply is expected. Individual "A" publishes an event. Individual "B" reads the event and incorporates it into their calendar. Events are published in several ways including: embedding the event as an object in a web page, e-mailing the event to a distribution list, or posting the event to a newsgroup. The table below illustrates the sequence of events between the publisher and the consumers of a published event. +-----------------+-----------------------+-------------------------+ | Action | Organizer | Receiver | +-----------------+-----------------------+-------------------------+ | Publish an | "A" sends or posts a | "B' status code. If the Printer determines this problem after accepting the request and returning an operation response with one of the successful status codes, the Printer adds the 'unsupported-document-format' value to the job's "job-state-reasons" attribute. If the Printer object's default value attribute "document-format- default" is set to 'application/octet-stream', the Printer object not only supports auto-sensing of the document format, but will depend on the result of applying its auto-sensing when the client does not supply the "document-format" attribute. If the client supplies a document format value, the Printer MUST rely on the supplied attribute, rather than trust its auto-sensing algorithm. To summarize: 1. If the client does not supply a document format value, the Printer MUST rely on its default value setting (which may be 'application/octet-stream' indicating an auto-sensing mechanism). 2. If the client supplies a value other than 'application/octet- stream', the client is supplying valid information about the format of the document data and the Printer object MUST trust the client supplied value more than the outcome of applying an Hastings, et al. Standards Track [Page 88] RFC 2911 IPP/1.1: Model and Semantics September 2000 automatic format detection mechanism. For example, the client may be requesting the printing of a PostScript file as a 'text/plain' document. The Printer object MUST print a text representation of the PostScript commands rather than interpret the stream of PostScript commands and print the result. 3. If the client supplies a value of 'application/octet-stream', the client is indicating that the Printer object MUST use its auto-sensing mechanism on the client supplied document data whether auto-sensing is the Printer object's default or not. Note: Since the auto-sensing algorithm is probabilistic, if the client requests both auto-sensing ("document-format" set to 'application/octet-stream') and true fidelity ("ipp-attribute- fidelity" set to 'true'), the Printer object might not be able to guarantee exactly what the end user intended (the auto-sensing algorithm might mistake one document format for another), but it is able to guarantee that its auto-sensing mechanism be used. When a Printer performs auto-sensing of a document in a submitted job, it is RECOMMENDED that the Printer indicate to the user that such auto-sensing has occurred and which document-format was auto- sensed by printing that information on the job's job-start-sheet. 4.1.10 'octetString' The 'octetString' attribute syntax is a sequence of octets encoded in a maximum of 1023 octets which is indicated in sub-section headers using the notation: octetString(MAX). This syntax type is used for opaque data. 4.1.11 'boolean' The 'boolean' attribute syntax has only two values: 'true' and 'false'. 4.1.12 'integer' The 'integer' attribute syntax is an integer value that is in the range from -2**31 (MIN) to 2**31 - 1 (MAX). Each individual attribute may specify the range constraint explicitly in sub-section headers if the range is different from the full range of possible integer values. For example: job-priority (integer(1:100)) for the "job-priority" attribute. However, the enforcement of that additional constraint is up to the IPP objects, not the protocol. Hastings, et al. Standards Track [Page 89] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.1.13 'rangeOfInteger' The 'rangeOfInteger' attribute syntax is an ordered pair of integers that defines an inclusive range of integer values. The first integer specifies the lower bound and the second specifies the upper bound. If a range constraint is specified in the header description for an attribute in this document whose attribute syntax is 'rangeOfInteger' (i.e., 'X:Y' indicating X as a minimum value and Y as a maximum value), then the constraint applies to both integers. 4.1.14 'dateTime' The 'dateTime' attribute syntax is a standard, fixed length, 11 octet representation of the "DateAndTime" syntax as defined in RFC 2579 [RFC2579]. RFC 2579 also identifies an 8 octet representation of a "DateAndTime" value, but IPP objects MUST use the 11 octet representation. A user interface will provide a mapping between protocol dateTime values and displayable user-friendly words or presentation values and phrases which are localized to the natural language and date format of the user, including time zone. 4.1.15 'resolution' The 'resolution' attribute syntax specifies a two-dimensional resolution in the indicated units. It consists of 3 values: a cross feed direction resolution (positive integer value), a feed direction resolution (positive integer value), and a units value. The semantics of these three components are taken from the Printer MIB [RFC1759] suggested values. That is, the cross feed direction component resolution component is the same as the prtMarkerAddressabilityXFeedDir object in the Printer MIB, the feed direction component resolution component is the same as the prtMarkerAddressabilityFeedDir in the Printer MIB, and the units component is the same as the prtMarkerAddressabilityUnit object in the Printer MIB (namely, '3' indicates dots per inch and '4' indicates dots per centimeter). All three values MUST be present even if the first two values are the same. Example: '300', '600', '3' indicates a 300 dpi cross-feed direction resolution, a 600 dpi feed direction resolution, since a '3' indicates dots per inch (dpi). 4.1.16 '1setOf X' The '1setOf X' attribute syntax is 1 or more values of attribute syntax type X. This syntax type is used for multi-valued attributes. The syntax type is called '1setOf' rather than just 'setOf' as a reminder that the set of values MUST NOT be empty (i.e., a set of Hastings, et al. Standards Track [Page 90] RFC 2911 IPP/1.1: Model and Semantics September 2000 size 0). Sets are normally unordered. However each attribute description of this type may specify that the values MUST be in a certain order for that attribute. 4.2 Job Template Attributes Job Template attributes describe job processing behavior. Support for Job Template attributes by a Printer object is OPTIONAL (see section 12.2.3 for a description of support for OPTIONAL attributes). Also, clients OPTIONALLY supply Job Template attributes in create requests. Job Template attributes conform to the following rules. For each Job Template attribute called "xxx": 1. If the Printer object supports "xxx" then it MUST support both a "xxx-default" attribute (unless there is a "No" in the table below) and a "xxx-supported" attribute. If the Printer object doesn't support "xxx", then it MUST support neither an "xxx- default" attribute nor an "xxx-supported" attribute, and it MUST treat an attribute "xxx" supplied by a client as unsupported. An attribute "xxx" may be supported for some document formats and not supported for other document formats. For example, it is expected that a Printer object would only support "orientation-requested" for some document formats (such as 'text/plain' or 'text/html') but not others (such as 'application/postscript'). 2. "xxx" is OPTIONALLY supplied by the client in a create request. If "xxx" is supplied, the client is indicating a desired job processing behavior for this Job. When "xxx" is not supplied, the client is indicating that the Printer object apply its default job processing behavior at job processing time if the document content does not contain an embedded instruction indicating an xxx-related behavior. Since an administrator MAY change the default value attribute after a Job object has been submitted but before it has been processed, the default value used by the Printer object at job processing time may be different that the default value in effect at job submission time. 3. The "xxx-supported" attribute is a Printer object attribute that describes which job processing behaviors are supported by that Printer object. A client can query the Printer object to find out what xxx-related behaviors are supported by inspecting the returned values of the "xxx-supported" attribute. Hastings, et al. Standards Track [Page 91] RFC 2911 IPP/1.1: Model and Semantics September 2000 Note: The "xxx" in each "xxx-supported" attribute name is singular, even though an "xxx-supported" attribute usually has more than one value, such as "job-sheet-supported", unless the "xxx" Job Template attribute is plural, such as "finishings" or "sides". In such cases the "xxx-supported" attribute names are: "finishings- supported" and "sides-supported". 4. The "xxx-default" default value attribute describes what will be done at job processing time when no other job processing information is supplied by the client (either explicitly as an IPP attribute in the create request or implicitly as an embedded instruction within the document data). If an application wishes to present an end user with a list of supported values from which to choose, the application SHOULD query the Printer object for its supported value attributes. The application SHOULD also query the default value attributes. If the application then limits selectable values to only those value that are supported, the application can guarantee that the values supplied by the client in the create request all fall within the set of supported values at the Printer. When querying the Printer, the client MAY enumerate each attribute by name in the Get-Printer- Attributes Request, or the client MAY just name the "job-template" group in order to get the complete set of supported attributes (both supported and default attributes). The "finishings" attribute is an example of a Job Template attribute. It can take on a set of values such as 'staple', 'punch', and/or 'cover'. A client can query the Printer object for the "finishings- supported" attribute and the "finishings-default" attribute. The supported attribute contains a set of supported values. The default value attribute contains the finishing value(s) that will be used for a new Job if the client does not supply a "finishings" attribute in the create request and the document data does not contain any corresponding finishing instructions. If the client does supply the "finishings" attribute in the create request, the IPP object validates the value or values to make sure that they are a subset of the supported values identified in the Printer object's "finishings- supported" attribute. See section 3.1.7. The table below summarizes the names and relationships for all Job Template attributes. The first column of the table (labeled "Job Attribute") shows the name and syntax for each Job Template attribute in the Job object. These are the attributes that can optionally be supplied by the client in a create request. The last two columns (labeled "Printer: Default Value Attribute" and "Printer: Supported Values Attribute") show the name and syntax for each Job Template attribute in the Printer object (the default value attribute and the Hastings, et al. Standards Track [Page 92] RFC 2911 IPP/1.1: Model and Semantics September 2000 supported values attribute). A "No" in the table means the Printer MUST NOT support the attribute (that is, the attribute is simply not applicable). For brevity in the table, the 'text' and 'name' entries do not show the maximum length for each attribute. +===================+======================+======================+ | Job Attribute |Printer: Default Value| Printer: Supported | | | Attribute | Values Attribute | +===================+======================+======================+ | job-priority | job-priority-default |job-priority-supported| | (integer 1:100) | (integer 1:100) |(integer 1:100) | +-------------------+----------------------+----------------------+ | job-hold-until | job-hold-until- |job-hold-until- | | (type3 keyword | | default | supported | | name) | (type3 keyword | |(1setOf ( | | | name) |type3 keyword | name))| +-------------------+----------------------+----------------------+ | job-sheets | job-sheets-default |job-sheets-supported | | (type3 keyword | | (type3 keyword | |(1setOf ( | | name) | name) |type3 keyword | name))| +-------------------+----------------------+----------------------+ |multiple-document- |multiple-document- |multiple-document- | | handling | handling-default |handling-supported | | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)| +-------------------+----------------------+----------------------+ | copies | copies-default | copies-supported | | (integer (1:MAX)) | (integer (1:MAX)) | (rangeOfInteger | | | | (1:MAX)) | +-------------------+----------------------+----------------------+ | finishings | finishings-default | finishings-supported | |(1setOf type2 enum)|(1setOf type2 enum) |(1setOf type2 enum) | +-------------------+----------------------+----------------------+ | page-ranges | No | page-ranges- | | (1setOf | | supported (boolean) | | rangeOfInteger | | | | (1:MAX)) | | | +-------------------+----------------------+----------------------+ | sides | sides-default | sides-supported | | (type2 keyword) | (type2 keyword) |(1setOf type2 keyword)| +-------------------+----------------------+----------------------+ | number-up | number-up-default | number-up-supported | | (integer (1:MAX)) | (integer (1:MAX)) |(1setOf (integer | | | | (1:MAX) | | | | | rangeOfInteger | | | | (1:MAX))) | Hastings, et al. Standards Track [Page 93] RFC 2911 IPP/1.1: Model and Semantics September 2000 +-------------------+----------------------+----------------------+ | orientation- |orientation-requested-|orientation-requested-| | requested | default | supported | | (type2 enum) | (type2 enum) | (1setOf type2 enum) | +-------------------+----------------------+----------------------+ | media | media-default | media-supported | | (type3 keyword | | (type3 keyword | |(1setOf ( | | name) | name) |type3 keyword | name))| | | | | | | | media-ready | | | |(1setOf ( | | | |type3 keyword | name))| +-------------------+----------------------+----------------------+ | printer-resolution| printer-resolution- | printer-resolution- | | (resolution) | default | supported | | | (resolution) |(1setOf resolution) | +-------------------+----------------------+----------------------+ | print-quality | print-quality-default| print-quality- | | (type2 enum) | (type2 enum) | supported | | | |(1setOf type2 enum) | +-------------------+----------------------+----------------------+ 4.2.1 job-priority (integer(1:100)) This attribute specifies a priority for scheduling the Job. A higher value specifies a higher priority. The value 1 indicates the lowest possible priority. The value 100 indicates the highest possible priority. Among those jobs that are ready to print, a Printer MUST print all jobs with a priority value of n before printing those with a priority value of n-1 for all n. If the Printer object supports this attribute, it MUST always support the full range from 1 to 100. No administrative restrictions are permitted. This way an end-user can always make full use of the entire range with any Printer object. If privileged jobs are implemented outside IPP/1.1, they MUST have priorities higher than 100, rather than restricting the range available to end-users. If the client does not supply this attribute and this attribute is supported by the Printer object, the Printer object MUST use the value of the Printer object's "job-priority-default" at job submission time (unlike most Job Template attributes that are used if necessary at job processing time). The syntax for the "job-priority-supported" is also integer(1:100). This single integer value indicates the number of priority levels supported. The Printer object MUST take the value supplied by the client and map it to the closest integer in a sequence of n integers Hastings, et al. Standards Track [Page 94] RFC 2911 IPP/1.1: Model and Semantics September 2000 values that are evenly distributed over the range from 1 to 100 using the formula: roundToNearestInt((100x+50)/n) where n is the value of "job-priority-supported" and x ranges from 0 through n-1. For example, if n=1 the sequence of values is 50; if n=2, the sequence of values is: 25 and 75; if n = 3, the sequence of values is: 17, 50 and 83; if n = 10, the sequence of values is: 5, 15, 25, 35, 45, 55, 65, 75, 85, and 95; if n = 100, the sequence of values is: 1, 2, 3, ... 100. If the value of the Printer object's "job-priority-supported" is 10 and the client supplies values in the range 1 to 10, the Printer object maps them to 5, in the range 11 to 20, the Printer object maps them to 15, etc. 4.2.2 job-hold-until (type3 keyword | name (MAX)) This attribute specifies the named time period during which the Job MUST become a candidate for printing. Standard keyword values for named time periods are: 'no-hold': immediately, if there are not other reasons to hold the job 'indefinite': - the job is held indefinitely, until a client performs a Release-Job (section 3.3.6) 'day-time': during the day 'evening': evening 'night': night 'weekend': weekend 'second-shift': second-shift (after close of business) 'third-shift': third-shift (after midnight) An administrator MUST associate allowable print times with a named time period (by means outside the scope of this IPP/1.1 document). An administrator is encouraged to pick names that suggest the type of time period. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. If the value of this attribute specifies a time period that is in the future, the Printer SHOULD add the 'job-hold-until-specified' value to the job's "job-state-reasons" attribute, MUST move the job to the Hastings, et al. Standards Track [Page 95] RFC 2911 IPP/1.1: Model and Semantics September 2000 'pending-held' state, and MUST NOT schedule the job for printing until the specified time-period arrives. When the specified time period arrives, the Printer MUST remove the 'job-hold-until-specified' value from the job's "job-state-reason" attribute, if present. If there are no other job state reasons that keep the job in the 'pending-held' state, the Printer MUST consider the job as a candidate for processing by moving the job to the 'pending' state. If this job attribute value is the named value 'no-hold', or the specified time period has already started, the job MUST be a candidate for processing immediately. If the client does not supply this attribute and this attribute is supported by the Printer object, the Printer object MUST use the value of the Printer object's "job-hold-until-default" at job submission time (unlike most Job Template attributes that are used if necessary at job processing time). 4.2.3 job-sheets (type3 keyword | name(MAX)) This attribute determines which job start/end sheet(s), if any, MUST be printed with a job. Standard keyword values are: 'none': no job sheet is printed 'standard': one or more site specific standard job sheets are printed, e.g. a single start sheet or both start and end sheet is printed An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. The effect of this attribute on jobs with multiple documents MAY be affected by the "multiple-document-handling" job attribute (section 4.2.4), depending on the job sheet semantics. 4.2.4 multiple-document-handling (type2 keyword) This attribute is relevant only if a job consists of two or more documents. This attribute MUST be supported with at least one value if the Printer supports multiple documents per job (see sections 3.2.4 and 3.3.1). The attribute controls finishing operations and the placement of one or more print-stream pages into impressions and onto media sheets. When the value of the "copies" attribute exceeds 1, it also controls the order in which the copies that result from Hastings, et al. Standards Track [Page 96] RFC 2911 IPP/1.1: Model and Semantics September 2000 processing the documents are produced. For the purposes of this explanations, if "a" represents an instance of document data, then the result of processing the data in document "a" is a sequence of media sheets represented by "a(*)". Standard keyword values are: 'single-document': If a Job object has multiple documents, say, the document data is called a and b, then the result of processing all the document data (a and then b) MUST be treated as a single sequence of media sheets for finishing operations; that is, finishing would be performed on the concatenation of the sequences a(*),b(*). The Printer object MUST NOT force the data in each document instance to be formatted onto a new print-stream page, nor to start a new impression on a new media sheet. If more than one copy is made, the ordering of the sets of media sheets resulting from processing the document data MUST be a(*), b(*), a(*), b(*), start on a new media sheet. 'separate-documents-uncollated-copies': If a Job object has multiple documents, say, the document data is called a and b, then the result of processing the data in each document instance MUST be treated as a single sequence of media sheets for finishing operations; that is, the sets a(*) and b(*) would each be finished separately. The Printer object MUST force each copy of the result of processing the data in a single document to start on a new media sheet. If more than one copy is made, the ordering of the sets of media sheets resulting from processing the document data MUST be a(*), a(*), ..., b(*), b(*) ... . 'separate-documents-collated-copies': If a Job object has multiple documents, say, the document data is called a and b, then the result of processing the data in each document instance MUST be treated as a single sequence of media sheets for finishing operations; that is, the sets a(*) and b(*) would each be finished separately. The Printer object MUST force each copy of the result of processing the data in a single document to start on a new media sheet. If more than one copy is made, the ordering of the sets of media sheets resulting from processing the document data MUST be a(*), b(*), a(*), b(*), ... . 'single-document-new-sheet': Same as 'single-document', except that the Printer object MUST ensure that the first impression of each document instance in the job is placed on a new media sheet. This value allows multiple documents to be stapled together with a single staple where each document starts on a new sheet. Hastings, et al. Standards Track [Page 97] RFC 2911 IPP/1.1: Model and Semantics September 2000 The 'single-document' value is the same as 'separate-documents- collated-copies' with respect to ordering of print-stream pages, but not media sheet generation, since 'single-document' will put the first page of the next document on the back side of a sheet if an odd number of pages have been produced so far for the job, while 'separate-documents-collated- copies' always forces the next document or document copy on to a new sheet. In addition, if the "finishings" attribute specifies 'staple', then with 'single-document', documents a and b are stapled together as a single document with no regard to new sheets, with 'single-document-new-sheet', documents a and b are stapled together as a single document, but document b starts on a new sheet, but with 'separate-documents-uncollated-copies' and 'separate-documents-collated-copies', documents a and b are stapled separately. Note: None of these values provide means to produce uncollated sheets within a document, i.e., where multiple copies of sheet n are produced before sheet n+1 of the same document. The relationship of this attribute and the other attributes that control document processing is described in section 15.3. 4.2.5 copies (integer(1:MAX)) This attribute specifies the number of copies to be printed. On many devices the supported number of collated copies will be limited by the number of physical output bins on the device, and may be different from the number of uncollated copies which can be supported. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3. 4.2.6 finishings (1setOf type2 enum) This attribute identifies the finishing operations that the Printer uses for each copy of each printed document in the Job. For Jobs with multiple documents, the "multiple-document-handling" attribute determines what constitutes a "copy" for purposes of finishing. Hastings, et al. Standards Track [Page 98] RFC 2911 IPP/1.1: Model and Semantics September 2000 Standard enum values are: Value Symbolic Name and Description '3' 'none': Perform no finishing '4' 'staple': Bind the document(s) with one or more staples. The exact number and placement of the staples is site- defined. '5' 'punch': This value indicates that holes are required in the finished document. The exact number and placement of the holes is site-defined The punch specification MAY be satisfied (in a site- and implementation-specific manner) either by drilling/punching, or by substituting pre- drilled media. '6' 'cover': This value is specified when it is desired to select a non-printed (or pre-printed) cover for the document. This does not supplant the specification of a printed cover (on cover stock medium) by the document itself. '7' 'bind': This value indicates that a binding is to be applied to the document; the type and placement of the binding is site-defined. '8' 'saddle-stitch': Bind the document(s) with one or more staples (wire stitches) along the middle fold. The exact number and placement of the staples and the middle fold is implementation and/or site-defined. '9' 'edge-stitch': Bind the document(s) with one or more staples (wire stitches) along one edge. The exact number and placement of the staples is implementation and/or site- defined. '10'-'19' reserved for future generic finishing enum values. The following values are more specific; they indicate a corner or an edge as if the document were a portrait document (see below): '20' 'staple-top-left': Bind the document(s) with one or more staples in the top left corner. '21' 'staple-bottom-left': Bind the document(s) with one or more staples in the bottom left corner. '22' 'staple-top-right': Bind the document(s) with one or more staples in the top right corner. '23' 'staple-bottom-right': Bind the document(s) with one or more staples in the bottom right corner. '24' 'edge-stitch-left': Bind the document(s) with one or more staples (wire stitches) along the left edge. The exact number and placement of the staples is implementation and/or site-defined. quot; reads a published | | event | PUBLISH message | event | | | | | | Publish an | "A" sends or posts a | "B" reads the updated | | updated event | PUBLISH message | event | | | | | | Cancel a | "A" sends or posts a | "B" reads the canceled | | published event | CANCEL message | event publication | +-----------------+-----------------------+-------------------------+ 4.1.1. A Minimal Published Event The iCalendar object below describes a single event that begins on July 1, 1997 at 20:00 UTC. This event contains the minimum set of properties for a "PUBLISH" for a "VEVENT" calendar component. BEGIN:VCALENDAR METHOD:PUBLISH PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTART:19970701T200000Z DTSTAMP:19970611T190000Z SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES UID:0981234-1234234-23@example.com END:VEVENT END:VCALENDAR Daboo Expires April 7, 2010 [Page 76] Internet-Draft iTIP October 2009 4.1.2. Changing A Published Event The iCalendar object below describes an update to the event described in 4.1.1, the time has been changed, an end time has been added, and the sequence number has been adjusted. BEGIN:VCALENDAR METHOD:PUBLISH VERSION:2.0 PRODID:-//Example/ExampleCalendarClient//EN BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTAMP:19970612T190000Z DTSTART:19970701T210000Z DTEND:19970701T230000Z SEQUENCE:1 UID:0981234-1234234-23@example.com SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES END:VEVENT END:VCALENDAR The "UID" property is used by the client to identify the event. The "SEQUENCE" property indicates that this is a change to the event. The event with a matching UID and sequence number 0 is superseded by this event. The "SEQUENCE" property provides a reliable way to distinguish different versions of the same event. Each time an event is published, its sequence number is incremented. If a client receives an event with a sequence number 5 and finds it has the same event with sequence number 2, the event SHOULD be updated. However, if the client received an event with sequence number 2 and finds it already has sequence number 5 of the same event, the event MUST NOT be updated. 4.1.3. Canceling A Published Event The iCalendar object below cancels the event described in 4.1.1. This cancels the event with "SEQUENCE" property of 0, 1, and 2. Daboo Expires April 7, 2010 [Page 77] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:CANCEL VERSION:2.0 PRODID:-//Example/ExampleCalendarClient//EN BEGIN:VEVENT ORGANIZER:mailto:a@example.com COMMENT:DUKES forfeit the game SEQUENCE:2 UID:0981234-1234234-23@example.com DTSTAMP:19970613T190000Z END:VEVENT END:VCALENDAR 4.1.4. A Rich Published Event This example describes the same event as in 4.1.1, but in much greater detail. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:PUBLISH SCALE:GREGORIAN VERSION:2.0 BEGIN:VTIMEZONE TZID:America-Chicago TZURL:http://example.com/tz/America-Chicago BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0500 TZOFFSETTO:-0600 TZNAME:CST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0600 TZOFFSETTO:-0500 TZNAME:CDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTACH:http://www.example.com/ CATEGORIES:SPORTS EVENT,ENTERTAINMENT CLASS:PRIVATE Daboo Expires April 7, 2010 [Page 78] Internet-Draft iTIP October 2009 DESCRIPTION:MIDWAY STADIUM\n Big time game. MUST see.\n Expected duration:2 hours\n DTEND;TZID=America-Chicago:19970701T180000 DTSTART;TZID=America-Chicago:19970702T160000 DTSTAMP:19970614T190000Z STATUS:CONFIRMED LOCATION;VALUE=URI:http://stadium.example.com/ PRIORITY:2 RESOURCES:SCOREBOARD SEQUENCE:3 SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES UID:0981234-1234234-23@example.com RELATED-TO:0981234-1234234-14@example.com BEGIN:VALARM TRIGGER:-PT2H ACTION:DISPLAY DESCRIPTION:You should be leaving for the game now. END:VALARM BEGIN:VALARM TRIGGER:-PT30M ACTION:AUDIO END:VALARM END:VEVENT END:VCALENDAR The "RELATED-TO" field contains the "UID" property of a related calendar event. The "SEQUENCE" property 3 indicates that this event supersedes versions 0, 1, and 2. 4.1.5. Anniversaries or Events attached to entire days This example demonstrates the use of the "VALUE" parameter to tie a "VEVENT" to day rather than a specific time. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:PUBLISH VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com DTSTAMP:19970614T190000Z UID:0981234-1234234-23@example.com DTSTART;VALUE=DATE:19970714 RRULE:FREQ=YEARLY;INTERVAL=1 SUMMARY: Bastille Day Daboo Expires April 7, 2010 [Page 79] Internet-Draft iTIP October 2009 END:VEVENT END:VCALENDAR 4.2. Group Event Examples Group events are distinguished from published events in that they have "Attendees" and that there is interaction between the "Attendees" and the "Organizer" with respect to the event. Individual "A" requests a meeting between individuals "A", "B", "C" and "D". Individual "B" confirms attendance to the meeting. Individual "C" declines attendance. Individual "D" tentatively confirms attendance. The following table illustrates the the message flow between these individuals. A, the CU scheduling the meeting, is referenced as the "Organizer". +--------------+-----------------------+----------------------------+ | Action | "Organizer" | Attendee | +--------------+-----------------------+----------------------------+ | Initiate a | "A" sends a REQUEST | | | meeting | message to "B", "C", | | | request | and "D" | | | | | | | Accept the | | "B" sends a REPLY message | | meeting | | to "A" with its ATTENDEE | | request | | "PARTSTAT" parameter set | | | | to "ACCEPTED" | | | | | | Decline the | | "C" sends a REPLY message | | meeting | | to "A" with its ATTENDEE | | request | | "PARTSTAT" parameter set | | | | to "DECLINED" | | | | | | Tentatively | | "D" sends a REPLY message | | accept the | | to "A" with its ATTENDEE | | meeting | | "PARTSTAT" parameter set | | request | | to "TENTATIVE" | | | | | | Confirm | "A" sends a REQUEST | | | meeting | message to "B" and | | | status with | "D" with updated | | | attendees | information. | | +--------------+-----------------------+----------------------------+ Daboo Expires April 7, 2010 [Page 80] Internet-Draft iTIP October 2009 4.2.1. A Group Event Request A sample meeting request is sent from "A" to "B", "C", and "D". "E" is also sent a copy of the request but is not expected to attend and need not reply. "E" illustrates how CUAs might implement an "FYI" type feature. Note the use of the "ROLE" parameter. The default value for the "ROLE" parameter is "REQ-PARTICIPANT" and it need not be enumerated. In this case we are using the value "NON-PARTICIPANT" to indicate "E" is a non-attending CU. The parameter is not needed on other "Attendees" since "PARTICIPANT" is the default value. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=A:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=B:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=C:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com ATTENDEE;RSVP=FALSE;CUTYPE=ROOM:conf_big@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T2100000Z SUMMARY:Conference UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.2.2. Reply To A Group Event Request Attendee "B" accepts the meeting. Daboo Expires April 7, 2010 [Page 81] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com ORGANIZER:mailto:a@example.com UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 REQUEST-STATUS:2.0;Success DTSTAMP:19970612T190000Z END:VEVENT END:VCALENDAR "B" could have declined the meeting or indicated tentative acceptance by setting the "ATTENDEE" "PARTSTAT" parameter to "DECLINED" or "TENTATIVE", respectively. Also, "REQUEST-STATUS" is not required in successful transactions. 4.2.3. Update An Event The event is moved to a different time. The combination of the "UID" property (unchanged) and the "SEQUENCE" (bumped to 1) properties indicate the update. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL;CN=Hal:mailto:d@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE; CUTYPE=ROOM:mailto:conf@example.com ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:mailto:e@example.com DTSTART:19970701T180000Z DTEND:19970701T190000Z SUMMARY:Phone Conference UID:calsrv.example.com-873970198738777@example.com SEQUENCE:1 DTSTAMP:19970613T190000Z STATUS:CONFIRMED END:VEVENT Daboo Expires April 7, 2010 [Page 82] Internet-Draft iTIP October 2009 END:VCALENDAR 4.2.4. Countering an Event Proposal "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to "A" to change the time and location. "A" sends the following "REQUEST": BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com DTSTART:19970701T190000Z DTEND:19970701T200000Z SUMMARY:Discuss the Merits of the election results LOCATION:Green Conference Room UID:calsrv.example.com-873970198738777a@example.com SEQUENCE:0 DTSTAMP:19970611T190000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR "B" sends "COUNTER" to "A", requesting changes to time and place. "B" uses the "COMMENT" property to communicate a rationale for the change. Note that the "SEQUENCE" property is NOT incremented on a "COUNTER". Daboo Expires April 7, 2010 [Page 83] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:COUNTER VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com DTSTART:19970701T160000Z DTEND:19970701T170000Z DTSTAMP:19970612T190000Z SUMMARY:Discuss the Merits of the election results LOCATION:Blue Conference Room COMMENT:This time works much better and I think the big conference room is too big UID:calsrv.example.com-873970198738777a@example.com SEQUENCE:0 END:VEVENT END:VCALENDAR "A" accepts the changes from "B". To accept a counter-proposal, the "Organizer" sends a new event "REQUEST" with an incremented sequence number. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:c@example.com DTSTAMP:19970613T190000Z DTSTART:19970701T160000Z DTEND:19970701T170000Z SUMMARY:Discuss the Merits of the election results - changed to meet B's schedule LOCATION:Blue Conference Room UID:calsrv.example.com-873970198738777@example.com SEQUENCE:1 STATUS:CONFIRMED END:VEVENT END:VCALENDAR Daboo Expires April 7, 2010 [Page 84] Internet-Draft iTIP October 2009 Instead, "A" rejects "B's" counter proposal BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:DECLINECOUNTER VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com COMMENT:Sorry, I cannot change this meeting time UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 DTSTAMP:19970614T190000Z END:VEVENT END:VCALENDAR 4.2.5. Delegating an Event When delegating an event request to another "Calendar User", the "Delegator" must both update the "Organizer" with a "REPLY" and send a request to the "Delegate". There is currently no protocol limitation to delegation depth. It is possible for the original delegate to delegate the meeting to someone else, and so on. When a request is delegated from one CUA to another there are a number of responsibilities required of the "Delegator". The "Delegator" MUST: o Send a "REPLY" to the "Organizer" with the following updates: A. The "Delegator's" "ATTENDEE" property "PARTSTAT" parameter set to "DELEGATED" and the "DELEGATED-TO" parameter is set to the address of the "DelegateHastings, et al. Standards Track [Page 99] RFC 2911 IPP/1.1: Model and Semantics September 2000 '25' 'edge-stitch-top': Bind the document(s) with one or more staples (wire stitches) along the top edge. The exact number and placement of the staples is implementation and/or site-defined. '26' 'edge-stitch-right': Bind the document(s) with one or more staples (wire stitches) along the right edge. The exact number and placement of the staples is implementation and/or site-defined. '27' 'edge-stitch-bottom': Bind the document(s) with one or more staples (wire stitches) along the bottom edge. The exact number and placement of the staples is implementation and/or site-defined. '28' 'staple-dual-left': Bind the document(s) with two staples (wire stitches) along the left edge assuming a portrait document (see above). '29' 'staple-dual-top': Bind the document(s) with two staples (wire stitches) along the top edge assuming a portrait document (see above). '30' 'staple-dual-right': Bind the document(s) with two staples (wire stitches) along the right edge assuming a portrait document (see above). '31' 'staple-dual-bottom': Bind the document(s) with two staples (wire stitches) along the bottom edge assuming a portrait document (see above). The 'staple-xxx' values are specified with respect to the document as if the document were a portrait document. If the document is actually a landscape or a reverse-landscape document, the client supplies the appropriate transformed value. For example, to position a staple in the upper left hand corner of a landscape document when held for reading, the client supplies the 'staple-bottom-left' value (since landscape is defined as a +90 degree rotation of the image with respect to the media from portrait, i.e., anti-clockwise). On the other hand, to position a staple in the upper left hand corner of a reverse-landscape document when held for reading, the client supplies the 'staple-top-right' value (since reverse-landscape is defined as a -90 degree rotation of the image with respect to the media from portrait, i.e., clockwise). The angle (vertical, horizontal, angled) of each staple with respect to the document depends on the implementation which may in turn depend on the value of the attribute. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3. Hastings, et al. Standards Track [Page 100] RFC 2911 IPP/1.1: Model and Semantics September 2000 If the client supplies a value of 'none' along with any other combination of values, it is the same as if only that other combination of values had been supplied (that is the 'none' value has no effect). 4.2.7 page-ranges (1setOf rangeOfInteger (1:MAX)) This attribute identifies the range(s) of print-stream pages that the Printer object uses for each copy of each document which are to be printed. Nothing is printed for any pages identified that do not exist in the document(s). Ranges MUST be in ascending order, for example: 1-3, 5-7, 15-19 and MUST NOT overlap, so that a non-spooling Printer object can process the job in a single pass. If the ranges are not ascending or are overlapping, the IPP object MUST reject the request and return the 'client-error-bad-request' status code. The attribute is associated with print-stream pages not application- numbered pages (for example, the page numbers found in the headers and or footers for certain word processing applications). For Jobs with multiple documents, the "multiple-document-handling" attribute determines what constitutes a "copy" for purposes of the specified page range(s). When "multiple-document-handling" is 'single-document', the Printer object MUST apply each supplied page range once to the concatenation of the print-stream pages. For example, if there are 8 documents of 10 pages each, the page-range '41:60' prints the pages in the 5th and 6th documents as a single document and none of the pages of the other documents are printed. When "multiple-document- handling" is 'separate-documents- uncollated-copies' or 'separate-documents-collated-copies', the Printer object MUST apply each supplied page range repeatedly to each document copy. For the same job, the page-range '1:3, 10:10' would print the first 3 pages and the 10th page of each of the 8 documents in the Job, as 8 separate documents. In most cases, the exact pages to be printed will be generated by a device driver and this attribute would not be required. However, when printing an archived document which has already been formatted, the end user may elect to print just a subset of the pages contained in the document. In this case, if page-range = n.m is specified, the first page to be printed will be page n. All subsequent pages of the document will be printed through and including page m. "page-ranges-supported" is a boolean value indicating whether or not the printer is capable of supporting the printing of page ranges. This capability may differ from one PDL to another. There is no "page-ranges-default" attribute. If the "page-ranges" attribute is not supplied by the client, all pages of the document will be printed. Hastings, et al. Standards Track [Page 101] RFC 2911 IPP/1.1: Model and Semantics September 2000 Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3. 4.2.8 sides (type2 keyword) This attribute specifies how print-stream pages are to be imposed upon the sides of an instance of a selected medium, i.e., an impression. The standard keyword values are: 'one-sided': imposes each consecutive print-stream page upon the same side of consecutive media sheets. 'two-sided-long-edge': imposes each consecutive pair of print- stream pages upon front and back sides of consecutive media sheets, such that the orientation of each pair of print-stream pages on the medium would be correct for the reader as if for binding on the long edge. This imposition is sometimes called 'duplex' or 'head-to-head'. 'two-sided-short-edge': imposes each consecutive pair of print- stream pages upon front and back sides of consecutive media sheets, such that the orientation of each pair of print-stream pages on the medium would be correct for the reader as if for binding on the short edge. This imposition is sometimes called 'tumble' or 'head-to-toe'. 'two-sided-long-edge', 'two-sided-short-edge', 'tumble', and 'duplex' all work the same for portrait or landscape. However 'head-to-toe' is 'tumble' in portrait but 'duplex" B. Add an additional "ATTENDEE" property for the "Delegate" with the "DELEGATED-FROM" property parameter set to the "Delegator" C. Indicate whether they want to continue to receive updates when the "Organizer" sends out updated versions of the event. Setting the "RSVP" property parameter to "TRUE" will cause the updates to be sent, setting it to "FALSE" causes no further updates to be sent. Note that in either case, if the "Delegate" declines the invitation the "Delegator" will be notified. o The "Delegator" MUST also send a copy of the original "REQUEST" method to the "Delegate", with changes (A) and (B) as detailed above applied. If the "Delegate" declines the meeting, the "Organizer" MUST send an update "REQUEST" to the "Delegator" so that the "Delegator" may elect to delegate the "REQUEST" to another CUA. Daboo Expires April 7, 2010 [Page 85] Internet-Draft iTIP October 2009 +-----------------+----------------+--------------------------------+ | Action | "Organizer" | Attendee | +-----------------+----------------+--------------------------------+ | Initiate a | "A" sends a | | | meeting request | REQUEST | | | | message to "B" | | | | and "C" | | | | | | | Delegate: "C" | | "C" sends a REPLY to "A" with | | delegates to | | the ATTENDEE "PARTSTAT" | | "E" | | parameter set to "DELEGATED" | | | | and with a new "ATTENDEE" | | | | property for "E". "E's" | | | | ATTENDEE "DELEGATED-FROM" | | | | parameter is set to "C". | | | | "C's" ATTENDEE "DELEGATED-TO" | | | | parameter is set to "E". "C" | | | | sends REQUEST message to "E" | | | | with the original meeting | | | | request information. The | | | | "PARTSTAT" property parameter | | | | for "C" is set to "DELEGATED" | | | | and the "DELEGATED-TO" | | | | parameter is set to the | | | | address of "E". An "ATTENDEE" | | | | property is added for "E" and | | | | the "DELEGATED-FROM" parameter | | | | is set to the address of "C". | | | | | | Confirm meeting | | "E" sends REPLY message to "A" | | attendance | | and optionally "C" with its | | | | "PARTSTAT" property parameter | | | | set to "ACCEPTED" | | | | | | Optional: | "A" sends | | | Redistribute | REQUEST | | | meeting to | message to | | | attendees | "B", "C" and | | | | "E". | | +-----------------+----------------+--------------------------------+ "C" responds to the "Organizer". Daboo Expires April 7, 2010 [Page 86] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- TO="mailto:e@example.com":mailto:c@example.com UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 REQUEST-STATUS:2.0;Success DTSTAMP:19970611T190000Z END:VEVENT END:VCALENDAR Attendee &Hastings, et al. Standards Track [Page 102] RFC 2911 IPP/1.1: Model and Semantics September 2000 Value Description '1' the Printer MUST place one print-stream page on a single side of an instance of the selected medium (MAY add some sort of translation, scaling, or rotation). '2' the Printer MUST place two print-stream pages on a single side of an instance of the selected medium (MAY add some sort of translation, scaling, or rotation). '4' the Printer MUST place four print-stream pages on a single side of an instance of the selected medium (MAY add some sort of translation, scaling, or rotation). This attribute primarily controls the translation, scaling and rotation of print-stream pages. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3. 4.2.10 orientation-requested (type2 enum) This attribute indicates the desired orientation for printed print- stream pages; it does not describe the orientation of the client- supplied print-stream pages. For some document formats (such as 'application/postscript'), the desired orientation of the print-stream pages is specified within the document data. This information is generated by a device driver prior to the submission of the print job. Other document formats (such as 'text/plain') do not include the notion of desired orientation within the document data. In the latter case it is possible for the Printer object to bind the desired orientation to the document data after it has been submitted. It is expected that a Printer object would only support "orientations-requested" for some document formats (e.g., 'text/plain' or 'text/html') but not others (e.g., 'application/postscript'). This is no different than any other Job Template attribute since section 4.2, item 1, points out that a Printer object may support or not support any Job Template attribute based on the document format supplied by the client. However, a special mention is made here since it is very likely that a Printer object will support "orientation-requested" for only a subset of the supported document formats. Hastings, et al. Standards Track [Page 103] RFC 2911 IPP/1.1: Model and Semantics September 2000 Standard enum values are: Value Symbolic Name and Description '3' 'portrait': The content will be imaged across the short edge of the medium. '4' 'landscape': The content will be imaged across the long edge of the medium. Landscape is defined to be a rotation of the print-stream page to be imaged by +90 degrees with respect to the medium (i.e. anti-clockwise) from the portrait orientation. Note: The +90 direction was chosen because simple finishing on the long edge is the same edge whether portrait or landscape '5' 'reverse-landscape': The content will be imaged across the long edge of the medium. Reverse-landscape is defined to be a rotation of the print-stream page to be imaged by - 90 degrees with respect to the medium (i.e. clockwise) from the portrait orientation. Note: The 'reverse- landscape' value was added because some applications rotate landscape -90 degrees from portrait, rather than +90 degrees. '6' 'reverse-portrait': The content will be imaged across the short edge of the medium. Reverse-portrait is defined to be a rotation of the print-stream page to be imaged by 180 degrees with respect to the medium from the portrait orientation. Note: The 'reverse-portrait' value was added for use with the "finishings" attribute in cases where the opposite edge is desired for finishing a portrait document on simple finishing devices that have only one finishing position. Thus a 'text'/plain' portrait document can be stapled "on the right" by a simple finishing device as is common use with some middle eastern languages such as Hebrew. Note: The effect of this attribute on jobs with multiple documents is controlled by the "multiple-document-handling" job attribute (section 4.2.4) and the relationship of this attribute and the other attributes that control document processing is described in section 15.3. 4.2.11 media (type3 keyword | name(MAX)) This attribute identifies the medium that the Printer uses for all impressions of the Job. The values for "media" include medium-names, medium-sizes, input- trays and electronic forms so that one attribute specifies the media. If a Printer object supports a medium name as a value of this Hastings, et al. Standards Track [Page 104] RFC 2911 IPP/1.1: Model and Semantics September 2000 attribute, such a medium name implicitly selects an input-tray that contains the specified medium. If a Printer object supports a medium size as a value of this attribute, such a medium size implicitly selects a medium name that in turn implicitly selects an input-tray that contains the medium with the specified size. If a Printer object supports an input-tray as the value of this attribute, such an input-tray implicitly selects the medium that is in that input-tray at the time the job prints. This case includes manual-feed input- trays. If a Printer object supports an electronic form as the value of this attribute, such an electronic form implicitly selects a medium-name that in turn implicitly selects an input-tray that contains the medium specified by the electronic form. The electronic form also implicitly selects an image that the Printer MUST merge with the document data as its prints each page. Standard keyword values are taken from ISO DPA [ISO10175], the Printer MIB [RFC1759], and ASME-Y14.1M [ASME-Y14.1M] and are listed in section 14. An administrator MAY define additional values using the 'name' or 'keyword' attribute syntax, depending on implementation. There is also an additional Printer attribute named "media-ready" which differs from "media-supported" in that legal values only include the subset of "media-supported" values that are physically loaded and ready for printing with no operator intervention required. If an IPP object supports "media-supported", it NEED NOT support "media-ready". The relationship of this attribute and the other attributes that control document processing is described in section 15.3. 4.2.12 printer-resolution (resolution) This attribute identifies the resolution that Printer uses for the Job. 4.2.13 print-quality (type2 enum) This attribute specifies the print quality that the Printer uses for the Job. The standard enum values are: Value Symbolic Name and Description '3' 'draft': lowest quality available on the printer '4' 'normal': normal or intermediate quality on the printer '5' 'high': highest quality available on the printer Hastings, et al. Standards Track [Page 105] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.3 Job Description Attributes The attributes in this section form the attribute group called "job- description". The following table summarizes these attributes. The third column indicates whether the attribute is a REQUIRED attribute that MUST be supported by Printer objects. If it is not indicated as REQUIRED, then it is OPTIONAL. The maximum size in octets for 'text' and 'name' attributes is indicated in parenthesizes. +----------------------------+----------------------+--------------+ | Attribute | Syntax | REQUIRED? | +----------------------------+----------------------+--------------+ | job-uri | uri | REQUIRED | +----------------------------+----------------------+--------------+ | job-id | integer(1:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-printer-uri | uri | REQUIRED | +----------------------------+----------------------+--------------+ | job-more-info | uri | | +----------------------------+----------------------+--------------+ | job-name | name (MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-originating-user-name | name (MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-state | type1 enum | REQUIRED | +----------------------------+----------------------+--------------+ | job-state-reasons | 1setOf type2 keyword | REQUIRED | +----------------------------+----------------------+--------------+ | job-state-message | text (MAX) | | +----------------------------+----------------------+--------------+ | job-detailed-status- | 1setOf text (MAX) | | | messages | | | +----------------------------+----------------------+--------------+ | job-document-access-errors | 1setOf text (MAX) | | +----------------------------+----------------------+--------------+ | number-of-documents | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | output-device-assigned | name (127) | | +----------------------------+----------------------+--------------+ | time-at-creation | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | time-at-processing | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | time-at-completed | integer (MIN:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | job-printer-up-time | integer (1:MAX) | REQUIRED | +----------------------------+----------------------+--------------+ | date-time-at-creation | dateTime | | Hastings, et al. Standards Track [Page 106] RFC 2911 IPP/1.1: Model and Semantics September 2000 +----------------------------+----------------------+--------------+ | date-time-at-processing | dateTime | | +----------------------------+----------------------+--------------+ | date-time-at-completed | dateTime | | +----------------------------+----------------------+--------------+ | number-of-intervening-jobs | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-message-from-operator | text (127) | | +----------------------------+----------------------+--------------+ | job-k-octets | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-impressions | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-media-sheets | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-k-octets-processed | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-impressions-completed | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | job-media-sheets-completed | integer (0:MAX) | | +----------------------------+----------------------+--------------+ | attributes-charset | charset | REQUIRED | +----------------------------+----------------------+--------------+ | attributes-natural-language| naturalLanguage | REQUIRED | +----------------------------+----------------------+--------------+ 4.3.1 job-uri (uri) This REQUIRED attribute contains the URI for the job. The Printer object, on receipt of a new job, generates a URI which identifies the new Job. The Printer object returns the value of the "job-uri" attribute as part of the response to a create request. The precise format of a Job URI is implementation dependent. If the Printer object supports more than one URI and there is some relationship between the newly formed Job URI and the Printer object's URI, the Printer object uses the Printer URI supplied by the client in the create request. For example, if the create request comes in over a secure channel, the new Job URI MUST use the same secure channel. This can be guaranteed because the Printer object is responsible for generating the Job URI and the Printer object is aware of its security configuration and policy as well as the Printer URI used in the create request. For a description of this attribute and its relationship to "job-id" and "job-printer-uri" attribute, see the discussion in section 2.4 on "Object Identity". Hastings, et al. Standards Track [Page 107] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.3.2 job-id (integer(1:MAX)) This REQUIRED attribute contains the ID of the job. The Printer, on receipt of a new job, generates an ID which identifies the new Job on that Printer. The Printer returns the value of the "job-id" attribute as part of the response to a create request. The 0 value is not included to allow for compatibility with SNMP index values which also cannot be 0. For a description of this attribute and its relationship to "job-uri" and "job-printer-uri" attribute, see the discussion in section 2.4 on "Object Identity". 4.3.3 job-printer-uri (uri) This REQUIRED attribute identifies the Printer object that created this Job object. When a Printer object creates a Job object, it populates this attribute with the Printer object URI that was used in the create request. This attribute permits a client to identify the Printer object that created this Job object when only the Job object's URI is available to the client. The client queries the creating Printer object to determine which languages, charsets, operations, are supported for this Job. For a description of this attribute and its relationship to "job-uri" and "job-id" attribute, see the discussion in section 2.4 on "Object Identity". 4.3.4 job-more-info (uri) Similar to "printer-more-info", this attribute contains the URI referencing some resource with more information about this Job object, perhaps an HTML page containing information about the Job. 4.3.5 job-name (name(MAX)) This REQUIRED attribute is the name of the job. It is a name that is more user friendly than the "job-uri" attribute value. It does not need to be unique between Jobs. The Job's "job-name" attribute is set to the value supplied by the client in the "job-name" operation attribute in the create request (see Section 3.2.1.1). If, however, the "job-name" operation attribute is not supplied by the client in the create request, the Printer object, on creation of the Job, MUST generate a name. The printer SHOULD generate the value of the Job's "job-name" attribute from the first of the following sources that produces a value: 1) the "document-name" operation attribute of the Hastings, et al. Standards Track [Page 108] RFC 2911 IPP/1.1: Model and Semantics September 2000 first (or only) document, 2) the "document-URI" attribute of the first (or only) document, or 3) any other piece of Job specific and/or Document Content information. 4.3.6 job-originating-user-name (name(MAX)) This REQUIRED attribute contains the name of the end user that submitted the print job. The Printer object sets this attribute to the most authenticated printable name that it can obtain from the authentication service over which the IPP operation was received. Only if such is not available, does the Printer object use the value supplied by the client in the "requesting-user-name" operation attribute of the create operation (see Sections 4.4.2, 4.4.3, and 8). Note: The Printer object needs to keep an internal originating user id of some form, typically as a credential of a principal, with the Job object. Since such an internal attribute is implementation- dependent and not of interest to clients, it is not specified as a Job Description attribute. This originating user id is used for authorization checks (if any) on all subsequent operations. 4.3.7 job-state (type1 enum) This REQUIRED attribute identifies the current state of the job. Even though the IPP protocol defines seven values for job states (plus the out-of-band 'unknown' value - see Section 4.1), implementations only need to support those states which are appropriate for the particular implementation. In other words, a Printer supports only those job states implemented by the output device and available to the Printer object implementation. Standard enum values are: Values Symbolic Name and Description '3' 'pending': The job is a candidate to start processing, but is not yet processing. '4' 'pending-held': The job is not a candidate for processing for any number of reasons but will return to the 'pending' state as soon as the reasons are no longer present. The job's "job-state-reason" attribute MUST indicate why the job is no longer a candidate for processing. Hastings, et al. Standards Track [Page 109] RFC 2911 IPP/1.1: Model and Semantics September 2000 '5' 'processing': One or more of: 1. the job is using, or is attempting to use, one or more purely software processes that are analyzing, creating, or interpreting a PDL, etc., 2. the job is using, or is attempting to use, one or more hardware devices that are interpreting a PDL, making marks on a medium, and/or performing finishing, such as stapling, etc., 3. the Printer object has made the job ready for printing, but the output device is not yet printing it, either because the job hasn't reached the output device or because the job is queued in the output device or some other spooler, awaiting the output device to print it. When the job is in the 'processing' state, the entire job state includes the detailed status represented in the Printer object's "printer-state", "printer-state- reasons", and "printer-state-message" attributes. Implementations MAY, though they NEED NOT, include additional values in the job's "job-state-reasons" attribute to indicate the progress of the job, such as adding the 'job-printing' value to indicate when the output device is actually making marks on paper and/or the 'processing-to-stop-point' value to indicate that the IPP object is in the process of canceling or aborting the job. Most implementations won"C" delegates presence at the meeting to "E". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=DELEGATED;DELEGATED- TO="mailto:e@example.com":mailto:c@example.com ATTENDEE;RSVP=TRUE; DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com DTSTART:19970701T180000Z DTEND:19970701T200000Z SUMMARY:Phone Conference UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 STATUS:CONFIRMED DTSTAMP:19970611T190000Z END:VEVENT END:VCALENDAR 4.2.6. Delegate Accepts the Meeting To accept a delegated meeting, the delegate, "E", sends the following message to "A" and "C": Daboo Expires April 7, 2010 [Page 87] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED- FROM="mailto:c@example.com":mailto:e@example.com ATTENDEE;PARTSTAT=DELEGATED; DELEGATED-TO="mailto:e@example.com":mailto:c@example.com UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 REQUEST-STATUS:2.0;Success DTSTAMP:19970614T190000Z END:VEVENT END:VCALENDAR 4.2.7. Delegate Declines the Meeting In this example the "Delegate" declines the meeting request and sets the "ATTENDEE" property "PARTSTAT" parameter to "DECLINED". The "Organizer" SHOULD resend the "REQUEST" to "C" with the "PARTSTAT" parameter of the "Delegate" set to "DECLINED". This lets the "Delegator" know that the "Delegate" has declined and provides an opportunity to the "Delegator" to either accept the request or delegate it to another CU. Response from "E" to "A" and "C". Note the use of the "COMMENT" property "E" uses to indicate why the delegation was declined. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=DELEGATED; DELEGATED-TO="mailto:e@example.com":mailto:c@example.com ATTENDEE;PARTSTAT=DECLINED; DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com COMMENT:Sorry, I will be out of town at that time. UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 REQUEST-STATUS:2.0;Success DTSTAMP:19970614T190000Z END:VEVENT Daboo Expires April 7, 2010 [Page 88] Internet-Draft iTIP October 2009 END:VCALENDAR "A" resends the "REQUEST" method to "C". "A" may also wish to express the fact that the item was delegated in the "COMMENT" property. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=DECLINED; DELEGATED-FROM="mailto:c@example.com":mailto:e@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 SUMMARY:Phone Conference DTSTART:19970701T180000Z DTEND:19970701T200000Z DTSTAMP:19970614T200000Z COMMENT:DELEGATE (ATTENDEE mailto:e@example.com) DECLINED YOUR INVITATION END:VEVENT END:VCALENDAR 4.2.8. Forwarding an Event Request The protocol does not prevent an "Attendee" from "forwarding" an "VEVENT" calendar component to other "Calendar Users". Forwarding differs from delegation in that the forwarded "Calendar User" (often referred to as a "Party Crasher") does not replace the forwarding "Calendar User". Implementations are not required to add the "Party Crasher" to the "Attendee" list and hence there is no guarantee that a "Party Crasher" will receive additional updates to the event. The forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the attendee list. The "Organizer" MAY add the forwarded "Calendar User" to the attendee list. 4.2.9. Cancel A Group Event Individual "A" requests a meeting between individuals "A", "B", "C", and "D". Individual "B" declines attendance to the meeting. Individual "A" decides to cancel the meeting. The following table illustrates the sequence of messages that would be exchanged between Daboo Expires April 7, 2010 [Page 89] Internet-Draft iTIP October 2009 these individuals. Messages related to a previously canceled event ("SEQUENCE" property value is less than the "SEQUENCE" property value of the "CANCEL" message) MUST be ignored. +-------------+--------------------+--------------------------------+ | Action | "Organizer" | "Attendee" | +-------------+--------------------+--------------------------------+ | Initiate a | "A" sends a | | | meeting | REQUEST message to | | | request | "B", "C", and "D" | | | | | | | Decline the | | "B" sends a "REPLY" message to | | meeting | | "A" with its "PARTSTAT" | | request | | parameter set to "DECLINED". | | | | | | Cancel the | "A" sends a CANCEL | | | meeting | message to "B", | | | | "C" and "D" | | +-------------+--------------------+--------------------------------+ The example shows how "A" cancels the event. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:CANCEL VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;CUTYPE=INDIVIDUAL;mailto:a@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com COMMENT:Mr. B cannot attend. It's raining. Lets cancel. UID:calsrv.example.com-873970198738777@example.com SEQUENCE:1 STATUS:CANCELLED DTSTAMP:19970613T190000Z END:VEVENT END:VCALENDAR Daboo Expires April 7, 2010 [Page 90] Internet-Draft iTIP October 2009 4.2.10. Removing Attendees "A" wants to remove "B" from a meeting. This is done by sending a "CANCEL" to "B" and removing "B" from the attendee list in the master copy of the event. +-------------------+----------------------------------+------------+ | Action | "Organizer" | "Attendee" | +-------------------+----------------------------------+------------+ | Remove "B" as an | "A" sends a CANCEL message to | | | "Attendee" | "B" | | | | | | | Update the master | "A" optionally sends the updated | | | copy of the event | event to the remaining | | | | "Attendees" | | +-------------------+----------------------------------+------------+ The original meeting includes "A", "B", "C", and "D". The example below shows the "CANCEL" that "A" sends to "B". Note that in the example below the "STATUS" property is omitted. This is used when the meeting itself is cancelled and not when the intent is to remove an "Attendee" from the event. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:CANCEL VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE:mailto:b@example.com COMMENT:You're off the hook for this meeting UID:calsrv.example.com-873970198738777@example.com DTSTAMP:19970613T193000Z SEQUENCE:1 END:VEVENT END:VCALENDAR The updated master copy of the event is shown below. The "Organizer" MAY resend the updated event to the remaining "Attendees". Note that "B" has been removed. Daboo Expires April 7, 2010 [Page 91] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com ATTENDEE;CUTYPE=ROOM:mailto:cr_big@example.com ATTENDEE;ROLE=NON-PARTICIPANT; RSVP=FALSE:mailto:e@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T203000Z SUMMARY:Phone Conference UID:calsrv.example.com-873970198738777@example.com SEQUENCE:2 STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.2.11. Replacing the Organizer The scenario for this example begins with "A" as the "Organizer" for a recurring meeting with "B", "C", and "D". "A" receives a new job offer in another country and drops out of touch. "A" left no forwarding address or way to be reached. Using out-of-band communication, the other "Attendees" eventually learn what has happened and reach an agreement that "B" should become the new "Organizer" for the meeting. To do this, "B" sends out a new version of the event and the other "Attendees" agree to accept "B" as the new "Organizer". "B" also removes "A" from the event. When the "Organizer" is replaced, the "SEQUENCE" property value MUST be incremented. This is the message "B" sends to "C" and "D" Daboo Expires April 7, 2010 [Page 92] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:b@example.com ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:mailto:b@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:c@example.com ATTENDEE;CUTYPE=INDIVIDUAL:mailto:d@example.com DTSTAMP:19970611T190000Z DTSTART:19970701T200000Z DTEND:19970701T203000Z RRULE:FREQ=WEEKLY SUMMARY:Phone Conference UID:123456@example.com SEQUENCE:1 STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.3. Busy Time Examples Busy time objects can be used in several ways. First, a CU may request busy time from another CU for a specific range of time. That request can be answered with a busy time Reply. Additionally, a CU may simply publish their busy time for a given interval and point other CUs to the published location. The following examples outline both scenarios. 4.3.1. Publish Busy Time Individual "A" publishes busy time for one week. Daboo Expires April 7, 2010 [Page 93] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 METHOD:PUBLISH BEGIN:VFREEBUSY DTSTAMP:19980101T124100Z ORGANIZER:mailto:a@example.com DTSTART:19980101T124200Z DTEND:19980108T124200Z FREEBUSY:19980101T180000Z/19980101T190000Z FREEBUSY:19980103T020000Z/19980103T050000Z FREEBUSY:19980107T020000Z/19980107T050000Z FREEBUSY:19980113T000000Z/19980113T010000Z FREEBUSY:19980115T190000Z/19980115T200000Z FREEBUSY:19980115T220000Z/19980115T230000Z FREEBUSY:19980116T013000Z/19980116T043000Z END:VFREEBUSY END:VCALENDAR 4.3.2. Request Busy Time Individual "A" requests busy time from individuals "B", "C". Individual "B" and "C" replies with busy time data to individual "A". The following table illustrates the sequence of messages that would be exchanged between these individuals. +----------------------+--------------------+-----------------------+ | Action | "Organizer" | Attendee | +----------------------+--------------------+-----------------------+ | Initiate a busy time | "A" sends | | | request | "REQUEST" message | | | | to "B" and "C" | | | | | | | Reply to the "BUSY" | | "B" sends a "REPLY" | | request with "BUSY" | | message to "A" with | | time data | | busy time data | +----------------------+--------------------+-----------------------+ "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time Daboo Expires April 7, 2010 [Page 94] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VFREEBUSY ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com DTSTAMP:19970613T190000Z DTSTART:19970701T080000Z DTEND:19970701T200000 UID:calsrv.example.com-873970198738777@example.com END:VFREEBUSY END:VCALENDAR 4.3.3. Reply To A Busy Time Request "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component to "A" BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VFREEBUSY ORGANIZER:mailto:a@example.com ATTENDEE:mailto:b@example.com DTSTART:19970701T080000Z DTEND:19970701T200000Z UID:calsrv.example.com-873970198738777@example.com FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M DTSTAMP:19970613T190030Z END:VFREEBUSY END:VCALENDAR "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30. 4.4. Recurring Event and Time Zone Examples 4.4.1. A Recurring Event Spanning Time Zones This event describes a weekly phone conference. The "Attendees" are each in a different time zone. Daboo Expires April 7, 2010 [Page 95] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTIMEZONE TZID:America-SanJose TZURL:http://example.com/tz/America-SanJose BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED; CUTYPE=INDIVIDUAL:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:b@example.fr ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:c@example.jp DTSTAMP:19970613T190030Z DTSTART;TZID=America-SanJose:19970701T140000 DTEND;TZID=America-SanJose:19970701T150000 RRULE:FREQ=WEEKLY;COUNT=20;WKST=SU;BYDAY=TU RDATE;TZID=America-SanJose:19970910T140000 EXDATE;TZID=America-SanJose:19970909T140000 EXDATE;TZID=America-SanJose:19971028T140000 SUMMARY:Weekly Phone Conference UID:calsrv.example.com-873970198738777@example.com SEQUENCE:0 STATUS:CONFIRMED END:VEVENT END:VCALENDAR The first component of this iCalendar object is the time zone component. The "DTSTART" date coincides with the first instance of the RRULE property. The recurring meeting is defined in a particular time zone, Daboo Expires April 7, 2010 [Page 96] Internet-Draft iTIP October 2009 presumably that of the originator. The client for each "Attendee" has the responsibility of determining the recurrence time in the "Attendee's" time zone. The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT (UTC-7). "Attendee" B@example.fr is in France where the local time on this date is 9 hours ahead of PDT or 23:00 CEST (UTC+2). "Attendee" C@example.jp is in Japan where local time is 16 hours ahead of PDT or Wednesday, July 2 at 06:00 JST (UTC+9). The event repeats weekly on Tuesdays (in PST/PDT). The "RRULE" property results in 20 instances. The last instance falls on Tuesday, November 11, 1997 2:00pm PST. The "RDATE" property adds another instance: WED, 10-SEP-1997 2:00 PM PDT. There are also two exception dates to the recurrence rule. The first one is: o TUE, 09-SEP-1997 14:00 PDT (UTC-7) o TUE, 09-SEP-1997 23:00 CEST (UTC+2) o WED, 10-SEP-1997 06:00 JST (UTC+9) and the second is: o TUE, 28-OCT-1997 14:00 PST (UTC-8) o TUE, 28-OCT-1997 23:00 CET (UTC+1) o WED, 29-OCT-1997 07:00 JST (UTC+9) 4.4.2. Modify A Recurring Instance In this example the "Organizer" issues a recurring meeting. Later the "Organizer" changes an instance of the event by changing the "DTSTART" property. Note the use of "RECURRENCE-ID" property and "SEQUENCE" property in the second request. Original Request: Daboo Expires April 7, 2010 [Page 97] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com SEQUENCE:0 RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z LOCATION:Conference Call DTSTAMP:19970526T083000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR The event request below is to change the time of a specific instance. This changes the July 1st instance to July 3rd. #x27;t bother with this nuance. '6' 'processing-stopped': The job has stopped while processing for any number of reasons and will return to the 'processing' state as soon as the reasons are no longer present. The job's "job-state-reason" attribute MAY indicate why the job has stopped processing. For example, if the output device is stopped, the 'printer-stopped' value MAY be included in the job's "job-state-reasons" attribute. Note: When an output device is stopped, the device usually indicates its condition in human readable form locally at the device. A client can obtain more complete device status remotely by querying the Printer object's "printer-state", "printer-state-reasons" and "printer- state-message" attributes. '7' 'canceled': The job has been canceled by a Cancel-Job operation and the Printer object has completed canceling Hastings, et al. Standards Track [Page 110] RFC 2911 IPP/1.1: Model and Semantics September 2000 the job and all job status attributes have reached their final values for the job. While the Printer object is canceling the job, the job remains in its current state, but the job's "job-state-reasons" attribute SHOULD contain the 'processing-to-stop-point' value and one of the 'canceled-by-user', 'canceled-by-operator', or 'canceled-at-device' value. When the job moves to the 'canceled' state, the 'processing-to-stop-point' value, if present, MUST be removed, but the 'canceled-by-xxx', if present, MUST remain. '8' 'aborted': The job has been aborted by the system, usually while the job was in the 'processing' or 'processing- stopped' state and the Printer has completed aborting the job and all job status attributes have reached their final values for the job. While the Printer object is aborting the job, the job remains in its current state, but the job's "job-state-reasons" attribute SHOULD contain the 'processing-to-stop-point' and 'aborted-by- system' values. When the job moves to the 'aborted' state, the 'processing-to-stop-point' value, if present, MUST be removed, but the 'aborted-by-system' value, if present, MUST remain. '9' 'completed': The job has completed successfully or with warnings or errors after processing and all of the job media sheets have been successfully stacked in the appropriate output bin(s) and all job status attributes have reached their final values for the job. The job's "job-state-reasons" attribute SHOULD contain one of: 'completed-successfully', 'completed-with-warnings', or 'completed-with-errors' values. The final value for this attribute MUST be one of: 'completed', 'canceled', or 'aborted' before the Printer removes the job altogether. The length of time that jobs remain in the 'canceled', 'aborted', and 'completed' states depends on implementation. See section 4.3.7.2. The following figure shows the normal job state transitions. +----> canceled / +----> pending --------> processing ---------+------> completed | ^ ^ \ --->+ | | +----> aborted | v v / +----> pending-held processing-stopped ---+ Hastings, et al. Standards Track [Page 111] RFC 2911 IPP/1.1: Model and Semantics September 2000 Normally a job progresses from left to right. Other state transitions are unlikely, but are not forbidden. Not shown are the transitions to the 'canceled' state from the 'pending', 'pending- held', and 'processing-stopped' states. Jobs reach one of the three terminal states: 'completed', 'canceled', or 'aborted', after the jobs have completed all activity, including stacking output media, after the jobs have completed all activity, and all job status attributes have reached their final values for the job. 4.3.7.1 Forwarding Servers As with all other IPP attributes, if the implementation cannot determine the correct value for this attribute, it SHOULD respond with the out-of-band value 'unknown' (see section 4.1) rather than try to guess at some possibly incorrect value and give the end user the wrong impression about the state of the Job object. For example, if the implementation is just a gateway into some printing system from which it can normally get status, but temporarily is unable, then the implementation should return the 'unknown' value. However, if the implementation is a gateway to a printing system that never provides detailed status about the print job, the implementation MAY set the IPP Job object's state to 'completed', provided that it also sets the 'queued-in-device' value in the job's "job-state-reasons" attribute (see section 4.3.8). 4.3.7.2 Partitioning of Job States This section partitions the 7 job states into phases: Job Not Completed, Job Retention, Job History, and Job Removal. This section also explains the 'job-restartable' value of the "job-state-reasons" Job Description attribute for use with the Restart-Job operation. Job Not Completed: When a job is in the 'pending', 'pending-held', 'processing', or 'processing-stopped' states, the job is not completed. Job Retention: When a job enters one of the three terminal job states: 'completed', 'canceled', or 'aborted', the IPP Printer object MAY "retain" the job in a restartable condition for an implementation-defined time period. This time period MAY be zero seconds and MAY depend on the terminal job state. This phase is called Job Retention. While in the Job Retention phase, the job's document data is retained and a client may restart the job using the Restart-Job operation. If the IPP object supports the Restart-Job Hastings, et al. Standards Track [Page 112] RFC 2911 IPP/1.1: Model and Semantics September 2000 operation, then it SHOULD indicate that the job is restartable by adding the 'job-restartable' value to the job's "job-state-reasons" attribute (see Section 4.3.8) during the Job Retention phase. Job History: After the Job Retention phase expires for a job, the Printer object deletes the document data for the job and the job becomes part of the Job History. The Printer object MAY also delete any number of the job attributes. Since the job is no longer restartable, the Printer object MUST remove the 'job-restartable' value from the job's "job-state-reasons" attribute, if present. Job Removal: After the job has remained in the Job History for an implementation-defined time, such as when the number of jobs exceeds a fixed number or after a fixed time period (which MAY be zero seconds), the IPP Printer removes the job from the system. Using the Get-Jobs operation and supplying the 'not-completed' value for the "which-jobs" operation attribute, a client is requesting jobs in the Job Not Completed phase. Using the Get-Jobs operation and supplying the 'completed' value for the "which-jobs" operation attribute, a client is requesting jobs in the Job Retention and Job History phases. Using the Get-Job-Attributes operation, a client is requesting a job in any phase except Job Removal. After Job Removal, the Get-Job-Attributes and Get-Jobs operations no longer are capable of returning any information about a job. 4.3.8 job-state-reasons (1setOf type2 keyword) This REQUIRED attribute provides additional information about the job's current state, i.e., information that augments the value of the job's "job-state" attribute. These values MAY be used with any job state or states for which the reason makes sense. Some of these value definitions indicate conformance requirements; the rest are OPTIONAL. Furthermore, when implemented, the Printer MUST return these values when the reason applies and MUST NOT return them when the reason no longer applies whether the value of the Job's "job-state" attribute changed or not. When the Job does not have any reasons for being in its current state, the value of the Job's "job-state-reasons" attribute MUST be 'none'. Note: While values cannot be added to the 'job-state' attribute without impacting deployed clients that take actions upon receiving "job-state" values, it is the intent that additional "job-state- reasons" values can be defined and registered without impacting such deployed clients. In other words, the "job-state-reasons" attribute is intended to be extensible. Hastings, et al. Standards Track [Page 113] RFC 2911 IPP/1.1: Model and Semantics September 2000 The following standard keyword values are defined. For ease of understanding, the values are presented in the order in which the reasons are likely to occur (if implemented), starting with the 'job-incoming' value: 'none': There are no reasons for the job's current state. This state reason is semantically equivalent to "job-state-reasons" without any value and MUST be used when there is no other value, since the 1setOf attribute syntax requires at least one value. 'job-incoming': Either (1) the Printer has accepted the Create- Job operation and is expecting additional Send-Document and/or Send-URI operations, or (2) the Printer is retrieving/accepting document data as a result of a Print-Job, Print-URI, Send- Document or Send-URI operation. 'job-data-insufficient': The Create-Job operation has been accepted by the Printer, but the Printer is expecting additional document data before it can move the job into the 'processing' state. If a Printer starts processing before it has received all data, the Printer removes the 'job-data- insufficient' reason, but the 'job-incoming' remains. If a Printer starts processing after it has received all data, the Printer removes the 'job-data-insufficient' reason and the 'job-incoming' at the same time. 'document-access-error': After accepting a Print-URI or Send-URI request, the Printer could not access one or more documents passed by reference. This reason is intended to cover any file access problem, including file does not exist and access denied because of an access control problem. The Printer MAY also indicate the document access error using the "job-document- access-errors" Job Description attribute (see section 4.3.11). Whether the Printer aborts the job and moves the job to the 'aborted' job state or prints all documents that are accessible and moves the job to the 'completed' job state and adds the 'completed-with-errors' value in the job's "job-state-reasons" attribute depends on implementation and/or site policy. This value SHOULD be supported if the Print-URI or Send-URI operations are supported. 'submission-interrupted': The job was not completely submitted for some unforeseen reason, such as: (1) the Printer has crashed before the job was closed by the client, (2) the Printer or the document transfer method has crashed in some non-recoverable way before the document data was entirely transferred to the Printer, (3) the client crashed or failed to close the job before the time-out period. See section 4.4.31. 'job-outgoing': The Printer is transmitting the job to the output device. Hastings, et al. Standards Track [Page 114] RFC 2911 IPP/1.1: Model and Semantics September 2000 'job-hold-until-specified': The value of the job's "job-hold- until" attribute was specified with a time period that is still in the future. The job MUST NOT be a candidate for processing until this reason is removed and there are no other reasons to hold the job. This value SHOULD be supported if the "job- hold-until" Job Template attribute is supported. 'resources-are-not-ready': At least one of the resources needed by the job, such as media, fonts, resource objects, etc., is not ready on any of the physical printer's for which the job is a candidate. This condition MAY be detected when the job is accepted, or subsequently while the job is pending or processing, depending on implementation. The job may remain in its current state or be moved to the 'pending-held' state, depending on implementation and/or job scheduling policy. 'printer-stopped-partly': The value of the Printer's "printer- state-reasons" attribute contains the value 'stopped-partly'. 'printer-stopped': The value of the Printer's "printer-state" attribute is 'stopped'. 'job-interpretingDaboo Expires April 7, 2010 [Page 98] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com RECURRENCE-ID:19970701T210000Z SEQUENCE:1 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970703T210000Z DTEND:19970703T220000Z LOCATION:Conference Call DTSTAMP:19970626T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.4.3. Cancel an Instance In this example the "Organizer" of a recurring event deletes the August 1st instance. BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com RECURRENCE-ID:19970801T210000Z SEQUENCE:2 STATUS:CANCELLED DTSTAMP:19970721T093000Z END:VEVENT END:VCALENDAR Daboo Expires April 7, 2010 [Page 99] Internet-Draft iTIP October 2009 4.4.4. Cancel Recurring Event In this example the "Organizer" wishes to cancel the entire recurring event and any exceptions. BEGIN:VCALENDAR METHOD:CANCEL PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com DTSTAMP:19970721T103000Z STATUS:CANCELLED SEQUENCE:3 END:VEVENT END:VCALENDAR 4.4.5. Change All Future Instances This example changes the meeting location from a conference call to Seattle starting September 1 and extends to all future instances. Daboo Expires April 7, 2010 [Page 100] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com RECURRENCE-ID;THISANDFUTURE:19970901T210000Z SEQUENCE:3 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com DESCRIPTION:IETF-C&S Discussion CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970901T210000Z DTEND:19970901T220000Z LOCATION:Building 32, Microsoft, Seattle, WA DTSTAMP:19970526T083000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.4.6. Add A New Instance To A Recurring Event This example adds a one-time additional instance to the recurring event. "Organizer" adds a second July meeting on the 15th. Daboo Expires April 7, 2010 [Page 101] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:ADD PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:4 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T210000Z DTEND:19970715T220000Z LOCATION:Conference Call DTSTAMP:19970629T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR 4.4.7. Add A New Series of Instances To A Recurring Event The scenario for this example involves an ongoing meeting, originally set up to occur every Tuesday. The "Organizer" later decides that the meetings need to be on Tuesdays and Thursdays. The original event: Daboo Expires April 7, 2010 [Page 102] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:0 RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY 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:19980303T210000Z DTEND:19980303T220000Z LOCATION:The White Room DTSTAMP:19980301T093000Z STATUS:CONFIRMED END:VEVENT END:VCALENDAR The entire event can be rescheduled using a "REQUEST". This is done by using the "UID" of the event to reschedule and including the modified "RRULE". Note, that since this is an entire rescheduling of the event, any instance-specific information will be lost, unless explicitly included with the update "REQUEST". BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:7 RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY 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:19980303T210000Z DTEND:19980303T220000Z DTSTAMP:19980303T193000Z LOCATION:The White Room STATUS:CONFIRMED END:VEVENT END:VCALENDAR Daboo Expires April 7, 2010 [Page 103] Internet-Draft iTIP October 2009 4.4.8. Refreshing A Recurring Event The next series of examples illustrate how an "Organizer" would respond to a "REFRESH" submitted by an "Attendee" after a series of instance-specific modifications. To convey all instance-specific changes, the "Organizer" must provide the latest event description and the relevant instances. The first three examples show the history including the initial "VEVENT" request and subsequent instance changes and finally the "REFRESH". Original Request: BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:0 RDATE:19980304T180000Z RDATE:19980311T180000Z RDATE:19980318T180000Z 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 END:VCALENDAR Organizer changes 2nd instance Location and Time: Daboo Expires April 7, 2010 [Page 104] Internet-Draft iTIP October 2009 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 Organizer adds a 4th instance of the meeting using the "ADD" method BEGIN:VCALENDAR METHOD:ADD PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:123456789@example.com SEQUENCE:2 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:19980315T180000Z DTEND:19980315T200000Z DTSTAMP:19980307T193000Z LOCATION:Conference Room A STATUS:CONFIRMED END:VEVENT END:VCALENDAR If "B" requests a "REFRESH", "A" responds with the following to capture all instance-specific data. In this case both the initial request and an additional "VEVENT" that specifies the instance- specific data are included. Because these are both of the same type Daboo Expires April 7, 2010 [Page 105] Internet-Draft iTIP October 2009 (they are both "VEVENTS"), they can be conveyed in the same iCalendar object. 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 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 4.4.9. Counter An Instance Of A Recurring Event In this example one of the "Attendees" counters the "DTSTART" property of the proposed second July meeting. Daboo Expires April 7, 2010 [Page 106] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:COUNTER PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com RECURRENCE-ID:19970715T210000Z SEQUENCE:4 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;RSVP=TRUE:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970715T220000Z DTEND:19970715T230000Z LOCATION:Conference Call COMMENT:May we bump this by an hour? I have a conflict DTSTAMP:19970629T094000Z END:VEVENT END:VCALENDAR 4.4.10. Error Reply To A Request The following example illustrates a scenario where a meeting is proposed containing an unsupported property and a bad property. Original Request Daboo Expires April 7, 2010 [Page 107] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:guid-1@example.com SEQUENCE:0 RRULE:FREQ=MONTHLY;BYMONTHDAY=1 ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com DESCRIPTION:IETF-C&S Conference Call CLASS:PUBLIC SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970601T210000Z DTEND:19970601T220000Z DTSTAMP:19970602T094000Z LOCATION:Conference Call STATUS:CONFIRMED FOO:BAR END:VEVENT END:VCALENDAR Response from "B" to indicate that RRULE is not supported and an unrecognized property was encountered BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE:mailto:b@example.com REQUEST-STATUS:3.0;Invalid Property Name;FOO UID:guid-1@example.com SEQUENCE:0 DTSTAMP:19970603T094000Z END:VEVENT END:VCALENDAR Daboo Expires April 7, 2010 [Page 108] Internet-Draft iTIP October 2009 4.5. Group To-do Examples Individual "A" creates a group task in which individuals "A", "B", "C" and "D" will participate. Individual "B" confirms acceptance of the task. Individual "C" declines the task. Individual "D" tentatively accepts the task. The following table illustrates the sequence of messages that would be exchanged between these individuals. Individual "A" then issues a "REQUEST" method to obtain the status of the to-do from each participant. The response indicates the individual "Attendee's" completion status. The table below illustrates the message flow. +--------------+------------------------+---------------------------+ | Action | "Organizer" | Attendee | +--------------+------------------------+---------------------------+ | Initiate a | "A" sends a REQUEST | | | to-do | message to "B", "C", | | | request | and "D" | | | | | | | Accept the | | "B" sends a "REPLY" | | to-do | | message to "A" with its | | request | | "PARTSTAT" parameter set | | | | to "ACCEPTED". | | | | | | Decline the | | "C" sends a REPLY message | | to-do | | to "A" with its | | request | | "PARTSTAT" parameter set | | | | to "DECLINED". | | | | | | Tentatively | | "D" sends a REPLY message | | accept the | | to "A" with its | | to-do | | "PARTSTAT" parameter set | | request | | to "TENTATIVE". | | | | | | Check | "A" sends a REQUEST | | | attendee | message to "B" and "D" | | | completion | with current | | | status | information. | | | | | | | Attendee | | "B" sends a "REPLY" | | indicates | | message indicating | | percent | | percent complete | | complete | | | | | | | | Attendee | | "D" sends a "REPLY" | | indicates | | message indicating | | completion | | completion | +--------------+------------------------+---------------------------+ Daboo Expires April 7, 2010 [Page 109] Internet-Draft iTIP October 2009 4.5.1. A VTODO Request A sample "REQUEST" for a "VTODO" calendar component that "A" sends to "B", "C", and "D&': Job is in the 'processing' state, but more specifically, the Printer is interpreting the document data. 'job-queued': Job is in the 'processing' state, but more specifically, the Printer has queued the document data. 'job-transforming': Job is in the 'processing' state, but more specifically, the Printer is interpreting document data and producing another electronic representation. 'job-queued-for-marker': Job is in any of the 'pending-held', 'pending', or 'processing' states, but more specifically, the Printer has completed enough processing of the document to be able to start marking and the job is waiting for the marker. Systems that require human intervention to release jobs using the Release-Job operation, put the job into the 'pending-held' job state. Systems that automatically select a job to use the marker put the job into the 'pending' job state or keep the job in the 'processing' job state while waiting for the marker, depending on implementation. All implementations put the job into (or back into) the 'processing' state when marking does begin. 'job-printing': The output device is marking media. This value is useful for Printers which spend a great deal of time processing (1) when no marking is happening and then want to show that marking is now happening or (2) when the job is in the process of being canceled or aborted while the job remains in the 'processing' state, but the marking has not yet stopped so that impression or sheet counts are still increasing for the job. Hastings, et al. Standards Track [Page 115] RFC 2911 IPP/1.1: Model and Semantics September 2000 'job-canceled-by-user': The job was canceled by the owner of the job using the Cancel-Job request, i.e., by a user whose authenticated identity is the same as the value of the originating user that created the Job object, or by some other authorized end-user, such as a member of the job owner's security group. This value SHOULD be supported. 'job-canceled-by-operator': The job was canceled by the operator using the Cancel-Job request, i.e., by a user who has been authenticated as having operator privileges (whether local or remote). If the security policy is to allow anyone to cancel anyone's job, then this value may be used when the job is canceled by other than the owner of the job. For such a security policy, in effect, everyone is an operator as far as canceling jobs with IPP is concerned. This value SHOULD be supported if the implementation permits canceling by other than the owner of the job. 'job-canceled-at-device': The job was canceled by an unidentified local user, i.e., a user at a console at the device. This value SHOULD be supported if the implementation supports canceling jobs at the console. 'aborted-by-system': The job (1) is in the process of being aborted, (2) has been aborted by the system and placed in the 'aborted' state, or (3) has been aborted by the system and placed in the 'pending-held' state, so that a user or operator can manually try the job again. This value SHOULD be supported. 'unsupported-compression': The job was aborted by the system because the Printer determined while attempting to decompress the document-data's that the compression is actually not among those supported by the Printer. This value MUST be supported, since "compressions is a REQUIRED operation attribute. 'compression-error': The job was aborted by the system because the Printer encountered an error in the document-data while decompressing it. If the Printer posts this reason, the document-data has already passed any tests that would have led to the 'unsupported-compression' job-state-reason. 'unsupported-document-format': The job was aborted by the system because the document-data's document-format is not among those supported by the Printer. If the client specifies the document-format as 'application/octet-stream', the printer MAY abort the job and post this reason even though the format is a member of the "document-format-supported" printer attribute, but not among the auto-sensed document-formats. This value MUST be supported, since "document-format" is a REQUIRED operation attribute. Hastings, et al. Standards Track [Page 116] RFC 2911 IPP/1.1: Model and Semantics September 2000 'document-format-error': The job was aborted by the system because the Printer encountered an error in the document-data while processing it. If the Printer posts this reason, the document-data has already passed any tests that would have led to the 'unsupported-document-format' job-state-reason. 'processing-to-stop-point': The requester has issued a Cancel-Job operation or the Printer object has aborted the job, but is still performing some actions on the job until a specified stop point occurs or job termination/cleanup is completed. If the implementation requires some measurable time to cancel the job in the 'processing' or 'processing-stopped' job states, the IPP object MUST use this value to indicate that the Printer object is still performing some actions on the job while the job remains in the 'processing' or 'processing-stopped' state. After all the job's job description attributes have stopped incrementing, the Printer object moves the job from the 'processing' state to the 'canceled' or 'aborted' job states. 'service-off-line': The Printer is off-line and accepting no jobs. All 'pending' jobs are put into the 'pending-held' state. This situation could be true if the service's or document transform's input is impaired or broken. 'job-completed-successfully': The job completed successfully. This value SHOULD be supported. 'job-completed-with-warnings': The job completed with warnings. This value SHOULD be supported if the implementation detects warnings. 'job-completed-with-errors': The job completed with errors (and possibly warnings too). This value SHOULD be supported if the implementation detects errors. 'job-restartable' - This job is retained (see section 4.3.7.2) and is currently able to be restarted using the Restart-Job operation (see section 3.3.7). If 'job-restartable' is a value of the job's 'job-state-reasons' attribute, then the IPP object MUST accept a Restart-Job operation for that job. This value SHOULD be supported if the Restart-Job operation is supported. 'queued-in-device': The job has been forwarded to a device or print system that is unable to send back status. The Printer sets the job's "job-state " attribute to 'completed' and adds the 'queued-in-device' value to the job's "job-state-reasons" attribute to indicate that the Printer has no additional information about the job and never will have any better information. See section 4.3.7.1. Hastings, et al. Standards Track [Page 117] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.3.9 job-state-message (text(MAX)) This attribute specifies information about the quot;. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;RSVP=TRUE:mailto:b@example.com ATTENDEE;RSVP=TRUE:mailto:c@example.com ATTENDEE;RSVP=TRUE:mailto:d@example.com DTSTART:19970701T170000Z DUE:19970722T170000Z PRIORITY:1 SUMMARY:Create the requirements document UID:calsrv.example.com-873970198738777-00@example.com SEQUENCE:0 DTSTAMP:19970717T200000Z STATUS:NEEDS-ACTION END:VTODO END:VCALENDAR 4.5.2. A VTODO Reply "B" accepts the to-do. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=ACCEPTED:mailto:b@example.com UID:calsrv.example.com-873970198738777-00@example.com COMMENT:I'll send you my input by e-mail SEQUENCE:0 DTSTAMP:19970717T203000Z REQUEST-STATUS:2.0;Success END:VTODO END:VCALENDAR Daboo Expires April 7, 2010 [Page 110] Internet-Draft iTIP October 2009 "B" could have declined the TODO or indicated tentative acceptance by setting the "PARTSTAT" property parameter sequence to "DECLINED" or "TENTATIVE", respectively. 4.5.3. A VTODO Request for Updated Status "A" requests status from all "Attendees". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com UID:calsrv.example.com-873970198738777-00@example.com SUMMARY:Create the requirements document PRIORITY:1 SEQUENCE:0 STATUS:IN-PROCESS DTSTART:19970701T170000Z DTSTAMP:19970717T230000Z END:VTODO END:VCALENDAR 4.5.4. A Reply: Percent-Complete A reply indicating the task being worked on and that "B" is 75% complete with "B's" part of the assignment. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com PERCENT-COMPLETE:75 UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z SEQUENCE:0 END:VTODO END:VCALENDAR Daboo Expires April 7, 2010 [Page 111] Internet-Draft iTIP October 2009 4.5.5. A Reply: Completed A reply indicating that "D" completed "D's" part of the assignment. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;PARTSTAT=COMPLETED:mailto:d@example.com UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z SEQUENCE:0 END:VTODO END:VCALENDAR 4.5.6. An Updated VTODO Request Organizer "A" resends the "VTODO" calendar component. "A" sets the overall completion for the to-do at 40%. BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE;PARTSTAT=ACCEPTED;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;PARTSTAT=COMPLETED;CUTYPE=INDIVIDUAL:mailto:d@example.com DTSTART:19970701T170000Z DUE:19970722T170000Z PRIORITY:1 SUMMARY:Create the requirements document UID:calsrv.example.com-873970198738777-00@example.com SEQUENCE:1 DTSTAMP:19970718T100000Z STATUS:IN-PROCESS PERCENT-COMPLETE:40 END:VTODO END:VCALENDAR Daboo Expires April 7, 2010 [Page 112] Internet-Draft iTIP October 2009 4.5.7. Recurring VTODOs The following examples relate to recurring "VTODO" calendar components. 4.5.7.1. Request for a Recurring VTODO In this example "A" sends a recurring "VTODO" calendar component to "B" and "D". BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REQUEST VERSION:2.0 BEGIN:VTODO ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR:mailto:a@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:b@example.com ATTENDEE;RSVP=TRUE;CUTYPE=INDIVIDUAL:mailto:d@example.com RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR DTSTART:19980101T100000Z DUE:19980103T100000Z SUMMARY:Send Status Reports to Area Managers UID:calsrv.example.com-873970198738777-00@example.com SEQUENCE:0 DTSTAMP:19970717T200000Z STATUS:NEEDS-ACTION PRIORITY:1 END:VTODO END:VCALENDAR 4.5.7.2. Replying to an instance of a recurring VTODO In this example "B" updates "A" on a single instance of the "VTODO" calendar component. Daboo Expires April 7, 2010 [Page 113] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REPLY VERSION:2.0 BEGIN:VTODO ATTENDEE;PARTSTAT=IN-PROCESS:mailto:b@example.com PERCENT-COMPLETE:75 UID:calsrv.example.com-873970198738777-00@example.com DTSTAMP:19970717T233000Z RECURRENCE-ID:19980101T170000Z SEQUENCE:1 END:VTODO END:VCALENDAR 4.6. Journal Examples The iCalendar object below describes a single journal entry for October 2, 1997. The "RELATED-TO" property references the phone conference event for which minutes were taken. BEGIN:VCALENDAR METHOD:PUBLISH PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VJOURNAL DTSTART:19971002T200000Z DTSTAMP:19970717T233100Z ORGANIZER:mailto:a@example.com SUMMARY:Phone conference minutes DESCRIPTION:The editors meeting was held on October 1, 1997. Details are in the attached document. UID:0981234-1234234-2410@example.com RELATED-TO:0981234-1234234-2402-35@example.com ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt END:VJOURNAL END:VCALENDAR 4.7. Other Examples 4.7.1. Event Refresh Refresh the event with "UID" property value of "guid-1-12345@example.com": Daboo Expires April 7, 2010 [Page 114] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REFRESH VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com ATTENDEE:mailto:c@example.com ATTENDEE:mailto:d@example.com UID:guid-1-12345@example.com DTSTAMP:19970603T094000 END:VEVENT END:VCALENDAR 4.7.2. Bad RECURRENCE-ID Component instances are identified by the combination of "UID", "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends an iTIP message to an "Attendee", there are three cases in which an instance cannot be found. They are: 1. The component with the referenced "UID" and "RECURRENCE-ID" has been found but the "SEQUENCE" number in the calendar store does not match that of the iTIP message. 2. The component with the referenced "UID" has been found, the "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be found. 3. The "UID" and "SEQUENCE" numbers are found but the CUA does not support recurrences. In case (1), two things can happen. If the "SEQUENCE" number of the "Attendee's" instance is larger than that in the "Organizer's" message then the "Attendee" is receiving an out-of-sequence message and MUST ignore it. If the "SEQUENCE" number of the "Attendee's" instance is smaller, then the "Organizer" is sending out a newer version of the component and the "Attendee's" version needs to be updated. Since one or more updates have been missed, the "Attendee" SHOULD send a "REFRESH" message to the "Organizer" to get an updated version of the event. In case (2), something has gone wrong. Both the "Organizer" and the "Attendee" should have the same instances, but the "Attendee" does not have the referenced instance. In this case the "Attendee" SHOULD send a "REFRESH" to the "Organizer" to get an updated version of the event. Daboo Expires April 7, 2010 [Page 115] Internet-Draft iTIP October 2009 In case (3), the limitations of the "Attendee's" CUA makes it impossible to match an instance other than the single instance scheduled. In this case, the "Attendee" need not send a "REFRESH" to the "Organizer". The example below shows a sequence in which an "Attendee" sends a "REFRESH" to the "Organizer". +-------------------------+--------------------+--------------------+ | Action | "Organizer" | Attendee | +-------------------------+--------------------+--------------------+ | Update an instance | "A" sends | | | request | "REQUEST" message | | | | to "B" | | | | | | | Attendee requests | | "B" sends a | | refresh because | | "REFRESH" message | | "RECURRENCE-ID" was not | | to "A" | | found | | | | | | | | Refresh the entire | "A" sends the | | | event | latest copy of the | | | | event to "B" | | | | | | | Attendee handles the | | "B" updates to the | | request and updates the | | latest copy of the | | instance | | meeting. | +-------------------------+--------------------+--------------------+ Request from "A": Daboo Expires April 7, 2010 [Page 116] Internet-Draft iTIP October 2009 BEGIN:VCALENDAR METHOD:REQUEST PRODID:-//Example/ExampleCalendarClient//EN VERSION:2.0 BEGIN:VEVENT UID:example-12345@example.com SEQUENCE:3 RRULE:FREQ=WEEKLY RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z ORGANIZER:mailto:a@example.com ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:mailto:a@example.com ATTENDEE:mailto:b@example.com DESCRIPTION:IETF-C&S Conference Call SUMMARY:IETF Calendaring Working Group Meeting DTSTART:19970801T210000Z DTEND:19970801T220000Z RECURRENCE-ID:19970809T210000Z DTSTAMP:19970726T083000 STATUS:CONFIRMED END:VEVENT END:VCALENDAR "B" has the event with "UID" property "example-12345@example.com" but "B's" "SEQUENCE" property value is "1" and the event does not have an instance at the specified recurrence time. This means that "B" has missed at least one update and needs a new copy of the event. "B" requests the latest copy of the event with the following refresh message: BEGIN:VCALENDAR PRODID:-//Example/ExampleCalendarClient//EN METHOD:REFRESH VERSION:2.0 BEGIN:VEVENT ORGANIZER:mailto:a@example.com ATTENDEE:mailto:b@example.com UID:example-12345@example.com DTSTAMP:19970603T094000 END:VEVENT END:VCALENDAR Daboo Expires April 7, 2010 [Page 117] Internet-Draft iTIP October 2009 5. Application Protocol Fallbacks 5.1. Partial Implementation Applications that support this specification are not required to support the entire protocol. The following describes how methods and properties SHOULD "fallback" in applications that do not support the complete protocol. If a method or property is not addressed in this section, it may be ignored. 5.1.1. Event-Related Fallbacks +----------------+--------------------------------------------------+ | Method | Fallback | +----------------+--------------------------------------------------+ | PUBLISH | Required | | REQUEST | PUBLISH | | REPLY | Required | | ADD | Required if recurrences supported, otherwise | | | reply with a REQUEST-STATUS "2.8;Success, | | | repeating event ignored. Scheduled as a single | | | component." and schedule as a single component. | | CANCEL | Required | | REFRESH | Required | | COUNTER | Reply with "Not Supported" | | DECLINECOUNTER | Required if COUNTER is implemented for VEVENTs, | | | otherwise reply with "Not Supported" | +----------------+--------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN | | PRODID | Ignore | | METHOD | Required as described in the Method list above | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | Event-Related | Fallback | | Components | | +-----------------+-------------------------------------------------+ | VALARM | Reply with "Not Supported" | | VTIMEZONE | Required if any DateTime value refers to a time | | | zone. | +-----------------+-------------------------------------------------+ Daboo Expires April 7, 2010 [Page 118] Internet-Draft iTIP October 2009 +-----------------+-------------------------------------------------+ | Component | Fallback | | Property | | +-----------------+-------------------------------------------------+ | ATTACH | Ignore | | ATTENDEE | Required if METHOD is REQUEST, otherwise ignore | | CATEGORIES | Ignore | | CLASS | Ignore | | COMMENT | Ignore | | COMPLETED | Ignore | | CONTACT | Ignore | | CREATED | Ignore | | DESCRIPTION | Ignore | | DURATION | Required | | DTSTAMP | Required | | DTSTART | Required | | DTEND | Required | | EXDATE | Ignore | | GEO | Ignore | | LAST-MODIFIED | Ignore | | LOCATION | Required | | ORGANIZER | Required if METHOD is REQUEST, otherwise ignore | | PRIORITY | Ignore | | RELATED-TO | Ignore | | RDATE | Ignore | | RRULE | Ignore - assume the first instance occurs on | | | the DTSTART property. If implemented, | | | VTIMEZONE MUST also be implemented. | | RECURRENCE-ID | Required if RRULE is implemented, otherwise | | | Ignore | | REQUEST-STATUS | Required | | RESOURCES | Ignore | | SEQUENCE | Required | | STATUS | Ignore | | SUMMARY | Ignore | | TRANSP | Required if FREEBUSY is implemented, otherwise | | | Ignore | | URL | Ignore | | UID | Required | | X- | Ignore | +-----------------+-------------------------------------------------+ Daboo Expires April 7, 2010 [Page 119] Internet-Draft iTIP October 2009 5.1.2. Free/Busy-Related Fallbacks +---------+---------------------------------------------------------+ | Method | Fallback | +---------+---------------------------------------------------------+ | PUBLISH | Required if freebusy lookups are supported, otherwise | | | reply with a REQUEST-STATUS "3.14;Unsupported | | | capability" | | REQUEST | Required if freebusy lookups are supported, otherwise | | | reply with a REQUEST-STATUS "3.14;Unsupported | | | capability" | | REPLY | Required if freebusy lookups are supported, otherwise | | | reply with a REQUEST-STATUS "3.14;Unsupported | | | capability" | +---------+---------------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN. | | PRODID | Ignore | | METHOD | Required as described in the Method list above. | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | Component | Fallback | | Property | | +-----------------+-------------------------------------------------+ | ATTENDEE | Required if METHOD is REQUEST, otherwise ignore | | COMMENT | Ignore | | CONTACT | Ignore | | DTEND | Required | | DTSTAMP | Required | | DTSTART | Required | | DURATION | Ignore | | FREEBUSY | Required | | ORGANIZER | Required if METHOD is REQUEST, otherwise ignore | | REQUEST-STATUS | Ignore | | UID | Required | | URL | Ignore | | X- | Ignore | +-----------------+-------------------------------------------------+ Daboo Expires April 7, 2010 [Page 120] Internet-Draft iTIP October 2009 5.1.3. To-Do-Related Fallbacks +----------------+--------------------------------------------------+ | Method | Fallback | +----------------+--------------------------------------------------+ | PUBLISH | Required | | REQUEST | PUBLISH | | REPLY | Required | | ADD | Required if recurrences supported, otherwise | | | reply with a REQUEST-STATUS "2.8;Success, | | | repeating event ignored. Scheduled as a single | | | component." and schedule as a single component. | | CANCEL | Required | | REFRESH | Required | | COUNTER | Reply with "Not Supported" | | DECLINECOUNTER | Required if COUNTER for VTODOs is implemented, | | | otherwise reply with "Not Supported" | +----------------+--------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN. | | PRODID | Ignore | | METHOD | Required as described in the Method list above. | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | To-Do-Related | Fallback | | Components | | +-----------------+-------------------------------------------------+ | VALARM | Reply with "Not Supported" | | VTIMEZONE | Required if any DateTime value refers to a time | | | zone. | +-----------------+-------------------------------------------------+ Daboo Expires April 7, 2010 [Page 121] Internet-Draft iTIP October 2009 +------------------+------------------------------------------------+ | Component | Fallback | | Property | | +------------------+------------------------------------------------+ | ATTACH | Ignore | | ATTENDEE | Required if METHOD is REQUEST, otherwise | | | ignore | | CATEGORIES | Ignore | | CLASS | Ignore | | COMMENT | Ignore | | COMPLETED | Required | | CONTACT | Ignore | | CREATED | Ignore | | DESCRIPTION | Required if METHOD is REQUEST, otherwise | | | ignore | | DUE | Required | | DURATION | Required | | DTSTAMP | Required | | DTSTART | Required | | EXDATE | Ignore - reply with "Not Supported" | | LAST-MODIFIED | Ignore | | LOCATION | Ignore | | ORGANIZER | Required if METHOD is REQUEST, otherwise | | | ignore | | PERCENT-COMPLETE | Ignore | | PRIORITY | Required | | RECURRENCE-ID | Required if RRULE is implemented, otherwise | | | Ignore | | RELATED-TO | Ignore | | REQUEST-STATUS | Ignore | | RDATE | Ignore | | RRULE | Ignore - assume the first instance occurs on | | | the DTSTART property. If implemented, | | | VTIMEZONE MUST also be implemented. | | RESOURCES | Ignore | | SEQUENCE | Required | | STATUS | Required | | SUMMARY | Ignore | | URL | Ignore | | UID | Required | | X- | Ignore | +------------------+------------------------------------------------+ Daboo Expires April 7, 2010 [Page 122] Internet-Draft iTIP October 2009 5.1.4. Journal-Related Fallbacks +---------+---------------------------------------------------------+ | Method | Fallback | +---------+---------------------------------------------------------+ | PUBLISH | Implementations MAY ignore the METHOD type. The | | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | returned. | | ADD | Implementations MAY ignore the METHOD type. The | | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | returned. | | CANCEL | Implementations MAY ignore the METHOD type. The | | | REQUEST-STATUS "3.14;Unsupported capability" MUST be | | | returned. | +---------+---------------------------------------------------------+ +-----------------+-------------------------------------------------+ | iCalendar | Fallback | | Property | | +-----------------+-------------------------------------------------+ | CALSCALE | Ignore - assume GREGORIAN. | | PRODID | Ignore | | METHOD | Required as described in the Method list above. | | VERSION | Ignore | +-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+ | Journal-Related | Fallback | | Components | | +-----------------+-------------------------------------------------+ | VTIMEZONE | Required if any DateTime value refers to a time | | | zone | +-----------------+-------------------------------------------------+ Daboo Expires April 7, 2010 [Page 123] Internet-Draft iTIP October 2009 +-----------------+-------------------------------------------------+ | Component | Fallback | | Property | | +-----------------+-------------------------------------------------+ | ATTACH | Ignore | | ATTENDEE | Ignore | | CATEGORIES | Ignore | | CLASS | Ignore | | COMMENT | Ignore | | CONTACT | Ignore | | CREATED | Ignore | | DESCRIPTION | Ignore | | DTSTAMP | Required | | DTSTART | Required | | EXDATE | Ignore | | LAST-MODIFIED | Ignore | | ORGANIZER | Ignore | | RECURRENCE-ID | Required if RRULE is implemented, otherwise | | | Ignore | | RELATED-TO | Ignore | | RDATE | Ignore. | | RRULE | Ignore - assume the first instance occurs on | | | the DTSTART property. If implemented, | | | VTIMEZONE MUST also be implemented. | | SEQUENCE | Required | | STATUS | Ignore | | SUMMARY | Required | | URL | Ignore | | UID | Required | | X- | Ignore | +-----------------+-------------------------------------------------+ 5.2. Latency Issues With a store-and-forward transport, it is possible for events to arrive out of sequence. That is, a "CANCEL" method may be received prior to receiving the associated "REQUEST" for the calendar component. This section discusses a few of these scenarios. 5.2.1. Cancellation of an Unknown Calendar Component. When a "CANCEL" method is received before the original "REQUEST" method the calendar will be unable to correlate the "UID" property of the cancellation with an existing calendar component. It is suggested that messages that can not be correlated that also contain non-zero sequence numbers be held and not discarded. Implementations MAY age them out if no other messages arrive with the same "UID" property value and a lower sequence number. Daboo Expires April 7, 2010 [Page 124] Internet-Draft iTIP October 2009 5.2.2. Unexpected Reply from an Unknown Delegate When an "Attendee" delegates an item to another CU they MUST send a "REPLY" method to the "Organizer" using the "ATTENDEE" properties to indicate that the request was delegated and to whom. Hence, it is possible for an "Organizer" to receive an "REPLY" from a CU not listed as one of the original "Attendees". The resolution is left to the implementation but it is expected that the calendaring software will either accept the reply or hold it until the related "REPLY" method is received from the "Delegator". If the version of the "REPLY" method is out of date the "Organizer" SHOULD treat the message as a "REFRESH" message and update the delegate with the correct version provided that delegation to that delegate is acceptable. 5.3. Sequence Number Under some conditions, a CUA may receive requests and replies with the same "SEQUENCE" property value. The "DTSTAMP" property is utilized as a tie-breaker when two items with the same "SEQUENCE" property value are evaluated. 6. Security Considerations iTIP is an abstract transport protocol which will be bound to a real- time transport, a store-and-forward transport, and perhaps other transports. The transport protocol will be responsible for providing facilities for authentication and encryption using standard Internet mechanisms that are mutually understood between the sender and receiver. 6.1. Security Threats 6.1.1. Spoofing the "Organizer" In iTIP, the "Organizer" (or someone working on the "Organizer's" behalf) is the only person authorized to make changes to an existing "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or redistribute updates to the "Attendees". An iCalendar object that maliciously changes or cancels an existing "VEVENT", "VTODO" or "VJOURNAL" calendar component may be constructed by someone other than the "Organizer" and republished or sent to the "Attendees". 6.1.2. Spoofing the "Attendee" In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component (or someone working on the "Attendee's" behalf) is the only person Daboo Expires April 7, 2010 [Page 125] Internet-Draft iTIP October 2009 authorized to update any parameter associated with their "ATTENDEE" property and send it to the "Organizer". An iCalendar object that maliciously changes the "ATTENDEE" parameters may be constructed by someone other than the real "Attendee" and sent to the "Organizer". 6.1.3. Unauthorized Replacement of the Organizer There will be circumstances when "Attendees" of an event or to-do decide, using out-of-band mechanisms, that the "Organizer" must be replaced. When the new "Organizer" sends out the updated "VEVENT" or "VTODO" the "Attendee's" CUA will detect that the "Organizer" has been changed, but it has no way of knowing whether or not the change was mutually agreed upon. 6.1.4. Eavesdropping and Data Integrity The iCalendar object is constructed with human-readable clear text. Any information contained in an iCalendar object may be read and/or changed by unauthorized persons while the object is in transit. 6.1.5. Flooding a Calendar Implementations could provide a means to automatically incorporate "REQUEST" methods into a calendar. This presents the opportunity for a calendar to be flooded with requests, which effectively block all the calendar's free time. 6.1.6. Unauthorized REFRESH Requests It is possible for an "Organizer" to receive a "REFRESH" request from someone who is not an "Attendee" of an event or to-do. Only "Attendee's" of an event or to-do are authorized to receive replies to "REFRESH" requests. Replying to such requests to anyone who is not an "Attendee" may be a security problem. 6.2. Recommendations For an application where the information is sensitive or critical and the network is subject to a high probability of attack, iTIP transactions SHOULD be encrypted and authenticated. This helps mitigate the threats of spoofing, eavesdropping and malicious changes in transit. 6.2.1. Securing iTIP transactions iTIP transport bindings MUST provide a mechanism to enable authentication of the sender's identity, and privacy and integrity of the data being transmitted. This allows the receiver of a signed Daboo Expires April 7, 2010 [Page 126] Internet-Draft iTIP October 2009 iCalendar object to verify the identity of the sender. This sender may then be correlated to an "ATTENDEE" property in the iCalendar object. If the correlation is made and the sender is authorized to make the requested change or update then the operation may proceed. It also allows the message to be encrypted to prevent unauthorized reading of the message contents in transit. iTIP transport binding documents describe this process in detail. 6.2.2. Implementation Controls The threat of unauthorized replacement of the "Organizer" SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that make "Calendar Users" aware of such "Organizer" changes and allowing them to decide whether or not the request should be honored. The threat of flooding a calendar SHOULD be mitigated by a calendar system that uses this protocol by providing controls that may be used to limit the acceptable sources for iTIP transactions, and perhaps the size of messages and volume of traffic, by source. The threat of unauthorized "REFRESH" requests SHOULD be mitigated by a calendar system that uses this protocol by providing controls or alerts that allow "Calendar User" to decide whether or not the request should be honored. An implementation MAY decide to maintain, for audit or historical purposes, "Calendar Users" who were part of an attendee list and who were subsequently uninvited. Similar controls or alerts should be provided when a "REFRESH" request is received from these "Calendar Users" as well. 6.2.3. Access Controls and Filtering In many environments there could be restrictions on who is allowed to scheduled with whom, and who allowed delegates are for particular calendar users. iTIP transport bindings SHOULD provide mechanisms for implementing access controls or filtering to ensure iTIP transactions only take place between authorized calendar users. That would include preventing one calendar user from scheduling with another, or a calendar user delegating to another. 6.3. Privacy Issues The "Organizer" might want to keep "Attendees" from knowing which other "Attendees" are participating in an event or to-do. The "Organizer" has the choice of sending single iTIP messages with a full list of "Attendees" or sending iTIP messages to each "Attendee" Daboo Expires April 7, 2010 [Page 127] Internet-Draft iTIP October 2009 with only that "Attendee" listed. 7. IANA Consideration 7.1. Registration Template for REQUEST-STATUS Values This specification updates [RFC5545] by adding a "REQUEST-STATUS" value registry to the iCalendar Elements registry. A "REQUEST-STATUS" value is defined by completing the following template. Status Code: Hierarchical, numeric return status code, following the rules defined in Section 3.8.8.3 of [RFC5545]. Status Description: Textual status description. A short but clear description of the error. Status Exception Data: Textual exception data. A short but clear description of what might appear in this field. Description: Describe the underlying cause for this status code value. 7.2. Additions to iCalendar METHOD Registry This documents defines the following values for the iCalendar "METHOD" property using the values template from Section 8.2.6 of [RFC5545]. These should be added to the Methods Registry defined in Section 8.3.12 of [RFC5545]: 7.2.1. METHOD:PUBLISH Value: PUBLISH Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.2. METHOD:REQUEST Value: REQUEST Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.3. METHOD:REPLY Daboo Expires April 7, 2010 [Page 128] Internet-Draft iTIP October 2009 Value: REPLY Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.4. METHOD:ADD Value: ADD Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.5. METHOD:CANCEL Value: CANCEL Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.6. METHOD:REFRESH Value: REFRESH Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.7. METHOD:COUNTER Value: COUNTER Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.2.8. METHOD:DECLINECOUNTER Value: DECLINECOUNTER Purpose: Standard iTIP "METHOD" value. Conformance: Only used with the "METHOD" property. Examples: See this RFC. 7.3. REQUEST-STATUS Value Registry The following table is to be used to initialize the "REQUEST-STATUS" value registry. Daboo Expires April 7, 2010 [Page 129] Internet-Draft iTIP October 2009 +-------------+---------+-------------------------+ | Status Code | Status | Reference | +-------------+---------+-------------------------+ | 2.0 | Current | RFCXXXX, Section 3.6.1 | | 2.1 | Current | RFCXXXX, Section 3.6.2 | | 2.2 | Current | RFCXXXX, Section 3.6.3 | | 2.3 | Current | RFCXXXX, Section 3.6.4 | | 2.4 | Current | RFCXXXX, Section 3.6.5 | | 2.5 | Current | RFCXXXX, Section 3.6.6 | | 2.6 | Current | RFCXXXX, Section 3.6.7 | | 2.7 | Current | RFCXXXX, Section 3.6.8 | | 2.8 | Current | RFCXXXX, Section 3.6.9 | | 2.9 | Current | RFCXXXX, Section 3.6.10 | | 2.10 | Current | RFCXXXX, Section 3.6.11 | | 2.11 | Current | RFCXXXX, Section 3.6.12 | | 3.0 | Current | RFCXXXX, Section 3.6.13 | | 3.1 | Current | RFCXXXX, Section 3.6.14 | | 3.2 | Current | RFCXXXX, Section 3.6.15 | | 3.3 | Current | RFCXXXX, Section 3.6.16 | | 3.4 | Current | RFCXXXX, Section 3.6.17 | | 3.5 | Current | RFCXXXX, Section 3.6.18 | | 3.6 | Current | RFCXXXX, Section 3.6.19 | | 3.7 | Current | RFCXXXX, Section 3.6.20 | | 3.8 | Current | RFCXXXX, Section 3.6.21 | | 3.9 | Current | RFCXXXX, Section 3.6.22 | | 3.10 | Current | RFCXXXX, Section 3.6.23 | | 3.11 | Current | RFCXXXX, Section 3.6.24 | | 3.12 | Current | RFCXXXX, Section 3.6.25 | | 3.13 | Current | RFCXXXX, Section 3.6.26 | | 3.14 | Current | RFCXXXX, Section 3.6.27 | | 4.0 | Current | RFCXXXX, Section 3.6.28 | | 5.0 | Current | RFCXXXX, Section 3.6.29 | | 5.1 | Current | RFCXXXX, Section 3.6.30 | | 5.2 | Current | RFCXXXX, Section 3.6.31 | | 5.3 | Current | RFCXXXX, Section 3.6.32 | +-------------+---------+-------------------------+ 8. Acknowledgments This is an update to the original iTIP document authored by S. Silverberg, S. Mansour, F. Dawson and R. Hopson. This revision is the product of the Calsify IETF Working Group, and several participants have made important contributions to this specification, including: Oliver Block, Bernard Desruisseaux, Mike Douglass, Tim Hare, Ciny Joy, Bruce Kahn, Reinhold Kainhofer, Eliot Lear, Jonathan Lennox, Andy Mabbett, Aki Niemi, John W. Noerenberg Daboo Expires April 7, 2010 [Page 130] Internet-Draft iTIP October 2009 II, Robert Ransdell, Caleb Richardson. 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009. 9.2. Informative References [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-Based Interoperability Protocol (iMIP)", draft-ietf-calsify-rfc2447bis-06 (work in progress), September 2009. Appendix A. Differences from RFC 2446 A.1. Changed Restrictions This specification now defines an allowed combination of "REQUEST- STATUS" codes when multiple iCalendar components are included in an iTIP message. This specification now restricts "RECURRENCE-ID" to only a single occurrence in any one iCalendar component in an iTIP message as required by [RFC5545]. Changed "RECURRENCE-ID" entry in component restriction table to "0 or 1" from "0+" to fall in line with [RFC5545]. Changed "FREEBUSY" entry in "VFREEBUSY" "PUBLISH" and "REPLY" restriction table to "0+" from "1+" to fall in line with [RFC5545]. Changed "FREEBUSY" description in "VFREEBUSY" "REPLY" restriction table to indicate that different "FBTYPE" ranges MUST NOT overlap. Changed "TZNAME" entry in "VTIMEZONE" restriction table to "0+" from "0 or 1" to fall in line with [RFC5545]. Daboo Expires April 7, 2010 [Page 131] Internet-Draft iTIP October 2009 Changed "COMMENT" entry in component restriction tables to "0+" from "0 or 1" to fall in line with [RFC5545]. Added "ATTENDEE" entry in "VALARM" restriction table to match email alarm type in [RFC5545]. Changed "CATEGORIES" entry in component restriction tables to "0+" from &"job-state" and "job- state-reasons" attributes in human readable text. If the Printer object supports this attribute, the Printer object MUST be able to generate this message in any of the natural languages identified by the Printer's "generated-natural-language-supported" attribute (see the "attributes-natural-language" operation attribute specified in Section 3.1.4.1). The value SHOULD NOT contain additional information not contained in the values of the "job-state" and "job-states-reasons" attributes, such as interpreter error information. Otherwise, application programs might attempt to parse the (localized text). For such additional information such as interpreter errors for application program consumption or specific document access errors, new attributes with keyword values, needs to be developed and registered. 4.3.10 job-detailed-status-messages (1setOf text(MAX)) This attribute specifies additional detailed and technical information about the job. The Printer NEED NOT localize the message(s), since they are intended for use by the system administrator or other experienced technical persons. Localization might obscure the technical meaning of such messages. Clients MUST NOT attempt to parse the value of this attribute. See "job- document-access-errors" (section 4.3.11) for additional errors that a program can process. 4.3.11 job-document-access-errors (1setOf text(MAX)) This attribute provides additional information about each document access error for this job encountered by the Printer after it returned a response to the Print-URI or Send-URI operation and subsequently attempted to access document(s) supplied in the Print- URI or Send-URI operation. For errors in the protocol that is identified by the URI scheme in the "document-uri" operation attribute, such as 'http:' or 'ftp:', the error code is returned in parentheses, followed by the URI. For example: (404) http://ftp.pwg.org/pub/pwg/ipp/new_MOD/ipp-model-v11.pdf Most Internet protocols use decimal error codes (unlike IPP), so the ASCII error code representation is in decimal. Hastings, et al. Standards Track [Page 118] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.3.12 number-of-documents (integer(0:MAX)) This attribute indicates the number of documents in the job, i.e., the number of Send-Document, Send-URI, Print-Job, or Print-URI operations that the Printer has accepted for this job, regardless of whether the document data has reached the Printer object or not. Implementations supporting the OPTIONAL Create-Job/Send- Document/Send-URI operations SHOULD support this attribute so that clients can query the number of documents in each job. 4.3.13 output-device-assigned (name(127)) This attribute identifies the output device to which the Printer object has assigned this job. If an output device implements an embedded Printer object, the Printer object NEED NOT set this attribute. If a print server implements a Printer object, the value MAY be empty (zero- length string) or not returned until the Printer object assigns an output device to the job. This attribute is particularly useful when a single Printer object supports multiple devices (so called "fan-out" - see section 2.1). 4.3.14 Event Time Job Description Attributes This section defines the Job Description attributes that indicate the time at which certain events occur for a job. If the job event has not yet occurred, then the IPP object MUST return the 'no-value' out-of-band value (see the beginning of Section 4.1). The "time-at- xxx(integer)" attributes represent time as an 'integer' representing the number of seconds since the device was powered up (informally called "time ticks"). The "date-time-at-xxx(dateTime)" attributes represent time as 'dateTime' representing date and time (including an offset from UTC). In order to populate these attributes, the Printer object copies the value(s) of the following Printer Description attributes at the time the event occurs: 1. the value in the Printer's "printer-up-time" attribute for the "time-at-xxx(integer)" attributes 2. the value in the Printer's "printer-current-time" attribute for the "date-time-at-xxx(dateTime)" attributes. If the Printer resets its "printer-up-time" attribute to 1 on power- up (see section 4.4.29) and has persistent jobs, then it MUST change all of jobs' "time-at-xxx(integer)" (time tick) job attributes whose events have occurred either to: Hastings, et al. Standards Track [Page 119] RFC 2911 IPP/1.1: Model and Semantics September 2000 1. 0 to indicate that the event happened before the most recent power up OR 2. the negative of the number of seconds before the most recent power-up that the event took place, though the negative number NEED NOT reflect the exact number of seconds. If a client queries a "time-at-xxx(integer)" time tick Job attribute and finds the value to be 0 or negative, the client MUST assume that the event occurred in some life other than the Printer's current life. Note: A Printer does not change the values of any "date-time-at- xxx(dateTime)" job attributes on power-up. 4.3.14.1 time-at-creation (integer(MIN:MAX)) This REQUIRED attribute indicates the time at which the Job object was created. 4.3.14.2 time-at-processing (integer(MIN:MAX)) This REQUIRED attribute indicates the time at which the Job object first began processing after the create operation or the most recent Restart-Job operation. The out-of-band 'no-value' value is returned if the job has not yet been in the 'processing' state (see the beginning of Section 4.1). 4.3.14.3 time-at-completed (integer(MIN:MAX)) This REQUIRED attribute indicates the time at which the Job object completed (or was canceled or aborted). The out-of-band 'no-value' value is returned if the job has not yet completed, been canceled, or aborted (see the beginning of Section 4.1). 4.3.14.4 job-printer-up-time (integer(1:MAX)) This REQUIRED Job Description attribute indicates the amount of time (in seconds) that the Printer implementation has been up and running. This attribute is an alias for the "printer-up-time" Printer Description attribute (see Section 4.4.29). A client MAY request this attribute in a Get-Job-Attributes or Get- Jobs request and use the value returned in combination with other requested Event Time Job Description Attributes in order to display time attributes to a user. The difference between this attribute and the 'integer' value of a "time-at-xxx" attribute is the number of Hastings, et al. Standards Track [Page 120] RFC 2911 IPP/1.1: Model and Semantics September 2000 seconds ago that the "time-at-xxx" event occurred. A client can compute the wall-clock time at which the "time-at-xxx" event occurred by subtracting this difference from the client's wall-clock time. 4.3.14.5 date-time-at-creation (dateTime) This attribute indicates the date and time at which the Job object was created. 4.3.14.6 date-time-at-processing (dateTime) This attribute indicates the date and time at which the Job object first began processing after the create operation or the most recent Restart-Job operation. 4.3.14.7 date-time-at-completed (dateTime) This attribute indicates the date and time at which the Job object completed (or was canceled or aborted). 4.3.15 number-of-intervening-jobs (integer(0:MAX)) This attribute indicates the number of jobs that are "ahead" of this job in the relative chronological order of expected time to complete (i.e., the current scheduled order). For efficiency, it is only necessary to calculate this value when an operation is performed that requests this attribute. 4.3.16 job-message-from-operator (text(127)) This attribute provides a message from an operator, system administrator or "intelligent" process to indicate to the end user the reasons for modification or other management action taken on a job. 4.3.17 Job Size Attributes This sub-section defines job attributes that describe the size of the job. These attributes are not intended to be counters; they are intended to be useful routing and scheduling information if known. For these attributes, the Printer object may try to compute the value if it is not supplied in the create request. Even if the client does supply a value for these three attributes in the create request, the Printer object MAY choose to change the value if the Printer object is able to compute a value which is more accurate than the client supplied value. The Printer object may be able to determine the correct value for these attributes either right at job submission time or at any later point in time. Hastings, et al. Standards Track [Page 121] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.3.17.1 job-k-octets (integer(0:MAX)) This attribute specifies the total size of the document(s) in K octets, i.e., in units of 1024 octets requested to be processed in the job. The value MUST be rounded up, so that a job between 1 and 1024 octets MUST be indicated as being 1, 1025 to 2048 MUST be 2, etc. This value MUST NOT include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the value is independent of the implementation and indicates the size of the document(s) measured in K octets independent of the number of copies. This value MUST also not include the multiplicative factor due to a copies instruction embedded in the document data. If the document data actually includes replications of the document data, this value will include such replication. In other words, this value is always the size of the source document data, rather than a measure of the hardcopy output to be produced. 4.3.17.2 job-impressions (integer(0:MAX)) This attribute specifies the total size in number of impressions of the document(s) being submitted (see the definition of impression in section 12.2.5). As with "job-k-octets", this value MUST NOT include the multiplicative factors contributed by the number of copies specified by the "copies" attribute, independent of whether the device can process multiple copies without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the value is independent of the implementation and reflects the size of the document(s) measured in impressions independent of the number of copies. As with "job-k-octets", this value MUST also not include the multiplicative factor due to a copies instruction embedded in the document data. If the document data actually includes replications of the document data, this value will include such replication. In other words, this value is always the number of impressions in the source document data, rather than a measure of the number of impressions to be produced by the job. Hastings, et al. Standards Track [Page 122] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.3.17.3 job-media-sheets (integer(0:MAX)) This attribute specifies the total number of media sheets to be produced for this job. Unlike the "job-k-octets" and the "job-impressions" attributes, this value MUST include the multiplicative factors contributed by the number of copies specified by the "copies" attribute and a 'number of copies' instruction embedded in the document data, if any. This difference allows the system administrator to control the lower and upper bounds of both (1) the size of the document(s) with "job-k- octets-supported" and "job-impressions-supported" and (2) the size of the job with "job-media-sheets-supported". 4.3.18 Job Progress Attributes This sub-section defines job attributes that describe the progress of the job. These attributes are intended to be counters. That is, the value for a job that has not started processing MUST be 0. When the job's "job-state" is 'processing' or 'processing-stopped', this value is intended to contain the amount of the job that has been processed to the time at which the attributes are requested. When the job enters the 'completed', 'canceled', or 'aborted' states, these values are the final values for the job. 4.3.18.1 job-k-octets-processed (integer(0:MAX)) This attribute specifies the total number of octets processed in K octets, i.e., in units of 1024 octets so far. The value MUST be rounded up, so that a job between 1 and 1024 octets inclusive MUST be indicated as being 1, 1025 to 2048 inclusive MUST be 2, etc. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value MUST be equal to the value of the "job-k-octets" attribute. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value MUST be a multiple of the value of the "job-k-octets" attribute. 4.3.18.2 job-impressions-completed (integer(0:MAX)) This job attribute specifies the number of impressions completed for the job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. Hastings, et al. Standards Track [Page 123] RFC 2911 IPP/1.1: Model and Semantics September 2000 4.3.18.3 job-media-sheets-completed (integer(0:MAX)) This job attribute specifies the media-sheets completed marking and stacking for the entire job so far whether those sheets have been processed on one side or on both. 4.3.19 attributes-charset (charset) This REQUIRED attribute is populated using the value in the client supplied "attributes-charset" attribute in the create request. It identifies the charset (coded character set and encoding method) used by any Job attributes with attribute syntax 'text' and 'name' that were supplied by the client in the create request. See Section 3.1.4 for a complete description of the "attributes-charset" operation attribute. This attribute does not indicate the charset in which the 'text' and 'name' values are stored internally in the Job object. The internal charset is implementation-defined. The IPP object MUST convert from whatever the internal charset is to that being requested in an operation as specified in Section 3.1.4. 4.3.20 attributes-natural-language (naturalLanguage) This REQUIRED attribute is populated using the value in the client supplied "attributes-natural-language" attribute in the create request. It identifies the natural language used for any Job attributes with attribute syntax 'text' and 'name' that were supplied by the client in the create request. See Section 3.1.4 for a complete description of the "attributes-natural-language" operation attribute. See Sections 4.1.1.2 and 4.1.2.2 for how a Natural Language Override may be supplied explicitly for each 'text' and 'name' attribute value that differs from the value identified by the "attributes-natural-language" attribute. 4.4 Printer Description Attributes These attributes form the attribute group called "printer- description". The following table summarizes these attributes, their syntax, and whether or not they are REQUIRED for a Printer object to support. If they are not indicated as REQUIRED, they are OPTIONAL. The maximum size in octets for 'text' and 'name' attributes is indicated in parenthesizes. Note: How these attributes are set by an Administrator is outside the scope of this IPP/1.1 document. Hastings, et al. Standards Track [Page 124]quot;0 or 1" to fall in line with [RFC5545]. Changed "RESOURCES" entry in component restriction tables to "0+" from "0 or 1" to fall in line with [RFC5545]. Changed "CONTACT" entry in "VFREEBUSY" restriction table to "0 or 1" from "0+" to fall in line with [RFC5545]. Changed "UID" entry in "VFREEBUSY" "PUBLISH" restriction table to "1" from "0" to fall in line with [RFC5545]. Added "COMPLETED" entry in "VTODO" restriction tables to fall in line with [RFC5545]. Added "REQUEST-STATUS" entry in "VJOURNAL" restriction tables to fall in line with [RFC5545]. A.2. Deprecated features The "EXRULE" property was removed in [RFC5545] and references to that have been removed in this document too. The "PROCEDURE" value for the "ACTION" property was removed in [RFC5545] and references to that have been removed in this document too. The "THISANDPRIOR" option for the "RANGE" parameter was removed in [RFC5545] and references to that have been removed in this document too. Appendix B. Change History (to be removed prior to publication as an RFC) Changes in -10: a. Gen-ART: changed section title "Eavesdropping" to "Eavesdropping and Data Integrity". b. SecDir: changed "encrypted" to "encrypted and authenticated" in 6.2. Daboo Expires April 7, 2010 [Page 132] Internet-Draft iTIP October 2009 c. SecDir: removed S/MIME reference and changed text to just talk about "generic" authentication and encryption. d. SecDir: added access controls and filtering section. e. IESG: fixed "THISANDFUTURE" -> "THISANDPRIOR" in A.2. f. IESG: 2447bis is now an informative reference. g. IESG: Changed text about email groups to reference mailto URI. h. IESG: tweaked fallback text for free/busy methods. i. IESG: fallback for DURATION in events and to-dos now required. j. IESG: removed last sentence in 6.2.1. k. IESG: added reference to values template section in 2445bis in IANA section. l. IESG: clarified that 2.0 is the default REQUEST-STATUS if the property is not present. m. IANA: added registry for REQUEST-STATUS codes. n. Updated to RFC 5545 reference! o. Fixed minor typos. Changes in -09: a. Updated to RFC5322 reference. b. Fixed more issues from Reinhold Kainhofer review being tracked on the WG wiki. Changes in -08: a. AD review: Changed "calendar entry" to "iCalendar object". b. AD review: Added extra captions above restriction tables for more clarity. c. AD review: Added missing step of uninvited CU replying to Organizer in description of event forwarding. d. AD review: Clarified text about "unsuccessful" REQUEST processing. e. AD review: VFREEBUSY text about allowing multiple components moved into description of PUBLISH method. f. AD review: VTODO description changed to reflect fact that originator is not always the Organizer. g. AD review: Changed VTODO ADD description to use proper 3.14 code instead of 5.3. h. AD review: Changed short description on 5.0 status code. i. AD review: Added IANA-PROPERTY/COMPONENT items to restrictions tables and changed 3.7.3 to better reflect requirements on handling extensions. j. AD review: Fixed example in 4.2.4. k. AD review: Clarified who is responsible for updating the delegator in 4.2.5. l. AD review: Fixed PARTSTAT in example in 4.2.6. m. AD review: Added reference to IANA methods registry in 2445bis in IANA section. Daboo Expires April 7, 2010 [Page 133] Internet-Draft iTIP October 2009 n. Removed section on calculating recurring due dates as that is covered in 2445bis. o. Fixed lots of issues from Reinhold Kainhofer review being tracked on the WG wiki. p. Fixed DECLINE-COUNTER -> DECLINECOUNTER. Changes in -07: a. IANA considerations now registers METHOD values. b. Added Appendix with key 2446 changes and text to the introduction pointing to that. Changes in -06: a. Added text to SEQUENCE number description about detecting a significant change. b. Added text to REQUEST-STATUS section describing the allowed combinations of codes. c. Added text to REQUEST-STATUS section to require new codes to be defined in a standard or experimental RFC. d. Removed THISANDFUTURE. e. Cleaned up some examples. Changes in -05: a. Changed "memo" to "specification". b. Removed EXRULE as it is no longer in 2445bis. c. Removed section on PROCEDURE alarms since those are no longer in 2445bis. d. Changed TYPE= to CUTYPE=. e. Fixed formatting of examples. f. Use lowercase mailto everywhere. Changes in -04: a. Added empty IANA Considerations section - to be done. b. Formatting fixes. c. Changed VEVENT, VTODO, VJOURNAL cancel descriptions that incorrectly implied RECURRENCE-ID could appear multiple times in a single component. d. [Issue91] FREEBUSY properties changed to '0+' from '1+' in VFREEBUSY PUBLISH and REPLY tables. e. [Issue89] Description for VEVENT ADD method simplified for clarity. f. Fixed some iCalendar property/parameter/value capitalization issues. g. MAY NOT -> MUST NOT in VFREEBUSY FREEBUSY response type. Changes in -03: a. Added empty IANA Considerations section - to be done. Changes in -02: Daboo Expires April 7, 2010 [Page 134] Internet-Draft iTIP October 2009 a. Tweaked abstract wording. b. Fixed some improper references. c. Removed bogus TZOFFSET entry from VTIMEZONE restriction table. d. Changed TZNAME entry in VTIMEZONE restriction table to "0+" from "0 or 1" to fall in line with 2445. e. Changed COMMENT entry in component restriction tables to "0+" from "0 or 1" to fall in line with 2445. f. Added ATTENDEE entry in VALARM restriction table to match email alarm type in 2445. g. Changed CATEGORIES entry in component restriction tables to "0+" from "0 or 1" to fall in line with 2445. h. Changed RESOURCES entry in component restriction tables to "0+" from "0 or 1" to fall in line with 2445. i. Changed CONTACT entry in VFREEBUSY restriction table to "0 or 1" from "0+" to fall in line with 2445. j. Made UID required in VFREEBUSY publish. k. Added COMPLETED entry in VTODO restriction tables to fall in line with 2445. l. Added REQUEST-STATUS entry in VJOURNAL restriction tables to fall in line with 2445. Changes in -01: a. Updated to 2445bis and 2447bis references. Changes in -00 (from RFC2446): a. Updated to latest i-d boilerplate text. b. Rewrote abstract and introduction. c. Reformatted Formatting Conventions section. d. Split iTIP Roles and Transactions into two sections e. iTIP roles uses a table to describe different roles f. Converted tables into xml2rfc format. Author's Address Cyrus Daboo (editor) Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA Email: cyrus@daboo.name URI: http://www.apple.com/ Daboo Expires April 7, 2010 [Page 135]