idnits 2.17.1
draft-ietf-calsch-many-xcal-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** There are 21 instances of too long lines in the document, the longest
one being 12 characters in excess of 72.
** The abstract seems to contain references ([RFC2119], [XML], [RFC2445]),
which it shouldn't. Please replace those with straight textual mentions
of the documents in question.
** The document seems to lack a both a reference to RFC 2119 and the
recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
keywords -- however, there's a paragraph with a matching beginning.
Boilerplate error?
RFC 2119 keyword, line 145: '... use namespaces MUST NOT include othe...'
RFC 2119 keyword, line 181: '... This FPI MUST be used on the DOCTYP...'
RFC 2119 keyword, line 184: '... This FPI SHOULD also be used to ide...'
RFC 2119 keyword, line 214: '... to this specification MUST be able to...'
RFC 2119 keyword, line 218: '...orming to this memo MUST only send the...'
(18 more instances...)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 458 has weird spacing: '...alendar xmln...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 25, 2002) is 7946 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Missing reference section? 'XML' on line 1989 looks like a reference
-- Missing reference section? 'RFC 2445' on line 1982 looks like a reference
-- Missing reference section? 'RFC 2119' on line 1978 looks like a reference
-- Missing reference section? 'RFC 2146' on line 133 looks like a reference
-- Missing reference section? 'XMLNS' on line 669 looks like a reference
-- Missing reference section? 'RFC2445' on line 242 looks like a reference
-- Missing reference section? 'RFC 2045' on line 1974 looks like a reference
-- Missing reference section? 'ISO 9070' on line 1926 looks like a reference
-- Missing reference section? 'FPI' on line 1965 looks like a reference
-- Missing reference section? 'ISO9070' on line 1969 looks like a reference
Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 12 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group F. Dawson
3 Internet-Draft Nokia
4 Expires: January 23, 2003 S. Reddy
5 Oracle
6 D. Royer
7 INET-Consulting
8 E. Plamondon
9 Oracle
10 July 25, 2002
12 iCalendar DTD Document (xCal)
13 draft-ietf-calsch-many-xcal-02
15 Status of this Memo
17 This document is an Internet-Draft and is in full conformance with
18 all provisions of Section 10 of RFC2026.
20 Internet-Drafts are working documents of the Internet Engineering
21 Task Force (IETF), its areas, and its working groups. Note that
22 other groups may also distribute working documents as Internet-
23 Drafts.
25 Internet-Drafts are draft documents valid for a maximum of six months
26 and may be updated, replaced, or obsoleted by other documents at any
27 time. It is inappropriate to use Internet-Drafts as reference
28 material or to cite them other than as "work in progress."
30 The list of current Internet-Drafts can be accessed at http://
31 www.ietf.org/ietf/1id-abstracts.txt.
33 The list of Internet-Draft Shadow Directories can be accessed at
34 http://www.ietf.org/shadow.html.
36 This Internet-Draft will expire on January 23, 2003.
38 Copyright Notice
40 Copyright (C) The Internet Society (2002). All Rights Reserved.
42 Abstract
44 This memo defines a [XML] Document Type Definition (DTD) that
45 corresponds to the iCalendar, Internet Calendaring and Scheduling
46 Core Object Specification defined by [RFC 2445]. This DTD provides
47 equivalent functionality to the standard format defined by [RFC
48 2445]. Documents structured in accordance with this DTD may also be
49 known as "XML iCalendar" documents or "xCal".
51 The mailing list for discussion of this memo is "ietf-
52 calendar@imc.org". Send an email to "ietf-calendar-request@imc.org"
53 with the message "SUBSCRIBE" to add your email address to this
54 mailing list. Send an email to "ietf-calendar-request@imc.org" with
55 the message "UNSUBSCRIBE" to remove your email address from this
56 mailing list.
58 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
59 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
60 document are to be interpreted as described in [RFC 2119].
62 Table of Contents
64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
65 2. Using XML For Representating iCalendar . . . . . . . . . . . 6
66 2.1 XML Dependencies . . . . . . . . . . . . . . . . . . . . . . 6
67 2.2 Document Type Definition . . . . . . . . . . . . . . . . . . 6
68 2.3 Working With Standard and XML iCalendar Representations . . 6
69 2.3.1 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 6
70 2.3.2 Mixed Use of Both Representations . . . . . . . . . . . . . 7
71 2.4 Using Data Types . . . . . . . . . . . . . . . . . . . . . . 7
72 2.5 Including Binary Content . . . . . . . . . . . . . . . . . . 8
73 2.6 Including Multiple iCalendar Objects . . . . . . . . . . . . 9
74 2.7 Mapping Property Parameters to XML . . . . . . . . . . . . . 10
75 2.8 Mapping Calendar Properties to XML . . . . . . . . . . . . . 11
76 2.9 Mapping Component Properties to XML . . . . . . . . . . . . 13
77 2.10 Parameter Entities . . . . . . . . . . . . . . . . . . . . . 16
78 2.11 Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 17
79 2.12 Emailing the iCalendar XML Representation . . . . . . . . . 17
80 2.13 iCalendar XML Representation and File Systems . . . . . . . 18
81 3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . 20
82 3.1 A well-formed and valid iCalendar XML document . . . . . . . 20
83 3.2 Adding non-standard, experimental extensions . . . . . . . . 20
84 3.3 Including binary content in attachments . . . . . . . . . . 21
85 3.4 iCalendar XML document with multiple iCalendar objects . . . 23
86 3.5 Using the iCalendar namespace . . . . . . . . . . . . . . . 24
87 3.6 Publish meeting information . . . . . . . . . . . . . . . . 25
88 3.7 Publish transparent annual event . . . . . . . . . . . . . . 25
89 3.8 Meeting invitation . . . . . . . . . . . . . . . . . . . . . 26
90 3.9 Assign a to-do . . . . . . . . . . . . . . . . . . . . . . . 27
91 3.10 Publish a journal entry . . . . . . . . . . . . . . . . . . 28
92 3.11 Publish busy time . . . . . . . . . . . . . . . . . . . . . 29
93 3.12 Request busy time . . . . . . . . . . . . . . . . . . . . . 29
94 3.13 Response to a busy time request . . . . . . . . . . . . . . 30
95 3.14 Published event that references time zone information . . . 30
96 3.15 An event with an alarm . . . . . . . . . . . . . . . . . . . 31
97 4. iCalendar XML Document Type Definition . . . . . . . . . . . 34
98 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 48
99 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49
100 7. Security Considerations . . . . . . . . . . . . . . . . . . 50
101 8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 51
102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51
103 Full Copyright Statement . . . . . . . . . . . . . . . . . . 53
105 1. Introduction
107 The Extended Markup Language (XML) as defined in [XML] is gaining
108 widespread attention as a "web friendly" syntax for representing and
109 exchanging documents and data on the Internet. This interest
110 includes requests for and discussion of possible document type
111 definitions (DTD) and name-space for IETF standard formats such as
112 that defined by [RFC 2445].
114 This memo defines how XML can be used to represent iCalendar objects.
115 This memo includes the definition of the XML DTD for a XML document
116 representation of an iCalendar object.
118 NOTE: The [RFC 2445] is the definitive reference for the definition
119 of iCalendar semantics. This memo only provides an alternative, XML
120 representation for the standard syntax defined in [RFC 2445]. This
121 memo does not introduce any semantics not already defined by [RFC
122 2445].
124 An attempt has been made to leverage the standard features of the XML
125 syntax in order to represent the component iCalendar semantics. For
126 example, strong data typing is specified using the XML notation
127 declaration. The element type attributes are used to represent many
128 of the calendar properties that provide a "global attribute"
129 capability in an iCalendar object. Binary content in the ATTACH
130 component property may either be specified through an external entity
131 reference to a non-XML binary content or may be included in the XML
132 document's content information, after first being encoding using the
133 BASE64 scheme of [RFC 2146]. Parameter entities are used to
134 logically group content particles in the XML DTD in order to
135 facilitate reading and comprehension of the structure specified by
136 the iCalendar XML DTD.
138 The publication of XML version 1.0 was followed by the publication of
139 a World-wide Web Consortium (W3C) recommendation on "Namespaces in
140 XML". A XML name-space is a collection of names, identified by a
141 URI. In anticipation of the broader use of XML namespaces, this memo
142 includes the definition of the URI to be used to identify the
143 namespace associated with the iCalendar DTD element types in other
144 XML documents. XML applications that conform to this memo and also
145 use namespaces MUST NOT include other non-iCalendar namespaces in an
146 iCalendar XML document.
148 It is expected that the DTD defined in this memo will not normally be
149 included with iCalendar XML documents that are distributed. Instead,
150 the DTD will be referenced in the document type declaration in the
151 document entity. Such iCalendar XML documents will be well-formed
152 and valid, as defined in [XML]. In addition, other iCalendar XML
153 documents will be specified that do not include the XML prolog. Such
154 iCalendar XML documents will be well-formed but not valid.
156 2. Using XML For Representating iCalendar
158 XML is a simplified version of the text markup syntax defined by ISO
159 8879, Standard Generalized Markup Language (SGML). XML was published
160 as a proposed recommendation [XML] by the World-wide Web Consortium
161 (W3C) on February 10, 1998.
163 2.1 XML Dependencies
165 This memo specifies the XML representation for the standard iCalendar
166 format defined by [RFC 2445]. There are no XML dependencies other
167 than the [XML] and the [XMLNS] recommendations.
169 2.2 Document Type Definition
171 A XML DTD for iCalendar is defined by the DTD specified in section 3.
173 The formal public identifier (FPI) for the DTD is:
175 -//IETF//DTD XCAL//iCalendar XML//EN
177 NOTE: The "DTD XCAL" text in the FPI value will be replaced with the
178 text "RFC xxxx", where "xxxx" is the RFC number, when the memo is
179 published as a RFC.
181 This FPI MUST be used on the DOCTYPE statement within a XML document
182 referencing the DTD defined by this memo.
184 This FPI SHOULD also be used to identify iCalendar XML documents
185 within operating system registries of file, clipboard and interactive
186 rendering (e.g., memory clipboard or drag/drop) formats.
188 2.3 Working With Standard and XML iCalendar Representations
190 This memo defines an alternative, XML representation for the standard
191 iCalendar format defined in [RFC 2445]. This alternative
192 representation provides the same semantics as that defined in the
193 standard format.
195 2.3.1 Conversion
197 The standard format can be converted to and from this XML format
198 without loss of any calendaring information. When the XML
199 representation was defined, every attempt was made to use existing
200 component, property and parameter naming conventions. This greatly
201 facilitates transformations between the two representations.
203 2.3.2 Mixed Use of Both Representations
205 As previously indicated, conversion between the standard and XML
206 representations of iCalendar is a straightforward process. In
207 addition, mixed use of both representations is also possible.
209 With the use of the MIME multipart content-types, compound MIME
210 entities containing a mix of the standard and XML representations can
211 be specified. This capability is useful in applications where both
212 representations might be encountered. In addition, this capability
213 demonstrates the isomeric nature of the two representations. XML
214 applications conforming to this specification MUST be able to
215 properly parse and process a MIME multipart entity containing the
216 MIME type associated with this iCalendar XML document type.
218 Internet applications conforming to this memo MUST only send the
219 iCalendar XML document in a "multipart/alternative" MIME entity that
220 also contains an equivalent iCalendar object in the standard format
221 defined by [RFC2445]. This restriction will guarantee that the
222 iCalendar object can also be processed by Internet applications that
223 only support the standard iCalendar representation.
225 2.4 Using Data Types
227 Strong "data typing" is an integral design principle to the iCalendar
228 format. Strong data typing in iCalendar means that the format type
229 for each property value is well known. Within [RFC 2445], the data
230 type is called the "value type". The standard format defined by [RFC
231 2445] specifies a default value type for each calendar and component
232 property. In addition, many of the property definitions allow for
233 the specification of alternate value types. This XML representation
234 continues this design principle.
236 Explicit value/data typing in the XML representation is specified
237 with the "value" attribute on each element type. In addition, the
238 XML DTD specifies a default value/data type for each element type.
239 XML documents conforming to this memo need only specify the "value"
240 attribute on element types when the value needs to override the
241 default value/data type. The standard value types defined in
242 [RFC2445] are specified in the XML DTD by individual NOTATION
243 declarations. The formal public identifier for standard value types
244 all have the common string format of:
246 -//IETF//NOTATION XCAL/Value Type/xxx//EN
248 NOTE: The "XCAL" text in the FPI value will be replaced with the text
249 "RFC xxxx", where "xxxx" is the RFC number, when the memo is
250 published as a RFC.
252 Where "xxx" is replaced with the text specified in the table below.
254 The following table specifies the XML value/data type that
255 corresponds to each of the standard value types defined in [RFC
256 2445].
258 +--------------+------------+-------------------------+
259 | RFC 2445 | XML Value | Notation FPI Text |
260 | Value Type | Type | |
261 +--------------+------------+-------------------------+
262 | BINARY | BINARY | Binary |
263 | BOOLEAN | BOOLEAN | Boolean |
264 | CALADR | CALADR | Calendar User Address |
265 | DATE | DATE | Date |
266 | DATE-TIME | DATE-TIME | Date-Time |
267 | DURATION | DURATION | Duration |
268 | FLOAT | FLOAT | Float |
269 | INTEGER | INTEGER | Integer |
270 | PERIOD | PERIOD | Period of Time |
271 | RECUR | RECUR | Recurrence Rule |
272 | TEXT | TEXT | Text |
273 | TIME | TIME | Time |
274 | URI | URI | URI |
275 | UTC-OFFSET | UTC-OFFSET | UTC-Offset |
276 | Non-standard | X-NAME | X-Name |
277 +--------------+------------+-------------------------+
279 Other standard XML data types can be specified by including a
280 NOTATION declaration that specifies the formal public identifier
281 associated with the other standard format. In addition, the name of
282 the format specified in the NOTATION declaration is specified in the
283 "value" attribute of any element type that caste to the other
284 standard format.
286 2.5 Including Binary Content
288 Binary content can be included in an iCalendar object with the
289 "ATTACH" component property. In the standard iCalendar format this
290 content may either be specified through an external entity reference,
291 using a URI value type, or maybe specified within the iCalendar
292 object, after first BASE64 encoding the content.
294 The XML representation for iCalendar also supports including binary
295 content in an iCalendar object with the "attach" element type. It
296 also supports either an external reference to the non-XML binary
297 content or inclusion of the binary content after first encoding the
298 binary information using the BASE64 encoding of [RFC 2045].
300 Any iCalendar properties defined in [RFC 2445] that can be used to
301 include binary content are defined in the XML representation as an
302 element type with a content model that consists of either the
303 "extref" or the "b64bin" element type. The "extref" element type is
304 used to reference an external entity containing the binary content.
305 An external reference to the binary content is specified by the "uri"
306 attribute on the "extref" element type. For every external
307 reference, an ENTITY declaration and a corresponding NOTATION
308 declaration MUST also be specified in an internal DTD to identify the
309 location and format of the external entity. For example, the
310 following XML snippets would be needed to include a reference to the
311 executable "foo.exe" in the "attach" element type; which corresponds
312 to the "ATTACH" iCalendar component property:
314
316
317
319
321
323 The "b64bin" element type is used to include the binary content
324 within the XML document, after first character encoding the binary
325 information using the BASE64 encoding method of [RFC 2045]. For
326 example, the following XML snippets would be needed to include the
327 executable "foo.exe" in the "attach" element type; after first BASE64
328 encoding the binary information:
330
332 MIICajCC
333 AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l
334 dHNjYXBlIENvbW11bmljYXR5z...and so on...IENvcnBvc==
335
337 2.6 Including Multiple iCalendar Objects
339 The iCalendar format has the capability for including multiple,
340 individual iCalendar objects in a single data stream. The XML
341 representation can support this also. Individual iCalendar objects
342 are specified by the "vcalendar" element type. One or more
343 "vcalendar" element types are permitted within the parent element
344 type, called "iCalendar". For example:
346
347
348
349
351
352
353
354
356 2.7 Mapping Property Parameters to XML
358 The property parameters defined in the standard iCalendar format are
359 represented in the XML representation as an attribute on element
360 types. The following table specifies the attribute name
361 corresponding to each property parameter.
363 +----------------+----------------+-----------+-----------------+
364 | Property | Attribute | Attribute | Default |
365 | Parameter Name | Name | Type | Value |
366 +----------------+----------------+-----------+-----------------+
367 | ALTREP | altrep | ENTITY | IMPLIED |
368 | CN | cn | CDATA | Null String |
369 | CUTYPE | cutype | NMTOKEN | INDIVIDUAL |
370 | DELEGATED-FROM | delegated-from | CDATA | IMPLIED |
371 | DELEGATED-TO | delegated-to | CDATA | IMPLIED |
372 | DIR | dir | ENTITY | IMPLIED |
373 | ENCODING | Not Used | n/a | n/a |
374 | FMTTYPE | fmttype | CDATA | REQUIRED |
375 | FBTYPE | fbtype | NMTOKEN | BUSY |
376 | LANGUAGE | language | CDATA | IMPLIED |
377 | MEMBER | member | CDATA | IMPLIED |
378 | PARTSTAT | partstat | NMTOKEN | NEEDS-ACTION |
379 | RANGE | range | NMTOKEN | THISONLY |
380 | RELATED | related | NMTOKEN | START |
381 | RELTYPE | reltype | NMTOKEN | PARENT |
382 | ROLE | role | NMTOKEN | REQ-PARTICIPANT |
383 | RSVP | rsvp | NMTOKEN | FALSE |
384 | SENT-BY | sent-by | CDATA | IMPLIED |
385 | TZID | tzid | CDATA | IMPLIED |
386 | VALUE | value | NOTATION | See elements |
387 +----------------+----------------+-----------+-----------------+
389 The inline "ENCODING" property parameter is not needed in the XML
390 representation. Inline binary information is always included as
391 parsable character data, after first being encoded using the BASE64
392 encoding of [RFC 2045].
394 The "RANGE" property parameter defined by [RFC 2445] does not include
395 the "THISONLY" enumeration. This is the implicit default, if the
396 parameter is not specified on the "RECURRENCE-ID" property. However,
397 the value is needed in the XML representation because all attributes
398 need to explicitly specify a default value in the attribute's
399 declaration in the DTD. This enumeration has been added to the XML
400 representation.
402 A non-standard, experimental parameter can be added to the XML
403 representation by declaring it in an ATTLIST declaration and
404 assigning it a XML attribute type and corresponding default value.
406 2.8 Mapping Calendar Properties to XML
408 Calendar properties defined in the standard iCalendar format provide
409 information about an iCalendar object, as a whole. The calendar
410 properties are represented in the XML representation as an attribute
411 on the "iCalendar" and the "vcalendar" element type. The following
412 table specifies the attribute name permitted on the "iCalendar"
413 element type.
415 +---------------+-----------+-----------+-----------------+
416 | Calendar | Attribute | Attribute | Default |
417 | Property Name | Name | Type | Value |
418 +---------------+-----------+-----------+-----------------+
419 | CALSCALE | calscale | CDATA | IMPLIED |
420 | METHOD | method | NMTOKEN | PUBLISH |
421 | VERSION | version | CDATA | REQUIRED |
422 | PRODID | prodid | CDATA | IMPLIED |
423 +---------------+-----------+-----------+-----------------+
425 In addition to these attributes, the "vcalendar" element type can
426 also have the following attributes:
428 +-----------+-----------+---------+----------------------------+
429 | Attribute | Attribute | Default | Description |
430 | Name | Type | Value | |
431 +-----------+-----------+---------+----------------------------+
432 | xmlns | CDATA | FIXED | Used to specify the default|
433 | | | | iCalendar XML name space. |
434 | xmlns: + | CDATA | FIXED | Used to specify the |
435 | | | | |
437 +-----------+-----------+---------+----------------------------+
439 The semantics of the "xmlns" attribute, and any attribute with
440 "xmlns:" as a prefix, is as specified in [XMLNS]. It is used to
441 declare a namespace in XML. It can be used to declare the iCalendar
442 XML namespace in a XML document with a document type other than the
443 iCalendar XML document type. The iCalendar XML document type MUST
444 only use element types from the iCalendar namespace. Non-standard,
445 experimental element types and attributes lists MUST only be
446 specified by declarations in an internal DTD within the iCalendar XML
447 document. To specify the iCalendar namespace, the attribute value
448 for the "xmlns" and any attribute with the prefix "xmlns:" MUST be:
450 'http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt'
452 NOTE: This attribute value will be replaced with the URL "http://
453 www.ietf.org/rfc/rfcxxxx.txt", where "xxxx" is the RFC number, when
454 this memo is published as a RFC.
456 For example:
458
460
463
465 The following table specifies the attribute name corresponding to
466 each calendar property. These attributes are only permitted on the
467 "vcalendar" element type.
469 +---------------+-----------+-----------+-----------------+
470 | Calendar | Attribute | Attribute | Default |
471 | Property Name | Name | Type | Value |
472 +---------------+-----------+-----------+-----------------+
473 | CALSCALE | calscale | CDATA | IMPLIED |
474 | METHOD | method | NMTOKEN | PUBLISH |
475 | VERSION | version | CDATA | REQUIRED |
476 | PRODID | prodid | CDATA | IMPLIED |
477 +---------------+-----------+-----------+-----------------+
479 The semantics for these attributes is as specified for the
480 corresponding calendar property in [RFC 2445].
482 The following table specifies additional attributes that are
483 permitted on the "vcalendar" element type.
485 +-----------+-----------+---------+----------------------------+
486 | Attribute | Attribute | Default | Description |
487 | Name | Type | Value | |
488 +-----------+-----------+---------+----------------------------+
489 | language | CDATA | IMPLIED | Used to specify the default|
490 +-----------+-----------+---------+----------------------------+
492 The "language" attribute permits the default language to be specified
493 for the whole iCalendar object. If the "language" attribute is
494 specified on the XML document, then if the XML representation is
495 converted into the standard format the "LANGUAGE" property parameter
496 MUST be specified on each TEXT valued property to prevent information
497 loss; when translating into the standard format.
499 2.9 Mapping Component Properties to XML
501 Component properties in the standard iCalendar format provide
502 calendar information about the calendar component. The component
503 properties defined in the standard iCalendar format are represented
504 in the XML representation as element types. The following tables
505 specify the element types corresponding to each of the properties in
506 the specified property category.
508 Descriptive Component Properties
509 +----------------+-------------+-----------------------------+
510 | Component | Element | Element Content Model |
511 | Property Name | Name | |
512 +----------------+-------------+-----------------------------+
513 | ATTACH | attach | extref or b64bin |
514 | | extref | EMPTY |
515 | | b64bin | PCDATA |
516 | CATEGORIES | categories | Any number of item elements |
517 | | item | PCDATA |
518 | CLASS | class | PCDATA |
519 | COMMENT | comment | PCDATA |
520 | DESCRIPTION | description | PCDATA |
521 | GEO | geo | lat followed by lon element |
522 | | lat | PCDATA |
523 | | lon | PCDATA |
524 | LOCATION | location | PCDATA |
525 | PERCENT | percent | PCDATA |
526 | PRIORITY | priority | PCDATA |
527 | RESOURCES | resources | Any number of item elements |
528 | STATUS | status | PCDATA |
529 | SUMMARY | summary | PCDATA |
530 +----------------+-------------+-----------------------------+
531 Date and Time Component Properties
532 +----------------+------------+-----------------------------+
533 | Component | Element | Element Content Model |
534 | Property Name | Name | |
535 +----------------+------------+-----------------------------+
536 | COMPLETED | completed | PCDATA |
537 | DTEND | dtend | PCDATA |
538 | DUE | due | PCDATA |
539 | DTSTART | dtstart | PCDATA |
540 | DURATION | duration | PCDATA |
541 | FREEBUSY | freebusy | PCDATA |
542 | TRANSP | transp | PCDATA |
543 +----------------+------------+-----------------------------+
545 Time Zone Component Properties
546 +----------------+-------------+-----------------------------+
547 | Component | Element | Element Content Model |
548 | Property Name | Name | |
549 +----------------+-------------+-----------------------------+
550 | TZID | tzid | PCDATA |
551 | TZNAME | tzname | PCDATA |
552 | TZOFFSETFROM | tzoffsetfrom| PCDATA |
553 | TZOFFSETTO | tzoffsetto | PCDATA |
554 | TZURL | tzurl | EMPTY |
555 +----------------+-------------+-----------------------------+
557 Relationship Component Properties
558 +----------------+---------------+--------------------------+
559 | Component | Element | Element Content Model |
560 | Property Name | Name | |
561 +----------------+---------------+--------------------------+
562 | ATTENDEE | attendee | PCDATA |
563 | CONTACT | contact | PCDATA |
564 | ORGANIZER | organizer | PCDATA |
565 | RECURRENCE-ID | recurrence-id | PCDATA |
566 | RELATED-TO | related-to | PCDATA |
567 | URL | url | EMPTY |
568 | UID | uid | PCDATA |
569 +----------------+---------------+--------------------------+
571 Recurrence Component Properties
572 +----------------+------------+-----------------------------+
573 | Component | Element | Element Content Model |
574 | Property Name | Name | |
575 +----------------+------------+-----------------------------+
576 | EXDATE | exdate | PCDATA |
577 | EXRULE | exrule | PCDATA |
578 | RDATE | rdate | PCDATA |
579 | RRULE | rrule | PCDATA |
580 +----------------+------------+-----------------------------+
582 Alarm Component Properties
583 +----------------+------------+-----------------------------+
584 | Component | Element | Element Content Model |
585 | Property Name | Name | |
586 +----------------+------------+-----------------------------+
587 | ACTION | action | PCDATA |
588 | REPEAT | repeat | PCDATA |
589 | TRIGGER | trigger | PCDATA |
590 +----------------+------------+-----------------------------+
592 Change Management Component Properties
593 +----------------+---------------+--------------------------+
594 | Component | Element | Element Content Model |
595 | Property Name | Name | |
596 +----------------+---------------+--------------------------+
597 | CREATED | created | PCDATA |
598 | DTSTAMP | dtstamp | PCDATA |
599 | LAST-MODIFIED | last-modified | PCDATA |
600 | SEQUENCE | sequence | PCDATA |
601 +----------------+---------------+--------------------------+
603 Miscellaneous Component Properties
604 +----------------+----------------+-------------------------+
605 | Component | Element | Element Content Model |
606 | Property Name | Name | |
607 +----------------+----------------+-------------------------+
608 | REQUEST-STATUS | request-status | PCDATA |
609 +----------------+----------------+-------------------------+
611 The following table specifies the element types that represent each
612 of the calendar components.
614 Component Structuring Properties
615 +----------------+------------+-------------------------------+
616 | Component | Element | Element Content Model |
617 | Property Name | Name | |
618 +----------------+------------+-------------------------------+
619 | Multiple iCal- | iCalendar | One or more iCal elements |
620 | endar objects | | |
621 | VCALENDAR | vcalendar | calcomp parameter entity |
622 | VEVENT | vevent | vevent.opt1 and vevent.optm |
623 | | | parameter entity and valarm |
624 | | | element |
625 | VTODO | vtodo | vtodo.opt1 and vtodo.optm |
626 | | | parameter entity and valarm |
627 | | | element |
628 | VJOURNAL | vjournal | vjournal.opt1 and |
629 | | | vjournal.optm parameter |
630 | | | entity |
631 | VFREEBUSY | vfreebusy | vfreebusy.opt1 and |
632 | | | vfreebusy.optm parameter |
633 | | | entity |
634 | VTIMEZONE | vtimezone | vtimezone.man, |
635 | | | vtimezone.opt1, |
636 | | | vtimezone.mann parameter |
637 | | | entity |
638 | STANDARD | standard | standard.man or standard.optm |
639 | | | entity |
640 | DAYLIGHT | daylight | daylight.man or daylight.optm |
641 | | | entity |
642 | VALARM | valarm | valarm.audio, valarm.display, |
643 | | | valarm.email and |
644 | | | valarm.procedure entity |
645 +----------------+------------+-------------------------------+
647 The [RFC 2445] specification specifies that the equivalent component
648 properties to the "comment", "description", "location", "summary" and
649 "contact" element types can contain formatted content, such as is
650 specified by multiple lines of text. In such cases, the formatted
651 text should be specified in as CDATA Section content. The CDATA
652 section specifies arbitrary character data that is not meant to be
653 interpretted. It is not scanned for markup by the XML parser. The
654 CDATA Section in these element types MUST NOT contain markup or other
655 such alternate representation of the property value. The "altrep"
656 attribute is used to reference any such alternate representation for
657 the textual content of these element types.
659 2.10 Parameter Entities
661 The external, iCalendar XML DTD specified in section 3 makes use of
662 parameter entity declarations. This XML feature is used to group
663 declarations within the DTD. This technique has been used in DTD
664 design in order to facilitate the reading and comprehension of the
665 structure specified by the DTD.
667 2.11 Namespace
669 [XMLNS] defines "Namespaces in XML" to be a collection of names,
670 identified by a URI, which are used in XML documents as element types
671 and attribute names. The [XML] specification does not include a
672 definition for namespaces, but does set down some guidelines for
673 experimental naming of namespaces.
675 XML namespaces allow multiple markup vocabulary in a single document.
676 Considering the utility of the iCalendar properties in other
677 applications, it is important for the iCalendar XML DTD to define a
678 namespace for the iCalendar element types.
680 This memo defines the value that MUST be used in non-iCalendar XML
681 documents that reference element types or attribute lists from the
682 iCalendar namespace.
684 The following is an example of a well-formed but invalid "xdoc"
685 document type that includes elements and attribute lists from the
686 iCalendar namespace:
688
689
690
693
694
696
697
699 2.12 Emailing the iCalendar XML Representation
701 It is expected that iCalendar XML documents will need to be sent over
702 SMTP/MIME email. The "text/xml" and "application/xml" content-types
703 have been registered for XML documents. However, use of these
704 content-type definitions present some problems for XML applications
705 such as calendaring and scheduling.
707 The "text/xml" and "application/xml" content-type definitions do not
708 provide for any header field parameters to identify the type of XML
709 document contained in the MIME entity. This means that a recipient
710 mail user agent must (MUA) open up each "text/xml" or "application/
711 xml" content in order to determine what object handler is needed to
712 process the information. To a MUA, all XML documents look like just
713 plain "text/xml" or "application/xml" content.
715 Additionally, it is accepted practice for a MUA to provide iconic
716 feedback to the user for individual content-types that are supported
717 by the MUA. For example, not only would feedback be provided for a
718 calendaring and scheduling content. Some further unique
719 identification would also be provided for each different scheduling
720 message; such as a meeting invitation, response to an invitation,
721 reschedule notice, cancellation notice, etc. In such cases,
722 acceptable performance by the MUA is dependent on the existence of
723 header field information, such as it provided in the definition of
724 the "text/calendar" content-type by [RFC 2445].
726 Internet application conforming to this memo MUST identify iCalendar
727 XML documents with the experimental content-type "application/
728 calendar+xml". The content-type header field SHOULD also contain a
729 "component" and "method" parameter to clearly identify a comma-
730 separated list of components and the singular method used in the
731 iCalendar XML document. For example, an iCalendar XML document
732 specifying a REQUEST for a VEVENT and VTODO would be specified with
733 the following content-type header field:
735 content-type:application/calendar+xml;method=REQUEST;component=VEVENT,VTODO
737 The content-type can also include the "optinfo" parameter to specify
738 any other optional iCalendar information. The semantics of these
739 content-type parameters is as defined in [RFC 2445].
741 Internet applications conforming to this memo MUST only send the
742 iCalendar XML document in a "multipart/alternative" MIME entity that
743 also contains an equivalent iCalendar object in the standard format
744 defined by [RFC 2445]. This restrict will guarantee that the
745 iCalendar object can also be processed by internet applications that
746 only support the standard iCalendar format.
748 An XML application supporting the iCalendar XML document type MUST be
749 able to receive and properly process the "application/calendar+xml"
750 document contained within a "multipart" message content-type.
752 2.13 iCalendar XML Representation and File Systems
754 The iCalendar XML documents will be stored in file systems. The
755 accepted practice for file extensions for XML documents is the text
756 "XML". However, in order to uniquely identify iCalendar XML
757 documents for file association with applications that can directly
758 process this document type, it is RECOMMENDED that the file extension
759 be the text "XCS".
761 3. Example Usage
763 The following sections provide various examples of iCalendar XML
764 documents.
766 3.1 A well-formed and valid iCalendar XML document
768 The following is a simple example of a iCalendar XML document. This
769 document is both a well-formed and valid XML document. The iCalendar
770 object specifies an appointment.
772
773
776
777
780
781 19981116T150000@cal10.host.com
782 19981116T145958Z
783 Project XYZ Review
784 Conference Room 23A
785 19981116T163000Z
786 19981116T190000Z
787
788 - Appointment
789
790
791
792
794 3.2 Adding non-standard, experimental extensions
796 The following is an example of a valid iCalendar XML document that
797 also includes a non-standard, experimental extension, as provided for
798 by [RFC 2445]. The iCalendar object specifies the publication of a
799 to-do with a non-standard experimental property for a customer charge
800 code.
802 The non-standard experimental property is identified by the "X-"
803 prefix to the element name. All non-standard properties MUST be
804 specified with element types with an "X-" type element name. In
805 addition, a text identifier for the vendor specifying the extension
806 SHOULD be appended to the "X-" text prefix. In this case, the
807 example specifies a "foo" for the name of the vendor specifying the
808 non- standard property.
810
811
821
822
823 ]>
825
826
829
830 19981104T130000@cal1.host.com
831 19981104T125957Z
832 19981105T133000Z
833 19981106T133000Z
834 Draft a test plan
835 1998-ABC Corp-1234
836 1
837
838
839
841 3.3 Including binary content in attachments
843 The following is an example of a valid iCalendar XML document that
844 also includes an external reference to an attachment. The iCalendar
845 object specifies a meeting invitation with an attachment.
847
848
854
856 ]>
858
859
862
863 19981211T133000@cal1.host.com
864 19981211T132928Z
865 jim@host.com
866 19981212T150000Z
867 19981212T160000Z
868 Department Meeting
869 Conference Room 23A
870 jim@host.com
871 MAILTO:joe@host.com
873 MAILTO:steve@host.com
875
876
877
878
880 The following is an example of a well-formed and valid iCalendar XML
881 document that includes an attachment as inline binary content. The
882 iCalendar object specifies a meeting invitation with an attachment.
884
885
888
889
892
893 19981211T133000@cal1.host.com
894 19981211T132928Z
895 MAILTO:jim@host.com
896 19981212T150000Z
897 19981212T160000Z
898 Department Meeting
899 Conference Room 23A
900 MAILTO:jim@host.com
901 MAILTO:joe@host.com
903 MAILTO:steve@host.com
905 MIICajCCAdOgAwIBAgI
906 CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB
907 lIEjYXRpb25z...and so on...IENvcnBvc==
908
909
910
912 3.4 iCalendar XML document with multiple iCalendar objects
914 The following is an example of a well-formed and valid iCalendar XML
915 document that includes more than one iCalendar object.
917
918
921
922
925
926 19981009T233000@cal1.host.com
927 19981009T232928Z
928 19981010T000000Z
929 19981010T235959Z
930 Register for conference
931 2
932
933
934
937
938 19981009T233010@cal1.host.com
939 19981009T233000Z
940 19981120T133000Z
941 19981122T183000Z
942 IT Conference
943 Downtowner Hotel
944
945
946
948 3.5 Using the iCalendar namespace
950 The following is an example of a snippet of a XML document that
951 includes elements from the iCalendar name-space.
953
956 19981123T133000Z
957 19981123T203000Z
958 1234567
959 999.99
960
962 3.6 Publish meeting information
964 The following is a snippet of an iCalendar XML document that
965 publishes information about a meeting. The "method" attribute isn't
966 specified since it is the default value.
968
969
971
972 19970901T130000Z-123401@host.com
973 19970901T130000Z
974 19970903T163000Z
975 19970903T190000Z
976 Annual Employee Review
977 PRIVATE
978
979 - Business
980 - Human Resources
981
982
983
984
986 3.7 Publish transparent annual event
988 The following is a snippet of an iCalendar XML document that
989 publishes information about an annually repeating event that is
990 transparent to busy time searches.
992
993
995
996 19990101T125957Z-123403@host.com
997 19990101T130000Z
998 19991102
999 19991102
1000 Our Blissful Anniversary
1001 CONFIDENTIAL
1002 TRANSPARENT
1003
1004 - Anniversary
1005 - Personal
1006 - Special Occasion
1007
1008 FREQ=YEARLY
1009
1010
1011
1013 3.8 Meeting invitation
1015 The following is a snippet of an iCalendar XML document that
1016 specifies an invitation for a meeting. The meeting occurs on the
1017 first Monday of each year for five years.
1019
1020
1023
1024 19981220T130000Z-123403@host.com
1025 19981220T130050Z
1026 MAILTO:corprel@host.com
1027 19990104T140000Z
1028 19990104T220000Z
1029 Annual Stockholders Meeting
1030 One Corporate Drive, Wilmington, DL
1031 MAILTO:mrbig@host.com
1032 MAILTO:stockholders@host.com
1034
1035 - Business
1036 - Meeting
1037 - Special Occasion
1038
1039 FREQ=YEARLY;COUNT=5;BYDAY=1MO
1040
1041
1042
1044 3.9 Assign a to-do
1046 The following is a snippet of an iCalendar XML document that assigns
1047 a to-do.
1049
1050
1053
1054 19990104T133402@ical1.host.com
1055 19990104T133410Z
1056 19990104
1057 19990129
1058 MAILTO:dboss@host.com
1059 Periodic Self Review
1060 Complete your self review.
1061 Contact me if you questions.
1062 1
1063 CONFIDENTIAL
1064 MAILTO:dilbert@host.com
1065
1066
1067
1069 3.10 Publish a journal entry
1071 The following is a snippet of an iCalendar XML document that
1072 publishes a journal entry.
1074
1075
1078
1079 19990104T170003@ical1.host.com
1080 19990104T170001Z
1081 19990104
1082 MAILTO:corprel@host.com
1083 PUBLIC
1084 Year end report for Worldwide Calendar Company
1085 The complete report can be found at the Corporate website.
1086 http://www.host.com/annualreport
1087
1088 - Annual Report
1089 - Business
1090
1091
1092
1093
1095 3.11 Publish busy time
1097 The following is an iCalendar XML document that publishes busy time
1098 information. The default value for the "method" attribute is
1099 "PUBLISH" and does not need to be specified in this example.
1101
1102
1106 ]>
1108
1109
1111
1112 19980313T133000@ical1.host.com
1113 19990104T133010Z
1114 MAILTO:jsmith@host.com
1115 19980313T141711Z
1116 19980410T141711Z
1117
1118 19980314T233000Z/19980315T003000Z
1119 19980316T153000Z/19980316T163000Z
1120 19980318T030000Z/19980318T040000Z
1121
1122
1123
1125 3.12 Request busy time
1127 The following is a snippet of an iCalendar XML document that requests
1128 a calendar user's busy time information.
1130
1131
1134
1135 19970901T083000@ical1.host.com
1136 19970901T083000Z
1137 MAILTO:jane_doe@host1.com
1138 19971015T050000Z
1139 19971016T050000Z
1140 MAILTO:john_public@host2.com
1141
1142
1143
1145 3.13 Response to a busy time request
1147 The following is an iCalendar XML document that responds to request
1148 for busy time information.
1150
1151
1154 ]>
1156
1157
1160
1161 19970901T083000@ical1.host.com
1162 19970901T100000Z
1163 MAILTO:jane_doe@host1.com
1164
1165 MAILTO:john_public@host2.com
1166 19971015T050000Z/PT8H30M,
1167 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
1168
1169
1170
1172 3.14 Published event that references time zone information
1174 The following is a snippet of an iCalendar XML document that
1175 publishes calendar information about an event that includes date/time
1176 values that reference a time zone definition.
1178
1179
1181
1182 US-Eastern
1183
1184 19981025T020000
1185 -0400
1186 0500
1187 19981025T020000
1188 EST
1189
1190
1191 19990404T020000
1192 -0500
1193 -0400
1194 19990404T020000
1195 EDT
1196
1197
1198
1199 19980309T231000Z
1200 guid-1.host1.com
1201 19980312T083000
1202 19980312T093000
1203 MAILTO:mrbig@host.com
1204 Project XYZ Review Meeting
1205 PUBLIC
1206 XYZ Project Review
1207 1CP Conference Room 4350
1208
1209 - Meeting
1210
1211 MAILTO:employee-@host.com
1214
1215
1216
1217
1219 3.15 An event with an alarm
1221 The following is an iCalendar XML with associated alarms. The event
1222 specifies alarm definitions for a "display", "audio", "email" and
1223 "procedure" type of alarms. The "method" attribute isn't specified
1224 since it is the default value.
1226
1227
1231
1232
1234
1235 ]>
1236
1237
1239
1240 19990104T130000@host.com
1241 19990104T130100Z
1242 19990704T230000Z
1243 19970705T040000Z
1244 Firework Celebration
1245
1246 - Holiday
1247 - Special Occasion
1248
1249
1250 DISPLAY
1251 Firework Celebration Tonight at
1252 6 PM !!!
1253 19990704T224500Z
1254 2
1255 PT15M
1256
1257
1258 AUDIO
1259 19990704T224500Z
1260 2
1261 PT15M
1262
1263
1264
1265 EMAIL
1266 Firework Celebration Tonight
1267 at 6 PM on Channel 6!!!
1268 *** Firework Celebration On TV ***
1269 19990704T224500Z
1270 MAILTO:PIN1234@pager.host.com
1272
1273
1274 PROCEDURE
1275
1276 19990704T230000Z
1277
1278
1279
1280
1282 4. iCalendar XML Document Type Definition
1284 The following DTD conforms to XML version 1.0, as specified by [XML].
1286
1288
1289
1290
1292
1296
1300
1303
1304
1305
1307
1310
1312
1315
1317
1320
1322
1325
1327
1330
1331
1332
1334
1337
1339
1342
1344
1347
1348
1349
1351
1352
1353
1354
1355
1356
1357
1359
1362
1363
1365
1368
1370
1373
1374
1376
1379
1380
1381
1383
1386
1388
1391
1393
1396
1398
1402
1408
1409
1414
1416
1422
1424
1429
1431
1435
1437
1441
1443
1447
1449
1452
1453
1455
1458
1460
1463
1465
1468
1469
1471
1474
1476
1479
1481
1484
1486
1489
1491
1494
1496
1499
1500
1502
1505
1507
1511
1514
1515
1518
1519
1521
1525
1528
1530
1533
1534
1536
1539
1540
1542
1545
1546
1548
1553
1556
1558
1561
1562
1564
1567
1568
1572
1573
1574
1576
1580
1582
1584
1587
1589
1592
1595
1597
1599
1602
1605
1607
1609
1611
1614
1616
1617
1618
1620
1621
1623
1625
1626
1627
1628
1630
1631
1634
1635
1639
1641
1642
1646
1647
1651
1652
1657
1658
1663
1665
1666
1667
1669
1670
1671
1673
1674
1679
1680
1683
1684
1687
1688
1693
1694
1698
1699
1701
1702
1707
1709
1710
1713
1714
1718
1719
1723
1724
1727
1728
1731
1732
1736
1737
1739
1741
1743
1744
1747
1748
1752
1753
1756
1757
1760
1761
1764
1766
1767
1781
1782
1787
1788
1795
1796
1801
1802
1806
1807
1809
1810
1813
1815
1816
1820
1821
1824
1825
1829
1830
1833
1835
1836
1838
1840
1841
1844
1845
1849
1850
1852
1853
1856
1857
1860
1861
1864
1865
1868
1870
1871
1875
1877
1879
1880
1888
1889
1890
1891
1893
1894
1896
1897
1899
1900
1902
1903
1904
1905
1908
1910
1912
1915 5. Acknowledgments
1917 The following have participated in the drafting and discussion of
1918 this memo:
1920 Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert,
1921 Thomas Rowe.
1923 6. IANA Considerations
1925 This document defines a XML Formal Public Identifier (FPI), based on
1926 a format defined in [ISO 9070], that identifies a XML document type
1927 corresponding to this memo. Publication of this memo constitutes
1928 registration of this identifier.
1930 In addition, this memo defines the XML FPIs corresponding to each of
1931 the value types specified in [RFC 2445].
1933 7. Security Considerations
1935 CDATA Sections - - A XML iCalendar document may contain CDATA
1936 sections to represent content for specific element types. The CDATA
1937 section specifies arbitrary character data that is not meant to be
1938 interpretted. It is not scanned by the XML parser for markup. While
1939 this memo restricts that any CDATA section MUST NOT contain markup or
1940 other such alternate representation for the property value, in
1941 general, CDATA section from a non-conformant implementation can
1942 contain content such as HTML markup. HTML text can be used to invoke
1943 programs. Implementors should be aware that this may leave an
1944 implementation open to malicious attack that might occur as a result
1945 of executing the markup in the CDATA section.
1947 PROCEDURAL ALARMS - - A XML iCalendar document can be created that
1948 contains a "VEVENT" and "VTODO" calendar component with "VALARM"
1949 calendar components. The "VALARM" calendar component can be of type
1950 PROCEDURE and can have an attachment containing some sort of
1951 executable program. Implementations that incorporate these types of
1952 alarms are subject to any virus or malicious attack that might occur
1953 as a result of executing the attachment.
1955 ATTACHMENTS - - A XML iCalendar document can include references to
1956 Uniform Resource Locators that can be programmed resources.
1957 Implementers and users of this memo should be aware of the network
1958 security implications of accepting and parsing such information.
1960 In addition, the security considerations observed by implementations
1961 of electronic mail systems should be followed for this memo.
1963 8. Bibliography
1965 [FPI] F. Dawson, "iCalendar Formal Public Identifier", Internet
1966 Draft, http://www.internic.net/internet-drafts/draft-calsch-icalfpi-
1967 00.txt, September 1998.
1969 [ISO9070] "Information Technology_SGML Support Facilities_
1970 Registration Procedures for Public Text Owner Identifiers", ISO/IEC
1971 9070, Second Edition, International Organization for Standardization,
1972 April 1991.
1974 [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail
1975 Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC
1976 2045, November 1996.
1978 [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
1979 Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt,
1980 March 1997.
1982 [RFC 2445] F. Dawson and D. Stenerson, "Internet Calendaring and
1983 Scheduling Core Object Specification (iCalendar)", RFC 2445, http://
1984 www.ietf.org/rfc/rfc2445.txt, November 1998.
1986 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium,
1987 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
1989 [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium,
1990 http://www.w3.org/TR/1998/REC-xml-19980210, February 1998.
1992 Authors' Addresses
1994 Frank Dawson
1995 Nokia Corporation
1997 Phone: +1 (972) 894 4083
1998 EMail: frank.dawson@nokia.com
1999 Surendra K. Reddy
2000 Oracle
2001 M/S 6op3
2002 500 Oracle Parkway
2003 Redwoodshores, CA 94065
2004 US
2006 Phone: +1 (650) 506 5441
2007 Fax: +1 (650) 654 6205
2008 EMail: skreddy@us.oracle.com
2010 Doug Royer
2011 INET-Consulting LLC
2012 1795 W. Broadway #266
2013 Idaho Falls, ID 83402
2014 US
2016 Phone: +1 (208) 520 4044
2017 Fax: +1 (208) 552 1179
2018 EMail: doug@royer.com
2020 Eric R. Plamondon
2021 Oracle
2022 2000 Peel Street, 4th Floor
2023 Montreal, QC H3A 2W5
2024 Canada
2026 Phone: +1 (514) 733 8500
2027 Fax: +1 (514) 733 8878
2028 EMail: ericp@steltor.com
2030 Full Copyright Statement
2032 Copyright (C) The Internet Society (2002). All Rights Reserved.
2034 This document and translations of it may be copied and furnished to
2035 others, and derivative works that comment on or otherwise explain it
2036 or assist in its implementation may be prepared, copied, published
2037 and distributed, in whole or in part, without restriction of any
2038 kind, provided that the above copyright notice and this paragraph are
2039 included on all such copies and derivative works. However, this
2040 document itself may not be modified in any way, such as by removing
2041 the copyright notice or references to the Internet Society or other
2042 Internet organizations, except as needed for the purpose of
2043 developing Internet standards in which case the procedures for
2044 copyrights defined in the Internet Standards process must be
2045 followed, or as required to translate it into languages other than
2046 English.
2048 The limited permissions granted above are perpetual and will not be
2049 revoked by the Internet Society or its successors or assigns.
2051 This document and the information contained herein is provided on an
2052 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
2053 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
2054 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
2055 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
2056 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
2058 Acknowledgement
2060 Funding for the RFC Editor function is currently provided by the
2061 Internet Society.