<!ENTITY rfc3283 "<span class='ref'><linkurl='http://tools.ietf.org/html/rfc3283'>Guide to Internet Calendaring</link></span><note>RFC 3283: Guide to Internet Calendaring <<linkurl='http://tools.ietf.org/html/rfc3283'>http://tools.ietf.org/html/rfc3283</link>>.</note>" >
<!ENTITY draft-xcal "<span class='ref'><linkurl='http://tools.ietf.org/html/draft-royer-calsch-xcal'>iCalendar in XML Format</link></span><note>iCalendar in XML Format (xCal-Basic) <<linkurl='http://tools.ietf.org/html/draft-royer-calsch-xcal-03'>http://tools.ietf.org/html/draft-royer-calsch-xcal-03</link>>.</note>" >
<title>Calendaring Extensions to Publish-Subscribe</title>
<abstract>This specification defines calendaring extensions to Publish-Subscribe for the purposes of group calendaring and scheduling between "Calendar Users" (CUs), accessing, managing, and sharing calendaring and scheduling information on a Calendar Server, and a mechanism for alarm notifications.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0060</spec>
<spec>XEP-0068</spec>
<spec>XEP-0082</spec>
<spec>RFC 2445</spec>
<spec>RFC 2446</spec>
<spec>RFC 4791</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>&SN;</shortname>
<author>
<firstname>Klaus</firstname>
<surname>Hartke</surname>
<email>klaus.hartke@googlemail.com</email>
<jid>nx@jabber.org</jid>
</author>
<revision>
<version>0.0.3.1</version>
<date>2009-02-14</date>
<initials>kh</initials>
<remark><p>Added XML schema; fixed a number of minor issues.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2008-08-01</date>
<initials>kh</initials>
<remark><p>Clarified a number of issues; cleaned up specification.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2008-05-25</date>
<initials>kh</initials>
<remark><p>First (semi) complete version supporting all use cases.</p></remark>
<p>The &rfc3283; describes the relationship between various internet calendaring specifications like this: "&rfc2445; is the language used to describe calendar objects. &rfc2446; (Transport-Independent Interoperability Protocol) describes a way to use the iCalendar language to do scheduling. &rfc2447; (Message-Based Interoperability Protocol) describes how to do iTIP scheduling via e-mail."</p>
<p>Recently another standard track protocol for calendar and scheduling access has appeared. &rfc4791; (Calendaring Extensions to WebDAV) is a &rfc4918; (Web-based Distributed Authoring and Versioning) based mechanism for manipulating internet calendars, and viewing free/busy lists, and via a planned &draft-sched;, could be used for proposing calendar events as well.</p>
<p>This specification defines calendaring extensions to &xep0060; for the purposes of group calendaring and scheduling between "Calendar Users" (CUs) as defined by <cite>iTIP</cite>. Additionally, it defines extensions for accessing, managing, and sharing calendaring and scheduling information on a calendar server, reusing the syntax and semantics defined by <cite>CalDAV</cite>. Finally, it defines a mechanism for reminding of upcoming events by alarm notifications.</p>
<p>The protocol enables all common transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel <cite>iCalendar</cite>-based calendar components, as well as search for busy time information. The protocol is a superset of <cite>Publish-Subscribe</cite> and will gracefully degrade to <cite>Publish-Subscribe</cite> for clients that do not support the calendaring extensions defined.</p>
<!-- == How It Works ===================================================== -->
<section2topic='How It Works'anchor='intro-howitworks'>
<p>This specification follows the same pattern as the Internet calendaring and scheduling standards by developing all features based on a well-described data model. This model is described in <linkurl='#datamodel'>Calendaring Data Model</link>. As a brief overview, calendars are modeled as nodes of a calendaring-aware publish-subscribe service; each calendar node contains a number of items representing calendar objects. Each item representing a calendar object (event, to-do, journal entry, or other calendar components) is called a "calendar item".</p>
<p>Calendar objects are represented using &draft-xcal;. The format is not an alternative or next generation of <cite>iCalendar</cite> but defines how to use XML to represent iCalendar objects in XML. For example, both examples below describe the same single event that begins on July 14, 1997 at 00:00 UTC and ends on July 15, 1997 at 03:59 UTC.</p>
<examplecaption='Bastille Day Party (iCalendar)'><![CDATA[
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//ACME/DesktopCalendar//EN
BEGIN:VEVENT
ORGANIZER:xmpp:a@example.com
DTSTART:19970714T170000Z
DTEND:19970715T035959Z
DTSTAMP:19970611T190000Z
SUMMARY;LANGUAGE="en_US":Bastille Day Party
UID:fcd5cb18-93a6-478d-8f71-95cd78e8ebe6
END:VEVENT
END:VCALENDAR
]]></example>
<examplecaption='Bastille Day Party (iCalendar in XML)'><![CDATA[
<vcalendarxmlns='urn:ietf:params:xml:ns:xcal'>
<version>2.0</version>
<prodid>-//ACME/DesktopCalendar//EN</prodid>
<vevent>
<organizer>xmpp:a@example.com</organizer>
<dtstart>1997-07-14T17:00:00Z</dtstart>
<dtend>1997-07-15T03:59:59Z</dtend>
<dtstamp>1997-06-11T19:00:00Z</dtstamp>
<summaryxml:lang='en-US'>Bastille Day Party</summary>
<uid>fcd5cb18-93a6-478d-8f71-95cd78e8ebe6</uid>
</vevent>
</vcalendar>
]]></example>
<p>This specification is structured as follows: <linkurl='#disco'>Discovering Support</link> describes how to discover support for the calendaring extensions defined by this specification. An entity may create new calendar nodes as described in <linkurl='#create'>Creating Calendars</link>. The section on <linkurl='#publish'>Scheduling Calendar Entries</link> provides the transport specific information necessary to convey <cite>iTIP</cite> messages over <cite>Publish-Subscribe</cite> which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components. The sections <linkurl='#retrieve'>Retrieving Calendar Entries</link> and <linkurl='#freebusy'>Retrieving Free/Busy Time</link> define how to retrieve items from a calendar node, and how to search for busy time information. <linkurl='#alarm'>Alarm Notifications</link> provide a mechanism for setting up and subscribing to alarm notifications.</p>
<p>In order to refer to elements of the calendaring and scheduling model, core object or interoperability protocol defined in <cite>RFC 2445</cite> and <cite>RFC 2446</cite> several formatting conventions have been utilized.</p>
<p>Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" (CU) within the scheduling protocol defined by <cite>RFC 2446</cite>.</p>
<p>Scheduling methods defined by <cite>RFC 2446</cite> are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified, "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component.</p>
<p>Calendar components defined by <cite>RFC 2445</cite> are referred to with capitalized text. All calendar components start with the letter "V". For example, VEVENT refers to the event calendar component, VTODO refers to the to-do calendar component and VJOURNAL refers to the daily journal calendar component.</p>
<p>Properties defined by <cite>RFC 2445</cite> are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a "Calendar User". Property parameters are referred to with lower case, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Values are referred to with quoted-strings of text, either alone or followed by the word "value".</p>
<p>Implementers will need to be familiar with several other specifications that describe the Internet calendaring and scheduling standards. The related documents are:</p>
<ul>
<li><cite>RFC 2445</cite> specifies the objects, data types, properties and property parameters used in the protocols;</li>
<li><cite>RFC 2446</cite> specifies an interoperability protocol for scheduling static and dynamic event, to-do, journal and free/busy objects;</li>
<li><cite>RFC 4791</cite> specifies the syntax for calendaring reports used by this specification.</li>
</ul>
<p>This specification is an extension of the Publish-Subscribe protocol specified by <cite>XEP-0060</cite>, so implementers will need to be familiar with that as well.</p>
<p>This specification does not attempt to repeat the specification of concepts or definitions from these other specifications. Where possible, references are made to the specification that provides that provides the relevant concepts or definitions.</p>
<section1topic='Calendaring Data Model'anchor='datamodel'>
<!--
<p>This specification follows the same pattern as the Internet calendaring and scheduling standards by developing all features based on a well-described data model.</p>
<p>As a brief overview, a calendar is modeled as a publish-subscribe node with a defined structure; each calendar node contains a number of items representing calendar objects. Each item representing a calendar object (event, to-do, journal entry, or other calendar components) is called a "calendar item".</p>
<p>A calendar service is a calendaring-aware engine combined with a publish-subscribe service. A publish-subscribe service enables XMPP entities to create nodes and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node.</p>
<p>A calendar service MAY include calendar data in some of its nodes, and non-calendaring data in others.</p>
<p>A publish-subscribe service can advertise itself as a calendar service if it supports the functionality defined in this specification at any of its nodes. That might mean that calendar nodes are spread throughout the service and mixed with non-calendar nodes. Calendaring features are only required in the nodes that are calendar nodes.</p>
<p>The calendar service is the canonical location for calendar data and state information. Entities may submit requests to change data or download data. Entities may store calendar objects offline and attempt to synchronize at a later time. However, entities MUST be prepared for calendar data on the service to change between the time of last synchronization and when attempting an update, as calendar nodes may be shared and accessed by multiple entities.</p>
<p>A calendar node contains calendar items that represent calendar components within a calendar. A calendar node is manifested to entities as a publish-subscribe node identified by a NodeID. A calendar node MUST report the '&NS;' feature &VNOTE; in the result of a 'disco#info' query. A calendar service MUST persist items for a calendar node.</p>
<p>A calendar node can be created through provisioning (i.e., automatically created when a user's account is provisioned), or it can be created with the publish-subscribe <create/> request (see section <linkurl='#create'>Creating Calendars</link>). It can be useful for a user to create additional calendars (e.g., soccer schedule) or for users to share a calendar (e.g., team events or conference rooms). However, note that this specification doesn't define the purpose of calendar nodes. Users may use the 'pubsub#title' and 'pubsub#description' fields in node meta-data to find out what a calendar node is for.</p>
<p>Calendar nodes MUST only contain calendar items. This ensures that entities do not have to deal with non-calendar data in a calendar node.</p>
<p>Calendar items in a calendar node MUST NOT contain more than one type of calendar component (e.g., VEVENT, VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE components, which MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. For instance, a calendar item can contain one VEVENT component and one VTIMEZONE component, but it cannot contain one VEVENT component and one VTODO component. Instead, the VEVENT and VTODO components would have to be stored in separate calendar items in the same node.</p>
<p>Calendar object items in calendar collections MUST NOT specify the iCalendar "METHOD" property.</p>
<p>The "UID" property value of the calendar components contained in a calendar item MUST be unique in the scope of the calendar node in which they are stored.</p>
<p>Calendar components in a calendar node that have different "UID" property values MUST be stored in separate calendar items.</p>
<p>Calendar components with the same "UID" property value, in a given calendar node, MUST be contained in the same calendar item. This ensures that all components in a recurrence "set" are contained in the same calendar item. It is possible for a calendar item to just contain components that represent "overridden" instances (ones that modify the behavior of a regular instance, and thus include a "RECURRENCE-ID" property) without also including the "master" recurring component (the one that defines the recurrence "set" and does not contain any "RECURRENCE-ID" property).</p>
<!-- == Roles and Transactions =========================================== -->
<section2topic='Roles and Transactions'anchor='rolesandtransactions'>
<p>This specification uses methods defined by <cite>RFC 2446</cite> for exchanging calendar objects for the purposes of group calendaring and scheduling between "Calendar Users" (CUs). CUs take on one of two roles in iTIP. The CU who initiates an exchange takes on the role of "Organizer". For example, the CU who proposes a group meeting is the "Organizer". The CUs asked to participate in the group meeting by the "Organizer" take on the role of "Attendee".</p>
<pclass='box'>Note: "role" is also a descriptive parameter to the "ATTENDEE" property. Its use is to convey descriptive context to an "Attendee" such as "chair", "req-participant" or "non-participant" and has nothing to do with the calendaring workflow.</p>
<p>A calendar entry is created and managed by an "Organizer". The "Organizer" interacts with other CUs by sending one or more requests specifying the "REQUEST" method to a calendar service which will forward these to "Attendees" (and send notifications to pubsub subscribers). "Attendees" use the same requests specifying the "REPLY" method to communicate their status back to the calendar service. "Attendees" cannot make any changes to the calendar entry except for their own status. They can, however, use requests specifying the "COUNTER" method to suggest changes to the "Organizer". In any case, the "Organizer" has complete control over the master calendar entry.</p>
<tablecaption='Methods'>
<tr>
<th>Method</th>
<th>Description</th>
</tr>
<tr>
<td>PUBLISH</td>
<td>Used to publish a calendar object to a calendar node and when sending notifications to pubsub subscribers. There is no interactivity between the publisher and any other calendar user. An example might include a baseball team publishing its schedule to the public.</td>
</tr>
<tr>
<td>REQUEST</td>
<td>Used to schedule a calendar entry with other Calendar Users. Requests are interactive in that they require the receiver to respond using the Reply methods. Invitations and the assignment of To-Dos to other Calendar Users are examples. Requests are also used by the "Organizer" to update the status of a calendar entry.</td>
</tr>
<tr>
<td>REPLY</td>
<td>A Reply is used in response to a Request to convey "Attendee" status to the calendar service (which will forward it to the "Organizer"). Replies are commonly used to respond to meeting and task requests.</td>
</tr>
<tr>
<td>ADD</td>
<td>Add one or more instances to an existing VEVENT, VTODO, or VJOURNAL.</td>
</tr>
<tr>
<td>CANCEL</td>
<td>Cancel one or more instances of an existing VEVENT, VTODO, or VJOURNAL. This does not remove the calendar entry from persistent storage.</td>
</tr>
<tr>
<td>COUNTER</td>
<td>The Counter method is used by an "Attendee" to negotiate a change in the calendar entry. Examples include the request to change a proposed Event time or change the due date for a To-Do.</td>
</tr>
</table>
<p>The methods listed above and their usage and semantics are defined in section 3 of <cite>RFC 2446</cite>.</p>
<p>The other methods defined by <cite>RFC 2446</cite>, REFRESH and DECLINECOUNTER, are not used and MUST NOT be specified by requesting entities. Entities SHOULD use the reporting methods defined in this specification to request the latest version of a calendar entry. "Organizers" MAY decline a proposed counter-proposal by sending a rude chat message to the "Attendee" who proposed the counter-proposal.</p>
<p>Subscriptions to a calendar node may exist in three different ways.</p>
<!--
<p>Subscriptions to a calendar node may exist in three different ways: 'attendee', 'freebusy-subscriber', and/or 'subscriber'. These are not mutually exclusive.</p>
<p>The "authorize" access model is RECOMMENDED.</p>
<p>Group scheduling is accomplished using the set of "request" and "response" methods described above. To manage permissions, this specification builds on the hierarchy of affiliations defined by <cite>XEP-0060</cite>. Therefore, a calendar service MUST support and adhere to the requirements of pubsub affiliations. Calendaring permissions are calculated from the pubsub affiliation of the XMPP entity and, if applicable, the properties of the calendar item involved in an operation.</p>
<!--
<p>A calendar service MUST support the mechanism defined in this section.</p>
<p>The following table shows the methods broken down by who can send them.</p>
<p>There are two distinct states relevant to calendar entries: the overall state of the entry and the state associated with an "Attendee" to that entry.</p>
<p>The state of an entry is defined by the "STATUS" property and is controlled by the "Organizer." There is no default value for the "STATUS" property. The "Organizer" sets the "STATUS" property to the appropriate value for each calendar entry.</p>
<p>The state of a particular "Attendee" relative to an entry is defined by the "partstat" parameter in the "ATTENDEE" property for each "Attendee". When an "Organizer" issues the initial entry, "Attendee" status is unknown. The "Organizer" specifies this by setting the "partstat" parameter to "needs-action". Each "Attendee" modifies their "ATTENDEE" property "partstat" parameter to an appropriate value.</p>
<p>The "SEQUENCE" property is used by the "Organizer" to indicate revisions to the calendar item. The rules for incrementing the "SEQUENCE" number for a given "UID" in a calendar component are as follows:</p>
<ul>
<li>For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property value is incremented according to the rules defined in <cite>RFC 2445</cite>.</li>
<li>The "SEQUENCE" property value MUST be incremented each time the "Organizer" uses the "ADD" or "CANCEL" methods.</li>
<li>The "SEQUENCE" property value MUST NOT be incremented when an "Attendee" modifies the "ATTENDEE" property "partstat" parameter, when an "Attendee" submits a counter proposal to negotiate a change in a calendar item, or when an "Attendee" grants another CU (or several CUs) the right to attend on their behalf.</li>
<li>The "SEQUENCE" property value MUST NOT be incremented when retrieving calendar objects from a calendar node or sending pubsub notifications to subscribers.</li>
<p>The value of the "SEQUENCE" property contained in a response from an "Attendee" may not always match the current revision of the master calendar entry. Implementations may choose to indicate to the "Attendee" that the response is to an entry that has been revised and allow the CU to decide whether or not to send the response.</p>
<p>Calendar services must often correlate a component in a calendar node with a component received in a pubsub request. For example, an event may be updated with a later revision of the same event. To accomplish this, a calendar service must correlate the version of the event already in the calendar node with the version sent in the pubsub request. In addition to this correlation, there are several factors that can cause requests to arrive in an unexpected order. That is, a calendar service could receive a reply to an earlier revision of a component AFTER receiving a reply to a later revision.</p>
<p>To maximize interoperability and to handle messages that arrive in an unexpected order, implementations SHOULD follow the rules in section 2.1.5 of <cite>RFC 2446</cite>. Hence, a calendar service must persist the following component properties: "UID", "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP". Furthermore, for each "ATTENDEE" property of a component a calendar service must persist the "SEQUENCE" and "DTSTAMP" property values associated with the "Attendee's" response.</p>
<p>A calendar service MUST respond to service discovery information requests qualified by the 'http://jabber.org/protocol/disco#info' namespace. The "disco#info" result returned by a calendar service MUST indicate the identity of a pubsub service and indicate which pubsub features are supported. A calendar service supporting the features described in this specification MUST also include "&NS;" as a feature in the "disco#info" result. A feature of "&NS;" &VNOTE; in the result MUST indicate that the service supports all MUST level requirements in this specification.</p>
<examplecaption='Entity queries calendar service regarding supported features'><![CDATA[
<p>A calendar service MUST also allow entities to query individual nodes for the information associated with that node. A calendar service supporting the features described in this specification MUST include "&NS;" &VNOTE; as a feature in the "disco#info" result for a calendar node. It MUST NOT include the feature in the result for a non-calendar node. The "disco#info" result MAY include detailed meta-data about the node as described in section 5.4 of <cite>XEP-0060</cite>.</p>
<examplecaption='Entity queries a node for information'><![CDATA[
<p>An entity may want to create a new calendar node. Support for this feature is RECOMMENDED. However, a calendar service MAY disallow creation of calendar nodes based on the identity of the requesting entity, or MAY disallow calendar node creation altogether (e.g., reserving that privilege to a service-wide administrator).</p>
<p>The methods to create a node are explained in section 8.1 of <cite>XEP-0060</cite>. To create a new calendar node, the requesting entity MUST include a Data Form containing a 'pubsub#type' field whose <value/> is "urn:ietf:params:xml:ns:xcal".</p>
<examplecaption='Entity requests a new calendar node with "authorize" access model'><![CDATA[
<p>If calendar nodes are supported and none of the general or method-specific errors has occurred, the calendar service SHOULD create the node and inform the requesting entity of success.</p>
<examplecaption='Service informs requesting entity of success'><![CDATA[
<p>In addition to the errors already defined for leaf nodes by <cite>XEP-0060</cite>, there are several reasons why the calendar node creation request might fail:</p>
<ol>
<li>The service does not support creation of calendar nodes.</li>
<li>The requesting entity does not have sufficient privileges to create calendar nodes.</li>
</ol>
<p>These error cases are described more fully in the following sections.</p>
<p>A calendar service MUST offer a couple of node configuration options that are specific to calendar nodes and not provided by standard pubsub leaf nodes. The following table shows these configuration options and defines a mapping to the calendar properties specified by <cite>RFC 4791</cite>:</p>
<tablecaption='Calendar configuration options'>
<tr>
<th>Configuration option</th>
<th>Type</th>
<th>Description</th>
<th>CalDAV property</th>
</tr>
<tr>
<td>pubsub#title</td>
<td>text-single</td>
<td>Provides a human-readable description of the calendar node.</td>
<td>calendar-description</td>
</tr>
<tr>
<td>&SN;#timezone</td>
<td>text-single</td>
<td>Specifies a time zone on a calendar node.</td>
<td>calendar-timezone</td>
</tr>
<tr>
<td>&SN;#component_set</td>
<td>text-multi</td>
<td>Specifies the calendar component types (e.g., VEVENT,
VTODO, etc.) that calendar items can contain in the calendar
node.</td>
<td>supported-calendar-component-set</td>
</tr>
<tr>
<td>pubsub#type</td>
<td>text-single</td>
<td>Specifies what media types are allowed for calendar items in
a calendar node.</td>
<td>supported-calendar-data</td>
</tr>
<tr>
<td>pubsub#max_payload_size</td>
<td>text-single</td>
<td>Provides a numeric value indicating the maximum size of a
resource in octets that the calendar service is willing to accept
when a calendar item is stored in a calendar node.</td>
<td>max-resource-size</td>
</tr>
<tr>
<td>&SN;#min_date_time</td>
<td>text-single</td>
<td>Provides a DATE-TIME value indicating the earliest date and
time (in UTC) that the calendar service is willing to accept for
any DATE or DATE-TIME value in a calendar item stored in a calendar
node.</td>
<td>min-date-time</td>
</tr>
<tr>
<td>&SN;#max_date_time</td>
<td>text-single</td>
<td>Provides a DATE-TIME value indicating the latest date and
time (in UTC) that the calendar service is willing to accept for
any DATE or DATE-TIME value in a calendar item stored in a calendar
node.</td>
<td>max-date-time</td>
</tr>
<tr>
<td>&SN;#max_instances</td>
<td>text-single</td>
<td>Provides a numeric value indicating the maximum number of
recurrence instances that a calendar item stored in a calendar
node can generate.</td>
<td>max-instances</td>
</tr>
<tr>
<td>&SN;#max_attendees_per_instance</td>
<td>text-single</td>
<td>Provides a numeric value indicating the maximum number of
"ATTENDEE" properties in any instance of a calendar item stored
in a calendar node.</td>
<td>max-attendees-per-instance</td>
</tr>
</table>
<p>An entity SHOULD should specify the 'pubsub#title' field for a human-readable name of the calendar when configuring a calendar node. The entity SHOULD NOT set the 'pubsub#title' field to be the same as any other calendar node owned by the same entity. When displaying calendar nodes to users, clients SHOULD check the 'pubsub#title' field and use that value as the name of the calendar. In the event that the 'pubsub#title' field is empty, the client MAY use the NodeID of the calendar as the name; however, the NodeID may be "opaque" and not represent any meaningful human-readable text.</p>
<p>An entity may schedule calendar entries by sending a <publish/> request to the calendar service. Support for this feature is REQUIRED.</p>
<p>The syntax is as follows:</p>
<ul>
<li>The <publish/> element MUST possess a 'node' attribute, specifying the NodeID of the calendar node.</li>
<li>Depending on the node configuration, the <publish/> element MAY contain no &ITEM; elements, one &ITEM; element, or (for Batch Processing) more than one &ITEM; element.</li>
<li>Each &ITEM; element MUST contain a <vcalendar/> element qualified by the 'urn:ietf:params:xml:ns:xcal' namespace.</li>
<li>The <vcalendar/> element MUST contain a <method/> element, specifying the calendaring-specific method of the request.</li>
<li>The <vcalendar/> element MUST contain an XML element qualified by the 'urn:ietf:params:xml:ns:xcal' namespace representing the calendar object to publish (i.e. <vevent/>, <vtodo/>, <vjournal/>, etc.).</li>
<li>The calendar object MAY contain an "UID" property, specifying a unique ItemID for the item. If an ItemID is not provided, the calendar service MUST generate one and MUST ensure that it is unique for that calendar node.</li>
<li>If an ItemID is specified in the publish request, the &ITEM; element MUST possess an 'id' attribute whose value is the ItemID. Otherwise, the &ITEM; element MUST NOT possess an 'id' attribute.</li>
<li>The calendar object MUST conform to the property constraints defined in <cite>RFC 2446</cite> for the specified method, except for the "UID" property which is OPTIONAL for ItemID generation purposes as described above. The "ORGANIZER" property MUST be present and MUST be set to an XMPP URI identifying the publishing entity.</li>
</ul>
<p>The example below publishes a single event that begins on July 1, 1997 at 20:00 UTC. This event contains the minimum set of properties for publishing an event to a calendar.</p>
<examplecaption='"Organizer" publishes a minimal event with an ItemID'><![CDATA[
<p>If the calendar service can successfully process the request, it MUST inform the publisher of success. If the publish request did not include an ItemID, the IQ-result SHOULD include an empty <item/> element that specifies the ItemID of the published item.</p>
<examplecaption='Service replies with success'><![CDATA[
<iqtype='result'
from='pubsub.shakespeare.lit'
to='hamlet@denmark.lit/blogbot'
id='publish1'/>
]]></example>
<pclass='box'>Note: If the publisher previously published an item with the same ItemID, successfully processing the request means that the service MUST proceed as described in <cite>RFC 2446</cite> for the calendaring-specific method used. This usually means that the service MUST overwrite the old calendar entry with a modified entry and then proceed as follows.</p>
<p>The calendar service MUST then send one &MESSAGE; stanza containing a pubsub event notification to each entity that meets the criteria for receiving a notification, as described in section 7.1.2 of <cite>XEP-0060</cite>. Event notifications MUST be sent specifying the "PUBLISH" method, even if the event notification results from a publishing request that specified a different method.</p>
<p>In addition to the errors already defined for publish requests by <cite>XEP-0060</cite>, there are several reasons why the request might fail:</p>
<ol>
<li>The namespace of the root payload element submitted in the request does not match the configured namespace for the node, or the payload does not conform to the syntax of the 'urn:ietf:params:xml:ns:xcal' namespace.</li>
<li>The calendar component submitted in the request does not contain a type of calendar component that is supported in the calendar node.</li>
<li>The calendar component submitted in the request does not obey all restrictions.</li>
<li>The calendar component submitted in the request does not conform to the configuration.</li>
</ol>
<p>These error cases are described more fully in the following sections.</p>
<p>If the namespace of the root payload element submitted in the request does not match the configured namespace for the node (i.e., the 'urn:ietf:params:xml:ns:xcal' namespace) or the payload does not conform to the syntax of the 'urn:ietf:params:xml:ns:xcal' namespace, the service MUST respond with a &badrequest; error, which SHOULD also include a pubsub-specific error condition of <invalid-payload/>.</p>
<examplecaption='Entity attempts to publish item with invalid payload'><