| Abstract: | A simple mechanism to transport iCal data over the jabber protocol |
| Author: | Justin Kirby |
| Copyright: | © 1999 - 2011 XMPP Standards Foundation. SEE LEGAL NOTICES. |
| Status: | Deferred |
| Type: | Standards Track |
| Version: | 0.1 |
| Last Updated: | 2003-06-10 |
WARNING: Consideration of this document has been Deferred by the XMPP Standards Foundation. Implementation of the protocol described herein is not recommended.
1. Introduction
2. Disco
3. Sending iCal Data
4. Receiving iCal Data
5. IANA Considerations
6. XMPP Registrar Considerations
7. Formal Definition
7.1. Schema
7.2. DTD
8. Unresolved Issues
Appendices
A: Document Information
B: Author Information
C: Legal Notices
D: Relation to XMPP
E: Discussion Venue
F: Requirements Conformance
G: Notes
H: Revision History
This will be the first, in a series (hopefully), of specifications which will define how to utilize GroupWare over jabber. While GroupWare is extremely broad subject, this document will focus on iCal [1]. Since iCal is a defined standard which is transport-agnostic, all this document will do is define how iCal will be transported over Jabber.
What this document will cover:
Before sending iCal messages to a jabber entity, a disco query should be performed in order to discover whether or not that entity supports iCal Envelopes.
<iq
type='get'
from='romeo@montague.net/orchard'
to='juliet@capulet.com/balconey'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>
If the jabber entity supports iCal Envelopes, then it MUST respond with http://jabber.org/protocol/gw/ical as a feature.
<iq
type='result'
from='juliet@capulet.com/balconey'
to='romeo@montague.net/orchard'
id='info1'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='http://jabber.org/protocol/gw/ical'/>
</query>
</iq>
To send iCal, all that needs to be done is wrap the iCal data in a ical element. All iCal data sent MUST be in the ical element in the http://jabber.org/protocol/gw/ical namespace. The CDATA section is optional and is used here simply to make it readable.
Other than wrapping iCal in XML, the data itself MUST follow the ietf 2445 RFC [2]
<message to="jdev@jabber.org" from="calendar.jabber.org" type="normal">
<body>
Protocol gathering every Tuesday at 22:00 UTC
located in foundation@conference.jabber.org
</body>
<ical xmlns="http://jabber.org/protocol/gw/ical">
BEGIN:VCALENDAR
PRODID:-//Ximian//NONSGML Evolution Calendar//EN
VERSION:2.0
METHOD:PUBLISH
BEGIN:VEVENT
UID:20030418T014238Z-5727-500-1-2@oadev
DTSTAMP:20030418T014238Z
DTSTART:20030422T220000Z
DTEND:20030422T230000Z
SEQUENCE:3
SUMMARY:XEPs
LOCATION:foundation@conference.jabber.org
CATEGORIES:XSF
CLASS:PUBLIC
TRANSP:OPAQUE
LAST-MODIFIED:20030418T014527Z
DESCRIPTION:discuss jeps
RRULE:FREQ=WEEKLY;INTERVAL=1;BYDAY=TU
END:VEVENT
END:VCALENDAR
</ical>
</message>
As a convenience for users which do not have ical support the sender may want to place human readable information in the <body/> for the receiver to read.
When a client receives a message containing iCal data there are a few options which are considered reasonable.
Per the jabber standard, any message received which the entity does not understand CAN be ignored. This behavior is expected of clients which have not implemenred this jep.
The entity may display the ical data as text to the user, this is not recommended for obvious reasons. However, some data is better than no data, so this is considered preferable to just dropping the message stanza.
Most users today have some form of calendaring functionality available to them which supports the iCal standard. Simply redirecting the received ical to the user's preferred calendaring application would be the ideal scenario.
This document requires no interaction with the Internet Assigned Numbers Authority (IANA)
The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this document.
TBD
TBD
The following are issues that need to be resolved
Series: XEP
Number: 0097
Publisher: XMPP Standards Foundation
Status:
Deferred
Type:
Standards Track
Version: 0.1
Last Updated: 2003-06-10
Approving Body: XMPP Council
Dependencies: None
Supersedes: None
Superseded By: None
Short Name: ice
Source Control:
HTML
This document in other formats:
XML
PDF
Email:
justin@openaether.org
JabberID:
zion@openaether.org
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
1. iCalendar http://www.ietf.org/html.charters/calsch-charter.html
2. 2445 RFC http://www.ietf.org/rfc/rfc2445.txt
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
END