One document matched: draft-royer-calsch-xcal-02.txt
Differences from draft-royer-calsch-xcal-01.txt
Network Working Group D. Royer
Internet-Draft IntelliCal
Expires: February 27, 2006 August 26, 2005
iCalendar in XML Format (xCal-Basic)
draft-royer-calsch-xcal-02
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
The mailing list for discussion of this memo is "xCal@
INET-Consulting.com" and signup page at
"http://INET-Conusulting.com/mailman/listinfo/xcal. This is a
rerelease of an expired draft with updates and a much more simplivied
approach. This approach uses an exact 1 to 1 mapping between
iCalendar and xml objects.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
Royer Expires February 27, 2006 [Page 1]
Internet-Draft xCal-Basic-RSS August 2005
document are to be interpreted as described in [KEYWORDS].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Using XML For Representating iCalendar . . . . . . . . . . . . 4
2.1 XML Dependencies . . . . . . . . . . . . . . . . . . . . . 5
2.2 Working With Standard and XML iCalendar Representations . 5
2.2.1 Conversion . . . . . . . . . . . . . . . . . . . . . . 5
2.2.2 Mixed Use of Both Representations . . . . . . . . . . 5
2.3 Using Data Types . . . . . . . . . . . . . . . . . . . . . 6
2.4 Including Binary Content . . . . . . . . . . . . . . . . . 6
2.5 Including Multiple iCalendar Objects . . . . . . . . . . . 7
2.6 Mapping Property Parameters to XML . . . . . . . . . . . . 7
2.7 Mapping VCALENDAR object Properties to XML . . . . . . . . 8
2.8 Mapping All Components to XML . . . . . . . . . . . . . . 9
2.9 Mapping All Values to XML . . . . . . . . . . . . . . . . 10
2.10 Emailing the iCalendar XML Representation . . . . . . . . 11
2.11 iCalendar XML Representation and File Systems . . . . . . 12
3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1 A well-formed and valid iCalendar XML document . . . . . . 13
3.2 Including binary content in attachments . . . . . . . . . 13
3.3 iCalendar XML document with multiple iCalendar objects . . 15
3.4 Using the iCalendar namespace . . . . . . . . . . . . . . 16
3.5 Publish meeting information . . . . . . . . . . . . . . . 16
3.6 Publish transparent annual event . . . . . . . . . . . . . 17
3.7 Meeting invitation . . . . . . . . . . . . . . . . . . . . 17
3.8 Publish busy time . . . . . . . . . . . . . . . . . . . . 18
3.9 Request busy time . . . . . . . . . . . . . . . . . . . . 19
3.10 Issue a CAP command . . . . . . . . . . . . . . . . . . . 19
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
7. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23
Intellectual Property and Copyright Statements . . . . . . . . 24
Royer Expires February 27, 2006 [Page 2]
Internet-Draft xCal-Basic-RSS August 2005
1. Introduction
The Extended Markup Language (XML) as defined in [XML] is gaining
widespread attention as a "web friendly" syntax for representing and
exchanging documents and data on the Internet. This interest
includes requests for and discussion of possible document type
definitions (DTD) and name-space for IETF standard formats such as
that defined by [iCAL]. This memo defines how XML can be used to
represent iCalendar objects and does not specify a DTD as iCalendar
can be extended.
This format was selected to ease its translation back to the
iCalendar format using an XSLT transform. (See project iCalendar on
SourceForge.com - http://sourceforge.net/projects/icalendar/ )
NOTE: The [iCAL] is the definitive reference for the definition of
iCalendar semantics. This memo only provides an alternative, XML
representation for the standard syntax defined in [iCAL]. This memo
does not introduce any semantics not already defined by [RFC 2445].
An attempt has been made to leverage the standard features of the XML
syntax in order to represent the component iCalendar semantics. For
example, strong data typing is specified using the XML notation
declaration. The element type attributes are used to represent many
of the calendar properties that provide a "global attribute"
capability in an iCalendar object. Binary content in the ATTACH
component property may either be specified through an external entity
reference to a non-XML binary content or may be included in the XML
document's content information, after first being encoding using the
BASE64 scheme of [RFC 2146].
The publication of XML version 1.0 was followed by the publication of
a World-wide Web Consortium (W3C) recommendation on "Namespaces in
XML". A XML name-space is a collection of names, identified by a
URI. In anticipation of the broader use of XML namespaces. Within
this memo the term "xCal" will mean the XML namespace usage as
described in this memo.
Royer Expires February 27, 2006 [Page 3]
Internet-Draft xCal-Basic-RSS August 2005
2. Using XML For Representating iCalendar
XML is a simplified version of the text markup syntax defined by ISO
8879, Standard Generalized Markup Language (SGML). XML was published
as a proposed recommendation [XML] by the World-wide Web Consortium
(W3C) on February 10, 1998.
In iCalendar names can be in upper case, lower case, or mixed case.
In xCal the predefined iCaledars names will be represented in lower
case only as XML element and attribute names are case sensitive..
Values to properties and parameters that are user specified may be in
upper, lower, or mixed case.
All iCalendar component names will be represented in xCal as XML
element names in lower case. The "BEGIN" iCalendar component will be
represented in xCal as: <begin>.
All iCalendar property names will be represented in xCal as XML
element names in lower case.
All iCalendar parameter names will be represented in xCal as XML
attribute names in lower case.
All iCalendar predefined names that are used as values will be
represented in xCal in lower case.
This example:
BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//hacksw/handcal//NONSGML v1.0//EN
BEGIN:VEVENT
DTSTART:19970714T170000Z
DTEND:19970715T035959Z
SUMMARY;LANGUAGE="en_US":Bastille Day Party
END:VEVENT
END:VCALENDAR
Is represented in xCal as:
Royer Expires February 27, 2006 [Page 4]
Internet-Draft xCal-Basic-RSS August 2005
<?xml version="1.0" TODO_NAMESPACE="foo"?>
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<version>2.0</version>
<prodid>-//hacksw/handcal//NONSGML v1.0//EN</prodid>
<vevent>
<dtstart>19970714T170000Z</dtstart>
<dtendt>19970715T035959Z</dtend>
<summary xml:lang="en_US">Bastille Day Party</summary>
</vevent>
</vcaledar>
</iCalendar>
2.1 XML Dependencies
This memo specifies the XML representation for the standard iCalendar
format defined by [iCAL]. There are no XML dependencies other than
the [XML] and the [XMLNS] recommendations.
2.2 Working With Standard and XML iCalendar Representations
This memo defines an alternative, XML representation for the standard
iCalendar format defined in [iCAL]. This alternative representation
provides the same semantics as that defined in the standard format.
It is the goal of this memo to allow all [iCAL] extensions and
modifications to be translated into and from this XML format.
2.2.1 Conversion
The standard format can be converted to and from this XML format
without loss of any calendaring information. When the XML
representation was defined, every attempt was made to use existing
component, property and parameter naming conventions. This greatly
facilitates transformations between the two representations.
2.2.2 Mixed Use of Both Representations
As previously indicated, conversion between the standard and XML
representations of iCalendar is a straightforward process. In
addition, mixed use of both representations is also possible using
MIME objects.
With the use of the MIME multipart content-types, compound MIME
entities containing a mix of the standard and XML representations can
be specified. This capability is useful in applications where both
representations might be encountered. In addition, this capability
Royer Expires February 27, 2006 [Page 5]
Internet-Draft xCal-Basic-RSS August 2005
demonstrates the isomeric nature of the two representations. XML
applications conforming to this specification MUST be able to
properly parse and process a MIME multipart entity containing the
MIME type associated with this iCalendar XML document type.
Internet applications conforming to this memo MUST only send the
iCalendar XML document in a "multipart/alternative" MIME entity that
also contains an equivalent iCalendar object in the standard format
defined by [RFC2445]. This restriction will guarantee that the
iCalendar object can also be processed by Internet applications that
only support the standard iCalendar representation.
2.3 Using Data Types
Strong "data typing" is an integral design principle to the iCalendar
format. Strong data typing in iCalendar means that the format type
for each property value is well known. Within [iCAL], the data type
is called the "value type". The standard format defined by [RFC
2445] specifies a default value type for each calendar and component
property. In addition, many of the property definitions allow for
the specification of alternate value types. This XML representation
continues this design principle.
Explicit value/data typing in the XML representation is specified
with the "value" attribute on each element type. XML documents
conforming to this memo need only specify the "value" attribute on
element types when the value needs to override the default value/data
type defined in the iCalendar specifications. The formal public
identifier for standard value types all have the common string format
of:
2.4 Including Binary Content
Binary content can be included in an iCalendar object with the
"ATTACH" component property. In the standard iCalendar format this
content may either be specified through an external entity reference,
using a URI value type, or maybe specified within the iCalendar
object, after first BASE64 encoding the content.
The XML representation for iCalendar also supports including binary
content in an iCalendar object with the "attach" element type. It
also supports either an external reference to the non-XML binary
content or inclusion of the binary content after first encoding the
binary information using the BASE64 encoding of [MIME].
<attach>http://host.com/bin/foo.exe</attach>
Royer Expires February 27, 2006 [Page 6]
Internet-Draft xCal-Basic-RSS August 2005
<attach fmttype="APPLICATION/OCTET-STRING">MIICajCC
AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
dHNjYXBlIENvbW11bmljYXR5z...and so on...IENvcnBvc==</attach>
2.5 Including Multiple iCalendar Objects
The iCalendar format has the capability for including multiple,
individual iCalendar objects in a single data stream. The XML
representation can support this also. Individual iCalendar objects
are specified by the "vcalendar" element type. One or more
"vcalendar" element types are permitted within the parent element
type, called "iCalendar". For example:
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<version>2.0</version>
<!-- remainder of the first vcalendar object -->
</vcalendar>
<vcalendar>
<version>2.0</version>
<!-- remainder of the second vcalendar object -->
</vcalendar>>
</iCalendar>
2.6 Mapping Property Parameters to XML
The property parameters defined in the standard iCalendar format are
represented in the XML representation as an attribute on element
types. The following table specifies some of the attribute name
corresponding to each property parameter. This is true for all
iCalendar object parameters defined in any iCalendar specification.
The property and paramater names will be all lower case. Here are
some iCalendar parameter names and how they are mapped to their lower
case xCal names.
NOTE: that the iCalendar "language" parameter is converted to the
"xml:lang" attribute as an exception to the one to one mapping.
Royer Expires February 27, 2006 [Page 7]
Internet-Draft xCal-Basic-RSS August 2005
+----------------+----------------+
| Property | Attribute |
| Parameter Name | Name |
+----------------+----------------+
| ALTREP | altrep |
| CN | cn |
| CUTYPE | cutype |
| DELEGATED-FROM | delegated-from |
| DELEGATED-TO | delegated-to |
| DIR | dir |
| FMTTYPE | fmttype |
| FBTYPE | fbtype |
| LANGUAGE | xml:lang |
| MEMBER | member |
| PARTSTAT | partstat |
| RANGE | range |
| RELATED | related |
| RELTYPE | reltype |
| ROLE | role |
| RSVP | rsvp |
| SENT-BY | sent-by |
| TZID | tzid |
| VALUE | value |
| X-... | x-... |
| ..... | ..... |
+----------------+----------------+
2.7 Mapping VCALENDAR object Properties to XML
Calendar properties defined in the standard iCalendar format provide
information about an iCalendar object, as a whole. The calendar
properties are represented in the XML representation as element types
as shown in lower case. Here is a list of some iCalendar properties
and them mapped to xCal lower case names:
+------------------+------------------+
| Calendar | Tag |
| Property Name | Name |
+------------------+------------------+
| ACTION | action |
| ATTACH | attach |
| ATTENDEE | attendee |
| CALSCALE | calscale |
| CATEGORIES | categories |
| CLASS | class |
| COMMENT | comment |
| COMPLETED | completed |
Royer Expires February 27, 2006 [Page 8]
Internet-Draft xCal-Basic-RSS August 2005
| CONTACT | contact |
| CREATED | created |
| DESCRIPTION | description |
| DTEND | dtend |
| DTSTART | dtstart |
| DTSTAMP | dtstamp |
| DUE | due |
| DURATION | duration |
| EXDATE | exdate |
| EXRULE | exrule |
| FREEBUSY | freebusy |
| GEO | geo |
| LAST-MODIFIED | last-modified |
| LOCATION | location |
| METHOD | method |
| ORGANIZER | organizer |
| PERCENT-COMPLETE | percent-complete |
| PRIORITY | priority |
| PRODID | prodid |
| RECURRENCE-ID | recrrence-id |
| RDATE | rdate |
| RELATED-TO | related-to |
| REPEAT | repeat |
| RESORCES | resources |
| RRULE | rrule |
| SEQUENCE | sequence |
| STATUS | status |
| SUMMARY | summary |
| TRANSP | transp |
| TRIGGER | trigger |
| TZID | tzid |
| TZNAME | tzname |
| TZOFFSETTO | tzoffsetto |
| TZOFFSETFROM | tzoffsetfrom |
| TZURL | tzurl |
| URL | url |
| UID | uid |
| VERSION | version |
| X-... | x-... |
| ... | ... |
+------------------+------------------+
The semantics for these are as specified for the corresponding
calendar property in [iCAL].
2.8 Mapping All Components to XML
All components in xCal are mapped to their component name without the
Royer Expires February 27, 2006 [Page 9]
Internet-Draft xCal-Basic-RSS August 2005
BEGIN tag. This example show how many component names are mapped to
xCal lower case names:
+----------------+-------------+------------------------------+
| Component | Element | Example |
+----------------+-------------+------------------------------+
| VEVENT | vevent | <vevent> ... </vevent> |
| VTODO | vtodo | <vtoto> ... </vtodo> |
| VJOURNAL | vjournal | <vjournal> ... </vjournal> |
| VTIMEZONE | vtimezone | <vtimezone> ... </vtimezone> |
| STANDARD | standard | <standard> ... </standard> |
| DAYLIGHT | daylight | <daylight> ... </daylight> |
| X-... | x-... | <x-...> ... </x-...> |
| ... | ... | ... |
+----------------+-------------+-------------------------------
2.9 Mapping All Values to XML
The [iCAL] specification specifies that the equivalent component
properties to the "comment", "description", "location", "summary" and
"contact" element types can contain formatted content, such as is
specified by multiple lines of text. In such cases, the formatted
text should be specified in as CDATA Section content. The CDATA
section specifies arbitrary character data that is not meant to be
interpretted. It is not scanned for markup by the XML parser. The
CDATA Section in these element types MUST NOT contain markup or other
such alternate representation of the property value.
Values MUST NOT be mapped to lower case. iCalendar property values
and iCalendar parameter values are used without lower case
conversion.
Vaues that have characters forbidden by XML MUST be encoded using
standard XML escaping mechanisms.
Values that containe XML tags like in this example:
DESCRIPTION:How to map xml DESCRIPTION into
an XML <description> element.
Would be encoded using standard XML encoding as shown here:
Royer Expires February 27, 2006 [Page 10]
Internet-Draft xCal-Basic-RSS August 2005
<description>How to map xml DESCRIPTION into
an XML <description> element.</description>
2.10 Emailing the iCalendar XML Representation
It is expected that iCalendar XML documents will need to be sent over
SMTP/MIME email. The "text/xml" and "application/xml" content-types
have been registered for XML documents. However, use of these
content-type definitions present some problems for XML applications
such as calendaring and scheduling.
The "text/xml" and "application/xml" content-type definitions do not
provide for any header field parameters to identify the type of XML
document contained in the MIME entity. This means that a recipient
mail user agent must (MUA) open up each "text/xml" or "application/
xml" content in order to determine what object handler is needed to
process the information. To a MUA, all XML documents look like just
plain "text/xml" or "application/xml" content.
Additionally, it is accepted practice for a MUA to provide iconic
feedback to the user for individual content-types that are supported
by the MUA. For example, not only would feedback be provided for a
calendaring and scheduling content. Some further unique
identification would also be provided for each different scheduling
message; such as a meeting invitation, response to an invitation,
reschedule notice, cancellation notice, etc. In such cases,
acceptable performance by the MUA is dependent on the existence of
header field information, such as it provided in the definition of
the "text/calendar" content-type by [iCAL].
Internet application conforming to this memo MUST identify iCalendar
XML documents with the experimental content-type "application/
calendar+xml". The content-type header field SHOULD also contain a
"component" and "method" parameter to clearly identify a comma-
separated list of components and the singular method used in the
iCalendar XML document. For example, an iCalendar XML document
specifying a REQUEST for a VEVENT would be specified with the
following content-type header field:
content-type:application/calendar+xml;method=REQUEST;component=VEVENT
The content-type can also include the "optinfo" parameter to specify
any other optional iCalendar information. The semantics of these
content-type parameters is as defined in [iCAL].
Internet applications conforming to this memo MUST only send the
Royer Expires February 27, 2006 [Page 11]
Internet-Draft xCal-Basic-RSS August 2005
iCalendar XML document in a "multipart/alternative" MIME entity that
also contains an equivalent iCalendar object in the standard format
defined by [iCAL]. This restrict will guarantee that the iCalendar
object can also be processed by internet applications that only
support the standard iCalendar format.
An XML application supporting the iCalendar XML document type MUST be
able to receive and properly process the "application/calendar+xml"
document contained within a "multipart" message content-type.
2.11 iCalendar XML Representation and File Systems
The iCalendar XML documents will be stored in file systems. The
accepted practice for file extensions for XML documents is the text
"XML". However, in order to uniquely identify iCalendar XML
documents for file association with applications that can directly
process this document type, it is RECOMMENDED that the file extension
be the text "XCS".
Royer Expires February 27, 2006 [Page 12]
Internet-Draft xCal-Basic-RSS August 2005
3. Example Usage
The following sections provide various examples of iCalendar XML
documents.
3.1 A well-formed and valid iCalendar XML document
The following is a simple example of a iCalendar XML document. This
document is both a well-formed and valid XML document. The iCalendar
object specifies an appointment.
<?xml version="1.0" encoding="UTF-8"?>
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<method>PUBLISH</method>
<version>2.0</version>
<prodid>-//HandGen//NONSGML vGen v1.0//EN</prodid>
<vevent>
<uid>19981116T150000@cal10.host.com</uid>
<dtstamp>19981116T145958Z</dtstamp>
<summary>Project XYZ Review</summary>
<location>Conference Room 23A</location>
<dtstart>19981116T163000Z</dtstart>
<dtend>19981116T190000Z</dtend>
<x-foo-cust-code>1998-ABC Corp-1234</x-foo-cust-code>
<categories>Appointment,Work</categories>
</vevent>
</vcalendar>
</iCalendar>
3.2 Including binary content in attachments
The following is an example of a valid iCalendar XML document that
also includes an external reference to an attachment. The iCalendar
object specifies a meeting invitation with an attachment.
Royer Expires February 27, 2006 [Page 13]
Internet-Draft xCal-Basic-RSS August 2005
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt"
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<method>REQUEST</method>
<version>2.0</version>
<prodid>-//HandGen//NONSGML vGen v1.0//EN</prodid>
<vevent>
<uid>19981211T133000@cal1.host.com</uid>
<dtstamp>19981211T132928Z</dtstamp>
<organizer>cap://host.com/jim</organizer>
<dtstart>19981212T150000Z</dtstart>
<dtend>19981212T160000Z</dtend>
<summary>Department Meeting</summary>
<location>Conference Room 23A</location>
<attendee role="CHAIR">jim@host.com</attendee>
<attendee role="REQ-PART"
rsvp="TRUE">MAILTO:joe@host.com</attendee>
<attendee role="REQ-PART"
rsvp="TRUE">MAILTO:steve@host.com</attendee>
<attach>http://host.com/pub/photos/holiday.jpg</attach>
</vevent>
</vcalendar>
</iCalendar>
The following is an example of a well-formed and valid iCalendar XML
document that includes an attachment as inline binary content. The
iCalendar object specifies a meeting invitation with an attachment.
Royer Expires February 27, 2006 [Page 14]
Internet-Draft xCal-Basic-RSS August 2005
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/internet-drafts/draft-royer-calsch-xcal-02.txt">
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<method>REQUEST</method>
<version>2.0</version>
<prodid>-//HandGen//NONSGML vGen v1.0//EN</prodid>
<vevent>
<uid>19981211T133000@cal1.host.com</uid>
<dtstamp>19981211T132928Z</dtstamp>
<organizer>MAILTO:jim@host.com</organizer>
<dtstart>19981212T150000Z</dtstart>
<dtend>19981212T160000Z</dtend>
<summary>Department Meeting</summary>
<location>Conference Room 23A</location>
<attendee role="CHAIR">MAILTO:jim@host.com</attendee>
<attendee role="REQ-PART"
rsvp="TRUE">MAILTO:joe@host.com</attendee>
<attendee role="REQ-PART"
rsvp="TRUE">MAILTO:steve@host.com</attendee>
<attach fmttype="IMAGE/JPEG">MIICajCCAdOgAwIBAgI
CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB
lIEjYXRpb25z...and so on...IENvcnBvc==</attach>
</vevent>
</vevent>
</iCalendar>
3.3 iCalendar XML document with multiple iCalendar objects
The following is an example of a well-formed and valid iCalendar XML
document that includes more than one iCalendar object.
Royer Expires February 27, 2006 [Page 15]
Internet-Draft xCal-Basic-RSS August 2005
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE iCalendar PUBLIC "-//IETF//DTD XCAL/iCalendar XML//EN"
"http://www.ietf.org/rfc/rfcXXXX.txt">
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<method>PUBLISH</method>
<version>2.0</version>
<prodid>-//HandGen//NONSGML vGen v1.0//EN</prodid>
</vcalendar>
<vcalendar>
<version>2.0</version>
<prodid>-//HandGen//NONSGML vGen v1.0//EN</prodid>
<method>PUBLISH</method>
<vevent>
<uid>19981009T233010@cal1.host.com</uid>
<dtstamp>19981009T233000Z</dtstamp>
<dtstart>19981120T133000Z</dtstart>
<dtend>19981122T183000Z</dtend>
<summary>IT Conference</summary>
<location>Downtowner Hotel</location>
</vevent>
</vcalendar>
</iCalendar>
3.4 Using the iCalendar namespace
The following is an example of a snippet of a XML document that
includes elements from the iCalendar name-space.
<x xmlns:xCal="urn:ietf:params:xml:ns:xcal">
xmlns:pdi="http://pdi.org/schema">
<xCal:dtstart>19981123T133000Z</xCal:dtstart>
<xCal:dtend>19981123T203000Z</xCal:dtend>
<pdi:idnum>1234567</pdi:idnum>
<pdi:usage>999.99</pdi:usage>
</x>
3.5 Publish meeting information
The following is a snippet of an iCalendar XML document that
publishes information about a meeting.
Royer Expires February 27, 2006 [Page 16]
Internet-Draft xCal-Basic-RSS August 2005
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<version>2.0</version>
<prodid>-//hacksw/handcal//NONSGML 1.0//EN</prodid>
<method>PUBLISH</method>
<vevent>
<uid>19970901T130000Z-123401@host.com</uid>
<dtstamp>19970901T130000Z</dtstamp>
<dtstart>19970903T163000Z</dtstart>
<dtend>19970903T190000Z</dtend>
<summary>Annual Employee Review</summary>
<class>PRIVATE</class>
<categories>Business,Human Resources</categories>
</vevent>
</vcalendar>
</iCalendar>
3.6 Publish transparent annual event
The following is a snippet of an iCalendar XML document that
publishes information about an annually repeating event that is
transparent to busy time searches.
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<version>2.0</version>
<prodid-//hacksw/handcal//NONSGML 1.0//EN</prodid>
<method>PUBLISH</publish>
<vevent>
<uid>19990101T125957Z-123403@host.com</uid>
<dtstamp>19990101T130000Z</dtstamp>
<dtstart value="DATE">19991102</dtstart>
<summary>Our Blissful Anniversary</summary>
<class>CONFIDENTIAL</class>
<transp>TRANSPARENT</transp>
<categories>Anniversary,Personal,Special Occasion</categories>
<rrule>FREQ=YEARLY</rrule>
</vevent>
</vcalendar>
</iCalendar>
3.7 Meeting invitation
The following is a snippet of an iCalendar XML document that
specifies an invitation for a meeting. The meeting occurs on the
first Monday of each year for five years.
Royer Expires February 27, 2006 [Page 17]
Internet-Draft xCal-Basic-RSS August 2005
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<method>REQUEST</method>
<version>2.0</version>
<prodid>-//hacksw/handcal//NONSGML 1.0//EN</prodid>
<vevent>
<uid>19981220T130000Z-123403@host.com</uid>
<dtstamp>19981220T130050Z</dtstamp>
<organizer>MAILTO:corprel@host.com</organizer>
<dtstart>19990104T140000Z</dtstart>
<dtend>19990104T220000Z</dtend>
<summary>Annual Stockholders Meeting</summary>
<location>One Corporate Drive, Wilmington, DL</location>
<attendee role="CHAIR">MAILTO:mrbig@host.com</attendee>
<attendee cutype="GROUP"
rsvp="TRUE">CAP:host.com/stockholders</attendee>
<categories>Business,Meeting,Special Occasion</categories>
<rrule>FREQ=YEARLY;COUNT=5;BYDAY=1MO</rrule>
</vevent>
</vcalendar>
</iCalendar>
3.8 Publish busy time
The following is an iCalendar XML document that publishes busy time
information. The default value for the "method" attribute is
"PUBLISH" and does not need to be specified in this example.
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<version>2.0</version>
<prodid>-//hacksw/handcal//NONSGML 1.0//EN</prodid>
<vfreebusy>
<uid>19980313T133000@ical1.host.com</uid>
<dtstamp>19990104T133010Z</dtstamp>
<organizer>CAP:host.com/jsmith</organizer>
<dtstart>19980313T141711Z</dtstart>
<dtend>19980410T141711Z</dtend>
<url>jsmith.ifb</url>
<freebusy>19980314T233000Z/19980315T003000Z</freebusy>
<freebusy>19980316T153000Z/19980316T163000Z</freebusy>
<freebusy>19980318T030000Z/19980318T040000Z</freebusy>
</vfreebusy>
</vcalendar>
</iCalendar>
Royer Expires February 27, 2006 [Page 18]
Internet-Draft xCal-Basic-RSS August 2005
3.9 Request busy time
The following is a snippet of an iCalendar XML document that requests
a calendar user's busy time information.
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<method>REQUEST</method>
<version>2.0</version>
<prodid>-//hacksw/handcal//NONSGML 1.0//EN</prodid>
<vfreebusy>
<uid>19970901T083000@ical1.host.com</uid>
<dtstamp>19970901T083000Z</dtstamp>
<organizer>MAILTO:jane_doe@host1.com</organizer>
<dtstart>19971015T050000Z</dtstart>
<dtend>19971016T050000Z</dtend>
<attendee>MAILTO:john_public@host2.com</attendee>
</vfreebusy>
</vcalendar>
</iCalendar>
3.10 Issue a CAP command
The following is a snippet of an iCalendar XML document that issues a
CAP command to delete a UID.
<iCalendar xmlns:xCal="urn:ietf:params:xml:ns:xcal">
<vcalendar>
<version>2.0</version>
<prodid>-//hacksw/handcal//NONSGML 1.0//EN</prodid>
<target>relcalid-22</target>
<cmd id="random but unique per CUA">DELETE</cmd>
<vquery>
<query>SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345'</query>
</vquery>
</vcalendar>
</iCalendar>
Royer Expires February 27, 2006 [Page 19]
Internet-Draft xCal-Basic-RSS August 2005
4. Acknowledgments
The following have participated in the drafting and discussion of
this memo:
Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert,
Thomas Rowe.
Royer Expires February 27, 2006 [Page 20]
Internet-Draft xCal-Basic-RSS August 2005
5. IANA Considerations
TODO - registration if application/calendar+xml
Royer Expires February 27, 2006 [Page 21]
Internet-Draft xCal-Basic-RSS August 2005
6. Security Considerations
CDATA Sections - - A XML iCalendar document may contain CDATA
sections to represent content for specific element types. The CDATA
section specifies arbitrary character data that is not meant to be
interpretted. It is not scanned by the XML parser for markup. While
this memo restricts that any CDATA section MUST NOT contain markup or
other such alternate representation for the property value, in
general, CDATA section from a non-conformant implementation can
contain content such as HTML markup. HTML text can be used to invoke
programs. Implementors should be aware that this may leave an
implementation open to malicious attack that might occur as a result
of executing the markup in the CDATA section.
PROCEDURAL ALARMS - - A XML iCalendar document can be created that
contains a "VEVENT" calendar component with "VALARM" calendar
components. The "VALARM" calendar component can be of type PROCEDURE
and can have an attachment containing some sort of executable
program. Implementations that incorporate these types of alarms are
subject to any virus or malicious attack that might occur as a result
of executing the attachment.
ATTACHMENTS - - A XML iCalendar document can include references to
Uniform Resource Locators that can be programmed resources.
Implementers and users of this memo should be aware of the network
security implications of accepting and parsing such information.
In addition, the security considerations observed by implementations
of electronic mail systems should be followed for this memo.
Royer Expires February 27, 2006 [Page 22]
Internet-Draft xCal-Basic-RSS August 2005
7. Bibliography
[BASIC] D. Royer, "Basic Internet Calendaring and Scheduling Core
Object Specification", Internet Draft, http://www.internic.net/
internet-drafts/draft-royer-ical-basic-03.txt, June 2005.
[ISO9070] "Information Technology_SGML Support Facilities_
Registration Procedures for Public Text Owner Identifiers", ISO/IEC
9070, Second Edition, International Organization for Standardization,
April 1991.
[MIME] N. Freed, N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
2045, November 1996.
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt,
March 1997.
[iCAL] F. Dawson and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
http://www.ietf.org/rfc/rfc2445.txt, November 1998.
[XML] "Extensible Markup Language (XML)", Worldwide Web Consortium,
http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
[XML] "Extensible Markup Language (XML)", Worldwide Web Consortium,
http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
Author's Address
Doug Royer
IntelliCal LLC
267 Kentlands Blvd., #3041
Gaithersburg, MD 20878
US
Phone: (208)881-0380
Email: Doug@Royer.com
Royer Expires February 27, 2006 [Page 23]
Internet-Draft xCal-Basic-RSS August 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Royer Expires February 27, 2006 [Page 24]
| PAFTECH AB 2003-2026 | 2026-04-23 23:11:35 |