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.