xep-0097.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM "xep.ent">
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
  <header>
    <title>iCal Envelope</title>
    <abstract>A simple mechanism to transport iCal data over the jabber protocol</abstract>
    &LEGALNOTICE;
    <number>0097</number>
    <status>Deferred</status>
    <type>Standards Track</type>
    <sig>Standards</sig>
    <approver>Council</approver>
    <dependencies><spec>XEP-0030</spec></dependencies>
    <supersedes/>
    <supersededby/>
    <shortname>ice</shortname>
    <author>
      <firstname>Justin</firstname>
      <surname>Kirby</surname>
      <email>justin@openaether.org</email>
      <jid>zion@openaether.org</jid>
    </author>
    <revision>
      <version>0.1</version>
      <date>2003-06-10</date>
      <initials>jk</initials>
      <remark>Initial draft (jk).</remark>
    </revision>
  </header>
  <section1 topic='Introduction'>
    <p>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<note>iCalendar <link url='http://www.ietf.org/html.charters/calsch-charter.html'>http://www.ietf.org/html.charters/calsch-charter.html</link></note>. Since iCal is a defined standard which is transport-agnostic, all this document will do is define how iCal will be transported over Jabber.</p>
    <p>What this document will cover:</p>
    <ul>
      <li>Sending iCal data</li>
      <li>Receiving iCal data</li>
    </ul>
  </section1>
  <section1 topic='Disco'>
    <p>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.</p>
    <example><![CDATA[
<iq
  type='get'
  from='romeo@montague.net/orchard'
  to='juliet@capulet.com/balconey'
  id='info1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>]]></example>
    <p>If the jabber entity supports iCal Envelopes, then it MUST respond with http://jabber.org/protocol/gw/ical as a feature.</p>
    <example><![CDATA[
<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>]]></example>
  </section1>
  <section1 topic='Sending iCal Data'>
    <p>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.</p>
    <p>Other than wrapping iCal in XML, the data itself MUST follow the ietf 2445 RFC<note>2445 RFC <link url='http://www.ietf.org/rfc/rfc2445.txt'>http://www.ietf.org/rfc/rfc2445.txt</link></note></p>
    <example><![CDATA[
<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>]]></example>
    <p>As a convenience for users which do not have ical support the sender may want to place human readable information in the &lt;body/&gt; for the receiver to read.</p>
  </section1>
  <section1 topic='Receiving iCal Data'>
    <p> When a client receives a message containing iCal data there are a few options which are considered reasonable.</p>
    <ul>
      <li>Ignore the message</li>
      <li>Display the ical data in the message</li>
      <li>Hand the ical data off to the user's calendaring application</li>
    </ul>
    <p>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.</p>
    <p>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.</p>
    <p>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.</p>
  </section1>
  <section1 topic='IANA Considerations'>
    <p>This document requires no interaction with the Internet Assigned Numbers Authority (IANA)</p>
  </section1>
  <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
    <p>The 'http://jabber.org/protocol/gw/ical' namespace is registered with the XMPP Registrar as a result of this document.</p>
  </section1>
  <section1 topic='Formal Definition'>
    <section2 topic='Schema'>
      <p>TBD</p>
    </section2>
    <section2 topic='DTD'>
      <p>TBD</p>
    </section2>
  </section1>
  <section1 topic='Unresolved Issues'>
    <p>The following are issues that need to be resolved</p>
    <ul>
      <li>Does scheduling negotiation need to be defined?</li>
      <li>How should attachments to ical be handled?</li>
    </ul>
  </section1>
</xep>