[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01

Network Working Group                               Frank Dawson, Lotus
Internet Draft                                   Surendra Reddy, Oracle
draft-many-ical-xmldoc-01.txt              Doug Royer, Sun Microsystems
Expires six months after:                                 June 10, 1999


                       The iCalendar DTD Document

Status of this Memo

   This memo is an Internet-Draft and is in full conformance with all
   provisions of Section 10 of RFC 2026.

   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.

   Distribution of this document is unlimited.

   Copyright (C) The Internet Society 1999. All Rights Reserved.

Abstract

   This memo defines a [XML] Document Type Definition (DTD) that
   corresponds to the iCalendar, Internet Calendaring and Scheduling
   Core Object Specification defined by [RFC2445]. This DTD provides
   equivalent functionality to the standard format defined by [RFC2445].
   Documents structured in accordance with this DTD may also be known as
   "XML iCalendar" documents or "ICALXML".

   The mailing list for discussion of this memo is "ietf-
   calendar@imc.org". Send an email to " ietf-calendar-request@imc.org"
   with the message "SUBSCRIBE" to add your email address to this
   mailing list. Send an email to " ietf-vcard-xml-request@imc.org" with
   the message "UNSUBSCRIBE" to remove your email address from this
   mailing list.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].








Dawson, Reddy, Royer               1              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999





Table of Contents

1 INTRODUCTION.........................................................4


2 USING XML FOR REPRESENTATION ICALENDAR...............................5

 2.1 XML DEPENDENCIES .................................................5
 2.2 DOCUMENT TYPE DEFINITION .........................................5
 2.3 WORKING WITH STANDARD AND XML ICALENDAR REPRESENTATIONS ..........5
  2.3.1 Conversion ....................................................5
  2.3.2 Mixed Use of Both Representations .............................5
 2.4 USING DATA TYPES .................................................6
 2.5 INCLUDING BINARY CONTENT .........................................7
 2.6 INCLUDING MULTIPLE ICALENDAR OBJECTS .............................8
 2.7 MAPPING PROPERTY PARAMETERS TO XML ...............................8
 2.8 MAPPING CALENDAR PROPERTIES TO XML ...............................9
 2.9 MAPPING COMPONENT PROPERTIES TO XML .............................11
 2.10 PARAMETER ENTITIES .............................................14
 2.11 NAMESPACE ......................................................14
 2.12 EMAILING THE ICALENDAR XML REPRESENTATION ......................15
 2.13 ICALENDAR XML REPRESENTATION AND FILE SYSTEMS ..................16

3 EXAMPLE USAGE.......................................................16

 3.1 A WELL-FORMED AND VALID ICALENDAR XML DOCUMENT ..................16
 3.2 ADDING NON-STANDARD, EXPERIMENTAL EXTENSIONS ....................16
 3.3 INCLUDING BINARY CONTENT IN ATTACHMENTS .........................17
 3.4 ICALENDAR XML DOCUMENT WITH MULTIPLE ICALENDAR OBJECTS ..........19
 3.5 USING THE ICALENDAR NAMESPACE ...................................19
 3.6 PUBLISH MEETING INFORMATION .....................................20
 3.7 PUBLISH TRANSPARENT ANNUAL EVENT ................................20
 3.8 MEETING INVITATION ..............................................21
 3.9 ASSIGN A TO-DO ..................................................21
 3.10 PUBLISH A JOURNAL ENTRY ........................................22
 3.11 PUBLISH BUSY TIME ..............................................22
 3.12 REQUEST BUSY TIME ..............................................23
 3.13 RESPONSE TO A BUSY TIME REQUEST ................................23
 3.14 PUBLISHED EVENT THAT REFERENCES TIME ZONE INFORMATION ..........24
 3.15 AN EVENT WITH AN ALARM .........................................24

4 ICALENDAR XML DOCUMENT TYPE DEFINITION..............................26


5 ACKNOWLEDGMENTS.....................................................38


6 IANA CONSIDERATIONS.................................................38


7 SECURITY CONSIDERATIONS.............................................38


Dawson, Reddy, Royer               2              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


8 BIBLIOGRAPHY........................................................38


9 AUTHOR'S ADDRESS....................................................39


10 FULL COPYRIGHT STATEMENT...........................................40

















































Dawson, Reddy, Royer               3              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999





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 [RFC2445].

   This memo defines how XML can be used to represent iCalendar objects.
   This memo includes the definition of the XML DTD for a XML document
   representation of an iCalendar object.

   NOTE: The [RFC2445] is the definitive reference for the definition of
   iCalendar semantics. This memo only provides an alternative, XML
   representation for the standard syntax defined in [RFC2445]. This
   memo does not introduce any semantics not already defined by
   [RFC2445].

   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 encoding using the BASE64
   scheme of [RFC2045]. Parameter entities are used to logically group
   content particles in the XML DTD in order to facilitate reading and
   comprehension of the structure specified by the iCalendar XML DTD.

   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, this memo
   includes the definition of the URI to be used to identify the
   namespace associated with the iCalendar DTD element types in other
   XML documents. XML applications that conform to this memo and also
   use namespaces MUST NOT include other non-iCalendar namespaces in an
   iCalendar XML document.

   It is expected that the DTD defined in this memo will not normally be
   included with iCalendar XML documents that are distributed. Instead,
   the DTD will be referenced in the document type declaration in the
   document entity. Such iCalendar XML documents will be well-formed and
   valid, as defined in [XML]. In addition, other iCalendar XML
   documents will be specified that do not include the XML prolog. Such
   iCalendar XML documents will be well-formed but not valid.




Dawson, Reddy, Royer               4              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


2  Using XML For Representation 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 W3C on February 10, 1998.

2.1 XML Dependencies

   This memo specifies the XML representation for the standard iCalendar
   format defined by [RFC2445]. There are no XML dependencies other than
   the [XML] and the [XMLNS] recommendations.

2.2 Document Type Definition

   A XML DTD for iCalendar is defined by the DTD specified in section 3.

   The formal public identifier (FPI) for the DTD is:

   "-//IETF//DTD ICALXML/iCalendar XML//EN"

        NOTE: The "ICALXML" text in the FPI value will be replaced with
        the text "RFC xxxx", where "xxxx" is the RFC number, when the
        memo is published as a RFC.

   This FPI MUST be used on the DOCTYPE statement within a XML document
   referencing the DTD defined by this memo.

   This FPI SHOULD also be used to identify iCalendar XML documents
   within operating system registries of file, clipboard and interactive
   rendering (e.g., memory clipboard or drag/drop) formats.

2.3 Working With Standard and XML iCalendar Representations

   This memo defines an alternative, XML representation for the standard
   iCalendar format defined in [RFC2445]. This alternative
   representation provides the same semantics as that defined in the
   standard format.

2.3.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.3.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.

   With the use of the MIME multipart content-types, compound MIME
   entities containing a mix of the standard and XML representations can


Dawson, Reddy, Royer               5              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   be specified. This capability is useful in applications where both
   representations might be encountered. In addition, this capability
   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.4 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 [RFC2445], the data
   type is called the "value type". The standard format defined by
   [RFC2445] 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. In addition, the XML
   DTD specifies a default value/data type for 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. The standard value types defined in
   [RFC2445] are specified in the XML DTD by individual NOTATION
   declarations. The formal public identifier for standard value types
   all have the common string format of:

        -//IETF//NOTATION ICALXML/Value Type/xxx//EN

        NOTE: The "ICALXML" text in the FPI value will be replaced with
        the text "RFC xxxx", where "xxxx" is the RFC number, when the
        memo is published as a RFC.

   Where "xxx" is replaced with the text specified in the table below.

   The following table specifies the XML value/data type that
   corresponds to each of the standard value types defined in [RFC2445].

      +--------------+------------+-------------------------+
      |  RFC 2445    | XML Value  | Notation FPI Text       |
      | Value Type   |   Type     |                         |
      +--------------+------------+-------------------------+
      | BINARY       | BINARY     | Binary                  |
      | BOOLEAN      | BOOLEAN    | Boolean                 |
      | CALADR       | CALADR     | Calendar User Address   |
      | DATE         | DATE       | Date                    |


Dawson, Reddy, Royer               6              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


      | DATE-TIME    | DATE-TIME  | Date-Time               |
      | DURATION     | DURATION   | Duration                |
      | FLOAT        | FLOAT      | Float                   |
      | INTEGER      | INTEGER    | Integer                 |
      | PERIOD       | PERIOD     | Period of Time          |
      | RECUR        | RECUR      | Recurrence Rule         |
      | TEXT         | TEXT       | Text                    |
      | TIME         | TIME       | Time                    |
      | URI          | URI        | URI                     |
      | UTC-OFFSET   | UTC-OFFSET | UTC-Offset              |
      | Non-standard | X-NAME     | X-Name                  |
      +--------------+------------+-------------------------+

   Other standard XML data types can be specified by including a
   NOTATION declaration that specifies the formal public identifier
   associated with the other standard format. In addition, the name of
   the format specified in the NOTATION declaration is specified in the
   "value" attribute of any element type that caste to the other
   standard format.

2.5 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 [RFC2045].

   Any iCalendar properties defined in [RFC2445] that can be used to
   include binary content are defined in the XML representation as an
   element type with a content model that consists of either the
   "extref" or the "b64bin" element type. The "extref" element type is
   used to reference an external entity containing the binary content.
   An external reference to the binary content is specified by the "uri"
   attribute on the "extref" element type. For every external reference,
   an ENTITY declaration and a corresponding NOTATION declaration MUST
   also be specified in an internal DTD to identify the location and
   format of the external entity. For example, the following XML
   snippets would be needed to include a reference to the executable
   "foo.exe" in the "attach" element type; which corresponds to the
   "ATTACH" iCalendar component property:

   <!-- Following specified within the internal DTD. -->

   <!NOTATION EXE SYSTEM "Executable Module Format">
   <!ENTITY attach-1 SYSTEM "http://host.com/bin/foo.exe" NDATA EXE>

   <!-- Following specified within the body of the XML document. -->


Dawson, Reddy, Royer               7              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999



   <attach><extref uri="attach-1" /></attach>

   The "b64bin" element type is used to include the binary content
   within the XML document after first character encoding the binary
   information using the BASE64 encoding method of [RFC2045]. For
   example, the following XML snippets would be needed to include the
   executable "foo.exe" in the "attach" element type; after first BASE64
   encoding the binary information:

   <!-- Following specified within the body of the XML document. -->

   <attach><b64bin fmttype="APPLICATION/OCTET-STRING"> MIICajCC
   AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
   dHNjYXBlIENvbW11bmljYXR5z...and so on...IENvcnBvc==</b64bin>
   </attach>

2.6 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 "iCal" element type. One or more "iCal" element
   types are permitted within the parent element type, called
   "iCalendar". For example:

   <iCalendar><iCal version="2.0">
   <!-- remainder of the first iCalendar object -->
   </iCal>

   <iCal version="2.0">
   <!-- remainder of the second iCalendar object -->
   </iCal></iCalendar>

2.7 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 the attribute name corresponding
   to each property parameter.

      +----------------+-----------+-----------+-----------------+
      |    Property    | Attribute | Attribute | Default         |
      | Parameter Name |   Name    |   Type    |  Value          |
      +----------------+-----------+-----------+-----------------+
      | ALTREP         | altrep    | ENTITY    | IMPLIED         |
      | CN             | cn        | CDATA     | Null String     |
      | CUTYPE         | cutype    | NMTOKEN   | INDIVIDUAL      |
      | DELEGATED-FROM | delfrom   | CDATA     | IMPLIED         |
      | DELEGATED-TO   | delto     | CDATA     | IMPLIED         |
      | DIR            | dir       | ENTITY    | IMPLIED         |
      | ENCODING       | Not Used  | n/a       | n/a             |
      | FMTTYPE        | fmttype   | CDATA     | REQUIRED        |
      | FBTYPE         | fbtype    | NMTOKEN   | BUSY            |


Dawson, Reddy, Royer               8              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


      | LANGUAGE       | lang      | CDATA     | IMPLIED         |
      | MEMBER         | member    | CDATA     | IMPLIED         |
      | PARTSTAT       | partstat  | NMTOKEN   | NEEDS-ACTION    |
      | RANGE          | range     | NMTOKEN   | THISONLY        |
      | RELATED        | trigtype  | NMTOKEN   | START           |
      | RELTYPE        | reltype   | NMTOKEN   | PARENT          |
      | ROLE           | role      | NMTOKEN   | REQ-PARTICIPANT |
      | RSVP           | rsvp      | NMTOKEN   | FALSE           |
      | SENT-BY        | sentby    | CDATA     | IMPLIED         |
      | TZID           | tzid      | CDATA     | IMPLIED         |
      | VALUE          | value     | NOTATION  | See elements    |
      +----------------+-----------+-----------+-----------------+

   The inline "ENCODING" property parameter is not needed in the XML
   representation. Inline binary information is always included as
   parsable character data, after first being encoded using the BASE64
   encoding of [RFC2045].

   The "RANGE" property parameter defined by [RFC2445] does not include
   the "THISONLY" enumeration. This is the implicit default, if the
   parameter is not specified on the "RECURRENCE-ID" property. However,
   the value is needed in the XML representation, because all attributes
   need to explicitly specify a default value in the attribute's
   declaration in the DTD. This enumeration has been added to the XML
   representation.

   A non-standard, experimental parameter can be added to the XML
   representation by declaring it in an ATTLIST declaration and
   assigning it a XML attribute type and corresponding default value.

2.8 Mapping Calendar 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 an attribute
   on the "iCalendar" and the "iCal" element type. The following table
   specifies the attribute name permitted on the "iCalendar" element
   type.

      +---------------+-----------+-----------+-----------------+
      |    Calendar   | Attribute | Attribute | Default         |
      | Property Name |   Name    |   Type    |  Value          |
      +---------------+-----------+-----------+-----------------+
      | CALSCALE      | calscale  | CDATA     | IMPLIED         |
      | METHOD        | method    | NMTOKEN   | PUBLISH         |
      | VERSION       | version   | CDATA     | REQUIRED        |
      | PRODID        | prodid    | CDATA     | IMPLIED         |
      +---------------+-----------+-----------+-----------------+

   In addition to these attributes, the "iCal" element type can also
   have the following attributes:

      +-----------+-----------+---------+----------------------------+
      | Attribute | Attribute | Default | Description                |


Dawson, Reddy, Royer               9              Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


      |   Name    |   Type    |  Value  |                            |
      +-----------+-----------+---------+----------------------------+
      | xmlns     | CDATA     | FIXED   | Used to specify the default|
      |           |           |         | iCalendar XML name space.  |
      | xmlns: +  | CDATA     | FIXED   | Used to specify the        |
      | <namespace|           |         | A string with "xmlns:"     |
      | prefix>   |           |         | prefix is used to specify  |
      |           |           |         | a namespace.               |
      +-----------+-----------+---------+----------------------------+

   The semantics of the"xmlns" attribute, and any attribute with
   "xmlns:" as a prefix, is as specified in [XMLNS]. It is used to
   declare a namespace in XML. It can be used to declare the iCalendar
   XML namespace in a XML document with a document type other than the
   iCalendar XML document type. The iCalendar XML document type MUST
   only use element types from the iCalendar namespace. Non-standard,
   experimental element types and attributes lists MUST only be
   specified by declarations in an internal DTD within the iCalendar XML
   document. To specify the iCalendar namespace, the attribute value for
   the "xmlns" and any attribute with the prefix "xmlns:" MUST be:

   'http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-01.txt'

        NOTE: This attribute value will be replaced with the URL
        "http://www.ietf.org/rfc/rfcxxxx.txt", where "xxxx" is the RFC
        number, when this memo is published as a RFC.

   For example:

   <iCalendar   xmlns:iCalv3='http://www.ietf.org/internet-
   drafts/draft-many-ical-xmldoc-01.txt'>
   <!-- the "iCalendar" prefix is bound to
   'http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-01.txt'
   for the "iCalendar" element and contents-->
   </iCalendar>

   The following table specifies the attribute name corresponding to
   each calendar property. These attributes are only permitted on the
   "iCal" element type.

      +---------------+-----------+-----------+-----------------+
      |    Calendar   | Attribute | Attribute | Default         |
      | Property Name |   Name    |   Type    |  Value          |
      +---------------+-----------+-----------+-----------------+
      | CALSCALE      | calscale  | CDATA     | IMPLIED         |
      | METHOD        | method    | NMTOKEN   | PUBLISH         |
      | VERSION       | version   | CDATA     | REQUIRED        |
      | PRODID        | prodid    | CDATA     | IMPLIED         |
      +---------------+-----------+-----------+-----------------+

   The semantics for these attributes is as specified for the
   corresponding calendar property in [RFC2445].




Dawson, Reddy, Royer               10             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   The following table specifies additional attributes that are
   permitted on the "iCal" element type.

      +-----------+-----------+---------+----------------------------+
      | Attribute | Attribute | Default | Description                |
      |   Name    |   Type    |  Value  |                            |
      +-----------+-----------+---------+----------------------------+
      | lang      | CDATA     | IMPLIED | Used to specify the default|
      +-----------+-----------+---------+----------------------------+

   The "lang" attribute permits the default language to be specified for
   the whole iCalendar object. If the "lang" attribute is specified on
   the XML document, then if the XML representation is converted into
   the standard format the "LANGUAGE" property parameter MUST be
   specified on each TEXT valued property to prevent information loss;
   when translating into the standard format.

2.9 Mapping Component Properties to XML

   Component properties in the standard iCalendar format provide
   calendar information about the calendar component. The component
   properties defined in the standard iCalendar format are represented
   in the XML representation as element types. The following tables
   specify the element types corresponding to each of the properties in
   the specified property category.

      Descriptive Component Properties
      +----------------+------------+-----------------------------+
      |   Component    |  Element   |  Element Content Model      |
      | Property Name  |   Name     |                             |
      +----------------+------------+-----------------------------+
      | ATTACH         | attach     | extref or b64bin            |
      |                | extref     | EMPTY                       |
      |                | b64bin     | PCDATA                      |
      | CATEGORIES     | categories | Any number of item elements |
      |                | item       | PCDATA                      |
      | CLASS          | class      | PCDATA                      |
      | COMMENT        | comment    | PCDATA                      |
      | DESCRIPTION    | desc       | PCDATA                      |
      | GEO            | geo        | lat followed by lon element |
      |                | lat        | PCDATA                      |
      |                | lon        | PCDATA                      |
      | LOCATION       | location   | PCDATA                      |
      | PERCENT        | percent    | PCDATA                      |
      | PRIORITY       | priority   | PCDATA                      |
      | RESOURCES      | resources  | Any number of item elements |
      | STATUS         | status     | PCDATA                      |
      | SUMMARY        | summary    | PCDATA                      |
      +----------------+------------+-----------------------------+


      Date and Time Component Properties
      +----------------+------------+-----------------------------+
      |   Component    |  Element   |  Element Content Model      |


Dawson, Reddy, Royer               11             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


      | Property Name  |   Name     |                             |
      +----------------+------------+-----------------------------+
      | COMPLETED      | completed  | PCDATA                      |
      | DTEND          | end        | PCDATA                      |
      | DUE            | due        | PCDATA                      |
      | DTSTART        | start      | PCDATA                      |
      | DURATION       | duration   | PCDATA                      |
      | FREEBUSY       | fbdata     | PCDATA                      |
      | TRANSP         | transp     | PCDATA                      |
      +----------------+------------+-----------------------------+


      Time Zone Component Properties
      +----------------+-------------+-----------------------------+
      |   Component    |  Element    |  Element Content Model      |
      | Property Name  |   Name      |                             |
      +----------------+-------------+-----------------------------+
      | TZID           | tzid        | PCDATA                      |
      | TZNAME         | tzname      | PCDATA                      |
      | TZOFFSETFROM   | tzoffsetfrom| PCDATA                      |
      | TZOFFSETTO     | tzoffsetto  | PCDATA                      |
      | TZURL          | tzurl       | EMPTY                       |
      +----------------+-------------+-----------------------------+


      Relationship Component Properties
      +----------------+------------+-----------------------------+
      |   Component    |  Element   |  Element Content Model      |
      | Property Name  |   Name     |                             |
      +----------------+------------+-----------------------------+
      | ATTENDEE       | attendee   | PCDATA                      |
      | CONTACT        | contact    | PCDATA                      |
      | ORGANIZER      | organizer  | PCDATA                      |
      | RECURRENCE-ID  | recurid    | PCDATA                      |
      | RELATED-TO     | related    | PCDATA                      |
      | URL            | url        | EMPTY                       |
      | UID            | uid        | PCDATA                      |
      +----------------+------------+-----------------------------+


      Recurrence Component Properties
      +----------------+------------+-----------------------------+
      |   Component    |  Element   |  Element Content Model      |
      | Property Name  |   Name     |                             |
      +----------------+------------+-----------------------------+
      | EXDATE         | exdate     | PCDATA                      |
      | EXRULE         | exrule     | PCDATA                      |
      | RDATE          | rdate      | PCDATA                      |
      | RRULE          | rrule      | PCDATA                      |
      +----------------+------------+-----------------------------+


      Alarm Component Properties
      +----------------+------------+-----------------------------+


Dawson, Reddy, Royer               12             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


      |   Component    |  Element   |  Element Content Model      |
      | Property Name  |   Name     |                             |
      +----------------+------------+-----------------------------+
      | ACTION         | action     | PCDATA                      |
      | REPEAT         | repeat     | PCDATA                      |
      | TRIGGER        | trigger    | PCDATA                      |
      +----------------+------------+-----------------------------+


      Change Management Component Properties
      +----------------+------------+-----------------------------+
      |   Component    |  Element   |  Element Content Model      |
      | Property Name  |   Name     |                             |
      +----------------+------------+-----------------------------+
      | CREATED        | created    | PCDATA                      |
      | DTSTAMP        | dtstamp    | PCDATA                      |
      | LAST-MODIFIED  | last-mod   | PCDATA                      |
      | SEQUENCE       | seq        | PCDATA                      |
      +----------------+------------+-----------------------------+


      Miscellaneous Component Properties
      +----------------+------------+-----------------------------+
      |   Component    |  Element   |  Element Content Model      |
      | Property Name  |   Name     |                             |
      +----------------+------------+-----------------------------+
      | REQUEST-STATUS | rstatus    | PCDATA                      |
      +----------------+------------+-----------------------------+

   The following table specifies the element types that represent each
   of the calendar components.

   Component Structuring Properties
      +----------------+------------+-------------------------------+
      |   Component    |  Element   |  Element Content Model        |
      | Property Name  |   Name     |                               |
      +----------------+------------+-------------------------------+
      | Multiple iCal- | iCalendar  | One or more iCal elements     |
      | endar objects  |            |                               |
      | VCALENDAR      | iCal       | calcomp parameter entity      |
      | VEVENT         | event      | event.opt1 and event.optm     |
      |                |            | parameter entity and alarm    |
      |                |            | element                       |
      | VTODO          | todo       | todo.opt1 and todo.optm       |
      |                |            | parameter entity and alarm    |
      |                |            | element                       |
      | VJOURNAL       | journal    | journal.opt1 and              |
      |                |            | journal.optm parameter        |
      |                |            | entity                        |
      | VFREEBUSY      | freebusy   | freebusy.opt1 and             |
      |                |            | freebusy.optm parameter       |
      |                |            | entity                        |
      | VTIMEZONE      | timezone   | timezone.man, timezone.opt1,  |
      |                |            | timezone.mann parameter       |


Dawson, Reddy, Royer               13             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


      |                |            | entity                        |
      | STANDARD       | standard   | standard.man or standard.optm |
      |                |            | entity                        |
      | DAYLIGHT       | daylight   | daylight.man or daylight.optm |
      |                |            | entity                        |
      | VALARM         | alarm      | alarm.audio, alarm.display,   |
      |                |            | alarm.email and               |
      |                |            | alarm.procedure entity        |
      +----------------+------------+-------------------------------+

   The [RFC2445] specification specifies that the equivalent component
   properties to the "comment", "desc", "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. The "altrep"
   attribute is used to reference any such alternate representation for
   the textual content of these element types.

2.10    Parameter Entities

   The external, iCalendar XML DTD specified in section 3 makes use of
   parameter entity declarations. This XML feature is used to group
   declarations within the DTD. This technique has been used in DTD
   design in order to facilitate the reading and comprehension of the
   structure specified by the DTD.

2.11    Namespace

   [XMLNS] defines "Namespaces in XML" to be a collection of names,
   identified by a URI, which are used in XML documents as element types
   and attribute names. The [XML] specification does not include a
   definition for namesspaces, but does set down some guidelines for
   experimental naming of name-spaces.

   XML namespaces allow multiple markup vocabulary in a single document.
   Considering the utility of the iCalendar properties in other
   applications, it is important for the iCalendar XML DTD to define a
   namespace for the iCalendar element types.

   This memo defines the value that MUST be used in non-iCalendar XML
   documents that reference element types or attribute lists from the
   iCalendar namespace.

   The following is an example of a well-formed but invalid "xdoc"
   document type that includes elements and attribute lists from the
   iCalendar namespace:

   <?xml version="1.0" encoding="UTF-8"?>
   <xdoc>
   <iCal:iCal version="3.0" xmlns:icalxml="http://www.ietf.org/internet


Dawson, Reddy, Royer               14             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   -drafts/draft-many-ical-xmldoc-01.txt">

   <!-- Remainder of the XML document, each element from the -->
   <!-- iCalendar namespace with the "icalxml:" prefix. -->

   </iCal:iCal>
   </xdoc>

2.12    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 [RFC2445].

   Internet application conforming to this memo MUST identify iCalendar
   XML documents with the experimental content-type "text/x-icalxml".
   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 and VTODO would be specified with the following content-
   type header field:

   content-type:text/x-icalxml;method=REQUEST
        ;component=VEVENT,VTODO

   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 [RFC2445].

   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


Dawson, Reddy, Royer               15             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   defined by [RFC2445]. 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 "text/x-icalxml" document
   contained within a "multipart" message content-type.

2.13    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".

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"?>
   <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD ICALXML/iCalendar XML//EN"
   "http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-01.txt">

   <iCalendar>
   <iCal method="PUBLISH"
         version="2.0"
         prodid="-//HandGen//NONSGML vGen v1.0//EN">
   <event>
        <uid>19981116T150000@cal10.host.com</uid>
        <dtstamp>19981116T145958Z</dtstamp>
        <summary>Project XYZ Review</summary>
        <location>Conference Room 23A</location>
        <start>19981116T163000Z</start>
        <end>19981116T190000Z</end>
        <categories><item>Appointment</item></categories>
   </event>
   </iCal>
   </iCalendar>

3.2 Adding non-standard, experimental extensions

   The following is an example of a valid iCalendar XML document that
   also includes a non-standard, experimental extension, as provided for
   by [RFC2445]. The iCalendar object specifies the publication of a to-



Dawson, Reddy, Royer               16             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   do with a non-standard experimental property for a customer charge
   code.

   The non-standard experimental property is identified by the "X-"
   prefix to the element name. All non-standard properties MUST be
   specified with element types with an "X-" type element name. In
   addition, a text identifier for the vendor specifying the extension
   SHOULD be appended to the "X-" text prefix. In this case, the example
   specifies a "foo" for the name of the vendor specifying the non-
   standard property.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD ICALXML/iCalendar XML//EN"
   "http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-01.txt"
   [
   <!ELEMENT todo ((class | completed | created | desc | dtstamp | start
   | geo | last-mod | location | organizer | percent | priority |
   recurid | seq | status | summary | uid | url | (due | duration))*,
   (attach | attendee | categories | comment | contact | exdate | exrule
   | rstatus | related | resources | rdate | rrule | x-foo-cust-code)*,
   (alarm)*)>

   <!ELEMENT x-foo-cust-code (#PCDATA)>
   <!ATTLIST x-foo-cust-code value NOTATION (X-NAME) #IMPLIED>
   ]>

   <iCalendar>
   <iCal method="PUBLISH"
         version="2.0"
         prodid="-//HandGen//NONSGML vGen v1.0//EN">
   <todo>
        <uid>19981104T130000@cal1.host.com </uid>
        <dtstamp>19981104T125957Z</dtstamp>
        <start>19981105T133000Z</start>
        <due>19981106T133000Z</due>
        <summary>Draft a test plan</summary>
        <x-foo-cust-code>1998-ABC Corp-1234</x-foo-cust-code>
        <priority>1</priority>
   </todo>
   </iCal>
   </iCalendar>

3.3 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.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD ICALXML/iCalendar XML//EN"
   "http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-01.txt"
   [
   <!ENTITY attach1 SYSTEM "http://host.com/pub/photos/holiday.jpg"
   NDATA JPEG>


Dawson, Reddy, Royer               17             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <!NOTATION JPEG PUBLIC "ISO/IEC 10918:1993//NOTATION Digital
   Compression and Coding of Continuous-tone Still Images (JPEG)//EN" >
   ]>

   <iCalendar>
   <iCal method="REQUEST"
         version="2.0"
         prodid="-//HandGen//NONSGML vGen v1.0//EN">
   <event>
        <uid>19981211T133000@cal1.host.com</uid>
        <dtstamp>19981211T132928Z</dtstamp>
        <organizer>jim@host.com</organizer>
        <start>19981212T150000Z</start>
        <end>19981212T160000Z</end>
        <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><extref uri="attach1" /></attach>
   </event>
   </iCal>
   </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.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD ICALXML/iCalendar XML//EN"
   "http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-01.txt">

   <iCalendar>
   <iCal method="REQUEST"
         version="2.0"
         prodid="-//HandGen//NONSGML vGen v1.0//EN">
   <event>
        <uid>19981211T133000@cal1.host.com</uid>
        <dtstamp>19981211T132928Z</dtstamp>
        <organizer>MAILTO:jim@host.com</organizer>
        <start>19981212T150000Z</start>
        <end>19981212T160000Z</end>
        <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><b64bin fmttype="IMAGE/JPEG">MIICajCCAdOgAwIBAgI
        CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB
        lIEjYXRpb25z...and so on...IENvcnBvc==</b64bin></attach>


Dawson, Reddy, Royer               18             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   </event>
   </iCal>
   </iCalendar>

3.4 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.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD ICALXML/iCalendar XML//EN"
   "http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-00.txt">

   <iCalendar>
   <iCal method="PUBLISH"
         version="2.0"
         prodid="-//HandGen//NONSGML vGen v1.0//EN">
   <todo>
        <uid>19981009T233000@cal1.host.com</uid>
        <dtstamp>19981009T232928Z</dtstamp>
        <start>19981010T000000Z</start>
        <due>19981010T235959Z</due>
        <summary>Register for conference</summary>
        <priority>2</priority>
   </todo>
   </iCal>
   <iCal version="2.0"
         prodid="-//HandGen//NONSGML vGen v1.0//EN"
         method="PUBLISH">
   <event>
        <uid>19981009T233010@cal1.host.com</uid>
        <dtstamp>19981009T233000Z</dtstamp>
        <start>19981120T133000Z</start>
        <end>19981122T183000Z</end>
        <summary>IT Conference</summary>
        <location>Downtowner Hotel</location>
   </event>
   </iCal>
   </iCalendar>

3.5 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:icalxml="http://www.ietf.org/internet-drafts/
   draft-many-ical-xmldoc-01.txt"
        xmlns:pdi="http://pdi.org/schema">
   <icalxml:start>19981123T133000Z</icalxml:start>
   <icalxml:end>19981123T203000Z</icalxml:end>
   <pdi:idnum>1234567</pdi:idnum>
   <pdi:usage>999.99</pdi:usage>
   </x>



Dawson, Reddy, Royer               19             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


3.6 Publish meeting information

   The following is a snippet of an iCalendar XML document that
   publishes information about a meeting. The "method" attribute isn't
   specified since it is the default value.

   <iCalendar>
   <iCal version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <event>
   <uid>19970901T130000Z-123401@host.com</uid>
   <dtstamp>19970901T130000Z</dtstamp>
   <start>19970903T163000Z</start>
   <end>19970903T190000Z</end>
   <summary>Annual Employee Review</summary>
   <class>PRIVATE</class>
   <categories>
        <item>Business</item>
        <item>Human Resources</item>
   </categories>
   </event>
   </iCal>
   </iCalendar>

3.7 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>
   <iCal version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <event>
   <uid>19990101T125957Z-123403@host.com</uid>
   <dtstamp>19990101T130000Z</dtstamp>
   <start value="DATE">19991102</start>
   <end value="DATE">19991102</end>
   <summary>Our Blissful Anniversary</summary>
   <class>CONFIDENTIAL</class>
   <transp>TRANSPARENT</transp>
   <categories>
        <item>Anniversary</item>
        <item>Personal</item>
        <item>Special Occasion</item>
   </categories>
   <rrule>FREQ=YEARLY</rrule>
   </event>
   </iCal>
   </iCalendar>






Dawson, Reddy, Royer               20             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


3.8 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.

   <iCalendar>
   <iCal method="REQUEST"
         version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <event>
   <uid>19981220T130000Z-123403@host.com</uid>
   <dtstamp>19981220T130050Z</dtstamp>
   <organizer>MAILTO:corprel@host.com</organizer>
   <start>19990104T140000Z</start>
   <end>19990104T220000Z</end>
   <summary>Annual Stockholders Meeting</summary>
   <location><![CDATA[Room AUD1
   One Corporate Drive
   Wilmington, DL]]></location>
   <attendee role="CHAIR">MAILTO:mrbig@host.com</attendee>
   <attendee cutype="GROUP"
             rsvp="TRUE">MAILTO:stockholders@host.com</attendee>
   <categories>
        <item>Business</item>
        <item>Meeting</item>
        <item>Special Occasion</item>
   </categories>
   <rrule>FREQ=YEARLY;COUNT=5;BYDAY=1MO</rrule>
   </event>
   </iCal>
   </iCalendar>

3.9 Assign a to-do

   The following is a snippet of an iCalendar XML document that assigns
   a to-do.

   <iCalendar>
   <iCal method="REQUEST"
         version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <todo>
   <uid>19990104T133402@ical1.host.com</uid>
   <dtstamp>19990104T133410Z</dtstamp>
   <start value="DATE">19990104</start>
   <due value="DATE">19990129</due>
   <organizer>MAILTO:dboss@host.com</organizer>
   <summary>Periodic Self Review</summary>
   <desc><![CDATA[Complete your self review.
   Contact me if you questions.]]></desc>
   <priority>1</priority>
   <class>CONFIDENTIAL</class>
   <attendee>MAILTO:dilbert@host.com</attendee>


Dawson, Reddy, Royer               21             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   </todo>
   </iCal>
   </iCalendar>

3.10    Publish a journal entry

   The following is a snippet of an iCalendar XML document that
   publishes a journal entry.

   <iCalendar>
   <iCal method="PUBLISH"
         version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <journal>
   <uid>19990104T170003@ical1.host.com</uid>
   <dtstamp>19990104T170001Z</dtstamp>
   <start value="DATE">19990104</start>
   <organizer>MAILTO:corprel@host.com</organizer>
   <class>PUBLIC</class>
   <desc><![CDATA[Year end report for Worldwide Calendar Company.
   The complete report can be found at the Corporate website.
   http://www.host.com/annualreport]]></desc>
   <categories>
        <item>Annual Report</item>
        <item>Business</item>
   </categories>
   </journal>
   </iCal>
   </iCalendar>

3.11    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.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE iCalendar SYSTEM "icalendar.dtd" [

   <!ENTITY jsmith.ifb SYSTEM
   "http://www.host.com/calendar/busytime/jsmith.ifb" NDATA BINARY>
   ]>

   <iCalendar>
   <iCal version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <freebusy>
   <uid>19980313T133000@ical1.host.com</uid>
   <dtstamp>19990104T133010Z</dtstamp>
   <organizer>MAILTO:jsmith@host.com</organizer>
   <start>19980313T141711Z</start>
   <end>19980410T141711Z</end>
   <url uri="jsmith.ifb" />
   <fbdata>19980314T233000Z/19980315T003000Z</fbdata>


Dawson, Reddy, Royer               22             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <fbdata>19980316T153000Z/19980316T163000Z</fbdata>
   <fbdata>19980318T030000Z/19980318T040000Z</fbdata>
   </freebusy>
   </iCal>
   </iCalendar>

3.12    Request busy time

   The following is a snippet of an iCalendar XML document that requests
   a calendar user's busy time information.

   <iCalendar>
   <iCal method="REQUEST"
         version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <freebusy>
   <uid>19970901T083000@ical1.host.com</uid>
   <dtstamp>19970901T083000Z</dtstamp>
   <organizer>MAILTO:jane_doe@host1.com</organizer>
   <start>19971015T050000Z</start>
   <end>19971016T050000Z</end>
   <attendee>MAILTO:john_public@host2.com</attendee>
   </freebusy>
   </iCal>
   </iCalendar>

3.13    Response to a busy time request

   The following is an iCalendar XML document that responds to request
   for busy time information.

   <?xml version="1.0" encoding="UTF-8"?>
   <!DOCTYPE iCalendar SYSTEM "icalendar.dtd" [

   <!ENTITY jpublic-01.ifb SYSTEM "http://host2.com/pub/busy/ jpublic-
   01.ifb" NDATA BINARY>
   ]>

   <iCalendar>
   <iCal method="REPLY"
         version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <freebusy>
   <uid>19970901T083000@ical1.host.com</uid>
   <dtstamp>19970901T100000Z</dtstamp>
   <organizer>MAILTO:jane_doe@host1.com</organizer>
   <url uri="jpublic-01.ifb" />
   <attendee>MAILTO:john_public@host2.com</attendee>
   <fbdata value="PERIOD">19971015T050000Z/PT8H30M,
   19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M</fbdata>
   </freebusy>
   </iCal>
   </iCalendar>



Dawson, Reddy, Royer               23             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


3.14    Published event that references time zone information

   The following is a snippet of an iCalendar XML document that
   publishes calendar information about an event that includes date/time
   values that reference a time zone definition.

   <iCalendar>
   <iCal version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <timezone>
   <tzid>US-Eastern</tzid>
   <standard>
        <start>19981025T020000</start>
        <tzoffsetfrom>-0400</tzoffsetfrom>
        <tzoffsetto>0500</tzoffsetto>
        <rdate>19981025T020000</rdate>
        <tzname>EST</tzname>
   </standard>
   <daylight>
        <start>19990404T020000</start>
        <tzoffsetfrom>-0500</tzoffsetfrom>
        <tzoffsetto>-0400</tzoffsetto>
        <rdate>19990404T020000</rdate>
        <tzname>EDT</tzname>
   </daylight>
   </timezone>
   <event>
        <dtstamp>19980309T231000Z</dtstamp>
        <uid>guid-1.host1.com</uid>
        <start tzid="US-Eastern">19980312T083000</start>
        <end tzid="US-Eastern">19980312T093000</end>
        <organizer>MAILTO:mrbig@host.com</organizer>

        <desc>Project XYZ Review Meeting</desc>
        <class>PUBLIC</class>
        <summary>XYZ Project Review</summary>
        <location>1CP Conference Room 4350</location>
        <categories><item>Meeting</item></categories>
        <attendee rsvp="TRUE"
             role="REQ-PART"
             cutype="GROUP">MAILTO:employee-@host.com
        </attendee>
   </event>
   </iCal>
   </iCalendar>

3.15    An event with an alarm

   The following is an iCalendar XML with associated alarms. The event
   specifies alarm definitions for a "display", "audio", "email" and
   "procedure" type of alarms. The "method" attribute isn't specified
   since it is the default value.

   <?xml version="1.0" encoding="UTF-8"?>


Dawson, Reddy, Royer               24             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <!DOCTYPE iCalendar PUBLIC "-//IETF//DTD ICALXML/iCalendar XML//EN"
   "http://www.ietf.org/internet-drafts/draft-many-ical-xmldoc-01.txt"
   [
   <!ENTITY boom SYSTEM "ftp://host.com/sounds/cannon.wav" NDATA wave>
   <!NOTATION wave SYSTEM "WAVE Audio Format">
   <!ENTITY doit SYSTEM "http://procs.host.com/litesout.exe" NDATA
   binary>
   <!NOTATION binary SYSTEM "Foo Bar Executable Format">
   ]>
   <iCalendar>
   <iCal version="2.0"
         prodid="-//hacksw/handcal//NONSGML 1.0//EN">
   <event>
        <uid>19990104T130000@host.com</uid>
        <dtstamp>19990104T130100Z</dtstamp>
        <start>19990704T230000Z</start>
        <end>19970705T040000Z</end>
        <summary>Firework Celebration</summary>
        <categories>
           <item>Holiday</item>
           <item>Special Occasion</item>
        </categories>
   <alarm>
        <action>DISPLAY</action>
        <desc>Firework Celebration Tonight at 6 PM !!!</desc>
        <trigger>19990704T224500Z</trigger>
        <repeat>2</repeat>
        <duration>PT15M</duration>
   </alarm>
   <alarm>
        <action>AUDIO</action>
        <trigger>19990704T224500Z</trigger>
        <repeat>2</repeat>
        <duration>PT15M</duration>
        <attach><extref uri="boom"/></attach>
   </alarm>
   <alarm>
        <action>EMAIL</action>
        <desc><![CDATA[Firework Celebration Tonight
        at 6 PM on Channel 6!!!]]></desc>
        <summary>*** Firework Celebration On TV ***</summary>
        <trigger>19990704T224500Z</trigger>
        <attendee>MAILTO:PIN1234@pager.host.com</attendee>
   </alarm>
   <alarm>
        <action>PROCEDURE</action>
        <attach><extref uri="doit"/></attach>
        <trigger>19990704T230000Z</trigger>
   </alarm>
   </event>
   </iCal>
   </iCalendar>




Dawson, Reddy, Royer               25             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


4  iCalendar XML Document Type Definition

   The following DTD conforms to XML version 1.0, as specified by [XML].

   <?xml version="1.0" encoding="UTF-8"?>

   <!-- ******************* -->
   <!-- Entity declarations -->
   <!-- ******************* -->

   <!ENTITY % attr.altrep "
        altrep ENTITY #IMPLIED
   ">

   <!ENTITY % attr.cn "
        cn CDATA ''
   ">

   <!ENTITY % attr.cutype "
        cutype NMTOKEN 'INDIVIDUAL'
   ">
   <!-- Valid name tokens are "INDIVIDUAL", "GROUP", "RESOURCE" -->
   <!-- "ROOM", "UNKNOWN", a non-standard "X-" name or another -->
   <!-- IANA registered name. -->

   <!ENTITY % attr.delfrom "
        delfrom CDATA #IMPLIED
   ">
   <!-- delfrom value is a calendar user address -->

   <!ENTITY % attr.delto "
        delto CDATA #IMPLIED
   ">
   <!-- delto value is one or more calendar user addresses -->

   <!ENTITY % attr.dir "
        dir ENTITY #IMPLIED
   ">
   <!-- dir value is a URI to a directory entry -->

   <!ENTITY % attr.fmttype "
        fmttype CDATA #REQUIRED
   ">
   <!-- fmttype value is any IANA registered content type -->

   <!ENTITY % attr.fbtype "
        fbtype NMTOKEN 'BUSY'
   ">
   <!-- Valid token values are "FREE", "BUSY", "BUSY-UNAVAILABLE", -->
   <!-- "BUSY-TENTATIVE", a non-standard "X-" name or another -->
   <!-- IANA registered name. -->

   <!ENTITY % attr.lang "
        lang CDATA #IMPLIED


Dawson, Reddy, Royer               26             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   ">
   <!-- lang value is a valid RFC 1766 language string -->

   <!ENTITY % attr.member "
        member CDATA #IMPLIED
   ">
   <!-- member value is one or more calendar user addresses -->

   <!ENTITY % attr.partstat "
        partstat NMTOKEN 'NEEDS-ACTION'
   ">
   <!-- Valid token value for VEVENT: "NEEDS-ACTION", "ACCEPTED", -->
   <!-- "DECLINED", "TENTATIVE", "DELEGATED", a non-standard "X- -->
   <!-- name or another IANA registered name. -->

   <!-- Valid token value for VTODO: "NEEDS-ACTION", "ACCEPTED", -->
   <!-- "DECLINED", "TENTATIVE", "DELEGATED", "COMPLETED", -->
   <!-- "IN-PROGRESS, a non-standard "X- name or another IANA -->
   <!-- registered name. -->

   <!-- Valid token value for VJOURNAL: "NEEDS-ACTION", "ACCEPTED", -->
   <!-- "DECLINED", a non-standard "X- name or another IANA -->
   <!-- registered name. -->

   <!ENTITY % attr.range "
        range NMTOKEN 'THISONLY'
   ">
   <!-- Valid token values are "THISONLY" or "THISANDPRIOR" or -->
   <!-- "THISANDFUTURE" -->

   <!ENTITY % attr.trigtype "
        trigtype NMTOKEN 'START'
   ">
   <!-- Valid token values are "START" or "END" -->

   <!ENTITY % attr.reltype "
        reltype NMTOKEN 'PARENT'
   ">
   <!-- Valid token values are "PARENT", "CHILD", SIBLING", -->
   <!-- a non-standard "X-" name or any IANA registered name. -->

   <!ENTITY % attr.role "
        role NMTOKEN 'REQ-PARTICIPANT'
   ">
   <!-- Valid token values are "CHAIR", "REQ-PARTICIPANT", -->
   <!-- "OPT-PARTICIPANT", "NON-PARTICIPANT", a non-standard "X-" -->
   <!-- name or any IANA registered name. -->

   <!ENTITY % attr.rsvp "
        rsvp NMTOKEN 'FALSE'
   ">
   <!-- Valid token values are "TRUE" or "FALSE", -->

   <!ENTITY % attr.sentby "


Dawson, Reddy, Royer               27             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


        sentby CDATA #IMPLIED
   ">
   <!-- sentby value is a calendar user address -->

   <!ENTITY % attr.tzid "
        tzid CDATA #IMPLIED
   ">
   <!-- tzid value is a time zone identifier -->

   <!ENTITY % cal.comp "
        event | todo | journal | freebusy | timezone
   ">

   <!ENTITY % event.opt1 "
        class | created | desc | dtstamp | start | geo |
        last-mod | location | organizer | priority | recurid |
        seq | status | summary | transp | uid | url |
        (end | duration)
   ">
   <!-- These properties may only appear once in a VEVENT -->

   <!ENTITY % event.optm "
        attach | attendee | categories | comment | contact |
        exdate | exrule | rdate | related | resources | rstatus |
        rrule
   ">
   <!-- These properties may appear one or more times in a VEVENT -->

   <!ENTITY % todo.opt1 "
        class | completed | created | desc | dtstamp | start |
        geo | last-mod | location | organizer | percent | priority |
        recurid | seq | status | summary | uid | url |
        (due | duration)
   ">
   <!-- These properties may only appear once in a VTODO -->

   <!ENTITY % todo.optm "
        attach | attendee | categories | comment | contact |
        exdate | exrule | rstatus | related | resources |
        rdate | rrule
   ">
   <!-- These properties may appear one or more times in a VTODO -->

   <!ENTITY % journal.opt1 "
        class | created | desc | start | dtstamp | last-mod |
        organizer | recurid | seq | status | summary | uid | url
   ">
   <!-- These properties may only appear once in a VJOURNAL -->

   <!ENTITY % journal.optm "
        attach | attendee | categories | comment | contact |
        exdate | exrule | related | rdate | rrule | rstatus
   ">
   <!-- These properties may appear one or more times in a VJOURNAL -->


Dawson, Reddy, Royer               28             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999



   <!ENTITY % freebusy.opt1 "
        contact | dtstamp | start | end | duration |
        organizer | uid | url
   ">
   <!-- These properties may only appear once in a VFREEBUSY -->

   <!ENTITY % freebusy.optm "
        attendee | comment | fbdata | rstatus
   ">
   <!-- These properties may appear one or more times in a -->
   <!-- VFREEBUSY -->

   <!ENTITY % timezone.man "
        tzid
   ">
   <!-- These properties must appear in a TIMEZONE -->

   <!ENTITY % timezone.opt1 "
        last-mod | tzurl
   ">
   <!-- These properties may only appear once in a VTIMEZONE -->

   <!ENTITY % timezone.mann "
        (standard | daylight), (standard | daylight)*
   ">
   <!-- These properties must appear in a VTIMEZONE and may -->
   <!-- appear multiple times -->

   <!ENTITY % standard.man "
        start | tzoffsetto | tzoffsetfrom
   ">
   <!-- These properties must appear in a STANDARD, but only once -->

   <!ENTITY % standard.optm "
        comment | rdate | rrule | tzname
   ">
   <!-- These properties may appear one or more times in a STANDARD -->

   <!ENTITY % daylight.man "
        start | tzoffsetto | tzoffsetfrom
   ">
   <!-- These properties must appear in a DAYLIGHT, but only once -->

   <!ENTITY % daylight.optm "
        comment | rdate | rrule | tzname
   ">
   <!-- These properties may appear one or more times in a DAYLIGHT -->

   <!ENTITY % audio.man "
        action, trigger
   ">
   <!-- These properties must appear in an audio VALARM. -->



Dawson, Reddy, Royer               29             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <!ENTITY % audio.optx "
        duration | repeat
   ">
   <!-- These properties may appear once in an audio VALARM. If one -->
   <!-- appears, then both must appear. -->

   <!ENTITY % audio.opt1 "
        attach
   ">
   <!-- These properties may appear once in an audio VALARM. -->

   <!ENTITY % alarm.audio "
        (%audio.man;), (%audio.optx;)*, (%audio.opt1;)
   ">

   <!ENTITY % display.man "
        action, desc, trigger
   ">
   <!-- These properties must appear in a display VALARM. -->

   <!ENTITY % display.optx "
        duration | repeat
   ">
   <!-- These properties may appear once in a display VALARM. If -->
   <!-- one appears, then both must appear. -->

   <!ENTITY % alarm.display "
        (%display.man;), (%display.optx;)*
   ">

   <!ENTITY % email.man "
        action, desc, summary, trigger
   ">
   <!-- These properties must appear in an email VALARM. -->

   <!ENTITY % email.optx "
        duration | repeat
   ">
   <!-- These properties may appear once in an email VALARM. If one -->
   <!-- appears, then both must appear. -->

   <!ENTITY % email.optm "
        attach
   ">
   <!-- These properties may appear one or more times in an email -->
   <!-- VALARM. -->

   <!ENTITY % email.mann "
        attendee
   ">
   <!-- These properties must appear in an email VALARM. The may -->
   <!-- appear more than once. -->

   <!ENTITY % alarm.email "


Dawson, Reddy, Royer               30             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


        (%email.man;), (%email.optx;)*, (%email.optm;)*,
        (%email.mann;)*
   ">

   <!ENTITY % procedure.man "
        action, attach, trigger
   ">
   <!-- These properties must appear in an audio VALARM. -->

   <!ENTITY % procedure.optx "
        duration | repeat
   ">
   <!-- These properties may appear once in an procedure VALARM. -->
   <!-- If one appears, then both must appear. -->

   <!ENTITY % procedure.opt1 "
        desc
   ">
   <!-- These properties may appear once in a procedure VALARM -->

   <!ENTITY % alarm.procedure "
        (%procedure.man;), (%procedure.optx;)*, (%procedure.opt1;)?
   ">

   <!-- ******************************************** -->
   <!-- iCalendar value type notation declarations -->
   <!-- ******************************************** -->

   <!-- NOTE: The "ICALXML" text in the following NOTATION values
   will be replaced with the text "RFC xxxx", where "xxxx" is the RFC
   number, when this memo is published as a RFC. -->

   <!NOTATION BINARY PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Binary//EN">

   <!NOTATION BOOLEAN PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Boolean//EN">

   <!NOTATION CALADR PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Calendar User Address//EN">

   <!NOTATION DATE PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Date//EN">

   <!NOTATION DATE-TIME PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Date-Time//EN">

   <!NOTATION DURATION PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Duration//EN">

   <!NOTATION FLOAT PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Float//EN">




Dawson, Reddy, Royer               31             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <!NOTATION INTEGER PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Integer//EN">

   <!NOTATION PERIOD PUBLIC "-//IETF//NOTATION ICALXML/Value Type/Period
   of Time//EN">

   <!NOTATION RECUR PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Recurrence Rule//EN">

   <!NOTATION TEXT PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Text//EN">

   <!NOTATION TIME PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/Time//EN">

   <!NOTATION URI PUBLIC "-//IETF//NOTATION ICALXML/Value Type/URI//EN">

   <!NOTATION UTC-OFFSET PUBLIC "-//IETF//NOTATION ICALXML/Value
   Type/UTC-Offset//EN">

   <!NOTATION X-NAME PUBLIC "-//IETF//NOTATION ICALXML/Value Type/X-
   Name//EN">

   <!-- ************************************************* -->
   <!-- iCalendar property element/attribute declarations -->
   <!-- ************************************************** -->

   <!ELEMENT br EMPTY>
   <!-- Signifies a new line in the TEXT value content information -->

   <!-- Description component properties element type declarations -->

   <!ELEMENT attach (extref | b64bin)>
   <!-- extref holds a reference to an external entity that -->
   <!-- has the attachment. b64bin holds the inline BASE64 encoded -->
   <!-- binary data for the attachment as defined in RFC 2045. -->

   <!ELEMENT extref EMPTY>
   <!ATTLIST extref
        uri ENTITY #REQUIRED>

   <!ELEMENT b64bin (#PCDATA)>
   <!ATTLIST b64bin
        %attr.fmttype;
        value NOTATION (BINARY) #IMPLIED>

   <!ELEMENT categories (item)*>

   <!ELEMENT item (#PCDATA)>
   <!ATTLIST item
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT class (#PCDATA)>


Dawson, Reddy, Royer               32             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <!ATTLIST class
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT comment (#PCDATA)*>
   <!ATTLIST comment
        %attr.lang;
        %attr.altrep;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT desc (#PCDATA)*>
   <!ATTLIST desc
        %attr.lang;
        %attr.altrep;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT geo (lat, lon)>

   <!ELEMENT lat (#PCDATA)>
   <!ATTLIST lat value NOTATION (FLOAT) #IMPLIED>
   <!-- A decimal degree float number to 6 decimal places -->

   <!ELEMENT lon (#PCDATA)>
   <!ATTLIST lon value NOTATION (FLOAT) #IMPLIED>
   <!-- A decimal degree float number to 6 decimal places -->

   <!ELEMENT location (#PCDATA)>
   <!ATTLIST location
        %attr.lang;
        %attr.altrep;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT percent (#PCDATA)>
   <!ATTLIST percent
        value NOTATION (INTEGER) #IMPLIED>

   <!ELEMENT priority (#PCDATA)>
   <!ATTLIST priority
        value NOTATION (INTEGER) #IMPLIED>

   <!ELEMENT resources (#PCDATA)>
   <!ATTLIST resources
        %attr.lang;
        %attr.altrep;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT status (#PCDATA)>
   <!ATTLIST status
        %attr.lang;
        %attr.altrep;
        value NOTATION (TEXT) #IMPLIED>
   <!-- Text value must match the valid values for the particular -->
   <!-- calendar component. -->



Dawson, Reddy, Royer               33             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <!ELEMENT summary (#PCDATA)>
   <!ATTLIST summary
        %attr.lang;
        %attr.altrep;
        value NOTATION (TEXT) #IMPLIED >

   <!-- Data and time component property element type declarations -->

   <!ELEMENT start (#PCDATA)>
   <!ATTLIST start
        %attr.tzid;
        value NOTATION (DATE-TIME | DATE) "DATE-TIME">

   <!ELEMENT end (#PCDATA)>
   <!ATTLIST end
        %attr.tzid;
        value NOTATION (DATE-TIME | DATE) "DATE-TIME">

   <!ELEMENT due (#PCDATA)>
   <!ATTLIST due
        %attr.tzid;
        value NOTATION (DATE-TIME | DATE) "DATE-TIME">

   <!ELEMENT completed (#PCDATA)>
   <!ATTLIST completed
        value NOTATION (DATE-TIME) #IMPLIED>

   <!ELEMENT duration (#PCDATA)>
   <!ATTLIST duration
        value NOTATION (DURATION) #IMPLIED>

   <!ELEMENT fbdata (#PCDATA)>
   <!ATTLIST fbdata
        %attr.fbtype;
        value NOTATION (PERIOD) #IMPLIED>

   <!ELEMENT transp (#PCDATA)>
   <!ATTLIST transp
        value NOTATION (TEXT) #IMPLIED>
   <!-- Text value must be one of the valid enumerations. -->

   <!-- Time zone component property element type declarations -->

   <!ELEMENT tzid (#PCDATA)>
   <!ATTLIST tzid
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT tzname (#PCDATA)>
   <!ATTLIST tzname
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT tzoffsetfrom (#PCDATA)>
   <!ATTLIST tzoffsetfrom


Dawson, Reddy, Royer               34             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


        value NOTATION (UTC-OFFSET) #IMPLIED>

   <!ELEMENT tzoffsetto (#PCDATA)>
   <!ATTLIST tzoffsetto
        value NOTATION (UTC-OFFSET) #IMPLIED>

   <!ELEMENT tzurl EMPTY>
   <!ATTLIST tzurl
        uri ENTITY #REQUIRED>

   <!-- Relationship component property element type declarations -->

   <!ELEMENT attendee (#PCDATA)>
   <!ATTLIST attendee
        %attr.lang;
        %attr.cn;
        %attr.role;
        %attr.partstat;
        %attr.rsvp;
        %attr.cutype;
        %attr.member;
        %attr.delto;
        %attr.delfrom;
        %attr.sentby;
        %attr.dir;
        value NOTATION (CALADR) #IMPLIED>

   <!ELEMENT contact (#PCDATA)*>
   <!ATTLIST contact
        %attr.lang;
        %attr.altrep;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT organizer (#PCDATA)>
   <!ATTLIST organizer
        %attr.lang;
        %attr.cn;
        %attr.sentby;
        %attr.dir;
        value NOTATION (CALADR) #IMPLIED>

   <!ELEMENT recurid (#PCDATA)>
   <!ATTLIST recurid
        %attr.tzid;
        %attr.range;
        value NOTATION (DATE-TIME | DATE) "DATE-TIME">

   <!ELEMENT related (#PCDATA)>
   <!ATTLIST related
        %attr.reltype;
        value NOTATION (TEXT) #IMPLIED>

   <!ELEMENT url EMPTY>
   <!ATTLIST url


Dawson, Reddy, Royer               35             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


        uri ENTITY #REQUIRED>

   <!ELEMENT uid (#PCDATA)>
   <!ATTLIST uid
        value NOTATION (TEXT) #IMPLIED>

   <!-- Recurrence component property element type declarations -->

   <!ELEMENT exdate (#PCDATA)>
   <!ATTLIST exdate
        %attr.tzid;
        value NOTATION (DATE-TIME | DATE) "DATE-TIME">

   <!ELEMENT exrule (#PCDATA)>
   <!ATTLIST exrule
        value NOTATION (RECUR) #IMPLIED>

   <!ELEMENT rdate (#PCDATA)>
   <!ATTLIST rdate
        %attr.tzid;
        value NOTATION (DATE-TIME | DATE) "DATE-TIME">

   <!ELEMENT rrule (#PCDATA)>
   <!ATTLIST rrule
        value NOTATION (RECUR) #IMPLIED>

   <!-- Alarm component property element type declarations -->

   <!ELEMENT action (#PCDATA)>
   <!ATTLIST action
        value NOTATION (TEXT) #IMPLIED>
   <!-- Text value must be a valid enumeration -->

   <!ELEMENT repeat (#PCDATA)>
   <!ATTLIST repeat
        value NOTATION (INTEGER) #IMPLIED>

   <!ELEMENT trigger (#PCDATA)>
   <!ATTLIST trigger
        %attr.trigtype;
        value NOTATION (DURATION | DATE-TIME) "DURATION">

   <!-- Change management component property element type -->
   <!-- declarations -->

   <!ELEMENT created (#PCDATA)>
   <!ATTLIST created
        value NOTATION (DATE-TIME) #IMPLIED>

   <!ELEMENT dtstamp (#PCDATA)>
   <!ATTLIST dtstamp
        value NOTATION (DATE-TIME) #IMPLIED>

   <!ELEMENT last-mod (#PCDATA)>


Dawson, Reddy, Royer               36             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   <!ATTLIST last-mod
        value NOTATION (DATE-TIME) #IMPLIED>

   <!ELEMENT seq (#PCDATA)>
   <!ATTLIST seq
        value NOTATION (INTEGER) #IMPLIED>

   <!-- Miscellaneous component property element type declarations -->

   <!ELEMENT rstatus (#PCDATA)>
   <!ATTLIST rstatus
        %attr.lang;
        value NOTATION (TEXT) #IMPLIED>

   <!-- iCalendar object element type declarations -->

   <!ELEMENT iCalendar (iCal+)>

   <!ELEMENT iCal (%cal.comp;)*>
   <!ATTLIST iCal
        %attr.lang;
        xmlns CDATA #FIXED 'http://www.ietf.org/internet-drafts/draft-
   many-ical-xmldoc-01.txt'
        calscale CDATA "GREGORIAN"
        method CDATA "PUBLISH"
        version CDATA #REQUIRED
        prodid CDATA #IMPLIED>
   <!-- version - Must be "2.0" if document conforms to this spec. -->
   <!-- calscale - Calendar scale. Default is GREGORIAN. -->
   <!-- method - C&S method. Default is iTIP PUBLISH. -->
   <!-- prodid - ISO 9070 FPI for product that generated iCalendar. -->

   <!-- "event" element type declaration -->
   <!ELEMENT event      ((%event.opt1;)*, (%event.optm;)*, alarm*)>

   <!-- "todo" element type declaration -->
   <!ELEMENT todo       ((%todo.opt1;)*, (%todo.optm;)*, alarm*)>

   <!-- "journal" element type declaration -->
   <!ELEMENT journal    ((%journal.opt1;)*, (%journal.optm;)*)>

   <!-- "freebusy" element type declaration -->
   <!ELEMENT freebusy   ((%freebusy.opt1;)*, (%freebusy.optm;)*)>

   <!-- "timezone" element type declaration -->
   <!ELEMENT timezone   (%timezone.man;, (%timezone.opt1;)*,
                        (%timezone.mann;)*)>

   <!ELEMENT standard   (((%standard.man;)*), (%standard.optm;)*)>

   <!ELEMENT daylight   (((%daylight.man;)*), (%daylight.optm;)*)>

   <!ELEMENT alarm      ((%alarm.audio;) | (%alarm.display;) |
                         (%alarm.email;) | (%alarm.procedure;))>


Dawson, Reddy, Royer               37             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


5  Acknowledgments

   The following have participated in the drafting and discussion of
   this memo:

   Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert,
   Thomas Rowe.

6  IANA Considerations

   This document defines a XML Formal Public Identifier (FPI), based on
   a format defined in [ISO9070], that identifies a XML document type
   corresponding to this memo. Publication of this memo constitutes
   registration of this identifier.

   In addition, this memo defines the XML FPIs corresponding to each of
   the value types specified in [RFC2445].

7  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" and "VTODO" 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.

8  Bibliography

   [ISO9070] "Information Technology_SGML Support Facilities_
   Registration Procedures for Public Text Owner Identifiers", ISO/IEC
   9070, Second Edition, International Organization for Standardization,
   April 1991.


Dawson, Reddy, Royer               38             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


   [RFC2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
   Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
   2045, Error! Bookmark not defined., November 1996.

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt,
   March 1997.

   [RFC2445] 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.

   [XMLNS] "Namespaces in XML", Worldwide Web Consortium,
   http://www.w3.org/TR/1999/REC-xml-names-19990114, January 1999.

9  Author's Address

   The following address information is provided in a vCard XML DTD
   electronic business card, format.


   <vCard
        version="3.0">
   <fn>Frank Dawson</fn>
   <n>  <family>Dawson</family>
        <given>Frank</given></n>
   <org><orgname>Lotus Development Corporation</orgname>
   <adr adr.type="WORK POSTAL PARCEL">
        <street>6544 Battleford Drive</street>
        <locality>Raleigh</locality>
        <region>NC</region>
        <pcode>27613-3502</pcode>
        <country>USA</country></adr>
   <tel tel.type="PREF WORK MSG">+1-617-693-8728</tel>
   <tel tel.type="WORK MSG">+1-919-676-9515</tel>
   <email email.type="PREF INTERNET">Frank_Dawson@Lotus.com</email>
   <email email.type="INTERNET">fdawson@earthlink.net</email>
   </vCard>

   <vCard
        version="3.0">
   <fn>Surendra K. Reddy</fn>
   <n>  <family>Reddy</family>
        <given>Surendra</given>
        <other>K.</other>
   <org><orgname>Oracle Corporation</orgname></org>
   <adr adr.type="WORK POSTAL PARCEL">
        <extadr> M/S 6op3</extadr>
        <street>500 Oracle Parkway</street>
        <locality>Redwoodshores</locality>
        <region>CA</region>


Dawson, Reddy, Royer               39             Expires December 1999




Internet Draft           iCalendar DTD Document           June 10, 1999


        <pcode>94065</pcode>
        <country>USA</country></adr>
        <tel tel.type="WORK MSG">+1(650) 506 5441</tel>
        <tel tel.type="WORK FAX">+1(650) 654 6205</tel>
        <email email.type="INTERNET">skreddy@us.oracle.com</email>
   </vCard>

   <vCard
        version="3.0">
   <fn> Doug Royer </fn>
   <n>  <family>Royer</family>
        <given>Doug</given>
   <org><orgname>Sun Microsystems</orgname></org>
   <adr adr.type="WORK POSTAL PARCEL">
        <extadr> MS MPK17-105</extadr>
        <street>901 San Antonio Road</street>
        <locality>Palo Alto</locality>
        <region>CA</region>
        <pcode>94303-4900</pcode>
        <country>USA</country></adr>
        <tel tel.type="WORK MSG">+1(650) 786 7599</tel>
        <email email.type="INTERNET">doug.royer@sun.com</email>
   </vCard>


10 Full Copyright Statement

   "Copyright (C) The Internet Society (1999).All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implmentation may be prepared, copied, published and
   distributed, in whole or in part, without restriction of any kind,
   provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process MUST be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.




Dawson, Reddy, Royer               40             Expires December 1999


Html markup produced by rfcmarkup 1.127, available from https://tools.ietf.org/tools/rfcmarkup/