From 792b1a5083478782dbd435ff025bd97b8069ecb8 Mon Sep 17 00:00:00 2001 From: Andrew McMillan Date: Mon, 4 Sep 2006 23:11:31 +1200 Subject: [PATCH] Initial commit --- caldav.session | 12 + caldav.webprj | 27 + config/config.php | 15 + dba/caldav.sql | 14 + dba/create-database.sh | 12 + dba/sample-data.sql | 6 + docs/IETF-CAP-RFC4324.txt | 7342 +++++++++++++++++ docs/draft-dawson-ical-xml-dtd-01.txt | 1368 ++++ docs/draft-ietf-calsch-many-xcal-02.txt | 2971 +++++++ docs/dusseault-caldav-12.txt.html | 6155 ++++++++++++++ docs/dusseault2005CalDAV.pdf | Bin 0 -> 313171 bytes docs/rfc2445.html | 8342 +++++++++++++++++++ docs/rfc2445.txt | 8291 +++++++++++++++++++ docs/rfc2518.html | 5109 ++++++++++++ docs/rfc2616.html | 9901 +++++++++++++++++++++++ htdocs/index.php | 47 + inc/always.php | 21 + inc/caldav-OPTIONS.php | 6 + inc/caldav-PUT.php | 105 + inc/caldav-REPORT.php | 108 + inc/iCalendar.php | 231 + testing/delete-meeting.txt | 4 + testing/full-options-response.txt | 7 + testing/sample-tcp-stream.txt | 87 + testing/schedule-meeting.txt | 77 + 25 files changed, 50258 insertions(+) create mode 100644 caldav.session create mode 100644 caldav.webprj create mode 100644 config/config.php create mode 100644 dba/caldav.sql create mode 100755 dba/create-database.sh create mode 100644 dba/sample-data.sql create mode 100644 docs/IETF-CAP-RFC4324.txt create mode 100644 docs/draft-dawson-ical-xml-dtd-01.txt create mode 100644 docs/draft-ietf-calsch-many-xcal-02.txt create mode 100644 docs/dusseault-caldav-12.txt.html create mode 100644 docs/dusseault2005CalDAV.pdf create mode 100644 docs/rfc2445.html create mode 100644 docs/rfc2445.txt create mode 100644 docs/rfc2518.html create mode 100644 docs/rfc2616.html create mode 100644 htdocs/index.php create mode 100644 inc/always.php create mode 100644 inc/caldav-OPTIONS.php create mode 100644 inc/caldav-PUT.php create mode 100644 inc/caldav-REPORT.php create mode 100644 inc/iCalendar.php create mode 100644 testing/delete-meeting.txt create mode 100644 testing/full-options-response.txt create mode 100644 testing/sample-tcp-stream.txt create mode 100644 testing/schedule-meeting.txt diff --git a/caldav.session b/caldav.session new file mode 100644 index 00000000..46c2be27 --- /dev/null +++ b/caldav.session @@ -0,0 +1,12 @@ + + + + + + + + + + + + diff --git a/caldav.webprj b/caldav.webprj new file mode 100644 index 00000000..fb072394 --- /dev/null +++ b/caldav.webprj @@ -0,0 +1,27 @@ + + + + + Andrew McMillan + andrew@catalyst.net.nz + -//W3C//DTD XHTML 1.0 Transitional//EN + + templates/ + toolbars/ + + + + + + + + + + + + + + + + + diff --git a/config/config.php b/config/config.php new file mode 100644 index 00000000..e713d200 --- /dev/null +++ b/config/config.php @@ -0,0 +1,15 @@ +domainname = "mycaldav.andrew"; + + if ( ! $dbconn = pg_Connect("port=5433 dbname=caldav user=general") ) { + if ( ! $dbconn = pg_Connect("port=5432 dbname=caldav user=general") ) { + echo "Database Error +

Database Error

+

Could not connect to PGPool or to Postgres

+ + "; + exit; + } + } + +?> \ No newline at end of file diff --git a/dba/caldav.sql b/dba/caldav.sql new file mode 100644 index 00000000..5ee0efc9 --- /dev/null +++ b/dba/caldav.sql @@ -0,0 +1,14 @@ +-- My CalDAV server - Database Schema +-- + +-- Use the usr, group and schema management stufffrom libawl-php +\i /usr/share/awl/dba/awl-tables.sql +\i /usr/share/awl/dba/schema-management.sql + +CREATE TABLE ics_event_data ( + user_no INT references usr(user_no), + ics_event_name TEXT, + ics_event_etag TEXT, + ics_raw_data TEXT +); + diff --git a/dba/create-database.sh b/dba/create-database.sh new file mode 100755 index 00000000..0623f04a --- /dev/null +++ b/dba/create-database.sh @@ -0,0 +1,12 @@ +#!/bin/sh +# +# Build the CalDAV database +# + +DBNAME="${1:-caldav}" + +createdb -E UTF8 "${DBNAME}" + +psql -f caldav.sql "${DBNAME}" + +psql -f sample-data.sql "${DBNAME}" diff --git a/dba/sample-data.sql b/dba/sample-data.sql new file mode 100644 index 00000000..dd2e4e0e --- /dev/null +++ b/dba/sample-data.sql @@ -0,0 +1,6 @@ +-- Some sample data to prime the database... + +INSERT INTO usr ( user_no, active, email_ok, updated, username, password, fullname, email ) + VALUES( 1, TRUE, current_date, current_date, 'andrew', '**x', 'Andrew McMillan', 'andrew@catalyst.net.nz' ); + +SELECT setval('usr_user_no_seq', 1); diff --git a/docs/IETF-CAP-RFC4324.txt b/docs/IETF-CAP-RFC4324.txt new file mode 100644 index 00000000..ba0a2884 --- /dev/null +++ b/docs/IETF-CAP-RFC4324.txt @@ -0,0 +1,7342 @@ +From: http://www.ietf.org/rfc4324.txt +Title: Calendar Access Protocol (CAP) +Reference: IETF Network Working Group, Experimental Request for Comments #4324 +Date: December 2005 + +See also: http://xml.coverpages.org/ni2003-12-31-a.html (CalDAV) + +======================================================================== + +Network Working Group D. Royer +Request for Comments: 4324 IntelliCal, LLC +Category: Experimental G. Babics + Oracle + S. Mansour + eBay + December 2005 + + + Calendar Access Protocol (CAP) + +Status of This Memo + + This memo defines an Experimental Protocol for the Internet + community. It does not specify an Internet standard of any kind. + Discussion and suggestions for improvement are requested. + Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2005). + +Abstract + + The Calendar Access Protocol (CAP) described in this memo permits a + Calendar User (CU) to utilize a Calendar User Agent (CUA) to access + an iCAL-based Calendar Store (CS). At the time of this writing, + three vendors are implementing CAP, but it has already been + determined that some changes are needed. In order to get + implementation experience, the participants felt that a CAP + specification is needed to preserve many years of work. Many + properties in CAP which have had many years of debate, can be used by + other iCalendar protocols. + + + + + + + + + + + + + + + + + + +Royer, et al. Experimental [Page 1] + +RFC 4324 Calendar Access Protocol December 2005 + + +Table of Contents + + 1. Introduction ....................................................5 + 1.1. Formatting Conventions .....................................5 + 1.2. Related Documents ..........................................6 + 1.3. Definitions ................................................7 + 2. Additions to iCalendar .........................................11 + 2.1. New Value Types (Summary) ................................14 + 2.1.1. New Parameters (summary) .............................14 + 2.1.2. New or Updated Properties (summary) ..................14 + 2.1.3. New Components (summary) .............................17 + 2.2. Relationship of RFC-2446 (ITIP) to CAP ...................18 + 3. CAP Design .....................................................20 + 3.1. System Model ..............................................20 + 3.2. Calendar Store Object Model ...............................20 + 3.3. Protocol Model ............................................21 + 3.3.1. Use of BEEP, MIME, and iCalendar .....................22 + 4. Security Model .................................................23 + 4.1. Calendar User and UPNs ....................................23 + 4.1.1. UPNs and Certificates ................................24 + 4.1.2. Anonymous Users and Authentication ...................25 + 4.1.3. User Groups ..........................................25 + 4.2. Access Rights .............................................26 + 4.2.1. Access Control and NOCONFLICT ........................26 + 4.2.2. Predefined VCARs .....................................26 + 4.2.3. Decreed VCARs ........................................28 + 4.3. CAP Session Identity ......................................28 + 5. CAP URL and Calendar Address ...................................29 + 6. New Value Types ................................................30 + 6.1. Property Value Data Types .................................30 + 6.1.1. CAL-QUERY Value Type .................................30 + 6.1.1.1. [NOT] CAL-OWNERS() ..............................36 + 6.1.1.2. CURRENT-TARGET() ................................37 + 6.1.1.3. PARAM() .........................................37 + 6.1.1.4. SELF() ..........................................38 + 6.1.1.5. STATE() .........................................38 + 6.1.1.6. Use of Single Quote .............................38 + 6.1.1.7. Comparing DATE and DATE-TIME Values .............39 + 6.1.1.8. DTEND and DURATION ..............................40 + 6.1.1.9. [NOT] LIKE ......................................40 + 6.1.1.10. Empty vs. NULL .................................41 + 6.1.1.11. [NOT] IN .......................................41 + 6.1.1.12. DATE-TIME and TIME Values in a WHERE Clause ....42 + 6.1.1.13. Multiple Contained Components ..................43 + 6.1.1.14. Example, Query by UID ..........................43 + 6.1.1.15. Query by Date-Time Range .......................43 + 6.1.1.16. Query for All Unprocessed Entries ..............44 + 6.1.1.17. Query with Subset of Properties by Date/Time ...44 + + + +Royer, et al. Experimental [Page 2] + +RFC 4324 Calendar Access Protocol December 2005 + + + 6.1.1.18. Query with Components and Alarms in A Range ....45 + 6.1.2. UPN Value Type .......................................45 + 6.1.3. UPN-FILTER Value .....................................46 + 7. New Parameters .................................................48 + 7.1. ACTION Parameter ..........................................48 + 7.2. ENABLE Parameter ..........................................48 + 7.3. ID Parameter ..............................................49 + 7.4. LATENCY Parameter .........................................50 + 7.5. LOCAL Parameter ...........................................50 + 7.6. LOCALIZE Parameter ........................................51 + 7.7. OPTIONS Parameter .........................................52 + 8. New Properties .................................................52 + 8.1. ALLOW-CONFLICT Property ...................................52 + 8.2. ATT-COUNTER Property ......................................53 + 8.3. CALID Property ............................................54 + 8.4. CALMASTER Property ........................................54 + 8.5. CAP-VERSION Property ......................................55 + 8.6. CARID Property ............................................55 + 8.7. CAR-LEVEL Property ........................................56 + 8.8. COMPONENTS Property .......................................56 + 8.9. CSID Property .............................................58 + 8.10. DECREED Property .........................................58 + 8.11. DEFAULT-CHARSET Property .................................59 + 8.12. DEFAULT-LOCALE Property ..................................60 + 8.13. DEFAULT-TZID Property ....................................61 + 8.14. DEFAULT-VCARS Property ...................................62 + 8.15. DENY Property ............................................62 + 8.16. EXPAND property ..........................................63 + 8.17. GRANT Property ...........................................64 + 8.18. ITIP-VERSION Property ....................................64 + 8.19. MAX-COMP-SIZE Property ...................................65 + 8.20. MAXDATE Property .........................................65 + 8.21. MINDATE Property .........................................66 + 8.22. MULTIPART Property .......................................66 + 8.23. NAME Property ............................................67 + 8.24. OWNER Property ...........................................68 + 8.25. PERMISSION Property ......................................68 + 8.26. QUERY property ...........................................69 + 8.27. QUERYID property .........................................70 + 8.28. QUERY-LEVEL Property .....................................70 + 8.29. RECUR-ACCEPTED Property ..................................71 + 8.30. RECUR-LIMIT Property .....................................71 + 8.31. RECUR-EXPAND Property ....................................72 + 8.32. RESTRICTION Property .....................................72 + 8.33. SCOPE Property ...........................................73 + 8.34. STORES-EXPANDED Property .................................74 + 8.35. TARGET Property ..........................................74 + 8.36. TRANSP Property ..........................................75 + + + +Royer, et al. Experimental [Page 3] + +RFC 4324 Calendar Access Protocol December 2005 + + + 9. New Components .................................................76 + 9.1. VAGENDA Component .........................................76 + 9.2. VCALSTORE Component .......................................78 + 9.3. VCAR Component ............................................80 + 9.4. VRIGHT Component ..........................................82 + 9.5. VREPLY Component ..........................................83 + 9.6. VQUERY Component ..........................................83 + 10. Commands and Responses ........................................85 + 10.1. CAP Commands (CMD) .......................................85 + 10.2. ABORT Command ............................................88 + 10.3. CONTINUE Command .........................................89 + 10.4. CREATE Command ...........................................90 + 10.5. DELETE Command ...........................................96 + 10.6. GENERATE-UID Command .....................................98 + 10.7. GET-CAPABILITY Command ..................................100 + 10.8. IDENTIFY Command ........................................103 + 10.9. MODIFY Command ..........................................105 + 10.10. MOVE Command ...........................................110 + 10.11. REPLY Response to a Command ............................112 + 10.12. SEARCH Command .........................................113 + 10.13. SET-LOCALE Command .....................................116 + 10.14. TIMEOUT Command ........................................118 + 10.15. Response Codes .........................................118 + 11. Object Registration ..........................................120 + 11.1. Registration of New and Modified Entities ...............120 + 11.2. Post the Item Definition ................................120 + 11.3. Allow a Comment Period ..................................120 + 11.4. Release a New RFC .......................................120 + 12. BEEP and CAP .................................................120 + 12.1. BEEP Profile Registration ...............................120 + 12.2. BEEP Exchange Styles ....................................123 + 12.3. BEEP Connection Details .................................123 + 13. IANA Considerations ..........................................125 + 14. Security Considerations ......................................125 + Appendix A. Acknowledgements ....................................127 + Appendix B. References ..........................................127 + Appendix B.1. Normative References ..........................127 + Appendix B.2. Informative References ........................128 + + + + + + + + + + + + + +Royer, et al. Experimental [Page 4] + +RFC 4324 Calendar Access Protocol December 2005 + + +1. Introduction + + This document specifies the Calendar Access Protocol (CAP). CAP + permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) + to access an iCAL-based Calendar Store (CS) and manage calendar + information. In particular, the document specifies how to query, + create, modify, and delete iCalendar components (e.g., events, to- + dos, or daily journal entries). It further specifies how to search + for available busy time information. Synchronization with CUAs is + not covered, but it is believed to be possible using CAP. + + At the time of this writing, three vendors are implementing CAP. It + has already been determined that some changes are needed. In order + to get implementation experience, the participants felt that a CAP + specification is needed to preserve many years of work. Many + properties in CAP can be used by other iCalendar protocols and have + had many years of debate. + + CAP is specified as a BEEP (Block Extensible Exchange Protocol) + "profile" [BEEP] [BEEPGUIDE]. Many aspects of the protocol (e.g., + authentication and privacy) are provided within BEEP. The protocol + data units of CAP leverage the standard iCalendar format iCAL [iCAL] + to convey calendar-related information. + + CAP can also be used to store and fetch iCalendar Transport- + Independent Interoperability Protocol (iTIP) objects [iTIP]. iTIP + objects used are exactly as defined in [iTIP]. When iCalendar + objects are transferred between the CUA and a CS, some additional + properties and parameters may be added; the CUA is responsible for + correctly generating iCalendar objects to non-CAP processes. + + The definition of new components, properties, parameters, and value + types are broken into two parts. The first part summarizes and + defines the new objects. The second part provides detail and ABNF + for those objects. The ABNF rules for CAP, as for other iCalendar + specifications, are order-independent. That is, properties in a + component may occur in any order, and parameters in any property may + occur in any order. + +1.1. Formatting Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Calendaring and scheduling roles are referred to in quoted-strings of + text with the first character of each word in upper case. For + example, "Organizer" refers to a role of a "Calendar User" (CU) + + + +Royer, et al. Experimental [Page 5] + +RFC 4324 Calendar Access Protocol December 2005 + + + within the protocol defined by [iTIP]. Calendar components defined + by [iCAL] are referred to with capitalized, quoted-strings of text. + All iCalendar components should start with the letter "V". For + example, "VEVENT" refers to the event calendar component, "VTODO" + refers to the to-do component, and "VJOURNAL" refers to the daily + journal component. + + Scheduling methods defined by [iTIP] are referred to with + capitalized, quoted-strings of text. For example, "REPLY" refers to + the method for replying to a "REQUEST". + + CAP commands are referred to by upper-case, quoted-strings of text, + followed by the word "command". For example, '"CREATE" command' + refers to the command for creating a calendar entry, '"SEARCH" + command' refers to the command for reading calendar components. CAP + commands are named using the "CMD" property. + + Properties defined by this memo are referred to with capitalized, + quoted-strings of text, followed by the word "property". For + example, '"ATTENDEE" property' refers to the iCalendar property used + to convey the calendar address that has been invited to a "VEVENT" or + "VTODO" component. + + Property parameters defined by this memo are referred to with + capitalized, quoted-strings of text, followed by the word + "parameter". For example, "PARTSTAT" parameter refers to the + iCalendar property parameter used to specify the participation status + of an attendee. Enumerated values defined by this memo are referred + to with capitalized text, either alone or followed by the word + "value". + + Object states defined by this memo are referred to with capitalized, + quoted-strings of text, followed by the word "state". For example, + '"BOOKED" state' refers to an object in the booked state. + + Within a query, the different parts are referred to as a "clause" and + its value as "clause value" and the clause name will be in uppercase + enclosed in quotes, for example, 'The "SELECT" claus' or 'if the + "SELECT" clause value contains ...'. + + In tables, the quoted-string text is specified without quotes in + order to minimize the table length. + +1.2. Related Documents + + Implementers will need to be familiar with several other memos that, + along with this one, describe the Internet calendaring and scheduling + standards. These documents are as follows. + + + +Royer, et al. Experimental [Page 6] + +RFC 4324 Calendar Access Protocol December 2005 + + + [iCAL] (RFC2445) specifies the objects, data types, properties and + property parameters used in the protocols, along with the + methods for representing and encoding them. + + [iTIP] (RFC2446) specifies an interoperability protocol for + scheduling between different installations. + + [iMIP] (RFC2447) specifies the Internet email binding for [iTIP]. + + [GUIDE] (RFC3283) is a guide to implementers and describes the + elements of a calendaring system, how they interact with each + other, how they interact with end users, and how the standards + and protocols are used. + + This memo does not attempt to repeat the specification of concepts + and definitions from these earlier memos. Where possible, references + are made to the memo that provides the specification of these + concepts and definitions. + +1.3 Definitions + + UNPROCESSED, BOOKED, DELETED - A conceptual state of an object in + the calendar store. There are three conceptual states: + "UNPROCESSED" state, "BOOKED" state, and marked for deletion, + which is the "DELETED" state. How the implementation stores the + state of any object is not a protocol issue and is not discussed. + An object can be said to be booked, unprocessed, or marked for + deletion. + + 1. An "UNPROCESSED" state scheduling object has been stored in + the calendar store but has not been acted on by a CU or CUA. + All scheduled entries are [iTIP] objects. No [iTIP] objects + in the store are in the "BOOKED" state. To retrieve any + [iTIP] object, simply do a query asking for any objects that + are stored in the "UNPROCESSED" state. + + 2. A "BOOKED" state entry is stored with the "CREATE" command. + It is an object that has been acted on by a CU or CUA and + there has been a decision to store an object. To retrieve any + booked object, simply do a query asking for any objects that + were stored in the "BOOKED" state. + + 3. A "DELETED" state entry is created by sending a "DELETE" + command with the "OPTION" parameter value set to "MARK". To + retrieve any deleted object, simply do a query asking for any + objects that were stored in the "DELETED" state. By default + objects marked for delete are not returned. The CUA must + specifically ask for marked-for-deletion objects. You cannot + + + +Royer, et al. Experimental [Page 7] + +RFC 4324 Calendar Access Protocol December 2005 + + + ask for components in the "DELETED" state and in other states + in the same "VQUERY" component, as there would be no way to + distinguish between them in the reply. + + Calendar - A collection of logically related objects or entities + each of which may be associated with a calendar date and possibly + time of day. These entities can include calendar properties or + components. In addition, a calendar might be related to other + calendars with the "RELATED-TO" property. A calendar is + identified by its unique calendar identifier. The [iCAL] defines + the initial calendar properties, calendar components and + properties that make up the contents of a calendar. + + Calendar Access Protocol (CAP) - The Internet protocol that permits + a CUA to access and manipulate calendars residing on a Calendar + Store. (This memo.) + + Calendar Access Rights (VCAR) - The mechanism for specifying the CAP + operations ("PERMISSION") that a particular calendar user ("UPN", + defined below) is granted or denied permission to perform on a + given calendar object ("SCOPE"). The calendar access rights are + specified with a "VCAR" component. (Section 9.3) + + Calendar Address - Also see Calendar URL, which is the same as a CAP + address. The calendar address can also be the value to the + "ATTENDEE" and "ORGANIZER" properties, as defined in [iCAL]. + Calendar URL - A calendar URL is a URL, defined in this memo, + that specifies the address of a CS or Calendar. + + Component - Any object that conforms to the iCalendar object format + and that is either defined in an Internet Draft, registered with + IANA, or is an experimental object that is prefixed with "x-". + Some types of components include calendars, events, to-dos, + journals, alarms, and time zones. A component consists of + properties and possibly other contained components. For example, + an event may contain an alarm component. + + Container - This is a generic name for VCALSTORE or VAGENDA. + + Properties - An attribute of a particular component. Some + properties are applicable to different types of components. For + example, the "DTSTART" property is applicable to the "VEVENT", + "VTODO", and "VJOURNAL" components. Other components are + applicable only to an individual type of calendar component. For + example, the "TZURL" property may only be applicable to the + "VTIMEZONE" components. + + + + + +Royer, et al. Experimental [Page 8] + +RFC 4324 Calendar Access Protocol December 2005 + + + Calendar Identifier (CALID) - A globally unique identifier + associated with a calendar. Calendars reside within a CS. See + Qualified Calendar Identifier and Relative Calendar Identifier. + All CALIDs start with "cap:". + + Calendar Policy - A CAP operational restriction on the access or + manipulation of a calendar. These may be outside the scope of the + CAP protocol. An example of an implementation or site policy is, + "events MUST be scheduled in unit intervals of one hour". + + Calendar Property - An attribute of a calendar ("VAGENDA"). The + attribute applies to the calendar, as a whole. For example, the + "CALSCALE" property specifies the calendar scale (e.g., the + "GREGORIAN" value) for the all entries within the calendar. + + Calendar Store (CS) - The data and service model definitions for a + Calendar Store as defined in this memo. This memo does not + specify how the CS is implemented. + + Calendar Server - An implementation of a Calendar Store (CS) that + manages one or more calendars. + + Calendar Store Identifier (CSID) - The globally unique identifier + for an individual CS. A CSID consists of the host and port + portions of a "Common Internet Scheme Syntax" part of a URL, as + defined by [URL]. The CSID excludes any reference to a specific + calendar. (Section 8.9) + + Calendar Store Components - Components maintained in a CS specify a + grouping of calendar store-wide information. + + Calendar Store Properties - Properties maintained in a Calendar + Store represent store-wide information. + + Calendar User (CU) - An entity (often biological) that uses a + calendaring system. + + Calendar User Agent (CUA) - The client application that a CU + utilizes to access and manipulate a calendar. + + CAP Session - An open communication channel between a CUA and a CS. + If the CAP session is authenticated, the CU is "authenticated" and + it is an "authenticated CAP session". + + Contained Component / Contained Properties - A component or property + that is contained inside of another component. For example, a + "VALARM" component may be contained inside a "VEVENT" component, + + + + +Royer, et al. Experimental [Page 9] + +RFC 4324 Calendar Access Protocol December 2005 + + + and a "TRIGGER" property could be a contained property of a + "VALARM" component. + + Delegate - A CU (sometimes called the delegatee) who has been + assigned participation in a scheduled component (e.g., VEVENT) by + one of the attendees in the scheduled component (sometimes called + the delegator). An example of a delegate is a team member told to + go to a particular meeting in place of another invitee who is + unable to attend. + + Designate - A CU who is authorized to act on behalf of another CU. + An example of a designate is an assistant. + + Experimental - The CUA and CS may implement experimental extensions + to the protocol. They might also have experimental components, + properties, and parameters. These extensions MUST start with "x-" + (or "X-") and should include a vendor prefix (such as "x- + myvendor-"). There is no guarantee that these experimental + extensions will interoperate with other implementations. There is + no guarantee that they will not interact in unpredictable ways + with other vendor experimental extensions. There is no guarantee + that the same specific experimental extension is not used by + multiple vendors in incompatible ways. Implementations should + limit sending those extensions to other implementations. + + Object - A generic name for any component, property, parameter, or + value type to be used in iCalendar. + + Overlapped Booking - A policy that indicates whether or not + components with a "TRANSP" property not set to "TRANSPARENT- + NOCONFLICT" or "OPAQUE-NOCONFLICT" value can overlap one another. + When the policy is applied to a calendar it indicates whether or + not the time span of any component (VEVENT, VTODO, ...) in the + calendar can overlap the time span of any other component in the + same calendar. When applied to an individual object, it indicates + whether or not any other component's time span can overlap that + individual component. If the CS does not allow overlapped + booking, then the CS is unwilling to allow any overlapped bookings + within any calendar or entry in the CS. + + Owner - One or more CUs or UGs that are listed in the "OWNER" + property in a calendar. There can be more than one owner. + + Qualified Calendar Identifier (Qualified CALID) - A CALID in which + both the scheme and CSID of the CAP URI are present. + + Realm - A collection of calendar user accounts, identified by a + string. The name of the Realm is only used in UPNs. In order to + + + +Royer, et al. Experimental [Page 10] + +RFC 4324 Calendar Access Protocol December 2005 + + + avoid namespace conflict, the Realm SHOULD be postfixed with an + appropriate DNS domain name (e.g., the foobar Realm could be + called foobar.example.com). + + Relative Calendar Identifier (Relative CALID) - An identifier for an + individual calendar in a calendar store. It MUST be unique within + a calendar store. A Relative CALID consists of the "URL path" of + the "Common Internet Scheme Syntax" portion of a URL, as defined + by [URI] and [URLGUIDE]. + + Session Identity - A UPN associated with a CAP session. A session + gains an identity after successful authentication. The identity + is used in combination with VCAR to determine access to data in + the CS. + + User Group (UG) - A collection of Calendar Users and/or User Groups. + These groups are expanded by the CS and may reside either locally + or in an external database or directory. The group membership may + be fixed or dynamic over time. + + Username - A name that denotes a Calendar User within a Realm. This + is part of a UPN. + + User Principal Name (UPN) - A unique identifier that denotes a CU or + a group of CUs. (Section 6.1.2) + +2. Additions to iCalendar + + Several new components, properties, parameters, and value types are + added in CAP. This section summarizes those new objects. + + This memo extends the properties that can go into 'calprops' as + defined in [iCAL] section 4.6 page 51, to allow [iTIP] objects + transmitted between a CAP aware CUA and the CS to contain the + "TARGET" and "CMD" properties. This memo also adds to the [iCAL] + ABNF to allow IANA and experimental extensions. This memo does not + address how a CUA transmits [iTIP] or [iMIP] objects to non-CAP + programs. What follows is ABNF, as described in [ABNF]. + + calprops= 2*( + + ; 'prodid' and 'version' are both REQUIRED, + ; but MUST NOT occur more than once. + ; + prodid /version / + ; + ; These are optional, but MUST NOT occur + ; more than once. + + + +Royer, et al. Experimental [Page 11] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; + calscale / + method / + cmd / + ; + ; Target is optional, and may occur more + ; than once. + ; + target / other-props ) + ; + other-props = *(x-prop) *(iana-prop) *(other-props) + ; + iana-prop = ; Any property registered by IANA directly or + ; included in an RFC that may be applied to + ; the component and within the rules published. + ; + x-prop = ; As defined in [iCAL]. + ; + methodp = ; As defined in [iCAL]. + ; + prodid = ; As defined in [iCAL]. + ; + calscale = ; As defined in [iCAL]. + ; + + Another change is that the 'component' part of the 'icalbody' ABNF as + described in [iCAL] section 4.6 is optional when sending a command, + as shown in the following updated ABNF: + + icalbody = calprops component + + ; If the "VCALENDAR" component contains the "CMD" + ; property then the 'component' is optional: + ; + / calprops ; Which MUST include a "CMD" property + ; + component = ; As defined in [iCAL]. + + In addition, a problem exists with the control of "VALARM" components + and their "TRIGGER" properties. A CU may wish to set its own alarms + (local alarms) on components. These local alarms are not to be + forwarded to other CUs, CUAs, or CSs. Similarly, the "SEQUENCE" + property and the "ENABLE" parameter in local alarms are not to be + forwarded to other CUs, CUAs, or CSs. Therefore, for the protocol + between a CUA and a CS, the following changes from [iCAL] section + 4.6.6 page 67 apply to the CAP protocol: + + alarmc = "BEGIN" ":" "VALARM" CRLF + + + +Royer, et al. Experimental [Page 12] + +RFC 4324 Calendar Access Protocol December 2005 + + + alarm-seq + other-props + (audioprop / dispprop / emailprop / procprop) + "END" ":" "VALARM" CRLF + ; + emailprop = ; As defined in [iCAL] + ; + procprop = ; As defined in [iCAL] + ; + dispprop = ; As defined in [iCAL] + ; + audioprop = ; As defined in [iCAL] + ; + alarm-seq = "SEQUENCE" alarmseqparams ":" posint0 CRLF + ; + alarmseqparams = other-params [";" local-param] other-params + ; + ; Where DIGIT is defined in [iCAL] + ; + posint0 = 1*DIGIT + posint1 = posintfirst 1*DIGIT + ; + ; A number starting with 1 through 9. + ; + posintfirst = %x31-39 + ; + other-params = *(";" xparam) *(";" iana-params) + *(";" other-params) + ; + iana-params = ; Any parameter registered by IANA directly or + ; included in an RFC that may be applied to + ; the property and within the rules published. + ; + xparam ; As defined in [iCAL]. + ; + + The CUA adds a "SEQUENCE" property to each "VALARM" component as it + books the component. This property, along with the "LOCAL" and + "ENABLE" parameters, allows the CUA to uniquely identify any VALARM + in any component. The CUA should remove those before forwarding to + non-CAP-aware CUAs. + + In addition, if a CUA wished to ignore a "TRIGGER" property in a + "VALARM" component that was supplied to it by the "Organizer", the + CUA needs a common way to tag that trigger as disabled. So the + following is a modification to [iCAL] section 4.8.6.3 page 127: + + trigger = "TRIGGER" 1*(";" enable-param) (trigrel / trigabs) + + + +Royer, et al. Experimental [Page 13] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; + trigrel = ; As defined in [iCAL]. + ; + trigabs = ; As defined in [iCAL]. + + See Section 7.2 and Section 7.5. + +2.1. New Value Types (Summary) + + UPN: The UPN value type is a text value type restricted to only UPN + values (see Section 6.1.2). + + UPN-FILTER: Like the UPN value type, but also includes filter rules + that allow wildcards (see Section 6.1.3). + + CALQUERY: The "CAL-QUERY" value type is a query syntax that is used + by the CUA to specify the rules that apply to a CAP command (see + Section 6.1.1). + +2.1.1. New Parameters (summary) + + ACTION - The "ACTION" parameter informs the endpoint if it should + abort or ask to continue on timeout. (Section 7.1) + + ENABLE - The "ENABLE" parameter in CAP is used to tag a property in + a component as disabled or enabled. (Section 7.2) + + ID - The "ID" parameter specifies a unique identifier to be used for + any outstanding commands. + + LATENCY - The "LATENCY" parameter supplies the timeout value for + command completion to the other endpoint. (Section 7.4) + + LOCAL - The "LOCAL" parameter in CAP is used to tag a property in a + component to signify that the component is local or to be + distributed. (Section 7.5) + + LOCALIZE - The "LOCALIZE" parameter specifies the locale to be used + in error and warning messages. + + OPTIONS - The "OPTIONS" parameter passes optional information for + the command being sent. + +2.1.2. New or Updated Properties (summary) + + ALLOW-CONFLICT - Some entries in a calendar might not be valid if + other entries were allowed to overlap the same time span. + (Section 8.1) + + + +Royer, et al. Experimental [Page 14] + +RFC 4324 Calendar Access Protocol December 2005 + + + ATT-COUNTER - When storing a "METHOD" property with the "COUNTER" + method, there needs to be a way to remember the "ATTENDEE" value + that sent the COUNTER. (Section 8.2) + + CAP-VERSION - The version of CAP that the implementation supports. + (Section 8.5) + + CAR-LEVEL - The level of calendar access supported. (Section 8.7) + + COMPONENTS - The list of components supported. (Section 8.8) + + CSID - The Calendar Store IDentifier (CSID) uniquely identifies a + CAP server. (Section 8.9) + + CALID - Each calendar within a CS needs to be uniquely identifiable. + The "CALID" property identifies a unique calendar within a CS. It + can be a full CALID or a relative CALID. (Section 8.3) + + CALMASTER - The "CALMASTER" property specifies the contact + information for the CS. (Section 8.4) + + CARID - Access rights can be saved and fetched by unique ID - the + "CARID" property. (Section 8.6) + + CMD - The CAP commands, as well as replies are transmitted using the + "CMD" property. (Section 10.1) + + DECREED - Some access rights are not changeable by the CUA. When + that is the case, the "DECREED" property value in the "VCAR" + component will be "TRUE". (Section 8.10) + + DEFAULT-CHARSET - The list of charsets supported by the CS. The + first entry is the default for the CS. (Section 8.11) + + DEFAULT-LOCALE - The list of locales supported by the CS. The first + entry in the list is the default locale. (Section 8.12) + + DEFAULT-TZID - This is the list of known timezones supported. The + first entry is the default. (Section 8.13) + + DEFAULT-VCARS - A list of the "CARID" properties that will be used + to create new calendars. (Section 8.14) + + DENY - The UPNs listed in the "DENY" property of a "VCAR" component + will be denied access, as described in the "VRIGHT" component. + (Section 8.15) + + + + + +Royer, et al. Experimental [Page 15] + +RFC 4324 Calendar Access Protocol December 2005 + + + EXPAND - This property tells the CS if the query reply should expand + components into multiple instances. The default is "FALSE" and is + ignored for CSs that cannot expand recurrence rules. (Section + 8.16) + + GRANT - The UPNs listed in the "GRANT" property of a "VCAR" + component will be allowed access as described in the "VRIGHT" + component. (Section 8.17) + + ITIP-VERSION - The version of [iTIP] supported. (Section 8.18) + + MAXDATE - The maximum date supported by the CS. (Section 8.20) + + MAX-COMP-SIZE - The largest component size allowed in the + implementation including attachments in octets. (Section 8.19) + + MINDATE - The minimum date supported by the CS. (Section 8.21) + + MULTIPART - Passed in the capability messages to indicate which MIME + multipart types the sender supports. (Section 8.22) + + NAME - The "NAME" property is used to add locale-specific + descriptions into components. (Section 8.23) + + OWNER - Each calendar has at least one "OWNER" property. (xref + target="OWNER"/>) Related to the "CAL-OWNERS()" query clause. + (Section 6.1.1.1) + + PERMISSION - This property specifies the permission being granted or + denied. Examples are the "SEARCH" and "MODIFY" values. (Section + 8.25) + + QUERY - Used to hold the CAL-QUERY (Section 8.26) for the component. + + QUERYID - A unique id for a stored query. (Section 8.27) + + QUERY-LEVEL - The level of the query language supported. (Section + 8.28) + + RECUR-ACCEPTED - If the implementation support recurrence rules. + (Section 8.29) + + RECUR-EXPAND - If the implementation support expanding recurrence + rules. (Section 8.31) + + RECUR-LIMIT - Any maximum limit on the number of instances the + implementation will expand recurring objects. (Section 8.30) + + + + +Royer, et al. Experimental [Page 16] + +RFC 4324 Calendar Access Protocol December 2005 + + + REQUEST-STATUS - The [iCAL] "REQUEST-STATUS" property is extended to + include new error numbers. + + RESTRICTION - In the final check when granting calendar access + requests, the CS test the results of a command for the value of + the "RESTRICTION" property in the corresponding "VRIGHT" + component, to determine if the access meets that restriction. + (Section 8.32) + + SCOPE - The "SCOPE" property is used in "VRIGHT"s component to + select the subset of data that may be acted upon when checking + access rights. (Section 8.33) + + SEQUENCE - When the "SEQUENCE" property is used in a "VALARM" + component, it uniquely identifies the instances of the "VALARM" + within that component. + + STORES-EXPANDED - Specifies if the implementation stores recurring + objects expanded or not. (Section 8.34) + + TARGET - The new "VCALENDAR" component property "TARGET" (Section + 8.35) is used to specify which calendar(s) will be the subject of + the CAP command. + + TRANSP - This is a modification of the [iCAL] "TRANSP" property and + it allows more values. The new values are related to conflict + control. (Section 8.36) + +2.1.3. New Components (summary) + + VAGENDA - CAP allows the fetching and storing of the entire contents + of a calendar. The "VCALENDAR" component is not sufficient to + encapsulate all of the needed data that describes a calendar. The + "VAGENDA" component is the encapsulating object for an entire + calendar. (Section 9.1) + + VCALSTORE - Each CS contains one or more calendars (VAGENDAs), the + "VCALSTORE" component is the encapsulating object that can hold + all of the "VAGENDA" components along with any components and + properties that are unique to the store level. (Section 9.2) + + VCAR - Calendar Access Rights are specified and encapsulated in the + new iCalendar "VCAR" component. The "VCAR" component holds some + new properties and at least one "VRIGHT" component. (Section 9.3) + + VRIGHT - This component encapsulates a set of instructions to the + CS to define the rights or restrictions needed. (Section 9.4) + + + + +Royer, et al. Experimental [Page 17] + +RFC 4324 Calendar Access Protocol December 2005 + + + VREPLY - This component encapsulates a set of data that can consist + of an arbitrary number of properties and components. Its contents + are dependent on the command that was issued. (Section 9.5) + + VQUERY - The search operation makes use of a new component, called + "VQUERY" and a new value type "CAL-QUERY" (Section 6.1.1). The + "VQUERY" component is used to fetch objects from the CS. (Section + 9.6) + +2.2. Relationship of RFC-2446 (ITIP) to CAP + + [iTIP] describes scheduling methods that result in indirect + manipulation of components. In CAP, the "CREATE" command is used to + deposit entities into the store. Other CAP commands, such as + "DELETE", "MODIFY", and "MOVE" command values, provide direct + manipulation of components. In the CAP calendar store model, + scheduling messages are conceptually kept separate from other + components by their state. + + All scheduling operations are as defined in [iTIP]. This memo makes + no changes to any of the methods or procedures described in [iTIP]. + In this memo, referring to the presence of the "METHOD" property in + an object is the same as saying an [iTIP] object. + + A CUA may create a "BOOKED" state object by depositing an iCalendar + object into the store. This is done by depositing an object that + does not have a "METHOD" property. The CS then knows to set the + state of the object to the "BOOKED" state. If the object has a + "METHOD" property, then the object is stored in the "UNPROCESSED" + state. + + If existing "UNPROCESSED" state objects exist in the CS for the same + UID (UID is defined in [iCAL]), then a CUA may wish to consolidate + the objects into one "BOOKED" state object. The CUA would fetch the + "UNPROCESSED" state objects for that UID and process them in the CUA + as described in [iTIP]. Then, if the CUA wished to book the UID, the + CUA would issue a "CREATE" command to create the new "BOOKED" state + object in the CS, followed by a "DELETE" command to remove any + related old [iTIP] objects from the CS. It might also involve the + CUA sending some [iMIP] objects or contacting other CSs and + performing CAP operations on those CSs. + + The CUA could also decide not to book the object. In this case, the + "UNPROCESSED" state objects could be removed from the CS, or the CUA + could set those objects to the marked-for-delete state. The CUA + could also ignore objects for later processing. + + + + + +Royer, et al. Experimental [Page 18] + +RFC 4324 Calendar Access Protocol December 2005 + + + The marked-for-delete state is used to keep the object around so that + the CUA can process duplicate requests automatically. If a duplicate + [iTIP] object is deposited into the CS and there exists identical + marked-for-delete objects, then a CUA acting on behalf of the "OWNER" + can silently drop those duplicate entries. + + Another purpose for the marked-for-delete state is so that, when a CU + decides they do not wish to have the object show in their calendar, + the CUA can book the object by changing the "PARTSTAT" parameter to + "DECLINED" in the "ATTENDEE" property that corresponds to their UPN. + Then the CUA can perform [iTIP] processing such as sending back a + decline, and then mark that object as marked-fo-delete. The CUA + might be configurable to automatically drop any updates for that + object, knowing the CU has already declined. + + When synchronizing with multiple CUAs, the marked-for-delete state + could be used to inform the synchronization process that an object is + to be deleted. How synchronization is done is not specified in this + memo. + + Several "UNPROCESSED" state entries can be in the CS for the same + UID. However, once consolidated, only one object exists in the CS + and that is the booked object. The other objects MUST be removed or + have their state changed to "DELETED". + + There MUST NOT be more than one "BOOKED" state object in a calendar + for the same "UID". The "ADD" method value may create multiple + objects in the "BOOKED" state for the same UID; however, for the + purpose of this memo, they are the same object and simply have + multiple "VCALENDAR" components. + + For example, if you were on vacation, you could have received a + "REQUEST" method to attend a meeting and several updates to that + meeting. Your CUA would have to issue "SEARCH" commands to find them + in the CS using CAP, process them, and determine the final state of + the object from a possible combination of user input and programmed + logic. Then the CUA would instruct the CS to create a new booked + object from the consolidated results. Finally, the CUA could do a + "DELETE" command to remove the related "UNPROCESSED" state objects. + See [iTIP] for details on resolving multiple [iTIP] scheduling + entries. + + + + + + + + + + +Royer, et al. Experimental [Page 19] + +RFC 4324 Calendar Access Protocol December 2005 + + +3. CAP Design + +3.1. System Model + + The system model describes the high level components of a calendar + system and how they interact with each other. + + CAP is used by a CUA to send commands to, and receive responses from, + a CS. + + The CUA prepares a [MIME] encapsulated message, sends it to the CS, + and receives a [MIME] encapsulated response. The calendaring-related + information within these messages are represented by iCalendar + objects. In addition, the "GET-CAPABILITY" command can be sent from + the CS to the CUA. + + There are two distinct protocols in operation to accomplish this + exchange. [BEEP] is the transport protocol used to move these + encapsulations between a CUA and a CS. CAP's [BEEP] profile defines + the application protocol that specifies the content and semantics of + the messages sent between the CUA and the CS. + +3.2. Calendar Store Object Model + + [iCAL] describes components such as events, todos, alarms, and + timezones. CAP requires additional object infrastructure, in + particular, detailed definitions of the containers for events and + todos (calendars), access control objects, and a query language. + + The conceptual model for a calendar store is shown below. The + calendar store (VCALSTORE - Section 9.2) contains "VCAR"s, "VQUERY"s, + "VTIMEZONE"s, "VAGENDA"s and calendar store properties. + + Calendars (VAGENDAs) contain "VEVENT"s, "VTODO"s, "VJOURNAL"s, + "VCAR"s, "VTIMEZONE"s, "VFREEBUSY", "VQUERY"s, and calendar + properties. + + The component "VCALSTORE" is used to denote the root of the calendar + store and contains all of the calendars. + + + + + + + + + + + + +Royer, et al. Experimental [Page 20] + +RFC 4324 Calendar Access Protocol December 2005 + + + Calendar Store + + VCALSTORE + | + +-- properties + +-- VCARs + +-- VQUERYs + +-- VTIMEZONEs + +-- VAGENDA + | | + | +--properties + | +--VEVENTs + | | | + | | +--VALARMs + | +--VTODOs + | | | + | | +--VALARMs + | +--VJOURNALs + | +--VCARs + | +--VTIMEZONEs + | +--VQUERYs + | +--VFREEBUSYs + | | + | | ... + . + . + +-- VAGENDA + . . + . . + . . + + Calendars within a Calendar Store are identified by their unique + Relative CALID. + +3.3. Protocol Model + + CAP uses [BEEP] as the transport and authentication protocol. + + The initial charset MUST be UTF-8 for a session in an unknown locale. + If the CS supplied the [BEEP] 'localize' attribute in the [BEEP] + 'greeting', then the CUA may tell the CS to switch locales for the + session by issuing the "SET-LOCALE" CAP command and supplying one of + the locales supplied by the [BEEP] 'localize' attribute. If a locale + is supplied, the first locale in the [BEEP] 'localize' attribute is + the default locale of the CS. The locale is switched only after a + successful reply. + + + + + +Royer, et al. Experimental [Page 21] + +RFC 4324 Calendar Access Protocol December 2005 + + + The "DEFAULT-CHARSET" property of the CS contains the list of + charsets supported by the CS with the first value being the default + for new calendars. If the CUA wishes to switch to one of those + charsets for the session, the CUA issues the "SET-LOCALE" command. + The CUA would have to first perform a "GET-CAPABILITY" command on the + CS to get the list of charsets supported by the CS. The charset is + switched only after a successful reply. + + The CUA may switch locales and charsets as needed. There is no + requirement that a CS support multiple locales or charsets. + +3.3.1. Use of BEEP, MIME, and iCalendar + + CAP uses the [BEEP] application protocol over TCP. Refer to [BEEP] + and [BEEPTCP] for more information. The default port on which the CS + listens for connections is user port 1026. + + The [BEEP] data exchanged in CAP is a iCalendar MIME content that + fully conforms to [iCAL] iCalendar format. + + This example tells the CS to generate and return 10 UIDs to be used + by the CUA. Note that throughout this memo, 'C:' refers to what the + CUA sends, 'S:' refers to what the CS sends, 'I:' refers to what the + initiator sends, and 'L:' refers to what the listener sends. Here + initiator and listener are used as defined in [BEEP]. + + C: MSG 1 2 . 432 62 + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: CMD;ID=unique-per-cua-123;OPTIONS=10:GENERATE-UID + C: END:VCALENDAR + + NOTE: The following examples will not include the [BEEP] header and + footer information. Only the iCalendar objects that are sent between + the CUA and CS will be shown because the [BEEP] payload boundaries + are independent of CAP. + + The commands listed below are used to manipulate or access the data + on the calendar store: + + ABORT - Sent to halt the processing of some of the commands. + (Section 10.2) + + CONTINUE - Sent to continue processing a command that has reached + its specified timeout time. (Section 10.3) + + + +Royer, et al. Experimental [Page 22] + +RFC 4324 Calendar Access Protocol December 2005 + + + CREATE - Create a new object on the CS. Initiated only by the CUA. + (Section 10.4) + + SET-LOCALE - Tell the CS to use any named locale and charset + supplied. Initiated by the CUA only. (Section 10.13) + + DELETE - Delete objects from the CS. Initiated only by the CUA. + Can also be used to mark an object for deletion. (Section 10.5) + + GENERATE-UID - Generate one or more unique ids. Initiated only by + the CUA. (Section 10.6) + + GET-CAPABILITY - Query the capabilities of the other end point of the + session. (Section 10.7) + + IDENTIFY - Set a new identity for the session. Initiated only by + the CUA. (Section 10.8) + + MODIFY - Modify components. Initiated by the CUA only. (Section + 10.9) + + MOVE - Move components to another container. Initiated only by the + CUA. (Section 10.10) + + REPLY - When replying to a command, the "CMD" value will be set to + "REPLY" so that it will not be confused with a new command. + (Section 10.11) + + SEARCH - Search for components. Initiated only by the CUA. + (Section 10.12) + + TIMEOUT - Sent when a specified amount of time has lapsed and a + command has not finished. (Section 10.14) + +4. Security Model + + BEEP transport performs all session authentication. + +4.1. Calendar User and UPNs + + A CU is an entity that can be authenticated. It is represented in + CAP as a UPN, which is a key part of access rights. The UPN + representation is independent of the authentication mechanism used + during a particular CUA/CS interaction. This is because UPNs are + used within VCARs. If the UPN were dependent on the authentication + mechanism, a VCAR could not be consistently evaluated. A CU may use + one mechanism while using one CUA, but the same CU may use a + + + + +Royer, et al. Experimental [Page 23] + +RFC 4324 Calendar Access Protocol December 2005 + + + different authentication mechanism when using a different CUA, or + while connecting from a different location. + + The user may also have multiple UPNs for various purposes. + + Note that the immutability of the user's UPN may be achieved by using + SASL's authorization identity feature. The transmitted authorization + identity may be different than the identity in the client's + authentication credentials [SASL, section 3]. This also permits a CU + to authenticate using their own credentials, yet request the access + privileges of the identity for which they are proxying SASL. Also, + the form of authentication identity supplied by a service like TLS + may not correspond to the UPNs used to express a server's access + rights, requiring a server-specific mapping to be done. The method + by which a server determines a UPN, based on the authentication + credentials supplied by a client, is implementation-specific. See + [BEEP] for authentication details; [BEEP] relies on SASL. + +4.1.1. UPNs and Certificates + + When using X.509 certificates for purposes of CAP authentication, the + UPN should appear in the certificate. Unfortunately, there is no + single correct guideline for which field should contain the UPN. + + Quoted from RFC-2459, section 4.1.2.6 (Subject): + + If subject naming information is present only in the + subjectAlt-Name extension (e.g., a key bound only to an email + address or URI), then the subject name MUST be an empty + sequence and the subjectAltName extension MUST be critical. + + Implementations of this specification MAY use these comparison + rules to process unfamiliar attribute types (i.e., for name + chaining). This allows implementations to process certificates + with unfamiliar attributes in the subject name. + + In addition, legacy implementations exist where an RFC 2822 + name [RFC2822] is embedded in the subject distinguished name as + an EmailAddress attribute. The attribute value for + EmailAddress is of type IA5String to permit inclusion of the + character '@', which is not part of the PrintableString + character set. EmailAddress attribute values are not case + sensitive (e.g., "fanfeedback@redsox.example.com" is the same + as "FANFEEDBACK@REDSOX.EXAMPLE.COM"). + + Conforming implementations generating new certificates with + electronic mail addresses MUST use the rfc822Name in the + subject alternative name field (see sec. 4.2.1.7 of [X509CRL]) + + + +Royer, et al. Experimental [Page 24] + +RFC 4324 Calendar Access Protocol December 2005 + + + to describe such identities. Simultaneous inclusion of the + EmailAddress attribute in the subject distinguished name to + support legacy implementations is deprecated but permitted. + + Since no single method of including the UPN in the certificate will + work in all cases, CAP implementations MUST support the ability to + configure what the mapping will be by the CS administrator. + Implementations MAY support multiple mapping definitions, for + example, the UPN may be found in either the subject alternative name + field, or the UPN may be embedded in the subject distinguished name + as an EmailAddress attribute. + + Note: If a CS or CUA is validating data received via [iMIP], if the + "ORGANIZER" or "ATTENDEE" properties said, for example, + "ATTENDEE;CN=Joe Random User:MAILTO:juser@example.com", then the + email address should be checked against the UPN. This is so the + "ATTENDEE" property cannot be changed to something misleading like + "ATTENDEE;CN=Joe Rictus User:MAILTO:jrictus@example.com" and have it + pass validation. Note that it is the email addresses that + miscompare, the CN miscompare is irrelevant. + +4.1.2. Anonymous Users and Authentication + + Anonymous access is often desirable. For example, an organization + may publish calendar information that does not require any access + control for viewing or login. Conversely, a user may wish to view + unrestricted calendar information without revealing their identity. + +4.1.3. User Groups + + A User Group is used to represent a collection of CUs or other UGs + that can be referenced in VCARs. A UG is represented in CAP as a + UPN. The CUA cannot distinguish between a UPN that represents a CU + or a UG. + + UGs are expanded as necessary by the CS. The CS MAY expand a UG + (including nested UGs) to obtain a list of unique CUs. Duplicate + UPNs are filtered during expansion. + + How the UG expansion is maintained across commands is + implementation-specific. A UG may reference a static list of + members, or it may represent a dynamic list. Operations SHOULD + recognize changes to UG membership. + + CAP does not define commands or methods for managing UGs. + + + + + + +Royer, et al. Experimental [Page 25] + +RFC 4324 Calendar Access Protocol December 2005 + + +4.2. Access Rights + + Access rights are used to grant or deny access to calendars, + components, properties, and parameters in a CS to a CU. CAP defines + a new component type called a Calendar Access Right (VCAR). + Specifically, a "VCAR" component grants, or denies, UPNs the right to + search and write components, properties, and parameters on calendars + within a CS. + + The "VCAR" component model does not put any restriction on the + sequence in which the object and access rights are created. That is, + an object associated with a particular "VCAR" component might be + created before or after the actual "VCAR" component is defined. In + addition, the "VCAR" and "VEVENT" components might be created in the + same iCalendar object and passed together in a single object. + + All rights MUST be denied unless specifically granted. + + If two rights specified in "VCAR" components are in conflict, the + right that denies access always takes precedence over the right that + grants access. Any attempt to create a "VCAR" component that + conflicts with a "VCAR" components with a "DECREED" property set to + the "TRUE" value must fail. + +4.2.1. Access Control and NOCONFLICT + + The "TRANSP" property can take on values -- "TRANSPARENT-NOCONFLICT" + and "OPAQUE-NOCONFLICT" -- that prohibit other components from + overlapping it. This setting overrides access. The "ALLOW-CONFLICT" + CS, Calendar or component setting may also prevent overlap, returning + an error code "6.3". + +4.2.2. Predefined VCARs + + The predefined calendar access CARIDs that MUST be implemented are: + + CARID:READBUSYTIMEINFO - Specifies the "GRANT" and "DENY" rules + that allow UPNs to search "VFREEBUSY" components. An example + definition for this VCAR is: + + BEGIN:VCAR + CARID:READBUSYTIMEINFO + BEGIN:VRIGHT + GRANT:* + PERMISSION:SEARCH + SCOPE:SELECT * FROM VFREEBUSY WHERE STATE() = 'BOOKED' + END:VRIGHT + END:VCAR + + + +Royer, et al. Experimental [Page 26] + +RFC 4324 Calendar Access Protocol December 2005 + + + CARID:REQUESTONLY - Specifies the "GRANT" and "DENY" rules to + UPNs other than the owner of the calendar and specifies the + ability to write new objects with the "METHOD" property set to + the "REQUEST" value. This CARID allows the owner to specify + which UPNs are allowed to make scheduling requests. An example + definition for this VCAR is: + + BEGIN:VCAR + CARID:REQUESTONLY + BEGIN:VRIGHT + GRANT:NON CAL-OWNERS() + PERMISSION:CREATE + RESTRICTION:SELECT VEVENT FROM VAGENDA + WHERE METHOD = 'REQUEST' + RESTRICTION:SELECT VTODO FROM VAGEND + WHERE METHOD = 'REQUEST' + RESTRICTION:SELECT VJOURNAL FROM VAGEND + WHERE METHOD = 'REQUEST' + END:VRIGHT + END:VCAR + + CARID:UPDATEPARTSTATUS - Grants authenticated users the right to + modify the instances of the "ATTENDEE" property set to one of + their calendar addresses in any components for any booked + component containing an "ATTENDEE" property. This allows (or + denies) a CU the ability to update their own participation + status in a calendar where they might not otherwise have + "MODIFY" command access. They are not allowed to change the + "ATTENDEE" property value. An example definition for this VCAR + (only affecting the "VEVENT" components) is: + + BEGIN:VCAR + CARID:UPDATEPARTSTATUS + BEGIN:VRIGHT + GRANT:* + PERMISSION:MODIFY + SCOPE:SELECT ATTENDEE FROM VEVENT + WHERE ATTENDEE = SELF() + AND ORGANIZER = CURRENT-TARGET() + AND STATE() = 'BOOKED' + RESTRICTION:SELECT * FROM VEVENT + WHERE ATTENDEE = SELF() + END:VRIGHT + END:VCAR + + CARID:DEFAULTOWNER - Grants to any owner the permission they have + for the target. An example definition for this VCAR is: + + + + +Royer, et al. Experimental [Page 27] + +RFC 4324 Calendar Access Protocol December 2005 + + + BEGIN:VCAR + CARID:DEFAULTOWNER + BEGIN:VRIGHT + GRANT:CAL-OWNERS() + PERMISSION:* + SCOPE:SELECT * FROM VAGENDA + END:VRIGHT + END:VCAR + +4.2.3. Decreed VCARs + + A CS MAY choose to implement and allow persistent immutable VCARs + that may be configured by the CS administrator. A reply from the CS + may dynamically create "VCAR" components that are decreed depending + on the implementation. To the CUA, any "VCAR" component with the + "DECREED" property set to "TRUE" cannot be changed by the currently + authenticated UPN, and, depending on the implementation and other + "VCAR" components, might not be able to be changed by any UPN using + CAP (never when the CUA gets a "DECREED:TRUE" VCAR). + + When a user attempts to modify or override a decreed "VCAR" component + rules, an error will be returned indicating that the user has + insufficient authorization to perform the operation. The reply to + the CUA MUST be the same as if a non-decreed VCAR caused the failure. + + The CAP protocol does not define the semantics used to initially + create a decreed VCAR. This administrative task is outside the scope + of the CAP protocol. + + For example, an implementation or a CS administrator may wish to + define a VCAR that will always allow the calendar owners to have full + access to their own calendars. + + Decreed "VCAR" components MUST be readable by the calendar owner in + standard "VCAR" component format. + +4.3. CAP Session Identity + + A [BEEP] session has an associated set of authentication credentials, + from which is derived a UPN. This UPN is the identity of the CAP + session, and is used to determine access rights for the session. + + The CUA may change the identity of a CAP session by calling the + "IDENTIFY" command. The CS only permits the operation if the + session's authentication credentials are good for the requested + identity. The method of checking this permission is implementation- + dependent, but it may be thought of as a mapping from authentication + credentials to UPNs. The "IDENTIFY" command allows a single set of + + + +Royer, et al. Experimental [Page 28] + +RFC 4324 Calendar Access Protocol December 2005 + + + authentication credentials to choose from multiple identities, and + allows multiple sets of authentication credentials to assume the same + identity. + + For anonymous access, the identity of the session is "@". A UPN with + a null Username and null Realm is anonymous. A UPN with a null + Username but non-null Realm (e.g.,"@example.com") may be used to mean + any identity from that Realm. This is useful to grant access rights + to all users in a given Realm. A UPN with a non-null Username and + null Realm (e.g., "bob@") could be a security risk and MUST NOT be + used. + + Because the UPN includes Realm information, it may be used to govern + calendar store access rights across Realms. However, governing + access rights across Realms is only useful if login access is + available. This could be done through a trusted server relationship + or a temporary account. Note that trusted server relationships are + outside the scope of CAP. + + The "IDENTIFY" command also provides for a weak group implementation. + By allowing multiple sets of authentication credentials belonging to + different users to identify as the same UPN, that UPN essentially + identifies a group of people, and may be used for group calendar + ownership, or the granting of access rights to a group. + +5. CAP URL and Calendar Address + + The CAP URL scheme is used to designate both calendar stores and + calendars accessible using the CAP protocol. + + The CAP URL scheme conforms to the generic URL syntax defined in RFC + 2396 and follows the Guidelines for URL Schemes set forth in RFC + 2718. + + A CAP URL begins with the protocol prefix "cap" and is defined by the + following grammar. + + capurl = "cap://" csidpart [ "/" relcalid ] + ; + csidpart = hostport ; As defined in Section 3.2.2 of RFC 2396 + ; + relcalid = *uric ; As defined in Section 2 of RFC 2396 + + A 'relcalid' is an identifier that uniquely identifies a calendar on + a particular calendar store. There is no implied structure in a + Relative CALID (relcalid). It may refer to the calendar of a user or + of a resource such as a conference room. It MUST be unique within + the calendar store. + + + +Royer, et al. Experimental [Page 29] + +RFC 4324 Calendar Access Protocol December 2005 + + + Here are some examples: + + cap://cal.example.com + cap://cal.example.com/Company/Holidays + cap://cal.example.com/abcd1234Usr + + A 'relcalid' is permitted and is resolved according to the rules + defined in Section 5 of RFC 2396. + + Examples of valid relative CAP URLs: + + opqaueXzz123String + UserName/Personal + + Calendar addresses can be described as qualified or relative CAP + URLs. + + For a user currently authenticated to the CS on cal.example.com, + these two example calendar addresses refer to the same calendar: + + cap://cal.example.com/abcd1234USR + abcd1234USR + +6. New Value Types + + The following sections contains new components, properties, + parameters, and value definitions. + + The purpose of these is to extend the iCalendar objects in a + compatible way so that existing iCalendar "VERSION" property "2.0" + value parsers can still parse the objects without modification. + +6.1. Property Value Data Types + +6.1.1. CAL-QUERY Value Type + + Subject: Registration of text/calendar MIME value type CAL-QUERY + + Value Name: CAL-QUERY + + Value Type Purpose: This value type is used to identify values and + contains query statements targeted at locating those values. This + is based on [SQL92] and [SQLCOM]. + + 1. For the purpose of a query, all components should be handled + as tables, and the properties of those components should be + handled as columns. + + + + +Royer, et al. Experimental [Page 30] + +RFC 4324 Calendar Access Protocol December 2005 + + + 2. All VAGENDAs and CSs look like tables for the purpose of a + QUERY, and all of their properties look like columns in those + tables. + + 3. You MUST NOT do any cross-component-type joins. That means + you can ONLY have one component OR one "VAGENDA" component OR + one "VCALSTORE" component in the "FROM" clause. + + 4. Everything in the "SELECT" clause and "WHERE" clauses MUST be + from the same component type or "VAGENDA" component OR + "VCALSTORE" component in the "FROM" clause. + + 5. When multiple "QUERY" properties are supplied in a single + "VQUERY" component, the results returned are the same as the + results returned for multiple "VQUERY" components that each + have a single "QUERY" property. + + 6. The '.' is used to separate the table name (component) and + column name (property or component) when selecting a property + that is contained inside a component that is targeted in the + TARGET property. + + 7. A contained component without a '.' is not the same as + "component-name.*". If given as "component-name" (no dot), + the encapsulating BEGIN/END statement will be supplied for + "component-name". + + In the following example, '.' is used to separate the "TRIGGER" + property from its contained component (VALARM), which is contained in + any "VEVENT" component in the selected "TARGET" property value (a + relcalid). All "TRIGGER" properties in any "VEVENT" component in + relcalid would be returned. + + TARGET:relcalid + QUERY:SELECT VALARM.TRIGGER FROM VEVENT + SELECT VALARM FROM VEVENT WHERE UID = "123" + + This returns one BEGIN/END "VALARM" component for each "VALARM" + component in the matching "VEVENT" component. As there is no '.' + (dot) in the VALARM after the SELECT above, it returns: + + + + + + + + + + + +Royer, et al. Experimental [Page 31] + +RFC 4324 Calendar Access Protocol December 2005 + + + BEGIN:VALARM + TRIGGER;RELATED=END:PT5M + REPEAT:4 + ... + END:VALARM + BEGIN:VALARM + TRIGGER;RELATED=START:PT5M + DURATION:PT10M + ... + END:VALARM + ... + ... + + If the SELECT parameter is provided as "component-name.*", then only + the properties and any contained components will be returned. The + example: + + SELECT VALARM.* FROM VEVENT WHERE UID = "123" + + will return all of the properties in each "VALARM" component in the + matching "VEVENT" component: + + TRIGGER;RELATED=END:PT5M + REPEAT:4 + ... + TRIGGER;RELATED=START:PT5M + DURATION:PT10M + ... + ... + + In the following SELECT clauses: + + (a) SELECT FROM VEVENT + + (b) SELECT VALARM FROM VEVENT + + (c) SELECT VALARM.* FROM VEVENT + + (d) SELECT * FROM VEVENT + + (e) SELECT * FROM VEVENT WHERE + VALARM.TRIGGER < '20020201T000000Z' + AND VALARM.TRIGGER > '20020101T000000Z' + + Clause (a) elects all instances of from all "VEVENT" + components. + + + + + +Royer, et al. Experimental [Page 32] + +RFC 4324 Calendar Access Protocol December 2005 + + + Clauses (b) and (c) select all "VALARM" components from all "VEVENT" + components. (b) would return them in BEGIN/END VALARM tags. (c) would + return all of the properties without BEGIN/END VALARM tags. + + Clause (d) selects every property and every component that is in any + "VEVENT" component, with each "VEVENT" component wrapped in a + BEGIN/END VEVENT tags. + + Clause (e) selects all properties and all contained components in all + "VEVENT" components that have a "VALARM" component with a "TRIGGER" + property value between the provided dates and times, with each + "VEVENT" component wrapped in BEGIN/END VEVENT tags. + + Here are two invalid SELECT clauses: + + (f) SELECT VEVENT.VALARM.TRIGGER FROM VEVENT + + (g) SELECT DTSTART,UID FROM VEVENT + WHERE VTODO.SUMMERY = "Fix typo in CAP" + + Clause (f) is invalid because it contains two '.' characters. + + Clause (g) Is invalid because it mixes VEVENT + and VTODO properties in the same VQUERY. + + Formal Definition: The value type is defined by the following + notation: + + cal-query = "SELECT" SP cap-val SP + "FROM" SP comp-name SP + "WHERE" SP cap-expr + + / "SELECT" SP cap-cols SP + "FROM" SP comp-name + ; + cap-val = cap-cols / param + / ( cap-val "," cap-val ) + + ; NOTE: there is NO space around the "," on + ; the next line + cap-cols = cap-col / ( cap-cols "," cap-col) + / "*" + / "*.*" ; only valid when the target is a "VAGENDA" + ; + ; A 'cap-col' is: + ; + ; Any property name ('cap-prop') found in the + ; component named in the 'comp-name' used in the + + + +Royer, et al. Experimental [Page 33] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; "FROM" clause. + ; + ; SELECT ORGANIZER FROM VEVENT ... + ; + ; OR + ; + ; A component name ('comp-name') of an existing + ; component contained inside of the 'comp-name' + ; used in the "FROM" clause. + ; + ; SELECT VALARM FROM VEVENT ... + ; + ; OR + ; + ; A component name ('comp-name') of an existing + ; component contained inside of the 'comp-name' used + ; in the "FROM" clause followed by a property + ; name ('cap-prop') to be selected from that + ; component. + ; (comp-name "." cap-prop) + + ; SELECT VALARM.TRIGGER FROM VEVENT ... + + cap-col = comp-name + / comp-name "." cap-prop + / cap-prop + + comp-name = "VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" + / "VALARM" / "DAYLIGHT" / "STANDARD" / "VAGENDA" + / "VCAR" / "VCALSTORE" / "VQUERY" / "VTIMEZONE" + / "VRIGHT" / x-comp / iana-comp + + cap-prop = ; A property that may be in the 'cap-comp' named + ; in the "SELECT" clause. + + cap-expr = "(" cap-expr ")" + / cap-term + + cap-term = cap-expr SP cap-logical SP cap-expr + / cap-factor + + cap-logical= "AND" / "OR" + + cap-factor = cap-colval SP cap-oper SP col-value + / cap-colval SP "LIKE" SP col-value + / cap-colval SP "NOT LIKE" SP col-value + / cap-colval SP "IS NULL" + / cap-colval SP "IS NOT NULL" + + + +Royer, et al. Experimental [Page 34] + +RFC 4324 Calendar Access Protocol December 2005 + + + / col-value SP "IN" cap-colval + / col-value SP "NOT IN" cap-colval + / "STATE()" "=" ( "BOOKED" + / "UNPROCESSED" + / "DELETED" + / iana-state + / x-state ) + ; + iana-state = ; Any state registered by IANA directly or + ; included in an RFC that may be applied to + ; the component and within the rules published. + ; + x-state = ; Any experimental state that starts with + ; "x-" or "X-". + + cap-colval = cap-col / param + ; + param = "PARAM(" cap-col "," cap-param ")" + ; + cap-param = ; Any parameter that may be contained in the cap-col + ; in the supplied PARAM() function + + col-value = col-literal + / "SELF()" + / "CAL-OWNERS()" + / "CAL-OWNERS(" cal-address ")" + / "CURRENT-TARGET()" + ; + cal-address = ; A CALID as define by CAP + ; + col-literal = "'" literal-data "'" + ; + literal-data = ; Any data that matches the value type of the + ; column that is being compared. That is, you + ; cannot compare PRIORITY to "some string" because + ; PRIORITY has a value type of integer. If it is + ; not preceded by the LIKE element, any '%' and '_' + ; characters in the literal data are not treated as + ; wildcard characters and do not have to be + ; backslash-escaped. + ; + ; OR + ; + ; If the literal-data is preceded by the LIKE + ; element it may also contain the '%' and '_' + ; wildcard characters. And, if the literal data + ; that is comparing contains any '%' or '_' + ; characters, they MUST be backslash-escaped as + + + +Royer, et al. Experimental [Page 35] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; described in the notes below, in order for them + ; not to be treated as wildcard characters. + ; + ; And, if the literal data contains any characters + ; that would have to be backslash-escaped if + ; a property or parameter value, then they must + ; be backslash-escaped in the literal-data. + ; Also, the quote character (') must be backslash + ; escaped. Example: + ; + ; ... WHERE SUBJECT = 'It\'s time to ski' + ; + cap-oper = "=" + / "!=" + / "<" + / ">" + / "<=" + / ">=" + ; + SP = ; A single white space ASCII character + ; (value in HEX %x20). + ; + x-comp = ; As defined in [iCAL] section 4.6. + ; + iana-comp = ; As defined in [iCAL] section 4.6. + +6.1.1.1. [NOT] CAL-OWNERS() + + This function returns the list of "OWNER" properties for the named + calendar when used in the "SELECT" clause. + + If called as 'CAL-OWNERS()', it is equivalent to the comma-separated + list of all of the owners of the calendar that match the provided + "TARGET" property value. If the target is a "VCALSTORE", it returns + the "CALMASTER" property. + + If called as 'CAL-OWNERS(cal-address)', then it is the equivalent to + the comma-separated list of owners for the named calendar id. If + 'cal-address' is a CS, it returns the "CALMASTER" property. + + If used in the "WHERE" clause, it returns true if the currently + authenticated UPN is an owner of the currently selected object + matched in the provided "TARGET" property. Used in a CAL-QUERY + "WHERE" clause and in the UPN-FILTER. + + + + + + + +Royer, et al. Experimental [Page 36] + +RFC 4324 Calendar Access Protocol December 2005 + + +6.1.1.2. CURRENT-TARGET() + + This is equivalent to the value of the "TARGET" property in the + current command. It is used in a CAL-QUERY "WHERE" clause. + +6.1.1.3. PARAM() + + This is used in a CAL-QUERY. It returns or tests for the value of + the named parameter from the named property. + +6.1.1.3.1. PARAM() in SELECT + + When used in a "SELECT" clause, it returns the entire property and + all of that property's parameters; the result is not limited to the + supplied parameter. If the property does not contain the named + parameter, then the property is not returned. However, it could be + returned as a result of another "SELECT" clause value. If multiple + properties of the supplied name have the named parameter, all + properties with that named parameter are returned. If multiple + PARAM() clauses in a single "SELECT" CLAUSE match the same property, + then the single matching property is returned only once. + + Also, note that many parameters have default values defined in [iCAL] + that must be treated as existing with their default value in the + properties, as defined in [iCAL], even when not explicitly present. + For example, if a query were performed with PARAM(ATTENDEE,ROLE) then + ALL "ATTENDEE" properties would match because, even when they do not + explicitly contain the "ROLE" parameter, it has a default value and + therefore must match. + + Therefore, when PARAM() is used in a "SELECT" clause, it is more + accurate to say that it means return the property, if it contains the + named parameter explicitly in the property or simply because the + parameter has a default for that property. + +6.1.1.3.2. PARAM() in WHERE + + When PARAM() is used in the "WHERE" clause, a match is true when the + parameter value matches the compare clause (according to the supplied + WHERE values). If multiple named properties contain the named + parameter, then each parameter value is compared in turn to the + condition; if any match, the results would be true for that condition + the same as if only one had existed. Each matching property or + component is returned only once. + + Because a parameter may be multi-valued, the comparison might need to + be done with an "IN" or "NOT IN" comparator. + + + + +Royer, et al. Experimental [Page 37] + +RFC 4324 Calendar Access Protocol December 2005 + + + Given the following query: + + ATTENDEE;PARTSTAT=ACCEPTED:cap://host.com/joe + + SELECT VEVENT FROM VAGENDA + WHERE PARAM(ATTENDEE,PARTSTAT) = 'ACCEPTED' + + Thus, all "VEVENT" components that contain one or more "ATTENDEE" + properties that have a "PARTSTAT" parameter with a "ACCEPTED" value + would be returned. Also, each uniquely matching VEVENT would be + returned only once, no matter how many "ATTENDEE" properties had + matching roles, in each unique "VEVENT" component. + + Also note that many parameters have default values defined in [iCAL]. + Therefore, if the following query were performed on the "ATTENDEE" + property in the above example: + + SELECT VEVENT FROM VAGENDA + WHERE PARAM(ATTENDEE,ROLE) = 'REQ-PARTICIPANT' + + It would return the "ATTENDEE" property shown above because the + default value for the "ROLE" parameter is "REQ-PARTICIPANT". + +6.1.1.4. SELF() + + Used in a CAL-QUERY "WHERE" clause. Returns the UPN of the currently + authenticated UPN or their current UPN as a result of an IDENTIFY + command. + +6.1.1.5. STATE() + + Returns one of three values, "BOOKED", "UNPROCESSED", or "DELETED" + depending on the state of the object. "DELETED" is a component in + the marked-for-delete state. Components that have been removed from + the store are never returned. + + If not specified in a query then both "BOOKED" and "UNPROCESSED" data + is returned. Each unique "METHOD" property must be in a separate + MIME object, per the [iCAL] section 3.2 restriction. + +6.1.1.6. Use of Single Quote + + All literal values are surrounded by single quotes ('), not double + quotes ("), and not without any quotes. If the value contains quotes + or any other ESCAPED-CHAR, they MUST be backslash-escaped as + described in section 4.3.11 "Text" of [iCAL]. Any "LIKE" clause + wildcard characters that are part of any literal data that is + preceded by a "LIKE" clause or "NOT LIKE" clause and is not intended + + + +Royer, et al. Experimental [Page 38] + +RFC 4324 Calendar Access Protocol December 2005 + + + to mean wildcard search MUST be escaped as described in note (7) + below. + +6.1.1.7. Comparing DATE and DATE-TIME Values + + When comparing "DATE-TIME" values to "DATE" values and when comparing + "DATE" values to "DATE-TIME" values, the result will be true if the + "DATE" value is on the same day as the "DATE-TIME" value. They are + compared in UTC no matter what time zone the data may have been + stored in. + + Local time event, as described in section 4.2.19 of [iCAL], must be + considered to be in the CUA default timezone that was supplied by the + CUA in the "CAPABILITY" exchange. + + VALUE-1 VALUE-2 Compare Results + + 20020304 20020304T123456 TRUE + (in UTC-3) (in UTC-3) + + 20020304 20020304T003456 FALSE + (in UTC) (in UTC-4) + + 20020304T003456Z 20020205T003456 FALSE + (in UTC-0) (in UTC-7) + + When "DATE" values and "DATE-TIME" values are compared with the + "LIKE" clause, the comparison will be done as if the value is a + [iCAL] DATE or DATE-TIME string value. + + LIKE '2002%' will match anything in the year 2002. + + LIKE '200201%' will match anything in January 2002. + + LIKE '%T000000' will match anything at midnight. + + LIKE '____01__T%' will match anything for any year or + time that is in January. + (Four '_', '01', two '_' 'T%'). + + Using a "LIKE" clause value of "%00%", would return any value that + contained two consecutive zeros. + + All comparisons will be done in UTC. + + + + + + + +Royer, et al. Experimental [Page 39] + +RFC 4324 Calendar Access Protocol December 2005 + + +6.1.1.8. DTEND and DURATION + + The "DTEND" property value is not included in the time occupied by + the component. That is, a "DTEND" property value of 20030614T12000 + includes all of the time up to, but not including, noon on that day. + + The "DURATION" property value end time is also not inclusive. So an + object with a "DTSTART" property value of 20030514T110000 and a + "DURATION" property value of "1H" does not include noon on that day. + + When a "QUERY" property value contains a "DTEND" value, then the CS + MUST also evaluate any existing "DURATION" property value and + determine if it has an effective end time that matches the "QUERY" + property supplied "DTEND" value or any range of values supplied by + the "QUERY" property. + + When a "QUERY" property contains a "DURATION" value, then the CS MUST + also evaluate any existing "DTEND" property values and determine if + they have an effective duration that matches the value, or any range + of values, supplied by the "QUERY" property. + +6.1.1.9. [NOT] LIKE + + The pattern matching characters are the '%' that matches zero or more + characters, and '_' that matches exactly one character (where + character does not always mean octet). + + "LIKE" clause pattern matches always cover the entire string. To + match a pattern anywhere within a string, the pattern must start and + end with a percent sign. + + To match a '%' or '_' in the data and not have it interpreted as a + wildcard character, they MUST be backslash-escaped. Thus, to search + for a '%' or '_' in the string: + + LIKE '%\%%' Matches any string with a '%' in it. + LIKE '%\_%' Matches any string with a '_' in it. + + Strings compared using the "LIKE" clause MUST be performed using case + insensitive comparisoison assumes 'a' = 'A'). + + If the "LIKE" clause is preceded by 'NOT' then there is a match when + the string compare fails. + + Some property values (such as the 'recur' value type), contain commas + and are not multi-valued. The CS must understand the objects being + compared and understand how to determine how any multi-valued or + multi-instances properties or parameter values are separated, quoted, + + + +Royer, et al. Experimental [Page 40] + +RFC 4324 Calendar Access Protocol December 2005 + + + and backslash-escaped. THE CS must perform the comparisons as if + each value existed by itself and was not quoted or backslash-escaped, + when comparing using the LIKE element. + + See related examples in Section 6.1.1.11. + +6.1.1.10. Empty vs. NULL + + When used in a CAL-QUERY value, "NULL" means that the property or + parameter is not present in the object. Paramaters that are not + provided and have a default value in the property are considered to + exist with their default value and will not be "NULL". + + If the property exists but has no value, then "NULL" MUST NOT + match. + + If the parameter exists but has no value, then "NULL" MUST NOT + match. + + If the parameter not present and has a default value, then "NULL" + MUST NOT match. + + If the property (or parameter) exists but has no value, then it + matches the empty string '' (quote quote). + +6.1.1.11. [NOT] IN + + This is similar to the "LIKE" clause, except it does value matching + and not string comparison matches. + + Some iCalendar objects can be multi-instance and multi-valued. The + "IN" clause will return a match if the literal value supplied as part + of the "IN" clause is contained in the value of any instance of the + named property or parameter, or is in any of the multiple values in + the named property or parameter. Unlike the "LIKE" clause, the '%' + and '_' matching characters are not used with the "IN" clause and + have no special meaning. + + BEGIN:A-COMPONENT + (a) property:value1,value2 One property, two values. + (b) property:"value1,value2" One property, one value. + (c) property:parameter=1,2:x One parameter, two values. + (d) property:parameter="1,2",3:y One parameter, one value. + (e) property:parameter=",":z One parameter, one value. + (f) property:x,y,z One property, three values + END:A-COMPONENT + + + + + +Royer, et al. Experimental [Page 41] + +RFC 4324 Calendar Access Protocol December 2005 + + + In this example: + + 'value1' IN property would match (a) only. + 'value1,value2' IN property would match (b) only. + 'value%' IN property would NOT match any. + ',' IN property would NOT match any. + '%,%' IN property would NOT match any. + 'x' IN property would match (f) and (c). + '2' IN parameter would match (c) only. + '1,2' IN parameter would match (d) only. + ',' IN parameter would match (e) only. + '%,%' IN parameter would NOT match any. + + property LIKE 'value1%' would match (a) and (b). + property LIKE 'value%' would match (a) and (b). + property LIKE 'x' would match (f) and (c). + parameter LIKE '1%' would match (c) and (d). + parameter LIKE '%2%' would match (c) and (d). + parameter LIKE ',' would match (e) only. + + Some property values (such as the "RECUR" value type), contain commas + and are not multi-valued. The CS must understand the objects being + compared and understand how to determine how any multi-valued or + multi-instance properties or parameter values are separated, quoted, + and backslash-escaped and perform the comparisons as if each value + existed by itself and not quoted or backslash-escaped when comparing + using the IN element. + + If the "IN" clause is preceded by 'NOT', then there is a match when + the value does not exist in the property or parameter value. + +6.1.1.12. DATE-TIME and TIME Values in a WHERE Clause + + All "DATE-TIME" and "TIME" literal values supplied in a "WHERE" + clause MUST be terminated with 'Z'. That means that the CUA MUST + supply the values in UTC. + + Valid: + + WHERE alarm.TRIGGER < '20020201T000000Z' + AND alarm.TRIGGER > '20020101T000000Z' + + Not valid; it is a syntax error and the CS MUST reject the QUERY: + + WHERE alarm.TRIGGER < '20020201T000000' + AND alarm.TRIGGER > '20020101T000000' + + + + + +Royer, et al. Experimental [Page 42] + +RFC 4324 Calendar Access Protocol December 2005 + + +6.1.1.13. Multiple Contained Components + + If a query references a component and a component or property + contained in the component, any clauses referring to the contained + component or property must be evaluated on all of the contained + components or properties. If any of the contained components or + properties match the query, and the conditions on the containing + component are also true, the component matches the query. + + For example, in the query below, if a BOOKED VEVENT contains multiple + VALARMs, and the VALARM.TRIGGER clause is true for any of the VALARMs + in the VEVENT, then the UID, SUMMARY, and DESCRIPTION of this VEVENT + would be included in the QUERY results. + + BEGIN:VQUERY + EXPAND:TRUE + QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT + WHERE VALARM.TRIGGER >= '20000101T030405Z' + AND VALARM.TRIGGER <= '20001231T235959Z' + AND STATE() = 'BOOKED' + END:VQUERY + +6.1.1.14. Example, Query by UID + + The following example would match the entire content of a "VEVENT" or + "VTODO" component with the "UID" property equal to "uid123" , and it + would not expand any multiple instances of the component. If the CUA + does not know if "uid123" was a "VEVENT", "VTODO", "VJOURNAL", or + any other component, then all components that the CUA supports MUST + be supplied in a QUERY property. This example assumes the CUA is + only interested in "VTODO" and "VEVENT" components. + + If the results were empty it could also mean that "uid123" was a + property in a component other than a VTODO or VEVENT. + + BEGIN:VQUERY + QUERY:SELECT * FROM VTODO WHERE UID = 'uid123' + QUERY:SELECT * FROM VEVENT WHERE UID = 'uid123' + END:VQUERY + +6.1.1.15. Query by Date-Time Range + + This query selects the entire content of every booked "VEVENT" + component that has an instance greater than or equal to July 1, + 2000 00:00:00 UTC and less than or equal to July 30, 2000 23:59:59 + UTC. This includes single instance "VEVENT" components that do + not explicitly contain any recurrence properties or "RECURRENCE- + ID" properties. This works only for CSs that have the "RECUR- + + + +Royer, et al. Experimental [Page 43] + +RFC 4324 Calendar Access Protocol December 2005 + + + EXPAND" property value set to "TRUE" in the "GET-CAPABILITY" + exchange. + + BEGIN:VQUERY + EXPAND:TRUE + QUERY:SELECT * FROM VEVENT + WHERE RECURRENCE-ID >= '20000701T000000Z' + AND RECURRENCE-ID <= '20000730T235959Z' + AND STATE() = 'BOOKED' + END:VQUERY + +6.1.1.16. Query for All Unprocessed Entries + + The following example selects the entire contents of all non-booked + "VTODO" and "VEVENT" components in the "UNPROCESSED" state. The + default for the "EXPAND" property is "FALSE", so the recurrence rules + will not be expanded. + + BEGIN:VQUERY + QUERYID:Fetch VEVENT and VTODO iTIP components + QUERY:SELECT * FROM VEVENT WHERE STATE() = 'UNPROCESSED' + QUERY:SELECT * FROM VTODO WHERE STATE() = 'UNPROCESSED' + END:VQUERY + + The following example fetches all "VEVENT" and "VTODO" components in + the "BOOKED" state. + + BEGIN:VQUERY + QUERYID:Fetch All Booked VEVENT and VTODO components + QUERY:SELECT * FROM VEVENT WHERE STATE() = 'BOOKED' + QUERY:SELECT * FROM VTODO WHERE STATE() = 'BOOKED' + END:VQUERY + + The following fetches the "UID" property for all "VEVENT" and "VTODO" + components that have been marked for delete. + + BEGIN:VQUERY + QUERYID:Fetch UIDs of marked-for-delete VEVENTs and VTODOs + QUERY:SELECT UID FROM VEVENT WHERE STATE() = 'DELETED' + QUERY:SELECT UID FROM VTODO WHERE STATE() = 'DELETED' + END:VQUERY + +6.1.1.17. Query with Subset of Properties by Date/Time + + In this example, only the named properties will be selected, and all + booked and non-booked components have a "DTSTART" value from February + 1st to February 10th 2000 (in UTC) will also be selected. + + + + +Royer, et al. Experimental [Page 44] + +RFC 4324 Calendar Access Protocol December 2005 + + + BEGIN:VQUERY + QUERY:SELECT UID,DTSTART,DESCRIPTION,SUMMARY FROM VEVENT + WHERE DTSTART >= '20000201T000000Z' + AND DTSTART <= '20000210T235959Z' + END:VQUERY + +6.1.1.18. Query with Components and Alarms in A Range + + This example fetches all booked "VEVENT" components with an alarm + that triggers within the specified time range. In this case only the + "UID", "SUMMARY", and "DESCRIPTION" properties will be selected for + all booked "VEVENTS" components that have an alarm between the two + date-times supplied. + + BEGIN:VQUERY + EXPAND:TRUE + QUERY:SELECT UID,SUMMARY,DESCRIPTION FROM VEVENT + WHERE VALARM.TRIGGER >= '20000101T030405Z' + AND VALARM.TRIGGER <= '20001231T235959Z' + AND STATE() = 'BOOKED' + END:VQUERY + +6.1.2. UPN Value Type + + Value Name: UPN + + Purpose: This value type is used to identify values that contain user + principal name of a CU or a group of CUs. + + Formal Definition: The value type is defined by the following + notation: + + ; + upn = "@" + / [ dot-atom-text ] "@" dot-atom-text + ; + ; dot-atom-text is defined in RFC 2822 [RFC2822] + ; + ; + dot-atom-text = ; As defined in [iCAL]. + + Description: This data type is an identifier that denotes a CU or a + group of CU. A UPN is an RFC 2822-compliant email address + [RFC2822], with exceptions listed below, and in most cases it is + deliverable to the CU. In some cases it is identical to the CU's + well known email address. A CU's UPN MUST never be an e-mail + address that is deliverable to a different person. And there is + no requirement that a person's UPN MUST be their e-mail address. + + + +Royer, et al. Experimental [Page 45] + +RFC 4324 Calendar Access Protocol December 2005 + + + A UPN is formatted as a user name followed by "@", followed by a + Realm in the form of a valid and unique DNS domain name. The user + name MUST be unique within the Realm. In its simplest form it + looks like "user@example.com". + + In certain cases a UPN will not be RFC 2822-compliant. When + anonymous authentication is used, or anonymous authorization is + being defined, the special UPN "@" will be used. When + authentication MUST be used, but unique identity MUST be obscured, + a UPN of the form @DNS-domain-name may be used. For example, + "@example.com". + + Example: + + The following is a UPN for a CU: + + jdoe@example.com + + The following is an example of a UPN that could be for a group of + CU: + + staff@example.com + + The following is a UPN for an anonymous CU that belongs to a + specific realm. When used as a UPN-FILTER, it applies to all UPNs + in a specific realm: + + @example.com + + The following is a UPN for an anonymous CU: + + @ + +6.1.3. UPN-FILTER Value + + Value Name: UPN-FILTER + + Purpose: This value type is used to identify values that contain a + user principal name filter. + + Formal Definition: The value type is defined by the following + notation: + + ; + ; NOTE: "CAL-OWNERS(cal-address)" + ; and "NOT CAL-OWNERS(cal-address)" + ; are both NOT allowed below. + ; + + + +Royer, et al. Experimental [Page 46] + +RFC 4324 Calendar Access Protocol December 2005 + + + upn-filter = "CAL-OWNERS()" / + "NOT CAL-OWNERS()" / + "*" / + [ "*" / dot-atom-text ] "@" ( "*" / dot-atom-text ) + ; + ; dot-atom-text is defined in RFC 2822 + + Description: The value is used to match user principal names (UPNs). + For "CAL-OWNERS()" and "NOT CAL-OWNERS()", see Section 8.24. + + * Matches all UPNs. + + @ Matches the UPN of anonymous CUs + belonging to the null realm + + @* Matches the UPN of anonymous CUs + belonging to any non-null realm + + @realm Matches the UPN of anonymous CUs + belonging to the specified realm. + + *@* Matches the UPN of non-anonymous CUs + belonging to any non-null realm + + *@realm Matches the UPN of non-anonymous CUs + belonging to the specified realm + + user@realm Matches the UPN of the specified CU + belonging to the specified realm + + user@* Not allowed. + + user@ Not allowed. + + Example: The following are examples of this value type: + + DENY:NON CAL-OWNERS() + DENY:@hackers.example.com + DENY:*@hackers.example.com + GRANT:sam@example.com + + + + + + + + + + + +Royer, et al. Experimental [Page 47] + +RFC 4324 Calendar Access Protocol December 2005 + + +7. New Parameters + +7.1. ACTION Parameter + + Parameter Name: ACTION + + Purpose: This parameter indicates the action to be taken when a + timeout occurs. + + Value Type: TEXT + + Conformance: This property can be specified in the "CMD" property. + + When present in a "CMD" property, the "ACTION" parameter specifies + the action to be taken when the command timeout expires. + + Formal Definition: The parameter is defined by the following + notation: + + action-param = ";" "ACTION" "=" ( "ASK" / "ABORT" ) + ; If 'action-param' is supplied then + ; 'latency-param' MUST be supplied. + + Example: + + CMD;LATENCY=10;ACTION=ASK:CREATE + +7.2. ENABLE Parameter + + Parameter Name: ENABLE + + Purpose: This parameter indicates whether or not the property should + be ignored. For example, it can indicate that a "TRIGGER" + property in a "VALARM" component should be ignored. + + Value Type: BOOLEAN + + Conformance: This property can be specified in the "TRIGGER" + properties. + + Description: When a non owner sends an [iTIP] "REQUEST" to a calendar + that object might contain a "VALARM" component. The owner may + wish to have local control over their own CUA and when or how + alarms are triggered. + + A CUA may add the "ENABLE" parameter to any "TRIGGER" property + before booking the component. If the "ENABLE" parameter is set to + "FALSE", then the alarm will be ignored by the CUA. If set to + + + +Royer, et al. Experimental [Page 48] + +RFC 4324 Calendar Access Protocol December 2005 + + + "TRUE", or if the "ENABLE" property is not in the "TRIGGER" + property, the alarm is enabled. This parameter may not be known + by pre-CAP implementations, but this should not be an issue as it + conforms to an 'ianaparam' [iCAL]. + + Formal Definition: The property is defined by the following notation: + + enable-param = "ENABLE" "=" boolean + ; + boolean = ; As defined in [iCAL]. + + Example: The following is an example of this property for a "VAGENDA" + component: + + TRIGGER;ENABLE=FALSE;RELATED=END:PT5M + +7.3. ID Parameter + + Parameter Name: ID + + Purpose: When used in a "CMD" component, it provides a unique + identifier. + + Value Type: TEXT + + Conformance: This parameter can be specified in the "CMD" property. + + Description: If more than one command is sent, then the "ID" + parameter is used to uniquely identify the command. + + A CUA may add the "ID" parameter to any "CMD" property before + sending the command. There must not be more than one outstanding + command tagged with the same "ID" parameter value. + + Formal Definition: The property is defined by the following notation: + + id-param = ";" "ID" "=" unique-id + ; The text value supplied is a unique value + ; shared between the CUA and CS to uniquely + ; identify the instance of command in the + ; the current CUA session. The value has + ; no meaning to other CUAs or other sessions. + ; + unique-id = ; text + ; + text = ; As defined in [iCAL]. + + Example: The following is an example of this parameter component: + + + +Royer, et al. Experimental [Page 49] + +RFC 4324 Calendar Access Protocol December 2005 + + + CMD;UD=some-unique-value:CREATE + +7.4. LATENCY Parameter + + Parameter Name: LATENCY + + Purpose: This parameter indicates time in seconds for when a timeout + occurs. + + Value Type: TEXT + + Conformance: This property can be specified in the "CMD" property. + + When present in a "CMD" property, the "LATENCY" parameter specifies + the time in seconds when the command timeout expires. + + Formal Definition: The parameter is defined by the following + notation: + + latency-param = ";" "LATENCY" "=" latency-sec + ; The value supplied in the time in seconds. + ; If 'latency-param' is supplied then + ; 'action-param' MUST be supplied. + ; + latency-sec = posint1 + + ; Default is zero (0) meaning no timeout. + + Example: The following is an example of this parameter: + + CMD;LATENCY=10;ACTION=ASK:CREATE + +7.5. LOCAL Parameter + + Parameter Name: LOCAL + + Purpose: Indicates if the named component should be exported to any + non-organizer calendar. + + Value Type: BOOLEAN + + Conformance: This parameter can be specified in the "SEQUENCE" + properties in a "VALARM" component. + + Description: When a non-owner sends an [iTIP] "REQUEST" to a calendar + that object might contain a "VALARM" component. The owner may + wish to have local control over their own CUA and when or how + alarms are triggered. + + + +Royer, et al. Experimental [Page 50] + +RFC 4324 Calendar Access Protocol December 2005 + + + A CUA may add the "LOCAL" parameter to the "SEQUENCE" property + before booking the component. If the "LOCAL" parameter is set to + "TRUE", then the alarm MUST NOT be forwarded to any other + calendar. If set to "FALSE", or if the "LOCAL" parameter is not + in the "SEQUENCE" property, the alarm is global. + + Formal Definition: The property is defined by the following notation: + + local-param = "LOCAL" "=" boolean + + Example: The following is an example of this parameter: + + SEQUENCE;LOCAL=TRUE:4 + +7.6. LOCALIZE Parameter + + Parameter Name: LOCALIZE + + Purpose: If provided, specifies the desired language for error and + warning messages. + + Value Type: TEXT + + Conformance: This parameter can be specified in the "CMD" properties. + + When the "LOCALIZE" parameter is supplied, its value MUST be one + of the values listed in the initial [BEEP] greeting 'localize' + attribute. + + A CUA may add the "LOCALIZE" parameter to the "CMD" property to + specify the language of any error or warning messages. + + Formal Definition: The property is defined by the following notation: + + localize-param = ";" "LOCALIZE" "=" beep-localize + ; + beep-localize = text ; As defined in [BEEP] + ; The value supplied MUST be one value from + ; the initial [BEEP] greeting 'localize' + ; attribute, specifying the locale to use + ; for error messages during + ; this instance of the command. + + Example: The following is an example of this parameter: + + CMD;LOCALIZE=fr_CA:CREATE + + + + + +Royer, et al. Experimental [Page 51] + +RFC 4324 Calendar Access Protocol December 2005 + + +7.7. OPTIONS Parameter + + Parameter Name: OPTIONS + + Purpose: If provided the "OPTIONS" parameter specifies some "CMD" + property-specific options. + + Value Type: TEXT + + Conformance: This parameter can be specified in the "CMD" properties. + + A CUA adds the "OPTIONS" parameter to the "CMD" property when the + command needs extra values. + + Formal Definition: The property is defined by the following notation: + + option-param = ";" "OPTIONS" "=" cmd-specific + ; + cmd-specific = ; The value supplied is dependent on the + ; CMD value. See the specific CMDs for the + ; correct values to use for each CMD. + + Example: The following is an example of this parameter: + + CMD;OPTIONS=10:GENERATE-UID + +8. New Properties + +8.1. ALLOW-CONFLICT Property + + Property Name: ALLOW-CONFLICT + + Purpose: This property indicates whether or not the calendar and CS + supports component conflicts. That is, whether or not any of the + components in the calendar can overlap. + + Value Type: BOOLEAN + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VAGENDA" and + "VCALSTORE" component. + + Description: This property is used to indicate whether components may + conflict, that is, whether their expanded instances may share the + same time or overlap the same time periods. If it has a value of + + + + +Royer, et al. Experimental [Page 52] + +RFC 4324 Calendar Access Protocol December 2005 + + + "TRUE", then conflicts are allowed. If "FALSE", the no two + components may conflict. + + If "FALSE" in the "VCALSTORE" component, then all "VAGENDA" + component "ALLOW-CONFLICT" property values MUST be "FALSE" in the + CS. + + Formal Definition: The property is defined by the following notation: + + allow-conflict = "ALLOW-CONFLICT" other-params ":" boolean + CRLF + + Example: The following is an example of this property for a "VAGENDA" + component: + + ALLOW-CONFLICT:FALSE + +8.2. ATT-COUNTER Property + + Property Name: ATT-COUNTER + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be specified in an iCalendar object + that specifies a counter proposal to a group-scheduled calendar + entity. When storing a "METHOD" property with the "COUNTER" + method, there needs to be a way to remember who sent the COUNTER. + The ATT-COUNTER property MUST be added to all "COUNTER" [iTIP] + components by the CUA before storing in a CS. + + Description: This property is used to identify the CAL-ADDRESS of the + entity that sent the "COUNTER" [iTIP] object. + + Formal Definition: The property is defined by the following notation: + + attcounter = "ATT-COUNTER" other-params ":" cal-address CRLF + + Examples: + + ATT-COUNTER:cap:example.com/Doug + ATT-COUNTER:mailto:Doug@Example.com + + + + + + + + + +Royer, et al. Experimental [Page 53] + +RFC 4324 Calendar Access Protocol December 2005 + + +8.3. CALID Property + + Property Name: CALID + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in the "VAGENDA" + component. + + Description: This property is used to specify a fully-qualified + CALID. + + Formal Definition: The property is defined by the following notation: + + calid = "CALID" other-params ":" relcalid CRLF + + Example: + + CALID:cap://cal.example.com/sdfifgty4321 + +8.4. CALMASTER Property + + Property Name: CALMASTER + + Purpose: The property specifies an e-mail address of a person + responsible for the calendar store. + + Value Type: URI + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in a "VCALSTORE" + component. + + Description: The parameter value SHOULD be a MAILTO URI as defined in + [URL]. It MUST be a contact URI such as a MAILTO URI and not a home + page or file URI that describes how to contact the calmasters. + + Formal Definition: The property is defined by the following notation: + + calmaster = "CALMASTER" other-params ":" uri CRLF + ; + uri = ; IANA registered uri as defined in [iCAL]. + + Example: The following is an example of this property: + + + + +Royer, et al. Experimental [Page 54] + +RFC 4324 Calendar Access Protocol December 2005 + + + CALMASTER:mailto:administrator@example.com + +8.5. CAP-VERSION Property + + Property Name: CAP-VERSION + + Purpose: This property specifies the version of CAP supported. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property is specified in the "VREPLY" component + that is sent in response to a "GET-CAPABILITY" command. + + Description: This specifies the version of CAP that the endpoint + supports. The list is a comma-separated list of supported RFC + numbers. The list MUST contain at least 4324. + + Formal Definition: The property is defined by the following notation: + + cap-version = "CAP-VERSION" other-params ":" text CRLF + + Example: The following are examples of this property: + + CAP-VERSION:4324 + +8.6. CARID Property + + Property Name: CARID + + Purpose: This property specifies the identifier for an access right + component. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be specified once in a "VCAR" + component. + + Description: This property is used in the "VCAR" component to specify + an identifier. A "CARID" property value is unique per container. + + Formal Definition: The property is defined by the following notation: + + + + +Royer, et al. Experimental [Page 55] + +RFC 4324 Calendar Access Protocol December 2005 + + + carid = "CARID" other-params ":" text CRLF + + Example: The following are examples of this property: + + CARID:xyzzy-007 + CARID:User Rights + +8.7. CAR-LEVEL Property + + Property Name: CAR-LEVEL + + Purpose: The property specifies the level of VCAR supported. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in a "VREPLY" component + that is sent in response to a "GET-CAPABILITY" command. + + Description: The value is one from a list of "CAR-NONE", "CAR-MIN", + or "CAR-FULL-1". If "CAR-FULL-1" is supplied, then "CAR-MIN" is + also available. A "CAR-MIN" implementation only supported the + "DEFAULT-VCARS" property values listed in the "VCALSTORE" + component, and a "CAR-MIN" implementation does not support the + creation or modification of "VCAR" components from the CUA. + + Formal Definition: The property is defined by the following notation: + + car-level = "CAR-LEVEL" ":" other-params ":" + car-level-values + + car-level-values = ( "CAR-NONE" / "CAR-MIN" / "CAR-FULL-1" + / other-levels ) + + other-levels = ; Any name published in an RFC for a + ; "CAR-LEVEL" property value. + + Example: The following is an example of this property: + + CAR-LEVEL:CAR-FULL-1 + +8.8. COMPONENTS Property + + Property Name: COMPONENTS + + + + + +Royer, et al. Experimental [Page 56] + +RFC 4324 Calendar Access Protocol December 2005 + + + Purpose: The property specifies a the list of components supported by + the endpoint. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in a "VREPLY" component in + response to a "GET-CAPABILITY" command. + + Description: A comma-separated list of components that are supported + by the endpoint. A component that is not in the list sent from + the endpoint is not supported by that endpoint. Sending an + unsupported component results in unpredictable results. This + includes any components inside of other components (VALARM for + example). The recommended list is + "VCALSTORE,VCALENDAR,VREPLY,VAGENDA, + VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO,VALARM, + DAYLIGHT,STANDARD,VCAR,VRIGHT,VQUERY". + + Formal Definition: The property is defined by the following notation: + + components = "COMPONENTS" other-params ":" comp-list CRLF + ; + ; All of these MUST be supplied only once. + ; + comp-list-req = "VCALSTORE" "," "VCALENDAR" "," "VTIMEZONE" "," + "VREPLY" "," "VAGENDA" "," "STANDARD" "," + "DAYLIGHT" + ; At least one MUST be supplied. The same value + ; MUST NOT occur more than once. + ; + comp-list-min = ( "," "VEVENT") + / ( "," "VTODO") + / ( "," "VJOURNAL" ) + ; The same value MUST NOT occur + ; more than once. If "VCAR" is supplied then + ; "VRIGHT" must be supplied. + ; + comp-list-opt = ( "," "VFREEBUSY" ) / ( "," "VALARM" ) + / ( "," "VCAR" ) / ( "," "VRIGHT" ) + / ( "," "VQUERY") / ( "," x-comp ) + / ( "," iana-comp ) + ; + comp-list = comp-list-req 1*3comp-list-min *(comp-list-opt) + + Example: The following is an example of this property: + + + +Royer, et al. Experimental [Page 57] + +RFC 4324 Calendar Access Protocol December 2005 + + + COMPONENTS:VCALSTORE,VCALENDAR,VREPLY,VAGENDA, + VEVENT,VALARM,VTIMEZONE,VJOURNAL,VTODO, + DAYLIGHT,STANDARD,VFREEBUSY,VCAR,VRIGHT,VQUERY + +8.9. CSID Property + + Property Name: CSID + + Purpose: The property specifies a globally unique identifier for the + calendar store. + + Value Type: URI + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in a "VCALSTORE" + component. + + Description: The identifier MUST be globally unique. Each CS needs + its own unique identifier. The "CSID" property is the official + unique identifier for the CS. If the BEEP 'serverName' attribute + was supplied in the BEEP 'start' message, then the CSID will be + mapped to the virtual host name supplied, and the host name part + of the CSID MUST be the same as the 'serverName' value. This + allows one CS implementation to service multiple virtual hosts. + CS's are not required to support virtual hosting. If a CS does + not support virtual hosting, then it must ignore the BEEP + 'serverName' attribute. + + Formal Definition: The property is defined by the following notation: + + csid = "CSID" other-params ":" capurl CRLF + + Example: The following is an example of this property: + + CSID:cap://calendar.example.com + +8.10. DECREED Property + + Property Name: DECREED + + Purpose: This property specifies if an access right calendar + component is decreed or not. + + Value Type: BOOLEAN + + + + + +Royer, et al. Experimental [Page 58] + +RFC 4324 Calendar Access Protocol December 2005 + + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MAY be specified once in a "VCAR" + component. + + Description: This property is used in the "VCAR" component to specify + whether the component is decreed or not. If the "DECREED" + property value is "TRUE" then the CUA will be unable to change the + contents of the "VCAR" component and any attempt will fail with an + error. + + Formal Definition: The property is defined by the following notation: + + decreed = "DECREED" other-params ":" boolean CRLF + + Example: The following is an example of this property: + + DECREED:TRUE + +8.11. DEFAULT-CHARSET Property + + Property Name: DEFAULT-CHARSET + + Purpose: This property indicates the default charset. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VAGENDA" and + "VCALSTORE" calendar component. + + Description: In a "VAGENDA" component this property is used to + indicate the charset of calendar. If not specified, the default + is the first value in the "VCALSTORE" components "DEFAULT-CHARSET" + property value list. The value MUST be an IANA registered + character set as defined in [CHARREG]. + + In a "VCALSTORE" component it is a comma-separated list of charsets + supported by the CS. The first entry is the default entry for all + newly created "VAGENDA" components. The "UTF-8" value MUST be in + the "VCALSTORE" component "DEFAULT-CHARSET" property list. All + compliant + + CAP implementations (CS and CUA) MUST support at least the "UTF-8" + charset. + + + +Royer, et al. Experimental [Page 59] + +RFC 4324 Calendar Access Protocol December 2005 + + + If a charset name contains a comma (,), that comma must be + backslash-escaped in the value. + + Formal Definition: The property is defined by the following notation: + + default-charset = "DEFAULT-CHARSET" other-params ":" text + *( "," text) CRLF + + Example: The following is an example of this property for a "VAGENDA" + component: + + DEFAULT-CHARSET:Shift_JIS,UTF-8 + +8.12. DEFAULT-LOCALE Property + + Property Name: DEFAULT-LOCALE + + Purpose: This property specifies the default language for text + values. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VAGENDA" and + "VCALSTORE" components. + + Description: In a "VAGENDA" component, the "DEFAULT-LOCALE" property + is used to indicate the locale of the calendar. The full locale + SHOULD be used. The default and minimum locale is POSIX (aka the + 'C' locale). + + In a "VCALSTORE" component, it is a comma-separated list of + locales supported by the CS. The first value in the list is the + default for all newly created VAGENDAs. "POSIX" MUST be in the + list. + + Formal Definition: The property is defined by the following notation: + + default-locale = "DEFAULT-LOCALE" other-params ":" language + *( "," language) CRLF + ; + language = ; Text identifying a locale, as defined in [CHARPOL] + + Example: The following is an example of this property: + + DEFAULT-LOCALE:en-US.iso-8859-1,POSIX + + + +Royer, et al. Experimental [Page 60] + +RFC 4324 Calendar Access Protocol December 2005 + + +8.13. DEFAULT-TZID Property + + Property Name: DEFAULT-TZID + + Purpose: This property specifies the text value that specifies the + time zones. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property may be specified once in a "VAGENDA" and + "VCALSTORE" components. + + Description: A multi-valued property that lists the known time zones. + The first is the default. Here "TZID" property values are the + same as the "TZID" property defined in [iCAL]. + + If used in a "VCALSTORE" component, it is a comma-separated list + of TZIDs known to the CS. The entry is used as the default TZID + list for all newly created calendars. The list MUST contain at + least "UTC". A "VCALSTORE" components MUST contain one + "VTIMEZONE" component for each value in the "DEFAULT-TZID" + property value. + + If used in a "VAGENDA" component, it is a comma-separated list of + "TZID" property values naming the time zones known to the + calendar. The first time zone in the list is the default and is + used as the localtime for objects that contain a date or date-time + value without a time zone. All "VAGENDA" components MUST have one + "VTIMEZONE" component contained for each value in the "DEFAULT- + TZID" property value. + + If a "TZID" property value contains a comma (,), the comma must be + backslash-escaped. + + Formal Definition: This property is defined by the following + notation: + + default-tzid = "DEFAULT-TZID" other-params + ":" [tzidprefix] text + *("," [tzidprefix] text) CRLF + ; + txidprefix = ; As defined in [iCAL]. + + Example: The following is an example of this property: + + + + +Royer, et al. Experimental [Page 61] + +RFC 4324 Calendar Access Protocol December 2005 + + + DEFAULT-TZID:US/Mountain,UTC + +8.14. DEFAULT-VCARS Property + + Property Name: DEFAULT-VCARS + + Purpose: This property is used to specify the "CARID" property ids of + the default "VCAR" components for newly created "VAGENDA" + components. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be specified in "VCALSTORE" calendar + component and MUST at least specify the following values: + "READBUSYTIMEINFO", "REQUESTONLY", "UPDATEPARTSTATUS", and + "DEFAULTOWNER". + + Description: This property is used in the "VCALSTORE" component to + specify the "CARID" value of the "VCAR" components that MUST be + copied into now "VAGENDA" components at creation time by the CS. + All "DEFAULT-VCAR" values must have "VCARS" components stored in + the "VCALSTORE". + + Formal Definition: The property is defined by the following notation: + + defautl-vcars = "DEFAULT-VCARS" other-params ":" text + *( "," text ) CRLF + + Example: The following is an example of this property: + + DEFAULT-VCARS:READBUSYTIMEINFO,REQUESTONLY, + UPDATEPARTSTATUS,DEFAULTOWNER + +8.15. DENY Property + + Property Name: DENY + + Purpose: This property identifies the UPN(s) being denied access in + the "VRIGHT" component. + + Value Type: UPN-FILTER + + Property Parameters: Non-standard property parameters can be + specified on this property. + + + + +Royer, et al. Experimental [Page 62] + +RFC 4324 Calendar Access Protocol December 2005 + + + Conformance: This property can be specified in "VRIGHT" components. + + Description: This property is used in the "VRIGHT" component to + define the CU or UG being denied access. + + Formal Definition: The property is defined by the following notation: + + deny = "DENY" other-params ":" upn-filter CRLF + + Example: The following are examples of this property: + + DENY:* + + DENY:bob@example.com + +8.16. EXPAND property + + Property Name: EXPAND + + Purpose: This property is used to notify the CS whether to expand any + component with recurrence rules into multiple instances, in a + query reply. + + Value Type: BOOLEAN + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VQUERY" components. + + Description: If a CUA wishes to see all of the instances of a + recurring component, the CUA sets EXPAND=TRUE in the "VQUERY" + component. If not specified, the default is "FALSE". Note that + if the CS has its "RECUR-EXPAND" CS property value set to "FALSE", + then the "EXPAND" property will be ignored and the result will be + as if the "EXPAND" value was set to "FALSE". The results will be + bounded by any date range or other limits in the query. + + Formal Definition: The property is defined by the following notation: + + expand = "EXPAND" other-params ":" ("TRUE" / "FALSE") CRLF + + Example: The following are examples of this property: + + EXPAND:FALSE + EXPAND:TRUE + + + + + +Royer, et al. Experimental [Page 63] + +RFC 4324 Calendar Access Protocol December 2005 + + +8.17. GRANT Property + + Property Name: GRANT + + Purpose: This property identifies the UPN(s) being granted access in + the "VRIGHT" component. + + Value Type: UPN-FILTER + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VRIGHT" calendar + components. + + Description: This property is used in the "VRIGHT" component to + specify the CU or UG being granted access. + + Formal Definition: The property is defined by the following notation: + + grant = "GRANT" other-params ":" upn-filter CRLF + + Example: The following are examples of this property: + + GRANT:* + + GRANT:bob@example.com + +8.18. ITIP-VERSION Property + + Property Name: ITIP-VERSION + + Purpose: This property specifies the version of ITIP supported. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property is specified in the "VREPLY" component + that is sent in response to a "GET-CAPABILITY" command. + + Description: This specifies the version of ITIP that the endpoint + supports. The list is a comma-separated list of supported RFC + numbers. The list MUST contain at least 2446, which is [iTIP] + + Formal Definition: The property is defined by the following notation: + + + + +Royer, et al. Experimental [Page 64] + +RFC 4324 Calendar Access Protocol December 2005 + + + itip-version = "ITIP-VERSION" other-params ":" text CRLF + + Example: The following are examples of this property: + + ITIP-VERSION:2446 + +8.19. MAX-COMP-SIZE Property + + Property Name: MAX-COMP-SIZE + + Purpose: This property specifies the largest size of any object + accepted. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property is specified in the "VREPLY" component + that is sent in response to a "GET-CAPABILITY" command. + + Description: A positive integer value that specifies the size of the + largest iCalendar object that can be accepted in octets. Objects + larger than this will be rejected. A value of zero (0) means no + limit. This is also the maximum value of any [BEEP] payload that + will be accepted or sent. + + Formal Definition: The property is defined by the following notation: + + max-comp-size = "MAX-COMP-SIZE" other-params ":" posint0 CRLF + + Example: The following are examples of this property: + + MAX-COMP-SIZE:1024 + +8.20. MAXDATE Property + + Property Name: MAXDATE + + Purpose: This property specifies the date/time in the future, beyond + which the CS or CUA cannot represent. + + Value Type: DATE-TIME + + Property Parameters: Non-standard property parameters can be + specified on this property. + + + + + +Royer, et al. Experimental [Page 65] + +RFC 4324 Calendar Access Protocol December 2005 + + + Conformance: The property can be specified in the "VCALSTORE" + component. + + Description: The date and time MUST be a UTC value and end with 'Z'. + + Formal Definition: The property is defined by the following notation: + + maxdate = "MAXDATE" other-params ":" date-time CRLF + + Example: The following is an example of this property: + + MAXDATE:20990101T000000Z + +8.21. MINDATE Property + + Property Name: MINDATE + + Purpose: This property specifies the date/time in the past, prior to + which the server cannot represent. + + Value Type: DATE-TIME + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in the "VCALSTORE" + component. + + Description: The date and time MUST be a UTC value and end with 'Z'. + + Formal Definition: The property is defined by the following notation: + + mindate = "MINDATE" other-params ":" date-time CRLF + + date-time = ; As defined in [iCAL]. + + Example: The following is an example of this property: + + MINDATE:19710101T000000Z + +8.22. MULTIPART Property + + Property Name: MULTIPART + + Purpose: This property provides a comma-separated list of supported + MIME multipart types supported by the sender. + + + + + +Royer, et al. Experimental [Page 66] + +RFC 4324 Calendar Access Protocol December 2005 + + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property is specified in the "VREPLY" component + that is sent in response to a "GET-CAPABILITY" command. + + Description: This property is used in the in the "GET-CAPABILITY" + command reply to indicate the MIME multipart types supported. A + CS and CUA SHOULD support all registered MIME multipart types. + + Formal Definition: The property is defined by the following notation: + + multipart = "MULTIPART" other-params ":" text *( "," text) CRLF + + Example: The following is an example of this property: + + MULTIPART:related,alternate,mixed + +8.23. NAME Property + + Property Name: NAME + + Purpose: This property provides a localizable display name for a + component. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in a component. + + Description: This property is used in the component to specify a + localizable display name. If more than one "NAME" properties are + in a component, then they MUST have unique "LANG" parameters. If + the "LANG" parameter is not supplied, then it defaults to the + "VAGENDA" component's "DEFAULT-LOCALE" first value. If the + component is a "VAGENDA", then the default value is the "VAGENDA"s + component's "DEFAULT-LOCALE" first value. A "VCALSTORE" + component's "DEFAULT-LOCALE" first value is the default if the + component is stored at the "VCALSTORE" level. + + Formal Definition: The property is defined by the following notation: + + + + + + +Royer, et al. Experimental [Page 67] + +RFC 4324 Calendar Access Protocol December 2005 + + + name = "NAME" nameparam ":" text CRLF + ; + nameparam = other-params [ ";" languageparam ] other-params + ; + languageparam = ; As defined in [iCAL]. + + Example: The following is an example of this property: + + NAME:Restrict Guests From Creating VALARMs On VEVENTs + +8.24. OWNER Property + + Property Name: OWNER + + Purpose: The property specifies an owner of the component. + + Value Type: UPN + + Property Parameters: Non-standard, alternate text representation and + language property parameters can be specified on this property. + + Conformance: The property MUST be specified in a "VAGENDA" component. + + Description: A multi-instanced property indicating the calendar + owner. + + Formal Definition: The property is defined by the following notation: + + owner = "OWNER" other-params ":" upn CRLF + + Example: The following is an example of this property: + + OWNER:jsmith@example.com + OWNER:jdough@example.com + +8.25. PERMISSION Property + + Property Name: PERMISSION + + Purpose: This property defines a permission that is granted or denied + in a "VRIGHT" component. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VRIGHT" components. + + + +Royer, et al. Experimental [Page 68] + +RFC 4324 Calendar Access Protocol December 2005 + + + Description: This property is used in the "VRIGHT" component to + define a permission that is granted or denied. + + Formal Definition: The property is defined by the following notation: + + permission = "PERMISSION" other-params ":" permvalue CRLF + ; + permvalue = ( "SEARCH" / "CREATE" / "DELETE" + / "MODIFY" / "MOVE" / all + / iana-cmd / x-cmd ) + ; + all = "*" + ; + iana-cmd = ; Any command registered by IANA directly or + ; included in an RFC that may be applied as + ; a command. + ; + x-cmd = ; Any experimental command that starts with + ; "x-" or "X-". + + Example: The following is an example of this property: + + PERMISSION:SEARCH + +8.26. QUERY property + + Property Name: QUERY + + Purpose: Specifies the query for the component. + + Value Type: CAL-QUERY + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VQUERY" components. + + Description: A "QUERY" is used to specify the "CAL-QUERY" (Section + 6.1.1 for the query. + + Formal Definition: The property is defined by the following notation: + + query = "QUERY" other-params ":" cal-query CRLF + + Example: The following is an example of this property: + + QUERY:SELECT * FROM VEVENT + + + + +Royer, et al. Experimental [Page 69] + +RFC 4324 Calendar Access Protocol December 2005 + + +8.27. QUERYID property + + Property Name: QUERYID + + Purpose: Specifies a unique ID for a query in the targeted container. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters are specified + on this property. + + Conformance: This property can be specified in "VQUERY" components. + + Description: A "QUERYID" property is used to specify the unique id + for a query. A "QUERYID" property value is unique per container. + + Formal Definition: The property is defined by the following notation: + + queryid = "QUERYID" other-params ":" text CRLF + + Example: The following are examples of this property: + + QUERYID:Any Text String + QUERYID:fetchUnProcessed + +8.28. QUERY-LEVEL Property + + Property Name: QUERY-LEVEL + + Purpose: This property specifies the level of query supported. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in the "VREPLY" component + in response to a "GET-CAPABILITY" command. + + Description: Indicates level of query support. CAL-QL-NONE is for + CS's that allow ITIP methods only to be deposited and nothing + else. + + Formal Definition: The property is defined by the following notation: + + query-level = "QUERY-LEVEL" other-params + ":" ( "CAL-QL-1" / "CAL-QL-NONE") CRLF + + + + +Royer, et al. Experimental [Page 70] + +RFC 4324 Calendar Access Protocol December 2005 + + + Example: The following is an example of this property: + + QUERY-LEVEL:CAL-QL-1 + +8.29. RECUR-ACCEPTED Property + + Property Name: RECUR-ACCEPTED + + Purpose: This property specifies if the endpoint supports recurring + instances. + + Value Type: BOOLEAN + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in the "VREPLY" component + in response to a "GET-CAPABILITY" command. + + Description: Indicates if recurrence rules are supported. If "FALSE" + then the endpoint cannot process any kind of recurring rules. + + Formal Definition: The property is defined by the following notation: + + recur-accepted = "RECUR-ACCEPTED" other-params ":" boolean CRLF + + Example: The following is an example of this property: + + RECUR-ACCEPTED:TRUE + RECUR-ACCEPTED:FALSE + +8.30. RECUR-LIMIT Property + + Property Name: RECUR-LIMIT + + Purpose: This property specifies the maximum number of instances the + endpoint will expand instances at query or storage time. + + Value Type: INTEGER + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in the "VREPLY" component + in response to a "GET-CAPABILITY" command. + + Description: For implementations that have the "STORES-EXPANDED" + value set to "TRUE", this value specifies the maximum number of + + + +Royer, et al. Experimental [Page 71] + +RFC 4324 Calendar Access Protocol December 2005 + + + instances that will be stored and fetched. For all + implementations, this is the maximum number of instances that will + be returned when the "EXPAND" parameter is specified as "TRUE" and + the results contain an infinite or large number of recurring + instances. + + Formal Definition: The property is defined by the following notation: + + recur-limit = "RECUR-LIMIT" other-params ":" posint1 CRLF + + Example: The following is an example of this property: + + RECUR-LIMIT:1000 + +8.31. RECUR-EXPAND Property + + Property Name: RECUR-EXPAND + + Purpose: This property specifies if the endpoint can expand + recurrences into multiple objects. + + Value Type: BOOLEAN + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in the "VREPLY" component + in response to a "GET-CAPABILITY" command. + + Description: If "TRUE", then the endpoint can expand an object into + multiple instances as defined by its recurrence rules when the + "EXPAND" property is supplied. If "FALSE", then the endpoint + ignores the "EXPAND" property. + + Formal Definition: The property is defined by the following notation: + + recur-expand = "RECUR-EXPAND" other-params ":" boolean CRLF + + Example: The following is an example of this property: + + RECUR-EXPAND:TRUE + RECUR-EXPAND:FALSE + +8.32. RESTRICTION Property + + Property Name: RESTRICTION + + + + + +Royer, et al. Experimental [Page 72] + +RFC 4324 Calendar Access Protocol December 2005 + + + Purpose: This property defines restrictions on the result value of + new or existing components. + + Value Type: CAL-QUERY + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VRIGHT" components, + but only when the "PERMISSION" property is set to "CREATE", + "MODIFY", or "*" property value. + + Description: This property is used in the "VRIGHT" component to + define restrictions on the components that can be written (i.e., + by using the "CREATE" or "MOVE" commands) as well as on the values + that may take existent calendar store properties, calendar + properties, components, and properties (i.e., by using the + "MODIFY" command). Accepted values MUST match any specified + "RESTRICTION" property values. + + Formal Definition: The property is defined by the following notation: + + restriction = "RESTRICTION" other-params ":" cal-query CRLF + + Example: The following are examples of this property: + + RESTRICTION:SELECT * FROM VCALENDAR WHERE METHOD = 'REQUEST' + + RESTRICTION:SELECT * FROM VEVENT WHERE + SELF() IN ORGANIZER + + RESTRICTION:SELECT * FROM VEVENT WHERE 'BUSINESS' IN + CATEGORIES + +8.33. SCOPE Property + + Property Name: SCOPE + + Purpose: This property identifies the objects in the CS to which the + access rights apply. + + Value Type: CAL-QUERY + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VRIGHT" components. + + + + +Royer, et al. Experimental [Page 73] + +RFC 4324 Calendar Access Protocol December 2005 + + + Description: This property is used in the "VRIGHT" component to + define the set of objects, subject to the access right being + defined. + + Formal Definition: The property is defined by the following notation: + + scope = "SCOPE" other-params ":" cal-query CRLF + + Example: The following is an example of this property: + + SCOPE:SELECT DTSTART,DTEND FROM VEVENT WHERE CLASS = 'PUBLIC' + +8.34. STORES-EXPANDED Property + + Property Name: STORES-EXPANDED + + Purpose: This property specifies if the sending endpoint expands + recurrence rules prior to storing them into the CS. + + Value Type: BOOLEAN + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in a "VREPLY" component + in response to a "GET-CAPABILITY" command. + + Description: If the value is "TRUE", then the endpoint expands + recurrence rules and stores the results into the CS. If this is + "TRUE", then the "RECUR-LIMIT" property is significant because an + infinitely-recurring appointment will store no more than "RECUR- + LIMIT" property values into the CS and all other instances will be + lost. + + Formal Definition: The property is specified by the following + notation: + + stores-expanded = "STORES-EXPANDED" other-params ":" boolean + CRLF + + The following is an example of this property: + + STORES-EXPANDED:TRUE + STORES-EXPANDED:FALSE + +8.35. TARGET Property + + Property Name: TARGET + + + +Royer, et al. Experimental [Page 74] + +RFC 4324 Calendar Access Protocol December 2005 + + + Purpose: This property defines the container that the issued command + will act upon. Its value is a capurl, as defined in Section 5. + + Value Type: URI + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in a command component. + + Description: This property value is used to specify the container + that the command will effect. When used in a command, the command + will be performed on the container that has a capurl matching the + value. + + Formal Definition: The property is specified by the following + notation: + + target = "TARGET" other-params ":" ( capurl / relcalid ) CRLF + + Example: The following is an example of this property: + + TARGET:cap://mycal.example.com + TARGET:SomeRelCalid + +8.36. TRANSP Property + + Property Name: TRANSP + + Purpose: This property defines whether a component is transparent or + not to busy-time searches. This is a modification to [iCAL] + "TRANSP" property, in that it adds some values. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in a component. + + Description: Time Transparency is the characteristic of an object + that determines whether it appears to consume time on a calendar. + Objects that consume actual time for the individual or resource + associated with the calendar SHOULD be recorded as "OPAQUE", + allowing them to be detected by free-busy time searches. Other + objects, which do not take up the individual's (or resource's) + time SHOULD be recorded as "TRANSPARENT", making them invisible to + free/busy time searches. + + + +Royer, et al. Experimental [Page 75] + +RFC 4324 Calendar Access Protocol December 2005 + + + Formal Definition: The property is specified by the following + notation: + + transp = "TRANSP" other-params ":" transvalue CRLF + ; + transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. + + / "TRANSPARENT" + ; Transparent on busy time searches. + + / "TRANSPARENT-NOCONFLICT" + ; Transparent on busy time searches, + ; and no other OPAQUE or OPAQUE- + ; NOCONFLICT objects can overlap it. + ; + / "OPAQUE-NOCONFLICT" + ; Opaque on busy time searches, and + ; no other OPAQUE or OPAQUE-NOCONFLICT + ; objects can overlap it. + ; + ; Default value is OPAQUE + + The following is an example of this property for an object that is + opaque or blocks on free/busy time searches, and no other object + can overlap it: + + TRANSP:OPAQUE-NOCONFLICT + +9. New Components + +9.1. VAGENDA Component + + Component Name: VAGENDA + + Purpose: Provide a grouping of properties that defines an agenda. + + Formal Definition: There are two formats of the "VAGENDA" component. + (1) When it is being created, and (2) how it exists in the + "VCALSTORE" component. + + A "VAGENDA" component in a "VCALSTORE" component is defined by the + following notes and ABNF notation: + + CALSCALE - The value MUST be from the "VCALSTORE" "CALSCALE" + property list. The default is the first entry in the + VCALSTORE CALSCALE list. + + CREATED - The timestamp of the calendar's create date. This + + + +Royer, et al. Experimental [Page 76] + +RFC 4324 Calendar Access Protocol December 2005 + + + is a READ ONLY property in a "VAGENDA". + + LAST-MODIFIED - The timestamp of any change to the "VAGENDA" + properties or when any component was last created, modified, + or deleted. + + agenda = "BEGIN" ":" "VAGENDA" CRLF + agendaprop + *(icalobject) ; as defined in [iCAL] + "END" ":" "VAGENDA" CRLF + + agendaprop = *( + ; The following MUST occur exactly once. + ; + allow-conflict / relcalid / calscale / created + / default-charset / default-locale + / default-tzid / last-mod + ; + ; The following MUST occur at least once. + ; and the value MUST NOT be empty. + ; + / owner + ; + ; The following are optional, + ; and MAY occur more than once. + ; + / name / related-to / other-props / x-comp + ) + + icalobject = ; As defined in [iCAL]. + ; + created = ; As defined in [iCAL]. + ; + related-to = ; As defined in [iCAL]. + + When creating a VAGENDA, use the following notation: + + agendac = "BEGIN" ":" "VAGENDA" CRLF + agendacprop + *(icalobject) ; as defined in [iCAL]. + "END" ":" "VAGENDA" CRLF + + agendacprop = *( + ; The following MUST occur exactly once. + ; + allow-conflict / relcalid / calscale + / default-charset / default-locale + / default-tzid + + + +Royer, et al. Experimental [Page 77] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; + ; The following MUST occur at least once. + ; and the value MUST NOT be empty. + ; + / owner + ; + ; The following are optional, + ; and MAY occur more than once. + ; + / name / related-to / other-props / x-comp + ) + + To fetch all of the properties from the targeted "VAGENDA" component + but do not fetch any components, use: + + SELECT * FROM VAGENDA + + To fetch all of the properties from the targeted VAGENDA and all of + the contained components, use the special '*.*' value: + + SELECT *.* FROM VAGENDA + +9.2. VCALSTORE Component + + Component Name: VCALSTORE + + Purpose: Provide a grouping of properties that defines a calendar + store. + + Formal Definition: A "VCALSTORE" component is defined by the + following table and ABNF notation. The creation of a "VCALSTORE" + component is an administrative task and not part of the CAP + protocol. + + The following are notes to some of the properties in the + "VCALSTORE" component. + + CALSCALE - A comma-separated list of CALSCALEs supported by + this CS. All "VAGENDA" component calendar CALSCALE + properties MUST be from this list. This list MUST contain + at least "GREGORIAN". The default for newly created + "VAGENDA" components is the first entry. + + RELATED-TO - This is a multiple-instance property. There MUST + be a "RELATED-TO" property for each of the "VAGENDA" + components contained in the "VCALSTORE" component, each with + the "RELTYPE" parameter value set to "CHILD". Other + "RELATED-TO" properties may be included. + + + +Royer, et al. Experimental [Page 78] + +RFC 4324 Calendar Access Protocol December 2005 + + + CREATED - The timestamp of the CS creation time. This is a + READ ONLY property. + + CSID - The CSID of this calendar store. This MUST NOT be + empty. How this property is set in the VCALSTORE is an + administrative or implementation-specific issue and is not + covered in CAP. This is a READ ONLY property. A suggested + value is the fully-qualified host name or a fully-qualified + virtual host name supported by the system. + + LAST-MODIFIED - The timestamp when the Properties of the + "VCALSTORE" component were last updated or calendars were + created or deleted. This is a READ ONLY PROPERTY. + + calstorec = "BEGIN" ":" "VCALSTORE" CRLF + calstoreprop + *(vagendac) + "END" ":" "VCALSTORE" CRLF + ; + calstoreprop = *( + ; the following MUST occur exactly once + ; + allow-conflict / calscale / calmaster + / created / csid / default-charset + / default-locale / default-vcars + / default-tzid / last-mod / maxdate / mindate + ; + ; the following are optional, + ; and MAY occur more than once + ; + / name / related-to / other-props / x-comp + ) + ; + + vagendac = ; As defined in [iCAL]. + ; + last-mod = ; As defined in [iCAL]. + + To fetch all of the properties from the targeted VCALSTORE and not + fetch the calendars that it contains, use: + + SELECT * FROM VCALSTORE + + To fetch all of the properties from the targeted "VCALSTORE" + component and all of the contained calendars and all of those + calendars' contained properties and components, use the special '*.*' + value: + + + + +Royer, et al. Experimental [Page 79] + +RFC 4324 Calendar Access Protocol December 2005 + + + SELECT *.* FROM VCALSTORE + +9.3. VCAR Component + + Component Name: VCAR + + Purpose: Provide a grouping of calendar access rights. + + Formal Definition: A "VCAR" component is defined by the following + notation: + + carc = "BEGIN" ":" "VCAR" CRLF + carprop 1*rightc + "END" ":" "VCAR" CRLF + ; + carprop = 1*( + ; + ; 'carid' is REQUIRED, + ; but MUST NOT occur more than once + ; + carid / + ; + ; the following are OPTIONAL, + ; and MAY occur more than once + ; + name / decreed / other-props + ) + + Description: A "VCAR" component is a grouping of properties, and + "VRIGHT" components, that represents access rights granted or + denied to UPNs. + + The "CARID" property specifies the local identifier for the "VCAR" + component. The "NAME" property specifies a localizable display + name. + + Example: In the following example, the UPN "foo@example.com" is given + search access to the "DTSTART" and "DTEND" VEVENT properties. No + other access is specified: + + + + + + + + + + + + +Royer, et al. Experimental [Page 80] + +RFC 4324 Calendar Access Protocol December 2005 + + + BEGIN:VCAR + CARID:View Start and End Times + NAME:View Start and End Times + BEGIN:VRIGHT + GRANT:foo@example.com + PERMISSION:SEARCH + SCOPE:SELECT DTSTART,DTEND FROM VEVENT + END:VRIGHT + END:VCAR + + In this example, all UPNs are given search access to "DTSTART" and + "DTEND" properties of VEVENT components. "All CUs and UGs" are + specified by the UPN value "*". Note that this enumerated UPN + value is not in quotes: + + BEGIN:VCAR + CARID:ViewStartEnd2 + NAME:View Start and End Times 2 + BEGIN:VRIGHT + GRANT:* + PERMISSION:SEARCH + SCOPE:SELECT DTSTART,DTEND FROM VEVENT + END:VRIGHT + END:VCAR + + In these examples, full calendar access rights are given to the + CAL-OWNERS(), and a hypothetical administrator is given access + rights to specify calendar access rights. If no other rights are + specified, only these two UPNs can specify calendar access rights: + + BEGIN:VCAR + CARID:some-id-3 + NAME:Only OWNER or ADMIN Settable VCARs + BEGIN:VRIGHT + GRANT:CAL-OWNERS() + PERMISSION:* + SCOPE:SELECT * FROM VAGENDA + END:VRIGHT + BEGIN:VRIGHT + GRANT:cal-admin@example.com + PERMISSION:* + SCOPE:SELECT * FROM VCAR + RESTRICTION:SELECT * FROM VCAR + END:VRIGHT + END:VCAR + + In this example, rights to write, search, modify or delete + calendar access are denied to all UPNs. This example would + + + +Royer, et al. Experimental [Page 81] + +RFC 4324 Calendar Access Protocol December 2005 + + + disable providing different access rights to the calendar store or + calendar. This calendar access right should be specified with + great care, as it removes the ability to change calendar access; + even for the owner or administrator. It could be used by small + devices that do not support changing any VCAR: + + BEGIN:VCAR + CARID:VeryRestrictiveVCAR-2 + NAME:No CAR At All + BEGIN:VRIGHT + DENY:* + PERMISSION:* + SCOPE:SELECT * FROM VCAR + END:VRIGHT + END:VCAR + +9.4. VRIGHT Component + + Component Name: "VRIGHT" + + Purpose: Provide a grouping of properties that describe an access + right (granted or denied). + + Formal Definition: A "VRIGHT" component is defined by the following + notation: + + rightc = "BEGIN" ":" "VRIGHT" CRLF + rightprop + "END" ":" "VRIGHT" CRLF + ; + rightprop = 2*( + ; + ; either 'grant' or 'deny' MUST + ; occur at least once + ; and MAY occur more than once + ; + grant / deny / + ; + ; 'permission' MUST occur at least once + ; and MAY occur more than once + ; + permission / + ; + ; the following are optional, + ; and MAY occur more than once + ; + scope / restriction / other-props + ) + + + +Royer, et al. Experimental [Page 82] + +RFC 4324 Calendar Access Protocol December 2005 + + + Description: A "VRIGHT" component is a grouping of calendar access + right properties. + + The "GRANT" property specifies the UPN that is being granted + access. The "DENY" property specifies the UPN that is being + denied access. The "PERMISSION" property specifies the actual + permission being set. The "SCOPE" property identifies the + calendar store properties, calendar properties, components, or + properties to which the access right applies. The "RESTRICTION" + property specifies restrictions on commands and results. If the + command does not match the restrictions, or if the results of the + command do not match the restrictions, then it is an access + violation. + +9.5. VREPLY Component + + Component Name: "VREPLY" + + Purpose: Provide a grouping of arbitrary properties and components + that are the data set result from an issued command. + + Formal Definition: A "VREPLY" component is defined by the following + notation: + + replyc = "BEGIN" ":" "VREPLY" CRLF + any-prop-or-comp + "END" ":" "VREPLY" CRLF + ; + any-prop-or-comp = ; Zero or more iana or experimental + ; properties and components, in any order. + + + Description: Provide a grouping of arbitrary properties and + components that are the data set result from an issued command. + + A query can return a predictable set of arbitrary properties and + components. This component is used by query and other commands to + return data that does not fit into any other component. It may + contain any valid property or component, even if they are not + registered. + +9.6. VQUERY Component + + Component Name: VQUERY + + Purpose: A component describes a set of objects to be acted upon. + + + + + +Royer, et al. Experimental [Page 83] + +RFC 4324 Calendar Access Protocol December 2005 + + + Formal Definition: A "VQUERY" component is defined by the following + notation: + + queryc = "BEGIN" ":" "VQUERY" CRLF + queryprop + "END" ":" "VCAR" CRLF + ; + queryprop = 1*( + ; + ; 'queryid' is OPTIONAL but MUST NOT occur + ; more than once. If the "TARGET" property + ; is supplied then the "QUERYID" property + ; MUST be supplied. + ; + queryid / target + ; + ; 'expand' is OPTIONAL but MUST NOT occur + ; more than once. + ; + expand + ; + ; the following are OPTIONAL, and MAY occur + ; more than once + ; + / name / other-props + ; + ; the following MUST occur at least once if + ; queryid is not supplied. + ; + / query + ) + + Description: A "VQUERY" contains properties that describe which + properties and components the CS is requested to act upon. + + The "QUERYID" property specifies the local identifier for a + "VQUERY" component. + + For a search, if the "TARGET" property is supplied in a "VQUERY" + component, then the CS is to search for the query in the CALID + supplied by the "TARGET" property value. + + For a create, the "TARGET" property MUST NOT be supplied because + the destination container is already supplied in the "TARGET" + property of the "VCALENDAR" component. + + Examples: see Section 6.1.1. + + + + +Royer, et al. Experimental [Page 84] + +RFC 4324 Calendar Access Protocol December 2005 + + +10. Commands and Responses + + CAP commands and responses are described in this section. + +10.1. CAP Commands (CMD) + + All commands are sent using the CMD property. + + Property Name: CMD + + Purpose: This property defines the command to be sent. + + Value Type: TEXT + + Property Parameters: Non-standard, id, localize, latency, action or + options. + + Conformance: This property is the method used to specify the commands + to a CS; it can exist in any object sent to the CS. + + Description: All of the commands to the CS are supplied in this + property. The "OPTIONS" parameter is overloaded and its meaning + is dependent on the CMD value supplied. + + Formal Definition: The property is defined by the following + notation: + + cmd = "CMD" ( + abort-cmd + / continue-cmd + / create-cmd + / delete-cmd + / generate-uid-cmd + / get-capability-cmd + / identify-cmd + / modify-cmd + / move-cmd + / reply-cmd + / search-cmd + / set-locale-cmd + / iana-cmd + / x-cmd + ) CRLF + ; + option-value = "OPTION" "=" paramtext + ; + paramtext ; As defined in [iCAL]. + + + + +Royer, et al. Experimental [Page 85] + +RFC 4324 Calendar Access Protocol December 2005 + + + Calendaring commands allow a CUA to directly manipulate a calendar. + + Calendar access rights can be granted or denied for any commands. + +10.1.1. Bounded Latency + + A CAP command can have an associated maximum latency time by + specifying the "LATENCY" parameter. If the command is unable to be + completed in the specified amount of time (as specified by the + "LATENCY" parameter value with an "ACTION" parameter set to the "ASK" + value), then a "TIMEOUT" command MUST be sent on the same channel". + The reply MUST be a an "ABORT" or a "CONTINUE" command. If the CUA + initiated the original command, then the CS would issue the "TIMEOUT" + command and the CUA would then have to issue an "ABORT" or "CONTINUE" + command. If the CS initiated the original command then the CUA would + have to issue the "TIMEOUT" and the CS would send the "ABORT" or + "CONTINUE". + + Upon receiving an "ABORT" command, the command must then be + terminated. Only the "ABORT", "TIMEOUT", "REPLY, and "CONTINUE" + commands cannot be aborted. The "ABORT", "TIMEOUT", and "REPLY" + commands MUST NOT have latency set. + + Upon receiving a "CONTINUE" command the work continues as if it had + not been delayed or stopped. Note that a new latency time MAY be + included in a "CONTINUE" command indicating to continue the original + command until the "LATENCY" parameter value expires or the results of + the original command can be returned. + + Both the "LATENCY" parameter and the "ACTION" parameter MUST be + supplied to any "CMD" property, or nether can be added to the "CMD" + property. The "LATENCY" parameter MUST be set to the maximum latency + time in seconds. The "ACTION" parameter accepts the following + values: "ASK" and "ABORT" parameters. + + If the maximum latency time is exceeded and the "ACTION" parameter is + set to the "ASK" value, then "TIMEOUT" command MUST be sent. + Otherwise, if the "ACTION" parameter is set to the "ABORT" value, + then the command MUST be terminated and return a REQUEST-STATUS code + of 2.0.3 for the original command. + + If a CS can both start sending the reply to a command and guarantee + that all of the results can be sent from a command (short of + something like network or power failure) prior to the "LATENCY" + timeout value, then the "LATENCY" time has not expired. + + Example: + + + + +Royer, et al. Experimental [Page 86] + +RFC 4324 Calendar Access Protocol December 2005 + + + In this example the initiator asks for the listeners capabilities. + + I: Content-Type: text/calendar + I: + I: BEGIN:VCALENDAR + I: VERSION:2.0 + I: PRODID:The CUA's PRODID + I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:GET-CAPABILITY + I: END:VCALENDAR + + # After 3 seconds + + L: Content-Type: text/calendar + L: + L: BEGIN:VCALENDAR + L: PRODID:-//someone's prodid + L: VERSION:2.0 + L: CMD;ID=xyz12346:TIMEOUT + L: END:VCALENDAR + + In order to continue and give the CS more time, the CUA would issue a + "CONTINUE" command: + + I: Content-Type: text/calendar + I: + I: BEGIN:VCALENDAR + I: VERSION:2.0 + I: PRODID:-//someone's prodid + I: CMD;ID=xyz12346;LATENCY=3;ACTION=ask:CONTINUE + I: END:VCALENDAR + + L: Content-Type: text/calendar + L: + L: BEGIN:VCALENDAR + L: VERSION:2.0 + L: PRODID:-//someone's prodid + L: CMD;ID=xyz12346:REPLY + L: BEGIN:VREPLY + L: REQUEST-STATUS:2.0.3;Continued for 3 more seconds + L: END:VREPLY + L: END:VCALENDAR + + Here the "2.0.3" status is returned because it is not an error, it is + a progress status sent in reply to the "CONTINUE" command. + + To abort the command and not wait any further, issue an "ABORT" + command: + + + + +Royer, et al. Experimental [Page 87] + +RFC 4324 Calendar Access Protocol December 2005 + + + I: Content-Type: text/calendar + I: + I: BEGIN:VCALENDAR + I: VERSION:2.0 + I: PRODID:-//someone's prodid + I: CMD;ID=xyz12346:ABORT + I: END:VCALENDAR + + # Which would result in a 2.0.3 reply. + + L: Content-Type: text/calendar + L: + L: BEGIN:VCALENDAR + L: VERSION:2.0 + L: PRODID:-//someone's prodid + L: CMD;ID=xyz12346:REPLY + L: BEGIN:VREPLY + L: REQUEST-STATUS:2.0.3;Aborted As Requested. + L: END:VREPLY + L: END:VCALENDAR + + If the "ACTION" value had been set to "ABORT", then the listner would + send a "7.0" error on timeout in the reply to the command that + initiated the command that timed out. + +10.2. ABORT Command + + CMD: ABORT + + Purpose: The "ABORT" command is sent to request that the named or the + only in-process command be aborted. Latency MUST not be supplied + with the "ABORT" command. + + Formal Definition: An "ABORT" command is defined by the following + notation: + + + + + + + + + + + + + + + + +Royer, et al. Experimental [Page 88] + +RFC 4324 Calendar Access Protocol December 2005 + + + abort-cmd = abortparam ":" "ABORT" + ; + abortparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ) + + The REPLY of any "ABORT" command is: + + abort-reply = "BEGIN" ":" "VCALENDAR" CRLF + calprops + abort-vreply + "END" ":" "VCALENDAR" CRLF + ; + abort-vreply = "BEGIN" ":" "VREPLY" CRLF + rstatus + other-props + "END" ":" "VREPLY" CRLF + +10.3. CONTINUE Command + + CMD: CONTINUE + + Purpose: The "CONTINUE" command is only sent after a "TIMEOUT" + command has been received to inform the other end of the session + to resume working on a command. + + Formal Definition: A "CONTINUE" command is defined by the following + notation: + + continue-cmd = continueparam ":" "CONTINUE" + ; + continueparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + + + +Royer, et al. Experimental [Page 89] + +RFC 4324 Calendar Access Protocol December 2005 + + + / latency-param + ; + ; the following MUST occur exactly once and only + ; when the latency-param has been supplied and + ; MUST NOT be supplied if the latency-param is + ; not supplied. + ; + / action-param + ; + ; the following are optional, + ; and MAY occur more than once + ; + / other-params + ) + + The REPLY of any "CONTINUE" command is: + + continue-reply = "BEGIN" ":" "VCALENDAR" CRLF + calprops + continue-vreply + "END" ":" "VCALENDAR" CRLF + ; + continue-vreply = "BEGIN" ":" "VREPLY" CRLF + rstatus + other-props + "END" ":" "VREPLY" CRLF + +10.4. CREATE Command + + CMD: CREATE + + Purpose: The "CREATE" command is used to create one or more + iCalendar objects in the store in the "BOOKED" or "UNPROCESSED" + state. + + A CUA MAY send a "CREATE" command to a CS. The "CREATE" command + MUST be implemented by all CSs. + + The CS MUST NOT send a "CREATE" command to any CUA. + + Formal Definition: A "CREATE" command is defined by the following + notation and the hierarchy restrictions, as defined in Section + 3.2: + + create-cmd = createparam ":" "CREATE" + ; + createparam = *( + ; + + + +Royer, et al. Experimental [Page 90] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + / latency-param + ; + ; the following MUST occur exactly once and only + ; when the latency-param has been supplied and + ; MUST NOT be supplied if the latency-param is + ; not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ) + + Response: + + One iCalendar object per TARGET property MUST be returned. + + The REPLY of any "CREATE" command is limited to the restriction + tables defined in [iTIP] for iTIP objects, in addition to this + ABNF: + + + + + + + + + + + + + + + + + + + + + + + + +Royer, et al. Experimental [Page 91] + +RFC 4324 Calendar Access Protocol December 2005 + + + create-reply = "BEGIN" ":" "VCALENDAR" CRLF + creply-props + 1*(create-vreply) + "END" ":" "VCALENDAR" CRLF + + ; + create-vreply = "BEGIN" ":" "VREPLY" CRLF + created-id + rstatus + other-props + "END" ":" "VREPLY" CRLF + ; + ; Where the id is appropriate for the + ; type of object created: + ; + ; VAGENDA = relcalid + ; VALARM = sequence + ; VCAR = carid + ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid + ; VQUERY = queryid + ; VTIMEZONE = tzid + ; x-comp = x-id + ; + created-id = ( relcalid / carid / uid / queryid / + tzid / sequence / x-id) + ; + tzid = ; As defined in [iCAL]. + ; + sequence = ; As defined in [iCAL]. + ; + uid = ; As defined in [iCAL]. + ; + x-id = ; An ID for an x-component. + ; + creply-props = 4*( + ; These are REQUIRED and MUST NOT occur + ; more than once. + ; + prodid /version / target / reply-cmd + ; + ; These are optional, and may occur more + ; than once. + ; + other-props ) + + For a "CREATE" command, the "TARGET" property specifies the + containers where the components will be created. + + + + +Royer, et al. Experimental [Page 92] + +RFC 4324 Calendar Access Protocol December 2005 + + + If the iCalendar object being created does not have a "METHOD" + property, then its state is "BOOKED" and it is not an [iTIP] + scheduling object. Use the "DELETE" command to set the state of + an object to the "DELETED" state (tagged for deletion). A CUA + cannot use the "CREATE" command to create an object in the + "DELETED" state. + + If the intention is to book an [iTIP] object, then the "METHOD" + property MUST NOT be supplied. Otherwise, any [iTIP] object MUST + have a valid [iTIP] "METHOD" property value and it is a scheduling + request being deposited into the CS with its state set to + "UNPROCESSED". + + Format Definition: ABNF for a "CREATE" object is: + + create-object = "BEGIN" ":" "VCALENDAR" CRLF + ; If 'calprops' contain the "METHOD" property + ; then this 'create-object' component MUST + ; conform to [iTIP] restrictions. + ; + ; calprops MUST include 'create-cmd' + ; + calprops + other-props + 1*(create-comp) + "END" ":" "VCALENDAR" CRLF + + ; NOTE: The 'VCALSTORE' component is not included in + ; 'create-comp' as it is out of scope for CAP to create + ; a new CS. + ; + create-comp = agendac / carc / queryc + / timezonec / freebusyc + / eventc / todoc / journalc + / iana-comp / x-comp + ; + freebusyc = ; As defined in [iCAL]. + ; + eventc = ; As defined in [iCAL]. + ; + journalc = ; As defined in [iCAL]. + ; + timezonec = ; As defined in [iCAL]. + ; + todoc = ; As defined in [iCAL]. + + In the following example, two new top level "VAGENDA" components are + created. Note that the "CSID" value of the server is + + + +Royer, et al. Experimental [Page 93] + +RFC 4324 Calendar Access Protocol December 2005 + + + cal.example.com, which is where the new "VAGENDA" components are + going to be created. + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: PRODID:-//someone's prodid + C: VERSION:2.0 + C: CMD;ID=creation01:CREATE + C: TARGET:cal.example.com + C: BEGIN:VAGENDA <- data for 1st new calendar + C: CALID:relcalz1 + C: NAME;LANGUAGE=en_US:Bill's Soccer Team + C: OWNER:bill + C: CALMASTER:mailto:bill@example.com + C: TZID:US/Pacific + C: END:VAGENDA + C: BEGIN:VAGENDA <- data for 2nd new calendar + C: CALID:relcalz2 + C: NAME;LANGUAGE=EN-us:Mary's personal calendar + C: OWNER:mary + C: CALMASTER:mailto:mary@example.com + C: TZID:US/Pacific + C: END:VAGENDA + C: END:VCALENDAR + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: CMD;ID=creation01:REPLY + S: TARGET:cal.example.com + S: BEGIN:VREPLY <- Reply for 1st calendar create + S: CALID:relcalz1 + S: REQUEST-STATUS:2.0 + S: END:REPLY + S: BEGIN:VREPLY <- Reply for 2nd calendar create + S: CALID:relcalz2 + S: REQUEST-STATUS:2.0 + S: END:VREPLY + S: END:VCALENDAR + + To create a new component in multiple containers, simply name all + of the containers in the "TARGET" in the create command. A new + "VEVENT" component is created in two TARGET components. In this + example, the "VEVENT" component is one new [iTIP] "REQUEST" to be + + + + +Royer, et al. Experimental [Page 94] + +RFC 4324 Calendar Access Protocol December 2005 + + + stored in two calendars. The results would be iCalendar objects + that conform to the [iTIP] replies as defined in [iTIP]. + + This example shows two [iTIP] "VEVENT" components being created in + each of the two supplied "TARGET" properties. As it contains the + "METHOD" property, they will be stored in the "UNPROCESSED" state: + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: CMD;ID=creation02:CREATE + C: METHOD:REQUEST + C: TARGET:relcalz1 + C: TARGET:relcalz2 + C: BEGIN:VEVENT + C: DTSTART:20030307T180000Z + C: UID:FirstInThisExample-1 + C: DTEND:20030307T190000Z + C: SUMMARY:Important Meeting + C: END:VEVENT + C: BEGIN:VEVENT + C: DTSTART:20040307T180000Z + C: UID:SecondInThisExample-2 + C: DTEND:20040307T190000Z + C: SUMMARY:Important Meeting + C: END:VEVENT + C: END:VCALENDAR + + The CS sends the "VREPLY" commands in separate MIME objects, one + per supplied "TARGET" property value. + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: CMD;ID=creation02:REPLY + S: TARGET:relcalz1 <- 1st TARGET listed. + S: BEGIN:REPLY <- Reply for 1st VEVENT create in 1st TARGET. + S: UID:FirstInThisExample-1 + S: REQUEST-STATUS:2.0 + S: END:VREPLY + S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 1st TARGET. + S: UID:SecondInThisExample-2 + S: REQUEST-STATUS:2.0 + S: END:VREPLY + + + +Royer, et al. Experimental [Page 95] + +RFC 4324 Calendar Access Protocol December 2005 + + + S: END:VCALENDAR + + And the second reply for the 2nd TARGET: + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: CMD;ID=creation02:REPLY + S: TARGET:relcalz2 <- 2nd TARGET listed + S: BEGIN:REPLY <- Reply for 1st VEVENT create in 2nd TARGET. + S: UID:FirstInThisExample-1 + S: REQUEST-STATUS:2.0 + S: END:VREPLY + S: BEGIN:REPLY <- Reply for 2nd VEVENT crate in 2nd TARGET. + S: UID:SecondInThisExample-2 + S: REQUEST-STATUS:2.0 + S: END:VREPLY + S: END:VCALENDAR + +10.5. DELETE Command + + CMD: DELETE + + Purpose: The "DELETE" command physically removes the QUERY result + from the store or marks it for deletion. + + A CUA MAY send a "DELETE" command to a CS. The "DELETE" command + MUST be implemented by all CSs. + + The CS MUST NOT send a "DELETE" command to any CUA. + + Formal Definition: A "DELETE" command is defined by the following + notation: + + delete-cmd = deleteparam ":" "DELETE" + ; + deleteparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + / latency-param + / option-param "MARK" + ; + + + +Royer, et al. Experimental [Page 96] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; The following MUST occur exactly once and + ; only when the latency-param has been supplied. + ; It MUST NOT be supplied if the latency-param + ; is not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ) + + The "DELETE" command is used to delete calendars or components. + The included "VQUERY" component(s) specifies the container(s) to + delete. + + To mark a component for delete without physically removing it, + include the "OPTIONS" parameter with its value set to the "MARK" + value in order to alter its state to "DELETED". + + When components are deleted, only the top-most component + "REQUEST-STATUS" properties are returned. No "REQUEST-STATUS" + properties are returned for components inside of the selected + components. There MUST be one "VREPLY" component returned for + each object that is deleted or marked for delete. Note that if no + "VREPLY" components are returned, then nothing matched and nothing + was deleted. + + Restriction Table for the "REPLY" command for any "DELETE" + command. + + delete-reply = "BEGIN" ":" "VCALENDAR" CRLF + calprops ; MUST include 'reply-cmd' + *(delete-vreply) + "END" ":" "VCALENDAR" CRLF + ; + delete-vreply = "BEGIN" ":" "VREPLY" CRLF + deleted-id + rstatus + "END" ":" "VREPLY" CRLF + ; + ; Where the id is appropriate for the + ; type of object deleted: + ; + ; VAGENDA = relcalid + ; VCAR = carid + ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid + + + +Royer, et al. Experimental [Page 97] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; VQUERY = queryid + ; ALARM = sequence + ; VTIMEZONE = tzid + ; x-comp = x-id + ; An instance = uid recurid + ; + deleted-id = ( relcalid / carid / uid / uid recurid + / queryid / tzid / sequence / x-id ) + + Example: to delete a "VEVENT" component with "UID" value of + "abcd12345" from the calendar "relcalid-22" from the current CS: + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: TARGET:relcalid-22 + C: CMD;ID:"random but unique per CUA":DELETE + C: BEGIN:VQUERY + C: QUERY:SELECT VEVENT FROM VAGENDA WHERE UID = 'abcd12345' + C: END:VQUERY + C: END:VCALENDAR + + S: BEGIN:VCALENDAR + S: TARGET:relcalid-22 + S: CMD;ID:"random but unique per CUA":REPLY + S: BEGIN:VREPLY + S: UID:abcd12345 + + S: REQUEST-STATUS:3.0 + S: END:VREPLY + S: END:VCALENDAR + + One or more iCalendar objects will be returned that contain + "REQUEST-STATUS" properties for the deleted components. More than + one component could have been deleted. Any booked component and + any number of unprocessed [iTIP] scheduling components that + matched the QUERY value in the above example will be returned. + Each unique "METHOD" property value that was deleted from the + store MUST be in a separate iCalendar object. This is because + only one "METHOD" property is allowed in a single "VCALENDAR" + BEGIN/END block. + +10.6. GENERATE-UID Command + + CMD: GENERATE-UID + + Purpose: The "GENERATE-UID" command returns one or more unique + identifiers that MUST be globally unique. + + + +Royer, et al. Experimental [Page 98] + +RFC 4324 Calendar Access Protocol December 2005 + + + The "GENERATE-UID" command MAY be sent to any CS. The "GENERATE- + UID" command MUST be implemented by all CSs. + + The "GENERATE-UID" command MUST NOT be sent to a CUA. + + Formal Definition: A "GENERATE-UID" command is defined by the + following notation: + + generate-uid-cmd = genuidparam ":" "GENERATE-UID" + ; + genuidparam = *( + ; + ; The following are optional, + ; but MUST NOT occur more than once. + ; + id-param + / localize-param + / latency-param + ; + ; The following MUST occur exactly once and + ; only when the latency-param has been supplied. + ; It MUST NOT be supplied if the latency-param + ; is not supplied. + ; + / action-param + ; + ; The following is optional, + ; and MAY occur more than once. + ; + / other-params + ; + ; The following MUST be supplied exactly once. + ; The value specifies the number of UIDs to + ; be returned. + ; + / option-param posint1 + ) + + Response: + + gen-reply = "BEGIN" ":" "VCALENDAR" CRLF + calprops ; Which MUST include 'reply-cmd' + 1*(gen-vreply) + "END" ":" "VCALENDAR" CRLF + + gen-vreply = "BEGIN" ":" "VREPLY" CRLF + 1*(uid) + rstatus + + + +Royer, et al. Experimental [Page 99] + +RFC 4324 Calendar Access Protocol December 2005 + + + "END" ":" "VREPLY" CRLF + {%%%IS THIS RIGHT%%%?] + + Example: + + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: CMD;ID=unique-per-cua-124;OPTIONS=5:GENERATE-UID + C: END:VCALENDAR + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: CMD;ID=unique-per-cua-124:REPLY + S: BEGIN:VREPLY + S: UID:20011121T120000Z-12340@cal.example.com + S: UID:20011121T120000Z-12341@cal.example.com + S: UID:20011121T120000Z-12342@cal.example.com + S: UID:20011121T120000Z-12343@cal.example.com + S: UID:20011121T120000Z-12344@cal.example.com + S: REQUEST-STATUS:2.0 + S: END:VREPLY + S: END:VCALENDAR + +10.7. GET-CAPABILITY Command + + CMD: GET-CAPABILITY + + Purpose: The "GET-CAPABILITY" command returns the capabilities of the + other end point of the session. + + A CUA MUST send a "GET-CAPABILITY" command to a CS after the + initial connection. A CS MUST send a "GET-CAPABILITY" command to + a CUA after the initial connection. The "GET-CAPABILITY" command + and reply MUST be implemented by all CSs and CUAs. + + Formal Definition: A "GET-CAPABILITY" command is defined by the + following notation: + + get-capability-cmd = capabilityparam ":" "GET-CAPABILITY" + + capabilityparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + + +Royer, et al. Experimental [Page 100] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; + id-param / localize-param / latency-param + ; + ; the following MUST occur exactly once and only + ; when the latency-param has been supplied and + ; MUST NOT be supplied if the latency-param is + ; not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ) + + Response: + + The "GET-CAPABILITY" command returns information about the + implementation at the other end of the session. The values + returned may differ depending on current user identify and the + security level of the connection. + + Client implementations SHOULD NOT require any capability element + beyond those defined in this specification or future RFC + publications. They MAY ignore any nonstandard, experimental + capability elements. The "GET-CAPABILITY" reply may return + different results, depending on the UPN and if the UPN is + authenticated. + + When sending a reply to a "GET-CAPABILITY" command, all of these + MUST be supplied. The following properties are returned in + response to a "GET-CAPABILITY" command: + + cap-vreply = "BEGIN" ":" "VCALENDAR" CRLF + ; The following properties may be in any order. + ; + rodid + version + reply-cmd + other-props + + "BEGIN" ":" "VREPLY" CRLF + ; The following properties may be in any order. + ; + cap-version + car-level + components + + + +Royer, et al. Experimental [Page 101] + +RFC 4324 Calendar Access Protocol December 2005 + + + stores-expanded + maxdate + mindate + itip-version + max-comp-size + multipart + query-level + recur-accepted + recur-expand + recur-limit + other-props + "END" ":" "VREPLY" CRLF + "END" ":" "VCALENDAR" CRLF + + Example: + + I: Content-Type: text/calendar + I: + I: BEGIN:VCALENDAR + I: VERSION:2.0 + I: PRODID:-//someone's prodid + I: CMD;ID=unique-per-cua-125:GET-CAPABILITY + I: END:VCALENDAR + + L: Content-Type: text/calendar + L: + L: BEGIN:VCALENDAR + L: VERSION:2.0 + L: PRODID:-//someone's prodid + L: CMD;ID=unique-per-cua-125:REPLY + L: BEGIN:VREPLY + L: CAP-VERSION:1.0 + L: PRODID:The CS prodid + L: QUERY-LEVEL:CAL-QL-1 + L: CAR-LEVEL:CAR-FULL-1 + L: MAXDATE:99991231T235959Z + L: MINDATE:00000101T000000Z + L: MAX-COMPONENT-SIZE:0 + L: COMPONENTS:VCALENDAR,VTODO,VJOURNAL,VEVENT,VCAR, + L: VALARM,VFREEBUSY,VTIMEZONE,STANDARD,DAYLIGHT,VREPLY + L: ITIP-VERSION:2446 + L: RECUR-ACCEPTED:TRUE + + + + + + + + + +Royer, et al. Experimental [Page 102] + +RFC 4324 Calendar Access Protocol December 2005 + + + L: RECUR-EXPAND:TRUE + L: RECUR-LIMIT:0 + L: STORES-EXPANDED:FALSE + L: X-INET-PRIVATE-COMMANDS:1.0 + L: END:VREPLY + L: END:VCALENDAR + +10.8. IDENTIFY Command + + CMD: IDENTIFY + + Purpose: The "IDENTIFY" command allows the CUA to set a new identity + to be used for calendar access. + + A CUA MAY send an "IDENTIFY" command to a CS. The "IDENTIFY" + command MUST be implemented by all CSs. A CS implementation MAY + reject all "IDENTIFY" commands. + + The CS MUST NOT send an "IDENTIFY" command to any CUA. + + Formal Definition: An "IDENTIFY" command is defined by the following + notation: + + identify-cmd = identifyparam ":" "IDENTIFY" + ; + identifyparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + / latency-param + ; + ; the following MUST occur exactly once and only + ; when the latency-param has been supplied and + ; MUST NOT be supplied if the latency-param is + ; not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ; + ; The value is the UPN of the requested + ; identity. If option is not supplied it is + + + +Royer, et al. Experimental [Page 103] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; a request to return to the original + ; authenticated identity. + ; + / option-param upn + ) + + Response: + + A "REQUEST-STATUS" property wrapped in a "VREPLY" component with + only one of the following request-status codes: + + 2.0 Successful. + + 6.4 Identity not permitted. VCAR restriction. + + The CS determines, through an internal mechanism, if the credentials + supplied at authentication permit the operation as the selected + identity. If they do, the session assumes the new identity; + otherwise, a security error is returned. + + Example: + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: CMD;ID=unique-per-cua-999;OPTIONS=newUserId:IDENTIFY + C: END:VCALENDAR + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: BEGIN:VREPLY + S: REQUEST-STATUS:2.0;Request Approved + S: END:VREPLY + S: END:VCALENDAR + + Or if denied: + + + + + + + + + + +Royer, et al. Experimental [Page 104] + +RFC 4324 Calendar Access Protocol December 2005 + + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: PRODID:-//someone's prodid + S: VERSION:2.0 + S: BEGIN:VREPLY + S: REQUEST-STATUS:6.4;Request Denied + S: END:VREPLY + S: END:VCALENDAR + + For the CUA to return to its original authenticated identity, the + OPTIONS parameter is omitted: + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: CMD;ID=unique-per-cua-995:IDENTIFY + C: END:VCALENDAR + + The CS may accept (2.0) or deny (6.4) the request to return to the + original identity. + + If a CS considers the "IDENTIFY" command an attempt to violate + security, the CS MAY terminate the [BEEP] session without any further + notice to the CUA after sending the "REQUEST-STATUS" 6.4 reply. + +10.9. MODIFY Command + + CMD: MODIFY + + Purpose: The "MODIFY" command is used to modify existing components. + + A CUA MAY send a "MODIFY" command to a CS. The "MODIFY" command + MUST be implemented by all CSs. + + The CS MUST NOT send a "MODIFY" command to any CUA. + + Formal Definition: A "MODIFY" command is defined by the following + notation: + + modify-cmd = modifyparam ":" "MODIFY" + ; + modifyparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + + + +Royer, et al. Experimental [Page 105] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; + id-param + / localize-param + / latency-param + ; + ; the following MUST occur exactly once and only + ; when the latency-param has been supplied and + ; MUST NOT be supplied if the latency-param is + ; not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ) + + The "MODIFY" command is used to modify existing components. The + TARGET property specifies the calendars that contain the + components that are going to be modified. + + The format of the request is three components inside of + "VCALENDAR" component: + + BEGIN:VCALENDAR + BEGIN:VQUERY + END:VQUERY + BEGIN:XXX + END:XXX + BEGIN:XXX + END:XXX + END:VCALENDAR + + The "VQUERY" component selects the components that are to be + modified. + + The "XXX" above is a named component type (VEVENT, VTODO, ...). + Both the old and new components MUST be of the same type. + + The old-values is a component and the contents of that component + are going to change and may contain information that helps + uniquely identify the original component (SEQUENCE in the example + below). If the CS cannot find a component that matches the QUERY + and does not have at least all of the OLD-VALUES, then a 6.1 error + is returned. + + + + + +Royer, et al. Experimental [Page 106] + +RFC 4324 Calendar Access Protocol December 2005 + + + The new-values is a component of the same type as old-values and + new-values contains the new data for each selected component. Any + data that is in old-values and not in new-values is deleted from + the selected component. Any values in new-values that was not in + old-values is added to the component. + + In this example, the "VEVENT" component with a "UID" property + value of 'unique-58' has the "LOCATION" property and "LAST- + MODIFIED" properties changed, the "VALARM" component with the + "SEQUENCE" property with a value of "3" has its "TRIGGER" property + disabled, the "X-LOCAL" property is removed from the "VEVENT" + component, and a "COMMENT" property is added. + + Because "SEQUENCE" property is used to locate the "VALARM" + component in this example, both the old-values and the new-values + contain the "SEQUENCE" property with a value of "3". If the + "SEQUENCE" property were to be left out of new-values, it would + have been deleted. + + Example: + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: TARGET:my-cal + C: CMD:ID=unique-mod:MODIFY + C: BEGIN:VQUERY <- Query to select data set. + C: QUERY:SELECT * FROM VEVENT WHERE UID = 'unique-58' + C: END:VQUERY + C: BEGIN:VEVENT <- Start of old data. + C: LOCATION:building 3 + C: LAST-MODIFIED:20020101T123456Z + C: X-LOCAL:some private stuff + C: BEGIN:VALARM + C: SEQUENCE:3 + C: TRIGGER;RELATED=END:PT5M + C: END:VALARM + C: END:VEVENT <- End of old data. + C: BEGIN:VEVENT <- Start of new data. + C: LOCATION:building 4 + C: LAST-MODIFIED:20020202T010203Z + C: COMMENT:Ignore global trigger. + C: BEGIN:VALARM + C: SEQUENCE:3 + C: TRIGGER;ENABLE=FALSE:RELATED=END:PT5M + C: END:VALARM + + + +Royer, et al. Experimental [Page 107] + +RFC 4324 Calendar Access Protocol December 2005 + + + C: END:VEVENT <- End of new data. + C: END:VCALENDAR + + The "X-LOCAL" property was not supplied in the new-values, so it + was deleted. The "LOCATION" property value was altered, as was + the "LAST-MODIFIED" value. The "VALARM" component with a + "SEQUENCE" property value of "3" had its "TRIGGER" property + disabled, and the "SEQUENCE" property value did not change so it + was not effected. The "COMMENT" property was added. + + When it comes to inline ATTACHMENTs, the CUA only needs to + uniquely identify the contents of the ATTACHMENT value in the + old-values in order to delete them. When the CS compares the + attachment data, it is compared in its binary form. The + ATTACHMENT value supplied by the CUA MUST be valid encoded + information. + + For example, to delete the same huge inline attachment from every + VEVENT in 'my-cal' that has an "ATTACH" property value with the + + old-values: + + BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//someone's prodid + TARGET:my-cal + CMD:MODIFY + BEGIN:VQUERY + QUERY:SELECT ATTACH FROM VEVENT + END:VQUERY + BEGIN:VEVENT + ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: + MIICajCCAdOgAwIBAgICbeUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U + EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE + ...< remainder of attachment data NOT supplied >.... + END:VEVENT + BEGIN:VEVENT + END:VEVENT + END:VCALENDAR + + Here the new-values is empty, so everything in the old-values is + deleted. + + Furthermore, the following additional restrictions apply: + + 1. One cannot change the "UID" property of a component. + + + + + +Royer, et al. Experimental [Page 108] + +RFC 4324 Calendar Access Protocol December 2005 + + + 2. If a contained component is changed inside of a selected + component, and that contained component has multiple instances, + then old-values MUST contain information that uniquely + identifies the instance or instances that are changing. It is + valid to change more than one. All contained components that + match old-values will be modified. In the first modify example + above, if "SEQUENCE" properties were to be deleted from both the + old-values and new-values, then all "TRIGGER" properties that + matched the old-values in all "VALARM" components in the + selected "VEVENT" components would be disabled. + + 3. The result of the modify MUST be a valid iCalendar object. + + Response: + + A "VCALENDAR" component is returned with one ore more "REQUEST- + STATUS" property values. + + If any error occurred: + + No component will be changed at all. That is, it will appear just + as it was prior to the modify and the CAP server SHOULD return a + "REQUEST-STATUS" property for each error that occurred. There + MUST be at least one error reported. + + If multiple components are selected, then what uniquely identified + the component MUST be returned (UID, QUERYID, ...) if the component + contains a unique identifier. If it does not, sufficient information + to uniquely identify the modified components MUST be returned in the + reply. + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: TARGET:relcalid + S: CMD;ID=delete#1:REPLY + S: BEGIN:VREPLY + S: BEGIN:VEVENT + S: UID:123 + S: REQUEST-STATUS:2.0 + S: END:VEVENT + S: END:VREPLY + S: END:VCALENDAR + + + + + + + + +Royer, et al. Experimental [Page 109] + +RFC 4324 Calendar Access Protocol December 2005 + + +10.10. MOVE Command + + CMD: MOVE + + Purpose: The "MOVE" command is used to move components within the CS. + + A CUA MAY send a "MOVE" command to a CS. The "MOVE" command MUST + be implemented by all CSs. + + The CS MUST NOT send a "MOVE" command to any CUA. + + Formal Definition: A "MOVE" command is defined by the following + notation: + + move-cmd = moveparam ":" "MOVE" + ; + moveparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + / latency-param + ; + ; the following MUST occur exactly once and only + ; when the latency-param has been supplied and + ; MUST NOT be supplied if the latency-param is + ; not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ; + ) + + Response: + + The REQUEST-STATUS in a VCALENDAR object. + + The content of each "result" is subject to the result restriction + table defined below. + + The access control on the "VAGENDA" component, after it has been + moved to its new location in the calstore, MUST be at least as + + + +Royer, et al. Experimental [Page 110] + +RFC 4324 Calendar Access Protocol December 2005 + + + secure as it was prior to the move. If the CS is not able to + ensure the same level of security, a permission-denied "REQUEST- + STATUS" property value MUST be returned, and the "MOVE" command + MUST NOT be performed. + + The "TARGET" property value specifies the new location, and the + "VQUERY" component specifies the old location. + + Restriction Table for the "REPLY" command of any "MOVE" command. + + move-reply = "BEGIN" ":" "VCALENDAR" CRLF + calprops + 1*(move-vreply) + "END" ":" "VCALENDAR" CRLF + + move-vreply = "BEGIN" ":" "VREPLY" CRLF + move-id + rstatus + "END" ":" "VREPLY" CRLF + + ; Where the id is appropriate for the + ; type of object moved: + ; + ; VAGENDA = relcalid + ; VCAR = carid + ; VEVENT, VFREEBUSY, VJOURNAL, VTODO = uid + ; VQUERY = queryid + ; ALARM = sequence + ; An instance = uid recurid + ; x-comp = x-id + ; + move-id = ( relcalid / carid / uid / uid recurid + / queryid / tzid / sequence / x-id) + + Example: moving the VAGENDA Nellis to Area-51 + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: CMD:MOVE + C: TARGET:Area-51 + C: BEGIN:VQUERY + C: QUERY: SELECT *.* FROM VAGENDA WHERE CALID='Nellis' + C: END:VQUERY + C: END:VCALENDAR + + + + +Royer, et al. Experimental [Page 111] + +RFC 4324 Calendar Access Protocol December 2005 + + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: TARGET:Area-51 + S: BEGIN:VREPLY + S: CALID:Nellis + S: REQUEST-STATUS: 2.0 + S: END:VREPLY + S: END:VCALENDAR + +10.11. REPLY Response to a Command + + CMD: REPLY + + Purpose: The "REPLY" value to the "CMD" property is used to return + the results of all other commands to the CUA. + + A CUA MUST send a "REPLY" command to a CS for any command a CS MAY + send to the CUA. The "REPLY" command MUST be implemented by all + CUAs that support getting the "GET-CAPABILITY" command. + + A CS MUST send a "REPLY" command to a CUA for any command a CUA + MAY send to the CS. The "REPLY" command MUST be implemented by + all CSs. + + Formal Definition: A "REPLY" command is defined by the following + notation: + + reply-cmd = replyparam ":" "REPLY" + ; + replyparam = *( + ; + ; The 'id' parameter value MUST be exactly the + ; same as the value sent in the original + ; CMD property. If the original CMD did + ; not have an 'id' parameter, then the 'id' + ; MUST NOT be supplied in the REPLY. + ; + id-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ) + + + + +Royer, et al. Experimental [Page 112] + +RFC 4324 Calendar Access Protocol December 2005 + + +10.12. SEARCH Command + + CMD: SEARCH + + Purpose: The "SEARCH" command is used to return selected components + to the CUA. + + A CUA MAY send a "SEARCH" command to a CS. The "SEARCH" command + MUST be implemented by all CSs. + + The CS MUST NOT send a "SEARCH" command to any CUA. + + Formal Definition: A "SEARCH" command is defined by the following + notation: + + search-cmd = searchparam ":" "SEARCH" + ; + searchparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + / latency-param + ; + ; the following MUST occur exactly once and only + ; when the latency-param has been supplied and + ; MUST NOT be supplied if the latency-param is + ; not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params + ) + + The format of the request is the search command (search-cmd) + followed by one or more (query) "VQUERY" components + + Response: + + The data in each result set contains one or more iCalendar + components composed of all the selected results enclosed in a + single "VREPLY" component per "QUERY". + + + + +Royer, et al. Experimental [Page 113] + +RFC 4324 Calendar Access Protocol December 2005 + + + Only "REQUEST-STATUS" property and the properties mentioned in the + "SELECT" clause of the QUERY are included in the components. Each + "VCALENDAR" component is tagged with the "TARGET" property. + + Searching for objects + + In the example below, objects on March 10,1999 between 080000Z and + 190000Z are read. In this case only four properties for each + object are returned. Two calendars are specified. Only booked + (vs. scheduled) entries are to be returned (this example only + selected VEVENT objects are to be returned): + + C: Content-Type: text/calendar + C: + C: BEGIN:VCALENDAR + C: VERSION:2.0 + C: PRODID:-//someone's prodid + C: CMD:SEARCH + C: TARGET:relcal2 + C: TARGET:relcal3 + C: BEGIN:VQUERY + C: QUERY:SELECT DTSTART,DTEND,SUMMARY,UID + C: FROM VEVENT + C: WHERE DTEND >= '19990310T080000Z' + C: AND DTSTART <= '19990310T190000Z' + C: AND STATE() = 'BOOKED' + C: END:VQUERY + C: END:VCALENDAR + + The return values are subject to VCAR filtering. That is, if the + request contains properties to which the UPN does not have access, + those properties will not appear in the return values. If the UPN + has access to at least one property of the component, but has been + denied access to all properties called out in the request, the + response will contain a single "REQUEST-STATUS" property + indicating the error. + + Here the request was successful, however one of the "VEVENT" + components contents were not accessible (4.1). + + + + + + + + + + + + +Royer, et al. Experimental [Page 114] + +RFC 4324 Calendar Access Protocol December 2005 + + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: TARGET:relcalid + S: CMD:REPLY + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: BEGIN:VREPLY + S: BEGIN:VEVENT + S: REQUEST-STATUS:4.1 + S: END:VEVENT + S: BEGIN:VEVENT + S: REQUEST-STATUS:2.0 + S: UID:123 + S: DTEND:19990310T080000Z + S: DSTART:19990310T190000Z + S: SUMMARY: Big meeting + S: END:VEVENT + + S: END:VREPLY + S: END:VCALENDAR + + If the UPN has no access to any components at all, the response + will simply be an empty data set. The response will look the same + if the particular components do not exist. + + S: Content-Type: text/calendar + S: + S: BEGIN:VCALENDAR + S: VERSION:2.0 + S: PRODID:-//someone's prodid + S: CMD:REPLY + S: TARGET:ralcalid + S: BEGIN:VREPLY + S: REQUEST-STATUS:2.0 + S: END:VREPLY + S: END:VCALENDAR + + If there are multiple targets, each iCalendar reply is contained + within its own iCalendar object. + +10.12.1. Searching for VFREEBUSY + + If a CS sets the "RECUR-EXPAND" property to "TRUE" and contains the + "VFREEBUSY" component in the "COMPONENTS" value in a reply to the + "GET-CAPABILITY" command, then it is the CS's responsibility (and not + the CUA's responsibility) to provide the correct "VFREEBUSY" + information for a calendar. + + + +Royer, et al. Experimental [Page 115] + +RFC 4324 Calendar Access Protocol December 2005 + + + If a CUA issues a "CREATE" "VFREEBUSY", such a CS MUST return success + and not store the "VFREEBUSY" component as the results would never be + used. + + Such a CS MUST dynamically create the results of a search for + "VFREEBUSY" components at search time when searching for STATE() = + 'BOOKED' items. + + If a CUA searches for "VFREEBUSY" components with STATE() = + 'UNPROCESSED', such a CS MUST return a "VREPLY" with no components. + + If a CUA searches for "VFREEBUSY" components without specifying the + STATE, such a CS MUST return the same result as if STATE()='BOOKED' + had been specified. + + For CSs that set the "CAPABILITY" "RECUR-EXPAND" property to "FALSE" + and have the "VFREEBUSY" component in the "COMPONENTS" value in the + "CAPABILITY" reply, a CUA MAY store the "VFREEBUSY" information on + the CS. These CSs then MUST return a "VFREEBUSY" component + calculated from the stored components. If no "VFREEBUSY" information + is available for the "TARGET" calendar, then a "VFREEBUSY" with no + blocked out time will be returned with a success code. A CUA sets + the "VFREEBUSY" time on a/those calendars by creating a "VFREEBUSY" + component without a "METHOD" creating a "BOOKED" entry. + + If a CS does not set the "VFREEBUSY" value in the "COMPONENTS" + "CAPABILITY" value, the CS does not support the "VFREEBUSY" component + and all creation and searching for a "VFREEBUSY" component MUST fail. + Examples of calendars that may be in this category are public event + calendars that will never require scheduling with other UPNs. + +10.13. SET-LOCALE Command + + CMD: SET-LOCALE + + Purpose: The "SET-LOCALE" command is used to select the locale that + will be used in error codes that are used in the "REQUEST-STATUS" + property. + + A CUA MAY send a "SET-LOCALE" command to a CS. The SET-LOCALE + command MUST be implemented by all CSs. + + The CS MUST NOT send a "SET-LOCALE" command to any CUA. + + Formal Definition: A "SET-LOCALE" command is defined by the following + notation: + + setlocale-cmd = setlocaleparam ":" "SET-LOCALE" + + + +Royer, et al. Experimental [Page 116] + +RFC 4324 Calendar Access Protocol December 2005 + + + ; + setlocaleparam = *( + ; + ; the following are optional, + ; but MUST NOT occur more than once + ; + id-param + / localize-param + / latency-param + / setlocale-option + ; + ; the following MUST occur exactly once and only + ; only when the latency-param has been supplied. + ; It MUST NOT be supplied if the latency-param + ; is not supplied. + ; + / action-param + ; + ; the following is optional, + ; and MAY occur more than once + ; + / other-params ) + + setlocale-option = option-param newlocale + ; + newlocale = ; Any locale supplied in the initial [BEEP] + ; "greeting" "localize" parameter and + ; and any charset supported by the CS + ; and listed in the DEFAULT-CHARSET property + ; of the VCALSTORE + + Examples: + + CMD:OPTIONS=en_US.UTF-8:SET-LOCALE + CMD:OPTIONS=th_TH.ISO8859-11:SET-LOCALE + CMD:OPTIONS=es_MX.ISO8859-1:SET-LOCALE + + Restriction Table for the "REPLY" command of any "SET-LOCALE" + command. + + setlocale-reply = "BEGIN" ":" "VCALENDAR" CRLF + calprops + 1*(setlocale-vreply) + "END" ":" "VCALENDAR" CRLF + + setlocale-vreply = "BEGIN" ":" "VREPLY" CRLF + rstatus + "END" ":" "VREPLY" CRLF + + + +Royer, et al. Experimental [Page 117] + +RFC 4324 Calendar Access Protocol December 2005 + + +10.14. TIMEOUT Command + + CMD: TIMEOUT + + Purpose: The "TIMEOUT" command is only sent after a command has been + sent with a latency value set. When received, it means the + command could not be completed in the time allowed. + + Formal Definition: A "TIMEOUT" command is defined by the following + notation: + + timeout-cmd = timeoutparam ":" "TIMEOUT" + + timeoutparam = *( + ; the following are optional, + ; but MUST NOT occur more than once + id-param + / localize-param + / other-params + ) + +10.15. Response Codes + + Numeric response codes are returned using the "REQUEST-STATUS" + property. + + The format of these codes is described in [iCAL] and extended in + [iTIP] and [iMIP]. The following describes new codes added to this + set and how existing codes apply to CAP. + + At the application layer, response codes are returned as the value of + a "REQUEST-STATUS" property. The value type of this property is + modified from that defined in [iCAL], in order to make the + accompanying "REQUEST-STATUS" property text optional. + + Code Description + -------------------------------------------------------------- + 2.0 Success. The parameters vary with the + operation and are specified. + + 2.0.3 In response to the client issuing an + "abort" reply, this reply code indicates + that any command currently underway was + successfully aborted. + + 3.1.4 Capability not supported. + + 4.1 Calendar store access denied. + + + +Royer, et al. Experimental [Page 118] + +RFC 4324 Calendar Access Protocol December 2005 + + + 6.1 Container not found. + + 6.2 Attempt to create or modify an object + that would overlap another object + in either of the following two circumstances: + + (a) One of the objects has a TRANSP + property set to OPAQUE-NOCONFLICT or + TRANSPARENT-NOCONFLICT. + + (b) The calendar's ALLOW-CONFLICT + property is set to FALSE. + + 6.3 Bad args. + + 6.4 Permission denied - VCAR restriction. + A VCAR exists and the CS will not perform + the operation. + + 7.0 A timeout has occurred. The server was + unable to complete the operation in the + requested time. + + 8.0 A failure has occurred in the CS + that prevents the operation from + succeeding. + + 8.1 A query was performed and the query is + too complex for the CS. The operation + was not performed. + + 8.2 Used to signal that an iCalendar object has + exceeded the server's size limit + + 8.3 A DATETIME value was too far in the future + to be represented on this Calendar. + + 8.4 A DATETIME value was too far in the past + to be represented on this Calendar. + + 8.5 An attempt was made to create a new + object, but the unique UID specified is + already in use. + + 9.0 An unrecognized command was received. + Or an unsupported command was received. + + + + + +Royer, et al. Experimental [Page 119] + +RFC 4324 Calendar Access Protocol December 2005 + + + 10.4 The operation has not been performed + because it would cause the resources + (memory, disk, CPU, etc) to exceed the + allocated quota. + -------------------------------------------------------------- + +11. Object Registration + + This section provides the process for registration of new or modified + properties, parameters, commands, or other modifications, additions, + or deletions to objects. + +11.1. Registration of New and Modified Entities + + New objects are registered by the publication of an IETF Request for + Comment (RFC). Changes to objects are registered by the publication + of a revision to the RFC in a new RFC. + +11.2. Post the Item Definition + + The object description MUST be posted to the new object discussion + list: ietf-calendar@imc.org. + +11.3. Allow a Comment Period + + Discussion on a new object MUST be allowed to take place on the list + for a minimum of two weeks. Consensus MUST be reached on the object + before proceeding to the next step. + +11.4. Release a New RFC + + The new object will be submitted for publication like any other + Internet Draft requesting RFC status. + +12. BEEP and CAP + +12.1. BEEP Profile Registration + + BEEP replies will be one-to-one (1:1 MSG/RPY) if possible, and one- + to-many (1:many MSG/ANS) when the "TARGET" property value changes. + No more than one "TARGET" property value is allowed per reply. + + Profile Identification: specify a [URI] that authoritatively + identifies this profile. + + http://iana.org/beep/cap/1.0 + + Message Exchanged during Channel Creation: + + + +Royer, et al. Experimental [Page 120] + +RFC 4324 Calendar Access Protocol December 2005 + + + CUAs SHOULD supply the BEEP "localize" attributes in the BEEP + "greeting" messages. + + CSs SHOULD supply the BEEP "localize" attributes in the BEEP + "greeting" messages. + + CUAs SHOULD supply the BEEP "serverName" attribute at channel + creation time to the CS, so that, if the CS is performing virtual + hosting, the CS can determine the intended virtual host. CSs that + do not support virtual hosting may ignore the BEEP "serverName" + attribute. + + Messages starting one-to-one exchanges: + + The initial message, after authentication in each direction, MUST + be a single "text/calendar" object containing a CAP "CAPABILITY" + CMD. It must not be part of a MIME multipart message. + + After the initial message, a BEEP "MSG" may contain one or more + MIME objects (at least one of which MUST be "text/calendar"), and + each "text/calendar" MIME object MUST contain a CAP "CMD" + property. + + Multiple iCalendar objects may be sent in a single BEEP message + either by representing them as separate MIME text/calendar parts + contained within a MIME multipart/mixed part or by simple + concatenation within a single text/calendar MIME object. + + In either case, all iCalendar objects that are transmitted + together must have the same TARGET property. + + The sending of multipart MIME entities over BEEP is not permitted + for CAP unless the other endpoint has indicated its ability to + accept them via the appropriate CAPABILITY. + + Messages in positive replies: + + After the initial message, a BEEP "RPY" may contain one or more + MIME objects (at least one of which MUST be "text/calendar"), and + each "text/calendar" MIME object MUST contain a CAP "CMD" + property. All "text/calendar" MIME objects in a single BEEP "RPY" + messages MUST have the same "TARGET" property value. + + Multiple iCalendar objects may be sent in a single BEEP message by + either representing them as separate MIME text/calendar parts + contained within a MIME multipart/mixed part or by simple + concatenation within a single text/calendar MIME object. + + + + +Royer, et al. Experimental [Page 121] + +RFC 4324 Calendar Access Protocol December 2005 + + + In either case, all iCalendar objects transmitted together must + have the same TARGET property. + + Sending multipart MIME entities over BEEP is not permitted for CAP + unless the other endpoint has indicated its ability to accept them + via the appropriate CAPABILITY. + + Messages in negative replies: + + Will contain any valid "text/calendar" MIME object that contains + CAP "REQUEST-STATUS" property and a CAP "CMD" property with a + property value of "REPLY". And where the CS has determined the + requested operation to be a fatal error. And when the CS has + performed NO operation that effected the contents of any part of + the CS or any calendar controlled by the CS. + + Messages in one-to-many exchanges: + + After the initial message then a BEEP "MSG" may contain one or + more MIME objects at least one of which MUST be "text/calendar" + and each "text/calendar" MIME object MUST contain a CAP "CMD" + property. + + The BEEP "MSG" messages can only contain MIME "multipart" MIME + objects if the other endpoint has received a CAP "CAPABILITY" + indicating the other endpoint supports multipart MIME objects. + This does not prevent the endpoint from sending multiple [iCAL] + 'icalobject' objects in a single BEEP "MSG" so long as all of them + have the same "TARGET" property value. + + Multiple iCalendar objects may be sent in a single BEEP message by + either representing them as separate MIME text/calendar parts + contained within a MIME multipart/mixed part or by simple + concatenation within a single text/calendar MIME object. + + In either case, all iCalendar objects transmitted together must + have the same TARGET property. + + The sending of multipart MIME entities over BEEP is not permitted + for CAP unless the other endpoint has indicated its ability to + accept them via the appropriate CAPABILITY. + + Message Syntax: + + They are CAP "text/calendar" MIME objects as specified in this + memo. + + + + + +Royer, et al. Experimental [Page 122] + +RFC 4324 Calendar Access Protocol December 2005 + + + Message Semantics: + + As defined in this memo. + +12.2. BEEP Exchange Styles + + [BEEP] defines three styles of message exchange: + + MSG/ANS,ANS,...,NUL - For one to many exchanges. + + MSG/RPY - For one to one exchanges. + + MSG/ERR - For requests the cannot be processed due to an error. + + A CAP request targeted at more than one container MAY use a one- to- + many exchange with a distinct answer associated with each target. A + CAP request targeted at a single container MAY use a one-to-one + exchange or a one-to-many exchange. "MSG/ERR" MAY only be used when + an error condition prevents the execution of the request on all the + targeted calendars. + +12.3. BEEP Connection Details + + All CAP communications must be done securely, so the initial greeting + includes the TLS profile. + + L: + + I: + + L: RPY 0 0 . 0 110 + L: Content-Type: application/beep+xml + L: + L: + L: + L: + L: END + + I: RPY 0 0 . 0 52 + I: Content-Type: application/beep+xml + I: + I: + I: END + + At this point, the connection is secure. The TLS profile 'resets' + the connection, so it resends the greetings, advertises the CAP + profiles that are supported, and replies with the profile selected + (only one profile exists at this time): + + + +Royer, et al. Experimental [Page 123] + +RFC 4324 Calendar Access Protocol December 2005 + + + L: + + I: + + L: RPY 0 0 . 0 110 + L: Content-Type: application/beep+xml + L: + L: + L: + L: + L: END + + I: RPY 0 0 . 0 110 + I: Content-Type: application/beep+xml + I: + I: + I: + I: + I: END + + Each channel must be authenticated before work can start, but + starting a channel involves authentication. Any SASL profile may be + included, for example: + + + + + + Example of anonymous channel: + + C: + C: + C: + + S: RPY 0 1 . 221 87 + S: Content-Type: application/beep+xml + S: + S: + S: END + + Example of DIGEST-MD5 channel: + + C: + C: + C: + + S: RPY 0 1 . 221 87 + S: Content-Type: application/beep+xml + + + +Royer, et al. Experimental [Page 124] + +RFC 4324 Calendar Access Protocol December 2005 + + + S: + S: + S: END + + Piggybacking the "CAPABILITY" command. + + The "CAPABILITY" reply may be included during channel start (see + RFC3080, section 2.3.1.2), as BEEP allows the start command to + include the initial data transfer. This reduces the number of round + trips to initiate a CAP session. + +13. IANA Considerations + + This memo defines IANA-registered extensions to the attributes + defined by iCalendar, as defined in [iCAL], and [iTIP]. + + IANA registration proposals for iCalendar and [iTIP] are to be mailed + to the registration agent for the "text/calendar" [MIME] content- + type, using the format defined in + section 7 of [iCAL]. + + The the IANA has registered the profile specified in Section 12.1, + and has selected an IANA-specific URI: http://iana.org/beep/cap/1.0. + +14. Security Considerations + + Access rights should be granted cautiously. Without careful + planning, it is possible to open up access to a greater degree than + desired. + + The "IDENTIFY" command should be carefully implemented. If it is + done incorrectly, UPNs may gain access as other, unintended, UPNs. + The "IDENTIFY" command may not chain; that is, the identity is always + validated against the original UPN and not the new UPN. + + Since CAP is a profile of [BEEP], consult [BEEP]'s Section 9 for a + discussion of BEEP-specific security issues. + + There are risks of allowing anonymous UPNs to deposit REQUEST and + REFRESH objects (calendar spam and denial-of-service, for example). + Implementations should consider methods to restrict anonymous + requests to within acceptable usages. + + CS implementations might consider automatically creating VCARs that + allow CAP ATTENDEEs in booked objects to deposit REFRESH and REPLY + objects for those UIDs if they otherwise do not have access rather + then opening up world access. And they may also consider allowing + COUNTER objects for those ATTENDEEs. + + + +Royer, et al. Experimental [Page 125] + +RFC 4324 Calendar Access Protocol December 2005 + + + When an object is booked by a CUA ,the CS reply may wish to include + warning messages to the CUA for ATTENDEEs that have CAP urls that do + not have local UPNs as those ATTENDEES may be unable to REPLY or + REFRESH. Some CSs may wish this to be an error. + + Although service provisioning is a policy matter, at a minimum, all + implementations must provide the following tuning profiles: + + o for authentication: http://iana.org/beep/SASL/DIGEST-MD5 + + o for confidentiality: http://iana.org/beep/TLS (using the + TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher) + + o for both: http://iana.org/beep/TLS (using the + TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side + certificates) + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Royer, et al. Experimental [Page 126] + +RFC 4324 Calendar Access Protocol December 2005 + + +Appendix A. Acknowledgements + + The following individuals were major contributors to the drafting and + discussion of this memo, and they are greatly appreciated: + + Alan Davies, Andrea Campi, Andre Courtemanche, Andrew Davison, Anil + Srivastava, ArentJan Banck, Arnaud Quillaud, Benjamin Sonntag, + Bernard Desruisseaux, Bertrand Guiheneuf, Bob Mahoney, Bob Morgan, + Bruce Kahn, Chris Dudding, Chris Olds, Christopher Apple, Cortlandt + Winters, Craig Johnson, Cyrus Daboo, Damon Chaplin, Dan Hickman, Dan + Kohn, Dan Winship, Darryl Champagne, David C. Thewlis, David Nicol, + David Nusbaum, David West, Derik Stenerson, Eric R. Plamondon, Frank + Dawson, Frank Nitsch, Gary Frederick, Gary McGath, Gilles Fortin, + Graham Gilmore, Greg Barnes, Greg FitzPatrick, Harald Alvestrand, + Harrie Hazewinkel, Helge Hess, Jagan Garimella, Jay Parker, Jim Ray, + Jim Smith, Joerg Reichelt, John Berthels, John Smith, John Stracke, + Jonathan Lennox, JP Rosevear, Karen Chu, Katie Capps Parlante, Kees + Cook, Ken Crawford, Ki Wong, Lars Eggert, Lata Kannan, Lawrence + Greenfield, Libby Miller, Lisa Dusseault, Lyndon Nerenberg, Mark + Davidson, Mark Paterson, Mark Smith, Mark Swanson, Mark Tearle, + Marshall Rose, Martijn van Beers, Martin Jackson, Matthias Laabs, Max + Froumentin, Micah Gorrell, Michael Fair, Mike Higginbottom, Mike + Hixson, Murata Makoto, Natalia Syracuse, Nathaniel Borenstein, Ned + Freed, Olivier Gutknecht, Patrice Lapierre, Patrice Scattolin, Paul + Hoffman, Paul Sharpe, Payod Deshpande, Pekka Pessi, Peter Thompson, + Preston Stephenson, Prometeo Sandino Roman Corral, Ralph Patterson, + Robert Lusardi, Robert Ransdell, Rob Siemborski, Satyanarayana + Vempati, Satya Vempati, Scott Hollenbeck, Seamus Garvey, Shannon + Clark, Shriram Vishwanathan, Steve Coya, Steve Mansour, Steve Miller, + Steve Vinter, Stuart Guthrie, Suchet Singh Khalsa, Ted Hardie, Tim + Hare, Timo Sirainen, Vicky Oliver, Paul Hill, and Yael Shaham-Gafni. + +Appendix B. References + +Appendix B.1. Normative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for + Syntax Specifications: ABNF", RFC 4234, October 2005. + + [BEEP] Rose, M., "The Blocks Extensible Exchange Protocol Core", + RFC 3080, March 2001. + + [BEEPTCP] Rose, M., "Mapping the BEEP Core onto TCP", RFC 3081, + March 2001. + + [BEEPGUIDE] Rose, M., "BEEP, The Definitive Guide", ISBN 0-596- + 00244-0, O'Reilly & Associates, Inc. + + + + +Royer, et al. Experimental [Page 127] + +RFC 4324 Calendar Access Protocol December 2005 + + + [GUIDE] Mahoney, B., Babics, G., and A. Taler, "Guide to Internet + Calendaring", RFC 3283, June 2002. + + [iCAL] Dawson, F. and D. Stenerson, "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", RFC + 2445, November 1998. + + [iTIP] Silverberg, S., Mansour, S., Dawson, F., and R. Hopson, + "iCalendar Transport-Independent Interoperability + Protocol (iTIP) Scheduling Events, BusyTime, To-dos and + Journal Entries", RFC 2446, November 1998. + + [iMIP] Dawson, F., Mansour, S., and S. Silverberg, "iCalendar + Message-Based Interoperability Protocol (iMIP)", RFC + 2447, November 1998. + + [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, BCP 14, March 1997. + +Appendix B.2. Informative References + + [CHARREG] Freed, N. and J. Postel, "IANA Charset Registration + Procedures", RFC 2278, January 1998. + + [CHARPOL] Alvestrand, H., "IETF Policy on Character Sets and + Languages", RFC 2277, January 1998. + + [RFC2822] Resnick, P., Ed., "Internet Message Format", RFC 2822, + April 2001. + + [SASL] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [SQL92] "Database Language SQL", ANSI/ISO/IEC 9075: 1992, aka + ANSI X3.135-1992, aka FIPS PUB 127-2 + + [SQLCOM] ANSI/ISO/IEC 9075:1992/TC-1-1995, Technical corrigendum 1 + to ISO/IEC 9075: 1992, also adopted as Amendment 1 to + ANSI X3.135.1992 + + [URLGUIDE] Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke, + "Guidelines for new URL Schemes", RFC 2718, November + 1999. + + + + +Royer, et al. Experimental [Page 128] + +RFC 4324 Calendar Access Protocol December 2005 + + + [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifiers (URI): Generic Syntax", RFC 3986, + January 2005. + + [URL] Berners-Lee, T, Masinter, L., and M. McCahil, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [X509CRL] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet + X.509 Public Key Infrastructure Certificate and + Certificate Revocation List (CRL) Profile", RFC 3280, + April 2002. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Royer, et al. Experimental [Page 129] + +RFC 4324 Calendar Access Protocol December 2005 + + +Authors' Addresses + + Doug Royer + IntelliCal, LLC + 267 Kentlands Blvd. #3041 + Gaithersburg, MD 20878 + US + + Phone: +1-866-594-8574 + Fax: +1-866-594-8574 + EMail: Doug@IntelliCal.com + URI: http://Royer.com + + + George Babics + Oracle + 600 Blvd. de Maisonneuve West + Suite 1900 + Montreal, Quebec H3A 3J2 + CA + + Phone: +1-514-905-8694 + EMail: george.babics@oracle.com + + + Steve Mansour + eBay + 2145 Hamilton Avenue + San Jose, CA 95125 + USA + + Phone: +1-408-376-8817 + EMail: smansour@ebay.com + + + + + + + + + + + + + + + + + + +Royer, et al. Experimental [Page 130] + +RFC 4324 Calendar Access Protocol December 2005 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2005). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET + ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, + INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE + INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at ietf- + ipr@ietf.org. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + +Royer, et al. Experimental [Page 131] + diff --git a/docs/draft-dawson-ical-xml-dtd-01.txt b/docs/draft-dawson-ical-xml-dtd-01.txt new file mode 100644 index 00000000..57ec7b84 --- /dev/null +++ b/docs/draft-dawson-ical-xml-dtd-01.txt @@ -0,0 +1,1368 @@ +The iCalendar XML DTD +From: http://www.ietf.org/internet-drafts/draft-dawson-ical-xml-dtd-01.txt +Date: 1999-01-20 + +--------------------------------------------------------------------------- + +Network Working Group Frank Dawson, Lotus +Internet Draft + + + +Dawson 3 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson 6 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson 7 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson 9 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson 10 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson 12 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + <-- Alarm component property element declarations --> + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +3 iCalendar Notation + + The formal public identifier (FPI) for the DTD described in this + specification is "-//IETF//DTD iCalendar//EN". + + A XML document can reference an external non-XML entity containing an + iCalendar object, as specified by [RFC2445]. The iCalendar object, + + +Dawson 15 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + while encoded in the standard, non-XML format can be referenced in an + external entity reference that identifies the [RFC2445] format in a + notation declaration. The [RFC2445] format is identified by the + formal public identifier "-//IETF//NONSGML iCalendar//EN", as defined + in [FPI]. + +4 Example Usage + +4.1 Simple iCalendar Object + + The following is a simple example of a XML document using this DTD. + + + + + + + + 19981116T163000Z + 19981116T190000Z + Project XYZ Review + Conference Room 23A + + + + +4.2 iCalendar with non-standard extension + + The following is an example of an iCalendar object that also includes + a non-standard extension. + + + + + + + ]> + + + + + 19981105T133000Z + 19981106T133000Z + Draft a test plan + 1998-ABC Corp-1234 + + +Dawson 16 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + 1 + + + + +4.3 iCalendar with ATTACH property + + The following is an example of an iCalendar object that also includes + an external reference to an attachment. + + + + + ]> + + + + + 19981212T150000Z + 19981212T160000Z + Department Holiday Party + Conference Room 23A + + + + + + The following is an example of an iCalendar object that includes an + attachment as inline binary content. + + + + + + + method="PUBLISH"> + + 19981212T150000Z + 19981212T160000Z + Department Holiday Party + Conference Room 23A + MIICajCCAdOgAwIBAgICBEUwDQ + EEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW + 11bmljYXRpb25z...and so on...IENvcnBvc== + + +Dawson 17 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + + + + +4.4 Document with multiple iCalendar objects + + The following is an example of a document that includes more than one + iCalendar object. + + + + + + + method="PUBLISH"> + + 19981010T000000Z + 19981010T235959Z + Register for conference + 2 + + + + method="PUBLISH"> + + 19981120T133000Z + 19981122T183000Z + IT Conference + Downtowner Hotel + + + + +4.5 Document utilizing iCalendar namespace + + The following is an example of a well-formed but invalid XML document + that declares the iCalendar namespace as it's default namespace. + + + + + + + The following is an example of a well-formed but invalid XML document + that includes elements from the iCalendar namespace. + + + + + 19981123T133000Z + 19981123T203000Z + 1234567 + 999.99 + + +4.6 XML document reference to a non-XML iCalendar object + + The following is an example of a XML document with a proper reference + to a non-XML entity containing an iCalendar object in the format + defined by [RFC2445]. This example shows how existing iCalendar + objects can be integrated into XML documents using the XML structure + defined in this document. + + + + + + + ]> + + + + + + + +5 Namespace + + [NSPACE] defines "XML namespaces" to be a collection of names, + identified by a URI, which are used in XML documents as element types + and attribute names. XML namespaces allow multiple markup vocabulary + in a single document. Considering the utility of the iCalendar + properties in other applications, it is important for the iCalendar + XML DTD to define a namespace for the iCalendar element types. + + This memo includes the definition of both a qualified name for the + iCalendar namespace and also a default namespace. The namespace + declaration is specified by attributes on the "iCal" element. The + default namespace is specified with the "xmlns" attribute and the + qualified name for the iCalendar namespace is specified with the + "xmlns:iCal" attribute. + + The default namespace attribute is useful in XML documents that are + based on the iCalendar document types. The qualified name for the + iCalendar namespace is useful in XML documents that partially consist + of iCalendar elements types but also consist of element types from + other schemas. + + + +Dawson 19 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + The following is an example of the iCalendar namespace declaration + using the qualified namespace: + + + + + + + + + + The following is an example of an iCalendar namespace declaration + using the default namespace: + + + + + + + + + +6 Acknowledgments + + The following have participated in the drafting and discussion of + this memo: + + Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Thomas Rowe, Doug + Royer + +7 Security Considerations + + Security issues are not currently discussed in this memo. + +8 Bibliography + + [FPI] F. Dawson, "iCalendar Formal Public Identifier", Internet + Draft, http://www.internic.net/internet-drafts/draft-calsch-icalfpi- + 00.txt, September 1998. + + [ISO9070] "Information Technology_SGML Support Facilities_ + Registration Procedures for Public Text Owner Identifiers", ISO/IEC + 9070, Second Edition, International Organization for Standardization, + April, 1991. + + [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC + 2045, November 1996. + + [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, ftp://ftp.isi.edu/in-notes/ + rfc2119.txt, March 1997. + + +Dawson 20 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + [NSPACE] T. Bray, D. Hollander, A. Layman, "Namespaces in XML", WD- + xml-names-19980916, http://www.w3.org/TR/1998/WD-xml-names-19980916, + Septebmer 1998. + + [RFC2445] F. Dawson and T. Howes, "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", RFC 2445, + ftp://ftp.isi.edu/in-notes/rfc2445.txt, November 1998. + + [XML] "Extensible Markup Language (XML)", Worldwid Web Consortium, + http://www.w3.org/TR/PR-xml-971208, December 1997. + +9 Author's Address + + The following address information is provided in a vCard XML DTD + electronic business card, format. + + + + Frank Dawson + Dawson + Frank + Lotus Development Corporation + + 6544 Battleford Drive + Raleigh + NC + 27613-3502 + + +1-617-693-8728 + +1-919-676-9515 + Frank_Dawson@Lotus.com + fdawson@earthlink.net + + + +10 Full Copyright Statement + + "Copyright (C) The Internet Society (1998).All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implmentation may be prepared, copied, published and + distributed, in whole or in part, without restriction of any kind, + provided that the above copyright notice and this paragraph are + included on all such copies and derivative works.However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process MUST be + followed, or as required to translate it into languages other than + English. + + +Dawson 21 Expires June 1999 + + +Internet Draft iCalendar XML DTD December 4, 1998 + + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson 22 Expires June 1999 diff --git a/docs/draft-ietf-calsch-many-xcal-02.txt b/docs/draft-ietf-calsch-many-xcal-02.txt new file mode 100644 index 00000000..9f7acd3e --- /dev/null +++ b/docs/draft-ietf-calsch-many-xcal-02.txt @@ -0,0 +1,2971 @@ +From: http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt +Title: iCalendar DTD Document (xCal) +Reference: draft-ietf-calsch-many-xcal-02 + +------------------------------------------------------------------------ + +Network Working Group F. Dawson +Internet-Draft Nokia +Expires: January 23, 2003 S. Reddy + Oracle + D. Royer + INET-Consulting + E. Plamondon + Oracle + July 25, 2002 + + + iCalendar DTD Document (xCal) + draft-ietf-calsch-many-xcal-02 + +Status of this Memo + + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. + + Internet-Drafts are draft documents valid for a maximum of six months + and may be updated, replaced, or obsoleted by other documents at any + time. It is inappropriate to use Internet-Drafts as reference + material or to cite them other than as "work in progress." + + The list of current Internet-Drafts can be accessed at http:// + www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. + + This Internet-Draft will expire on January 23, 2003. + +Copyright Notice + + Copyright (C) The Internet Society (2002). All Rights Reserved. + +Abstract + + This memo defines a [XML] Document Type Definition (DTD) that + corresponds to the iCalendar, Internet Calendaring and Scheduling + Core Object Specification defined by [RFC 2445]. This DTD provides + equivalent functionality to the standard format defined by [RFC + 2445]. Documents structured in accordance with this DTD may also be + known as "XML iCalendar" documents or "xCal". + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 1] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + The mailing list for discussion of this memo is "ietf- + calendar@imc.org". Send an email to "ietf-calendar-request@imc.org" + with the message "SUBSCRIBE" to add your email address to this + mailing list. Send an email to "ietf-calendar-request@imc.org" with + the message "UNSUBSCRIBE" to remove your email address from this + mailing list. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this + document are to be interpreted as described in [RFC 2119]. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Using XML For Representating iCalendar . . . . . . . . . . . 6 + 2.1 XML Dependencies . . . . . . . . . . . . . . . . . . . . . . 6 + 2.2 Document Type Definition . . . . . . . . . . . . . . . . . . 6 + 2.3 Working With Standard and XML iCalendar Representations . . 6 + 2.3.1 Conversion . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 2.3.2 Mixed Use of Both Representations . . . . . . . . . . . . . 7 + 2.4 Using Data Types . . . . . . . . . . . . . . . . . . . . . . 7 + 2.5 Including Binary Content . . . . . . . . . . . . . . . . . . 8 + 2.6 Including Multiple iCalendar Objects . . . . . . . . . . . . 9 + 2.7 Mapping Property Parameters to XML . . . . . . . . . . . . . 10 + 2.8 Mapping Calendar Properties to XML . . . . . . . . . . . . . 11 + 2.9 Mapping Component Properties to XML . . . . . . . . . . . . 13 + 2.10 Parameter Entities . . . . . . . . . . . . . . . . . . . . . 16 + 2.11 Namespace . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 2.12 Emailing the iCalendar XML Representation . . . . . . . . . 17 + 2.13 iCalendar XML Representation and File Systems . . . . . . . 18 + 3. Example Usage . . . . . . . . . . . . . . . . . . . . . . . 20 + 3.1 A well-formed and valid iCalendar XML document . . . . . . . 20 + 3.2 Adding non-standard, experimental extensions . . . . . . . . 20 + 3.3 Including binary content in attachments . . . . . . . . . . 21 + 3.4 iCalendar XML document with multiple iCalendar objects . . . 23 + 3.5 Using the iCalendar namespace . . . . . . . . . . . . . . . 24 + 3.6 Publish meeting information . . . . . . . . . . . . . . . . 25 + 3.7 Publish transparent annual event . . . . . . . . . . . . . . 25 + 3.8 Meeting invitation . . . . . . . . . . . . . . . . . . . . . 26 + 3.9 Assign a to-do . . . . . . . . . . . . . . . . . . . . . . . 27 + 3.10 Publish a journal entry . . . . . . . . . . . . . . . . . . 28 + 3.11 Publish busy time . . . . . . . . . . . . . . . . . . . . . 29 + 3.12 Request busy time . . . . . . . . . . . . . . . . . . . . . 29 + 3.13 Response to a busy time request . . . . . . . . . . . . . . 30 + 3.14 Published event that references time zone information . . . 30 + 3.15 An event with an alarm . . . . . . . . . . . . . . . . . . . 31 + 4. iCalendar XML Document Type Definition . . . . . . . . . . . 34 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 48 + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 2] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 49 + 7. Security Considerations . . . . . . . . . . . . . . . . . . 50 + 8. Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 51 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 51 + Full Copyright Statement . . . . . . . . . . . . . . . . . . 53 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 3] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +1. Introduction + + The Extended Markup Language (XML) as defined in [XML] is gaining + widespread attention as a "web friendly" syntax for representing and + exchanging documents and data on the Internet. This interest + includes requests for and discussion of possible document type + definitions (DTD) and name-space for IETF standard formats such as + that defined by [RFC 2445]. + + This memo defines how XML can be used to represent iCalendar objects. + This memo includes the definition of the XML DTD for a XML document + representation of an iCalendar object. + + NOTE: The [RFC 2445] is the definitive reference for the definition + of iCalendar semantics. This memo only provides an alternative, XML + representation for the standard syntax defined in [RFC 2445]. This + memo does not introduce any semantics not already defined by [RFC + 2445]. + + An attempt has been made to leverage the standard features of the XML + syntax in order to represent the component iCalendar semantics. For + example, strong data typing is specified using the XML notation + declaration. The element type attributes are used to represent many + of the calendar properties that provide a "global attribute" + capability in an iCalendar object. Binary content in the ATTACH + component property may either be specified through an external entity + reference to a non-XML binary content or may be included in the XML + document's content information, after first being encoding using the + BASE64 scheme of [RFC 2146]. Parameter entities are used to + logically group content particles in the XML DTD in order to + facilitate reading and comprehension of the structure specified by + the iCalendar XML DTD. + + The publication of XML version 1.0 was followed by the publication of + a World-wide Web Consortium (W3C) recommendation on "Namespaces in + XML". A XML name-space is a collection of names, identified by a + URI. In anticipation of the broader use of XML namespaces, this memo + includes the definition of the URI to be used to identify the + namespace associated with the iCalendar DTD element types in other + XML documents. XML applications that conform to this memo and also + use namespaces MUST NOT include other non-iCalendar namespaces in an + iCalendar XML document. + + It is expected that the DTD defined in this memo will not normally be + included with iCalendar XML documents that are distributed. Instead, + the DTD will be referenced in the document type declaration in the + document entity. Such iCalendar XML documents will be well-formed + and valid, as defined in [XML]. In addition, other iCalendar XML + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 4] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + documents will be specified that do not include the XML prolog. Such + iCalendar XML documents will be well-formed but not valid. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 5] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +2. Using XML For Representating iCalendar + + XML is a simplified version of the text markup syntax defined by ISO + 8879, Standard Generalized Markup Language (SGML). XML was published + as a proposed recommendation [XML] by the World-wide Web Consortium + (W3C) on February 10, 1998. + +2.1 XML Dependencies + + This memo specifies the XML representation for the standard iCalendar + format defined by [RFC 2445]. There are no XML dependencies other + than the [XML] and the [XMLNS] recommendations. + +2.2 Document Type Definition + + A XML DTD for iCalendar is defined by the DTD specified in section 3. + + The formal public identifier (FPI) for the DTD is: + + -//IETF//DTD XCAL//iCalendar XML//EN + + NOTE: The "DTD XCAL" text in the FPI value will be replaced with the + text "RFC xxxx", where "xxxx" is the RFC number, when the memo is + published as a RFC. + + This FPI MUST be used on the DOCTYPE statement within a XML document + referencing the DTD defined by this memo. + + This FPI SHOULD also be used to identify iCalendar XML documents + within operating system registries of file, clipboard and interactive + rendering (e.g., memory clipboard or drag/drop) formats. + +2.3 Working With Standard and XML iCalendar Representations + + This memo defines an alternative, XML representation for the standard + iCalendar format defined in [RFC 2445]. This alternative + representation provides the same semantics as that defined in the + standard format. + +2.3.1 Conversion + + The standard format can be converted to and from this XML format + without loss of any calendaring information. When the XML + representation was defined, every attempt was made to use existing + component, property and parameter naming conventions. This greatly + facilitates transformations between the two representations. + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 6] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +2.3.2 Mixed Use of Both Representations + + As previously indicated, conversion between the standard and XML + representations of iCalendar is a straightforward process. In + addition, mixed use of both representations is also possible. + + With the use of the MIME multipart content-types, compound MIME + entities containing a mix of the standard and XML representations can + be specified. This capability is useful in applications where both + representations might be encountered. In addition, this capability + demonstrates the isomeric nature of the two representations. XML + applications conforming to this specification MUST be able to + properly parse and process a MIME multipart entity containing the + MIME type associated with this iCalendar XML document type. + + Internet applications conforming to this memo MUST only send the + iCalendar XML document in a "multipart/alternative" MIME entity that + also contains an equivalent iCalendar object in the standard format + defined by [RFC2445]. This restriction will guarantee that the + iCalendar object can also be processed by Internet applications that + only support the standard iCalendar representation. + +2.4 Using Data Types + + Strong "data typing" is an integral design principle to the iCalendar + format. Strong data typing in iCalendar means that the format type + for each property value is well known. Within [RFC 2445], the data + type is called the "value type". The standard format defined by [RFC + 2445] specifies a default value type for each calendar and component + property. In addition, many of the property definitions allow for + the specification of alternate value types. This XML representation + continues this design principle. + + Explicit value/data typing in the XML representation is specified + with the "value" attribute on each element type. In addition, the + XML DTD specifies a default value/data type for each element type. + XML documents conforming to this memo need only specify the "value" + attribute on element types when the value needs to override the + default value/data type. The standard value types defined in + [RFC2445] are specified in the XML DTD by individual NOTATION + declarations. The formal public identifier for standard value types + all have the common string format of: + + -//IETF//NOTATION XCAL/Value Type/xxx//EN + + NOTE: The "XCAL" text in the FPI value will be replaced with the text + "RFC xxxx", where "xxxx" is the RFC number, when the memo is + published as a RFC. + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 7] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + Where "xxx" is replaced with the text specified in the table below. + + The following table specifies the XML value/data type that + corresponds to each of the standard value types defined in [RFC + 2445]. + + +--------------+------------+-------------------------+ + | RFC 2445 | XML Value | Notation FPI Text | + | Value Type | Type | | + +--------------+------------+-------------------------+ + | BINARY | BINARY | Binary | + | BOOLEAN | BOOLEAN | Boolean | + | CALADR | CALADR | Calendar User Address | + | DATE | DATE | Date | + | DATE-TIME | DATE-TIME | Date-Time | + | DURATION | DURATION | Duration | + | FLOAT | FLOAT | Float | + | INTEGER | INTEGER | Integer | + | PERIOD | PERIOD | Period of Time | + | RECUR | RECUR | Recurrence Rule | + | TEXT | TEXT | Text | + | TIME | TIME | Time | + | URI | URI | URI | + | UTC-OFFSET | UTC-OFFSET | UTC-Offset | + | Non-standard | X-NAME | X-Name | + +--------------+------------+-------------------------+ + + Other standard XML data types can be specified by including a + NOTATION declaration that specifies the formal public identifier + associated with the other standard format. In addition, the name of + the format specified in the NOTATION declaration is specified in the + "value" attribute of any element type that caste to the other + standard format. + +2.5 Including Binary Content + + Binary content can be included in an iCalendar object with the + "ATTACH" component property. In the standard iCalendar format this + content may either be specified through an external entity reference, + using a URI value type, or maybe specified within the iCalendar + object, after first BASE64 encoding the content. + + The XML representation for iCalendar also supports including binary + content in an iCalendar object with the "attach" element type. It + also supports either an external reference to the non-XML binary + content or inclusion of the binary content after first encoding the + binary information using the BASE64 encoding of [RFC 2045]. + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 8] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + Any iCalendar properties defined in [RFC 2445] that can be used to + include binary content are defined in the XML representation as an + element type with a content model that consists of either the + "extref" or the "b64bin" element type. The "extref" element type is + used to reference an external entity containing the binary content. + An external reference to the binary content is specified by the "uri" + attribute on the "extref" element type. For every external + reference, an ENTITY declaration and a corresponding NOTATION + declaration MUST also be specified in an internal DTD to identify the + location and format of the external entity. For example, the + following XML snippets would be needed to include a reference to the + executable "foo.exe" in the "attach" element type; which corresponds + to the "ATTACH" iCalendar component property: + + + + + + + + + + + The "b64bin" element type is used to include the binary content + within the XML document, after first character encoding the binary + information using the BASE64 encoding method of [RFC 2045]. For + example, the following XML snippets would be needed to include the + executable "foo.exe" in the "attach" element type; after first BASE64 + encoding the binary information: + + + + MIICajCC + AdOgAwIBAgICBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05l + dHNjYXBlIENvbW11bmljYXR5z...and so on...IENvcnBvc== + + + +2.6 Including Multiple iCalendar Objects + + The iCalendar format has the capability for including multiple, + individual iCalendar objects in a single data stream. The XML + representation can support this also. Individual iCalendar objects + are specified by the "vcalendar" element type. One or more + "vcalendar" element types are permitted within the parent element + type, called "iCalendar". For example: + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 9] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + +2.7 Mapping Property Parameters to XML + + The property parameters defined in the standard iCalendar format are + represented in the XML representation as an attribute on element + types. The following table specifies the attribute name + corresponding to each property parameter. + + +----------------+----------------+-----------+-----------------+ + | Property | Attribute | Attribute | Default | + | Parameter Name | Name | Type | Value | + +----------------+----------------+-----------+-----------------+ + | ALTREP | altrep | ENTITY | IMPLIED | + | CN | cn | CDATA | Null String | + | CUTYPE | cutype | NMTOKEN | INDIVIDUAL | + | DELEGATED-FROM | delegated-from | CDATA | IMPLIED | + | DELEGATED-TO | delegated-to | CDATA | IMPLIED | + | DIR | dir | ENTITY | IMPLIED | + | ENCODING | Not Used | n/a | n/a | + | FMTTYPE | fmttype | CDATA | REQUIRED | + | FBTYPE | fbtype | NMTOKEN | BUSY | + | LANGUAGE | language | CDATA | IMPLIED | + | MEMBER | member | CDATA | IMPLIED | + | PARTSTAT | partstat | NMTOKEN | NEEDS-ACTION | + | RANGE | range | NMTOKEN | THISONLY | + | RELATED | related | NMTOKEN | START | + | RELTYPE | reltype | NMTOKEN | PARENT | + | ROLE | role | NMTOKEN | REQ-PARTICIPANT | + | RSVP | rsvp | NMTOKEN | FALSE | + | SENT-BY | sent-by | CDATA | IMPLIED | + | TZID | tzid | CDATA | IMPLIED | + | VALUE | value | NOTATION | See elements | + +----------------+----------------+-----------+-----------------+ + + The inline "ENCODING" property parameter is not needed in the XML + representation. Inline binary information is always included as + parsable character data, after first being encoded using the BASE64 + encoding of [RFC 2045]. + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 10] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + The "RANGE" property parameter defined by [RFC 2445] does not include + the "THISONLY" enumeration. This is the implicit default, if the + parameter is not specified on the "RECURRENCE-ID" property. However, + the value is needed in the XML representation because all attributes + need to explicitly specify a default value in the attribute's + declaration in the DTD. This enumeration has been added to the XML + representation. + + A non-standard, experimental parameter can be added to the XML + representation by declaring it in an ATTLIST declaration and + assigning it a XML attribute type and corresponding default value. + +2.8 Mapping Calendar Properties to XML + + Calendar properties defined in the standard iCalendar format provide + information about an iCalendar object, as a whole. The calendar + properties are represented in the XML representation as an attribute + on the "iCalendar" and the "vcalendar" element type. The following + table specifies the attribute name permitted on the "iCalendar" + element type. + + +---------------+-----------+-----------+-----------------+ + | Calendar | Attribute | Attribute | Default | + | Property Name | Name | Type | Value | + +---------------+-----------+-----------+-----------------+ + | CALSCALE | calscale | CDATA | IMPLIED | + | METHOD | method | NMTOKEN | PUBLISH | + | VERSION | version | CDATA | REQUIRED | + | PRODID | prodid | CDATA | IMPLIED | + +---------------+-----------+-----------+-----------------+ + + In addition to these attributes, the "vcalendar" element type can + also have the following attributes: + + +-----------+-----------+---------+----------------------------+ + | Attribute | Attribute | Default | Description | + | Name | Type | Value | | + +-----------+-----------+---------+----------------------------+ + | xmlns | CDATA | FIXED | Used to specify the default| + | | | | iCalendar XML name space. | + | xmlns: + | CDATA | FIXED | Used to specify the | + | | | | | + +-----------+-----------+---------+----------------------------+ + + The semantics of the "xmlns" attribute, and any attribute with + "xmlns:" as a prefix, is as specified in [XMLNS]. It is used to + declare a namespace in XML. It can be used to declare the iCalendar + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 11] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + XML namespace in a XML document with a document type other than the + iCalendar XML document type. The iCalendar XML document type MUST + only use element types from the iCalendar namespace. Non-standard, + experimental element types and attributes lists MUST only be + specified by declarations in an internal DTD within the iCalendar XML + document. To specify the iCalendar namespace, the attribute value + for the "xmlns" and any attribute with the prefix "xmlns:" MUST be: + + 'http://www.ietf.org/internet-drafts/draft-ietf-calsch-many-xcal-01.txt' + + NOTE: This attribute value will be replaced with the URL "http:// + www.ietf.org/rfc/rfcxxxx.txt", where "xxxx" is the RFC number, when + this memo is published as a RFC. + + For example: + + + + + + The following table specifies the attribute name corresponding to + each calendar property. These attributes are only permitted on the + "vcalendar" element type. + + +---------------+-----------+-----------+-----------------+ + | Calendar | Attribute | Attribute | Default | + | Property Name | Name | Type | Value | + +---------------+-----------+-----------+-----------------+ + | CALSCALE | calscale | CDATA | IMPLIED | + | METHOD | method | NMTOKEN | PUBLISH | + | VERSION | version | CDATA | REQUIRED | + | PRODID | prodid | CDATA | IMPLIED | + +---------------+-----------+-----------+-----------------+ + + The semantics for these attributes is as specified for the + corresponding calendar property in [RFC 2445]. + + The following table specifies additional attributes that are + permitted on the "vcalendar" element type. + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 12] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + +-----------+-----------+---------+----------------------------+ + | Attribute | Attribute | Default | Description | + | Name | Type | Value | | + +-----------+-----------+---------+----------------------------+ + | language | CDATA | IMPLIED | Used to specify the default| + +-----------+-----------+---------+----------------------------+ + + The "language" attribute permits the default language to be specified + for the whole iCalendar object. If the "language" attribute is + specified on the XML document, then if the XML representation is + converted into the standard format the "LANGUAGE" property parameter + MUST be specified on each TEXT valued property to prevent information + loss; when translating into the standard format. + +2.9 Mapping Component Properties to XML + + Component properties in the standard iCalendar format provide + calendar information about the calendar component. The component + properties defined in the standard iCalendar format are represented + in the XML representation as element types. The following tables + specify the element types corresponding to each of the properties in + the specified property category. + + Descriptive Component Properties + +----------------+-------------+-----------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+-------------+-----------------------------+ + | ATTACH | attach | extref or b64bin | + | | extref | EMPTY | + | | b64bin | PCDATA | + | CATEGORIES | categories | Any number of item elements | + | | item | PCDATA | + | CLASS | class | PCDATA | + | COMMENT | comment | PCDATA | + | DESCRIPTION | description | PCDATA | + | GEO | geo | lat followed by lon element | + | | lat | PCDATA | + | | lon | PCDATA | + | LOCATION | location | PCDATA | + | PERCENT | percent | PCDATA | + | PRIORITY | priority | PCDATA | + | RESOURCES | resources | Any number of item elements | + | STATUS | status | PCDATA | + | SUMMARY | summary | PCDATA | + +----------------+-------------+-----------------------------+ + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 13] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + Date and Time Component Properties + +----------------+------------+-----------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+------------+-----------------------------+ + | COMPLETED | completed | PCDATA | + | DTEND | dtend | PCDATA | + | DUE | due | PCDATA | + | DTSTART | dtstart | PCDATA | + | DURATION | duration | PCDATA | + | FREEBUSY | freebusy | PCDATA | + | TRANSP | transp | PCDATA | + +----------------+------------+-----------------------------+ + + + Time Zone Component Properties + +----------------+-------------+-----------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+-------------+-----------------------------+ + | TZID | tzid | PCDATA | + | TZNAME | tzname | PCDATA | + | TZOFFSETFROM | tzoffsetfrom| PCDATA | + | TZOFFSETTO | tzoffsetto | PCDATA | + | TZURL | tzurl | EMPTY | + +----------------+-------------+-----------------------------+ + + + Relationship Component Properties + +----------------+---------------+--------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+---------------+--------------------------+ + | ATTENDEE | attendee | PCDATA | + | CONTACT | contact | PCDATA | + | ORGANIZER | organizer | PCDATA | + | RECURRENCE-ID | recurrence-id | PCDATA | + | RELATED-TO | related-to | PCDATA | + | URL | url | EMPTY | + | UID | uid | PCDATA | + +----------------+---------------+--------------------------+ + + + Recurrence Component Properties + +----------------+------------+-----------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+------------+-----------------------------+ + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 14] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + | EXDATE | exdate | PCDATA | + | EXRULE | exrule | PCDATA | + | RDATE | rdate | PCDATA | + | RRULE | rrule | PCDATA | + +----------------+------------+-----------------------------+ + + + Alarm Component Properties + +----------------+------------+-----------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+------------+-----------------------------+ + | ACTION | action | PCDATA | + | REPEAT | repeat | PCDATA | + | TRIGGER | trigger | PCDATA | + +----------------+------------+-----------------------------+ + + + Change Management Component Properties + +----------------+---------------+--------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+---------------+--------------------------+ + | CREATED | created | PCDATA | + | DTSTAMP | dtstamp | PCDATA | + | LAST-MODIFIED | last-modified | PCDATA | + | SEQUENCE | sequence | PCDATA | + +----------------+---------------+--------------------------+ + + + Miscellaneous Component Properties + +----------------+----------------+-------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+----------------+-------------------------+ + | REQUEST-STATUS | request-status | PCDATA | + +----------------+----------------+-------------------------+ + + The following table specifies the element types that represent each + of the calendar components. + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 15] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + Component Structuring Properties + +----------------+------------+-------------------------------+ + | Component | Element | Element Content Model | + | Property Name | Name | | + +----------------+------------+-------------------------------+ + | Multiple iCal- | iCalendar | One or more iCal elements | + | endar objects | | | + | VCALENDAR | vcalendar | calcomp parameter entity | + | VEVENT | vevent | vevent.opt1 and vevent.optm | + | | | parameter entity and valarm | + | | | element | + | VTODO | vtodo | vtodo.opt1 and vtodo.optm | + | | | parameter entity and valarm | + | | | element | + | VJOURNAL | vjournal | vjournal.opt1 and | + | | | vjournal.optm parameter | + | | | entity | + | VFREEBUSY | vfreebusy | vfreebusy.opt1 and | + | | | vfreebusy.optm parameter | + | | | entity | + | VTIMEZONE | vtimezone | vtimezone.man, | + | | | vtimezone.opt1, | + | | | vtimezone.mann parameter | + | | | entity | + | STANDARD | standard | standard.man or standard.optm | + | | | entity | + | DAYLIGHT | daylight | daylight.man or daylight.optm | + | | | entity | + | VALARM | valarm | valarm.audio, valarm.display, | + | | | valarm.email and | + | | | valarm.procedure entity | + +----------------+------------+-------------------------------+ + + The [RFC 2445] specification specifies that the equivalent component + properties to the "comment", "description", "location", "summary" and + "contact" element types can contain formatted content, such as is + specified by multiple lines of text. In such cases, the formatted + text should be specified in as CDATA Section content. The CDATA + section specifies arbitrary character data that is not meant to be + interpretted. It is not scanned for markup by the XML parser. The + CDATA Section in these element types MUST NOT contain markup or other + such alternate representation of the property value. The "altrep" + attribute is used to reference any such alternate representation for + the textual content of these element types. + +2.10 Parameter Entities + + The external, iCalendar XML DTD specified in section 3 makes use of + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 16] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + parameter entity declarations. This XML feature is used to group + declarations within the DTD. This technique has been used in DTD + design in order to facilitate the reading and comprehension of the + structure specified by the DTD. + +2.11 Namespace + + [XMLNS] defines "Namespaces in XML" to be a collection of names, + identified by a URI, which are used in XML documents as element types + and attribute names. The [XML] specification does not include a + definition for namespaces, but does set down some guidelines for + experimental naming of namespaces. + + XML namespaces allow multiple markup vocabulary in a single document. + Considering the utility of the iCalendar properties in other + applications, it is important for the iCalendar XML DTD to define a + namespace for the iCalendar element types. + + This memo defines the value that MUST be used in non-iCalendar XML + documents that reference element types or attribute lists from the + iCalendar namespace. + + The following is an example of a well-formed but invalid "xdoc" + document type that includes elements and attribute lists from the + iCalendar namespace: + + + + + + + + + + + + +2.12 Emailing the iCalendar XML Representation + + It is expected that iCalendar XML documents will need to be sent over + SMTP/MIME email. The "text/xml" and "application/xml" content-types + have been registered for XML documents. However, use of these + content-type definitions present some problems for XML applications + such as calendaring and scheduling. + + The "text/xml" and "application/xml" content-type definitions do not + provide for any header field parameters to identify the type of XML + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 17] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + document contained in the MIME entity. This means that a recipient + mail user agent must (MUA) open up each "text/xml" or "application/ + xml" content in order to determine what object handler is needed to + process the information. To a MUA, all XML documents look like just + plain "text/xml" or "application/xml" content. + + Additionally, it is accepted practice for a MUA to provide iconic + feedback to the user for individual content-types that are supported + by the MUA. For example, not only would feedback be provided for a + calendaring and scheduling content. Some further unique + identification would also be provided for each different scheduling + message; such as a meeting invitation, response to an invitation, + reschedule notice, cancellation notice, etc. In such cases, + acceptable performance by the MUA is dependent on the existence of + header field information, such as it provided in the definition of + the "text/calendar" content-type by [RFC 2445]. + + Internet application conforming to this memo MUST identify iCalendar + XML documents with the experimental content-type "application/ + calendar+xml". The content-type header field SHOULD also contain a + "component" and "method" parameter to clearly identify a comma- + separated list of components and the singular method used in the + iCalendar XML document. For example, an iCalendar XML document + specifying a REQUEST for a VEVENT and VTODO would be specified with + the following content-type header field: + + content-type:application/calendar+xml;method=REQUEST;component=VEVENT,VTODO + + The content-type can also include the "optinfo" parameter to specify + any other optional iCalendar information. The semantics of these + content-type parameters is as defined in [RFC 2445]. + + Internet applications conforming to this memo MUST only send the + iCalendar XML document in a "multipart/alternative" MIME entity that + also contains an equivalent iCalendar object in the standard format + defined by [RFC 2445]. This restrict will guarantee that the + iCalendar object can also be processed by internet applications that + only support the standard iCalendar format. + + An XML application supporting the iCalendar XML document type MUST be + able to receive and properly process the "application/calendar+xml" + document contained within a "multipart" message content-type. + +2.13 iCalendar XML Representation and File Systems + + The iCalendar XML documents will be stored in file systems. The + accepted practice for file extensions for XML documents is the text + "XML". However, in order to uniquely identify iCalendar XML + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 18] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + documents for file association with applications that can directly + process this document type, it is RECOMMENDED that the file extension + be the text "XCS". + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 19] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +3. Example Usage + + The following sections provide various examples of iCalendar XML + documents. + +3.1 A well-formed and valid iCalendar XML document + + The following is a simple example of a iCalendar XML document. This + document is both a well-formed and valid XML document. The iCalendar + object specifies an appointment. + + + + + + + + 19981116T150000@cal10.host.com + 19981116T145958Z + Project XYZ Review + Conference Room 23A + 19981116T163000Z + 19981116T190000Z + + Appointment + + + + + + +3.2 Adding non-standard, experimental extensions + + The following is an example of a valid iCalendar XML document that + also includes a non-standard, experimental extension, as provided for + by [RFC 2445]. The iCalendar object specifies the publication of a + to-do with a non-standard experimental property for a customer charge + code. + + The non-standard experimental property is identified by the "X-" + prefix to the element name. All non-standard properties MUST be + specified with element types with an "X-" type element name. In + addition, a text identifier for the vendor specifying the extension + SHOULD be appended to the "X-" text prefix. In this case, the + example specifies a "foo" for the name of the vendor specifying the + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 20] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + non- standard property. + + + + + + + ]> + + + + + 19981104T130000@cal1.host.com + 19981104T125957Z + 19981105T133000Z + 19981106T133000Z + Draft a test plan + 1998-ABC Corp-1234 + 1 + + + + + +3.3 Including binary content in attachments + + The following is an example of a valid iCalendar XML document that + also includes an external reference to an attachment. The iCalendar + object specifies a meeting invitation with an attachment. + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 21] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + ]> + + + + + 19981211T133000@cal1.host.com + 19981211T132928Z + jim@host.com + 19981212T150000Z + 19981212T160000Z + Department Meeting + Conference Room 23A + jim@host.com + MAILTO:joe@host.com + MAILTO:steve@host.com + + + + + + The following is an example of a well-formed and valid iCalendar XML + document that includes an attachment as inline binary content. The + iCalendar object specifies a meeting invitation with an attachment. + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 22] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + 19981211T133000@cal1.host.com + 19981211T132928Z + MAILTO:jim@host.com + 19981212T150000Z + 19981212T160000Z + Department Meeting + Conference Room 23A + MAILTO:jim@host.com + MAILTO:joe@host.com + MAILTO:steve@host.com + MIICajCCAdOgAwIBAgI + CBEUwDQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXB + lIEjYXRpb25z...and so on...IENvcnBvc== + + + + + +3.4 iCalendar XML document with multiple iCalendar objects + + The following is an example of a well-formed and valid iCalendar XML + document that includes more than one iCalendar object. + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 23] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + 19981009T233000@cal1.host.com + 19981009T232928Z + 19981010T000000Z + 19981010T235959Z + Register for conference + 2 + + + + + 19981009T233010@cal1.host.com + 19981009T233000Z + 19981120T133000Z + 19981122T183000Z + IT Conference + Downtowner Hotel + + + + + +3.5 Using the iCalendar namespace + + The following is an example of a snippet of a XML document that + includes elements from the iCalendar name-space. + + + 19981123T133000Z + 19981123T203000Z + 1234567 + 999.99 + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 24] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +3.6 Publish meeting information + + The following is a snippet of an iCalendar XML document that + publishes information about a meeting. The "method" attribute isn't + specified since it is the default value. + + + + + 19970901T130000Z-123401@host.com + 19970901T130000Z + 19970903T163000Z + 19970903T190000Z + Annual Employee Review + PRIVATE + + Business + Human Resources + + + + + + +3.7 Publish transparent annual event + + The following is a snippet of an iCalendar XML document that + publishes information about an annually repeating event that is + transparent to busy time searches. + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 25] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + 19990101T125957Z-123403@host.com + 19990101T130000Z + 19991102 + 19991102 + Our Blissful Anniversary + CONFIDENTIAL + TRANSPARENT + + Anniversary + Personal + Special Occasion + + FREQ=YEARLY + + + + + +3.8 Meeting invitation + + The following is a snippet of an iCalendar XML document that + specifies an invitation for a meeting. The meeting occurs on the + first Monday of each year for five years. + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 26] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + 19981220T130000Z-123403@host.com + 19981220T130050Z + MAILTO:corprel@host.com + 19990104T140000Z + 19990104T220000Z + Annual Stockholders Meeting + One Corporate Drive, Wilmington, DL + MAILTO:mrbig@host.com + MAILTO:stockholders@host.com + + Business + Meeting + Special Occasion + + FREQ=YEARLY;COUNT=5;BYDAY=1MO + + + + + +3.9 Assign a to-do + + The following is a snippet of an iCalendar XML document that assigns + a to-do. + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 27] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + 19990104T133402@ical1.host.com + 19990104T133410Z + 19990104 + 19990129 + MAILTO:dboss@host.com + Periodic Self Review + Complete your self review. + Contact me if you questions. + 1 + CONFIDENTIAL + MAILTO:dilbert@host.com + + + + + +3.10 Publish a journal entry + + The following is a snippet of an iCalendar XML document that + publishes a journal entry. + + + + + 19990104T170003@ical1.host.com + 19990104T170001Z + 19990104 + MAILTO:corprel@host.com + PUBLIC + Year end report for Worldwide Calendar Company + The complete report can be found at the Corporate website. + http://www.host.com/annualreport + + Annual Report + Business + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 28] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +3.11 Publish busy time + + The following is an iCalendar XML document that publishes busy time + information. The default value for the "method" attribute is + "PUBLISH" and does not need to be specified in this example. + + + + ]> + + + + + 19980313T133000@ical1.host.com + 19990104T133010Z + MAILTO:jsmith@host.com + 19980313T141711Z + 19980410T141711Z + + 19980314T233000Z/19980315T003000Z + 19980316T153000Z/19980316T163000Z + 19980318T030000Z/19980318T040000Z + + + + + +3.12 Request busy time + + The following is a snippet of an iCalendar XML document that requests + a calendar user's busy time information. + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 29] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + 19970901T083000@ical1.host.com + 19970901T083000Z + MAILTO:jane_doe@host1.com + 19971015T050000Z + 19971016T050000Z + MAILTO:john_public@host2.com + + + + + +3.13 Response to a busy time request + + The following is an iCalendar XML document that responds to request + for busy time information. + + + + ]> + + + + + 19970901T083000@ical1.host.com + 19970901T100000Z + MAILTO:jane_doe@host1.com + + MAILTO:john_public@host2.com + 19971015T050000Z/PT8H30M, + 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M + + + + + +3.14 Published event that references time zone information + + The following is a snippet of an iCalendar XML document that + publishes calendar information about an event that includes date/time + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 30] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + values that reference a time zone definition. + + + + + US-Eastern + + 19981025T020000 + -0400 + 0500 + 19981025T020000 + EST + + + 19990404T020000 + -0500 + -0400 + 19990404T020000 + EDT + + + + 19980309T231000Z + guid-1.host1.com + 19980312T083000 + 19980312T093000 + MAILTO:mrbig@host.com + Project XYZ Review Meeting + PUBLIC + XYZ Project Review + 1CP Conference Room 4350 + + Meeting + + MAILTO:employee-@host.com + + + + + + +3.15 An event with an alarm + + The following is an iCalendar XML with associated alarms. The event + specifies alarm definitions for a "display", "audio", "email" and + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 31] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + "procedure" type of alarms. The "method" attribute isn't specified + since it is the default value. + + + + + + + ]> + + + + 19990104T130000@host.com + 19990104T130100Z + 19990704T230000Z + 19970705T040000Z + Firework Celebration + + Holiday + Special Occasion + + + DISPLAY + Firework Celebration Tonight at + 6 PM !!! + 19990704T224500Z + 2 + PT15M + + + AUDIO + 19990704T224500Z + 2 + PT15M + + + + EMAIL + Firework Celebration Tonight + at 6 PM on Channel 6!!! + *** Firework Celebration On TV *** + 19990704T224500Z + MAILTO:PIN1234@pager.host.com + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 32] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + PROCEDURE + + 19990704T230000Z + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 33] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +4. iCalendar XML Document Type Definition + + The following DTD conforms to XML version 1.0, as specified by [XML]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 34] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 37] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 40] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 41] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 42] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 43] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 44] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 45] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 46] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 47] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +5. Acknowledgments + + The following have participated in the drafting and discussion of + this memo: + + Greg FitzPatrick, Charles Goldfarb, Paul Hoffman, Lisa Lippert, + Thomas Rowe. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 48] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +6. IANA Considerations + + This document defines a XML Formal Public Identifier (FPI), based on + a format defined in [ISO 9070], that identifies a XML document type + corresponding to this memo. Publication of this memo constitutes + registration of this identifier. + + In addition, this memo defines the XML FPIs corresponding to each of + the value types specified in [RFC 2445]. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 49] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +7. Security Considerations + + CDATA Sections - - A XML iCalendar document may contain CDATA + sections to represent content for specific element types. The CDATA + section specifies arbitrary character data that is not meant to be + interpretted. It is not scanned by the XML parser for markup. While + this memo restricts that any CDATA section MUST NOT contain markup or + other such alternate representation for the property value, in + general, CDATA section from a non-conformant implementation can + contain content such as HTML markup. HTML text can be used to invoke + programs. Implementors should be aware that this may leave an + implementation open to malicious attack that might occur as a result + of executing the markup in the CDATA section. + + PROCEDURAL ALARMS - - A XML iCalendar document can be created that + contains a "VEVENT" and "VTODO" calendar component with "VALARM" + calendar components. The "VALARM" calendar component can be of type + PROCEDURE and can have an attachment containing some sort of + executable program. Implementations that incorporate these types of + alarms are subject to any virus or malicious attack that might occur + as a result of executing the attachment. + + ATTACHMENTS - - A XML iCalendar document can include references to + Uniform Resource Locators that can be programmed resources. + Implementers and users of this memo should be aware of the network + security implications of accepting and parsing such information. + + In addition, the security considerations observed by implementations + of electronic mail systems should be followed for this memo. + + + + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 50] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +8. Bibliography + + [FPI] F. Dawson, "iCalendar Formal Public Identifier", Internet + Draft, http://www.internic.net/internet-drafts/draft-calsch-icalfpi- + 00.txt, September 1998. + + [ISO9070] "Information Technology_SGML Support Facilities_ + Registration Procedures for Public Text Owner Identifiers", ISO/IEC + 9070, Second Edition, International Organization for Standardization, + April 1991. + + [RFC 2045] N. Freed, N. Borenstein, "Multipurpose Internet Mail + Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC + 2045, November 1996. + + [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate + Requirement Levels", RFC 2119, http://www.ietf.org/rfc/rfc2119.txt, + March 1997. + + [RFC 2445] F. Dawson and D. Stenerson, "Internet Calendaring and + Scheduling Core Object Specification (iCalendar)", RFC 2445, http:// + www.ietf.org/rfc/rfc2445.txt, November 1998. + + [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, + http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. + + [XML] "Extensible Markup Language (XML)", Worldwide Web Consortium, + http://www.w3.org/TR/1998/REC-xml-19980210, February 1998. + + +Authors' Addresses + + Frank Dawson + Nokia Corporation + + Phone: +1 (972) 894 4083 + EMail: frank.dawson@nokia.com + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 51] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + + Surendra K. Reddy + Oracle + M/S 6op3 + 500 Oracle Parkway + Redwoodshores, CA 94065 + US + + Phone: +1 (650) 506 5441 + Fax: +1 (650) 654 6205 + EMail: skreddy@us.oracle.com + + + Doug Royer + INET-Consulting LLC + 1795 W. Broadway #266 + Idaho Falls, ID 83402 + US + + Phone: +1 (208) 520 4044 + Fax: +1 (208) 552 1179 + EMail: doug@royer.com + + + Eric R. Plamondon + Oracle + 2000 Peel Street, 4th Floor + Montreal, QC H3A 2W5 + Canada + + Phone: +1 (514) 733 8500 + Fax: +1 (514) 733 8878 + EMail: ericp@steltor.com + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 52] + +Internet-Draft iCalendar DTD Document (xCal) July 2002 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2002). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Dawson, Reddy, Royer, Plamondon Expires January 23, 2003 [Page 53] diff --git a/docs/dusseault-caldav-12.txt.html b/docs/dusseault-caldav-12.txt.html new file mode 100644 index 00000000..7a3bf369 --- /dev/null +++ b/docs/dusseault-caldav-12.txt.html @@ -0,0 +1,6155 @@ + + + + + +dusseault-caldav-12.txt + + +

draft-dusseault-caldav

+


+
+
+
+Network Working Group                                           C. Daboo
+Internet-Draft
+Expires: October 28, 2006                                B. Desruisseaux
+                                                                  Oracle
+                                                            L. Dusseault
+                                                                    OSAF
+                                                          April 26, 2006
+
+
+               Calendaring Extensions to WebDAV (CalDAV)
+                       draft-dusseault-caldav-12
+
+Status of this Memo
+
+   By submitting this Internet-Draft, each author represents that any
+   applicable patent or other IPR claims of which he or she is aware
+   have been or will be disclosed, and any of which he or she becomes
+   aware will be disclosed, in accordance with Section 6 of BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF), its areas, and its working groups.  Note that
+   other groups may also distribute working documents as Internet-
+   Drafts.
+
+   Internet-Drafts are draft documents valid for a maximum of six months
+   and may be updated, replaced, or obsoleted by other documents at any
+   time.  It is inappropriate to use Internet-Drafts as reference
+   material or to cite them other than as "work in progress."
+
+   The list of current Internet-Drafts can be accessed at
+   http://www.ietf.org/ietf/1id-abstracts.txt.
+
+   The list of Internet-Draft Shadow Directories can be accessed at
+   http://www.ietf.org/shadow.html.
+
+   This Internet-Draft will expire on October 28, 2006.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   This document specifies a set of methods, headers, message bodies,
+   properties, and reports that define calendar access extensions to the
+   WebDAV protocol.  The new protocol elements are intended to make
+   WebDAV-based calendaring and scheduling an interoperable standard
+   that supports calendar access, calendar management, calendar sharing,
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 1]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   and calendar publishing.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
+     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
+     1.2.  XML Namespaces and Processing . . . . . . . . . . . . . .   5
+   2.  Requirements Overview . . . . . . . . . . . . . . . . . . . .   6
+   3.  Calendaring Data Model  . . . . . . . . . . . . . . . . . . .   7
+     3.1.  Calendar Server . . . . . . . . . . . . . . . . . . . . .   7
+     3.2.  Recurrence and the Data Model . . . . . . . . . . . . . .   8
+   4.  Calendar Resources  . . . . . . . . . . . . . . . . . . . . .   8
+     4.1.  Calendar Object Resources . . . . . . . . . . . . . . . .   8
+     4.2.  Calendar Collection . . . . . . . . . . . . . . . . . . .  10
+   5.  Calendar Access Feature . . . . . . . . . . . . . . . . . . .  11
+     5.1.  Calendar Access Support . . . . . . . . . . . . . . . . .  11
+       5.1.1.  Example: Using OPTIONS for the Discovery of
+               Calendar Access Support . . . . . . . . . . . . . . .  11
+     5.2.  Calendar Collection Properties  . . . . . . . . . . . . .  11
+       5.2.1.  CALDAV:calendar-description Property  . . . . . . . .  11
+       5.2.2.  CALDAV:calendar-timezone Property . . . . . . . . . .  12
+       5.2.3.  CALDAV:supported-calendar-component-set Property  . .  14
+       5.2.4.  CALDAV:supported-calendar-data Property . . . . . . .  15
+       5.2.5.  CALDAV:max-resource-size Property . . . . . . . . . .  15
+       5.2.6.  CALDAV:min-date-time Property . . . . . . . . . . . .  16
+       5.2.7.  CALDAV:max-date-time Property . . . . . . . . . . . .  17
+       5.2.8.  CALDAV:max-instances Property . . . . . . . . . . . .  18
+       5.2.9.  CALDAV:max-attendees-per-instance Property  . . . . .  19
+       5.2.10. Additional Precondition for PROPPATCH . . . . . . . .  19
+     5.3.  Creating Resources  . . . . . . . . . . . . . . . . . . .  20
+       5.3.1.  MKCALENDAR Method . . . . . . . . . . . . . . . . . .  20
+         5.3.1.1.  Status Codes  . . . . . . . . . . . . . . . . . .  21
+         5.3.1.2.  Example: Successful MKCALENDAR request  . . . . .  22
+       5.3.2.  Creating Calendar Object Resources  . . . . . . . . .  24
+         5.3.2.1.  Additional Preconditions for PUT, COPY and MOVE .  25
+       5.3.3.  Non-standard components, properties and parameters  .  27
+       5.3.4.  Calendar Object Resource Entity Tag . . . . . . . . .  27
+   6.  Calendaring Access Control  . . . . . . . . . . . . . . . . .  28
+     6.1.  Calendaring Privilege . . . . . . . . . . . . . . . . . .  28
+       6.1.1.  CALDAV:read-free-busy Privilege . . . . . . . . . . .  28
+     6.2.  Additional Principal Property . . . . . . . . . . . . . .  29
+       6.2.1.  CALDAV:calendar-home-set Property . . . . . . . . . .  29
+   7.  Calendaring Reports . . . . . . . . . . . . . . . . . . . . .  30
+     7.1.  REPORT Method . . . . . . . . . . . . . . . . . . . . . .  30
+     7.2.  Ordinary collections  . . . . . . . . . . . . . . . . . .  30
+     7.3.  Date and floating time  . . . . . . . . . . . . . . . . .  31
+     7.4.  Time range filtering  . . . . . . . . . . . . . . . . . .  31
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 2]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+     7.5.  Partial Retrieval . . . . . . . . . . . . . . . . . . . .  32
+     7.6.  Non-standard components, properties and parameters  . . .  33
+     7.7.  CALDAV:calendar-query Report  . . . . . . . . . . . . . .  33
+       7.7.1.  Example: Partial retrieval of events by time range  .  35
+       7.7.2.  Example: Partial retrieval of recurring events  . . .  39
+       7.7.3.  Example: Expanded retrieval of recurring events . . .  42
+       7.7.4.  Example: Partial retrieval of stored free busy
+               components  . . . . . . . . . . . . . . . . . . . . .  44
+       7.7.5.  Example: Retrieval of to-dos by alarm time range  . .  46
+       7.7.6.  Example: Retrieval of event by UID  . . . . . . . . .  48
+       7.7.7.  Example: Retrieval of events by PARTSTAT  . . . . . .  50
+       7.7.8.  Example: Retrieval of events only . . . . . . . . . .  52
+       7.7.9.  Example: Retrieval of all pending to-dos  . . . . . .  56
+       7.7.10. Example: Attempt to query unsupported property  . . .  59
+     7.8.  CALDAV:calendar-multiget Report . . . . . . . . . . . . .  60
+       7.8.1.  Example: Successful CALDAV:calendar-multiget Report .  61
+     7.9.  CALDAV:free-busy-query Report . . . . . . . . . . . . . .  63
+       7.9.1.  Example: Successful CALDAV:free-busy-query Report . .  65
+   8.  Guidelines  . . . . . . . . . . . . . . . . . . . . . . . . .  65
+     8.1.  Client-to-client Interoperability . . . . . . . . . . . .  66
+     8.2.  Synchronization Operations  . . . . . . . . . . . . . . .  66
+       8.2.1.  Use of Reports  . . . . . . . . . . . . . . . . . . .  66
+         8.2.1.1.  Restrict the Time Range . . . . . . . . . . . . .  66
+         8.2.1.2.  Synchronize by Time Range . . . . . . . . . . . .  66
+         8.2.1.3.  Synchronization Process . . . . . . . . . . . . .  67
+       8.2.2.  Restrict the Properties Returned  . . . . . . . . . .  69
+     8.3.  Use of Locking  . . . . . . . . . . . . . . . . . . . . .  69
+     8.4.  Finding calendars . . . . . . . . . . . . . . . . . . . .  69
+     8.5.  Storing and Using Attachments . . . . . . . . . . . . . .  71
+       8.5.1.  Inline attachments  . . . . . . . . . . . . . . . . .  71
+       8.5.2.  External attachments  . . . . . . . . . . . . . . . .  72
+     8.6.  Storing and Using Alarms  . . . . . . . . . . . . . . . .  73
+   9.  XML Element Definitions . . . . . . . . . . . . . . . . . . .  74
+     9.1.  CALDAV:calendar XML Element . . . . . . . . . . . . . . .  74
+     9.2.  CALDAV:mkcalendar XML Element . . . . . . . . . . . . . .  74
+     9.3.  CALDAV:mkcalendar-response XML Element  . . . . . . . . .  74
+     9.4.  CALDAV:calendar-query XML Element . . . . . . . . . . . .  75
+     9.5.  CALDAV:calendar-data XML Element  . . . . . . . . . . . .  75
+       9.5.1.  CALDAV:comp XML Element . . . . . . . . . . . . . . .  76
+       9.5.2.  CALDAV:allcomp XML Element  . . . . . . . . . . . . .  77
+       9.5.3.  CALDAV:allprop XML Element  . . . . . . . . . . . . .  77
+       9.5.4.  CALDAV:prop XML Element . . . . . . . . . . . . . . .  78
+       9.5.5.  CALDAV:expand XML Element . . . . . . . . . . . . . .  78
+       9.5.6.  CALDAV:limit-recurrence-set XML Element . . . . . . .  79
+       9.5.7.  CALDAV:limit-freebusy-set XML Element . . . . . . . .  80
+     9.6.  CALDAV:filter XML Element . . . . . . . . . . . . . . . .  81
+       9.6.1.  CALDAV:comp-filter XML Element  . . . . . . . . . . .  81
+       9.6.2.  CALDAV:prop-filter XML Element  . . . . . . . . . . .  82
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 3]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+       9.6.3.  CALDAV:param-filter XML Element . . . . . . . . . . .  83
+       9.6.4.  CALDAV:is-not-defined XML Element . . . . . . . . . .  83
+       9.6.5.  CALDAV:text-match XML Element . . . . . . . . . . . .  84
+     9.7.  CALDAV:timezone XML Element . . . . . . . . . . . . . . .  84
+     9.8.  CALDAV:time-range XML Element . . . . . . . . . . . . . .  85
+     9.9.  CALDAV:calendar-multiget XML Element  . . . . . . . . . .  89
+     9.10. CALDAV:free-busy-query XML Element  . . . . . . . . . . .  90
+   10. Internationalization Considerations . . . . . . . . . . . . .  90
+   11. Security Considerations . . . . . . . . . . . . . . . . . . .  90
+   12. IANA Consideration  . . . . . . . . . . . . . . . . . . . . .  91
+     12.1. Namespace Registration  . . . . . . . . . . . . . . . . .  91
+   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  91
+   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  92
+     14.1. Normative References  . . . . . . . . . . . . . . . . . .  92
+     14.2. Informative References  . . . . . . . . . . . . . . . . .  93
+   Appendix A.  CalDAV Method Privilege Table (Normative)  . . . . .  93
+   Appendix B.  Calendar collections used in the examples  . . . . .  93
+   Appendix C.  Changes (to be removed prior to publication as an
+                RFC) . . . . . . . . . . . . . . . . . . . . . . . . 100
+     C.1.  Changes in -12  . . . . . . . . . . . . . . . . . . . . . 100
+     C.2.  Changes in -11  . . . . . . . . . . . . . . . . . . . . . 100
+     C.3.  Changes in -10  . . . . . . . . . . . . . . . . . . . . . 101
+     C.4.  Changes in -09  . . . . . . . . . . . . . . . . . . . . . 102
+     C.5.  Changes in -08  . . . . . . . . . . . . . . . . . . . . . 104
+     C.6.  Changes in -07  . . . . . . . . . . . . . . . . . . . . . 105
+     C.7.  Changes in -06  . . . . . . . . . . . . . . . . . . . . . 105
+     C.8.  Changes in -05  . . . . . . . . . . . . . . . . . . . . . 106
+     C.9.  Changes in -04  . . . . . . . . . . . . . . . . . . . . . 106
+     C.10. Changes in -03  . . . . . . . . . . . . . . . . . . . . . 107
+     C.11. Changes in -02  . . . . . . . . . . . . . . . . . . . . . 107
+     C.12. Changes in -01  . . . . . . . . . . . . . . . . . . . . . 107
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 108
+   Intellectual Property and Copyright Statements  . . . . . . . . . 109
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 4]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+1.  Introduction
+
+   The concept of using HTTP [RFC2616] and WebDAV [I-D.ietf-webdav-
+   rfc2518bis] as a basis for a calendar access protocol is by no means
+   a new concept: it was discussed in the IETF CALSCH working group as
+   early as 1997 or 1998.  Several companies have implemented calendar
+   access protocols using HTTP to upload and download iCalendar
+   [RFC2445] objects, and using WebDAV to get listings of resources.
+   However, those implementations do not interoperate because there are
+   many small and big decisions to be made in how to model calendaring
+   data as WebDAV resources, as well as how to implement required
+   features that aren't already part of WebDAV.  This document proposes
+   a way to model calendar data in WebDAV, with additional features to
+   make an interoperable calendar access protocol.
+
+   Discussion of this Internet-Draft is taking place on the mailing list
+   <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.
+
+1.1.  Notational Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+   The term "protected" is used in the Conformance field of property
+   definitions as defined in Section 1.4.2 of [RFC3253].
+
+   When XML element types in the namespaces "DAV:" and
+   "urn:ietf:params:xml:ns:caldav" are referenced in this document
+   outside of the context of an XML fragment, the string "DAV:" and
+   "CALDAV:" will be prefixed to the element type names respectively.
+
+1.2.  XML Namespaces and Processing
+
+   Definitions of XML elements in this document use XML element type
+   declarations (as found in XML Document Type Declarations), described
+   in Section 3.2 of [W3C.REC-xml-20040204].
+
+   The namespace "urn:ietf:params:xml:ns:caldav" is reserved for the XML
+   elements defined in this specification, its revisions, and related
+   CalDAV specifications.  XML elements defined by individual
+   implementations MUST NOT use the "urn:ietf:params:xml:ns:caldav"
+   namespace, and instead should use a namespace that they control.
+
+   The XML declarations used in this document do not include namespace
+   information.  Thus, implementers MUST NOT use these declarations as
+   the only way to create valid CalDAV properties or to validate CalDAV
+   XML element type.  Some of the declarations refer to XML elements
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 5]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   defined by WebDAV [I-D.ietf-webdav-rfc2518bis] which use the "DAV:"
+   namespace.  Wherever such XML elements appear, they are explicitly
+   prefixed with "DAV:" to avoid confusion.
+
+   Also note that some CalDAV XML element names are identical to WebDAV
+   XML element names, though their namespace differs.  Care must be
+   taken not to confuse the two sets of names.
+
+   Processing of XML by CalDAV clients and servers MUST follow the rules
+   described in [I-D.ietf-webdav-rfc2518bis], in particular Sections 8.2
+   and 17, and Appendix A of that specification.
+
+
+2.  Requirements Overview
+
+   This section lists what functionality is required of a CalDAV server.
+   To advertise support for CalDAV, a server:
+
+   o  MUST support iCalendar [RFC2445] as a media type for calendar
+      object resource format;
+
+   o  MUST support WebDAV Class 1 and Class 3 [I-D.ietf-webdav-
+      rfc2518bis];
+
+   o  MUST support WebDAV ACL [RFC3744] with the additional privilege
+      defined in Section 6.1 of this document;
+
+   o  MUST support transport over TLS [RFC2246] as defined in [RFC2818];
+
+   o  MUST support ETags [RFC2616] with additional requirements
+      specified in Section 5.3.4 of this document;
+
+   o  MUST support all calendaring REPORTs defined in Section 7 of this
+      document; and
+
+   o  MUST advertise support on all calendar collections and calendar
+      object resources for the calendaring REPORTs in the DAV:supported-
+      report-set property as defined in Versioning Extensions to WebDAV
+      [RFC3253].
+
+   In addition, a server:
+
+   o  SHOULD support the MKCALENDAR method defined in Section 5.3.1 of
+      this document.
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 6]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+3.  Calendaring Data Model
+
+   One of the features which has made WebDAV a successful protocol is
+   its firm data model.  This makes it a useful framework for other
+   applications such as calendaring.  This specification follows the
+   same pattern by developing all features based on a well-described
+   data model.
+
+   As a brief overview, a CalDAV calendar is modeled as a WebDAV
+   collection with a defined structure; each calendar collection
+   contains a number of resources representing calendar objects as its
+   direct child resource.  Each resource representing a calendar object
+   (event or to-do, or journal entry, or other calendar components) is
+   called a "calendar object resource".  Each calendar object resource
+   and each calendar collection can be individually locked and have
+   individual WebDAV properties.  Requirements derived from this model
+   are provided in Section 4.1 and Section 4.2.
+
+3.1.  Calendar Server
+
+   A CalDAV server is a calendaring-aware engine combined with a WebDAV
+   repository.  A WebDAV repository is a set of WebDAV collections,
+   containing other WebDAV resources, within a unified URL namespace.
+   For example, the repository "http://www.example.com/webdav/" may
+   contain WebDAV collections and resources, all of which have URLs
+   beginning with "http://www.example.com/webdav/".  Note that the root
+   URL "http://www.example.com/" may not itself be a WebDAV repository
+   (for example, if the WebDAV support is implemented through a servlet
+   or other Web server extension).
+
+   A WebDAV repository MAY include calendar data in some parts of its
+   URL namespace, and non-calendaring data in other parts.
+
+   A WebDAV repository can advertise itself as a CalDAV server if it
+   supports the functionality defined in this specification at any point
+   within the root of the repository.  That might mean that calendaring
+   data is spread throughout the repository and mixed with non-calendar
+   data in nearby collections (e.g., calendar data may be found in
+   /home/lisa/calendars/ as well as in /home/bernard/calendars/, and
+   non-calendar data in /home/lisa/contacts/).  Or, it might mean that
+   calendar data can be found only in certain sections of the repository
+   (e.g., /calendar/).  Calendaring features are only required in the
+   repository sections that are or contain calendar object resources.
+   So a repository confining calendar data to the /calendar/ collection
+   would only need to support the CalDAV required features within that
+   collection.
+
+   The CalDAV server or repository is the canonical location for
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 7]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   calendar data and state information.  Both CalDAV servers and clients
+   MUST ensure that the data is consistent and compliant.  Clients may
+   submit requests to change data or download data.  Clients may store
+   calendar objects offline and attempt to synchronize at a later time.
+   However, clients MUST be prepared for calendar data on the server to
+   change between the time of last synchronization and when attempting
+   an update, as calendar collections may be shared and accessible via
+   multiple clients.  Entity tags and other features make this possible.
+
+3.2.  Recurrence and the Data Model
+
+   Recurrence is an important part of the data model because it governs
+   how many resources are expected to exist.  This specification models
+   a recurring calendar component and its recurrence exceptions as a
+   single resource.  In this model, recurrence rules, recurrence dates,
+   exception rules, and exception dates are all part of the data in a
+   single calendar object resource.  This model avoids problems of
+   limiting how many recurrence instances to store in the repository,
+   how to keep recurrence instances in sync with the recurring calendar
+   component, and how to link recurrence exceptions with the recurring
+   calendar component.  It also results in less data to synchronize
+   between client and server, and makes it easier to make changes to all
+   recurrence instances or to a recurrence rule.  It makes it easier to
+   create a recurring calendar component, and easier to delete all
+   recurrence instances.
+
+   Clients are not forced to retrieve information about all recurrence
+   instances of a recurring component.  The CALDAV:calendar-query and
+   CALDAV:calendar-multiget REPORTs defined in this document allow
+   clients to retrieve only recurrence instances that overlap a given
+   time range.
+
+
+4.  Calendar Resources
+
+4.1.  Calendar Object Resources
+
+   Calendar object resources contained in calendar collections MUST NOT
+   contain more than one type of calendar component (e.g., VEVENT,
+   VTODO, VJOURNAL, VFREEBUSY, etc.) with the exception of VTIMEZONE
+   components which MUST be specified for each unique TZID parameter
+   value specified in the iCalendar object.  For instance, a calendar
+   object resource can contain two VEVENT components and one VTIMEZONE
+   component, but it cannot contain one VEVENT component and one VTODO
+   component.  Instead the VEVENT and VTODO components would have to be
+   stored in separate calendar object resources in the same collection.
+
+   Calendar object resources contained in calendar collections MUST NOT
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 8]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   specify the iCalendar METHOD property.
+
+   The UID property value of the calendar components contained in a
+   calendar object resource MUST be unique in the scope of the calendar
+   collection in which they are stored.
+
+   Calendar components in a calendar collection that have different UID
+   property values MUST be stored in separate calendar object resources.
+
+   Calendar components with the same UID property value, in a given
+   calendar collection, MUST be contained in the same calendar object
+   resource.  This ensures that all components in a recurrence "set" are
+   contained in the same calendar object resource.  It is possible for a
+   calendar object resource to just contain components that represent
+   "overridden" instances (ones which modify the behavior of a regular
+   instance, and thus include a RECURRENCE-ID property), without also
+   including the "master" recurring component (the one that defines the
+   recurrence "set" and does not contain any "RECURRENCE-ID" property).
+
+   For example, given the following iCalendar object:
+
+    BEGIN:VCALENDAR
+    PRODID:-//Example Corp.//CalDAV Client//EN
+    VERSION:2.0
+    BEGIN:VEVENT
+    UID:1@example.com
+    SUMMARY:One-off Meeting
+    DTSTAMP:20041210T183904Z
+    DTSTART:20041207T120000Z
+    DTEND:20041207T130000Z
+    END:VEVENT
+    BEGIN:VEVENT
+    UID:2@example.com
+    SUMMARY:Weekly Meeting
+    DTSTAMP:20041210T183838Z
+    DTSTART:20041206T120000Z
+    DTEND:20041206T130000Z
+    RRULE:FREQ=WEEKLY
+    END:VEVENT
+    BEGIN:VEVENT
+    UID:2@example.com
+    SUMMARY:Weekly Meeting
+    RECURRENCE-ID:20041213T120000Z
+    DTSTAMP:20041210T183838Z
+    DTSTART:20041213T130000Z
+    DTEND:20041213T140000Z
+    END:VEVENT
+    END:VCALENDAR
+
+
+
+Daboo, et al.           Expires October 28, 2006                [Page 9]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   The VEVENT component with the UID value "1@example.com", would be
+   stored in its own calendar object resource.  The two VEVENT
+   components with the UID value "2@example.com", which represent a
+   recurring event where one recurrence instance has been overridden,
+   would be stored in the same calendar object resource.
+
+4.2.  Calendar Collection
+
+   A calendar collection contains calendar object resources that
+   represent calendar components within a calendar.  A calendar
+   collection is manifested to clients as a WebDAV resource collection
+   identified by a URL.  A calendar collection MUST report the DAV:
+   collection and CALDAV:calendar XML elements in the value of the DAV:
+   resourcetype property.  The element type declaration for CALDAV:
+   calendar is:
+
+       <!ELEMENT calendar EMPTY>
+
+   A calendar collection can be created through provisioning (e.g.,
+   automatically created when a user's account is provisioned), or it
+   can be created with the MKCALENDAR method (see Section 5.3.1).  This
+   method can be useful for a user to create additional calendars (e.g.,
+   soccer schedule) or for users to share a calendar (e.g., team events
+   or conference room).  Note however that this document doesn't define
+   what extra calendar collections are for.  Users must rely on non-
+   standard cues to find out what a calendar collection is for, or use
+   the CALDAV:calendar-description property defined in Section 5.2.1 to
+   provide such a cue.
+
+   The following restrictions are applied to the resources within a
+   calendar collection:
+
+   a.  Calendar collections MUST only contain calendar object resources
+       and collections that are not calendar collections. i.e., the only
+       "top-level" non-collection resources allowed in a calendar
+       collection are calendar object resources.  This ensures that
+       calendar clients do not have to deal with non-calendar data in a
+       calendar collection, though they do have to distinguish between
+       calendar object resources and collections when using standard
+       WebDAV techniques to examine the contents of a collection.
+
+   b.  Collections contained in calendar collections MUST NOT contain
+       calendar collections at any depth. i.e., "nesting" of calendar
+       collections within other calendar collections at any depth is not
+       allowed.  This specification does not define how collections
+       contained in a calendar collection are used or how they relate to
+       any calendar object resources contained in the calendar
+       collection.
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 10]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Multiple calendar collections MAY be children of the same collection.
+
+
+5.  Calendar Access Feature
+
+5.1.  Calendar Access Support
+
+   A server supporting the features described in this document MUST
+   include "calendar-access" as a field in the DAV response header from
+   an OPTIONS request on any resource that supports any calendar
+   properties, reports, method, or privilege.  A value of "calendar-
+   access" in the DAV response header MUST indicate that the server
+   supports all MUST level requirements specified in this document.
+
+5.1.1.  Example: Using OPTIONS for the Discovery of Calendar Access
+        Support
+
+   >> Request <<
+
+   OPTIONS /home/bernard/calendars/ HTTP/1.1
+   Host: cal.example.com
+
+   >> Response <<
+
+   HTTP/1.1 200 OK
+   Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
+   Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
+   DAV: 1, 2, 3, access-control, calendar-access
+   Date: Fri, 11 Nov 2005 09:32:12 GMT
+   Content-Length: 0
+
+   In this example, the OPTIONS method returns the value "calendar-
+   access" in the DAV response header to indicate that the collection
+   "/home/bernard/calendars/" supports the properties, reports, methods,
+   or privileges defined in this specification.
+
+5.2.  Calendar Collection Properties
+
+   This section defines properties that MAY be defined on calendar
+   collections.
+
+5.2.1.  CALDAV:calendar-description Property
+
+   Name: calendar-description
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 11]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Provides a human-readable description of the calendar
+      collection.
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MAY be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).  An xml:lang attribute indicating
+      the human language of the description SHOULD be set for this
+      property by clients or through server provisioning.  Servers MUST
+      return any xml:lang attribute if set for the property.
+
+   Description: If present, the property contains a description of the
+      calendar collection that is suitable for presentation to a user.
+      If not present, the client should assume no description for the
+      calendar collection.
+
+   Definition:
+
+         <!ELEMENT calendar-description (#PCDATA)>
+         PCDATA value: string
+
+   Example:
+
+         <C:calendar-description xml:lang="fr-CA"
+            xmlns:C="urn:ietf:params:xml:ns:caldav"
+         >Calendrier de Mathilde Desruisseaux</C:calendar-description>
+
+5.2.2.  CALDAV:calendar-timezone Property
+
+   Name: calendar-timezone
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies a time zone on a calendar collection.
+
+   Conformance: This property SHOULD be defined on all calendar
+      collections.  If defined, it SHOULD NOT be returned by a PROPFIND
+      DAV:allprop request (as defined in Section 14.2 of [I-D.ietf-
+      webdav-rfc2518bis]).
+
+   Description: The CALDAV:calendar-timezone property is used to specify
+      the time zone the server should rely on to resolve "date" values
+      and "date with local time" values (i.e., floating time) to "date
+      with UTC time" values.  The server will require this information
+      to determine if a calendar component scheduled with "date" values
+      or "date with local time" values overlaps a CALDAV:time-range
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 12]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      specified in a CALDAV:calendar-query REPORT.  The server will also
+      require this information to compute the proper FREEBUSY time
+      period as "date with UTC time" in the VFREEBUSY component returned
+      in a response to a CALDAV:free-busy-query REPORT request that
+      takes into account calendar components scheduled with "date"
+      values or "date with local time" values.  In the absence of this
+      property the server MAY rely on the time zone of their choice.
+
+   Note: The iCalendar data embedded within the CALDAV:calendar-timezone
+      XML element MUST follow the standard XML character data encoding
+      rules, including use of &lt;, &gt;, &amp; etc entity encoding or
+      the use of a <[!CDATA[ ... ]]> construct.  In the later case the
+      iCalendar data cannot contain the character sequence "]]>" which
+      is the end delimiter for the CDATA section.
+
+   Definition:
+
+         <!ELEMENT calendar-timezone (#PCDATA)>
+         PCDATA value: an iCalendar object with exactly one VTIMEZONE
+               component.
+
+   Example:
+
+   <C:calendar-timezone
+       xmlns:C="urn:ietf:params:xml:ns:caldav">BEGIN:VCALENDAR
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   VERSION:2.0
+   BEGIN:VTIMEZONE
+   TZID:US-Eastern
+   LAST-MODIFIED:19870101T000000Z
+   BEGIN:STANDARD
+   DTSTART:19671029T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   TZNAME:Eastern Standard Time (US &amp; Canada)
+   END:STANDARD
+   BEGIN:DAYLIGHT
+   DTSTART:19870405T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   TZNAME:Eastern Daylight Time (US &amp; Canada)
+   END:DAYLIGHT
+   END:VTIMEZONE
+   END:VCALENDAR
+   </C:calendar-timezone>
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 13]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+5.2.3.  CALDAV:supported-calendar-component-set Property
+
+   Name: supported-calendar-component-set
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies the calendar component types (e.g., VEVENT, VTODO,
+      etc.) that calendar object resources can contain in the calendar
+      collection.
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MUST be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).
+
+   Description: The CALDAV:supported-calendar-component-set property is
+      used to specify restrictions on the calendar component types that
+      calendar object resources may contain in a calendar collection.
+      Any attempt by the client to store calendar object resources with
+      component types not listed in this property, if it exists, MUST
+      result in an error, with the CALDAV:supported-calendar-component
+      precondition (Section 5.3.2.1) being violated.  Since this
+      property is protected it cannot be changed by clients using a
+      PROPPATCH request.  However, clients can initialize the value of
+      this property when creating a new calendar collection with
+      MKCALENDAR.  The empty-element tag <C:comp name="VTIMEZONE"/> MUST
+      only be specified if support for calendar object resources that
+      only contain VTIMEZONE components is provided or desired.  Support
+      for VTIMEZONE components in calendar object resources that contain
+      VEVENT or VTODO components is always assumed.  In the absence of
+      this property the server MUST accept all component types, and the
+      client can assume that.
+
+   Definition:
+
+         <!ELEMENT supported-calendar-component-set (comp*)>
+
+   Example:
+
+         <C:supported-calendar-component-set
+             xmlns:C="urn:ietf:params:xml:ns:caldav">
+           <C:comp name="VEVENT"/>
+           <C:comp name="VTODO"/>
+         </C:supported-calendar-component-set>
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 14]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+5.2.4.  CALDAV:supported-calendar-data Property
+
+   Name: supported-calendar-data
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies what media types are allowed for calendar object
+      resources in a calendar collection.
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MUST be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).
+
+   Description: The CALDAV:supported-calendar-data property is used to
+      specify the media type supported for the calendar object resources
+      contained in a given calendar collection (e.g., iCalendar version
+      2.0).  Any attempt by the client to store calendar object
+      resources with a media type not listed in this property MUST
+      result in an error, with the CALDAV:supported-calendar-data
+      precondition (Section 5.3.2.1) being violated.  In the absence of
+      this property the server MUST accept data with the media type
+      "text/calendar" and iCalendar version 2.0, and clients can assume
+      that.
+
+   Definition:
+
+         <!ELEMENT supported-calendar-data (calendar-data*)>
+
+   Example:
+
+         <C:supported-calendar-data
+            xmlns:C="urn:ietf:params:xml:ns:caldav">
+           <C:calendar-data content-type="text/calendar" version="2.0"/>
+         </C:supported-calendar-data>
+
+5.2.5.  CALDAV:max-resource-size Property
+
+   Name: max-resource-size
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Provides a numeric value indicating the maximum size of
+      resource in octets that the server is willing to accept when a
+      calendar object resource is stored in a calendar collection.
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 15]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MUST be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).
+
+   Description: The CALDAV:max-resource-size is used to specify a
+      numeric value that represents the maximum size in octets that the
+      server is willing to accept when a calendar object resource is
+      stored in a calendar collection.  Any attempt to store a calendar
+      object resource exceeding this size MUST result in an error, with
+      the CALDAV:max-resource-size precondition (Section 5.3.2.1) being
+      violated.  In the absence of this property the client can assume
+      that the server will allow storing a resource of any reasonable
+      size.
+
+   Definition:
+
+         <!ELEMENT max-resource-size (#PCDATA)>
+         PCDATA value: a numeric value (positive integer)
+
+   Example:
+
+         <C:max-resource-size xmlns:C="urn:ietf:params:xml:ns:caldav"
+         >102400</C:max-resource-size>
+
+5.2.6.  CALDAV:min-date-time Property
+
+   Name: min-date-time
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Provides a date-time value indicating the earliest date and
+      time (in UTC) that the server is willing to accept for any date or
+      time value in a calendar object resource stored in a calendar
+      collection.
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MUST be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).
+
+   Description: The CALDAV:min-date-time is used to specify an iCalendar
+      DATE-TIME value in UTC that indicates the earliest inclusive date
+      that the server is willing to accept for any explicit date or time
+      value in a calendar object resource stored in a calendar
+      collection.  Any attempt to store a calendar object resource using
+      a date or time value earlier than this value MUST result in an
+      error, with the CALDAV:min-date-time precondition
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 16]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      (Section 5.3.2.1) being violated.  Note that servers MUST accept
+      recurring components that specify instances beyond this limit,
+      provided none of those instances have been overridden.  In that
+      case the server MAY simply ignore those instances outside of the
+      acceptable range when processing reports on the calendar object
+      resource.  In the absence of this property the client can assume
+      any valid iCalendar date may be used at least up to the CALDAV:
+      max-date-time value if that is defined.
+
+   Definition:
+
+         <!ELEMENT min-date-time (#PCDATA)>
+         PCDATA value: an iCalendar format DATE-TIME value in UTC
+
+   Example:
+
+         <C:min-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
+         >19000101T000000Z</C:min-date-time>
+
+5.2.7.  CALDAV:max-date-time Property
+
+   Name: max-date-time
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Provides a date-time value indicating the latest date and
+      time (in UTC) that the server is willing to accept for any date or
+      time value in a calendar object resource stored in a calendar
+      collection.
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MUST be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).
+
+   Description: The CALDAV:max-date-time is used to specify an iCalendar
+      DATE-TIME value in UTC that indicates the inclusive latest date
+      that the server is willing to accept for any date or time value in
+      a calendar object resource stored in a calendar collection.  Any
+      attempt to store a calendar object resource using a date or time
+      value later than this value MUST result in an error, with the
+      CALDAV:max-date-time precondition (Section 5.3.2.1) being
+      violated.  Note that servers MUST accept recurring components that
+      specify instances beyond this limit, provided none of those
+      instances have been overridden.  In that case the server MAY
+      simply ignore those instances outside of the acceptable range when
+      processing reports on the calendar object resource.  In the
+      absence of this property the client can assume any valid iCalendar
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 17]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      date may be used at least down to the CALDAV:min-date-time value
+      if that is defined.
+
+   Definition:
+
+         <!ELEMENT max-date-time (#PCDATA)>
+         PCDATA value: an iCalendar format DATE-TIME value in UTC
+
+   Example:
+
+         <C:max-date-time xmlns:C="urn:ietf:params:xml:ns:caldav"
+         >20491231T235959Z</C:max-date-time>
+
+5.2.8.  CALDAV:max-instances Property
+
+   Name: max-instances
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Provides a numeric value indicating the maximum number of
+      recurrence instances that a calendar object resource stored in a
+      calendar collection can generate.
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MUST be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).
+
+   Description: The CALDAV:max-instances is used to specify a numeric
+      value that indicates the maximum number of recurrence instances
+      that a calendar object resource stored in a calendar collection
+      can generate.  Any attempt to store a calendar object resource
+      with a recurrence pattern that generates more instances than this
+      value MUST result in an error, with the CALDAV:max-instances
+      precondition (Section 5.3.2.1) being violated.  In the absence of
+      this property the client can assume that the server has no limits
+      on the number of recurrence instances it can handle or expand.
+
+   Definition:
+
+         <!ELEMENT max-instances (#PCDATA)>
+         PCDATA value: a numeric value (integer greater than zero)
+
+   Example:
+
+         <C:max-instances xmlns:C="urn:ietf:params:xml:ns:caldav"
+         >100</C:max-instances>
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 18]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+5.2.9.  CALDAV:max-attendees-per-instance Property
+
+   Name: max-attendees-per-instance
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Provides a numeric value indicating the maximum number of
+      ATTENDEE properties in any instance of a calendar object resource
+      stored in a calendar collection.
+
+   Conformance: This property MAY be defined on any calendar collection.
+      If defined, it MUST be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).
+
+   Description: The CALDAV:max-attendees-per-instance is used to specify
+      a numeric value that indicates the maximum number of iCalendar
+      ATTENDEE properties on any one instance of a calendar object
+      resource stored in a calendar collection.  Any attempt to store a
+      calendar object resource with more ATTENDEE properties per
+      instance than this value MUST result in an error, with the CALDAV:
+      max-attendees-per-instance precondition (Section 5.3.2.1) being
+      violated.  In the absence of this property the client can assume
+      that the server can handle any number of ATTENDEE properties in a
+      calendar component.
+
+   Definition:
+
+         <!ELEMENT max-attendees-per-instance (#PCDATA)>
+         PCDATA value: a numeric value (integer greater than zero)
+
+   Example:
+
+         <C:max-attendees-per-instance
+              xmlns:C="urn:ietf:params:xml:ns:caldav"
+         >25</C:max-attendees-per-instance>
+
+5.2.10.  Additional Precondition for PROPPATCH
+
+   This specification requires an additional Precondition (see Section
+   16 of [I-D.ietf-webdav-rfc2518bis] for the PROPPATCH method.  The
+   precondition is:
+
+      (CALDAV:valid-calendar-data): The time zone specified in CALDAV:
+      calendar-timezone property MUST be a valid iCalendar object
+      containing a single valid VTIMEZONE component.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 19]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+5.3.  Creating Resources
+
+   The creation of calendar collections and calendar object resources
+   may be initiated by either a CalDAV client or by the CalDAV server.
+   For example, a server might come pre-configured with a user's
+   calendar collection, or the CalDAV client might request the server to
+   create a new calendar collection for a given user.  Servers might
+   populate events as calendar objects inside a calendar collection, or
+   clients might request the server to create events.  Either way, both
+   client and server MUST comply with the requirements in this document,
+   and MUST understand objects appearing in calendar collections or
+   according to the data model defined here.
+
+5.3.1.  MKCALENDAR Method
+
+   An HTTP request using the MKCALENDAR method creates a new calendar
+   collection resource.  A server MAY restrict calendar collection
+   creation to particular collections.
+
+   Support for MKCALENDAR on the server is only RECOMMENDED and not
+   REQUIRED because some calendar stores only support one calendar per
+   user (or principal) and those are typically pre-created for each
+   account.  However, servers and clients are strongly encouraged to
+   support MKCALENDAR whenever possible to allow users to create
+   multiple calendar collections to better help organize their data.
+
+   Clients SHOULD use the DAV:displayname property for a human-readable
+   name of the calendar.  Clients can either specify the value of the
+   DAV:displayname property in the request body of the MKCALENDAR
+   request, or alternatively issue a PROPPATCH request to change the
+   DAV:displayname property to the appropriate value immediately after
+   issuing the MKCALENDAR request.  Clients SHOULD NOT set the DAV:
+   displayname property to be the same as any other calendar collection
+   at the same URI "level".  When displaying calendar collections to
+   users, clients SHOULD check the DAV:displayname property and use that
+   value as the name of the calendar.  In the event that the DAV:
+   displayname property is empty, the client MAY use the last part of
+   the calendar collection URI as the name, however that path segment
+   may be "opaque" and not represent any meaningful human-readable text.
+
+   If a MKCALENDAR request fails, the server state preceding the request
+   MUST be restored.
+
+   Marshalling:
+
+      If a request body is included, it MUST be a CALDAV:mkcalendar XML
+      element.  Instruction processing MUST occur in the order
+      instructions are received (i.e., from top to bottom).
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 20]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      Instructions MUST either all be executed or none executed.  Thus
+      if any error occurs during processing, all executed instructions
+      MUST be undone and a proper error result returned.  Instruction
+      processing details can be found in the definition of the DAV:set
+      instruction in Section 14.26 of [I-D.ietf-webdav-rfc2518bis].
+
+         <!ELEMENT mkcalendar (DAV:set)>
+
+      If a response body for a successful request is included, it MUST
+      be a CALDAV:mkcalendar-response XML element.
+
+         <!ELEMENT mkcalendar-response ANY>
+
+      The response MUST include a Cache-Control:no-cache header.
+
+   Preconditions:
+
+      (DAV:resource-must-be-null): A resource MUST NOT exist at the
+      Request-URI;
+
+      (CALDAV:calendar-collection-location-ok): The Request-URI MUST
+      identify a location where a calendar collection can be created;
+
+      (CALDAV:valid-calendar-data): The time zone specified in the
+      CALDAV:calendar-timezone property MUST be a valid iCalendar object
+      containing a single valid VTIMEZONE component;
+
+      (DAV:needs-privilege): The DAV:bind privilege MUST be granted to
+      the current user on the parent collection of the Request-URI.
+
+   Postconditions:
+
+      (CALDAV:initialize-calendar-collection): A new calendar collection
+      exists at the Request-URI.  The DAV:resourcetype of the calendar
+      collection MUST contain both DAV:collection and CALDAV:calendar
+      XML elements.
+
+5.3.1.1.  Status Codes
+
+   The following are examples of response codes one would expect to get
+   in a response to a MKCALENDAR request.  Note that this list is by no
+   means exhaustive.
+
+      201 (Created) - The calendar collection resource was created in
+      its entirety;
+
+      207 (Multi-Status) - The calendar collection resource was not
+      created since one or more DAV:set instructions specified in the
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 21]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      request body could not be processed successfully.  The following
+      are examples of response codes one would expect to be used in a
+      207 (Multi-Status) response in this situation:
+
+         403 (Forbidden) - The client, for reasons the server chooses
+         not to specify, cannot alter one of the properties;
+
+         409 (Conflict) - The client has provided a value whose
+         semantics are not appropriate for the property.  This includes
+         trying to set read-only properties;
+
+         424 (Failed Dependency) - The DAV:set instruction on the
+         specified resource would have succeeded if it were not for the
+         failure of another DAV:set instruction specified in the request
+         body;
+
+         423 (Locked) - The specified resource is locked and the client
+         either is not a lock owner or the lock type requires a lock
+         token to be submitted and the client did not submit it; and
+
+         507 (Insufficient Storage) - The server did not have sufficient
+         space to record the property;
+
+      403 (Forbidden) - This indicates at least one of two conditions:
+      1) the server does not allow the creation of calendar collections
+      at the given location in its namespace, or 2) the parent
+      collection of the Request-URI exists but cannot accept members;
+
+      409 (Conflict) - A collection cannot be made at the Request-URI
+      until one or more intermediate collections have been created;
+
+      415 (Unsupported Media Type) - The server does not support the
+      request type of the body; and
+
+      507 (Insufficient Storage) - The resource does not have sufficient
+      space to record the state of the resource after the execution of
+      this method.
+
+5.3.1.2.  Example: Successful MKCALENDAR request
+
+   This example creates a calendar collection called /home/lisa/
+   calendars/events/ on the server cal.example.com with specific values
+   for the properties DAV:displayname, CALDAV:calendar-description,
+   CALDAV:supported-calendar-component-set, and CALDAV:calendar-
+   timezone.
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 22]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
+   Host: cal.example.com
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:mkcalendar xmlns:D="DAV:"
+                 xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:set>
+       <D:prop>
+         <D:displayname>Lisa's Events</D:displayname>
+         <C:calendar-description xml:lang="en"
+   >Calendar restricted to events.</C:calendar-description>
+         <C:supported-calendar-component-set>
+           <C:comp name="VEVENT"/>
+         </C:supported-calendar-component-set>
+         <C:calendar-timezone><![CDATA[BEGIN:VCALENDAR
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   VERSION:2.0
+   BEGIN:VTIMEZONE
+   TZID:US-Eastern
+   LAST-MODIFIED:19870101T000000Z
+   BEGIN:STANDARD
+   DTSTART:19671029T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   TZNAME:Eastern Standard Time (US & Canada)
+   END:STANDARD
+   BEGIN:DAYLIGHT
+   DTSTART:19870405T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   TZNAME:Eastern Daylight Time (US & Canada)
+   END:DAYLIGHT
+   END:VTIMEZONE
+   END:VCALENDAR
+   ]]></C:calendar-timezone>
+       </D:prop>
+     </D:set>
+   </C:mkcalendar>
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 23]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Response <<
+
+   HTTP/1.1 201 Created
+   Cache-Control: no-cache
+   Date: Fri, 11 Nov 2005 09:32:12 GMT
+   Content-Length: 0
+
+5.3.2.  Creating Calendar Object Resources
+
+   Clients populate calendar collections with calendar object resources.
+   The URL for each calendar object resource is entirely arbitrary, and
+   does not need to bear a specific relationship to the calendar object
+   resource's iCalendar properties or other metadata.  New calendar
+   object resources MUST be created with a PUT request targeted at an
+   unmapped URI.  A PUT request targeted at a mapped URI updates an
+   existing calendar object resource.
+
+   When servers create new resources, it's not hard for the server to
+   choose an unmapped URI.  It's slightly tougher for clients, because a
+   client might not want to examine all resources in the collection, and
+   might not want to lock the entire collection to ensure that a new
+   resource isn't created with a name collision.  However, there is an
+   HTTP feature to mitigate this.  If the client intends to create a new
+   non-collection resource, such as a new VEVENT, the client SHOULD use
+   the HTTP request header "If-None-Match: *" on the PUT request.  The
+   Request-URI on the PUT request MUST include the target collection,
+   where the resource is to be created, plus the name of the resource in
+   the last path segment.  The "If-None-Match: *" request header ensures
+   that the client will not inadvertently overwrite an existing
+   resource, if the last path segment turned out to already be used.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 24]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   PUT /home/lisa/calendars/events/qwue23489.ics HTTP/1.1
+   If-None-Match: *
+   Host: cal.example.com
+   Content-Type: text/calendar
+   Content-Length: xxxx
+
+   BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VEVENT
+   UID:20010712T182145Z-123401@example.com
+   DTSTAMP:20060712T182145Z
+   DTSTART:20060714T170000Z
+   DTEND:20060715T040000Z
+   SUMMARY:Bastille Day Party
+   END:VEVENT
+   END:VCALENDAR
+
+   >> Response <<
+
+   HTTP/1.1 201 Created
+   Content-Length: 0
+   Date: Fri, 11 Nov 2005 09:32:12 GMT
+   ETag: "123456789-000-111"
+
+   The request to change an existing event is the same, but with a
+   specific ETag in the "If-Match" header, rather than the "If-None-
+   Match" header.
+
+   As indicated in Section 3.10 of [RFC2445], the URL of calendar object
+   resources containing (an arbitrary set of) calendaring and scheduling
+   information may be suffixed by ".ics", and the URL of calendar object
+   resources containing free or busy time information may be suffixed by
+   ".ifb".
+
+5.3.2.1.  Additional Preconditions for PUT, COPY and MOVE
+
+   This specification creates additional Preconditions (see Section 16
+   of [I-D.ietf-webdav-rfc2518bis] for PUT, COPY and MOVE methods.
+   These preconditions apply:
+
+      When a PUT operation of a calendar object resource into a calendar
+      collection occurs.
+
+      When a COPY or MOVE operation of a calendar object resource into a
+      calendar collection occurs.
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 25]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   The new preconditions are:
+
+      (CALDAV:supported-calendar-data): The resource submitted in the
+      PUT request, or targeted by a COPY or MOVE request MUST be a
+      supported media type (i.e., iCalendar) for calendar object
+      resources;
+
+      (CALDAV:valid-calendar-data): The resource submitted in the PUT
+      request, or targeted by a COPY or MOVE request MUST be valid data
+      for the media type being specified (i.e., MUST contain valid
+      iCalendar data);
+
+      (CALDAV:valid-calendar-object-resource): The resource submitted in
+      the PUT request, or targeted by a COPY or MOVE request MUST obey
+      all restrictions specified in Section 4.1 (e.g., calendar object
+      resources MUST NOT contain more than one type of calendar
+      component, calendar object resources MUST NOT specify the
+      iCalendar METHOD property, etc.);
+
+      (CALDAV:supported-calendar-component): The resource submitted in
+      the PUT request, or targeted by a COPY or MOVE request MUST
+      contain a type of calendar component that is supported in the
+      targeted calendar collection;
+
+      (CALDAV:no-uid-conflict): The resource submitted in the PUT
+      request, or targeted by a COPY or MOVE request MUST NOT specify an
+      iCalendar UID property value already in use in the targeted
+      calendar collection or overwrite an existing calendar object
+      resource with one that has a different UID property value.
+      Servers SHOULD report the URL of the resource that is already
+      making use of the same UID property value in the DAV:href element;
+
+                <!ELEMENT no-uid-conflict (DAV:href)>
+
+      (CALDAV:calendar-collection-location-ok): In a COPY or MOVE
+      request, when the Request-URI is a calendar collection, the
+      Destination-URI MUST identify a location where a calendar
+      collection can be created;
+
+      (CALDAV:max-resource-size): The resource submitted in the PUT
+      request, or targeted by a COPY or MOVE request MUST have an octet
+      size less than or equal to the value of the CALDAV:max-resource-
+      size property value (Section 5.2.5) on the calendar collection
+      where the resource will be stored;
+
+      (CALDAV:min-date-time): The resource submitted in the PUT request,
+      or targeted by a COPY or MOVE request MUST have all of its
+      iCalendar date or time property values (for each recurring
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 26]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      instance) greater than or equal to the value of the CALDAV:min-
+      date-time property value (Section 5.2.6) on the calendar
+      collection where the resource will be stored;
+
+      (CALDAV:max-date-time): The resource submitted in the PUT request,
+      or targeted by a COPY or MOVE request MUST have all of its
+      iCalendar date or time property values (for each recurring
+      instance) less than the value of the CALDAV:max-date-time property
+      value (Section 5.2.7) on the calendar collection where the
+      resource will be stored;
+
+      (CALDAV:max-instances): The resource submitted in the PUT request,
+      or targeted by a COPY or MOVE request MUST generate a number of
+      recurring instances less than or equal to the value of the CALDAV:
+      max-instances property value (Section 5.2.8) on the calendar
+      collection where the resource will be stored;
+
+      (CALDAV:max-attendees-per-instance): The resource submitted in the
+      PUT request, or targeted by a COPY or MOVE request MUST have a
+      number of ATTENDEE properties on any one instance less than or
+      equal to the value of the CALDAV:max-attendees-per-instance
+      property value (Section 5.2.9) on the calendar collection where
+      the resource will be stored;
+
+5.3.3.  Non-standard components, properties and parameters
+
+   iCalendar provides a "standard mechanism for doing non-standard
+   things".  This extension support allows implementers to make use of
+   non-standard components, properties and parameters whose names are
+   prefixed with the text "X-".
+
+   Servers MUST support the use of non-standard components, properties
+   and parameters in calendar object resources stored via the PUT
+   method.
+
+   Servers may need to enforce rules for their own "private" components,
+   properties or parameters, so servers MAY reject any attempt by the
+   client to change those or use values for those outside of any
+   restrictions the server may have.  Servers SHOULD ensure that any
+   "private" components, properties or parameters it uses follow the
+   convention of including a vendor id in the "X-" name as described in
+   Section 4.2 of [RFC2445], e.g., "X-ABC-Private".
+
+5.3.4.  Calendar Object Resource Entity Tag
+
+   The DAV:getetag property MUST be defined and set to a strong entity
+   tag on all calendar object resources.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 27]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   A response to a GET request targeted at a calendar object resource
+   MUST contain an ETag response header field indicating the current
+   value of the strong entity tag of the calendar object resource.
+
+   Servers SHOULD return a strong entity tag (ETag header) in a PUT
+   response when the stored calendar object resource is equivalent by
+   octet equality to the calendar object resource submitted in the body
+   of the PUT request.  This allows clients to reliably use the returned
+   strong entity tag for data synchronization purposes.  For instance,
+   the client can do a PROPFIND request on the stored calendar object
+   resource and have the DAV:getetag property returned, and compare that
+   value with the strong entity tag it received on the PUT response, and
+   know that if they are equal, then the calendar object resource on the
+   server has not been changed.
+
+   In the case where the data stored by a server as a result of a PUT
+   request is not equivalent by octet equality to the submitted calendar
+   object resource, the behavior of the ETag response header is
+   undefined, with the exception that a strong entity tag MUST NOT be
+   returned in the response.  As a result, clients may need to retrieve
+   the modified calendar object resource (and ETag) as a basis for
+   further changes, rather than use the calendar object resource it had
+   sent with the PUT request.
+
+
+6.  Calendaring Access Control
+
+6.1.  Calendaring Privilege
+
+   CalDAV servers MUST support and adhere to the requirements of WebDAV
+   ACL [RFC3744].  WebDAV ACL provides a framework for an extensible set
+   of privileges that can be applied to WebDAV collections and ordinary
+   resources.  CalDAV servers MUST also support the calendaring
+   privilege defined in this section.
+
+6.1.1.  CALDAV:read-free-busy Privilege
+
+   Calendar users often wish to allow other users to see their busy time
+   information, without viewing the other details of the calendar
+   components (e.g., location, summary, attendees).  This allows a
+   significant amount of privacy while still allowing other users to
+   schedule meetings at times when the user is likely to be free.
+
+   The CALDAV:read-free-busy privilege controls which calendar
+   collections, regular collections and calendar object resources are
+   examined when a CALDAV:free-busy-query REPORT request is processed
+   (see Section 7.9).  This privilege can be granted on calendar
+   collections, regular collections or calendar object resources.
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 28]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Servers MUST support this privilege on all calendar collections,
+   regular collections and calendar object resources.
+
+
+           <!ELEMENT read-free-busy EMPTY>
+
+   The CALDAV:read-free-busy privilege MUST be aggregated in the DAV:
+   read privilege.  Servers MUST allow the CALDAV:read-free-busy to be
+   granted without the DAV:read privilege being granted.
+
+   Clients should note that when only the CALDAV:read-free-busy
+   privilege has been granted on a resource, this does not imply access
+   to GET, HEAD, OPTIONS and PROPFIND on the resource -- those
+   operations are governed by the DAV:read privilege.
+
+6.2.  Additional Principal Property
+
+   This section defines an additional property for WebDAV principal
+   resources as defined in [RFC3744].
+
+6.2.1.  CALDAV:calendar-home-set Property
+
+   Name: calendar-home-set
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Identifies the URL of any WebDAV collections that contain
+      calendar collections owned by the associated principal resource.
+
+   Conformance: This property MAY be defined in a principal resource.
+      If defined, it MAY be protected and SHOULD NOT be returned by a
+      PROPFIND DAV:allprop request (as defined in Section 14.2 of
+      [I-D.ietf-webdav-rfc2518bis]).  Support for this property is
+      RECOMMENDED.
+
+   Description: The CALDAV:calendar-home-set property is meant to allow
+      users to easily find the calendar collections owned by the
+      principal.  Typically, users will group all the calendar
+      collections that they own under a common collection.  This
+      property specifies the URL of collections that either are calendar
+      collections or ordinary collections that have child or descendant
+      calendar collections owned by the principal.
+
+   Definition:
+
+         <!ELEMENT calendar-home-set (DAV:href*)>
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 29]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Example:
+
+       <C:calendar-home-set xmlns:D="DAV:"
+                            xmlns:C="urn:ietf:params:xml:ns:caldav">
+         <D:href>http://cal.example.com/home/bernard/calendars/</D:href>
+       </C:calendar-home-set>
+
+
+7.  Calendaring Reports
+
+   This section defines the REPORTs that CalDAV servers MUST support on
+   calendar collections and calendar object resources.
+
+   CalDAV servers MUST advertise support for these REPORTs on all
+   calendar collections and calendar object resources with the DAV:
+   supported-report-set property defined in Section 3.1.5 of [RFC3253].
+   CalDAV servers MAY also advertise support for these REPORTs on
+   ordinary collections.
+
+   Some of these REPORTs allow calendar data (from possibly multiple
+   resources) to be returned.
+
+7.1.  REPORT Method
+
+   The REPORT method (defined in Section 3.6 of [RFC3253]) provides an
+   extensible mechanism for obtaining information about one or more
+   resources.  Unlike the PROPFIND method, which returns the value of
+   one or more named properties, the REPORT method can involve more
+   complex processing.  REPORT is valuable in cases where the server has
+   access to all of the information needed to perform the complex
+   request (such as a query), and where it would require multiple
+   requests for the client to retrieve the information needed to perform
+   the same request.
+
+   CalDAV servers MUST support the DAV:expand-property REPORT defined in
+   Section 3.8 of [RFC3253].
+
+7.2.  Ordinary collections
+
+   Servers MAY support the REPORTs defined in this document on ordinary
+   collections (collections that are not calendar collections) in
+   addition to calendar collections or calendar object resources.  In
+   computing responses to the REPORTs on ordinary collections, servers
+   MUST only consider calendar object resources contained in calendar
+   collections that are targeted by the REPORT based on the value of the
+   Depth request header.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 30]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+7.3.  Date and floating time
+
+   iCalendar provides a way to specify DATE and DATE-TIME values that
+   are not bound to any time zone in particular, hereafter called
+   "floating date" and "floating time" respectively.  These values are
+   used to represent the same day, hour, minute and second value
+   regardless of which time zone is being observed.  For instance, the
+   DATE value "20051111", represents November 11th, 2005 in no specific
+   time zone, while the DATE-TIME value "20051111T111100" represents
+   November 11th, 2005 at 11:11 AM in no specific time zone.
+
+   CalDAV servers may need to convert "floating date" and "floating
+   time" values in date with UTC time values in the processing of
+   calendaring REPORT requests.
+
+   For the CALDAV:calendar-query REPORT, CalDAV servers MUST rely on the
+   value of the CALDAV:timezone XML element, if specified as part of the
+   request body, to perform the proper conversion of "floating date" and
+   "floating time" values to date with UTC time values.  If the CALDAV:
+   timezone XML element is not specified in the request body, CalDAV
+   servers MUST rely on the value of the CALDAV:calendar-timezone
+   property, if defined, else the CalDAV servers MAY rely on the time
+   zone of their choice.
+
+   For the CALDAV:free-busy-query REPORT, CalDAV servers MUST rely on
+   the value of the CALDAV:calendar-timezone property, if defined, to
+   compute the proper FREEBUSY time period value as date with UTC time,
+   for calendar components scheduled with "floating date" or "floating
+   time".  If the CALDAV:calendar-timezone property is not defined,
+   CalDAV servers MAY rely on the time zone of their choice.
+
+7.4.  Time range filtering
+
+   Some of the reports defined in this section can include a time range
+   filter that is used to restrict the set of calendar object resources
+   returned to just those that overlap the specified time range.  The
+   time range filter can be applied to a calendar component as a whole,
+   or to specific calendar component properties with date or date-time
+   value types.
+
+   To determine whether a calendar object resource matches the time
+   range filter element, the start and end times for the targeted
+   component or property are determined and then compared to the
+   requested time range.  If there is an overlap with the requested time
+   range, then the calendar object resource matches the filter element.
+   The rules defined in [RFC2445] for determining the actual start and
+   end times of calendar components MUST be used, and these are fully
+   enumerated in Section 9.8 of this document.
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 31]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   When such time range filtering is used, special consideration must be
+   given to recurring calendar components such as VEVENT and VTODO
+   components.  The server MUST expand recurring components to determine
+   whether any recurrence instances overlap the specified time range.
+   If one or more recurrence instances overlap the time range, then the
+   calendar object resource matches the filter element.
+
+7.5.  Partial Retrieval
+
+   Some calendaring REPORTs defined in this document allow partial
+   retrieval of calendar object resources.  A CalDAV client MAY specify
+   what information to return in the body of a calendaring REPORT
+   request.
+
+   A CalDAV client MAY request particular WebDAV property values, all
+   WebDAV property values, or a list of the names of the resource's
+   WebDAV properties.  A CalDAV client MAY also request calendar data to
+   be returned and whether all calendar components and properties should
+   be returned or only particular ones.  See CALDAV:calendar-data in
+   Section 9.5.
+
+   By default, the returned calendar data will include the component
+   that defines the recurrence set, referred to as the "master
+   component", as well as the components that define exceptions to the
+   recurrence set, referred to as the "overridden components".
+
+   A CalDAV client only interested in the recurrence instances that
+   overlap a specified time range MAY request to receive only the
+   "master component" along with the "overridden components" that impact
+   the specified time range and thus limit the data returned by the
+   server.  See CALDAV:limit-recurrence-set in Section 9.5.6.  An
+   overridden component impacts a time range if its current start and
+   end times overlap the time range, or if the original start and end
+   times - the ones that would have been used if the instance were not
+   overridden - overlap the time range.
+
+   A CalDAV client with no support for recurrence properties (i.e.,
+   EXDATE, EXRULE, RDATE and RRULE) and possibly VTIMEZONE components,
+   or a client not willing to perform recurrence expansion because of
+   limited processing capability MAY request to receive only the
+   recurrence instances that overlap a specified time range as separate
+   calendar components that each define exactly one recurrence instance.
+   See CALDAV:expand in Section 9.5.5.
+
+   Finally, in the case of VFREEBUSY components, a CalDAV client MAY
+   request to receive only the FREEBUSY property values that overlap a
+   specified time range.  See CALDAV:limit-freebusy-set in
+   Section 9.5.7.
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 32]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+7.6.  Non-standard components, properties and parameters
+
+   Servers MUST support the use of non-standard component, property or
+   parameter names in the CALDAV:calendar-data XML element in
+   calendaring REPORT requests to allow clients to request that non-
+   standard components, properties and parameters be returned in the
+   calendar data provided in the response.
+
+   Servers MAY support the use of non-standard component, property or
+   parameter names in the CALDAV:comp-filter, CALDAV:prop-filter and
+   CALDAV:param-filter XML elements specified in the CALDAV:filter XML
+   element of calendaring REPORT requests.
+
+   Servers MUST fail with the CALDAV:supported-filter precondition if a
+   calendaring REPORT request uses a CALDAV:comp-filter, CALDAV:prop-
+   filter or CALDAV:param-filter XML element that makes reference to a
+   non-standard component, property or parameter name which the server
+   does not support queries on.
+
+7.7.  CALDAV:calendar-query Report
+
+   The CALDAV:calendar-query REPORT performs a search for all calendar
+   object resources that match a specified filter.  The response of this
+   REPORT will contain all the WebDAV properties and calendar object
+   resource data specified in the request.  In the case of the CALDAV:
+   calendar-data XML element, one can explicitly specify the calendar
+   components and properties that should be returned in the calendar
+   object resource data that matches the filter.
+
+   The format of this REPORT is modeled on the PROPFIND method.  The
+   request and response bodies of the CALDAV:calendar-query REPORT use
+   XML elements that are also used by PROPFIND.  In particular the
+   request can include XML elements to request WebDAV properties to be
+   returned.  When that occurs the response should follow the same
+   behavior as PROPFIND with respect to the DAV:multistatus response
+   elements used to return specific property results.  For instance, a
+   request to retrieve the value of a property which does not exist is
+   an error and MUST be noted with a response XML element which contains
+   a 404 (Not Found) status value.
+
+   Support for the CALDAV:calendar-query REPORT is REQUIRED.
+
+   Marshalling:
+
+      The request body MUST be a CALDAV:calendar-query XML element as
+      defined in Section 9.4.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 33]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      The request MAY include a Depth header.  If no Depth header is
+      included, Depth:0 is assumed.
+
+      The response body for a successful request MUST be a DAV:
+      multistatus XML element (i.e., the response uses the same format
+      as the response for PROPFIND).  In the case where there are no
+      response elements, the returned DAV:multistatus XML element is
+      empty.
+
+      The response body for a successful CALDAV:calendar-query REPORT
+      request MUST contain a DAV:response element for each iCalendar
+      object that matched the search filter.  Calendar data is being
+      returned in the CALDAV:calendar-data XML element inside the DAV:
+      propstat XML element.
+
+   Preconditions:
+
+      (CALDAV:supported-calendar-data): The attributes "content-type"
+      and "version" of the CALDAV:calendar-data XML element (see
+      Section 9.5) specify a media type supported by the server for
+      calendar object resources.
+
+      (CALDAV:valid-filter): The CALDAV:filter XML element (see
+      Section 9.6) specified in the REPORT request MUST be valid.  For
+      instance, a CALDAV:filter cannot nest a <C:comp name="VEVENT">
+      element in a <C:comp name="VTODO"> element, or a CALDAV:filter
+      cannot nest a <C:time-range start="..." end="..."> element in a
+      <C:prop name="SUMMARY"> element.
+
+      (CALDAV:supported-filter): The CALDAV:comp-filter (see
+      Section 9.6.1), CALDAV:prop-filter (see Section 9.6.2) and CALDAV:
+      param-filter (see Section 9.6.3) XML elements used in the CALDAV:
+      filter XML element (see Section 9.6) in the REPORT request only
+      make reference to components, properties and parameters for which
+      queries are supported by the server. i.e., if the CALDAV:filter
+      element attempts to reference an unsupported component, property
+      or parameter, this precondition is violated.  Servers SHOULD
+      report the CALDAV:comp-filter, CALDAV:prop-filter or CALDAV:param-
+      filter for which it does not provide support.
+
+            <!ELEMENT supported-filter (comp-filter*,
+                                        prop-filter*,
+                                        param-filter*)>
+
+      (CALDAV:valid-calendar-data): The time zone specified in the
+      REPORT request MUST be a valid iCalendar object containing a
+      single valid VTIMEZONE component.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 34]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      (CALDAV:min-date-time): Any XML element specifying a range of time
+      MUST have its start or end date or time values greater than or
+      equal to the value of the CALDAV:min-date-time property value
+      (Section 5.2.6) on the calendar collections being targeted by the
+      REPORT;
+
+      (CALDAV:max-date-time): Any XML element specifying a range of time
+      MUST have its start or end date or time values less than or equal
+      to the value of the CALDAV:max-date-time property value
+      (Section 5.2.7) on the calendar collections being targeted by the
+      REPORT;
+
+   Postconditions:
+
+      (DAV:number-of-matches-within-limits): The number of matching
+      calendar object resources must fall within server-specific,
+      predefined limits.  For example, this condition might be triggered
+      if a search specification would cause the return of an extremely
+      large number of responses.
+
+7.7.1.  Example: Partial retrieval of events by time range
+
+   In this example, the client requests the server to return specific
+   components and properties of the VEVENT components that overlap the
+   time range from January 4th, 2006 at 00:00:00 AM UTC to January 5th,
+   2006 at 00:00:00 AM UTC.  In addition the DAV:getetag property is
+   also requested and returned as part of the response.  Note that the
+   first calendar object returned is a recurring event whose first
+   instance lies outside of the requested time range, but whose third
+   instance does overlap the time range.  Note that due to the CALDAV:
+   calendar-data element restrictions, the DTSTAMP property in VEVENT
+   components has not been returned, and the only property returned in
+   the VCALENDAR object is VERSION.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 35]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:D="DAV:"
+                 xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop>
+       <D:getetag/>
+       <C:calendar-data>
+         <C:comp name="VCALENDAR">
+           <C:prop name="VERSION"/>
+           <C:comp name="VEVENT">
+             <C:prop name="SUMMARY"/>
+             <C:prop name="UID"/>
+             <C:prop name="DTSTART"/>
+             <C:prop name="DTEND"/>
+             <C:prop name="DURATION"/>
+             <C:prop name="RRULE"/>
+             <C:prop name="RDATE"/>
+             <C:prop name="EXRULE"/>
+             <C:prop name="EXDATE"/>
+             <C:prop name="RECURRENCE-ID"/>
+           </C:comp>
+           <C:comp name="VTIMEZONE"/>
+         </C:comp>
+       </C:calendar-data>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT">
+           <C:time-range start="20060104T000000Z"
+                         end="20060105T000000Z"/>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2005 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 36]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+              xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd2"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTART;TZID=US/Eastern:20060102T120000
+   DURATION:PT1H
+   RRULE:FREQ=DAILY;COUNT=5
+   SUMMARY:Event #2
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   BEGIN:VEVENT
+   DTSTART;TZID=US/Eastern:20060104T140000
+   DURATION:PT1H
+   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+   SUMMARY:Event #2 bis
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   BEGIN:VEVENT
+   DTSTART;TZID=US/Eastern:20060106T140000
+   DURATION:PT1H
+   RECURRENCE-ID;TZID=US/Eastern:20060106T120000
+   SUMMARY:Event #2 bis bis
+   UID:00959BC664CA650E933C892C@example.com
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 37]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd3"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTART;TZID=US/Eastern:20060104T100000
+   DURATION:PT1H
+   SUMMARY:Event #3
+   UID:DC6C50A017428C5216A2F1CD@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 38]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+7.7.2.  Example: Partial retrieval of recurring events
+
+   In this example, the client requests the server to return VEVENT
+   components that overlap the time range from January 3rd, 2006 at 00:
+   00:00 AM UTC to January 5th, 2006 at 00:00:00 AM UTC.  Use of the
+   CALDAV:limit-recurrence-set element causes the server to only return
+   overridden recurrence components that overlap the time range
+   specified in that element, or that affect other instances that
+   overlap the time range (e.g., in the case of a "THISANDFUTURE"
+   behavior).  In this example the first overridden component in the
+   matching resource is returned but the second one is not.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:D="DAV:"
+                     xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop>
+       <C:calendar-data>
+         <C:limit-recurrence-set start="20060103T000000Z"
+                                 end="20060105T000000Z"/>
+       </C:calendar-data>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT">
+           <C:time-range start="20060103T000000Z"
+                         end="20060105T000000Z"/>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 39]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+              xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd2"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART;TZID=US/Eastern:20060102T120000
+   DURATION:PT1H
+   RRULE:FREQ=DAILY;COUNT=5
+   SUMMARY:Event #2
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART;TZID=US/Eastern:20060104T140000
+   DURATION:PT1H
+   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+   SUMMARY:Event #2 bis
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 40]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd3"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+   DTSTAMP:20060206T001220Z
+   DTSTART;TZID=US/Eastern:20060104T100000
+   DURATION:PT1H
+   LAST-MODIFIED:20060206T001330Z
+   ORGANIZER:mailto:cyrus@example.com
+   SEQUENCE:1
+   STATUS:TENTATIVE
+   SUMMARY:Event #3
+   UID:DC6C50A017428C5216A2F1CD@example.com
+   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 41]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+     </D:response>
+   </D:multistatus>
+
+7.7.3.  Example: Expanded retrieval of recurring events
+
+   In this example, the client requests the server to return VEVENT
+   components that overlap the time range from January 2nd, 2006 at 00:
+   00:00 AM UTC to January 5th, 2006 at 00:00:00 AM UTC and to return
+   recurring calendar components expanded into individual recurrence
+   instance calendar components.  Use of the CALDAV:expand element
+   causes the server to only return overridden recurrence instances that
+   overlap the time range specified in that element.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:D="DAV:"
+                     xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop>
+       <C:calendar-data>
+         <C:expand start="20060103T000000Z"
+                   end="20060105T000000Z"/>
+       </C:calendar-data>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT">
+           <C:time-range start="20060103T000000Z"
+                         end="20060105T000000Z"/>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 42]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+              xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd2"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART:20060103T170000
+   DURATION:PT1H
+   RECURRENCE-ID:20060103T170000
+   SUMMARY:Event #2
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART:20060104T190000
+   DURATION:PT1H
+   RECURRENCE-ID:20060104T170000
+   SUMMARY:Event #2 bis
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd3"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VEVENT
+   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+   DTSTAMP:20060206T001220Z
+   DTSTART:20060104T150000
+   DURATION:PT1H
+   LAST-MODIFIED:20060206T001330Z
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 43]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   ORGANIZER:mailto:cyrus@example.com
+   SEQUENCE:1
+   STATUS:TENTATIVE
+   SUMMARY:Event #3
+   UID:DC6C50A017428C5216A2F1CD@example.com
+   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+7.7.4.  Example: Partial retrieval of stored free busy components
+
+   In this example, the client requests the server to return the
+   VFREEBUSY components that have free busy information that overlap the
+   time range from January 2nd, 2006 at 00:00:00 AM UTC (inclusively) to
+   January 3rd, 2006 at 00:00:00 AM UTC (exclusively).  Use of the
+   CALDAV:limit-freebusy-set element causes the server to only return
+   the FREEBUSY property values that overlap the time range specified in
+   that element.  Note that this is not an example of discovering when
+   the calendar owner is busy.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 44]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:D="DAV:"
+                 xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop>
+       <C:calendar-data>
+         <C:limit-freebusy-set start="20060102T000000Z"
+                                 end="20060103T000000Z"/>
+       </C:calendar-data>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VFREEBUSY">
+           <C:time-range start="20060102T000000Z"
+                           end="20060103T000000Z"/>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 45]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                  xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd8"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VFREEBUSY
+   ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
+   UID:76ef34-54a3d2@example.com
+   DTSTAMP:20050530T123421Z
+   DTSTART:20060101T100000Z
+   DTEND:20060108T100000Z
+   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
+   END:VFREEBUSY
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+7.7.5.  Example: Retrieval of to-dos by alarm time range
+
+   In this example, the client requests the server to return the VTODO
+   components that have an alarm trigger scheduled in the specified time
+   range.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 46]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop xmlns:D="DAV:">
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VTODO">
+           <C:comp-filter name="VALARM">
+             <C:time-range start="20060106T100000Z"
+                             end="20060107T100000Z"/>
+           </C:comp-filter>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 47]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                  xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd4"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTODO
+   DTSTAMP:20060205T235300Z
+   DUE;TZID=US/Eastern:20060106T120000
+   LAST-MODIFIED:20060205T235308Z
+   SEQUENCE:1
+   STATUS:NEEDS-ACTION
+   SUMMARY:Task #2
+   UID:E10BA47467C5C69BB74E8720@example.com
+   BEGIN:VALARM
+   ACTION:AUDIO
+   TRIGGER;RELATED=START:-PT10M
+   END:VALARM
+   END:VTODO
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+7.7.6.  Example: Retrieval of event by UID
+
+   In this example, the client requests the server to return the VEVENT
+   component that has the UID property set to
+   "DC6C50A017428C5216A2F1CD@example.com".
+
+   See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 48]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop xmlns:D="DAV:">
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT">
+           <C:prop-filter name="UID">
+             <C:text-match caseless="no">
+              DC6C50A017428C5216A2F1CD@example.com</C:text-match>
+           </C:prop-filter>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                  xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd3"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 49]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+   DTSTAMP:20060206T001220Z
+   DTSTART;TZID=US/Eastern:20060104T100000
+   DURATION:PT1H
+   LAST-MODIFIED:20060206T001330Z
+   ORGANIZER:mailto:cyrus@example.com
+   SEQUENCE:1
+   STATUS:TENTATIVE
+   SUMMARY:Event #3
+   UID:DC6C50A017428C5216A2F1CD@example.com
+   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+7.7.7.  Example: Retrieval of events by PARTSTAT
+
+   In this example, the client requests the server to return the VEVENT
+   components that have the ATTENDEE property with the value
+   "mailto:lisa@example.com" and for which the PARTSTAT parameter is set
+   to "NEEDS-ACTION".
+
+   See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 50]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop xmlns:D="DAV:">
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT">
+           <C:prop-filter name="ATTENDEE">
+             <C:text-match
+               caseless="yes">mailto:lisa@example.com</C:text-match>
+             <C:param-filter name="PARTSTAT">
+               <C:text-match caseless="yes">NEEDS-ACTION</C:text-match>
+             </C:param-filter>
+           </C:prop-filter>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                  xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd3"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 51]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+   DTSTAMP:20060206T001220Z
+   DTSTART;TZID=US/Eastern:20060104T100000
+   DURATION:PT1H
+   LAST-MODIFIED:20060206T001330Z
+   ORGANIZER:mailto:cyrus@example.com
+   SEQUENCE:1
+   STATUS:TENTATIVE
+   SUMMARY:Event #3
+   UID:DC6C50A017428C5216A2F1CD@example.com
+   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+7.7.8.  Example: Retrieval of events only
+
+   In this example, the client requests the server to return all VEVENT
+   components.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 52]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop xmlns:D="DAV:">
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT"/>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                  xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd1"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 53]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001102Z
+   DTSTART;TZID=US/Eastern:20060102T100000
+   DURATION:PT1H
+   SUMMARY:Event #1
+   Description:Go Steelers!
+   UID:74855313FA803DA593CD579A@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd2"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 54]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART;TZID=US/Eastern:20060102T120000
+   DURATION:PT1H
+   RRULE:FREQ=DAILY;COUNT=5
+   SUMMARY:Event #2
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART;TZID=US/Eastern:20060104T140000
+   DURATION:PT1H
+   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+   SUMMARY:Event #2 bis
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART;TZID=US/Eastern:20060106T140000
+   DURATION:PT1H
+   RECURRENCE-ID;TZID=US/Eastern:20060106T120000
+   SUMMARY:Event #2 bis bis
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd3"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 55]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+   DTSTAMP:20060206T001220Z
+   DTSTART;TZID=US/Eastern:20060104T100000
+   DURATION:PT1H
+   LAST-MODIFIED:20060206T001330Z
+   ORGANIZER:mailto:cyrus@example.com
+   SEQUENCE:1
+   STATUS:TENTATIVE
+   SUMMARY:Event #3
+   UID:DC6C50A017428C5216A2F1CD@example.com
+   X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+7.7.9.  Example: Retrieval of all pending to-dos
+
+   In this example, the client requests the server to return all VTODO
+   components that do not include a "COMPLETED" property and do not have
+   a "STATUS" property value matching "CANCELLED". i.e., VTODOs that
+   still need to be worked on.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 56]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop xmlns:D="DAV:">
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VTODO">
+           <C:prop-filter name="COMPLETED">
+             <C:is-not-defined/>
+           </C:prop-filter>
+           <C:prop-filter name="STATUS">
+             <C:text-match
+                negate-condition="yes">CANCELLED</c:text-match>
+           </C:prop-filter>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                  xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd4"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTODO
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 57]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   DTSTAMP:20060205T235335Z
+   DUE;VALUE=DATE:20060104
+   STATUS:NEEDS-ACTION
+   SUMMARY:Task #1
+   UID:DDDEEB7915FA61233B861457@example.com
+   BEGIN:VALARM
+   ACTION:AUDIO
+   TRIGGER;RELATED=START:-PT10M
+   END:VALARM
+   END:VTODO
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd5"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTODO
+   DTSTAMP:20060205T235300Z
+   DUE;VALUE=DATE:20060106
+   LAST-MODIFIED:20060205T235308Z
+   SEQUENCE:1
+   STATUS:NEEDS-ACTION
+   SUMMARY:Task #2
+   UID:E10BA47467C5C69BB74E8720@example.com
+   BEGIN:VALARM
+   ACTION:AUDIO
+   TRIGGER;RELATED=START:-PT10M
+   END:VALARM
+   END:VTODO
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 58]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+7.7.10.  Example: Attempt to query unsupported property
+
+   In this example, the client requests the server to return all VEVENT
+   components that include an "X-ABC-GUID" property with a value
+   matching "ABC".  However, the server does not support querying that
+   non-standard property and instead returns and error response.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop xmlns:D="DAV:">
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT">
+           <C:prop-filter name="X-ABC-GUID">
+             <C:text-match>ABC</C:text-match>
+           </C:prop-filter>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 403 Forbidden
+   Date: Fri, 11 Nov 2005 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:error>
+     <C:supported-filter>
+       <C:prop-filter name="X-ABC-GUID"/>
+     </C:supported-filter>
+   </D:error>
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 59]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+7.8.  CALDAV:calendar-multiget Report
+
+   The CALDAV:calendar-multiget REPORT is used to retrieve specific
+   calendar object resources from within a collection, if the Request-
+   URI is a collection, or to retrieve a specific calendar object
+   resource, if the Request-URI is a calendar object resource.  This
+   REPORT is similar to the CALDAV:calendar-query REPORT (see
+   Section 7.7), except that it takes a list of DAV:href elements
+   instead of a CALDAV:filter element to determine which calendar object
+   resources to return.
+
+   Support for the calendar-multiget REPORT is REQUIRED.
+
+   Marshalling:
+
+      The request body MUST be a CALDAV:calendar-multiget XML element
+      (see Section 9.9).  If the Request-URI is a collection resource,
+      then the DAV:href elements MUST refer to calendar object resources
+      within that collection, and they MAY refer to calendar object
+      resources at any depth within the collection.  As a result the
+      "Depth" header MUST be ignored by the server and SHOULD NOT be
+      sent by the client.  If the Request-URI refers to a non-collection
+      resource, then there MUST be a single DAV:href element that is
+      equivalent to the Request-URI.
+
+      The response body for a successful request MUST be a DAV:
+      multistatus XML element.
+
+      The response body for a successful CALDAV:calendar-multiget REPORT
+      request MUST contain a DAV:response element for each calendar
+      object resource referenced by the provided set of DAV:href
+      elements.  Calendar data is being returned in the CALDAV:calendar-
+      data element inside the DAV:prop element.
+
+      In the case of an error accessing any of the provided DAV:href
+      resources, the server MUST return the appropriate error status
+      code in the DAV:status element of the corresponding DAV:response
+      element.
+
+   Preconditions:
+
+      (CALDAV:supported-calendar-data): The attributes "content-type"
+      and "version" of the CALDAV:calendar-data XML elements (see
+      Section 9.5) specify a media type supported by the server for
+      calendar object resources.
+
+      (CALDAV:min-date-time): Any XML element specifying a range of time
+      MUST have its start or end date or time values greater than or
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 60]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      equal to the value of the CALDAV:min-date-time property value
+      (Section 5.2.6) on the calendar collections being targeted by the
+      REPORT;
+
+      (CALDAV:max-date-time): Any XML element specifying a range of time
+      MUST have its start or end date or time values less than or equal
+      to the value of the CALDAV:max-date-time property value
+      (Section 5.2.7) on the calendar collections being targeted by the
+      REPORT;
+
+   Postconditions:
+
+      None.
+
+7.8.1.  Example: Successful CALDAV:calendar-multiget Report
+
+   In this example, the client requests the server to return specific
+   properties of the VEVENT components referenced by specific URIs.  In
+   addition the DAV:getetag property is also requested and returned as
+   part of the response.  Note that in this example, the resource at
+   http://cal.example.com/bernard/work/mtg1.ics does not exist,
+   resulting in an error status response.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-multiget xmlns:D="DAV:"
+                    xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop>
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <D:href>/bernard/work/abcd1.ics</D:href>
+     <D:href>/bernard/work/mtg1.ics</D:href>
+   </C:calendar-multiget>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 61]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                  xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd1"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001102Z
+   DTSTART;TZID=US/Eastern:20060102T100000
+   DURATION:PT1H
+   SUMMARY:Event #1
+   Description:Go Steelers!
+   UID:74855313FA803DA593CD579A@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/mtg1.ics</D:href>
+       <D:status>HTTP/1.1 404 Not Found</D:status>
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 62]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+     </D:response>
+   </D:multistatus>
+
+7.9.  CALDAV:free-busy-query Report
+
+   The CALDAV:free-busy-query REPORT generates a VFREEBUSY component
+   containing free busy information for all the calendar object
+   resources targeted by the request and which have the CALDAV:read-
+   free-busy or DAV:read privilege granted to the current user.
+
+   Only VEVENT components without a TRANSP property or with the TRANSP
+   property set to "OPAQUE", and VFREEBUSY components SHOULD be
+   considered to generate the free busy time information.
+
+   In the case of VEVENT components, the free or busy time type (FBTYPE)
+   of the FREEBUSY properties in the returned VFREEBUSY component SHOULD
+   be derived from the value of the TRANSP and STATUS properties as
+   outlined in the table below:
+
+         +---------------------------++------------------+
+         |          VEVENT           ||    VFREEBUSY     |
+         +-------------+-------------++------------------+
+         | TRANSP      | STATUS      || FBTYPE           |
+         +=============+=============++==================+
+         |             | CONFIRMED   || BUSY             |
+         |             | (default)   ||                  |
+         | OPAQUE      +-------------++------------------+
+         | (default)   | CANCELLED   || FREE             |
+         |             +-------------++------------------+
+         |             | TENTATIVE   || BUSY-TENTATIVE   |
+         |             +-------------++------------------+
+         |             | x-name      || BUSY or          |
+         |             |             || x-name           |
+         +-------------+-------------++------------------+
+         |             | CONFIRMED   ||                  |
+         | TRANSPARENT | CANCELLED   || FREE             |
+         |             | TENTATIVE   ||                  |
+         |             | x-name      ||                  |
+         +-------------+-------------++------------------+
+
+   Duplicate busy time periods with the same FBTYPE parameter value
+   SHOULD NOT be specified in the returned VFREEBUSY component.  Servers
+   SHOULD coalesce consecutive or overlapping busy time period of the
+   same type.  Busy time periods with different FBTYPE parameter values
+   MAY overlap.
+
+   Support for the CALDAV:free-busy-query REPORT is REQUIRED.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 63]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Marshalling:
+
+      The request body MUST be a CALDAV:free-busy-query XML element (see
+      Section 9.10, which MUST contain exactly one CALDAV:time-range XML
+      element, as defined in Section 9.8.
+
+      The request MAY include a Depth header.  If no Depth header is
+      included, Depth:0 is assumed.
+
+      The response body for a successful request MUST be an iCalendar
+      object that contains exactly one VFREEBUSY component that
+      describes the busy time intervals for the calendar object
+      resources containing VEVENT or VFREEBUSY components that satisfy
+      the Depth value and for which the current user is at least granted
+      the CALDAV:read-free-busy privilege.  If no calendar object
+      resources are found to satisfy these conditions a VFREEBUSY
+      component with no FREEBUSY property MUST be returned.  This REPORT
+      only returns busy time information.  Free time information can be
+      inferred from the returned busy time information.
+
+      If the current user is not granted the CALDAV:read-free-busy or
+      DAV:read privileges on the Request-URI, the CALDAV:free-busy-query
+      REPORT request MUST fail and return a 404 (Not Found) status
+      value.  This restriction will prevent users from discovering URLs
+      of resources for which they are only granted the CALDAV:read-free-
+      busy privilege.
+
+      The CALDAV:free-busy-query REPORT request can only be run against
+      a collection (either a regular collection or a calendar
+      collection).  An attempt to run the report on a calendar object
+      resource MUST fail and return a 403 (Forbidden) status value.
+
+   Preconditions:
+
+      None.
+
+   Postconditions:
+
+      (DAV:number-of-matches-within-limits): The number of matching
+      calendar object resources must fall within server-specific,
+      predefined limits.  For example, this postcondition might fail if
+      the specified CALDAV:time-range would cause an extremely large
+      number calendar object resources to be considered to compute the
+      response.
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 64]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+7.9.1.  Example: Successful CALDAV:free-busy-query Report
+
+   In this example, the client requests the server to return free busy
+   information on the calendar collection /bernard/work/, between 9:00
+   AM and 5:00 PM EST (2:00 PM and 10:00 PM UTC) on the 4th January
+   2006.  The server responds indicating two busy time intervals of one
+   hour, one of which is tentative.
+
+   See Appendix B for the calendar data being targeted by this example.
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:free-busy-query xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <C:time-range start="20060104T140000Z"
+                     end="20060105T220000Z"/>
+   </C:free-busy-query>
+
+   >> Response <<
+
+   HTTP/1.1 200 OK
+   Date: Fri, 11 Nov 2006 09:32:12 GMT
+   Content-Type: text/calendar
+   Content-Length: xxxx
+
+   BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Server//EN
+   BEGIN:VFREEBUSY
+   DTSTAMP:20050125T090000Z
+   DTSTART:20060104T140000Z
+   DTEND:20060105T220000Z
+   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060104T150000Z/PT1H
+   FREEBUSY:20060104T190000Z/PT1H
+   END:VFREEBUSY
+   END:VCALENDAR
+
+
+8.  Guidelines
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 65]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+8.1.  Client-to-client Interoperability
+
+   There are a number of actions clients can take which will be legal
+   (the server will not return errors) but which can degrade
+   interoperability with other client implementations accessing the same
+   data.  For example, a recurrence rule could be replaced with a set of
+   recurrence dates, a single recurring event could be replaced with a
+   set of independent resources to represent each recurrence, or the
+   start/end time values can be translated from the original time zone
+   to another time zone.  Although this advice amounts to iCalendar
+   interoperability best practices and is not limited only to CalDAV
+   usage, interoperability problems are likely to be more evident in
+   CalDAV use cases.
+
+8.2.  Synchronization Operations
+
+   WebDAV already provides functionality required to synchronize a
+   collection or set of collections, make changes offline, and a simple
+   way to resolve conflicts when reconnected.  ETags are the key to
+   making this work, but these are not required of all WebDAV servers.
+   Since offline functionality is more important to calendar
+   applications than to some other WebDAV applications, CalDAV servers
+   MUST support ETags as specified in Section 5.3.4.
+
+8.2.1.  Use of Reports
+
+8.2.1.1.  Restrict the Time Range
+
+   The REPORTs provided in CalDAV can be used by clients to optimize
+   their performance in terms of network bandwidth usage, and resource
+   consumption on the local client machine.  Both are certainly major
+   considerations for mobile or handheld devices with limited capacity,
+   but they are also relevant to desktop client applications in cases
+   where the calendar collections contain large amounts of data.
+
+   Typically clients present calendar data to users in views that span a
+   finite time interval, so whenever possible clients should only
+   retrieve calendar components from the server using CALDAV:calendar-
+   query REPORT combined with a CALDAV:time-range element to limit the
+   set of returned components to just those needed to populate the
+   current view.
+
+8.2.1.2.  Synchronize by Time Range
+
+   Typically in a calendar, historical data (events, to-dos etc. that
+   have completed prior to the current date) do not change, though they
+   may be deleted.  As a result, a client can speed up the
+   synchronization process by only considering data for the present time
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 66]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   and the future up to a reasonable limit (e.g., one week, one month).
+   If the user then tries to examine a portion of the calendar outside
+   of the range that has been synchronized, the client can perform
+   another synchronization operation on the new time interval being
+   examined.  This "just-in-time" synchronization can minimize bandwidth
+   for common user interaction behaviors.
+
+8.2.1.3.  Synchronization Process
+
+   If a client wants to support calendar data synchronization, as
+   opposed to downloading calendar data each time it is needed, it needs
+   to cache the calendar object resource's URI and ETag along with the
+   actual calendar data.  While the URI remains static for the lifetime
+   of the calendar object resource, the ETag will change with each
+   successive change to the calendar object resource.  Thus to
+   synchronize a local data cache with the server, the client can first
+   fetch the URI/ETag pairs for the time interval being considered, and
+   compare those results with the cached data.  Any cached component
+   whose ETag differs from that on the server needs to be refreshed.
+
+   In order to properly detect the changes between the server and client
+   data, the client will need to keep a record of which calendar object
+   resources have been created, changed or deleted since the last
+   synchronization operation so that it can reconcile those changes with
+   the data on the server.
+
+   Here's an example of how to do that:
+
+   The client issues a CALDAV:calendar-query REPORT request for a
+   specific time range, and asks for only the DAV:getetag property to be
+   returned:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 67]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:D="DAV:"
+                     xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop>
+       <D:getetag/>
+     </D:prop>
+     <C:filter>
+       <C:comp-filter name="VCALENDAR">
+         <C:comp-filter name="VEVENT">
+           <C:time-range start="20040902T000000Z"
+                           end="20040903T000000Z"/>
+         </C:comp-filter>
+       </C:comp-filter>
+     </C:filter>
+   </C:calendar-query>
+
+   The client then uses the results to determine which calendar object
+   resources have changed, been created or deleted on the server and how
+   those relate to locally cached calendar object resources that may
+   have changed, been created or deleted.  If the client determines that
+   there are calendar object resources on the server that need to be
+   fetched, the client issues a CALDAV:calendar-multiget REPORT request
+   to fetch their calendar data:
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-multiget xmlns:D="DAV:"
+                        xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:prop>
+       <D:getetag/>
+       <C:calendar-data/>
+     </D:prop>
+     <D:href>/bernard/work/abcd1.ics</D:href>
+     <D:href>/bernard/work/mtg1.ics</D:href>
+   </C:calendar-multiget>
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 68]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+8.2.2.  Restrict the Properties Returned
+
+   Clients may not need all the calendar properties of a calendar object
+   resource when presenting information to the user.  Since some
+   calendar property values can be large (e.g., ATTACH or ATTENDEE)
+   clients can choose to restrict the calendar properties to be returned
+   in a calendaring REPORT request to those it knows it will use.
+
+   However, if a client needs to make a change to a calendar object
+   resource, it can only change the entire calendar object resource via
+   a PUT request.  There is currently no way to incrementally make a
+   change to a set of calendar properties of a calendar object resource.
+   As a result the client will have to get the entire calendar object
+   resource that is being changed.
+
+8.3.  Use of Locking
+
+   WebDAV locks can be used to prevent two clients modifying the same
+   resource from either overwriting each others' changes (though that
+   problem can also be solved by using ETags) or wasting time making
+   changes that will conflict with another set of changes.  In a multi-
+   user calendar system, an interactive calendar client could lock an
+   event while the user is editing the event, and unlock the event when
+   the user finishes or cancels.  Locks can also be used to prevent
+   changes while data is being reorganized.  For example, a calendar
+   client might lock two calendar collections prior to moving a bunch of
+   calendar resources from one to another.
+
+   Clients are responsible for requesting a lock timeout period that is
+   appropriate to the use case.  When the user explicitly decides to
+   reserve a resource and prevent other changes, a long timeout might be
+   appropriate, but in cases when the client automatically decides to
+   lock the resource the timeout should be short (and the client can
+   always refresh the lock should it need to).  A short lock timeout
+   means that if the client is unable to remove the lock, the other
+   calendar users aren't prevented from making changes.
+
+8.4.  Finding calendars
+
+   Much of the time a calendar client (or agent) will discover a new
+   calendar's location by being provided directly with the URL.  E.g., a
+   user will type his or her own calendar location into client
+   configuration information, or copy and paste a URL from email into
+   the calendar application.  The client need only confirm that the URL
+   points to a resource which is a calendar collection.  The client may
+   also be able to browse WebDAV collections to find calendar
+   collections.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 69]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   The choice of HTTP URLs means that calendar object resources are
+   backward compatible with existing software, but does have the
+   disadvantage that existing software does not usually know to look at
+   the OPTIONS response to that URL to determine what can be done with
+   it.  This is somewhat of a barrier for WebDAV usage as well as with
+   CalDAV usage.  This specification does not offer a way through this
+   other than making the information available in the OPTIONS response
+   should this be requested.
+
+   For calendar sharing and scheduling use cases, one might wish to find
+   the calendar belonging to another user.  If the other user has a
+   calendar in the same repository, that calendar can be found by using
+   the principal namespace required by WebDAV ACL support.  For other
+   cases, the authors have no universal solution but implementers can
+   consider whether to use vCard [RFC2426] or LDAP [RFC2251] standards
+   together with calendar attributes [RFC2739].
+
+   Because CalDAV requires servers to support WebDAV ACL [RFC3744]
+   including principal namespaces, and with the addition of the CALDAV:
+   calendar-home-set property, there are a couple options for CalDAV
+   clients to find one's own calendar or another user's calendar.
+
+   In this case, a DAV:principal-match REPORT is used to find a named
+   property (the CALDAV:calendar-home-set) on the Principal-URL of the
+   current user.  Using this, a WebDAV client can learn "who am I" and
+   "where are my calendars".  The REPORT request body looks like this:
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:principal-match xmlns:D="DAV:">
+     <D:self/>
+     <D:prop>
+       <C:calendar-home-set
+          xmlns:C="urn:ietf:params:xml:ns:caldav"/>
+     </D:prop>
+   </D:principal-match>
+
+   To find other users calendars, the DAV:principal-property-search
+   REPORT can be used to filter on some properties and return others.
+   To search for a calendar owned by a user named "Laurie", the REPORT
+   request body would look like this:
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 70]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:principal-property-search xmlns:D="DAV:">
+     <D:property-search>
+       <D:prop>
+         <D:displayname/>
+       </D:prop>
+       <D:match>Laurie</D:match>
+     </D:property-search>
+     <D:prop>
+       <C:calendar-home-set
+          xmlns:C="urn:ietf:params:xml:ns:caldav"/>
+       <D:displayname/>
+     </D:prop>
+   </D:principal-property-search>
+
+   The server performs a case-sensitive or caseless search for a
+   matching string subset of "Laurie" within the DAV:displayname
+   property.  Thus, the server might return "Laurie Dusseault", "Laurier
+   Desruisseaux" or "Wilfrid Laurier" all as matching DAV:displayname
+   values, and the calendars for each of these.
+
+8.5.  Storing and Using Attachments
+
+   CalDAV clients MAY create attachments in calendar components either
+   as inline or external.  This section contains some guidelines on
+   creating and managing attachments.
+
+8.5.1.  Inline attachments
+
+   CalDAV clients MUST support inline attachments as specified in
+   iCalendar [RFC2445].  CalDAV servers MUST support inline attachments,
+   so clients can rely on being able to create attachments this way.  On
+   the other hand, inline attachments have some drawbacks:
+
+   o  Servers MAY impose limitations on the size of calendar object
+      resources (i.e., refusing PUT requests of very large iCalendar
+      objects).  Servers that do that MUST use the CALDAV:max-resource-
+      size property on a calendar collection to inform the client as to
+      what the limitation is (see Section 5.2.5.
+
+   o  Servers MAY impose storage quota limitations on calendar
+      collections (See [RFC4331]).
+
+   o  Any change to a calendar object resource containing an attachment
+      requires the entire attachment to be re-uploaded.
+
+   o  Clients synchronizing a changed calendar object resource have to
+      download the entire calendar object resource even if the
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 71]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      attachment is unchanged.
+
+8.5.2.  External attachments
+
+   CalDAV clients MUST support external attachments: if the client
+   accesses any calendar object resource it MUST be capable of also
+   accessing the external attachment if one exists.  An external
+   attachment could be:
+
+   o  In a collection in the calendar collection containing the calendar
+      object resource;
+
+   o  Somewhere else in the same repository that hosts the calendar
+      collection; or
+
+   o  On an HTTP or FTP server elsewhere.
+
+   CalDAV servers MAY provide support for child collections in calendar
+   collections.  CalDAV servers MAY allow the MKCOL method to create
+   child collections in calendar collections.  Child collections of
+   calendar collections MAY contain any type of resource except calendar
+   collections which they MUST NOT contain.  Some CalDAV servers won't
+   allow child collections in calendar collections, and it may be
+   possible on such a server to discover other locations where
+   attachments can be stored.
+
+   Clients are entirely responsible for maintaining reference
+   consistency with calendar components that link to external
+   attachments.  A client deleting a calendar component with an external
+   attachment might therefore also delete the attachment if that's
+   appropriate, however appropriateness can be very hard to determine.
+   A new component might easily reference some pre-existing Web resource
+   which is intended to have independent existence from the calendar
+   component (the "attachment" could be a major proposal to be discussed
+   in a meeting, for instance).  Best practices will probably emerge and
+   should probably be documented but for now clients should be wary of
+   engaging in aggressive "cleanup" of external attachments.  A client
+   could involve the user in making decisions about removing
+   unreferenced documents, or a client could be conservative in only
+   deleting attachments it had created.
+
+   Also, clients are responsible for consistency of permissions when
+   using external attachments.  One reason for servers to support the
+   storage of attachments within child collections of calendar
+   collections is that ACL inheritance might make it easier to grant the
+   same permissions to attachments that are granted on the calendar
+   collection.  Otherwise, it can be very difficult to keep permissions
+   synchronized.  With attachments stored on separate repositories, it
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 72]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   can be impossible to keep permissions consistent -- the two
+   repositories may not support the same permissions or have the same
+   set of principals.  Some systems have used tickets or other anonymous
+   access control mechanisms to provide partially satisfactory solutions
+   to these kinds of problems.
+
+8.6.  Storing and Using Alarms
+
+   Note that all CalDAV calendar collections (including those which the
+   user might treat as public or group calendars) can contain alarm
+   information on events and to-dos.  Users can synchronize a calendar
+   between multiple devices and decide to have alarms execute on a
+   different device than the device that created the alarm.  Not all
+   alarm action types are completely interoperable (e.g., those which
+   name a sound file to play).
+
+      When the action is "AUDIO", and the client is configured to
+      execute the alarm, the client SHOULD play the suggested sound if
+      it's available or play another sound, but SHOULD NOT rewrite the
+      alarm just to replace the suggested sound with a sound that's
+      locally available.
+
+      When the action is "DISPLAY", and the client is configured to
+      execute the alarm, the client SHOULD execute a display alarm by
+      displaying either according to the suggested description or some
+      reasonable replacement, but SHOULD NOT rewrite the alarm for its
+      own convenience.
+
+      When the action is "EMAIL", and the client is incapable of sending
+      email, it SHOULD ignore the alarm but MUST continue to synchronize
+      the alarm itself.
+
+      This specification makes no recommendations about executing alarm
+      of type PROCEDURE except to note that clients are advised to take
+      care to avoid creating security holes by executing these.
+
+   Non-interoperable alarm information (e.g., should somebody define a
+   color to be used in a display alarm) should be put in non-standard
+   properties inside the VALARM component in order to keep the basic
+   alarm usable on all devices.
+
+   Clients that allow changes to calendar object resources MUST
+   synchronize the alarm data that already exists in the resources.
+   Clients MAY execute alarms that are downloaded in this fashion,
+   possibly based on user preference.  If a client is only doing read
+   operations on a calendar and there is no risk of losing alarm
+   information, then the client MAY discard alarm information.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 73]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   This specification makes no attempt to provide multi-user alarms on
+   group calendars or to find out who an alarm is intended for.
+   Addressing those issues might require extensions to iCalendar, for
+   example to store alarms per-user or indicate which user a VALARM was
+   intended for.  In the meantime, clients might maximize
+   interoperability by generally not uploading alarm information to
+   public, group or resource calendars.
+
+
+9.  XML Element Definitions
+
+9.1.  CALDAV:calendar XML Element
+
+   Name: calendar
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies the resource type of a calendar collection.
+
+   Description: See Section 4.2.
+
+   Definition:
+
+         <!ELEMENT calendar EMPTY>
+
+9.2.  CALDAV:mkcalendar XML Element
+
+   Name: mkcalendar
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies a request that includes the WebDAV property values
+      to be set for a calendar collection resource when it is created.
+
+   Description: See Section 5.3.1.
+
+   Definition:
+
+         <!ELEMENT mkcalendar (DAV:set)>
+
+9.3.  CALDAV:mkcalendar-response XML Element
+
+   Name: mkcalendar-response
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 74]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Purpose: Specifies a response body for a successful MKCALENDAR
+      request.
+
+   Description: See Section 5.3.1.
+
+   Definition:
+
+         <!ELEMENT mkcalendar-response ANY>
+
+9.4.  CALDAV:calendar-query XML Element
+
+   Name: calendar-query
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Defines a REPORT for querying calendar object resources.
+
+   Description: See Section 7.7.
+
+   Definition:
+
+         <!ELEMENT calendar-query ((DAV:allprop |
+                                    DAV:propname |
+                                    DAV:prop)?, filter, timezone?)>
+
+9.5.  CALDAV:calendar-data XML Element
+
+   Name: calendar-data
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Used to (1) specify a supported media type for calendar
+      object resources when nested in the CALDAV:supported-calendar-data
+      property; (2) specify which parts of a calendar object resource
+      should be returned by a given calendaring REPORT; and (3) specify
+      the content of a calendar object resource in a response to a
+      calendaring REPORT.
+
+   Description: When nested in the CALDAV:supported-calendar-data
+      property, the CALDAV:calendar-data XML element specifies a media
+      type supported by the CalDAV server for calendar object resources.
+
+      When used in a calendaring REPORT request, the CALDAV:calendar-
+      data XML element specifies which parts of calendar object
+      resources need to be returned in the response.  If the CALDAV:
+      calendar-data XML element doesn't contain any CALDAV:comp element,
+      calendar object resources will be returned in their entirety.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 75]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      Finally, when used in a calendaring REPORT response, the CALDAV:
+      calendar-data XML element specifies the content of a calendar
+      object resource.  Given that XML parsers normalize the two-
+      character sequence CRLF (US-ASCII decimal 13 and US-ASCII decimal
+      10) to a single LF character (US-ASCII decimal 10), the CR
+      character (US-ASCII decimal 13) MAY be omitted in calendar object
+      resources specified in the CALDAV:calendar-data XML element.
+      Furthermore, calendar object resources specified in the CALDAV:
+      calendar-data XML element MAY be invalid per their media type
+      specification if the CALDAV:calendar-data XML element part of the
+      calendaring REPORT request did not specify required properties
+      (e.g., UID, DTSTAMP, etc.) or specified a CALDAV:prop XML element
+      with the "novalue" attribute set to "yes".
+
+   Note: The CALDAV:calendar-data XML element is specified in requests
+      and responses inside the DAV:prop XML element as if it were a
+      WebDAV property.  However, the CALDAV:calendar-data XML element is
+      not a WebDAV property and as such it is not returned in PROPFIND
+      responses nor used in PROPPATCH requests.
+
+   Note: The iCalendar data embedded within the CALDAV:calendar-data XML
+      element MUST follow the standard XML character data encoding
+      rules, including use of &lt;, &gt;, &amp; etc entity encoding or
+      the use of a <[!CDATA[ ... ]]> construct.  In the later case the
+      iCalendar data cannot contain the character sequence "]]>" which
+      is the end delimiter for the CDATA section.
+
+   Definition:
+
+         <!ELEMENT calendar-data ((comp?, (expand |
+                                           limit-recurrence-set)?,
+                                           limit-freebusy-set?) |
+                                  #PCDATA)?>
+         PCDATA value: iCalendar object
+
+         <!ATTLIST calendar-data content-type CDATA "text/calendar">
+                                 version CDATA "2.0">
+         content-type value: a MIME media type
+         version value: a version string
+
+9.5.1.  CALDAV:comp XML Element
+
+   Name: comp
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 76]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Purpose: Defines which component types to return.
+
+   Description: The name value is a calendar component name (e.g.,
+      "VEVENT").
+
+   Definition:
+
+         <!ELEMENT comp ((allprop | prop*), (allcomp | comp*))>
+
+         <!ATTLIST comp name CDATA #REQUIRED>
+         name value: a calendar component name
+
+   Note: The CALDAV:prop and CALDAV:allprop elements have the same name
+      as the DAV:prop and DAV:allprop elements defined in [I-D.ietf-
+      webdav-rfc2518bis].  However, the CALDAV:prop and CALDAV:allprop
+      element are defined in the "urn:ietf:params:xml:ns:caldav"
+      namespace instead of the "DAV:" namespace.
+
+9.5.2.  CALDAV:allcomp XML Element
+
+   Name: allcomp
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies that all components shall be returned.
+
+   Description: The CALDAV:allcomp XML element can be used when the
+      client wants all types of components returned by a calendaring
+      REPORT request.
+
+   Definition:
+
+         <!ELEMENT allcomp EMPTY>
+
+9.5.3.  CALDAV:allprop XML Element
+
+   Name: allprop
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies that all properties shall be returned.
+
+   Description: The CALDAV:allprop XML element can be used when the
+      client wants all properties of components returned by a
+      calendaring REPORT request.
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 77]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Definition:
+
+         <!ELEMENT allprop EMPTY>
+
+   Note: The CALDAV:allprop element has the same name as the DAV:allprop
+      element defined in [I-D.ietf-webdav-rfc2518bis].  However, the
+      CALDAV:allprop element is defined in the
+      "urn:ietf:params:xml:ns:caldav" namespace instead of the "DAV:"
+      namespace.
+
+9.5.4.  CALDAV:prop XML Element
+
+   Name: prop
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Defines which properties to return in the response.
+
+   Description: The "name" attribute specifies the name of the calendar
+      property to return (e.g., "ATTENDEE").  The "novalue" attribute
+      can be used by clients to request that the actual value of the
+      property not be returned (if the "novalue" attribute is set to
+      "yes").  In that case the server will return just the iCalendar
+      property name and any iCalendar parameters and a trailing ":"
+      without the subsequent value data.
+
+   Definition:
+
+         <!ELEMENT prop EMPTY>
+
+         <!ATTLIST prop name CDATA #REQUIRED
+                     novalue (yes | no) "no">
+         name value: a calendar property name
+         novalue value: "yes" or "no"
+
+   Note: The CALDAV:prop element has the same name as the DAV:prop
+      element defined in [I-D.ietf-webdav-rfc2518bis].  However, the
+      CALDAV:prop element is defined in the
+      "urn:ietf:params:xml:ns:caldav" namespace instead of the "DAV:"
+      namespace.
+
+9.5.5.  CALDAV:expand XML Element
+
+   Name: expand
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 78]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Forces the server to expand recurring components into
+      individual recurrence instances.
+
+   Description: The CALDAV:expand XML element specifies that for a given
+      calendaring REPORT request the server MUST expand the recurrence
+      set into calendar components that define exactly one recurrence
+      instance and MUST return only those whose scheduled time intersect
+      a specified time range.  The "start" attribute specifies the
+      inclusive start of the time range, and the "end" attribute
+      specifies the non-inclusive end of the time range.  Both
+      attributes are specified as date with UTC time value.  The value
+      of the "end" attribute MUST be greater than the value of the
+      "start" attribute.  The server MUST use the same logic as defined
+      for CALDAV:time-range to determine if a recurrence instance
+      intersects the specified time range.  Recurring components, other
+      than the initial instance, MUST include a RECURRENCE-ID property
+      indicating which instance they refer to.  The returned calendar
+      components MUST NOT use recurrence properties (i.e., EXDATE,
+      EXRULE, RDATE and RRULE) and MUST NOT have reference to or include
+      VTIMEZONE components.  Date and local time with reference to time
+      zone information MUST be converted into date with UTC time.
+
+   Definition:
+
+         <!ELEMENT expand EMPTY>
+
+         <!ATTLIST expand start CDATA #REQUIRED
+                         end   CDATA #REQUIRED>
+         start value: an iCalendar "date with UTC time"
+         end value: an iCalendar "date with UTC time"
+
+9.5.6.  CALDAV:limit-recurrence-set XML Element
+
+   Name: limit-recurrence-set
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies a time range to limit the set of "overridden
+      components" returned by the server.
+
+   Description: The CALDAV:limit-recurrence-set XML element specifies
+      that for a given calendaring REPORT request the server MUST
+      return, in addition to the "master component", only the
+      "overridden components" that impact a specified time range.  An
+      overridden component impacts a time range if its current start and
+      end times overlap the time range, or if the original start and end
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 79]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      times - the ones that would have been used if the instance were
+      not overridden - overlap the time range.  The "start" attribute
+      specifies the inclusive start of the time range, and the "end"
+      attribute specifies the non-inclusive end of the time range.  Both
+      attributes are specified as date with UTC time value.  The value
+      of the "end" attribute MUST be greater than the value of the
+      "start" attribute.  The server MUST use the same logic as defined
+      for CALDAV:time-range to determine if the current or original
+      scheduled time of an "overridden" recurrence instance intersect
+      the specified time range.  Overridden components that have a RANGE
+      parameter on their RECURRENCE-ID property may specify one or more
+      instances in the recurrence set, and some of those instances may
+      fall within the specified time range, or may have originally
+      fallen within the specified time range prior to being overridden.
+      If that is the case, the overridden component MUST be included in
+      the results as it has a direct impact on the interpretation of
+      instances within the specified time range.
+
+   Definition:
+
+         <!ELEMENT limit-recurrence-set EMPTY>
+
+         <!ATTLIST limit-recurrence-set start CDATA #REQUIRED
+                                       end   CDATA #REQUIRED>
+         start value: an iCalendar "date with UTC time"
+         end value: an iCalendar "date with UTC time"
+
+9.5.7.  CALDAV:limit-freebusy-set XML Element
+
+   Name: limit-freebusy-set
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies a time range to limit the set of FREEBUSY values
+      returned by the server.
+
+   Description: The CALDAV:limit-freebusy-set XML element specifies that
+      for a given calendaring REPORT request the server MUST only return
+      the FREEBUSY property values of a VFREEBUSY component that
+      intersect a specified time range.  The "start" attribute specifies
+      the inclusive start of the time range, and the "end" attribute
+      specifies the non-inclusive end of the time range.  Both
+      attributes are specified as "date with UTC time" value.  The value
+      of the "end" attribute MUST be greater than the value of the
+      "start" attribute.  The server MUST use the same logic as defined
+      for CALDAV:time-range to determine if a FREEBUSY property value
+      intersect the specified time range.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 80]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Definition:
+
+         <!ELEMENT limit-freebusy-set EMPTY>
+
+         <!ATTLIST limit-freebusy-set start CDATA #REQUIRED
+                                     end   CDATA #REQUIRED>
+         start value: an iCalendar "date with UTC time"
+         end value: an iCalendar "date with UTC time"
+
+9.6.  CALDAV:filter XML Element
+
+   Name: filter
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies a filter to limit the set of calendar components
+      returned by the server.
+
+   Description: The CALDAV:filter XML element specifies the search
+      filter used to limit the calendar components returned by a
+      calendaring REPORT request.
+
+   Definition:
+
+         <!ELEMENT filter (comp-filter)>
+
+9.6.1.  CALDAV:comp-filter XML Element
+
+   Name: comp-filter
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies search criteria on calendar components.
+
+   Description: The CALDAV:comp-filter XML element specifies the queried
+      calendar component type (e.g., "VEVENT").  A calendar object
+      resource is said to match a CALDAV:comp-filter if:
+
+      *  A component of the type specified by the "name" attribute
+         exists, and the CALDAV:comp-filter is empty, or it contains at
+         least one recurrence instance scheduled to overlap a given time
+         range if a CALDAV:time-range XML element is specified, and that
+         any CALDAV:prop-filter and CALDAV:comp-filter child elements
+         also match.
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 81]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      or:
+
+      *  A component of the type specified by the "name" attribute does
+         not exist, and the CALDAV:is-not-defined element is specified.
+
+   Definition:
+
+         <!ELEMENT comp-filter (is-not-defined | (time-range?,
+                                prop-filter*, comp-filter*))>
+
+         <!ATTLIST comp-filter name CDATA #REQUIRED>
+         name value: a calendar component name (e.g., "VEVENT")
+
+9.6.2.  CALDAV:prop-filter XML Element
+
+   Name: prop-filter
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies search criteria on calendar properties.
+
+   Description: The CALDAV:prop-filter XML element specifies a search
+      criteria on a specific calendar property (e.g., CATEGORIES) in the
+      scope of a given CALDAV:comp-filter.  A calendar component is said
+      to match a CALDAV:prop-filter if:
+
+      *  A property of the type specified by the "name" attribute
+         exists, and the CALDAV:prop-filter is empty, or it matches the
+         CALDAV:time-range XML element or CALDAV:text-match conditions
+         if specified, and that any CALDAV:param-filter child elements
+         also match.
+
+      or:
+
+      *  A property of the type specified by the "name" attribute does
+         not exist, and the CALDAV:is-not-defined element is specified.
+
+   Definition:
+
+         <!ELEMENT prop-filter ((is-not-defined |
+                                ((time-range | text-match)?,
+                                 param-filter*))>
+
+         <!ATTLIST prop-filter name CDATA #REQUIRED>
+         name value: a calendar property name (e.g., "ATTENDEE")
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 82]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+9.6.3.  CALDAV:param-filter XML Element
+
+   Name: param-filter
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Limits the search to specific parameter values.
+
+   Description: The CALDAV:param-filter XML element specifies a search
+      criteria on a specific calendar property parameter (e.g.,
+      PARTSTAT) in the scope of a given CALDAV:prop-filter.  A calendar
+      property is said to match a CALDAV:param-filter if:
+
+      *  A parameter of the type specified by the "name" attribute
+         exists, and the CALDAV:param-filter is empty, or it matches the
+         CALDAV:text-match conditions if specified.
+
+      or:
+
+      *  A parameter of the type specified by the "name" attribute does
+         not exist, and the CALDAV:is-not-defined element is specified.
+
+   Definition:
+
+         <!ELEMENT param-filter (is-not-defined | text-match)?>
+
+         <!ATTLIST param-filter name CDATA #REQUIRED>
+         name value: a property parameter name (e.g., "PARTSTAT")
+
+9.6.4.  CALDAV:is-not-defined XML Element
+
+   Name: is-not-defined
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies that a match should occur if the enclosing
+      component, property or parameter does not exist.
+
+   Description: The CALDAV:is-not-defined XML element specifies that a
+      match occurs if the enclosing component, property or parameter
+      value specified in a calendaring REPORT request does not exist in
+      the calendar data being tested.
+
+   Definition:
+
+         <!ELEMENT is-not-defined EMPTY>
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 83]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+9.6.5.  CALDAV:text-match XML Element
+
+   Name: text-match
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies a substring match on a property or parameter
+      value.
+
+   Description: The CALDAV:text-match XML element specifies text used
+      for a substring match against the property or parameter value
+      specified in a calendaring REPORT request.
+
+      The "caseless" attribute indicates whether the match is case-
+      sensitive (value set to "no") or case-insensitive (value set to
+      "yes").  The default value is server-specified.  Support for the
+      "caseless" attribute is REQUIRED, and implementers of servers are
+      strongly encouraged to consult "The Unicode Standard" [UNICODE4],
+      especially Section 5.18, Subsection "Caseless Matching", for
+      guidance when implementing their case-insensitive matching
+      algorithms..  A server MAY ignore the caseless attribute when
+      applied to enumerated iCalendar property or parameter values, and
+      default to caseless matching for those values, since they are
+      defined as being case-insensitive in iCalendar.
+
+      The "negate-condition" attribute is used to indicate that this
+      test returns a match if the text matches, when the attribute value
+      is set to "no", or return a match if the text does not match, if
+      the attribute value is set to "yes".  For example, this can be
+      used to match components with a STATUS property not set to
+      CANCELLED.
+
+   Definition:
+
+         <!ELEMENT text-match (#PCDATA)>
+         PCDATA value: string
+
+         <!ATTLIST text-match caseless         (yes | no) #IMPLIED
+                              negate-condition (yes | no) "no">
+
+9.7.  CALDAV:timezone XML Element
+
+   Name: timezone
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 84]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Purpose: Specifies the time zone component to use when determining
+      the results of a report.
+
+   Description: The CALDAV:timezone XML element specifies that for a
+      given calendaring REPORT request the server MUST rely on the
+      specified VTIMEZONE component instead of the CALDAV:calendar-
+      timezone property of the calendar collection in which the calendar
+      object resource is contained to resolve "date" values and "date
+      with local time" values (i.e., floating time) to "date with UTC
+      time" values.  The server will require this information to
+      determine if a calendar component scheduled with "date" values or
+      "date with local time" values intersect a CALDAV:time-range
+      specified in a CALDAV:calendar-query REPORT.
+
+   Note: The iCalendar data embedded within the CALDAV:timezone XML
+      element MUST follow the standard XML character data encoding
+      rules, including use of &lt;, &gt;, &amp; etc entity encoding or
+      the use of a <[!CDATA[ ... ]]> construct.  In the later case the
+      iCalendar data cannot contain the character sequence "]]>" which
+      is the end delimiter for the CDATA section.
+
+   Definition:
+
+         <!ELEMENT timezone (#PCDATA)>
+         PCDATA value: an iCalendar object with exactly one VTIMEZONE
+
+9.8.  CALDAV:time-range XML Element
+
+   Name: time-range
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: Specifies a time range to limit the set of calendar
+      components returned by the server.
+
+   Description: The CALDAV:time-range XML element specifies that for a
+      given calendaring REPORT request the server MUST only return the
+      calendar object resources that, depending on the context, have a
+      component or property whose value intersect a specified time
+      range.  The "start" attribute specifies the inclusive start of the
+      time range, and the "end" attribute specifies the non-inclusive
+      end of the time range.  Both attributes MUST be specified as "date
+      with UTC time" value.  Time ranges open at one end can be
+      specified by including only one attribute, however at least one
+      attribute MUST always be present in the CALDAV:time-range element.
+      If either the "start" or "end" attribute is not specified in the
+      CALDAV:time-range XML element, assume "-infinity" and "+infinity"
+      as their value respectively.  If both "start" and "end" are
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 85]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      present, the value of the "end" attribute MUST be greater than the
+      value of the "start" attribute.
+
+      Time range tests MUST consider every recurrence instance when
+      testing the time range condition - if any one instance matches,
+      then the test returns true.  Testing recurrence instances requires
+      the server to infer an effective value for DTSTART, DTEND,
+      DURATION and DUE properties for an instance based on the
+      recurrence patterns and any overrides.
+
+      A VEVENT component overlaps a given time range if the condition
+      for the corresponding component state specified in the table below
+      is satisfied.  Note that as specified in [RFC2445] the DTSTART
+      property is REQUIRED in the VEVENT component.  The conditions
+      depend on the presence of the DTEND and DURATION properties in the
+      VEVENT component.  Furthermore, the value of the DTEND property
+      MUST be later in time than the value of the DTSTART property.  The
+      duration of a VEVENT component with no DTEND and DURATION
+      properties is 1 day (+P1D) when the DTSTART is a DATE value, and 0
+      seconds when the DTSTART is a DATE-TIME value.
+
+      +---------------------------------------------------------------+
+      | VEVENT has the DTEND property?                                |
+      |   +-----------------------------------------------------------+
+      |   | VEVENT has the DURATION property?                         |
+      |   |   +-------------------------------------------------------+
+      |   |   | DURATION property value is greater than 0 seconds?    |
+      |   |   |   +---------------------------------------------------+
+      |   |   |   | DTSTART property is a DATE-TIME value             |
+      |   |   |   |   +-----------------------------------------------+
+      |   |   |   |   | Condition to evaluate                         |
+      +---+---+---+---+-----------------------------------------------+
+      | Y | N | N | * | (start <  DTEND AND end > DTSTART)            |
+      +---+---+---+---+-----------------------------------------------+
+      | N | Y | Y | * | (start <  DTSTART+DURATION AND end > DTSTART) |
+      |   |   +---+---+-----------------------------------------------+
+      |   |   | N | * | (start <= DTSTART AND end > DTSTART)          |
+      +---+---+---+---+-----------------------------------------------+
+      | N | N | N | Y | (start <= DTSTART AND end > DTSTART)          |
+      +---+---+---+---+-----------------------------------------------+
+      | N | N | N | N | (start <  DTSTART+P1D AND end > DTSTART)      |
+      +---+---+---+---+-----------------------------------------------+
+
+      A VTODO component is said to overlap a given time range if the
+      condition for the corresponding component state specified in the
+      table below is satisfied.  The conditions depend on the presence
+      of the DTSTART, DURATION, DUE, COMPLETED and CREATED properties in
+      the VTODO component.  Note that as specified in [RFC2445] the DUE
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 86]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      value MUST be a DATE-TIME value equal to or after the DTSTART
+      value, if specified.
+
+   +-------------------------------------------------------------------+
+   | VTODO has the DTSTART property?                                   |
+   |   +---------------------------------------------------------------+
+   |   |   VTODO has the DURATION property?                            |
+   |   |   +-----------------------------------------------------------+
+   |   |   | VTODO has the DUE property?                               |
+   |   |   |   +-------------------------------------------------------+
+   |   |   |   | VTODO has the COMPLETED property?                     |
+   |   |   |   |   +---------------------------------------------------+
+   |   |   |   |   | VTODO has the CREATED property?                   |
+   |   |   |   |   |   +-----------------------------------------------+
+   |   |   |   |   |   | Condition to evaluate                         |
+   +---+---+---+---+---+-----------------------------------------------+
+   | Y | Y | N | * | * | (start  <= DTSTART+DURATION)  AND             |
+   |   |   |   |   |   | ((end   >  DTSTART)  OR                       |
+   |   |   |   |   |   |  (end   >= DTSTART+DURATION))                 |
+   +---+---+---+---+---+-----------------------------------------------+
+   | Y | N | Y | * | * | ((start <  DUE)      OR  (start <= DTSTART))  |
+   |   |   |   |   |   | AND                                           |
+   |   |   |   |   |   | ((end   >  DTSTART)  OR  (end   >= DUE))      |
+   +---+---+---+---+---+-----------------------------------------------+
+   | Y | N | N | * | * | (start  <= DTSTART)  AND (end >  DTSTART)     |
+   +---+---+---+---+---+-----------------------------------------------+
+   | N | N | Y | * | * | (start  <  DUE)      AND (end >= DUE)         |
+   +---+---+---+---+---+-----------------------------------------------+
+   | N | N | N | Y | Y | ((start <= CREATED)  OR  (start <= COMPLETED))|
+   |   |   |   |   |   | AND                                           |
+   |   |   |   |   |   | ((end   >= CREATED)  OR  (end   >= COMPLETED))|
+   +---+---+---+---+---+-----------------------------------------------+
+   | N | N | N | Y | N | (start  <= COMPLETED) AND (end  >= COMPLETED) |
+   +---+---+---+---+---+-----------------------------------------------+
+   | N | N | N | N | Y | (end    >  CREATED)                           |
+   +---+---+---+---+---+-----------------------------------------------+
+   | N | N | N | N | N | TRUE                                          |
+   +---+---+---+---+---+-----------------------------------------------+
+
+      A VJOURNAL component overlaps a given time range if the condition
+      for the corresponding component state specified in the table below
+      is satisfied.  The conditions depend on the presence of the
+      DTSTART property in the VJOURNAL component and on whether the
+      DTSTART is a DATE-TIME or DATE value.  The effective "duration" of
+      a VJOURNAL component is 1 day (+P1D) when the DTSTART is a DATE
+      value, and 0 seconds when the DTSTART is a DATE-TIME value.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 87]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      +----------------------------------------------------+
+      | VJOURNAL has the DTSTART property?                 |
+      |   +------------------------------------------------+
+      |   | DTSTART property is a DATE-TIME value          |
+      |   |   +--------------------------------------------+
+      |   |   | Condition to evaluate                      |
+      +---+---+--------------------------------------------+
+      | Y | Y | (start <= DTSTART)     AND (end > DTSTART) |
+      +---+---+--------------------------------------------+
+      | Y | N | (start <  DTSTART+P1D) AND (end > DTSTART) |
+      +---+---+--------------------------------------------+
+      | N | * | FALSE                                      |
+      +---+---+--------------------------------------------+
+
+      A VFREEBUSY component overlaps a given time range if the condition
+      for the corresponding component state specified in the table below
+      is satisfied.  The conditions depend on the presence in the
+      VFREEBUSY component of the DTSTART and DTEND properties and any
+      FREEBUSY properties in the absence of DTSTART and DTEND.  Any
+      DURATION property is ignored as it has a special meaning when used
+      in a VFREEBUSY component.
+
+      When only FREEBUSY properties are used, each period in each
+      FREEBUSY property is compared against the time range, irrespective
+      of the type of free busy information (free, busy, busy-tentative,
+      busy-unavailable) represented by the property.
+
+
+
+      +------------------------------------------------------+
+      | VFREEBUSY has both the DTSTART and DTEND properties? |
+      |   +--------------------------------------------------+
+      |   | VFREEBUSY has the FREEBUSY property?             |
+      |   |   +----------------------------------------------+
+      |   |   | Condition to evaluate                        |
+      +---+---+----------------------------------------------+
+      | Y | * | (start <= DTEND) AND (end > DTSTART)         |
+      +---+---+----------------------------------------------+
+      | N | Y | (start <  freebusy-period-end) AND           |
+      |   |   | (end   >  freebusy-period-start)             |
+      +---+---+----------------------------------------------+
+      | N | N | FALSE                                        |
+      +---+---+----------------------------------------------+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 88]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+      A VALARM component is said to overlap a given time range if the
+      following condition holds:
+
+         (start <= trigger-time) AND (end > trigger-time)
+
+      A VALARM component can be defined such that it triggers
+      repeatedly.  Such a VALARM component is said to overlap a given
+      time range if at least one of its triggers overlaps the time
+      range.
+
+      The calendar properties COMPLETED, CREATED, DTEND, DTSTAMP,
+      DTSTART, DUE and LAST-MODIFIED overlap a given time range if the
+      following condition holds:
+
+          (start <= date-time) AND (end > date-time)
+
+      Note that if DTEND is not present in a VEVENT, but DURATION is,
+      then the test should instead operate on the 'effective' DTEND,
+      i.e.  DTSTART+DURATION.  Similarly, if DUE is not present in a
+      VTODO, but DTSTART and DURATION are, then the test should instead
+      operate on the 'effective' DUE, i.e.  DTSTART+DURATION.
+
+      The semantic of CALDAV:time-range is not defined for any other
+      calendar properties.
+
+   Definition:
+
+         <!ELEMENT time-range EMPTY>
+
+         <!ATTLIST time-range start CDATA #IMPLIED
+                             end   CDATA #IMPLIED>
+         start value: an iCalendar "date with UTC time"
+         end value: an iCalendar "date with UTC time"
+
+9.9.  CALDAV:calendar-multiget XML Element
+
+   Name: calendar-multiget
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: CalDAV REPORT used to retrieve specific calendar object
+      resources.
+
+   Description: See Section 7.8.
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 89]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   Definition:
+
+         <!ELEMENT calendar-multiget ((DAV:allprop |
+                                      DAV:propname |
+                                      DAV:prop)?, DAV:href+)>
+
+9.10.  CALDAV:free-busy-query XML Element
+
+   Name: free-busy-query
+
+   Namespace: urn:ietf:params:xml:ns:caldav
+
+   Purpose: CalDAV REPORT used to generate a VFREEBUSY to determine busy
+      time over a specific time range.
+
+   Description: See Section 7.9.
+
+   Definition:
+
+         <!ELEMENT free-busy-query (time-range)>
+
+
+10.  Internationalization Considerations
+
+   CalDAV allows internationalized strings to be stored and retrieved
+   for the description of calendar collections (see Section 5.2.1).
+
+
+11.  Security Considerations
+
+   HTTP protocol transactions are sent in the clear over the network
+   unless protection from snooping is negotiated.  This can be
+   accomplished by use of TLS as defined in [RFC2818].  In particular,
+   HTTP Basic authentication MUST NOT be used unless TLS is in effect.
+
+   Servers MUST take adequate precautions to ensure malicious clients
+   cannot consume excessive server resources (CPU, memory, disk, etc.)
+   through carefully crafted reports.  For example, a client could
+   upload an event with a recurrence rule that specifies a recurring
+   event occurring every second for the next 100 years which would
+   result in approximately 3 x 10^9 instances!  A REPORT that asks for
+   recurrences to be expanded over that range would likely constitute a
+   denial-of-service attack on the server.
+
+   When creating new resources (including calendar collections), clients
+   MUST ensure that the resource name (the last path segment of the
+   resource URI) assigned to the new resource does not expose any data
+   from within the iCalendar resource itself and information about the
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 90]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   nature of a calendar collection.  This is required to ensure that the
+   presence of a specific iCalendar component or nature of components in
+   a collection cannot be inferred based on the name of a resource.
+
+   Security considerations described in iCalendar [RFC2445] and iTIP
+   [RFC2446] are also applicable to CalDAV.
+
+   Beyond these, CalDAV does not raise any security considerations that
+   are not present in HTTP [RFC2616] and WebDAV [I-D.ietf-webdav-
+   rfc2518bis], [RFC3253], [RFC3744], as discussed in those documents.
+
+
+12.  IANA Consideration
+
+   This document uses one new URN to identify a new XML namespace.  The
+   URN conforms to a registry mechanism described in [RFC3688].
+
+12.1.  Namespace Registration
+
+   Registration request for the CalDAV namespace:
+
+   URI: urn:ietf:params:xml:ns:caldav
+
+   Registrant Contact: See the "Author's Address" section of this
+   document.
+
+   XML: None.  Namespace URIs do not represent an XML specification.
+
+
+13.  Acknowledgements
+
+   The authors would like to thank the following individuals for
+   contributing their ideas and support for writing this specification:
+   Michael Arick, Mario Bonin, Chris Bryant, Scott Carr, Mike Douglass,
+   Helge Hess, Dan Mosedale, Kervin L. Pierre, Julian F. Reschke, Mike
+   Shaver, Simon Vaillancourt, Wilfredo Sanchez and Jim Whitehead,
+   Alexey Melnikov, Jeff McCullough, Brian Moseley, Jari Urpalainen.
+
+   The authors would also like to thank the Calendaring and Scheduling
+   Consortium for advice with this specification, and for organizing
+   interoperability testing events to help refine it.
+
+
+14.  References
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 91]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+14.1.  Normative References
+
+   [I-D.ietf-webdav-rfc2518bis]
+              Dusseault, L., "HTTP Extensions for Distributed Authoring
+              - WebDAV", draft-ietf-webdav-rfc2518bis-14 (work in
+              progress), February 2006.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
+              RFC 2246, January 1999.
+
+   [RFC2445]  Dawson, F. and Stenerson, D., "Internet Calendaring and
+              Scheduling Core Object Specification (iCalendar)",
+              RFC 2445, November 1998.
+
+   [RFC2446]  Silverberg, S., Mansour, S., Dawson, F., and R. Hopson,
+              "iCalendar Transport-Independent Interoperability Protocol
+              (iTIP) Scheduling Events, BusyTime, To-dos and Journal
+              Entries", RFC 2446, November 1998.
+
+   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
+              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
+              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
+
+   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [RFC3253]  Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
+              Whitehead, "Versioning Extensions to WebDAV (Web
+              Distributed Authoring and Versioning)", RFC 3253,
+              March 2002.
+
+   [RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
+              January 2004.
+
+   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+              Distributed Authoring and Versioning (WebDAV) Access
+              Control Protocol", RFC 3744, May 2004.
+
+   [UNICODE4]
+              The Unicode Consortium, "The Unicode Standard, Version
+              4.0", Addison-Wesley, Boston, MA. ISBN 0-321-18578-1,
+              August 2003,
+              <http://www.unicode.org/versions/Unicode4.0.0/>.
+
+   [W3C.REC-xml-20040204]
+              Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 92]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+              and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
+              Edition)", W3C REC REC-xml-20040204, February 2004.
+
+14.2.  Informative References
+
+   [RFC2251]  Wahl, M., Howes, T., and S. Kille, "Lightweight Directory
+              Access Protocol (v3)", RFC 2251, December 1997.
+
+   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",
+              RFC 2426, September 1998.
+
+   [RFC2739]  Small, T., Hennessy, D., and F. Dawson, "Calendar
+              Attributes for vCard and LDAP", RFC 2739, January 2000.
+
+   [RFC4331]  Korver, B. and L. Dusseault, "Quota and Size Properties
+              for Distributed Authoring and Versioning (DAV)
+              Collections", RFC 4331, February 2006.
+
+
+Appendix A.  CalDAV Method Privilege Table (Normative)
+
+   The following table extends the WebDAV Method Privilege Table
+   specified in Appendix B of [RFC3744].
+
+   +------------+------------------------------------------------------+
+   | METHOD     | PRIVILEGES                                           |
+   +------------+------------------------------------------------------+
+   | MKCALENDAR | DAV:bind                                             |
+   | REPORT     | DAV:read or CALDAV:read-free-busy (on all referenced |
+   |            | resources)                                           |
+   +------------+------------------------------------------------------+
+
+
+Appendix B.  Calendar collections used in the examples
+
+   This appendix shows the calendar object resources contained in the
+   calendar collection queried in the examples throughout this document.
+
+   The content of the calendar collection is being shown as it would be
+   returned by a CALDAV:calendar-query REPORT request designed to return
+   all the calendar data in the collection:
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 93]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   >> Request <<
+
+   REPORT /bernard/work/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 1
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:calendar-query xmlns:D="DAV:"
+                    xmlns:C="urn:ietf:params:xml:ns:caldav">
+    <D:prop>
+      <D:getetag/>
+      <C:calendar-data/>
+    </D:prop>
+    <C:filter>
+      <C:comp-filter name="VCALENDAR">
+        <C:allprop/>
+        <C:allcomp/>
+      </C:comp-filter>
+    </C:filter>
+   </C:calendar-query>
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+                 xmlns:C="urn:ietf:params:xml:ns:caldav">
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd1.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd1"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 94]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001102Z
+   DTSTART;TZID=US/Eastern:20060102T100000
+   DURATION:PT1H
+   SUMMARY:Event #1
+   Description:Go Steelers!
+   UID:74855313FA803DA593CD579A@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd2.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd2"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+   TZNAME:EST
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 95]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART;TZID=US/Eastern:20060102T120000
+   DURATION:PT1H
+   RRULE:FREQ=DAILY;COUNT=5
+   SUMMARY:Event #2
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   BEGIN:VEVENT
+   DTSTAMP:20060206T001121Z
+   DTSTART;TZID=US/Eastern:20060104T140000
+   DURATION:PT1H
+   RECURRENCE-ID;TZID=US/Eastern:20060104T120000
+   SUMMARY:Event #2 bis
+   UID:00959BC664CA650E933C892C@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd3.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd3"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTIMEZONE
+   LAST-MODIFIED:20040110T032845Z
+   TZID:US/Eastern
+   BEGIN:DAYLIGHT
+   DTSTART:20000404T020000
+   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+   TZNAME:EDT
+   TZOFFSETFROM:-0500
+   TZOFFSETTO:-0400
+   END:DAYLIGHT
+   BEGIN:STANDARD
+   DTSTART:20001026T020000
+   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 96]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   TZNAME:EST
+   TZOFFSETFROM:-0400
+   TZOFFSETTO:-0500
+   END:STANDARD
+   END:VTIMEZONE
+   BEGIN:VEVENT
+   ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com
+   ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com
+   DTSTAMP:20060206T001220Z
+   DTSTART;TZID=US/Eastern:20060104T100000
+   DURATION:PT1H
+   LAST-MODIFIED:20060206T001330Z
+   ORGANIZER:mailto:cyrus@example.com
+   SEQUENCE:1
+   STATUS:TENTATIVE
+   SUMMARY:Event #3
+   UID:DC6C50A017428C5216A2F1CD@example.com
+   END:VEVENT
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd4.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd4"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTODO
+   DTSTAMP:20060205T235335Z
+   DUE;VALUE=DATE:20060104
+   STATUS:NEEDS-ACTION
+   SUMMARY:Task #1
+   UID:DDDEEB7915FA61233B861457@example.com
+   BEGIN:VALARM
+   ACTION:AUDIO
+   TRIGGER;RELATED=START:-PT10M
+   END:VALARM
+   END:VTODO
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 97]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd5.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd5"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTODO
+   DTSTAMP:20060205T235300Z
+   DUE;VALUE=DATE:20060106
+   LAST-MODIFIED:20060205T235308Z
+   SEQUENCE:1
+   STATUS:NEEDS-ACTION
+   SUMMARY:Task #2
+   UID:E10BA47467C5C69BB74E8720@example.com
+   BEGIN:VALARM
+   ACTION:AUDIO
+   TRIGGER;RELATED=START:-PT10M
+   END:VALARM
+   END:VTODO
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd6.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd6"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTODO
+   COMPLETED:20051223T122322Z
+   DTSTAMP:20060205T235400Z
+   DUE;VALUE=DATE:20051225
+   LAST-MODIFIED:20060205T235308Z
+   SEQUENCE:1
+   STATUS:COMPLETED
+   SUMMARY:Task #3
+   UID:E10BA47467C5C69BB74E8722@example.com
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 98]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   END:VTODO
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd7.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd7"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VTODO
+   DTSTAMP:20060205T235600Z
+   DUE;VALUE=DATE:20060101
+   LAST-MODIFIED:20060205T235308Z
+   SEQUENCE:1
+   STATUS:CANCELLED
+   SUMMARY:Task #4
+   UID:E10BA47467C5C69BB74E8725@example.com
+   END:VTODO
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+     <D:response>
+       <D:href>http://cal.example.com/bernard/work/abcd8.ics</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:getetag>"fffff-abcd8"</D:getetag>
+           <C:calendar-data>BEGIN:VCALENDAR
+   VERSION:2.0
+   PRODID:-//Example Corp.//CalDAV Client//EN
+   BEGIN:VFREEBUSY
+   ORGANIZER;CN="Bernard Desruisseaux":mailto:bernard@example.com
+   UID:76ef34-54a3d2@example.com
+   DTSTAMP:20050530T123421Z
+   DTSTART:20060101T000000Z
+   DTEND:20060108T000000Z
+   FREEBUSY:20050531T230000Z/20050601T010000Z
+   FREEBUSY;FBTYPE=BUSY-TENTATIVE:20060102T100000Z/20060102T120000Z
+
+
+
+Daboo, et al.           Expires October 28, 2006               [Page 99]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   FREEBUSY:20060103T100000Z/20060103T120000Z
+   FREEBUSY:20060104T100000Z/20060104T120000Z
+   FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20060105T100000Z/20060105T120000Z
+   FREEBUSY:20060106T100000Z/20060106T120000Z
+   END:VFREEBUSY
+   END:VCALENDAR
+   </C:calendar-data>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+
+   </D:multistatus>
+
+
+Appendix C.  Changes (to be removed prior to publication as an RFC)
+
+C.1.  Changes in -12
+
+   a.  Changed requirements for ETags on PUT to better reflect the needs
+       of CalDAV clients wrt synchronization and reflect what other
+       standards define or do not define.
+
+   b.  Changed CALDAV:read-free-busy privilege so that it is also
+       defined on regular collections.
+
+C.2.  Changes in -11
+
+   a.  Added statement that calendar-query Depth defaults to zero if
+       header is not present.  Fixed one multiget example's Depth
+       header.
+
+   b.  Fixed reference to WebDAV Quota RFC.
+
+   c.  Changed DAV:resource to DAV:href in CALDAV:no-uid-conflict
+       element.
+
+   d.  Added CALDAV:calendar-collection-location-ok pre-condition for
+       COPY and MOVE.
+
+   e.  Added CALDAV:max-resource-size, CALDAV:min-date-time, CALDAV:max-
+       date-time, CALDAV:max-instances, CALDAV:max-attendees-per-
+       instance properties and preconditions.
+
+   f.  Changed to 2518bis reference.
+
+   g.  Now require 2518bis Class 3 behaviour.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 100]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   h.  Fixed indentation in examples and removed bogus whitespace before
+       </C:calendar-data> tags.
+
+   i.  Fixed </C:calendar-data/> typo.
+
+   j.  Added text to <C:calendar-data> element definition as a reminder
+       about the need to do XML character data encoding on any iCalendar
+       data within that element.
+
+   k.  Major reworking of CALDAV:time-range element description to
+       better cover all possibilities for each type of component based
+       on which properties are present.
+
+   l.  Added is-not-defined and negate-condition options to reports and
+       a new example to illustrate use of those.
+
+   m.  Fixed descriptions of some calendar collection properties.
+
+   n.  Removed section describing preconditions/postconditions as this
+       is incorporated into 2518bis.
+
+   o.  Clarified issue about separate component types in separate
+       resources.
+
+   p.  Reworded section on servers being allowed to reject changes to
+       their own private use iCal values.
+
+   q.  Clarified overridden component 'current' and 'original' time
+       range overlap.
+
+   r.  Added more section references for XML element definitions.
+
+   s.  Reworded limit-recurrence-set definition to try and make it clear
+       that mast component is always returned, but only some overridden
+       one are returned.
+
+   t.  Clarified dependence on UNICODE reference for caseless matching.
+
+C.3.  Changes in -10
+
+   a.  Added new section about support for X- items when storing data.
+
+   b.  Added new precondition to allow servers to reject queries on
+       unsupported X- items, and a new example.
+
+   c.  Added new text about always supporting X- in calendar-data.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 101]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   d.  Created new section for PUT, COPY and MOVE preconditions.
+
+   e.  Report examples re-done with full listing of calendar data in
+       Appendix.
+
+   f.  Removed description of using UID, SUMMARY etc as resource name.
+
+   g.  Indicate that calendar object resource may contain only
+       overridden components.
+
+   h.  Add security consideration about not expose details in resource
+       names.
+
+   i.  Add constraint that free-busy-query can only be run on a
+       collection.
+
+   j.  Add preconditions for calendar-timezone property/elements in
+       MKCALENDAR, PROPPATCH and calendar-query REPORT.
+
+   k.  Fix principal-match example.
+
+C.4.  Changes in -09
+
+   a.   Numerous editorial changes.
+
+   b.   Removed the CALDAV:is-defined XML element.
+
+   c.   Removed section on privilege aggregation.
+
+   d.   Renamed the CALDAV:expand-recurrence-set XML element to CALDAV:
+        expand and clarified the server behavior.
+
+   e.   Renamed the CALDAV:calendar-component-restriction-set XML
+        element to CALDAV:supported-calendar-component-set.
+
+   f.   Renamed the CALDAV:calendar-restrictions XML element to CALDAV:
+        supported-calendar-data.
+
+   g.   Renamed some preconditions as "success conditions" instead of
+        "failure causes".  For instance, the precondition CALDAV:
+        calendar-collection-location-bad has been renamed to CALDAV:
+        calendar-collection-location-ok.
+
+   h.   Reordered some sections.
+
+   i.   Clarified the definition of CALDAV:time-range to specify that a
+        repeating VALARM component is said to intersect a given time
+        range if at least one of its trigger intersect the time range.
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 102]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   j.   Clarified that calendar object resources stored in calendar
+        collections MUST NOT specify the iCalendar METHOD property.
+
+   k.   Clarified that CALDAV:calendar-data XML element is not a WebDAV
+        property even though it is specified in the DAV:prop XML element
+        in both calendaring REPORT requests and responses.
+
+   l.   Clarified CALDAV:limit-recurrence-set with respect to the RANGE
+        parameter on the RECURRENCE-ID property.
+
+   m.   Changed the CALDAV:free-busy-query XML element to contain
+        exactly one CALDAV:time-range XML element.
+
+   n.   Changed many ELEMENT and ATTLIST declarations to comply with DTD
+        syntax.
+
+   o.   Changed XML element CALDAV:calendar-query to allow new XML
+        element CALDAV:timezone.
+
+   p.   Changed the XML elements CALDAV:time-range, CALDAV:expand and
+        CALDAV:limit-recurrence-set to only allow DATE-TIME with UTC
+        time values for the "start" and "end" attributes.
+
+   q.   Changed description of CALDAV:limit-recurrence-set to specify
+        that re-scheduled "overridden" recurrence instances whose
+        original scheduled time used to overlap the time range specified
+        by the "start" and "end" attribute should always be returned in
+        a REPORT response.
+
+   r.   Changed the description of the value of CALDAV:calendar-data XML
+        element to specify that the CR character (US-ASCII decimal 13)
+        MAY be omitted in the iCalendar object specified in this XML
+        element.
+
+   s.   Added specific requirements for entity tags support.
+
+   t.   Added more preconditions.
+
+   u.   Added further guidelines about finding calendars.
+
+   v.   Added XML element CALDAV:limit-freebusy-set to limit the set of
+        FREEBUSY property values returned in VFREEBUSY components.
+
+   w.   Added property CALDAV:calendar-timezone on calendar collections.
+
+   x.   Added XML element CALDAV:timezone to override the CALDAV:
+        calendar-timezone property for a given CALDAV:calendar-query
+        REPORT request.
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 103]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   y.   Added text on the conversion of "floating date" and "floating
+        time" values to date with UTC time values.
+
+   z.   Completed internationalization considerations section.
+
+   aa.  Completed security considerations section.
+
+C.5.  Changes in -08
+
+   a.  Removed statement that said that client SHOULD always request
+       DAV:getetag in calendar REPORTs.
+
+   b.  Removed redefiniton of DAV:response.
+
+   c.  Removed XML elements CALDAV:calendar-data-only.
+
+   d.  Removed resource type CALDAV:calendar-home.
+
+   e.  Moved the CALDAV:calendar-data element in the DAV:prop element in
+       requests, and in the DAV:propstat element in responses.
+
+   f.  Further defined the request body of MKCALENDAR to allow clients
+       to set properties at calendar collection creation time.
+
+   g.  Renamed CALDAV:calendar-home-URL to CALDAV:calendar-home-set
+
+   h.  Clarified the fact that calendar collections may only contain
+       calendar object resources and ordinary collections.
+
+   i.  Clarified that calendar REPORTs should only be applied to
+       calendar object resources contained in calendar collections.
+
+   j.  Changed the CALDAV:calendar-component-restriction-set and CALDAV:
+       calendar-restriction properties to always be protected.
+
+   k.  Changed to use existing postcondition DAV:needs-privileges
+       instead of a new CALDAV:insufficient-privilege postcondition.
+
+   l.  Added example for limit-recurrence-set.
+
+   m.  Added example for expand-recurrence-set.
+
+   n.  Moved CALDAV:calendar-address-set in the calendar-schedule draft
+       and renamed it to CALDAV:calendar-user-address-set.
+
+   o.  Added guidelines on attachments and alarms.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 104]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+C.6.  Changes in -07
+
+   a.  Various editorial changes.
+
+   b.  Added properties calendar-restrictions and calendar-component-
+       restriction-set on calendar collections.
+
+   c.  Added properties calendar-home-URL and calendar-address-set on
+       principal resources.
+
+   d.  Removed property calendar-URL on principal resources.
+
+   e.  Added pre- and postconditions to reports.
+
+   f.  Added new XML elements calendar-data-only and limit-recurrent-
+       set.
+
+   g.  Modified calendar-data XML element to support the attributes
+       content-type and version.
+
+   h.  Reorganised sections 3, 4, 5 & 6 into two sections and re-ordered
+       sub-sections.
+
+   i.  Added comment about client not setting a duplicate displayname.
+
+   j.  Removed three CalDAV OPTIONS requests.
+
+   k.  Changed "authenticated user" to "user" in various places.
+
+   l.  Rewrote section on calendar object resource restrictions for
+       better clarity.
+
+C.7.  Changes in -06
+
+   a.  Reworded section "Recurrence and the Data Model".
+
+   b.  Removed timezone collection feature.
+
+   c.  Removed ability for a server to return the Location header on a
+       successful PUT request.
+
+   d.  Clarified restrictions on calendar object resources contained in
+       calendar collections.
+
+   e.  Added preconditions on PUT in calendar collections.
+
+   f.  Added informative "Guidelines" section, with information on
+       locking and how to find calendar collections.
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 105]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   g.  Moved "Sychronization Operations" section in the "Guidelines"
+       section.
+
+C.8.  Changes in -05
+
+   a.  Removed a lot of non-normative text.
+
+   b.  Removed property promotion/demotion requirements.
+
+   c.  Removed calendar-owner and cal-scale properties.
+
+   d.  Removed 'ical' prefix/text from element names.
+
+   e.  Relaxed WebDAV Class 2 (locking) requirement to a MAY.
+
+   f.  Relaxed MKCALENDAR requirement to a SHOULD.
+
+   g.  Moved the XML Namespace section in the Introduction.
+
+   h.  Added CALDAV: prefix to CalDAV XML elements in the text.
+
+   i.  Added CALDAV:calendar-multiget report.
+
+   j.  Added CALDAV:free-busy-query report.
+
+   k.  Added CALDAV:calendar-description property.
+
+   l.  Changed CALDAV:calendar-query-result element name to CALDAV:
+       calendar-data
+
+   m.  Added description and examples of handling timezones.
+
+   n.  Added mandatory "start" and "end" attributes to the CALDAV:
+       expand-recurrence-set element.
+
+   o.  Added three CalDAV OPTIONS requests.
+
+   p.  Grouped XML Element declarations in a separate section.
+
+C.9.  Changes in -04
+
+   a.  Added a note about the HTTP Location response header.
+
+   b.  Added report calendar-query.
+
+   c.  Removed reports calendar-property-search and calendar-time-range.
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 106]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+   d.  Removed section on CalDAV and timezones.
+
+   e.  Added requirement to return ETag on creation.
+
+   f.  Revised data model to remove sub-collections from calendar
+       collection.
+
+   g.  Added informative references section.
+
+   h.  Removed dependencies on DASL.
+
+C.10.  Changes in -03
+
+   a.  Removed Calendar Containers (simplification that doesn't seem to
+       remove much functionality)
+
+   b.  Added MKCALENDAR to create calendars and all sub-collections
+
+   c.  Added cal-scale property to calendars
+
+C.11.  Changes in -02
+
+   Basically still adding major sections of content:
+
+   a.  Defined new field values to the OPTIONS "DAV:" response header
+
+   b.  Added new resource properties
+
+   c.  Added new principal properties
+
+   d.  Added new SCHEDULE method and related headers
+
+   e.  Added new privileges for scheduling
+
+C.12.  Changes in -01
+
+   a.  Added section on privileges for calendaring, extending WebDAV ACL
+       privilege set
+
+   b.  Defined what to do with unrecognized properties in the bodies of
+       iCalendar events, with respect to property promotion/demotion
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 107]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+Authors' Addresses
+
+   Cyrus Daboo
+
+   Email: cyrus@daboo.name
+
+
+   Bernard Desruisseaux
+   Oracle Corporation
+   600 Blvd. de Maisonneuve West
+   Suite 1900
+   Montreal, QC  H3A 3J2
+   CA
+
+   Email: bernard.desruisseaux@oracle.com
+   URI:   http://www.oracle.com/
+
+
+   Lisa Dusseault
+   Open Source Application Foundation
+   2064 Edgewood Dr.
+   Palo Alto, CA  94303
+   US
+
+   Email: lisa@osafoundation.org
+   URI:   http://www.osafoundation.org/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 108]
+
+Internet-Draft                   CalDAV                       April 2006
+
+
+Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+Disclaimer of Validity
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+Copyright Statement
+
+   Copyright (C) The Internet Society (2006).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+
+Acknowledgment
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+Daboo, et al.           Expires October 28, 2006              [Page 109]
+
+
+

+

+
+
\ No newline at end of file diff --git a/docs/dusseault2005CalDAV.pdf b/docs/dusseault2005CalDAV.pdf new file mode 100644 index 0000000000000000000000000000000000000000..87ba07c372d2cad77117850ba6bba57957fd2814 GIT binary patch literal 313171 zcmcG$1zc6jzdkGyN{2Lvq#%f!y*DW(-Q5Vt1~%OdN=t(Z2-2W{fP_j(C?N`h0wN_! zhaxR0p}w;=a?UaCJ@%-C-|GnjLHyD$68U>Qq>zZful4x( z1^Iu?6GHr+C(I{|{I#AiKi_Zt3X2H*mM4Nl{`RiO?_+`UA^CqDADmBE;MeiN;etZH zsRrYW}Fu7maL+~Mle_e9~ zA3yTfF(cq2$lvM-2=f2BHxMF%zwHC0fDrQ6F@stBCM&SyzwIleFyC)7Knnlfo&a1x z=$Em;1q6f;zsiLVgT7z(A6(?0viEdH**T)!0gj1bIsn1UK)%E4pswsiF=0MSVL=2^gdc7th!RGk_|X<<1V0*uUlXZRZB1Eb+Ch=?0?V?975Y+zc3wUenDYoKvaSt8*mxKYA|^_M^Cgn zxI3ae(Xwbu7b`F{RkX8>r!5fWLHAIL9-i)KloK(5Vzh<1xw*Bu`A&CpTQhTB7xS~= zBhnY(-gwk_*QiPOn#Q++gY#xiFsp1HvBA2ImnXEci=CW8>i*tk*}NG)^&R50>{;!} z6TKzFZ)@@|=`MvPv{H~V!NOx~Zkf~tP-zH>&nDLtEn2TXZWMue&KB}Jvs@>{oAl>? zd6SVXMdnUd-l;Awm zkh*_QFPCYtXPifa=?l)t>Q|wR*WTfqxxM3Mka-JJA6in}*{L16eEI3P0ae6xl6E;& z{ttC$(w{Xqb8&IyJN9B>5fPm`XD*M8op*zR*0UK)@y+w+yu7@`X)E+t1IP~C0Gywu6n`++#~euxeB9?6GucO~OCiHMI~rAR%gEl%6bw>VwbYW_NP(s!-d zCqkTw0FQ`{=yaUCn1I}^lW!@%n7NLlMB2#OSL0FlWmH3*!*1Yi(|xcc$|6c67CZKq zF_rkOK~yQqxGgASlJTY4v107b6SWkof_yf`?~rFvrUSVJ55|Mn!wQd2<8O&Y>=0oQ zoh8{P)znsJ#a8*Q%iM*pE-y(}dx6sMZfXcRi5FXV7O`m{kg+p@Hg9}8CDwz*rQg+|kYu z#t$*1jrMTya<|0b>JTq7F3z5y7QhPf5LddkUQQOwB8SYNhPJXpNxS%h4?on9fUp3w zkO%_v?U!+Pas6|Nwu>jg4ygVU^bk<5e?eZ;-NjM|?Frh20aXNm5bf*93{!FfqnG({ zSHg5755~w0loFUc91IhJuQo^{K>7gQFnJ_MLxOLlBT*h8h<3Xv>36l$<~>fY)Rgn}RM5f94H}Sw4pjG` zRqz1n3LFRXf!H}gqETPpE6ag{@yy>clwzIK4e1>X5rMw6@KQvuOl#K^7LJ$ELf|N6; zE$M@G;}t@JO5lSB2cLAX=KOyNTpi^ESWiJwO-4q82P~(ZhYs4wP6y@e!3$*I4t9j2 z6=+Kd5VoDAl(UT^X0>5Do@gh1&>Hj=G5j$meoU`WiQ%mJnfvxCXPykKaUBTO0Q1T%oyo;esh;Ab=>-5;y@ljtCcLZZ6} zjm_B#?F;l*m@L}c&Jr!7W~9Q50DA^5_yZB9e~TPisXvGuw4&o>;faA2v=Gp=(=>+NsTu?)BNHr!Fgd;FrL)~N2;8V#D zG%G={%OLFs0kknB7}nui!a$V=>KNt{0CkC>2k2$!0csX{5qcH@>L?~3AWwh~%m?gt zXui-LGiT5{5|9e907zh72KpxE4ths|UZAu9co`@WmZ0Bsl42141?SE-+WLyPb>G4=7u@xca$6!~}qB0f1}=KyC{lZ3XiKz;^+#b_KxK0f3i+ zDZ(tg939b~FcV@`m=DYbu!5(pI~onM245|hhn?>)@IN5WpO@($x*hS4uOVg^{3kFL zgiP1JVGQj~2qR!yA8dCaW?^7?Vz9%Sp1-*?KA}EL65&~UgAP&JF8UhCUP$57c zRN;^dgn>SdK^mw8l>z$)Gj8aPK`8`dh)5vpLoFR(8{7eTAi)f1%XRWTJ+$)OK+~IsX@I@<#;z#vyj!9j=TRGwSw1>8+#BHe8vH&XLnkM19LSyC!1h zo8i(?wv30DoBAb_@uc_%T;1_{uLb>(%J)f?EB8ej^f)C{)`JDMswIZAuSiUmT5QD% z#}3Dgd0NzOU^{eO?$JP+ko)dFy4e>&HaRdPL)KYMw~Zi+)oVzgR($4%^u zuU*_rcbF>wRn=qPoyGRP%i@W#OzvE%n6jIH?nh>y?-_i{s`h+0qK7movwQm~|4XCc z%uG{(Oz~SscBUUqd>r1LS;V!;EPKRREFp>3nvsK-lb)z?J{xwWZK8Ag%6L0(K_J6K zMQew`$N9CjH>S9OGbT@rE;R;u)CuOC8*2>Q?%SR3+Fs^nm9J|Z<@=0i?^)AJ-`QaC z`jU1k=PO6<>%~iFSHGsF1#6MHjjTJ@7V}h}VDMgV-pw*^pFU?*dCI@{p@WhBogh~O zr4(zk<;N01L7%brI7NfDzs)B{e=484>5+NMZF^`_h5c0OOu&9O8A)9miXeOcDo5Z% zxEo(y3xN_1iDsTyj$!awe&V5kUgwzZSvvJ$t{TCW4VpTgn?AcEF9rIO^Uj`)4}is4 zM9_1-e%IM}F8Pbo)ri+{joNO@D;iwBHy^TJ6T3hsKusIZ@-TJB_UQht=~Fh}o9$q3 z-#M?u42QVoJh46%v^i`&hzd%4yBXKTWnp)`?0E={6+SoFbkz*Q-TPEb>8u}5d$p}U zBMeQw_Q5RWs>T9i$46Z~Q*);4=bJ`!pDZ$~j_>f`M4e^(h#q)A+Hj9XRLfDl-Q{^< z>$u7+aRK)zRgYGnh9jP7kn{C*ts~kOsUMK(9U1sA|WXvbK%Ysp?5EF zlTp+|kz;sr?9!HB7(Qy6;)H1NiYtdYw2aY_ea2xWl8L``;wloinx|om%5-4N{@z`Z zLa}{zr8CLbNp{msZ#~GpeV2z+uPJXYr-8+|UBoAk@kJ2R`@QH6Y?W;p7%?{6Hsz$$ zk$^$>A!RjH`w`DGW?Z6G>SSvQ-f_A`ZV6Ol1vrVR0fM@l5fdFLRE}(&7Hm-?VX=7> z3iXYBqrKN>Q|su7dEP|G&8u;pKp172sZxpf=+u9=saY8bF2DKYEV`_6KunIVCyKKo zjvZnCs=AIXLmB_Me@8@3%50Y4>XSve_XcuhlX?udT}3`mUeHkR)gyFxgxb2p<9v_a zpM^hd8jHv9dKM2&fwzA=p7c=vRm&DX{-@-oI-B+>^}O|-pWa@UA;-gS@u-tn56iGq z6pHH{A65~RQQDcP(C+NEr7m3%d}?q{K^@6Q_U(8ZsUu-gULrk<|6^|bn{0K;pVk#E z^vZ zl8PP`Rw45r1cw&i8y*U^8}Vc+{t&sjdvY(!Q-EWI;?8B>V~R0n+|z=YM-6l<%F3(y zn|zYUQmg`;4Ai8!9b;=K-&G=P*6#L%bD~!G(Og|@RKh1WRx%F7!zUwdr$UJQ{A<$ z(RDH+b;YTnNxav%WYtPf)EFb7C0fd*!2rNE#}V8XiL_* zsp?rVC1J-h2GR%GN$7q;VQA8K61wk2dUEWZt>z z==^;6{q6e&k3~69=k_NRz35XVcC}yg3!_Qh&8r_5yt&O8Gi*z9(kWG;JgnU`H-L82 zp17$tZ%%Vhz4?uv3&T9q*ZTB_Rzl}wyq%wpFb7baJ9|4pRI1tZoM^+H%YjFXYRUhdR~Yk(x*xjna3tYvA#WS^oO6I>mZ^p)Y1Z&@H#~`f8FFr>iw|K%JanYN|M2 z)b7lJ-p$herxb7bZiqb>Eru8S#m&_!&!kBqHYnvQtN3TJz1~;dIa?u~J(BJ749nIBzvG2SRV>lVaI7Fobol7PJLxOo|Atf+&cU% z6)g#wq(6nIg2r|Co9Th7cOt{=3bW+W1~?z)8Hg8|1yvu4 zi%37Uhj+W#W%e%zrsaLya?g2PreD-hxD_bb9hWvW;v^TF%#nWOl`&p#i5i`w#@SQnAS^O?ceskI)suV^`01}_A^_op_ym}`0Gn7M7=cG+pc zRE4{EA1aqiJ6eLDo#4N!mF-0~a1tlCEZu=b)8$CA(6jZKyYnW7A`f**T?Xen9^|m~ zU;Q+{n>yxV6hsD%1&Xk@UrUpzak%~abv;9^69(2IaD zxPbC51Q|2Jz)k`e0yrk2i=Q8u5uh9{a!?<02Vo)s$S(!`{M!Y+09}|)ppL)=bqeQ$ z149J!Hb@8nOGXg#(10{Q@cw|{CveDtE`jk5T>`*lg7Ssoz-nl8 z_zrqm5SaYXT?7P0Ab$%#@ahSG5Flg*LE$av&JXNTXuePy7-Nt#1{h$#8;eN;%MOal z@`DDTXGj>(1$6-3g}`Vq^+4}XkOzqzNB`33vqC(keD`ESoJaQlN!|7*`L9Lx*2e!;Z)_=K26fH(42UlW*!+TRm_ z9KIl0V1;(}06x|K%IO5T)&Jpj0 zKndiUgy;bH>4bp$LI{Wt0y?yp5BKxIem%e}1W5>8(5?l(T;PiNmkaX(X97cRgnpd5%^gaJMwj6xSQG6=`QU{u0jJ%k}#L*8UeLg;{} zpi07sgUV2hAJYnkOF<9(5S>7*0PdKf9P*9;AT5ZPAR@xt!F-TlD3Cy)=fB1e@}V?z zJ^@ot1maMzVWA(00x?7dP=_f5%m>X4BOH+a8EyaO+tpP0d5?lk_6ua-$RE+JpLWSl zv8aCuvH-u>&rpM&|Ardy82<~@gnmE`60`^igZ&0InLkY9&u(2faA5rtVNgio0AWyE z@E-t^18}m#cv;=_F9C~lP0N`W+AQfSL zCd4pn;2Cy?DFMJ*V8Eyjz-R+}#k#;(tPS%9{$hEU7VzRq{|rvB%$RW7KgEt=y+0@g ze{`h(&&3X$l?Tgy7}r7ouj3)Rfxs5uA4L9Vn*OKId7%?e2N5k{D7N!gKnr*)4}}g6 zcl=Z6KeL(+;4ClT;D+4Wkn;%?9AIM%4gv2~R1nyuZAxFC^SWj!yvToL95*2#oe4u&bT zvH;F?YtO$P4k}|@{1^xOLBj?h6!62%ukiC~LZ@Az;OS4Rc^GcP92xr?M38j;=V7y- z{OuTp126|ah*DrePY^kPT>}vv0?-kpg<;e`z(7zr#4<=gav0`;NaTO2;vG^I)X3ol zH7o+yk{H8tki#3a2K9{5@W6f+06Yd!>!G5Fp)nUA;N@M74(MD@W36zg-{;gaAM4-22_HG5_%C*&@iek^a%nij0qP2#S9uD zl!iV6m{Egg%m|<#B;>^ZaY2PpqY%gcM-2PlY5~7d?H@kKU?6`vzW*7O`9EU*x8NBR zsQ-a^5PuMX!+)n)St<3uz7}AU{uAsFj(=bs+K_+3y713fmj>9j!)Pte0KEsq>H;v1 z26(py@O6hE3lM*Ra9e=&16{@yfZ76}|1Yd70WvUv`2)23!dy|{)CLBqnA8DE(N0!S zuuT!L0EB6Iz_k$iF}U^s5l}}oAQTON^&b&5ZO|t~_y^qZg8&Yi`T=fxOswv2^eaGA z@;6VI5dX#$m`ERp!oh&02Mq=j1^k5~ejFkBi6Z`s$mxGV5r47*A=m@7Vzd*m!34qD z2!c=+Wb7b;S_55>=>?U8qkouZ=#J6G0LBiY(hxBJn+x*-cnQ>H$L>7?Oa<0qPdg(?F9DzM(ELqyh2|CxFQZ6M-~G%!C08L3fN4Fa!Z9 zu%N}m#vtwRFb#N!|OjW1b;FD|2Kvp#t4MwiV3u0^im+z z1KELJp!xr83mz=;&+Pdx;X+_U{X{vx5+;TmfBmffKL}$Zz~=g==LE!qF{e?W04wyZ zLH-D1gWxMBa{I%kJ`8hXBDtV0bccerP_Pzr5Cap^g?7h(as71~1?uF-^^emipgYVt z6;J|2&=1df9DabIw-3YGP~cb?bd4#44xK#xanBUIf#HMgr}m|GVb|6Nv|{0+C>Tp;n;{eDL?MALxGA??E1BdLWk= zdi>`Fy?9XN=SB|e{M_(gQ@{l7f!v{>J!k;zlwX?xA%jLx!YNTef%40 z{`95!M|}NX)rF;B6f{+36w?zkZheL}FY@(k{3&;TDg+v1m=|CIrPin@mv!c@2lIsXJm^Os zn3WiP!|*R#MgeB@=Pydi!Qs%K z?HDNU7pqheJQO3vWKDj$}rf#a^u(7E=%UN=HJI=cA$qXB70AgF(|Ad9v}c{zIio%55v z1@-ekoC;=>yQ6_Xoh`u-0Z9SxBIYP3#>b%J>f$Ny}u;c+3R}ore0wB$UA%sQvqhi(@jrCZ!E^aKpzrYhh!XHu=o9Pg-Hp7s%LRE}nPC zlf|Es(p|k^O=f82+AKv}g6C5y#qG?`QVN%4$LrU|;pYk^4>fpN-&RTvC!l+%Y!NqP zyyw3aZ~Z-DaquqpfX$QdC&xv%p!_As5=iJQBooCndx`=Vl)&}r+HMF~g0RZMq}5bsT=SXII@IsJw( zMKn>;D^w>h0-e4%SY7vQ(78G_W+{z&pQ!1HfY{6qTY z#(a{38$-pK{32YZV(6u`j>^Sb7BS-r49CXwYIbnjC!`yzYfa`;-i)y**5nTNkGytg zJb#7zDdqDRW4T99%Vv^$JCi%PXE_E82b2fU)kR}P-!w<_0$X08u2p6)Iyj0itVIp_ z+Gz{SrkA8k_3-yR$@Y0{?dP<)+xC9wa`g7;l@nuMeXq0GB!@MU<|W&>3Vzo?uQao@ zjt^y;-AG7!#CmxpB0`eZr@+O~S z2gOr)y8*|?lIQM2Yb}&t>m;(5{fY1QL}*u7Z;Oh1=d~-a?GbZje8eODJYBAsM@4Kyu&hA>UeL#`&=SI}_gx)Zt_0hYs zOl-F=`Mza!F4nSSDyft86l1hZy3;2{Ats;{ukIo&~3{HFfY>G>LTJxK_8vKpv;s-Bs>9^C- zecR#3YmbG!j#HvN7D$UbaQ*vdx4nQjx2-~Xo`<9~s%vIF8{I^8;!%?{EBfN6NE5V> zw))62s!ar2Gf$OV=vOt4VG>r5Z*+F9C#nWpUxnAEt z*BRY2ujS2eR)}&xuC<(yd{I%>hbh|b^cso9YpKEWis?JD>&#!IOz{K4&XQ1|4eCY+ zkb{%V{kQ#I%rO&9N%0{W1qX#qK2YomYF+h-q(tNTNl}j{Ki6xuz(tDhZPHzivo)8} z*+O>}>oD1LU)kt#!ZtWZlV52?>!jH|UEF_0G*N<8QJ|Il#T~1gRNDErOim9};zQiI zI$kwjd8HGi%ygsB`$WRaxRA5QI9emznKWj_#u%nt75JQ$V>G94vMkia%}i&PMBuZ( zIre?X@{IoS`p_yiX@W4GS*x-;?F**VXgJ@sDo@UvGDpaG+1hsR2(nW6ZN$&9=?$LW zYo_tFVYiPrL7uTaNv_UOu)@aP@yu!5wW-TW%A94NfGdzO?ihVx6nkh&(~A+&DMeHJ z$}Vb~4qaN3>^Iv@=Fd9}4F*4dey%tm`^fi#>w->&Unnsj)mL+tkSiIgrbpW>5LcN= z^J3z2v$39vt@4J!bGJMiIK)ZM+eo7N#o}5X+8&Q)6}@CVL{}Gkb(?IGn1P8ZRbgs# z|JJsq=;iy@Ud=pnV9n=ixiL9+-DP!7d~n2Tbd`PW7(bmBGrn-zGTXwfyX9ORWUU>m z$qCDM$$fb9jkTU-dA==}W?(ZL6;)_1#;WYqdFJlxc~mc=G;=Dy=;pg7Tsk+343Al9 z3156GJ}PlOgY??PM*vPv1Lgt#NUO;?E zWjT((X@qdsQrN@9>-6miT9q-jnQd9T^HE_AL^N6-RNWQpkJYpB;ct-Tj&luQx6;fy z^91Q|@m_Ayzv{U4xzu_iN@*lD%R*LT%X48?=41H%t=aOxi_bXDG`$ZdkeR26Z4&RR zFD!nUYHD=x-D&=ul5aD$MUvsqg?5PLa4!;sZ(jTARmQm`LKKjN=VsV6*gDv&n)zFlaah6Dk)PH~C zKWWjPp8I;h4j*@+WPVMKL;$UEyVLEZg3z< z>RGoh?1+4g(AUiu_*$3J#h=AtvD;3b->bR8g7Px>{v_p^Lk`oZu`!#w5?XzA$!{^A zVG?bKn|Je#b80h8!>~?7FSVj*Y3m~E29nP~hRb8u>x*x*VpIZH&BBDfEStv1 zf4o|LdSTy`eU!(l^0BXCV8Ixgqy8e!2A=SX@5Yk8H=guASm_@l^?p2H#V$=;a%!Zm zrT*pVTx);E-Pq?I*sy6r?JqR9PF0vtI(r}eicB7s`l`yYU)Xi;x?M@kl+NIGgr~rC zZ}H0H4t$B^h7~)B?x# zZoX7@cU3Ci`&fmqtoqF|HQPjy$+tw|bW}{Pb?$XW*Q$4naeK;UjFI*a^-keu+=(>P zFS=G>|5jN#REq!Z7cl(E=1DR zywO8=;0q0xK~C@m)z#iPYxB6pW!Hg*REOoGB9RiU-d|@l_da%wzH+^|#Y7@7k&NZ8 zC9!E@VjnnS=FJK#Sn@i3DX2oVM+-YbTgFXl5^qI|Afq~c-^C*G5nqOiuBa{3@H{n9 z;*e>Vm-^k8SIakWl_guD&(VEQf zHn?M+ZLay!UhS5dF}U&KP87G@jdN!t{4O2)@-@K8eE-l?wCJFk{P)NACuW zs(h8RkM=+EY0OuD>hl}Fr!#YBmMkWQFME)^(o$L7P+3=e{M}rsTgvVi<_wN+tnK4@?BBExFBQ0!%U*Op$j*a^1WBwm+io(Vcbsfk z0GDPxjUDZ8ix)W%O8G&g2uXs^|H&vf;7fchz7RL^-nb1Jd0x~9O)km-_Sf=XqvNdf zM$uF}Y%k9R8Te*keV%y{K=M?pcbKKV?8&`yuTovnZsi-@k15eJ9ml@)3A2mCOrG|t z-=HGr!aYfSGV8)IMfR^o0pm;c<_s3a-Ewd8#f{yrDhXB9i)c2hYtLEYhh7`1*v5hl z6CupPLXVFm@4eVae8nh`uexl_?1=U$r$`IV0&U?MZv+}31Lz1+awUTXPf>m4iQ;$ng(+Q5MKMp?2 z5~{(6Wvo$dn|Q-fiu?YHo>gDlESkA+@}9gkGA^1MEG?CE8f#eOS5Ht>dWp2f#FV+- ziwL%hwdq$*F@UxA=PL7?~|IL;HUfaKHsYCC@-~ZSUI0mGctx=91kU6TO#>{sP1l@^Y z8k)?W?!ee2hPk*NrZhA`G02ftKtTWU?Z8wdhUv*@|MaY=3+%@qrZ7zRr?P*Vc+mf+ z@IN&11O)!g#M9NY)1@?^F27T6R$0K}NsxxuU>qOA6~jQmA{|zNf83Vu8m$$Mv92u+ z<#U#)XHQ78YvbP2o)Di5mOm+FLJlVu>=eX~ni_obE?rhjKGdV+$tyRexS$XHqScRm zn)a5zE^j+OjC*wrWuzY!6&D?qjg-*J$w?EE6zA~>wD%sH2<7stNQ_inbNAMG9&c8$ z@6+e2=pK@FDra+dE`q_by<(W*>4wOH2h!{1y1>}WHoMb7TWLA+8F# zDyF8pg$QuICLtssDeiPfKF_pTIZ4$#@C8pO#*+dx(UKpX7D(+haC8YV$ zNycr@dhI)Z!>3apyb+XmYb{|dc}-_4Gaxgd?CZs2$zk_fy(4o@inLp`J6*e;#jhTl zMIuU@ZH9ZYJ*K2UVZga8#l|4psG1rr>6pQ6;-^}#9K3&$pPQ_=kw0ITSYbx_ z({4)Tr%OepGy0A+=NGkn*dsgGYS@xOm$@mM&o!XK=zCtskW%V9)mce~GafI^K6c9G z;Vm4awvc@H%K7es*jtTyms;M3Ry0*SK<{`C#QE7>a?;`9zcJi4C@pS4n0B=P5lURk zJn8nWvZY!3(X6zwv4@_l3{S@J7kyl#_DG&w^*$QCf+G>f72}YmG}6uFCR>(V?{*y9`1X&RHigs$*gq$A zaEdufT_ZMO9=nH~!5Wi0(G&SnD)71it?HX%`a#=pIqLFmQ+GIuO2hy+1I6^LxLKme znNt151wlC{4#|^FEA@WoI07?IskgBc8T9c@Mv)5+)an_9m6kne=VhUub;(We#<%hL zT2?cvvvViUaqRJz5jpblsLn@5gq=!#AGovbbMpy^Ak0Urxi={jb+zHRZGNGBPZpT> zvt1>&at&Dx8ikt*Hy0VGT;H9qk}33c+SqClV}64(@Z>D5s0d%Zk2L#((^eet;E81{ z;+!Lqv!WB@()jw8i_Fok1$d48^`riuzXiy^*R!L~Su+pcSq!oLRDL8Q?yVvL`4`cd z_JG2d_x;l~x=7OM5bhO4i`UJ(b}EEJ*q6&UB73tZzC0!u3y$@Txpt?5)9jITpS;_P zAc4{%H;1YVDPDql>Dr0ZDjd>Xi8gZ)_$9AT*-X8ap~Y3Q=a$)-wq8AoHtd@#R!K6T zi57hkfSn%_X?$iN8Ky=J$Bvg)@zNm_XuL>HPhTs>YN)H+R}tuN!fs7FGTJGHQJ8tT z2cJ^uO+tCbBt({Zy<%( zebv^9t1DdC#wh4DY9#A}xX+)JeWb~dpEpT@_n?CQ+)%BaacJ2M;5^iTKM@z(_2ypfnE+3CfxUYh3@ysA! z@{0juNIgd_W8~zBHPE=u>3r(dv41WdhOfMUDoj`s^cY=UeRK8LZA!s`>C5q=f=NP~kBxMGN@J4Y+5ezw zSo9@vpN$SDuKlKOX1E7m9wBFoHg`DZwsOh2m>8z?x;mzLg1K*+g0!J@bA;(#HLFKT zTM!|o>ZqMpurzU)GQ{VuRMN8mBtpt zl`s_e-Un+@Zz8_Du-7d91m5V_X`xbvqKlk2%i^hSkv%8iE~k;NS;KOyc7G#$G3vp^ zQ+3}7H8xhSOLeb&oXOyMCbYhX4A7M#)Gn0k7V(oU%sw~nKQkB+nO()eM?A54cDnEe zeeZoN$ukRjY311~woU^yS@}(5#>zBogx{=5_U+)N&Evv+fmmNi;SLOD&0|6`$!SUI zZ=Z$-WAT1Q<_71vR$*QJXs^V;M|S!Yx;gCu-XMedhn0;?eHF`lECs<%OIL~e7mgG3 zljJ8F;blrOG&&4nr{Xud-A~AQc$T$6QB8%8{j&SfksL|!2$H0>`&((kw^ys>%2K7p z)x_G(5Z@oQ-wTPJB6!O5@d>e{*~OGm{gmZ-d^rZK3okEiZb;+Uh3Vox*QO$hN~DJA zVwLpv-P6-hv27i;Rl_PdIu*_&&9ZO%oKkf)^mSQGGmA1i_2Z(qMo8H`ebuBcm95z> zA(yc$>s`&AmyMq{g^QYx1@P%yfS(+@{N|$IJpF^fOpZ~u?ZNF_8h?5kORjD^1-z+w z?pP;pJvic|a;`tkcpKJ>eQy3d@lNR_cPr<2hEO++^;^_YjGUnm|w zJMN@O<`5Ge9{!U_=IuqB*W!N0G4)0sYuMOfjeh6llTs2%8P0SJuU+x{6FOu5SSI50{S5tkZDY?BA!*vIS+O&&KH@&UO|!1qWC0uY@8S51 z%|fiCs5rYYl0x}%pWCmlcvhhnQdeIpIrP#gU9$RQICO`W@QRDthj8Aj23JTq2=AV# zK?R;(Bb4m&sfl@wdP;t}m#KHJsKTN&VK9R!#c(u6Bjm0+UEfpI#z-+8{`2>C-{Hr< zgGE^kK2M6m*QnO;<;t#?ML0Z-{C1UF;yha~ERSe_lILYr^R#`p(!}f7o%#Zt9efy( z_G3>i9DVgGWqm7mPmHRl(LC;dy8R%tV%sff+|oxi$kkQVb9M1sYCDB^#mm5Tiqcxo z(Q*;H?+r|g-kYoENNPV$H)9K}i%?08@#&bh6E~}T!CfrK+h67DYG`+*&Egb)dfK3# zO?uNN6TQ;?l!ygcJ-?g7OS7ph<~lZ1-_l*`u2(PnAH_5B^;`$ z*C%jTTl!fGu&)V)w2IDLAkqkzzamAKl-q&h$*y{GOjcYPSkuRyz@VJ3-%{A0v4*lM1$tRI%F1S5ddwo(cQd!AL-qA+`iJ}6 zuY~6LBNqFkc|v0-N1lg9R%YOx^r9L6jx;*DgUszL=*rsiT!`5P57qgi5y~)lk9q&>f(}j5z~u1oyl;Cz(s?tNHw=WX zUPqh)c70!Ejw(;7_q@NcPS1Y`hs%=B>PP5;-ed#Su^r@#w%=^bJB&2W>pJ|7_ zCVQq#PA*3Qr%bp&?ks#nT2(PRSr+bg)mK%ygSH}^QWpQti96&mcS4H|??wBwet3>M zrT>{L#$xs8>^Jhs{H({g1aI*eyl(!W}hWz@qWZ|wiZnO-Y|G^)XziPUJWoh?_p<`KW==#!j> z>p1O;MZ9Fq>e9!zu96999zVje_4(#3nKUxgS`vrQ%eo?Pk(A)*XmfOg>up{48xcjH zweeN+S^`vgKHquLw!l8iZ_L)ORK*{Y{nl@q*uwU1x5dTx#44p^&R$QBoQpal@(PE} z0ZlmJAha(cvoW0+$WQt(Vd06$jlM$CWrq4<`{J%k&tXXwg9Dd)Ka9S(SiBT?+4hBh zL1TLB5}liszR8t{9o>bj-uW6C#w7G7@(+d`)?#OvW^U$IclgZGZ{-)0(Geoet;eHV z%1aay!&X^{pIv@3hn``mKH`^)!z>fh)NA5Z8rI4}D!2U<$-tgwdhwwi^M^%qpXTjU z57k(!IZu(%)y59`d(ue3bFv{~??Y~uDH8Q9sR_|L@X--m4PR>^4Pm4$x?ttIVOFhQ zxn~4xXRO$0&h8#(j6xXVsndRDsN?W?SDIL?tG?)8vcGY0Gl`;JsHsrx6% zWYzMW{VLud+H63RY4$3)l{vAONdH6HXCm2h!5e2B4NuQZo^P<#T~sxXe&JRexTfE6 z^?SY#oFov=of1qM@99c#2UUr4#%?Ckf_?TWPtu^JF*4fe%zIrce(WK}qDQSvwdWOg zI($+@-@|c7+>WG-eWwvtd1r=yKhWo)yXpBze^=Cn^Cn-y3WL-QjmZtvb6`jkoT8Nc zh)>F2+|y46Mp(V+;4|}VHhMtwT_~=9wmAH4%vW#e(sJJ5j~CeJO&I-a?4&c4B*n)` z5F{q~-_W~nOW)cVnumQlK@h8!>;IxsBM6HeH$eLC{%dd3EoDb91mDo@gfzHJnBjJXqie-u|> zuX-`OMlZyNia0uXT57Mr#7Q<`3TDH(pu(IH*qjzJZxpKaZTm>@r|HXo`r`cKK;VB% z>`3Sg?7tkexT5E$t2;y&BU3WwA{iidy=7gZI@XU40lPlz-Pufx8|FJ;JkoLVZirH{1;mj;!7gE=+) zt90^eQW5#b*nz1gy>Iuf=vB|x@tbxgD-Upc<(`*!(hIuVsDYOt>mIkS7}-nZ$?)~f ztk5~Ta|7oj>$*Kh2UdK(#(h=Z8(nB0NgU-K&EC2+)|CG}z$a+?=r+%?IFqHgzOSM9 zJ%O(R_~{6|}UjM6u|h^qlgI91lyl zSl(X73t@WFg=7l{3Tm=vEkhypMACl`>HxZVJhu7}Ra* z=c_B`%tVdHVkd7dQxv|fs*FErM>E{ZNnusN*{MXpsv7$&wIl7e(wX|JXcb;A2kcMa ze32^UmUwtE**D<@XU`|)XBhPgU#l?43XF=rH&W{08&i(FjTfk#6@oTCJ$ED9d+@Moo+k@W-Cf*3bTU+~wBi%TMXn)acKI{H zXX>`ZCd`5Tkq!$5Hj~__tBuzUcI3kkSlsKPs)yP~A5UrcDy>`c2fB2l)GD_w$d&aZ2Gh~a{ zZ)Us7wir^n9_*9tbxgFE zWos+=T2F(B;HBB=s~nf(jdkg~{Q@2q+O+SHe)ptKF7T;N{97|uOKrSp%Hd!#Rdxw`i%*fR7BhRv5nXNc)c;7NF zgeW^Qht~qzA;mE)bJNu7RO1;}%f~HzXL)%W&C>>hK2VX7E|fpCMI>}r_Dr(1?SE18 zRUvGY^f{7qDSf%s`eLfwjVfL^@?Pr@z7=xMoI8m~fIVpweCjMD|r&8}rd z^pPEj9s0yiL+HYpp4LbgN3HRtK&3p4vfK`lJhZzRexhzUtU^W9zS_JIzwz-qCXe%N zoaJLT67N(}Cly3>(g{o5+vaED84}DiV~S#`yn8!C-IB{Oq=EP1+3cX@M3<1IVhd%} z(Ff9d-D@wit~V}(OL1@vF6GS4^c`#DSSuTC%QW>fCQ^vOb|dny!3$~M(bQ!)hqUdsD82nc6G= z{GjndX8XviD$d*9yDz_W%#7A;J8n0O?{q(^^B*fSN-x$vr8vomeNN1OaObG6nGCy} zElTO-%F>5x`d?@cZCeV_$5qcO}@-$c2pW{))+b zV&yDf+Vc22_L6{y_qEt;s+|fqctZk#14b#?U0Tl+It9!@Yvm^;iy&gJ3Fr>4A% z{pcVZcG|m(N#bVB)V=VRK^^03eJ1Ca%`;qbahWL6NnfkQ>Eu@n-117;O&=`r{#kZr_5@RSFiDHGfv&-thkeOa*=*(Zo_R@V`d3uZyUTAXVus)S(riX0q22o!Q!V*fTqto%M6 zBa?67Ox+v>3@4}icjIjI?Tle2>GBsFA*JT4www8oWj}tWSz1?~O1p@Tbs?Vfzd~8) zN?a~sUJgCP#hN`E(qa4xC8E>FYV6;0J=1y+C=4D*K9%JAd8OFSy2RID!XX028)Eu3 zH8+nZwcF^lV>_y?-GN))@&=OibRTu6-lz#x=LDWNI#K-qr$>#8PPv~}SN$GCML8nQ z6LNLFV&6o=#qnDo3O)V0Rm-o@TDOe0M4@3Fap8&k0=eJDpy*zCIV2Buo%+)S+Jh1> zmfdaT(OpDZ`IsR;mU|@$(srRdy`^0Z%hMf0Bqh0dtYLK*Do~;I1t{V>Zd%1zkvOo} zfPDDPIH6cJeZ9o2@=#KN2ZP%v*!O@N<)vqyePB_MVk3P;Tn+Mg5eEaSUoJ@OeYD~mtbwUXykA3L)Q)w z3L1a4Ou(ziUMJq-ob=0wU&Eknt0gd?y&-ti(0nmvr2`?!9K_ zTz4KUdjv-|;^5bYac?2R_rRut-Ig+Ywd{9o2a62@jtmi^$xfHh0#GGkQoU)4S*Y>> zd&EF{VFPXV=TqP+!SdyViKn=jK%bOi2j}(gW~U|loir#uiQ~13?s$sNN|Db@@d-)UT%_zcZQMRhxv-KO+hS#R+(0s@R&n=YDu6Rq7{oa37}(2Ko30g$pRgZ`^o=syu` z{_9yN#}_Z^-^@a-RlMbq%`mr2>f15!%^4$^XN&>02na=c?PBO^^8ya~;p6OxF$f_N zQlktPW}U2mavm*byP+a>Ds}WN)ca&YxZ^xb*TyJO<~DW;=?Dlb&1FBVJa12QDik~U zI=h;>ZMo%a-MwdTU5#R;D?ZCJ%f#yZNJ!3Xu^!92jfkk&ePF%H7Fe8dtP#xK#tW*q zf4U=@>Q}D;75vqLg*;R#uf)szd(o_ol4ECDQH>L(3UEY%f|)|(CSlF8@tB3N>{0A-Lo1xEIU)P+wf0QNXgT+e^kSx z=H@b^kkJ2#$rBuwSF#urR+^zsx(74)St=P(mPgJd!a;E=6rm}O@)IMX@KB!hl%0j2 zr!erCd{s6lU(Cz&<^0j&;hTYATIDz@XmyyPF@+|ocLXA97)veMBObM*hBoxl#M{lB z2NvHp)}_|vo7xt-k>N16iYP^7lCR<;CEjb{E6cOa9sIT2lihVU^0jDBnI8?{1t4F! zuu4LivJ1sD-84cf$});OrCL%s(g93~oqgGwK;m+-#1gaHuWtc-3vS2zg}fIpu*Fhi zZ0w5_R!z;9^H-Wm-Bkm-<*xt}F-N3izZc|S#zSdw80G@d-t9V--E4Bj|on;2OFjpx;nJ*!1r%Jfl7~6JP<98uDjv~;&T6>LxS0p^F zqC-fu8-RXf9-heI1Y4}2rj20H$0?1Twh6R4#9i7mWlLo9??jgD4+V2p44fFROEJKp zqyppdo&CN$T7sQ=&TLs(aNx`gjL0#d#OO^Kv1;=++B*ddl#H>7+uuO)o+BY^OUn?L z9_STKg}BoP92W*tymkZQ-ZlYMVjpP>?P7OuWvwkA@*|ZM(QFWxC!G0hoGjTf8|#Zm z7KxM%4&5NR3`Js}ZjLC*d>)VAuN4-r)agGT$&P-{pBN+)CoopF|IH?ViQ4;52#&qVH$PEWQL@?_SazPZU#;^dvOXO zv4_wITU~fYC{N0#FIxa~sTOKc^$uL>@~hnA;?-R5z#UO8K|Nz=3CDiHo49pfIZT~G zA5}r?x>~EJjw7W(oDgq1yR#t{XKr+sDCH=aiC}vKiW4!8Db8g zZ(-Br_(|ro1ihN!mkt7z87Blm9g5EHBmGfWz*Byj#0Eit9){dg8+>hqW(v9%34q@W z56wWq*#nNgnR19q-wb>DruER*HdhuDZQV{Upzy5r(X|CYy9@y4Bm?b6!)l z4+z3Tc#O}%I*ilGTK5T-KVIGT9cR_F>tb3Md#zT?A)4=hV@HbUDb)5Q=St~q z+>4a{+^v7ow6i!EMa-||rUiDul@9156W)8-#LVI39^H42+lV?RrHH~ti(ai!Z>mMa zcJ2^2g?FTsn<<8S0RoBd{uOd0#_a3qv#+vWr$A*orpg-84|AI?s|$II0m$NzUfmm6 z8>@>Coz#9wc@H-&21antOCNLjciy4k&a(eVTd4#5F&?>>cfzJTZ{|VnO##o1e06{EhPtX%5VibxY-KtT(zVz7*K_Rg%i8s;bnUHoKlW z+@`pe#@ETEAa@f=E5iq5E6oxz2y<<=&`Fg9RFJW9w0$VeU$ zCQD*<_EvaBC7qA5D4Er%=a0~x{T1jV3PpI-{<|S!z7ZC;|NZjz0)|)bmZpA$mHJkF z*I=^0si~H_+W%Yo$028IPjg3u0!ORnI%3nJyp5iew7Z-d1lPWrGJ}V^TuOU;9?Nm? zRZ{Np@#wGW{Y!;cdYA7gcXhr`ztb*1N{d$Smu0c_^6vBo!^5_sQZ~!ZmW2>H!3mj%C5bQkA-qfwsH|?wIpn9kA+_D8i>K<#=0;h zQp;A4H^-yQFX?w!ObmBYMO)ihX|$d?R|n%q`_7=o+)lFh+_tsCM&YpBbUtez8Ue-= zXE<7Co12Zc?d}0e3@(R4sx|X`!HS7u+5LbU3zWByWs?6O+!_o+s5h$C6<8mkeR@al z(?I%?uEEI~D;6&l4LxNWKiU@C2pTGCBP%&(ESAyf@|F0j7S{cl%q{R~YMj1HbZcd6 z@A^!IYWNQ3Vag~G9I4$M4BZ#WmE!8{zWoVUqXIj~glJdv{tjVGs(0`^anl{WsB43= z_x!+miOP#(Nkph4l+VFZGXwFyjtX@~coMQJ>>}Uyj+UbvI|kj{fyUMe@H^tpkB)1W zt{AEWDdzNjP%=N5JE+mX0|=l-kOX0Pzg)3HTxC~Skv z;7=?-?MmNZ?9P2AFKgxHPZ6Zf=!9(uNs^v;;VU6Z|MOr3E7V15k%$lMlp-%x%%U&= z>|oq}u4pU*b+2UV;$m|rI=E1(+?s*30!=K+yS22Y5I1@u)jRi}ZAGK%4ntM-B&)+v z;y4fN+rJ*#h4TC1>vbT19{7(FEW`(bb6|&R_Mm?DKvD6?HuIIM447dLm3#s=BL$v0 z&F%4R2hjEdd80}EhH>5%r5St$qsUYv;xNRk8gdJ|>j$qv%2egyr*kyx*ni*7mZA0h zt+Vk2H@*0&ti+#kR~*i)8Ve@uFoa% zp%15Od%M-iq2P3>I9m^3m=eLUjTY?tGvCo?6557Tp#ZaTD?D|@W!t!7vQ@sncdDr* zn=`q9BW=X`5%1$L$LNA6^IXcSn0vNyqn94W2qpx5I(QGo+xI>3<0G$4+2-3CgY3M> zFj^UdyMtDLi!{s>k>p|q17LJp3}ifBcK=E&wATKRyvinlsZdWZ4z?!9jDsEJE^J#zE_Q|nH6Lr9}oW~+#M5h z7Yzc}I+P&o3eH@Zg@nusVuWeUo27W$xihdTN@3Xd85VC=7EZuYSU?ogDe7Y(CnPI< zvJ}F`BUBRX_(6zg;`@G-_9Uo5(7Xv$Xi;^Cgd&o#$!`f^!lK-}7_}rplc9(Q#JFU( z{>W`4KD^Kdu~9+etH{q)oHVGL$lpSUXOIenWpjz+XdnUAMM3a^0iV|(*K6nP$pF@{ z0f7DMwag{YFGD#{+N()x@yC0^4-n|$uQ9(zi3}0n#Qm5s*2oC3VYe2^k z|G^-K0AwXVCh^TM7=k^ty8rCS998F@jR45a0a^ows>XRa?3`jH*1f}7IA#%Xj`^s$C3NGV9G8&88S;XFFpDAljCF{bQXAMZZRQ zy((D4)A3h;zH&KW`3Qa!V%4lqQIwpGG>EmDI>ufKk`Fn{d}7(*v0=6Sfe}O3zewvi z;H?zp>I&s#cM5zaH-8gn{3z5*UCRz-oa!IsMxw@>d@@z|Y&34JF`hzu(SF`j67ziY z^Y-}|j)6l1|KO0S$|v&ObcnbA4k##o4rfbgHRQ%=F3i%;8sT3I{LJ$h@o*px0opu8yJ6Ig7-(*vXyAvrM^G z1X>Q-tSU*h{4=8F1zWNWoDH=$c=G!Q-N72iygJR7wU%iInmy5BaE3`~(z(&H74LI4 z=^p8+AR+;R2#NSw?xX7< zBIhEk={5jv4B<{hr*O^>n~FITwZ@pz!D%btk??BQZ_R3|*7C(>Bqo z#&?aqr98Yr^>k{@tV+KhoG#}X>dru)cpIZ@=eFTz1wwnf`>R5j^u(e2|Lm!h-d&oV zpPx0f9vh*@WMWK@qR|`#^Rhybpi)*)^@=>pC$L2^iEqdoCv938IUJsTP7O$BgzK9O zV0-SbK;4cuz-R*MbU=H}5wU}q%Oiua-!=r)vj-xBe$9jC%qX0I%oz0m;-JfIoF_}z{v#Wpw$+uQo zPU*m{1DR+-%6UJR_uh&LQ{2r72a5m?J->}P8_1|k{5)uV&|M^V$+h??HvxMVA;OM+ z$G~BlrfLWr&H6k)#D5qz$U8N;suxC**?6eF)QtH!ngsV7h&XUe&3r}g-f_{#Xsr>6 zt}*3ltn}o>lZxpX<;Bc}r_dWyzOSV|7c<5xx@6()_`Bs0w^kwWuFKZ^)(xafyi_bsEFCKR zJdX_38F^ye6Z|(Ua{03C*&2lolKL*g{R4K5MRC5;u7-Lw;CFQaflk<_twT(i-jVGl0XT*o?hyj5+6$&Z4X3sZ(_SjpML^j={N(sc*DN*Qk!J#u5_FMY*P8 zahOpcBvWvmbcgmSv3eaod*)ukEflQm&KCz%++4R5*+-YGPcWMth&V0yI_M2O(>%|b zD-8?`BTCgt$7Q=s>a+y{(+qj_bH(b$3J2}FigbP z>iHtO$;w)|#6Dc{wA~DahiJRZy)B({NtdTT`OC%QD!>MN=<$I?PsxAUF=J{|27~LSC8TH3ru&GJgLw^JG0qH}}bJ6reRB#%*9!++gf7b?eU&e8jw@>=*5UV3w^`0AjbV}R^SbP-A*qxG~Z;#4eBIAk?3q*yOI!HPXJ z#)ivCnJc!Ie@AErdgQcU4~X%JLya5sU^9Q5rfItuQrd-4)hn$W2xQvt7?xy;Js#{< ztd9?d|E4S7dw2>AyGRz=)(DTU!J0@LmAH_S))miPB?w1!ody40Z5`K|M@_4oMTO+i zAHYtE3ETM?JkcK2wiiWukWm|qKoM^h1h9vj%Q4lr5$wmh99<9h{C9GuHFIINEcl#e zUM^0>#7wO%g3-G@IA~(c!8Fq%7_VtFW?Uou5O2jILtlSF=&XdsC-I3*U{82UIsbAP z*SU+45m&qQ`YPqDln#yzHlb({-1w!{lKF+Rgc?zco=>xkFV?QqDDT==JKB*A z=<-7mF)+-7f6BNgfr~hpI*b&w(@ZE*UF1#`yKQz8i{Ah1M)=ZQP>)G295N6idQSUtu&c7G!sB2syql73RF z-g@gid+I!@G4Pe88@3dszset_+17-%nU0Y>Xf2tTG;U)F^#?s+$YNY~oC<9Y~Pup#k z8c1i5Ji~F#Kh2tiTpdmlZ8f zmWm{I>Ws82=+Ey7cA^6j$_ax9n2%o^wWEA*WV>XXNrnIwnu+;gW+5a%WOGg>KrwaQ_V02PU7xp`ukM$My(fRcBJx=?k3^hRb(hd_|h-HqH-jDahosTRW&r#`jMVWAU6i+5;u3U3f?(3qs;(?h&-NR(o!b+YuC_aDIqqy z(3CFh(X3#UYZ&BB2X4Q8V5+dXL`mjabUQ?Mn%p8@55?nrPJ+y`kb3nkh*x_DCiz0_ zGEyemL8f$GC5=}Q7?CjOjImG~&yMj_#7Ai->o7d$Zs5zxEmJHtO^@Qn2a zx(w=ih5!6rRb^C+I{PcH$ll6gcC3F^EiGgk4oup>7Ao#~Gw@qtqyu-T7|MNy#*z}= zx_JSvzy_*CV+>z^6=fj{EwpD4L0yZtqMOpDRc8`7#=(N1v_d_JutA8fdPK{2sRJ*;fKlGfzw;7Jtr`klEiRVbSrJB#I-J4 z4WBy;9p^-S=iRDpKn~pB0 z%?fm{f$h`{SMzW*L_WTw?U^;267*DUCfKGvRs#gmlV6Nvjw6cnv4C>-*p4J1c0xtb zw2ciJAyb2MC~4MGl$uo|pzHbivdU!ViX=nCmwPvfI}_|`+5&?qB!@@8VsJ*UFbpbU z(#403I?|R)LrM)p^nDO`2jxDwP%C@Wk6{(0=w|fkl9fuCsqtuwN3cke5vkyz?_}>0 zsSKcsWaKZRcoEVude>l`UPClR_q{C|$ZkjPt#61ZYw1f%_!kw^7KEcnDN?g55V-v5 z`{RBNj!Wr7(tb-1!L3RCosL6Z3(&~_b|pzS#gUnnHPxR38993_jT&S^Wn|L+NNh{M zqeDqg)lF^(f9QZ~oXB8dBc!Hb^!YO!=u(YdMg_djNLf;a*)IHxOVbt2)z(d~r>dE` zAdc{ZGWD0q%$cQoYRHXwAmn^VZqIa*<7_?=5BwmfJ3Kb=_B|I*pDWlQKkb5wRyBtd zcB~RTS#S`&O9vxu1esJKdKbLz56wh-Vlh>X)D_8dW%AT2%0ev~xuH32sAjB4FCIr& zAs5)9*f-+X_{0FuK(Y(u6wd&>^a*Fv{br{ltm!Nt60k$>1n$6fguM1o(6%q#qQFlV z)_M`tqy9<)q6lf7rZZt}Vqx=M2`eAjqif*tQ#0@7!MtvK6X=A!y~MqPUWZnY5du^E zcT8Ew1~_LZstDR8H20V@8pJ$+f_a#ANB^w#V$3X_ zVGTG>P6F40ZyO!YE;$p?s@tV)O)yBRvI5fThbymPC2K+Htm_{j+0b7XIy#UHOGN~+)LtPV!8rU4A}Q) zWg~Z_T;W41ffBT-=G@%V!&@$UzC@X75Y9TyaQBP=S*N{ZA6DOs(KRZ#(ON1Czrv^5GI?{zf- zIJJF~!SvHZ6*0EmaU5HA|Ic;a8hDo>R8%)}gNJClhPa<9u&Ft1r=GqZT+dr_ons$s z{@z}2uA50aet3Y^`n1;i0%Ib0>X0q@Pfntq5_%wxax5s054A5v!g_Ii_} zN8J2`GG{cDQtTX^b%V>=@oS*!K3mH$DaYwhrb72Z^J$g)gl*YXu~-Z5Jmb@D_h+bwQB;xEDf%MPg0^(WjB5#BB{ z7!S73j4ekamtuHEh@LP3eR#tbKc1LTe*aG!X}KlKxjC#xIN7FjV!d~d`NJ%OjG*p0 zlsy@bY$ILrXq`b(R_~iON-4AP>HAZ;c$_&3KC9?`tzfMRLkOvh<8_ zYqUlNKU@8n;h{q14F^VUny+{t)XPEw3OJ)^0-p7ECw4P7`z$~>xDNs#PLSW39r19H zkD0;VKRE20+@{1|3Z903#8QL%c-@VQp+Xw$rLa)U)+N2@uGJkM@CDn9nb6#C3>+@$ zuD&Z;@|NB!6LJzYHf7=}F+%2x8r>$sA-|rEwAhbWr8wa|P2_H=fAZ}Q9W z`o7i4N&l7QLe(lRMD~c0IJL0QYVdtHSfZT4n?ZT7{$AU*%!^#G{fp7vnt$QrgoO&j| zn#$9|`_`B|Hp+e+yYrZRD~Pwrdm}%)HqE{^K8Be8rd_j)`pG5N=i;7A{$2cHZcu}z z>_CcXJ{@>qvRil(o+ma6>bJLUN9Bf!@Lr?6B=YQ|BOG**yCwB=AVleL=)PotvXTY`=D`AiG!{kV2cRj^{J@E7S7;@VZ1asDmd(K zo78~S@i596E|N+TKJotExOfB1%nBlc4mL@O2#+lFK(efi=+uIeLQ&n)F!cS#$LRZo zaY2b8NDk~l$iJ}0BV;knXY_zZEO33x5}#ib?vLKAy`J6%WY`hY-ChhU8M}$wg{P|e zJ&6PE1NBP8zq5V>ze9lgQ`Ty@m)BL*)#XRE$S^W`lf1#QoV|zA*`?xF69bFoEuWTx z8Nu)GDu;=sP@3iXh@%{Lqa-h>D$lDf*V?UpKg7`(_PD(0xvMX&E``-g96I;BUE zf7B$vh+qfP;@0Es^AQtb*coeDML0o6Ocdd)Q$cUFNTda2EhLSluXcutV~7&nxwW(I z(6jlO8R0Pk=AL0O4^=c$I-0Exd_vrEL-ZT$I$(n;AT33d?`%adJ-}A#47mP?w>WaM zl=1jdMQkZ#M}Fh~W@1TORjs{~ zd%Y^w;%LP(L60ez_2&wc%t}cOY1IL`UwvS^kv2j>iKCyY+OD>=d{~&BUv8&c)zsGa zLY#O#5SDp?1ZFsgUZ_G z>_Q>D=;y_Jf^NR^ll-d%{D0E${Vx~r8R@@7$N$X&zVrWDz&Aa%6=`B=kg>;X*K*|t z#LFE3{{h2y&!)E1M;`Ahj)$x}?;~ajc1{FhiHIFUDn3}96Rhln>@Hf` zId-dXULFSNoV1b&W=rG?HewO{q|um&_IfHPF>s%?J1u-r-z*4p-nJv&s_9^R{81uU zgVzdeA;~&gvF!M5nm0PleYUx-*KR%Zv7h0u?v)+1OR4!2^kcsmk?%vOI|*pTGT60} zh34iC8eR4BJ5;UaF{Pi&abm28iHb1}*jI98WP7{7Z1OUV!ldR+2foc3dna`07AL8l zGCgp#YG`tt3r(YV7j>A5ET4ZSA_?q353dnDzR#i z9-b>cL62%4A3Lv?M0WR+)UYIlr!XlKs@fJ}3jhbLKLHEU<7I}zgUg>LbAA|6>;ivO zcssFeh&9C1@KaL-mSgSJPD%hY@UlElzJLt48uGaY$USQqPcX!#%-O>DZqh;_jlCc%z#-LB5;K@-NJT2*7JCtA8tFR4e+;jFQ zn+3RS(}OiY_Gbo{GlORv6{u@rDvPq&$xub3?#F#IPamih-36X%&XO^qITEhgk2Wfs zNll>;KBMEst?0CWk@oP%J<_xCfV9S&1}=a-bHkQaptv(Y%4rl)iz5#j&N=(62T2_X z1I~dN0dj=8=1*U_5D$v8^NeA=7dL0q*HLb0W=^pRd#D)x z#|SimXn5fUNQEcoCnTv`9$QNuWD7HrG!!UV6_4b9~jpxvPl zA4IW=YQDwU3fn0=@y77=7la?%zx4Q4mKS{(T^?>PN*&gk*dD{#^;g5F>}<;09HuNK zC1qC;KT0o!>&@|0BKpBOv;mgK4))h3Z`Fj>u#NXhH+oC=lWPcO z>puw5X0`WZDij`Pst8JO`#|1$oKs5`9SKsv@m|EZdC3c)_?_aO1p_lCFJ7?XM40DX z79U$mWQHEm<>YkE+q6-6(B*(oYyyn!@0lo&hqjlo2GM`D6``Blxa*0Yajv;FK~;DA z1{%mh|Bf|VZ_?HY7+`VMhgs)Yr@-|xvQe>!p7tR9ZlEu!9MvoTeTcla_IWAyYr|KL zPY&_ZboRCmCOeh1x4dpGS+(ST_ENubgr|CTDcvO6;_xSA?FrK46-Urd3K%Raz@%=8 zwEJ-rgf}w>nFy$L4Haalqf!dd%Pkc3v^U2|F zH|*8a3=|fow;4MmlhiC~5dWmj{|}LpfA|=DsYCwb>))0J|7Rb7 zzbyg&tq;K8W(NP?GMQhTfiG>#f2WiA<&yCq;w%5K7x>Fj=3kDJ{!+61Plo}N5hbH! zKmfm)rH}E-#YM};L;CqLo0TS;wg365+M214baKjU`!vkt^t}P^zM&c_{f*3*CtG>- z98&#^# zJ_pG3h9V0#PDy5uJ#5dcugV+H&%Vz_g);zn{*;0GWI*?*-@G-xdcaoa`WjV%!%O7E z)nriqwU;+wVmT<9m&iMCNn9`1MVH8iW>LR!Nn9s5NquKQDaG^thlzRw32tYfA$6Z% zY<3609m7;5*_6xK!I3_zY3qX{69e$v#`js~=49rDLK2x?;}lg_BvQiwDJmx1J^IB$ zk{E}EffNK>F)1xd7M z_8-EK8uLaZ3b6txh!XRC5Cr7mmH<8y^4@v5?mPZivMBU z_`#n*FaSFqX_Eh<&9VNoSnB_DLsXYDv@|ht{-;5@gw2=Z2R_~3-m-r?UD1h~{N>yD zWfsKvwHrs!!r4jQ#8Jr3#{SEE#MT-AZz~u(Ydc4!zkFZt8UFUlQpEp9?lUm5vVL7A zYGM85|M>N3ZQyJoY+__*Z1TVPYn;!z<-j`w0O()vBvp+Zv{b;E1@*gRayd+nBv%TF zatxa!c8WEPL{yx2sx8KQGtMoj(B)rUspWjMyIpfv?@*{#K*Wmhd`S|{CnCy;aR2T$ zBg~F=r*-Gu4c;EyF5EuYPWtS?>_F?lMWNGukKUfh6%I$T17%=fu=_mA$~7KMD3nb4 z&PJ}&=4@?!?kSMQXtKMzJC;nNRi)kf{QUeBczf_mtwjE(;b24(rAnE0>n*qfBqXFt znR2OSqh+Jz0unNExmvYuzG!qhi`8P8%2|KOYU9~_sZz7;MnOTr_lMJkYQ1iOK(Nu# zQ9O~aUzn|zYZUTDOG`_mv5E@|3yX`{EN1ujN{VDMSgn%d<7YZN?#9Q*(P%UqtXIlZ z$`>oOe32Hu&i(}mR!d#pZ*VxA&gaXuO2x8STy7uCWl|}$I_<6(iFmptF^k5}r= zs&zZRKVAOTP*zn{&EfTaeY{xvief78?`5vFa7K7-j$UVp%9p_ z_`Y#EFW0QEuU7}`^ovDda5&DF%;XP8edBUnZ@Jm)h9i|uWp|h@7)>mePUCc0Z8(`T z8&BnMTC7;9KN?Tta@*{9x$D-b(eLdGhDN8+>~R08Ua1rst*-YqR4Ub~cUtvE%ZJmi zYO2y{zI=N)W3zrHSZ;BcE1Jk?wq9v_82)-fyRBNIqsg!5x!SBZyV~@Ad%WVa-`?&O z3WdYtb=*ImF&d7+<8#>EAN_j%9A2lx;;?$NsVpwvkG|kY^t;#}9<&*4uU{KaPf|BaB);e59Cud!eczVDgAIYkJz+q%Or&Y#1dI{1?Zf11G`DENbfe~|DG z68=HL|0g8uj$s4nD3RR!S45G2a*(F`zaok-aeR?H{y`M^>-)dsiO>m~xLO#Q2+3$j z{U=w1o{58v;XlbD!a~abf-3U4{CNogCtz%6XaZpD_t)_7a}6K}00sgA0ullS5)uXx z8VVW_6&?l#9u)%_85J2B104zFt01AHV`1ZBW1$lhlaUbp6jy* z00jat1~3K$kPrX}5fB&=5QGrma{!PJ000ma@bB_hv|j}n01yZS6bu{!5(*mde?JKb z00jJxlL!ESAb`L?AV8qtU=X0dFic-35rIJnkQhJ(6bz6F9sC)=P~v~q3K9{cD)t&O zF*^p#2!WF%C|&Q|7&)<^<<$j}3MVQXi}d9?v!c(c?3&!x2ldan?A?iy{U``-NE(>m zzb|YYTsU}8HFXV1E@~QDJbYvmQ!{f5O(||3UOIY01ONj1iWcPWn83k6S^f@zfB^~Q zD*^{XWKc%`c$B{)=vAD#W+FD+aSTWhQbILyV!j~(`zru&QkK5iuORZ#jYU*golSQC zBZU8R1Z4ji!sjXg9LV4IL<9i<-~%}M*zyy%a-?#~q1A^2Y0YoZz+s;K*J?q+g6?^=BBqxuN1J*i-!|%zX00M}U#dZp?kWI%&St zZvb<)*m<;-qt;laq$&7=DE$|p-2-4X>f7TMaY2uLVb{(>g+yqx-iqwbv* zYfE$RqjA!Ur7M5sr5fZKtgcYqNPBTDZg@$_+YfhdFhA@$Nv~u{WCdgD)d*+vC!y?? zw^?(do&c=}yf`D4V*US^Ti`dPhfRJ#cR+&g8I+Tw>C=ml(i+ zKBGZgT2R%Ii(#i&ZZ)Tq_K@6NrM+$ROrP)Z&wgXikYZiucf=fTxagLL`XShyp}qj^ zIfQBam$T=JGbehg`q_5Erqtw?_IPfB&2uNMerv061b{`en6Zmg_O$OhF~j^^*lx#i zLEPRWW+;pqz-4Q-br4xD&)F&*hGXurxx=a`MOrF7c7^;l}?Nv1EkNY!*R*k_LQf^iijVVvR8r1r$C+s z?$5c-J8oBcqNbXNdJ*x`PpkD%i4&xN4rhN|w6L>GzQS{YBkW-g`>S`#mBLc|T&ts= z#d_&%xZ~+S>sD#&@YR_#-G;PLNpK+^$8iVFA<3F+6WZcP19o|Q^J5|?j(J7*kwJrJ zyBzZw!UR(_6+4ccf60!~{>haDNZ@!M`5-x;AVImD+H%hkMQc^L@v1cCdUB2Vu39LY zXAM(ZwR-Gl`~i7;eNy?HtU4t#w7nFMpQQmX`dkhSRix!$Vq@Gc2+o}!n3Bw>PlOq5 zvph8X*jO0IhFw-j?}p3J)deL%oW$+7#L|N!jxW|Jc;qJcR5%Y1sz$^pI%cEvw?-%q=+)2rY z@>1`_opvbnv?n?=U5SNzcvnX1s;nC$vK9vMjNjy zU$v;#w=Tf4xyGHFdu+1R6U<>e=I56m3MoI1G{4DQk~AT)hF)@M;tb_V-e!l-+nn(5 zuNd)I+w^EjEZJvo!Xf{B!L!iKn5nb>9wRbUkg}IEtHy+Yd)QiK8(am)jk^Ahw>SG7 z+dy)$cjz$5KRnMTs@wSxyYCY#bbUU3nCB!e7WHeDue*<7pPTO$dDg^5oA+mk19kgx zXByB^0`}~YP#Q^YySZ;0acWvfc_(EBCufKc{aEpId5OXDnRREBRj}!m!h{1gT=cN& zY0G0AOni&g&%0;Ze9X%vTQm7ll-YB-1|!~FDw@g)u7lX(EG>dJcg}{s^`Y_pc5nBm zy5YHt8kU~qq3nI`kMhvD8=a&KBdfwTblgimkxKJ~U9V(5t+Onm+?mr0i;+6(qL3D7 zoHeJcQX>wmF6|0!S^xR(k3yWqi)7zr2p#CZjJsymSU&**4YGMN+T;6X54&iR8L^A0 zAnvdazPCtVIEd;|*GUyWx$$t)Ok7JiyrmXm$8)gn!`QmY!NVh*7@ojsmGD@eRns)% ztgvdC*bw>5KE1KQ4i>)oXjeR$7<%X5(|R*A4xKxVIHiNraS=+N5?yJf9Noh}b0*0R zR1UVXvPP^=OggEbVNPS?z+y{9rKV=DEPErJ$CS=(3a(#Q>DXBfqaw|>KTzG>_PNb( z(&fR9f#g-U(M`1p8=IkNllTx-{{VA{&NyWQI2t1Fg!JM8)#USKmH~$Zxnu3(j}&fP zKp5%8KkFaWK9h>ddVsR*$GXxs*=t6@W7}EwJ5OU;Cup90S5<%2->bQJExO!6 zeRhVqgCN^r1>{4v*!c&~LlfdvcjjYbxwcW93<6 z1$O#=hx2=h<8H7u{8s({09ih+ZmZPlIL#%&)rVTvl6+g-^B*;W&W+LS>UVVfyjH&h z5wA4Wc{Wv4iU@`Wdt=?n<3Xa>%=)qQc${%=D0ywap)YlhEGOJeWY`N2uxiu_awxgB z3~R;avi7)$bR8rZ9Q+jWGw`u&*^zT<-vyxPOql$5QDz-9IJt}rbHjt&2?jKdNk_X6 z8uAUTlHMI8AG{RcbDVW>88$b?zz2s`jQJe=#%zS+#gcfAJd%z{PKgnyfI8`8)Zuk* zp@G#t$zDEnS#8J4`&GW1>wdt-v)k%bBfF29&oup4{kr_luhr?u`(fO6Sjy@wVJ+Kc z_m}&FdkFm5j&wSg)$X0s_I;BTnBQoz)!khM%xj0}_U^7;G~9J;MDiBKchrBYnH0H| z;N#a}05-?h>JS0?GUo#Yx@dIeO}A9`hcNDGh=6;iFJNoAhV!8+xT>mZwnNws=`C}K zh$nC)=zoecWzClY9C;FSDq+P`YV^9*68MylG;$2Qq;g}!mIvIFqZk1w@kT>_E2e!* z>mNeN=^2&cbqsr~eHOB&*7m%Y7CHcEnLbLV)vmA6x^F?J3o9<1XVz}pRn`VL)@`uX z=yBk-J{&9@jQ;?uJvirdyowu*mx?YmzPl_e8=73#0xfZ$QN$4*W;IRI^8Th%^?s{5 zlYY^WZ>cY9UiWNeudb&SyFdVF0!FdI#p}ICr_{=8H?faqO-8`u1VPl99v{J98TiHC zsl0j*{%z5rCu>1zj~~5J`omTzs~+dDIp;2xkV)oe$C&P|*NKYjfGzgaT-G!_(hU2L zGIxIkof&fjo6Z5pwk{Ajg>UnHH?FM=I5FnVIfD!ad2(^aVkV`;W^Vrgcd_1_FRvGL zJg&I=S#~vn_v7ukwi^Mhtz%vs);Py5CB$kX70!=O)$BgJ;_TW6E1CsamRi<==A3&S z=jE6lO({MhiLY+aH;)w>fJvt6A8F^ z6=XWBras12cepfZFxk`+H05Y?->RQgt;TJQ>GTcS!waKMKRoIOD?96NMCq6~IQC#s z=$BeqW7y|T#@6R|cQVH7%xH&yP{hYAZML?zKURmxBu=_~m3*G5)BOjuUc&dW+Z(K% z!0pq|vbAO<4|d`RbO!DYa3l#ZcDPR{SK`%G7QVgV;jVEz->Cyn&P<=)cx6W)4IRX; zzSW%1Da^|+9HD~vs-wljWE($^RGo9FeOi7+w^g5uRz>s%`nFuryn2n%o816I930{0 z%tFICodz=ny+;Q`0Neya2r+TYZuvd1y|8*2@u zkR1J?&#-M9jO*>6GO{y1sdOQ3YunT4W;<}4;s_*%G#Bf&z_jprIz&dO7`a&3&3i4e zwL5trIKbNT?L28QphtgJ>D7R2$YA#top>N_gW>Hns;`fWMoWEL8@n?tCkix36TelWnuLv;$!s(+RJ@Mw)c93 zI1?=bOI*T#ImQnQsjKS74sX@^I)+FTWnYnXSr-GmwUgombhL)dC=$A)f9qBRu0IuZvVjN#Hw78MBs>zo_WAtwP z@AlY#*<9dBYvT832oG!)hik93j%uyd zadRl8w{&x1e);sG;`f2GQ?m_P<|`xKFrwIXmvtz-2yKL)1a`W^Wj+_Ol1eQy;JGmTw?xksTteP@& z+RXdw$9Jsvi(dF)e1|)6JGKWzNp8MtX6#INeOtz=oK`a-udd&^36@@*o*b1d5TG5SN^*S)eDHHjP(;)wpIfmYLH?PsV9nYfW5yu_$G zt6~O=1Ezv@3*-hD9s_5e4+%>n9}HCIWV*pvjeT2uq9OCjr$<>cILUzNFLH>i2KrKPQz}D4iT=F zSPb*~-fCZDtiffLG|Yz!9PK&b<-n;hk02BgA|3OgT9-2#+y~@(wC;0Q;?rv!_nFih+UB{iK9r6} zn$W}O-5V~p()@by@3qYpy_Q(h4Goj}XP#V0CxHj$KEKc~F|nQKV_8+=_CdH7x-8xt z$2PID3!CiMkE1%leQKeQK=lu_9SPD^3$k&ri?SPFZ4MEv?F5e@#-cvuXkpPB7q`Fj zkDrIqO#D1&HO+IL;6V;)y3Y+q((p$%9FvX1hBJ<^k+VnX(KtCgJf+HH#F>7VAF8zQ zaM^=dv4Qu{(PM}X7FI-)0JB`bU+xZl zuW1qoI}2N;fayKfm)NO@-EaN7XZ}q^k0yC?@`xDt;}Q%>JJ){QoABjwm1L!d>|ZL$3^qwSdWuvup6-ujsG*NTGyZH2CLcUL|3^UAm}v0I8m-HY=Fiyk^~tl;?UjzOPbT3s~4Bj^+r{QVEgAX z-(|M<;W)R_2B~26B#`1oU=2pyuxFW=SdIhIkZ0Uy&;4Og=&ak+b4hNF<~0&-zn{5Z zWf=j^wbqBw?_+8J=;$8pf7etVnT{XTGTh^_tPu8&<<`BeAi*LF9O?d7#bQewrJt5O zHB*qITW}v&m*VVvMske#a&XQ=-N_OGf%&n^`p7K7jG{=}vl*;ybM0gSA-@SDo)~pQ9bds5fI`3u$duot8gi+~U}1_UrAD-C4<}J=0y* zKE_ngcR8&j7?T^FJ7>RsP^_aRzhw1ob6V?5TH*oPe@00JJ5%lold2)m86THVg3Rkz zf z2DySi!Myj>bEk}zmGKy5hABrJ2dqjab2R`sNjF;GL8k4FZ=T7ImKd<|;{<1+GvVRX z8`d(Gr=i@hUM?$Z-YpI~Nq4pqIyD9U!*omeve0M69v2!*%Yq_ZYFqbde?j-Q(ZLETfYoIcR&B z_S9nZtWYPe!k*+l_z5m zK9SSBehWJuBMvDT+~!QAe1EaZ9~I3TJQ1_Rb?IeEB$CbQduEc}8FNXG>sPPJ3Lz~v zSv*LE49t55>9CMq-I_+GR z8z=Fi6p~3O+*nxQ*tCQ9Dip8^t7#Bg;&sVC1zRRgI+z<+{w;j`=3Jym*Kfs1B$5VDZ@lsVACM??f2`S^3#w$h9I@@l z8%=gj*Aes_Ts07W{tB(s@*PNXi}i8+9eR(C$SPRaSJ`XdX^V%tNSM|&0cT5_&5xLb zxoH?>$1Wi#^w5vQbY$guoR}{)@PbW5ewm^^!F#DVdxJ|s_PPljq;P)}$uCU$nb4b_ zPhaX5eYZB}@1z)W7+at&?Y*Z!*oJ&pS(jy4*5d~|Yr%8FpR_bFrng#4o_jaC^6#ph ze>dvpYm1(4!nwokGzkY!ZuUul@HFsn(Do~~`q9#@`p45NyQgKBvnB<1v==pk-HdSC zp=(@3IFEC6^Ih-2x$H;bSqCYE&z{HX%ZBeJNpV@oBzH2c`X9%0AIGyp1bvJ`RW3U+ z*N9z$1Gn{V+&A@8mDC*HP`JIe*#(Vxl3rQMjPV2Ug|XE-u01_#12wr}-i~p}ZG+vm zqWXjuvCa2w9_E;kI~krimOY5Vn_k~+fc3jUHa+MdiG{! z9TtZia$eVM^ueedyP916&K`S5!-dk5?32VvUS0Jg>JQeAo1boWOWV`h8tQhn+n-<$ zW6XMIMv~7NE7ILnv$?O(4hb+!$(SBpmhb#t=Ds1!a#5GWa7&lX$13BAjl`WjCgdx{ z>ObQD06Fn2ysm8g&o7rGrHWAE5{x}INSWi1IuFV1@qV}Eb#c^ja<26%pt|}p16(XE z-qr`&KoHik+K*@x$A_ZZb+&y+vfDJZ-8Jrc{#T-RXnacXzKiusspps3xMG@`9?;=0 zCv<%QsN;jF>(%s(t1s*JKNhNOw#u1NXmbNx{eXItwiZp;_*MGjBMq4^ zJ3}1y2TQ>%t_hNLB>Qz5`7Menb$HCF$8l(ZJo!pqlXq^H7jg-6qvhCefuBp=L)%V6 zsJY~9crJf%U^090qR@{o93JLK@XJF$0U1kMqb|Qyd_Ur+lgkWz#tiu<&0;>;jB)Vr zNC}f8$Ed%S>rWSh>Dk>grMD`crPJ%`FX|Ps`1e}I+~C(Rv9(e|rH-x6_Yh}DfMI&K zLBqcb>V^(JR`$M%*ylFWx$R(n_OaVX=Cj+kbRTU$R3+_%a4xX z?f(FziEc$e1H1?$PG)!zxX!Wlj*gyRNzL^$EB3f!7;tgqS!08m-E@LWyp$PN*RH(A z`Zj*Z!o-)buQhF{@pFjw>4_)wp4j8=D|@NsRLYrT$*tk- zfKIIrcVJGTq-eZ1to5wiZlhtr>epo78*k64&S$N=X_*e416tVrPr+8n>pxj~r2>q+ z>+PavZI&1$h>|&XFuH8sr-^{w*|#>0#lU)wnFImsZzoaUvhsepbn|ep99xp-7-(xl zNe6%${{V6MHdH!a_`Jc#wf6Nai#m&)Cuy3SB*`aZi=F+a71LtjVd1mW#HPG<9$Q;O zL5~;;Oi}p9GpwVFkb&2S`TU~0k;4ssu67^z#m({MmOfmQFK>(1I$df_YWgqMKdjhP z5M7%??Z(ZpJ*=~Hn$OW6pwj1&?LV6mo2mZ*jn0W%-rO2;GhEU`97AfY!{Y7EALdH) zM)apK#nyY+9_qtPw36Mr={kFs%^e2nJ&e3mTwoToi6E07yib?Sb9eQhthseq+&+}* z!d2s&#Nu(V-7g~jVHe0vTu-6kY z!39nJiqFOFPn_mwE*=vcbB-aY8u~!l%FQ`TnB$)*kP`{ylx3S9qlzTRQ0bx^?B1={ zADNj(9aPbK?6{Y?fz8}Y-LdaAmrHay9p4gx)4FF|$)=%2n3S@u!Gi0tnBsRkLfaj? zQ!yeItNIp5sqS`30J7UQxsKOsT<7;b)3mmD`7GyjTW;y!Yo{bu7#!nXqrTIxoOb>z zkLvXG`s<|i42tbz@2$1$0kL8F4nLu8gSh+^+9>+i%$LpeJV6n(2|6F8=#TX(e_L^~ zjW`jKT0YrBMuvBL{n{Q@*vHB>wXVC~9!s9l8=83LVm{?Z7bi2$XNMm&J-=w!&+3;D zIum;MTXPS^XCG)s38>0EJXr?3BlD$oJYKVjhl<>+{4&p7u4X+p)c02M3|RjFNwKtX z$%UnhZ`RS)EPXvk0?elDCc^A}mKOb-?QZ4{2FW^o6Rd^JXJX{lRd2G_Sl5`>bZ!KV zC!Q9DH%z+gjYloj-qIf1gGt>Yu)s{U!Z&&G@L2D^>mDc%w;7hO0%oQMI(z*G&)l=m z*Feg{?82}HT4;aLYjqpFzN2868bMuFW<9sDf~%cDV}prkox%v(elml07EPH|+AjSA zT3Y%D`b5YMFXupf6`o_0=W)uga~VMN{{T4{WxL$n#DN~8bJ4ZU{9m5nIEF8368#y< zGSf|`f1~8}HhpmV>(FW6kzY>8#{>}i?5f9b)mS^Z!9XI<5?sG`gfN2O?c z+{-tIH*1*Y?0bKerl>tb>gQ0i9EN0zHVy7;1D_x?g71SvjKr*bu9=r}MoaH@Lkop_ z+#T+KTs`pNA+yh93cB_M-{E~ZAT&H|oqv1W-^E?ZdHXHBrH>MSs(9s9&*+%>k7K9O zfZ+F3U0aDU?v^-eBe*LT@2dS{5rzFfsXJ(4-9@DBI(O8t&l<5wlQ+ch2?_GwdBoDUY`UHOy=4f2**%xn`__Ct1~R^ue}+9qe|T@u$m)R>pu2 zE>|aynbaz8r<=P9!bp~fiF190&1*L`^Uj6e1+{|9EZb``P4&0I?mFo^yvDj8!AtP} z0Ej~;(OllzM8OK}5JvxnOd7hp2AEA@= z7P~WSzZ$mZUi;ryy2iEFSR5m{CE=6Wd?jV|T5--+b1r+uBQ#vytq(RAz%>ozvlxHiFYt<$E@PZ5SAk97Iyhl$cN@w1(KudVpP z8CE+P>9vfH?a3cSqGB~r6=hXxXtcZ3XnTfhoI_0dZ9hbk3ElKgp5Gx9aC(kEP>)Y0 z_Z{x7g_m0v7MOE`H#OjHk?_?=n=Tm37|9dv%5szA zz4)6=4lZ?VE*qNA(`MHfZIagM=6*=`V!U;W@Ut^Z3vGG3G4rf*V}Uz~@3)@AQmL`R z>wPEWxwSO7w%3xgWMnx`5r3aHPF9h`;tS)u7TI$;8(&4qvECw6u&fh&Jx|VHKSxu(K?q+HO?qRA`|aEAe?V04He9#uSS z9G;_vWtJ0+ZDU(Q0VJ@N2z!9#(YNl`!BXZ-z2DV9$2f_Ub`}P{qqQF%{%Rlba&XUx z^5Z14N;004#VRo(I`Gb`U3>WJTs}`n%r-}-we74M1&#oZcc<>~GvoOcexI9vPqCLk zeNG2xAUH_ZP278-cNyIts&Eon8AI3|uhFfIEo=8Q0m;zM3oGi^)NH@3 z9V)DcXPRnz>}_-gn|3vT9p!=J={raR&&f*{sf?V;nRLDGE-Yrp7J;d3J3%^YAzWkf z8`Yg#^=sT;SR;mtt8RukE|tx6Ppbp!uTeRdW;XA%xUkx3EpV*+%O`WA=*zqYqq^+v zW9+A8ZY**9`7$Gq3G>x6;WOrPtB=1c?pRQ8Z`PN#mP>87sEH&r&% zTWg18*6qUAy|ouPkM_CVrs;6qGF`Oy1cFVjp_gTtw_3|yMWMA4{{T&md3kp7Dw5rf zHO}wNa1jA>_?W#;;>L#;dM9(Xv^=%Dyxccx?g>`wVT%(Yo(*iRNNC@I`AL8qop=(w8~MP9U9BOK;fz33QM* zk*~xJ5iyA%nB1eNC!wmf)8?a_n30AYgAtbjjIqSZCNk9H_0Tn;{z2O7VVId2F2jDy zDt6q5Rzse~I@fP}m$;XS18~+3ut^QcW*t(xbtz-AQV6p*dv*^9vbNx}= zcjfh~Gu>UePqFQL!|dADf*we5aCXqpcNyLADe&9XF|v#CUwuwt(c-2x>=CpXpKm&u zRp`eqrpDUFwe27>b>g-#&ykP0IKAf?)yu`r_QZ|kZVl&&?LRbHY`(_t73_!}@>{#w z4DHr6F|UHHW)4^FDzdA&!jcPar*n%*+IG4o0qlNCq~Kw}EMig;{a#M|GBw5i59GQ$ z#%SX*81h{37#K*yfQ}EECiWkbUmvIC<#fM6t*x$ok9$L`Yd3B5nIA|4?r8vh-IdI4 zznO2|qXUM(<2DwZ zWxq5ti<~mXeR(f8@7r^>G&mB{L6A#Jy@E-Dx;ZF=8G{{+EZ278N6tS5pNU*`9M*tD zHH3+iKDF-BJhg?Oa_{>{#yIW_G6k|=5Yl9Ocsz46+7(=4>iWI=16<218tNl!p6Mse z?=ATsg0Gr5&P+9@21ANop1cHoci(4Qo6nQogn*Rzd5Po$fjzyfARDqCLv(XXT>GYZ?&hQBbsWd_ z&rozs-S45r^xD!LX4eZGT){{n2m|)I8_UkevvN%6_moz3Z-YATcxX>oFCW-qjv^lP7WK{6vfZ~DqWxQl15qvw6 z1FxN11Gcsu2WFgyHYKInOTHYgf2bBc_$&@t%f_ zHp0N`E2ZUt#-w|;>!!YXEf-5(YuW%KKmj9@$Fz1?y;mb8xYi1)4#*nR;v8Dj^rzg- zrU!{t`Ph$VC?MI4hJ%i@=sU4<9Mr}uFgzwT>kI}!A)*_yvpxV66Kir@i0>2~LB z*RWMCXcdP&u=g|qcr)8U;sUky3$|GQ0I_8|zVLJsVWhj#)<{)zSxr_JS4FfCevQu$ zIvDL+Jk~Ep>ec0Rs?J4L`tBF615W65wV9vz3}RG8Z?w%pf)>O7Fp1h|c6HS7k^ ztg|<$btczdO%ATjH(L%3d}*UgAb9BF2_8x}=d%XJ&@k?GV1{~(4m)BsvEHAv%$*k} zoD&AJG==ce~%a*$o?eNsf3>WZ7v3r!~7nfinQWG4y_1s&dCtuKIp|z@QQje>EhM zN}Y|l%=F$gsB5g~(E(;=TH0wZv*@(J1HU_3IMl713+C23vfZ#6e9Z+V9d`2VOX4`lyU-IZ^rVtWP{qWzF2`ox zH9yR=v` zp`;DaW?{qIGazx~Rg81X%H@YKf=3=mN`d+G zk9EMhs;y;?4f;^m0(Q)6qOOwmj9lz&fZHg0UsbISs>YGE&32*9BgI)R0C+DQ`nC1P zH=tVTuE%xQ7C4iR?faPLY98NXh$r)#5P2G|v#fo0$HwXP<}?>%WixgzBVD*ThFj_v z?b5%Nr`k2+y5zs(UnQ56mTc1)vf|e+Gh>JQr}Tm8)%5N|{xtG4U z_fM&QhDSxJ%Sg4kazo^X?O^o85fSuAC!WVuv-N`J537Ae?IY9s734S(wmm1G z%|DTN1_xT|SPb-W@-1ZqmwHTjYj+W}xOfsYC&6@fe~f(BbSHG5v%7QYeIC25pKHUI zPTx!!hko}fpz8g18>izs+?xe8hiu$rxV|UTt$^-({D;p)$g?Z!FV^=yya4PDl1|HV z9!$IwsB_u$yZb7J_H&gEnb10qR>%JUoSl5zlFHq;8>H7Q4h8#5BVCQ3&2Fdjm!{A~ zcx^P%>Fi)@XaF=c0i#CUAbEV07$wboYDRg^PD_$886%26&gX=#jO8DaCcZ)HBK#ao z{{S1$&0~iv6DZ<_I6^Ro>BJ5gnI5)Blhxq;cIllH>b^6sdrj|c{{UyktP)S@?A51` z!eTcb2XeR`z4fE5{bP9<78>z4`!U*1&BswcyzPEnfLNifa}BPS2A=#GI_o}tmc}D8 zjvuK`6YMW;)`qdtLtQ6pgL{9js~@3#Pw5>Hi&)RJWi)A#U5fjSYrM2CGW%bhbwU1+5 z_YgOot|wt|5H_^^f!=I3>%^!oiwJc7nG zjboiyf&d_E=}GpV5{i-yS3UPWw^mpf1UT@21Z8g?NXS^*#1XfFrvCsd%wWcH`-X7h zF{3C*lej-9I_uSZnzA2#je9>y_JUl-dw_KIcA)K;nfw;*wUBJ|8Jw{M9u-{$(0I{ikSr!X& z1#Y;xt~WkIfNt080%P0va1~s3TlOXZ2f2?d(q*99U*q?qp1k+g?YORz%S7%k06wzE zIiqjpw4aizjn*uyr+uB2I>sa+k97zGYTia2|9xD^;gSO*z^T+u@jeI_m-duOr z4y%ytPMqV1V`Da#!Q2eAziUS7^&|z+x2W22#lL2Fu)MU_4v+^f`a7fhKZdIll;?0u z;vCuHHN(rx<(9%S@bO|i&OBonkIFTwApE+tI>mmTB@!UG$Rkmqcsi|IM-i2Ag68b4 z#F!+3=sJ8P#1A!t)N`!KuD01zt1TplIP)j^qlG&9lf$22tnT)WtG-5kz9k^YN6D+ z##TiPYq1@T`dz}(94C<+3DZO42`Jh8+r9-x>m6R*tS;PO^QZZt$M8aZ_BygQ0lBB? zZqv5D#L4EyEEBJhXUp*(UUw*QnxAZF`YcV#)c2G+8eq9nWNhQt%DL{a5|H!tCjVOsd}t_KTffMmzvz##GUTcR_U$q z`DuU#i!URs=Us~0ZNj(F3~-1I5YS7A+d%p!Q~0U2n(V3d+QvPObESk!NZflBm6Oo! z$F${iyI#kRYu%|H4RhoX{Fl$fEi-kDovig@G;GYdz#h>Jnep;ZUPaHeH`0c8aV`gg zz$_E@s#!U1TRbtwb}~c`8N?XQB!29M-;<4>nyh@e#7t!ohI6oJ`c2nr?%C-W4aw;5 ze%86JFMFG|Kxe4d$!KegOmJ2`)MViGI}c5B=)R{G?QDqs=7Qrf zh-617?Zu)H)iuMqDz;GZ23I)_We&S~`;8*ph1wV-bR_Wo0Rj*B9W zqtrS*{{Um^Om*1qB-MLm#yR$$OGIkZ?j58k4s6_{;|^@`;U=NXL~Yn*9XGBmntasZ zmn^{Jkd{-DaD+PXRht?b?mBn28C_Agbpe}^i(Oe2xwc!1_Po()2X?i++nX~xXKC#m zCfjCqcs1hM@BnRtV3O%1IqYC>JVgA_`oleJiw;E=RQA-y)+{q%XbmiJ(VMq4Mx$Ak zMVWm=5%qnc*7|jrsF@&bjTygB1+CRz7*;!pYk&>}AE4n4jtN#R$)cLQTOKxu*G);{ zKJ|~(`k4KbZcaz)dze9RE;0z)?A$3X(f#=F?x#jpZN8RfW-FTeWwhf0;@acf9RC1h zhaWcS+^Hqb4|YNZ-(*X_J5i)e>816PtMwOWWM*Yola9|_)t0k$ zOd-?5xN#xA8m#<`toQv?HC;`(_@(W#n`{;aT6eqIQ6N@KJi30ChqoGd^k=x!pVm4i zW?f>|vl9gRwNlyly6b;H^8N0fJpTZatrlN(c4cG@yISu`uiW;LyUe0sR^dbSlH%BL z{{V}uNaw@vOD87Ak4RK@mPvfNB=ZHVcBA=FmKk+bkU)4XYtGq_?Tz-tc~AQ5Bm`rS z0V5-+oR3m}mXB46Jcb;&qX>{r47lY#Zg(PM0e8ct_-Gx@gY^;l{W`w6*56}dm%k4M zuB2n@x=jEoQI1xVJ&;)WN z!0qzUUi(u$P2P;W$e4VA$^QTc!BESnUAWW%wUWl2+hRaF1GMCTK~T>OY-PbC$Bfw) zZgAY=CR*_I4nM`d2k`ud-v=q2@(7${%nxhy{ZftH?Opb0{b2fu^^9b*6`2jrW@}5^ zTZ5X`J%o}2&f)A9dtB!>WRE4wGwSD9$Lrs)Z;Wimjjd~+?0Z}{w`Ut6)R>wQD*wc^+^&NzNPBUt|cTWC85 zn`+a z$8){cIl;sb3%34`b&dAx?bq*FU47kCBNV?NuosHM19t-EGjOYDc8vfNu7|fWwsHQl zWcB`xaIfi^SvSyYvnkZLhnF&0y}zs28VPH+Pvx$;0E<2HaFDF)0=3uwK~U_9iFG>Zg$R`zNCQzcfw&|zdqMnR((HJb3WHyj(wH`bi?K2{?bO#+ej0r)f)-#eP!;} zc9H&LIr*y{)e4?*DQFe@UPot0+Sa$-wXWtROy^s?Gt+F(Ghh+%^kG6X#yEHk{d^}~ z_t@J10B4t%BkfOFj6R5P%J{?xt}Y%O^t2yRH(An+)-XA(z3gV`CQE7h4TJg4<#Y|` z40dbs>!zcQ#)jHVh_lk(9N92yG6@}wb|rKF09W$!IzLBlFzFdxO1o{c=eoa9jb`ep z0j~7uw1;hE#ElPx6|6qGX9l`{u4EQFR^%IP&<|-Xv+SOKf84D};Pcr~$KU%)A+7%v7Y%^ZJw#lmA!=Vv)+EJxZtyZzqfH&w;QXV%9O$re*{oa+H=H*DG(cK%~s z3n%LDr+?O-yLA%!jm~Isexw%UncptsWCP&0b2_#G`o~-7>KJaV)miFU>(Bsx+d~80 z>TZE8({8+-TCzT_=U^YL-DfJ?jCyGGcQE>_V+aExp!S!2AuazJ;UlNJ2x?k~||e5kf%!0F;ip9fs|W zt4k^-ST-4MkV8zFmhC5W>f_(yxt^sj%fqh1_SVbYw2=UZikeGF{q4GG#4fw2Wpvvw zeZRD5*&I-3O zA|W|TUJzslm+>waKfrN}QMqElA5g6f<+1PSy)^vVICa;LhjvCp3TC#tWVPh)bT>%{ z+aK(e%;i^Q@4q6_1H+FH0Y6JXA)r7!E}Jtkud5o0*viS#jjW4~*M_tmt|#1djYpga zSiNDR9*XMUU5|9Inyqc38hQ2-TcH9Eg3QIn^$V{p4H2VH=I-|pInqChc2@emZG&;j zB$q)lNZa$}TE#S7U3Al6A%pbAt{nFtdb;*jS++m}fC&C8DjcYkc!3vYMnhgHOXmI# z9=gklSFEplJ$G@5CsJp(+?16zwXPsf8o11Sf|Hotx)3AtLH_`1#bz;Ka|~}}4Lqkr z2U60(r)e7f>si&*A7b(WI

4!c><1l=@N(-tG?(hNEZFoMV&+!weNENQ;yI500DP#^ zgxc};294XnK5`Eq!DwT#kI2Y&;p#DF|}DD~_R%BVR}#yw}R#&3-d& zf2nm%b68yPUIYoykg|xWy+bAC%?$fH52#E6CZ_{E$GKPLxq2XWpX@7hLxyL!ijqkr zEuQBA#0?ftU3>AxIW@GrG4GavE|3`E_{Yg^la4L)jkWK4Lzp)WL~f9?I=kquo%Tb+ z543VioIZ&7{zXrl#rlc*xGVI(bjMVPNP(v0f#63^#YrTR;;PBKc&ns4t;q&QmyUU=8FK_X>kzS%Q$gl>N|2ZRl09Zb@m+FSkPWes%X#wKTqNN zzk1ZO1+8yle2@1mUPqVDj#17%MiS$I$SfYVM~i0;W6K(hc>e&-lh?p`DI}6!wbJqN z8;?_JaC2P3=IuL}<~ilz!0RCHkhE8oeN+0{{{XAjw+B7mr%AArCs*Sa9bDG(YbWUe z$0N92qA#J<3tMANZf@}KL1}3lw*%n|)_wu;UR#^xuMilrVgfmFb%vUMf_fI{=JRs# z8F27R-H*2^5H*iT(b~G{`y04e)MUQ8-)6@_)$&>dpWOtGcmZ@3b*vV2{{XW3E@@*6 z0dX63GcFv?r29`Rn8v(T?XUU{kW6tpACj?V&vQ%K;|5$0C8A_}RLKFdcuP;cRJp*@Zq;jN!`Q`6~+Bv`u@WI0NMQopKr-`v|I-2+Clul-{(m2`UAwPKM?re zEy%-)kYl9dkU!>?CCCuml0E~{4TmH|}DYvNPKT5!9 zV;w#lfwAA&V#?{iQuF%WSKEHGbq8cz16}rNo(q}}xJ$>egUX@(rQ3AQi_6w0u;+hW=3MWYS=jUZZ{j|zQIEs0OKD|~yPW?3)c#oc8zHfSnmHt3M-j+)Wy7HQ zyE%Pcs|$-I&UJ;)vEF={GF{IBLp!dEgWAUL^*3%j1G~ANdGJ|vR_mS{GD!nc2Apb7 z3tOl3*7~iNwWJ@UeXvirw4UphXHx$F7~N2VjfY=NsGS{P4Ke($TYLWi@F0s{)t|0e z4F@x?I-}fEyvNO+itJKWq5l9EgopH=Z<^*$Q7rO=FTxo3KyF~{{R$f@iXqn4)u?vC)ix$8&B^1S4!@cTdUsIZn2<-77;Fh@1Wp4 z!L9)5{81^xWf7&*}Rs-(KVFeK2_SEOGw;R=Q9C?f#`_^4|dD z<f*kPSvhIsFpmh4JCoo%9xBR>ZI?(SkO3YM=jMxEE1dTV z-vykK2=MTp2adpXv1VQ0xOW?Wj z>&o-o#xgdJS$*Oa{n_jIr<}oc3NZHhWy^tNSI!PU;{upXFA4 zhy8U}c4l?&t6}3R(bPI~Lzpeyt8^d@&ffaZleag`ML&u2+?9`rViLtw_pVyy82IGI zeL}jCVWE#KhG>CeSjVP006ZpA61_U#7!6|BsRdk)&|W62wUYk@Ju=(Tw+YX)2x zWsf9h#R%67hizFh<;OT<9^6J*9AB*UaSGJ!>HIpq7fr{)%)zW%dB%o0&LyW~S}k-m z7B%kIapWJ5WU{En#mS-g*EaJZ(g(IcYle^a5GFMpmUm6gWi%F-2D@pm-boPisc7x; zN24zq+{V4I7}tjZxCd<-yWB`Kq9H4r&FlDC7}h^7qx&+=&7#P2Zhf^sW1C%X+VJMN zyugo!t8b|1;&l91WaT?+28{z(IoyV@cX3>_*0Ol+Lf#s{+dZ0HI-OTSI1dJBfRs z9zTRs_>A*qoOy0uQ8@^?#zNpAbiAkcYU(v|HK+iw=bWX?XZEGSGGvg9y(8r&&G~pY zdi$GROE*;yZY>*`05z`_wy1Zwk~eoHVP<9R4eNhedJp)o&G4Mqvd&VJp&Vl&)Q%Hk5|Q$+?AoPf>#&_$-uo-ZlSMm@ z+T8LB-WmL$$T9Qmy`{dpdVV!60EcAU*EBplhQ8T{xxu7;IWB13wjk@Tkovge8rte< zhFDAi1nCp`{vR&g*L~3buu#sE_FTM*8!vP5?R~V82(0g8-d~_D18LL1a1zM}?Doey z9UpO3dVc2PT3Xq7c8$kMhS@#N(zV|-QAtiHDG{r3>eLT5q|srf~W82zOHl5@6rbjY3N+IiQM0! zx$G)Bs5XDy4JjEAsB6Yhh3V~Xq%7T=AZBB)#uyLewqA)<9=36O9ayuxGXngC^hukSX7uF z(ou5Dr{E26*c*(X+L3`xC!Eyz`;ZpKW-c1N7WD3gr}d|RSq+Un)5Y6FaawCCEoBS8 zEoWoSGn)vg0_0fsIR0u+^0=~$hNsFRV`=b~`KaXh8KJ#y+t-_Ud#J5A>K*5C6Qe=z zn{m#opKXgOxAx_Q&KA8e>Ytm=SQhG8vF3b7Cs1Ig-G+1bptCB!*AyZARR+~U}#l%Tl|8Dm)&yisN z0r=Y>8hifTyt@lpo{Ti_^Jle(mpuXnDJ?(kTJV|dgQo*gZ z2hLpM537m};l}KWVPsS;+q3{8 z-KLL5xPJg8S8i;qz*Iqcil~g50PWAi5>tXyk-Pi|f-;5ky+xRmSaa@ChSEf_-EUwQ zd!&rF4v$h(0*rzgCLifq(aqY%q@F40E>m-@K(k$;rF#8qeU!`~7U!duvOFO7W10hygN371IB{no z;8wg86EoZo_CBvJx?Und&02J*mL=mXcuRD~$W6#d`NsRdkKvTz$)FLo+L+N8)vzLY z=a^;22g6vR90NaTR-YEucML5nZy5T~fMYWWe5(Phcctga#j!`RpYwa(MYC+A&PF6T z4RxeJeBee+hY>MuPC0Hphi0Gs$SR$`oEO!%l@)lXYp|%`;DmMWC%Y{sO3JVk&bZcm;Pi1F=psK$Y3L6HYeoA>h*DSpRjf z5;M7+><0E7%xQg*VD^!))5tiPnct1#PzIE$H`syWtt z=({By9B(4hXfc&3$tvMy9xcGRG4)k_?KU$Yb3S@GXQe|e?IXj_M_C!|?#@fy{A5M~ zXF-&G(e4(Btx@-SaZw`UH0%FsPYf13xqiK@cE{64O=VC+LK1TjYB@dhOEmNE{Z26D zwMxrQ2Ip#+P*AiLvBFPjNqQL$V^Z^rRPZ{|GM7{hk|FmTlb!vgvy>h-RX=D5w#-q( zhOp$iEm3!EQz;%FU(eW$_a_Tus4eeRvi)F>Sk=p+FRC;`r6Ge%6g-;WudNqHiumcp zPH>NX6Q9KikyJ0&{npO}*z_t{36|CLaW#UFrNPr*?WGzj>SWr9C9r>*jNAH&^48{M zFF*F`8mk@3Q|qbdi9K5|tzO(BkqJ>mIP7DnW2PZp*|ra#TpP{%NB`eB7?#3o-=*Ho;kPK+;zLC{WtS zgz%B3eDDY3seGl6|P@+-H4~@!t#!mC=K-u2s)L@&i9>($?T)i}9rmZeqf+W>~_)&wDG7u+_ z&yz#wGY7scN<8Z3^VAS+o?4K}2pWEsGvfZr{aH{>FaOJjr58&9zJqDXRH9P%#f)$t z5>(U^|7ehMQ%5n0BUzjjMBzUOs3x+8~cpX_SONcYd1*b@agFOCII_M2j> z$Xs?5A!R~ai9!Ol$tH2y{{H;MBUxkf(lMFqeMeVsBE@;vWnJ8@DI-^gU{TyK z1*o2pFSsthU0-DCI@U9LIn6H;p^MpQYQHQUI$4}cmdrH!2au50Ph2EASIU!6vhS)Z zPd{Rw^D)>I`mBbvvF*z;KQy0fNc?%28+b2}G2gc|u_SViAPccpfMhZw8YWtTnR3-u zR#~>?Xju3QC?f!Xqjye@cH{QW@%X!EFFD~EkfQQMnH0{*JLHZ!mrA^Tw|=HVxZsHq z3{s~>W@U!ss(G!VNoKi5Skfje9S9~$9=m)S{fp0NM&bEV1omJhCE^CrtQ<=3DHo!# z*jG7T?`_1K-T1s-cW%dFUW3s2!1b5A zNa?!Sy^Vp?ver<%79+-RLLr}iIriiaIxD6Bt9kSDSixhj4_9*(bTJ2F$1aX#^*uwM z2~A)ufHirE72M^@qBcI{o3H6|{SRO>CCHE8CH7;HavaY)+LGR-nkiJ` zYBv*c;vI79Qv4|SJ{N89kHulW5~vKF;bF-ERC=fJPWMjOPYN%*y-YIv?6wt4P0lnx z)cx4a0|Fif3qKX-Tuzs3hdZJ;7D1z#%y-dzu4RiDlNY8C<)yvYehXxa$}avkyW~`-vG{w%S(BiaNOz7J4Ko zX*Yik_^{(SImB#h9TBHCb@_`k|C^)P!PqG*4Yt$J4 z3ev{JDmgk#@BW-+)m2v{(QkFK*970|_i|(Y2Y5JeE?+p7y17VqSsW zK42@&#K=u;vl#!`;MksTIkO`Q;KF-7a)$YIc{|ihu96>QMY%mFE>( z_yimu=NfZcjdpPloPGUevaQ^7S}G3Ljf9-JK+|p_WxHZMTF&`~fsD?IeLRsaz%7FL3XVZ^DA7 zHUk)kPDKWzp08v*Xz=!63^4X^0b91+RNG7om&3VI_V0Bz)wnfuN8fpE>X+}Neh+J` zC9UlC#MUn`-!eKhE5z;=_Yc`GRONl>N0GT<6ARcjG88lYk~Jnz><1tY17dngOov+K z{9cuZLIAJR5bk(V(+3&~4#`X#31Dqq=1=@6l|-4;ECi3k^BxWpQJzB8sD#1pP)g{= z0O{$k4RR5Y?;oAAQJIRja=W_&Z8+3KV@*<|hi}5xPCE`paP)32BwaClXQsaZzKPBaCN zK9Iajr%H-k;EGzKq%dBy4jp;^O?5jbtT^J zg4PZquvT#MOW*Q2Y=U;qX~ah0M>i1uS95F1Ak9+hfil*5De=+OlEbEynh!-0O**?G zifT1yqUs~10$zqCmQT!XpPIB^j&@(`&!qD>Il)ItpsXHqTj3cUN1Slju_`3=a|HX| zbLRP$`R<4iJDq4Zo@CYbnQlNTOx5lWQ3~v^rg$4cBYGpL;`ny(x61r+@RlMm5B zi4b*LN8EXeM;L(CPRl6EqGE?KJ8o#*%moNGO99iEHel+49RHU&k(HYuti)H(Fqfyy zn(d~ral}O~eNbG=j8Ik8TE}XO`}~Z-vpl{7dokD5&9SaQ3AgLY%@d924)_m0?zdj; zj48PEi6*ai=&_+;@P2DOiP(t$cK~w6I1O2qEZnRJ&v{)lR%EV6_N=sCmS`<8@p z0$-MfEZU9viMzT-aib;7cRhokt9=1G8q#9p^VmObFGwC@Dlu)7eREDNl=&>Mb%!N7 zX0}&n^`fANRrd@K>)rBb<%p2GiK!4tmwTG%;Xzib4Ct}q0PbG!W|EAO2~C4KRnmaW z8%cI@o@ORT@2ZYfd|d|^58-HwKhEvy`= zhTvsE4(#s)ny?r?JYT~!?Y-q*J(C?uz#&Hqqns(qcfkc4l83gm5awC26XY2661SF0 z{7Nft@wrJrdaQE`DWiR#TXTyu=JJLy>->KC&}y!?n5PL$NOA<-aLkTz-ni#z(J@l%B)Jdq20fyR!4q97m?2 z&lY9g3>zjU*5>pGmxIo=KkcGRYbO7s=J48s1E^>psj!9$_ExV)o}Hu!gQu5^gl^$<{cifDem6jlxWe-qWNMit7&bu07 zN}epN?g46&;s@Eb!A-CsZpL_L#NYGNp80O$N{So1_GfBVosIzwU@_IbU*x6X<{QEE zc?s(Lsjsv7gjNBOj`DAmC(vfR;>|>=4Y#xw01wQcs9m=(LJDw7jO2e!UsF^$iDOs9 zs{*|rHCagt9BF^iasi9CZf>b3j^?k>F%;M#jQ5#E9!Nj}o@k{YSms3&>9n8hX*NvUM~W;9u~f6dl) zC*oebvo8raN;;$;(eVhV4$L=oBB4S=90SyW!27pOR2CLD6ZMr5_wjl9!C@VE4@u9> z)Vcm#N)OJOhV0qrW=LyIIV5yh$b-56GdX!74J35Vzk`wB==~oN^uG6XJE{y^J?a0f z4^AQBip@}yfeh?7ru%~47w-QlE=aODdw{uyvk>b;CO7fGbb4(_rmb;$t5p4*|^u;^NCB3r_W^HMUVd7s2z{x zZ6>a=9asLL3ZnGZxwzEM!(Flm5V1_9XJEq^8?V_EaY|^PL7a$3j7qhz>2!f$WL5)^P3oE|vIMa^Qwa}`wzedx=#jpyLZ+Q4F+GQBfRp3= zk64)PRhs;!9r~I|eAA&L<={XKhjD2$91T;3gfZ98yVo%Z?he(@>p?S%fWk?3bz0Gr zOuq*vegCbIa;eQFp@Q?xmU*o>KL61prT$w!DNG`Tl@`s=o8&}5y#RLID`7R|{T47O zHL<~MT~Hv;_u%hsNRk7GiO(m?9=AtNEMHJBR5`I zz1^rvyZkGO^z8#B`2A#r6yprgOXX5Wa!S1#9EA0?rQRu?Tb{^Q-QgSpAlLif%8bri zF=0%c7Tn{<1m&><32Nl(wzd|Vt*bNEIBl0nV(9AJ%@gWjxCYnQ65xPtG_AN7L5#$J zj#EkdFCVZ5Lk!kPc1S%lcK~C(uM>$?9~2o~CKep=XSIUAN4~Pcku#LXHWzXx7$#Za zDSpHCHcqJ)hvon2S+>959$blE9Se(kojpbg^#G!Qw0<9`Ukuet_Svam5%;uBTD0QG z+u6iTBf5N5L?&xn#nDChqIlHy4BJ>n&62iagw0&K9Mw02AtKk_ueT&1NAHL`ea(F znX^{-@3TqfKT$!olWG=AB%U!ZQ&F-xLz7J|uXFIx&v{*kzQXXSLIi&($9t08F|MU6 z#UEeciZYxC|p1C?ehrqBOVnM^sffM#e8Ss0+;PDeFq&k>$R(o0Bfo0%D zZRr+g#G*1y1ITvA{G-s3p~0D<0Yse=96=@W7sW^i+?Lh_0UG^i3ThStQBuEW&smGb z;G3NZfj%2evwmZP9&@dP(MCVq+;;m(v{7?NO*c;RYh*XC&6D0}$jeXb&E2C9%pq#* zjX}^GH0hBsYgUJkfI&bxt8(n=U+c?ZT-2O<`@Kyel^lZJ>!pCH;vNs3V=KN2`9jGn z;=QWI(x74ZATXQ6E-b6n(_8+1lP4SdRLn;m$9;cTSPNNql}QF z`R3SXu$T~Xd(iRchXei&{k7jMT&Tm&DZ%BvE-&(z!HZt5Cr`!|W4B!mmyKBY`g%Dm zq8Htj9H|elPy%6LNy$!t>j7>bZZv3+N6z?L`0~|H=VJ03&S;q=`4$^uW>!u)CE^mhfZ>;14 zxZlLIpVW!RxOz78ZFHFCNjw=H2l5;y}Wlg!KowymyN@PvGm*q}eQxcUI zs#ur`sPZ@Q34A^1sUl4-&{d&^xGbdd>T4}K;T;cV9@gxfxqstZ>e5>E)I+#n{Xiq_ zl9WHe?0{vn8j&nOgcAlbRi`?$I}<}5p!;OlU&IJ4EfY6c;g!eCDx_R-wD zbGQ;S;+M6zCogFCVwMtEaae_#ikw!#%#BU6Wob-#kjG-!CA?LNRf}QKz{Jlt!}S=j zf2sY!>|7@TX%uTZVMF3}05Uzxu6G zx$qLyQ|Dc`?IN?2w~f}q*}hBOEa_svw;s9!QpJbzlY#V``P8Z@(KhKaVKS`qgc2j? zgVc#^Pvx9ymNo*Ogr;tY^i%Ff=ZCY7{m}v6x=_p7k20Xhoo*%isZPx5xEBye}bg&x{?~gtg3<+>)n(^f`;AR29;d}_C>XWtq2-O7 z5X%JUoTpY&0Pa5mp$LK+IVP6nvWapu`9&vxKsrHKuUU;=8rC+EN?g}vjvV1zY=6L; z+3%jYr>+ks7>z>ro@Z?U#zm|yJ!MjK9#u&#r8h6@%$+gGN^?uCrY2E15#vOazXs1j zgQuI@lLICKd2<$Yd1`aR8#l=8x$;v5=#~}B5h0Be)Y3&|BS1EKlND{`(XxZ^Gwr6* zA76RkJQh@*zjJIt$T{4?Y3v=Q7C=mT^dE$ADGiJ`l?KQUqG2XSPmW>Uo8qSyyW-am z<-;P05I`^x96iQ#!M!_)Fz;{svR&9W;^}Xh+Lnd5gK4SP z5p&P?ST2c?hMWzNpH&%Ii+6B}VI~!%k{X61#~+fpk!b1=2f7=ZqcK^oF?M79E=Srh z+NW^HO4a_Z*hlDdfrWWuHHKhny#)By6z0L`RC;o< zt;DP@OfWh-VnCd+5=#?38hT*RYL=Pf_<}T*f|9@{Jp3&*h7(jlDMEMk>!V# z9lI#N@VMB^CouG+rC#i-M6A7v+Yg)WB(LlUV!HD5=zwe(j>x6>StB?q%BU|{l*YBr zgnMc8z#)d?UC#LnqEcYo*!+BXuSM+vOtZvbDu+!vqv7BJpmwy*qpLEWx)xpw=G^I#_EH^ZhBvzE z*^fbKx{R0ms4Y2`em-K>itfi9Dhz{(U$Mx|`Kk8&TWhpI$pD-6SIeNv?||`vCuJ6A zm-O?F5%hjZ)Q`A74&p|~p&3|2C2qLo{o|&*N5RGri1Kw#6-G)&Ypk8^U=)mU=`G4< zTxc^NS~j3@1yiSyt$#75$j8YWmz0*fMyr0{8;_Hf@#c?Hf+g0+?t*Maf=r>2FPi^a z`FU7;u}w1QBXC$$?o2o&Dh$4&tBd@WF)t1LuS<^-ae-jmYEQc~8Kt)WtJKdDZIkBS z2y0mSc;?!a#C_S>4|}W!tNS6Hg>Kx!8(T;!$MD*~5>t z_S*%;vic89$BZHofUVZ&<<7k11M{>!%CoHQiTnO~3 z38(l7$x^O^3|dV``^LIQh#VXqwht3s5t(f^h!N8SeQ2bA3dIxox7^)S^K-b1I52hL z-HkwMyOi#4o8iQ_!jHH7CBe0&P~cvbTt1kePk4!H!RIfSK?V=W2tQlG&cDB z2FHjjO`5&7=-V3p@QkR{fFJg{b|z$m7mYA=bt~GqsQz$ksMGax>@tBc=TLvoZ2jV50G5 z?f#xVU`?2HMJ|G60}-BELXB5Qi7-I zSWCwso#olCh)$mPmc3+-QuZEWzfyP)589}qD`8-M^OUWR7urI|K9g9MAg5HFbqv(y z^l`kRHvX0$ou&MGdcC_mG;~^IdHU37=;#E6QuEic;J;9aFD7b>s*TSp3P;LdF3uK1 zL!EhDP1aBV)V5d$J*qW`a9QWz*{cHz4nAouBTS(5Dd{5oCRy@);-~o(D-7ybA)M8+ z#^f0*#`^`g45?~s@;5=FB=88UQD!pn+6})jsY699LY|E=W4>AN2C|COPBAb}-_Y`G zK3QyK43bGAy)lm;8oAMx{A;pUNyEpqPRoCq={{KF%n$}u=+L*7WlG=7HJ zvFs0#!326iI!M4RLt*2ArdQ)!0>s1VLONbR<~X-#*}%kcFO^=6A4R#V=;V~S-Egeu z+PiS?Bbl^@nWzY08j^3Fpe}+=ve~q?WUw`hH=-F$BwYXKD27s;zGRv-&JT+aaNy5~ zr8V?33|tPiIOB1lGv>k$)-aDy|JMsoy^`} zhG8xJhUfWtXIKcjX7OmrM73$;rw>m4>kec<+$rhN0X=nP{-9fp(M|ht>i2r{iiz6l zxug#?cmBM!1o${I`k=CnJZ>vlI@$cf%mmyg@!3ND>E4a}>O@M1T^CuQgP&O;Aiz{w z63gJMq%u!rn$w|v6Qz+Si`)OKi0sh1#BghSjQ>MW|w{T}wg z-=};-wPIl`S|2NWe@ZZ6YaHqgx3%C$O_``O15@|HjNXdj5o%MSxaIMiK z6dRHJ{te+gJkgY)|(0Pg>3+l@_1p<_1CvD|fFgbN(<$bP_)Muue+{ z*ejeJ8H+^JSr!nQ|CK&0zW)ijTtm(_aCH2x@=G3Bgud{eLq>;k$Fy5n>*SCF7$qj1 zM;Tfc`Z_rgu@CL0h*+VvPK~{{-6w3;S5jVcG zj{Q}XE|WyI$A1}C#c@;?L#DA&`W0l!uHd02~F+8tsEx({V)n4WnM zN?-oB@1Y6853(vU_^)&{WxV53P;OTzP=7Zk{{yDxy+#$kJ-6Oz|H18}e}LyOb7QIE z3b%vWYz+LRNCl>S)Ol{Xu}fd_+l;$U%4RO-$PAZ6 z1=PSo!Ok7S%NBlN2FU6&ZQ@4~azyo@Ttc)QXry~JCrrlhiFrvc*)C6x1#?dM$pj{V zG0B`dVl{d@%zRY!bMWnoO(h61w}@ubf01*3zbT9%)H(NPl@F>N3tm_%V}6KfCEY83 zvu7%5GiBp_@zFR;n|BYoWPG-6$0v&jj4r?LTG+057zeMRxjvo&<-<(wk`qLl{6~Lb zV!;vNq+-kJW#C{)nje`NB4f4?b+k~)O2oXv_Rbj-cd=&^q(st2kv5Fm=dGQoI9r<} zpaI4w7*Vg{ltA}}>~8J<44^NQnU70{paQlUB^KP1)KpGRix{IVEOVLBkha#Se?t$f&*5_9zbL-#X~Xe8;<0I92Yx{c9kSguk<-W zx0UGoA5R%ZnCid5^@r{@l|&t*tGaa^N~2LG%xZGT#=mb{MD{0K!8A=ofPJ(*l{6xN zQE39YTg(d*>1S+z+&Nr17W3KRNpo0CJTUOVVOU__090mrSGZ6K)F>s!K&FPQdRcDX zQE>t~?vfc3w@~IFB0JvrMQpRix1*z9x0hw&hX14MIAz%Z!%SbIP-v*8aIU;3ni$^j zW$8?(T=xEcGT1ovwU^PZvC?CW`G$tRzh*Q~8N=1Dzh|ar+3Aer2()TFn)UEbTLdom z2)fz-+7_*!3Ye9lH7*Gyks*^Ql0+^cCY&WOWfx$pkpHMi;c0TwngGv!iWj@H$Tzsq z$7oz5$(|$BL_D}2{iv}Fs-dBFWURNQpFGv8G;>y780u2(3J8CRc6f?cpyyRNp;qg? za{q0_bh+iU^~i?F#EnJhJm|?zkc*BJ7uyB>X4ye)CGF!+;j!~i{3)=P{4MvNlh+s7 z?>j3Ac*Ky28hR-0xmnfX!A0C7Y0JHzL&A1G{MJsdgX8Gfxx zCCSeJ+K-a*G<#+o(Kr^~R;3oMhir|3io1&m5twzRp6jx_V7t6}%-EK0+K6$tjBG=paLHxtGbEJq+82CuYWP8!PaSjXE z)~{_&Z#_A543UX#5}U{=SHmPFk$M%qp# zngY>9viwdv(>npY`I)8Cy=rJ~sp?dBm~fU*^>@jmh!1l42BY!d|K%P7B1WrgXBEe5zIBUxEJaCVpLbX7+j4D9Bh@hfow=YX;qOqK$DnLeH>gS?M zfdco%FEy6jplxRtH=zJXBD(cn%KW^KnC%O$dHk{)Rz(DWXA~~lbhK-cQk1YH=894n zCv6Iy90_#;$qbWe=#p~huOfHR8p$hzvF}pDsoVK4&Fa=xZr|7cZoA$Yu>F|&z}T2q ztf{rBb|LtJeCi#C_MUkz-sxsDZ<7++v}c5r#Y|Qm{%+opcjNTCn*G>vbTljN^d(Oz zc3#T=$$-@5=~j_0{P-V0!xRb@6PGhFm|G){ThF~A=9yVHG#(1;K7fZtNXMR-5?_+P zp5yRDCIPM&e)aj-1ML)P6ItKL*iiWDXOKjlDyS} z#Wgs;Slk*?Y}{vNneOQA!^#-BbRxU=%z#9?jh}7>-u!h%f5{Ul6sJ$w z|A<(`e~F_m<{mk+>5bdu4wK~Q#o$d%H!aK!w}!~|=5y}pL#+*>CY}1;npnl-4*{iH z`g#-&5}};FVSO#|R6*42%d7e$mJ@RHmcT zQT(W4>G$EXfrx((*)n?!sq;SovFtE@S|S60DG2k7bSn85yVb8OLt}v@;7o)f-Y_m+qV1i6b_O~AGw{e6VWj}90%GWj?wS7(GVnLHA zlr4)iGgm3T+wBQ+Ogs;C|%H`q~R^630(d-FVujgjk0mV^GHq4luv_oz$) zvHIzUPxgVPG?g)s{ajg0jN;ep(_D^&;|XDp9r;#e)cDbemy|_k%v1kGFJ+#0`ctq) zJ5G1-jVrDdEAFQ)l?98;uC4o9S7VNxmj?*1la2)nZJ*;d3N=|oIftX~o% zQe59fyC!6E>k&Mdo^#)g70ati%7t75FM-CU7s&U??K$o5gA9s>Dh>;OH01}6u{&Q< zDJbBoy^1FaTyK{4ufz_%e3O-@j{|0Tkuv_M95U~6HWx;S%ST3y+#EdFW$GUxpIz+% zf^KZBsk6^LJ9lKm>30v#)jYe43*^>1&+0?Vtpmc()An3lT_lp`){V`bI+~}5UxG89 z<_tQF(@P#S$(MQH@Hs8qZ|9kIaO0g6a_lXLp!n71KR_>1BWt_~s`O*s_@L;e{UqPH z7*3gx4@hB<@<#QmNAp#wZ9j2?m3J8tYqX^)4I|_A!PYZdRqZaALG6#^IYV*e?0gLl zrrQiQQgjrRM<3ZxuwnfXf&pTEYq-CI;9ydZYsC_JA5L=N{IurKx7EK4hIqa5o63!{ zNBgEU%yXVvJ)>hXz_#_vF58xdd|fU>b5D8x(B8Qq!K%d(Cj#8x7B$F@rciCB#i%lz zZo1d|`{Am=QSuJ!0LqBv)jmwdj0vJVgDz{rH&229QHw|JZHJ81Ue{gi6&m!fx6`am zrFSabdWhW^+8jHZY(!jC643jbSk>(wutvMFqdISY7J|*+4b&Wf4cMOa^n^Higm!Ma zHD;}o?zRTim8>YfXsG|MBUE^wRwu#`pEZaErVUXDLk&%zBpJ};!?z|6ZR{3|b6gOA z7+qR}7c|0lQZg)_*ffZT4`S}xeK%RoFLqa>0v*bMeA5Kh4ko0d^Pa zg_pFGC0j`9MymXJUEku#5=?Te9D-;Afe27p_%Q^U^Pf2|f(}2YA%>^5{nC$K%FmiCArylwoSkN(AkXG4e-n8ESJg^#rK|xhAX+uwccv zPk(~SX3PS`?&L5h7kNNZq1USQwdScs?P?xHxT}Ix+s-p^|M1N_&< zfTx)>y4)7v8Df6*k2D+3R@WZLa$mi@Gjr~B@wcE|Aqt*UoN3xyIb8bgmi*Bb8iA7< z`l-}17L2$TeEq7z18Su%CEdT0a{jD!T*Ii7oyLvUPn7%nRG!y_{JoLD^~7_*e*nI{ z6Ra`*nBRegcfxl?ZNG+{fA#CoE-3B?P9PeUh6DR_zEHmB__4XU@}eX0td6y3l%4fs zm*(xuvU>B*C9v=kY?vCnm(=OT4+(33T}9)MXE#5JsZ-C;A$%r=A9nc`2GE2n!Jc|C z9jz9XecYPe@&B2^d~sRw4^ZUkU%oenG~PxHQ5ok~)H}y-zCU}`7#lK4IY{e6(RWvT zYlrq`gOpfrY}6IKsFHmXNfR#AwylO8qhT!@$G_d?Mb{*wIofG4T~p<8^9v(ZfxTG> zcP5|bl#8RRK3wT3gHL4Qqg#DARX$_A?&w|nXc>eb@FJB1J^r?7{r!3*Rd%Gnz#c~y zgTcM0{%o(G?GY_*j0gv7Xv}M%CV`wGn7@afiRFVnPU2~$cZMwOCy$BpCS``qbi6GZ(3$fzUQdhKE}W`}cvs^{8`?j@v>t+0ofcEcTh# zEdHtwe7FlI)i-*7(u#r72V{VHX#ACAQE*I+oLt`}*#|P}>2C6w9B0s=L&T=8%@VO5 zvkz+UJfjn2Boqwwy5JAaU-_c{rgVBE^W|D=E!8BM0L_V1*6(~vI-Ypk>bXsA@=Kn2 z(;75-<5q4QlQw(=-^J5TWaP@yZn0JU7=F*=_=5x;ehbXi(%4q4zS(sO(wRFx7s4Bh zt4=ii2QX?nKZIMQQ#mc-kr4M+^IeWUQR7$Sb66>r-G>6z0ZlFBgv1`J~tF^mVTd=f<>QUocmuuIN+h0`_^Oe+*PNOmXZzX4$E78$KbaQ16DW77CoUfLmzxFXiCNbT8Fc+sbfuHg`5UxwyvW+OxL`70 zkFLpRlGdv7JZfZJF8v44J$(+-*@GeZs%IwC)gg75Er}16a#gnPeO<@blzoOm3Qy%3e6g@HX!*i8gI1@AAcGA9 z+AGS)fBY9Yw*(K5T>lfWnZQT`D$NT_Cw6&Cls0D%vCCTTkAcYd(aczlUA;{pXx%-^A6c z-CA5J^O&EXVWDcb0{_6x9@HkoC_mknKz{{ut&B;-olMHR-Q6EI9)QLD#)Cwn-Ttce z$p}ZFE2oqCJNpFPPkjZ><6@HnOYZ;a6L^@a93~rs;!JL0r#>$HIB_iSP$preON^SI z`o&ZBPX1VHo>Y*YV*x>;o*2Rs->M>WfG9!~#4-RNM8d#s&6)@D9Td%S`*s`^WLuI* z?Pf6!BG~558^H~YpD;7O*sVTm9!i^>eQdkDv~HfT{enj851ecWg+=WVi-xQV9Dy+~@aKO$$a7&2$mwei>!-iD`G zbsI+n?0AkJbbf$(x+_YBkXp%H>Xi=)Qr~j0YJIs5rBD}A@QeX@U4K+h<=ngY-oF4{ zriL$WE7I#kexo%ZNz;M3aMR6H#!|UbJGeQ7()y{|e>5#HvmEOd8sp$l;drx`UwE1o zvp#ZBQr)h$&a_S_XQ;M3ls|{>lYO^?bT@{G>QP}q(0aOt;Bx2gjbb9!82UKB?cW|smk`0 zj%dJe`1!tljB|Qw&b1s{JggXdn;72U&q#O5TejK0J|;PIGTw`LB-{yir4na$ZAIWm zI)fyKS#yP~dJ*T~&xR2{rKvImqGtLv;Th=kmxyJ4qR_rsZ*KuSZ_0W`X;DY(oG68P zVlN5f3h)i#O}K-dn!M7OIc@J_)TVhln!;Z>0$F~PQOdR8FQmq-u+*^~yCaF;dpI@B zNVO_x9#A#1aMkc*|zPz2)uxQgqs0t3i|>g*BsW za@-6C1>aYfT2%vo{o#X{TbACfS%;D05Q*EMJ+fB$J!; zTX|X5Cx2YNx>lu;_St5KmEB5&1g!HGGh5fYvx?u{`cRW;aQ3LL#sfEKG=z)Lcjv9W zSth(CNIZpe%364oMT8AFaJ$<$p~0{Rdp3l*rZWEY@PL%7GaugV-~3!=ta;GQV^c1h zpv3h~m#E?L7w~tSc1(e|I*QkV`Shwq;FM^OME0uPCg*WYTOI{P=B0DLSlL2fe0vv{ z85^9ff8m`grbZ$QIETGfPB-UpZrAF8t`y*jFpiKXbvS3oX3z3j z?{JXk0k|q$@Wyjfcq|Byp&CMRF!j}}K9Z=L%`xY`vENw#wqCBeUiO9oB=Eg^@fP8{ zTsqfyMcLyiYcK*Y6{u{yhavbb1G4|!Bqus!+PwFO?GlNR(DD!JmYXHUyR`Kr%$#gL zj=B2PmJxErK%`Z-g1$6P&|8pQX_lMRm*L<_h8p$sXYP}Qot#xr}-aj9} zBHqT3gm~$(1Bd!ByBUu+%c`e*Y=Z*gfN~=Fk>^oFY{4ZDYkNyenw&DCT`PZ*BYqdk z-jONY$(;OMxv(J%68*;2kL~+aFWB1#ba%bRlC@e$WhHMX9l{fl26HgIwbsKmcP1k| z*bLG9UfwGtIMknpvbX8xO@|NE$y14x8y=M*yQX+N)#d%o#4q%9NC&cwfEG=($dU9Y zs~4_{;j_J!uAK9rbp{-O)bVi=`GYqtE&3?4AvBcDQLL-OIt|6{`3x?|*N2uC~yO%9Un`8Pz~nLXL}!9$4UpHT|4jxwcCdT^&P)>081&ESZ3FLXP~e@_|y z>0J_d(r#ap1zo(v4ou{~woGNJJD0E3_t*PKQfIV4z(AFB%E0kuZAp5s{#`ds;rI2b zVk6WK)&;YBmXpk+#og9BO@9;bgqk4xg1d%mKb@0>YmCV4awi(*@TIJ_Dq_&96mBxU z6{m>fWTP38w;7!|Z_n{{TFUy+y~VUDx6bS|b(!;W&rVqwcgu|7MmxyQ-(SY*$1fa8 z1Rl-d%cp*vQX+}!p#+yz%@AA5y|&nm@!ZF!-IlVx`Upl-hJ!l?h20yHw8d zt>q_M;Zc_wXQ9JywcVE`E`{~ZXs&RbH`^7!J|)wex9$No9+lRVC`~q2F(mulr=kB* zbk<=_wrv<6pny^WuXLvhBb07lkdP8l>2e_8=rOuc1`?yBODUzhQ(`Dx8*Fq8HoBYl z+xPEt?0Am-@f_EEU)Ob>zw@dFdF9F=_0rT-xM*w;f(J*02@8XKsPc1%gp~U(txsU0 zGFTXSyyNh7;tFH0*^-%u67QjcX70u&TY6OJ-v`XX!C{PdLQ_z+m+5D3ubGewmT^hT z+(q$VxMGtiVFSS+%XE5D3v4KdJm2x68~46?*9Y^?fJ>HTovz`bjl}b}ci5c%3^U&? z@UeyTjDFRWnE3qswi5 zW?T>o4VciK`SDgQ68JVNHB}?ih(jfdBdpRM3)AM^YY%6CrICp|Jrnm$$;|ptEzadK zw+$zXmraHZeTvD28Ju5_=l_2*d#UGbZMb0LE?&pS-eyKKQ7(}|U)p7j%KPQOGVY&1 zTOW2c&IdE_-%K8SSdnM!p%+%(TjEyM+&rVd(58D>PUl5?@dR^f{&12AQSq6WqO`JD z$0Dfvnr08);q_D?59Zmo)Wlgcp#T%Hb@n`+2zTQ_MxA zUj!3HeiWazYTY>k;iX^EOwlmfIZnmt4#!_pR)V&DrYT=Nku{OLa)6XeiZ?X;@S@}_ zSlAQP^E$99tZUs??XKTlT%I(W6@0A#P*S28k`q<$t=mSt!>y*8>Pb|iEGs~tgTsT9 zy(Z?vgeDGy%TA=G@8`(VZt8pdVhdzmAY?-hzz>Tu7w2RsJ*Lmf*y0t?9o!!XBdidZ zXC2#IuFR;(Wv2t@Pm=tMiW`c}=1WH%B`p^XwHr&$Y|&rSOZFmH?-YlX8Pd(t*#$6% zS>RAKG<>43Pgl1&=do)kA>M7H5dqLc%Ct2#r%|zrkJ-<8C2+>8HMW7F_VGMKKpUVi z>NwSrfM*ZLn@e~251@)i-Gx8Sd)ry1*t2AdaCS69KLvz3SWi@VrRfGU{td~1U4+%k zl2e!LaDqeqSqHLIA*zDt3FTK_KsHrF0_FAlBtOD=2jacU1wM%g{0|Vm&BiuRpIlp< zgYX$=*>jKDJZ_h{5cHToPat=kiJdE>2+H5)@7(3{&Erp3D!;YjJkN*>mN^aTo&5zh zC=KF3v&{$Re4SirWPPb8cce<0VM!bp4)%(k`a<*Kpit9<5dHHum)@?3%FLS(+-TK|AYTJ}p(Z_oPP z`rz)b%|D=9dumC=QLZo`S!(yp_f{Xl>*jCk)^Fvk9_N6o41*re&s*fgx->M5lkB;M zjc~a$LgA-A#7MGOHk+w=!?(DSJrU!4c-?Kl)zH_E!akKO0V82Y!SAcIe)FxpupH+J za9VDux~Ljl&I3Ntr+wa^mj1be*LNe~CKq-GJZgSn!{%`>rbCi2v>?mG`FdkNqV)7c zJs?5(#9H%Y)Kgv1?ORs7vO$PJ(VWTb8HR5A{$ubc>?Eki%IQ?4p~HEP5U^38tIfS5 zw|C(u8h{%U?W@2v;l_B^-z(qD_K|7`2;?0|{s&lBpof>4ya_Stcl-|!T}1$iR;;IK z-oq^|rJ7q0QZ58ui{l5CO?SkHL+2;$*C2Z0=@l5w)oXyo^13vhH zmB-D$+ez@G4bN6V{fdJdVUPUrDeD7g5gokftNuUuAPC3JrwW-CcjTNohne*JtRuvd zQ{4$+zqMcyW-jQQ)2$tWu)Q>cW7M%6JTEB*5$N}_`TLv$9`-0FVT?L&@jZZn0GQeguM;`_EHe61UI};EJkM;{C zT@!g1703@!UG{`Y*dL#2=0!^`vHC}nD3b%Z`$Gh3R*=L8yE%PQNe`nl=O6hFQz7nu z9vO??0sTJ;gs6k}ddv7{7C=_l&x(J0ff|z?bJ;rNkPX8?p9wk6@Z+jO14s?$%$43a zYITEz#nXqtY`ZyO1Rg4>rS%_1Yc`-g`ojPpN`S2uPmxG{|UF!#LX-4U;na~}L6OmZc*#y6v)>#S6 z2;&$P2c44y?75#^gyFn)rY2k@Wh<)|Ok$`91_j|8L0hH^R5R~43E+x0XR3VqRmB2> z`_o>V4JS>O!&m%=%?zAQ^rKU3x`F@HnON$4Zb)pFQ|vx0(7Kn?W^ibwiE6b}l;1AV zbnLH4u_JpAp6y1+%-MUIjk8|%K+|s-IeufOVkZxcC`pkNQA+zGRNvC>q@GHyo-9_x zhv-Zl>DbWbhqM%6ICBhETSXG5-8s(CL!Ts<%!Mm9`ZG1K2!!WGFzug}p2Ogfl$86L z0>ZO<$^}UPr;R6RMt8!XK8RialW-6>_lG5=(h>~#nd7<1GV(_I3ogW{v-HD98`iyk z`;8sY_JSpUU&KDz>i3}X_K)Lie4MPP?IUb+xD3fvrxnGl(vQ=5g|GV8&p_EMx0QA8 zkCq=CrqQz9ykoth=>2|iZFaurG}|lay2jtRQi!|jHxkU3N1wgjbQbl+RLd}n^Xkz= z=2zA|yOF=|YTvxxurf+hOT=oiL{i!D`^QeXdywLE0)Bq2VWT@5Q?od(jaqFZ8d|0O zPQ=M=;6dpTdeTSg6Qqah-to~ZDu-reTs?%Ir7;k^kg!dsyM8qxyoQhtr#=&R(SGKf zmOJ+(iXpWgeBBDaKW}gML3s)yg5Yl?UcUB@LSu1&?JDKfh5%Qs*bQInPnUM z?!9CsJAAV)0Z94HQrq=Cy%1DbDFc!Vpt&n3`M7t;?QyGy@2HnC0TzE9GOjm?I^cVVaO{|Zc zu7nuZLJl2PmL9SBt+DyZ8ASa%W}fz7VdSFf#_A%ZZ+lRm!Ya zJcRj*7paKlNN@*)Z!M8(JLdI3n1e*+X-65Rmzm5S+%?ZHwTphlKL&MFQI&qRcxhyF zP8yloF#KG{ve{{6l~HuY35R5567Fl5F=4{izuo;(0rYA<SOO{?H=G^E&zmjFAG0Uj1M#2WPi`{pYGJ z`dck>qc!GfiG6YVr;LuCzbX0t32Clbc%ZKRr1Nr*DIz`*fGK)Dpk#8rU-Lj{R)!3^{`_$f}>K<*c49FpDE&}(T+4jdC3{FgI#Z_%|?#myF zUSy4VCWnSG+w#7VwjePuT&10|3LDUNwDW?Ed$%GPT`BJ|+ls7#>nF*cMP!=U9M3<~ z2q+>|NR4Z-QG|_`-bzwK&@1`p9wzU~!B4{)x@EMIE4%oq4IQ>H4adFz zW(BlzyAwXP_?}WXD&7N-sf`Ha8-jgC1pWOZNR_+%iEJ^0wAv@|>)b$j=In1KBF7}N zCHN#p=y^4U1KAkVC%rEeoYc#Ql*%ip@0mh;V-RLqNisxaedX!!pXj(V_c&UMmrd^# zWa2E8Qnn}f+6*PpOp~nUSwCqlU3nx>b5GnJ%Ut8_e7Hk{RURX)kmBEGa8>OZT_NYC z?<0sMFN95~oq$&soU8f0sTLdzc0#XI|0r|&6n{G-z+p8V zf6e5*X$`vqa>tSA1;2W{wx$J{?Ov;|CgNi6#gQNUD>9W77=nBZ214#N^bu7?%Fq>G z537GJAxegIVak-0oHg8YwJ6(_J1lQflC-&}T!{AE0qu03ShdeRM;`D9NC^4h$KF@W z$(*!Q@MkSz8yh9|h(^`fQ011!C$3K(W4Aiz~Xz1dj!!V7#9 z@1`th=;ppeoaBeo5|sPeMoX+=Ht)kf zw4!=Web>tBTRDUS7S>ewny^4=hcyheL*$)Vy&!xtu3u{Y14zof$Z9$h;ne~`{{gXU zDX=FGPFD$ERUn;u`yigoYTF<-DKxfzPvjm0EZCj?kdCp?mb9}LTtcpx8%j+n-Y(}u z?wu$XZDwjB%s|HWz9GLi+Fk>&wzZ|Ydr=PmW#VQ1V;d5>!-00k6`o8j|pDiY{w@j@2KMDdCmpKklPPNUjV7G>k$86=w zlkMgAoS7Ul9^dv{TZOF76P_rPbF=faP4RR!D}QQ*&EzI_B@Bn+#03NVV6En8c3?O;*az90-YV7{-U)&CE(WqmcD%n2+Qz?l zM0GG2^dq;61fQlODSmcxqp3}58TYmatd-}$9{=?;4UwI?=98E*?Sb}HT7Dn1PjxJ5U{2*IhWmHpHd{xZ4yJjcJuCYlD5{C6oD`O zE%1yGfR&#lPot>(wfalSIG%%i%1K%L_eWLtgae`H6rW-4Z%a=FTn7S)y%couyp5%k z)J7z~d=*r07;~-(pUD9HRbx;~x;^Y#xFavMx`Vr&Cj8i-!Z6}A4ZmdQF^jLIVg#rX zRWvqnC{%i$WDcpRsj@f??o=zUZmeND1&0#x@E7|*FV;SHiCHT=I=kb}6nyoE*Xm>M z@e zy}{-=f>o%|em7G;4=#Vokk(6(2m`94T_-6llvD0;o(V}y@hK+lJ^)*gM^Dl;BO*Kf zw<57kI56%xQ5p$QPJQoQBKD20dUy`seCB|ao-3GHrl>eSD2jqb)lmeja?2Z^sB}xZ zl*S?)QvMHTZ3o7-|A!eRGXSUF#w-i3KVpbljt>0@(@xDg6UbuH`;v?0ZaU*Wtbdv`A2F*dYqb1*dBsu6lx`$hPDCK(Ao#&qC z;hL)ya(}u5GR~JinoqqbR$zB+W6*5S=9;U#^Y*F$gL5Qg3^~h5A~aNAoI44PW~I0* z4_NW^I%q0;}w<{$%4n{VL$VSVBB;Am&6+&|QHEn~sCQlX33}-(XjrBUgqluU)Xl zW?H&qyhX=q8ODYK74F47!WAd@R>c9{@80#kb?xXS(4mTO)D2NAs&El6Pu>nl0K)xN zptBi7r%k;lp-GqFD2)Zb{i-BfC+Em2wpvp__5ra3&lbwiMux4hiqh_W--V-sq<>f0 z<^2;Li^%e$-Czk>s|uKQr#P6k_i(bl988Optr0 z6lO$IQA*F-9tw*V(y`EV&9YIb)3@h17!6(sy_XJhb&KNmi|2 z(drN%m4QXiOB`C|K0F>fEScIbv<MbDveF@=h|@EL-<*x3>_ke;P9p0 z_)*Ezgk^Sh2{?4wo>J|F6FH=U8ohP^lshX3}u5V=Ldb$t1B>>f?-|9<2N6b5Aj z1H3!p#JUZd!}5WsZ`R)lgpYzrr_p@)zi15TUNmcDxzhd0)SF}|S=+=A#ICiBi6z7< zvS!UunZwrYsJ+kgsAeR-n4kJd-h`Y9st)`uJy)F0d)`;kO?8L?Bo?a5C0R=nKe6kM zBw8ElakQ{-;!0ysVlf$D<{z2bYEmUJc*g~&e)!r%5m3tbVYoPt7Uxii)US~-B{APw6~NApCT^NW4$j2 zPrWf;X2{;<%VI31AQrstVSL9#y#^x2B!>nuLunV~vKK4jXZKnHSNGwxf@Up&NpMCD zCF@)TcprDlT8c(Ch|eqAp#l*iK5sO5`U7R(GIEb<-)#b*?Fvb_Kf9%~mB5GUF z+NH1~J$1i|V>63d$70je^ol#)hKjYGg$WC_T-5X9tf{q3Y#AP`gc~4zN;x~$=?JVT z9}*6osBM#!Srl1rPQ18j?D#gblY6QQRl|;3OQH0v4X!vwel2NpR7vEOg)F6_APN);6o-->NR8}>V<0vkqDB&t892c-v3Mx`yAJb5t*u)!arOkO^N-$d z&7o$SH3K6fq5C9<-|7quhdR+{%XcYr&>1 z0wF(q95^a`;}fehL#G12#|H{7==^pmvvltQE}fT)6?Yi0vE5al%`?%B+W_JUg2Cm* zC5$Nf-W(mXRr4m*lg}ZOd#wr_WmzfsS%@`6xRK+?g2a4>z*?^t3*#|UqDZK1LLMRF zD%s%o8&17ufuK)72LB%t_cDli(fes(W|zdpi^v)KqE&3ispQ6&>OHjx6|S+4&S0Um zVI2FL(JU)8#uhO=+%SA96lNYN>r8z208~#=_;|s`sIgjF+T$$GabkziAt-FGz6&h3 z@SmOfsC17$sFJ!cBb8>dnno)8?83c~AQjv?Zg0=`#oHNh4^WQ%bI*auDqqRcGB5f_ zGqZp9kZB<9;0E=FZ=0Ku|s_i<`TR@NA|I$OY2{- z8HylrqsWpslaF_J>l|w?M1+)tbxlT)MavnaLEm9X)JKy6gMhPlSJJv4_0G*rM2i#l z^=%ksBIpZg9B*RmP6At3rct|GgqJ9Rau+Go7#SHKeifhH2Qy(?##nXoT1G|DlLl93 zX75ghLnxchkwCG|cXTpdgB(D}@nt6@e1c#3T? zxF{HcDC7?f+h2D&Wql+5^yc(63+{%AuYB!8);XzInwpOK?QOxk@5Wkf{G%rxI=$94 zqf+&%p&!^QL%$5oot1l!%&1xL=o55vnX3%%!P_ow5bgA^LpdMI0V@%1cZAF1Ys=ap zGY)OYCys)!M2_VT>i;eu&jMRZg;*`^WEWWuZ(eOGDIXBlE;Ntm(*Ll9A4VJ#hA&We zCGi8co9I~I0mr|ei8$H>ej3FlO$_5gKK>|a(_uro(Qz^KOl1(97=Nlu1Du?QeRQI3 zh#Oi?ab*q(zRLbJU%oOcu>ris9UqsxA2HJ$&@JDwh}T-96AVQd&`uqGTDwqk`oOGx z7A-+^XZbcsn;`Mf=(WNx{315LxVifjsegdd(NYMy0&be(s;iTPkSc&9f@pY|fz(^G z6j?28n#UnQdtQ9pET%zR#GTaa8<4veT;!v8aA!^`L*s=|WJRclyM0I2KO;0yEOYoS z$18oYiB$t4-N-Q9ERwL)46eKG-5Ogr1P!|LuwXyY#C|FOW$WfR7_@w}uw|`$YIP!` z>p#2iB8Py}Fp~Y#!)p@H!r4y!f8>z4@8$H`+ncXKh&J}$HQu~A?(V|eBi`}0SCB_* z*rrx#RCbKjic7_h^I3ADqN#aLPDH|`h$y1~+FDqln=5o#<;A1rf5+>H%S*0KKpd)g=%fwu@A^AL2qdPBqc; zBB$yb62Kc(%34h4(h0^+2YV1s@x#F6=c{LahID-Pyv+JGiO^f)B18(rnswz?$vXA3 zoibA2M}z~|ul`Qa$LI=&Iy$H|x!FCj6Wv8c`OJvd%_ z7igu_y}g2wcExnGb!A`4pYI-B>8SE0%Op?|dkJdg^@}HtYx9lrkpOZYOuU#^IZL37 zhpv}qWH6n!)_`UOr^9fq2p#i1AV$IGy~XA*X%|jH3qw1P_dPVZJYU58@~FiI)Mo8s zx+iLOm;LZj44I~Vi26`FNEQFP;lUrZBm0gy2a3`rI4~5`=(|@gJC;rrGU=Gu6u)VN z_&PY+dg!7rWog~Ur{k>!_M+Y8QGVQe>sOm~1p)W24k8UdvE@-B&EfKM_<Zhf8;2^JF~ z3gHSft`Rf2f1SuC90+EKx6>36TEK9dWT2Obpx{7tpz@k*;Y-b|{?7&~GM=E;wruc} zOx}hY*E0v)F<1ZIpT>n zz4fU3oyz`XYTG7WCSzt-Le!2lnY#)4C0mZ_XQmxKO2ZM>xGbpauUIE4K(9>BFt{`5 zPUm@c*)O0ZVPenKfHBjJP)Njf#IPz>x!X1-;oONEW%kJCQH>8Kdf)lSWVr|j64ITU zw=^f&dK)aHHShvWlM{|kRdi)6f0=wjZ)5rVV}*fUjFQVD@)q^*<>L$P5Q3ta6xf9PKZ((DqYvPm?s>7}7;^+;hH)7x~CxT(Y%b-g|y! zZgTd=5q**SfDnW7;YEy1GgB(;5z%;(;_~5GJ>eNYB8ZUvmud$ZcdbcDT>xi}cava! zjCT(eH!z~#7&}NA(+KCg)&pM=yVS_8;&nz6bL)Z{`9 zsNYpq=TNLAOQOeTp0xr3{Lnn0V<;+PQ=gIkPRc)^marKt?kb9ah$PrVwmNxSFHY7I zN|AuWht-c;N+=_aWdV{Q+mQ>{;QPDU+StyFj4uJs5(}oqLoCbL4V_tqXY#!* zm!e8nV_z4r0}UhTVqD?YWg0lSG3D?X!tZkor_p$F(Z}-MOHTaoa}{v*)GkEc$Ma-T zolz?)<8AFxdBrYO04rl{huNkhb`Rymvi;+QbA3$(#uk#!zl{36`cWk>sVHxoj)Dc- zY+oIX5yxpZCA3xp_ak=ccpS7c-X7IDgEE=U8b$5>8%8Gxe?g;lD;6Ux43OLybv&oa zr zsBGZ?or-3q;mo03GWW+v0KQn&k+tlo)Jx66J>H z!J`ykuNq`7=eE99fIF+LOT?}z%X25MHr}*w3)O=u1IY~riO@-qVfQAsLv5QL=&d0R zQ3ZSMQt?&OQEhs+=lJE)P>hJW|1%8$q+Y`zY(V(0jDi!rMV~jAvYIa#wJ=b2w@wbR zL$lTQuoU6PqurK9tLAtjpdAI3(w4U9tOR!9BTml@B3b9y za3)XrEZwnZ_SF{dP!iR z>A_p-83UY3Cl^?_7{&Kkf9USs>@s?My~-U(m7eme_%a*?B=wHSKQ>vi5PLR+TWw>R zG9Q|=QEmgVP5QYOBshGl_^dG?=E$n|dZPQvdcN!wx!3EAyVBUEU!&;2)~G3QJcxf{ zCq~CXm*BS9C-}f*R=-`#f0ETUr)b}cS&nv4wFkU|&ku?JVv4hEf|dSPi{!{*Gu~hM_LO?;dgUSY_V3 z+HzdFqC?RjUQsIl06ar*WKTyTL@IS)QHje9ouxr81r=Tc=uPJqILPf+D5oBlI;&*% zA~g>lzM)L8o4yc*ZKVB{{qt5`_tJF8X(hFoae8g`!dJHWdA2NdM__|*X1QdWdo+ho zeczvtmU{d>!ydN6@oL=5yR>}Jo@KDEj{VmhQiO#>ZC$NAsu*Cr96fLc+(b z<<8r+7@@)4(DPZ@U1_&so@F){Jw}KCcEnq9@8GEs9>0nf8)X+KyEP`d^d#gsJG}gE zLG(Yp=3jip_F97~KvCeb1vv!+7-v5;UGZV-tvC+RGOC2_r08aaIxZT7jnjO^1~=Sl zmoT5&pY)!|SI~%5w7vr>XVHN#J}rg20S~%j0_oGp(#WzmoCC7kyW+0GV*<}=+5r} zlOayrYs7n!b2o4%>Q7vo0W>WATF2^&#d7)Ws2;HTqeH{mA`72pVLM^P>W6utbNO9bo&kt_<04-ft45rcA+)hxS%0f@Yiiv{XH-x#)hJ=mhFYuT{p+kB&~V)FMbp+XM8l! zP(c(2whxV?X)+|iLWSN2eS-Yt8S;_;m$km8ubTFj>O)BX| z!+Onfcaj0;-urSq(_>h0jk(r~UyFgfDh96Hs)HZb#cwpTvyVZswj5R^Pu=_G1*i*a zJT3kMaMMH|Psx5KHx>cO>S`zpe{PVIwKS)lrs~@hss2MHK9Fb&iRPey6nuyc!t9-y zoC7Ai?}bY1cA*ynAR7ey$4JvtLZ|o+vc2VVo_G<)u^{#aDnC5Wh+*$dQ!R-k%@k^l6<2VmXRm8`W<}Q zx$7UfZ6MfWA;L+(ban1#K|-;e)_n4=2AVc%!o<|aUha1}R^Qm9%Ql5=Gp$>kev)l^_=ay5yZ zHLY)*xO#&kCSj+OR$U7a~t(^=K;tB{mR1j|e|ER5nGwS$X*%CT~1u^){T37<943x7R zV|45?+YWzmmx#SgKfW2UPnEUsbENMjA9^Fccsyl;f z=PuwN0=lQHL#On^ZT8xSE2+@G3-4aSy$Q&JC*^1;dOB;8BL${LxeCc#bmfAHI0QR`J_7kZ4OHO+($@tbrV?Ht0G!^(L zU(|~m$rzKfHCQdm-x(qtq)UBI3z!Ekbh)zP{AM$eV^5XJ=n7VWSO~iQ1{_RT$NsQ` z1`I-;HU3_DJBvgkneMl7UHftR_}(Y0fC{X=X^6|U7rwWo$;k=O5^t#)%0>&FB ztgHz2YtOm+9uL+@y4AOYYv(HCX)9X?@*Y1Hef{;!J1O|^;gdOkX=i+3K~wl9P$Vcm z`t0~<>Zrnb7*~OOKz#*FUQ~t&u{V+q-tHWL{e8caL*1?-3u^Z^4QCb#T@2x zn!^Ru)8!+lc$dSMkBtm?43>yqHnj9fwtwT$t&M-}-nX_I3s^Z~kvuv!<(9cclRXma z)1-L=q6>MyJ&@3Mc5hJ;<$6_vom0ISx$ z$83Ig{Ia=}^RHv=yqCp)S;m*_uzLsOU1Sh4A^hrY-gu_frFuU4vM@1emc`{YqhpT0 z)A8_(tFy>lc#rD7(y-ebKco<8baQ8q4mVbVO>Q&o1@sQ#Dk_0?5AMe|V2Y{)2u@}7 z%CQo8_8$nn_hJ~+nXGO=PES6gU${K*ndQ^~|1OwGSe6)(19K|d6~0;Jb=GWva2g+r z&8eB{?bh4b$?gI9rHY!oDBif{D)@SNL(Qi8K{ln*d!INC&1RKTLIDH zH}c=@H!_DpAIk|Bj9SVIj=CJmgSLoA|POLGC!3|pG9@cYJvMlokYzg+bKh?aC>2;>9gdn1F`MYs75#YQN={BRrAWR_4*EH

pO4z`-ky3UjPGMJ{NchpQitd9|oph1yny4{F&;* zq`W%({L6<`0l)lpdZ^<++_n1vRj9^u_4t0EXwm@{tbf@Jo?<@LtVzW`LCxFIe|%f{ z+kIGo;cxqO0XCTq-nmr$-Cq6I%{Ttl9eV#ddcqq1w)*G8zZYQ84_uTXNV=^zqOR1x z{TZCXy9mA&;N9bK5p%hJ{No?kKPc>c+vW&C5OO$~BS{ocp!a`<5BE*Hh;c+B7270AAUDMR0W^z!>IF6#~GgUbCR z69Mu+kjkJ-36P1uij@44Clm)#LJbL0qzLi5P>DD$<-X8kBYJ1^5P( z;AMS;Zy50^ z4Euz!6vY6W`-U+u>->iCFAMq!<9Gqg;tdmU9$2lI+7JV*>AV?5n)y_4&ywo+RimZAq4U=O0hu;6E?l+EOG5HqOue z0iM3|il_0{PWYLQCP2l}J4S-@2k#j3bqodvS7pD^F$_p+y<^;KBY1uOUN6IcABThc%-%6DnJ*a2etDK0Cw!SRPrbJA&tvfP*R}D#d6ql}%CX81qUk{<;p}$ura&UjWA8Z+romfWOHL zN$?D?18@EDEI2Cij`8n2AW0T~=RLs4m*ezlek4o3?iv4t(H!|YCGv*x?=nf!JPU3B ze4`VnFYBNM`d!vY1~hwL2LnvWJMS5SeZ?!E<^t|`2k+J2FyO4cuY;j@`U@RReOWI< z1L1h@k7j>E_eFL|h8A9xgP-RI7WZW?%vZiJKs~{`(WJcpi90 zZJ%KaVT$JpImRK_K64HYxl@o&{he-uk1! z6Q|$!_rl)!LgC=Kz488qz3-vm@D=}V$6wgH&3Q>ZxX<&`+FsZzX8M(X6izejo4&oU z_k9)Yc+_t&`kki~&c3b!cpHNy-}y`dQ}=E=U)Z}1qX7Hf?bQo=-E#1G9bhYadu~9n z@UL`0V7~B0Al`io(3bqlXW@%&2XtTL4`5$x`wRQJUV;79Mm%or9t4AbND_#j_x}Q? zhDa7f;L1$magTr5Xqs5FE>F3%zw$}icPV^D3mzlL(q;_|`v%YnobR!|FW?Mt2YuIb fi52O)xa@!^4; + + + + +rfc2445 + + +

rfc2445

+


+
+
+
+
+
+
+Network Working Group                                         F. Dawson
+Request for Comments: 2445                                        Lotus
+Category: Standards Track                                  D. Stenerson
+                                                              Microsoft
+                                                          November 1998
+
+
+     Internet Calendaring and Scheduling Core Object Specification
+                              (iCalendar)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+Abstract
+
+   There is a clear need to provide and deploy interoperable calendaring
+   and scheduling services for the Internet. Current group scheduling
+   and Personal Information Management (PIM) products are being extended
+   for use across the Internet, today, in proprietary ways. This memo
+   has been defined to provide the definition of a common format for
+   openly exchanging calendaring and scheduling information across the
+   Internet.
+
+   This memo is formatted as a registration for a MIME media type per
+   [RFC 2048]. However, the format in this memo is equally applicable
+   for use outside of a MIME message content type.
+
+   The proposed media type value is 'text/calendar'. This string would
+   label a media type containing calendaring and scheduling information
+   encoded as text characters formatted in a manner outlined below.
+
+   This MIME media type provides a standard content type for capturing
+   calendar event, to-do and journal entry information. It also can be
+   used to convey free/busy time information. The content type is
+   suitable as a MIME message entity that can be transferred over MIME
+   based email systems, using HTTP or some other Internet transport. In
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 1]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   addition, the content type is useful as an object for interactions
+   between desktop applications using the operating system clipboard,
+   drag/drop or file systems capabilities.
+
+   This memo is based on the earlier work of the vCalendar specification
+   for the exchange of personal calendaring and scheduling information.
+   In order to avoid confusion with this referenced work, this memo is
+   to be known as the iCalendar specification.
+
+   This memo defines the format for specifying iCalendar object methods.
+   An iCalendar object method is a set of usage constraints for the
+   iCalendar object. For example, these methods might define scheduling
+   messages that request an event be scheduled, reply to an event
+   request, send a cancellation notice for an event, modify or replace
+   the definition of an event, provide a counter proposal for an
+   original event request, delegate an event request to another
+   individual, request free or busy time, reply to a free or busy time
+   request, or provide similar scheduling messages for a to-do or
+   journal entry calendar component. The iCalendar Transport-indendent
+   Interoperability Protocol (iTIP) defined in [ITIP] is one such
+   scheduling protocol.
+
+Table of Contents
+
+   1 Introduction.....................................................5
+   2 Basic Grammar and Conventions....................................6
+    2.1 Formatting Conventions .......................................7
+    2.2 Related Memos ................................................8
+    2.3 International Considerations .................................8
+   3 Registration Information.........................................8
+    3.1 Content Type .................................................8
+    3.2 Parameters ...................................................9
+    3.3 Content Header Fields .......................................10
+    3.4 Encoding Considerations .....................................10
+    3.5 Security Considerations .....................................10
+    3.6 Interoperability Considerations .............................11
+    3.7 Applications Which Use This Media Type ......................11
+    3.8 Additional Information ......................................11
+    3.9 Magic Numbers ...............................................11
+    3.10 File Extensions ............................................11
+    3.11 Contact for Further Information: ...........................12
+    3.12 Intended Usage .............................................12
+    3.13 Authors/Change Controllers .................................12
+   4 iCalendar Object Specification..................................13
+    4.1 Content Lines ...............................................13
+     4.1.1 List and Field Separators ................................16
+     4.1.2 Multiple Values ..........................................16
+     4.1.3 Binary Content ...........................................16
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 2]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     4.1.4 Character Set ............................................17
+    4.2 Property Parameters .........................................17
+     4.2.1 Alternate Text Representation ............................18
+     4.2.2 Common Name ..............................................19
+     4.2.3 Calendar User Type .......................................20
+     4.2.4 Delegators ...............................................20
+     4.2.5 Delegatees ...............................................21
+     4.2.6 Directory Entry Reference ................................21
+     4.2.7 Inline Encoding ..........................................22
+     4.2.8 Format Type ..............................................23
+     4.2.9 Free/Busy Time Type ......................................23
+     4.2.10 Language ................................................24
+     4.2.11 Group or List Membership ................................25
+     4.2.12 Participation Status ....................................25
+     4.2.13 Recurrence Identifier Range .............................27
+     4.2.14 Alarm Trigger Relationship ..............................27
+     4.2.15 Relationship Type .......................................28
+     4.2.16 Participation Role ......................................29
+     4.2.17 RSVP Expectation ........................................29
+     4.2.18 Sent By .................................................30
+     4.2.19 Time Zone Identifier ....................................30
+     4.2.20 Value Data Types ........................................32
+    4.3 Property Value Data Types ...................................32
+     4.3.1 Binary ...................................................33
+     4.3.2 Boolean ..................................................33
+     4.3.3 Calendar User Address ....................................34
+     4.3.4 Date .....................................................34
+     4.3.5 Date-Time ................................................35
+     4.3.6 Duration .................................................37
+     4.3.7 Float ....................................................38
+     4.3.8 Integer ..................................................38
+     4.3.9 Period of Time ...........................................39
+     4.3.10 Recurrence Rule .........................................40
+     4.3.11 Text ....................................................45
+     4.3.12 Time ....................................................47
+     4.3.13 URI .....................................................49
+     4.3.14 UTC Offset ..............................................49
+    4.4 iCalendar Object ............................................50
+    4.5 Property ....................................................51
+    4.6 Calendar Components .........................................51
+     4.6.1 Event Component ..........................................52
+     4.6.2 To-do Component ..........................................55
+     4.6.3 Journal Component ........................................56
+     4.6.4 Free/Busy Component ......................................58
+     4.6.5 Time Zone Component ......................................60
+     4.6.6 Alarm Component ..........................................67
+    4.7 Calendar Properties .........................................73
+     4.7.1 Calendar Scale ...........................................73
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 3]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     4.7.2 Method ...................................................74
+     4.7.3 Product Identifier .......................................75
+     4.7.4 Version ..................................................76
+    4.8 Component Properties ........................................77
+     4.8.1 Descriptive Component Properties .........................77
+       4.8.1.1 Attachment ...........................................77
+       4.8.1.2 Categories ...........................................78
+       4.8.1.3 Classification .......................................79
+       4.8.1.4 Comment ..............................................80
+       4.8.1.5 Description ..........................................81
+       4.8.1.6 Geographic Position ..................................82
+       4.8.1.7 Location .............................................84
+       4.8.1.8 Percent Complete .....................................85
+       4.8.1.9 Priority .............................................85
+       4.8.1.10 Resources ...........................................87
+       4.8.1.11 Status ..............................................88
+       4.8.1.12 Summary .............................................89
+     4.8.2 Date and Time Component Properties .......................90
+       4.8.2.1 Date/Time Completed ..................................90
+       4.8.2.2 Date/Time End ........................................91
+       4.8.2.3 Date/Time Due ........................................92
+       4.8.2.4 Date/Time Start ......................................93
+       4.8.2.5 Duration .............................................94
+       4.8.2.6 Free/Busy Time .......................................95
+       4.8.2.7 Time Transparency ....................................96
+     4.8.3 Time Zone Component Properties ...........................97
+       4.8.3.1 Time Zone Identifier .................................97
+       4.8.3.2 Time Zone Name .......................................98
+       4.8.3.3 Time Zone Offset From ................................99
+       4.8.3.4 Time Zone Offset To .................................100
+       4.8.3.5 Time Zone URL .......................................101
+     4.8.4 Relationship Component Properties .......................102
+       4.8.4.1 Attendee ............................................102
+       4.8.4.2 Contact .............................................104
+       4.8.4.3 Organizer ...........................................106
+       4.8.4.4 Recurrence ID .......................................107
+       4.8.4.5 Related To ..........................................109
+       4.8.4.6 Uniform Resource Locator ............................110
+       4.8.4.7 Unique Identifier ...................................111
+     4.8.5 Recurrence Component Properties .........................112
+       4.8.5.1 Exception Date/Times ................................112
+       4.8.5.2 Exception Rule ......................................114
+       4.8.5.3 Recurrence Date/Times ...............................115
+       4.8.5.4 Recurrence Rule .....................................117
+     4.8.6 Alarm Component Properties ..............................126
+       4.8.6.1 Action ..............................................126
+       4.8.6.2 Repeat Count ........................................126
+       4.8.6.3 Trigger .............................................127
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 4]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     4.8.7 Change Management Component Properties ..................129
+       4.8.7.1 Date/Time Created ...................................129
+       4.8.7.2 Date/Time Stamp .....................................130
+       4.8.7.3 Last Modified .......................................131
+       4.8.7.4 Sequence Number .....................................131
+     4.8.8 Miscellaneous Component Properties ......................133
+       4.8.8.1 Non-standard Properties .............................133
+       4.8.8.2 Request Status ......................................134
+   5 iCalendar Object Examples......................................136
+   6 Recommended Practices..........................................140
+   7 Registration of Content Type Elements..........................141
+    7.1 Registration of New and Modified iCalendar Object Methods ..141
+    7.2 Registration of New Properties .............................141
+     7.2.1 Define the property .....................................142
+     7.2.2 Post the Property definition ............................143
+     7.2.3 Allow a comment period ..................................143
+     7.2.4 Submit the property for approval ........................143
+    7.3 Property Change Control ....................................143
+   8 References.....................................................144
+   9 Acknowledgments................................................145
+   10 Authors' and Chairs' Addresses................................146
+   11 Full Copyright Statement......................................148
+
+1 Introduction
+
+   The use of calendaring and scheduling has grown considerably in the
+   last decade. Enterprise and inter-enterprise business has become
+   dependent on rapid scheduling of events and actions using this
+   information technology. However, the longer term growth of
+   calendaring and scheduling, is currently limited by the lack of
+   Internet standards for the message content types that are central to
+   these knowledgeware applications. This memo is intended to progress
+   the level of interoperability possible between dissimilar calendaring
+   and scheduling applications. This memo defines a MIME content type
+   for exchanging electronic calendaring and scheduling information. The
+   Internet Calendaring and Scheduling Core Object Specification, or
+   iCalendar, allows for the capture and exchange of information
+   normally stored within a calendaring and scheduling application; such
+   as a Personal Information Manager (PIM) or a Group Scheduling
+   product.
+
+   The iCalendar format is suitable as an exchange format between
+   applications or systems. The format is defined in terms of a MIME
+   content type. This will enable the object to be exchanged using
+   several transports, including but not limited to SMTP, HTTP, a file
+   system, desktop interactive protocols such as the use of a memory-
+   based clipboard or drag/drop interactions, point-to-point
+   asynchronous communication, wired-network transport, or some form of
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 5]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   unwired transport such as infrared might also be used.
+
+   The memo also provides for the definition of iCalendar object methods
+   that will map this content type to a set of messages for supporting
+   calendaring and scheduling operations such as requesting, replying
+   to, modifying, and canceling meetings or appointments, to-dos and
+   journal entries. The iCalendar object methods can be used to define
+   other calendaring and scheduling operations such a requesting for and
+   replying with free/busy time data. Such a scheduling protocol is
+   defined in the iCalendar Transport-independent Interoperability
+   Protocol (iTIP) defined in [ITIP].
+
+   The memo also includes a formal grammar for the content type based on
+   the Internet ABNF defined in [RFC 2234]. This ABNF is required for
+   the implementation of parsers and to serve as the definitive
+   reference when ambiguities or questions arise in interpreting the
+   descriptive prose definition of the memo.
+
+2 Basic Grammar and Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and
+   "OPTIONAL" in this document are to be interoperated as described in
+   [RFC 2119].
+
+   This memo makes use of both a descriptive prose and a more formal
+   notation for defining the calendaring and scheduling format.
+
+   The notation used in this memo is the ABNF notation of [RFC 2234].
+   Readers intending on implementing this format defined in this memo
+   should be familiar with this notation in order to properly interpret
+   the specifications of this memo.
+
+   All numeric and hexadecimal values used in this memo are given in
+   decimal notation.
+
+   All names of properties, property parameters, enumerated property
+   values and property parameter values are case-insensitive. However,
+   all other property values are case-sensitive, unless otherwise
+   stated.
+
+        Note: All indented editorial notes, such as this one, are
+        intended to provide the reader with additional information. The
+        information is not essential to the building of an
+        implementation conformant with this memo. The information is
+        provided to highlight a particular feature or characteristic of
+        the memo.
+
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 6]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The format for the iCalendar object is based on the syntax of the
+   [RFC 2425] content type. While the iCalendar object is not a profile
+   of the [RFC 2425] content type, it does reuse a number of the
+   elements from the [RFC 2425] specification.
+
+2.1 Formatting Conventions
+
+   The mechanisms defined in this memo are defined in prose. Many of the
+   terms used to describe these have common usage that is different than
+   the standards usage of this memo. In order to reference within this
+   memo elements of the calendaring and scheduling model, core object
+   (this memo) or interoperability protocol [ITIP] some formatting
+   conventions have been used. Calendaring and scheduling roles are
+   referred to in quoted-strings of text with the first character of
+   each word in upper case. For example, "Organizer" refers to a role of
+   a "Calendar User" within the scheduling protocol defined by [ITIP].
+   Calendar components defined by this memo are referred to with
+   capitalized, quoted-strings of text. All calendar components start
+   with the letter "V". For example, "VEVENT" refers to the event
+   calendar component, "VTODO" refers to the to-do calendar component
+   and "VJOURNAL" refers to the daily journal calendar component.
+   Scheduling methods defined by [ITIP] are referred to with
+   capitalized, quoted-strings of text. For example, "REQUEST" refers to
+   the method for requesting a scheduling calendar component be created
+   or modified, "REPLY" refers to the method a recipient of a request
+   uses to update their status with the "Organizer" of the calendar
+   component.
+
+   The properties defined by this memo are referred to with capitalized,
+   quoted-strings of text, followed by the word "property". For example,
+   "ATTENDEE" property refers to the iCalendar property used to convey
+   the calendar address of a calendar user. Property parameters defined
+   by this memo are referred to with lowercase, quoted-strings of text,
+   followed by the word "parameter". For example, "value" parameter
+   refers to the iCalendar property parameter used to override the
+   default data type for a property value. Enumerated values defined by
+   this memo are referred to with capitalized text, either alone or
+   followed by the word "value". For example, the "MINUTELY" value can
+   be used with the "FREQ" component of the "RECUR" data type to specify
+   repeating components based on an interval of one minute or more.
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 7]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+2.2 Related Memos
+
+   Implementers will need to be familiar with several other memos that,
+   along with this memo, form a framework for Internet calendaring and
+   scheduling standards. This memo, [ICAL], specifies a core
+   specification of objects, data types, properties and property
+   parameters.
+
+   [ITIP] - specifies an interoperability protocol for scheduling
+   between different implementations;
+
+   [IMIP] specifies an Internet email binding for [ITIP].
+
+   This memo does not attempt to repeat the specification of concepts or
+   definitions from these other memos. Where possible, references are
+   made to the memo that provides for the specification of these
+   concepts or definitions.
+
+2.3 International Considerations
+
+   In the rest of this document, descriptions of characters are of the
+   form "character name (codepoint)", where "codepoint" is from the US-
+   ASCII character set. The "character name" is the authoritative
+   description; (codepoint) is a reference to that character in US-ASCII
+   or US-ASCII compatible sets (for example the ISO-8859-x family, UTF-
+   8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set
+   is used, appropriate code-point from that character set MUST be
+   chosen instead. Use of non-US-ASCII-compatible character sets is NOT
+   recommended.
+
+3  Registration Information
+
+   The Calendaring and Scheduling Core Object Specification is intended
+   for use as a MIME content type. However, the implementation of the
+   memo is in no way limited solely as a MIME content type.
+
+3.1 Content Type
+
+   The following text is intended to register this memo as the MIME
+   content type "text/calendar".
+
+     To: ietf-types@uninett.no
+
+     Subject: Registration of MIME content type text/calendar.
+
+     MIME media type name: text
+
+     MIME subtype name: calendar
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 8]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+3.2 Parameters
+
+   Required parameters: none
+
+   Optional parameters: charset, method, component and optinfo
+
+   The "charset" parameter is defined in [RFC 2046] for other body
+   parts. It is used to identify the default character set used within
+   the body part.
+
+   The "method" parameter is used to convey the iCalendar object method
+   or transaction semantics for the calendaring and scheduling
+   information. It also is an identifier for the restricted set of
+   properties and values that the iCalendar object consists of. The
+   parameter is to be used as a guide for applications interpreting the
+   information contained within the body part. It SHOULD NOT be used to
+   exclude or require particular pieces of information unless the
+   identified method definition specifically calls for this behavior.
+   Unless specifically forbidden by a particular method definition, a
+   text/calendar content type can contain any set of properties
+   permitted by the Calendaring and Scheduling Core Object
+   Specification. The "method" parameter MUST be the same value as that
+   specified in the "METHOD" component property in the iCalendar object.
+   If one is present, the other MUST also be present.
+
+   The value for the "method" parameter is defined as follows:
+
+        method  = 1*(ALPHA / DIGIT / "-")
+        ; IANA registered iCalendar object method
+
+   The "component" parameter conveys the type of iCalendar calendar
+   component within the body part. If the iCalendar object contains more
+   than one calendar component type, then multiple component parameters
+   MUST be specified.
+
+   The value for the "component" parameter is defined as follows:
+
+        component       = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY"
+                        / "VTIMEZONE" / x-name / iana-token)
+
+   The "optinfo" parameter conveys optional information about the
+   iCalendar object within the body part. This parameter can only
+   specify semantics already specified by the iCalendar object and that
+   can be otherwise determined by parsing the body part. In addition,
+   the optional information specified by this parameter MUST be
+   consistent with that information specified by the iCalendar object.
+   For example, it can be used to convey the "Attendee" response status
+   to a meeting request. The parameter value consists of a string value.
+
+
+
+Dawson & Stenerson          Standards Track                     [Page 9]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The parameter can be specified multiple times.
+
+   This parameter MAY only specify semantics already specified by the
+   iCalendar object and that can be otherwise determined by parsing the
+   body part.
+
+   The value for the "optinfo" parameter is defined as follows:
+
+        optinfo = infovalue / qinfovalue
+
+        infovalue       = iana-token / x-name
+
+        qinfovalue      = DQUOTE (infovalue) DQUOTE
+
+3.3 Content Header Fields
+
+   Optional content header fields: Any header fields defined by [RFC
+   2045].
+
+3.4 Encoding Considerations
+
+   This MIME content type can contain 8bit characters, so the use of
+   quoted-printable or BASE64 MIME content-transfer-encodings might be
+   necessary when iCalendar objects are transferred across protocols
+   restricted to the 7bit repertoire. Note that a text valued property
+   in the content entity can also have content encoding of special
+   characters using a BACKSLASH character (US-ASCII decimal 92)
+   escapement technique. This means that content values can end up
+   encoded twice.
+
+3.5 Security Considerations
+
+   SPOOFING - - In this memo, the "Organizer" is the only person
+   authorized to make changes to an existing "VEVENT", "VTODO",
+   "VJOURNAL" calendar component and redistribute the updates to the
+   "Attendees". An iCalendar object that maliciously changes or cancels
+   an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar
+   component might be constructed by someone other than the "Organizer"
+   and sent to the "Attendees". In addition in this memo, other than the
+   "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL"
+   calendar component is the only other person authorized to update any
+   parameter associated with their "ATTENDEE" property and send it to
+   the "Organizer". An iCalendar object that maliciously changes the
+   "ATTENDEE" parameters can be constructed by someone other than the
+   real "Attendee" and sent to the "Organizer".
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 10]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   PROCEDURAL ALARMS - - An iCalendar object can be created that
+   contains a "VEVENT" and "VTODO" calendar component with "VALARM"
+   calendar components. The "VALARM" calendar component can be of type
+   PROCEDURE and can have an attachment containing some sort of
+   executable program. Implementations that incorporate these types of
+   alarms are subject to any virus or malicious attack that might occur
+   as a result of executing the attachment.
+
+   ATTACHMENTS - - An iCalendar object can include references to Uniform
+   Resource Locators that can be programmed resources.
+
+   Implementers and users of this memo should be aware of the network
+   security implications of accepting and parsing such information. In
+   addition, the security considerations observed by implementations of
+   electronic mail systems should be followed for this memo.
+
+3.6 Interoperability Considerations
+
+   This MIME content type is intended to define a common format for
+   conveying calendaring and scheduling information between different
+   systems. It is heavily based on the earlier [VCAL] industry
+   specification.
+
+3.7 Applications Which Use This Media Type
+
+   This content-type is designed for widespread use by Internet
+   calendaring and scheduling applications. In addition, applications in
+   the workflow and document management area might find this content-
+   type applicable. The [ITIP] and [IMIP] Internet protocols directly
+   use this content-type also. Future work on an Internet calendar
+   access protocol will utilize this content-type too.
+
+3.8 Additional Information
+
+   This memo defines this content-type.
+
+3.9 Magic Numbers
+
+   None.
+
+3.10 File Extensions
+
+   The file extension of "ics" is to be used to designate a file
+   containing (an arbitrary set of) calendaring and scheduling
+   information consistent with this MIME content type.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 11]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The file extension of "ifb" is to be used to designate a file
+   containing free or busy time information consistent with this MIME
+   content type.
+
+   Macintosh file type codes: The file type code of "iCal" is to be used
+   in Apple MacIntosh operating system environments to designate a file
+   containing calendaring and scheduling information consistent with
+   this MIME media type.
+
+   The file type code of "iFBf" is to be used in Apple MacIntosh
+   operating system environments to designate a file containing free or
+   busy time information consistent with this MIME media type.
+
+3.11 Contact for Further Information:
+
+   Frank Dawson
+   6544 Battleford Drive
+   Raleigh, NC 27613-3502
+   919-676-9515 (Telephone)
+   919-676-9564 (Data/Facsimile)
+   Frank_Dawson@Lotus.com (Internet Mail)
+
+   Derik Stenerson
+   One Microsoft Way
+   Redmond, WA  98052-6399
+   425-936-5522 (Telephone)
+   425-936-7329 (Facsimile)
+   deriks@microsoft.com (Internet Mail)
+
+3.12 Intended Usage
+
+   COMMON
+
+3.13 Authors/Change Controllers
+
+   Frank Dawson
+   6544 Battleford Drive
+   Raleigh, NC 27613-3502
+   919-676-9515 (Telephone)
+   919-676-9564 (Data/Facsimile)
+   Frank_Dawson@Lotus.com (Internet Mail)
+
+   Derik Stenerson
+   One Microsoft Way
+   Redmond, WA  98052-6399
+   425-936-5522 (Telephone)
+   425-936-7329 (Facsimile)
+   deriks@microsoft.com (Internet Mail)
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 12]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4 iCalendar Object Specification
+
+   The following sections define the details of a Calendaring and
+   Scheduling Core Object Specification. This information is intended to
+   be an integral part of the MIME content type registration. In
+   addition, this information can be used independent of such content
+   registration. In particular, this memo has direct applicability for
+   use as a calendaring and scheduling exchange format in file-, memory-
+   or network-based transport mechanisms.
+
+4.1 Content Lines
+
+   The iCalendar object is organized into individual lines of text,
+   called content lines. Content lines are delimited by a line break,
+   which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII
+   decimal 10).
+
+   Lines of text SHOULD NOT be longer than 75 octets, excluding the line
+   break. Long content lines SHOULD be split into a multiple line
+   representations using a line "folding" technique. That is, a long
+   line can be split between any two characters by inserting a CRLF
+   immediately followed by a single linear white space character (i.e.,
+   SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence
+   of CRLF followed immediately by a single linear white space character
+   is ignored (i.e., removed) when processing the content type.
+
+   For example the line:
+
+     DESCRIPTION:This is a long description that exists on a long line.
+
+   Can be represented as:
+
+     DESCRIPTION:This is a lo
+      ng description
+       that exists on a long line.
+
+   The process of moving from this folded multiple line representation
+   to its single line representation is called "unfolding". Unfolding is
+   accomplished by removing the CRLF character and the linear white
+   space character that immediately follows.
+
+   When parsing a content line, folded lines MUST first be unfolded
+   according to the unfolding procedure described above. When generating
+   a content line, lines longer than 75 octets SHOULD be folded
+   according to the folding procedure described above.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 13]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The content information associated with an iCalendar object is
+   formatted using a syntax similar to that defined by [RFC 2425]. That
+   is, the content information consists of CRLF-separated content lines.
+
+   The following notation defines the lines of content in an iCalendar
+   object:
+
+     contentline        = name *(";" param ) ":" value CRLF
+        ; This ABNF is just a general definition for an initial parsing
+        ; of the content line into its property name, parameter list,
+        ; and value string
+
+     ; When parsing a content line, folded lines MUST first
+        ; be unfolded according to the unfolding procedure
+        ; described above. When generating a content line, lines
+        ; longer than 75 octets SHOULD be folded according to
+        ; the folding procedure described above.
+
+     name               = x-name / iana-token
+
+     iana-token = 1*(ALPHA / DIGIT / "-")
+     ; iCalendar identifier registered with IANA
+
+     x-name             = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-")
+     ; Reservered for experimental use. Not intended for use in
+     ; released products.
+
+     vendorid   = 3*(ALPHA / DIGIT)     ;Vendor identification
+
+     param              = param-name "=" param-value
+                          *("," param-value)
+        ; Each property defines the specific ABNF for the parameters
+        ; allowed on the property. Refer to specific properties for
+        ; precise parameter ABNF.
+
+     param-name = iana-token / x-token
+
+     param-value        = paramtext / quoted-string
+
+     paramtext  = *SAFE-CHAR
+
+     value      = *VALUE-CHAR
+
+     quoted-string      = DQUOTE *QSAFE-CHAR DQUOTE
+
+     NON-US-ASCII       = %x80-F8
+     ; Use restricted by charset parameter
+     ; on outer MIME object (UTF-8 preferred)
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 14]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII
+     ; Any character except CTLs and DQUOTE
+
+     SAFE-CHAR  = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E
+                / NON-US-ASCII
+     ; Any character except CTLs, DQUOTE, ";", ":", ","
+
+     VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII
+     ; Any textual character
+
+     CR = %x0D
+     ; carriage return
+
+     LF = %x0A
+     ; line feed
+
+     CRLF       = CR LF
+     ; Internet standard newline
+
+     CTL        = %x00-08 / %x0A-1F / %x7F
+        ; Controls
+
+     ALPHA      = %x41-5A / %x61-7A   ; A-Z / a-z
+
+     DIGIT      = %x30-39
+        ; 0-9
+
+     DQUOTE     = %x22
+        ; Quotation Mark
+
+     WSP        = SPACE / HTAB
+
+     SPACE      = %x20
+
+     HTAB       = %x09
+
+   The property value component of a content line has a format that is
+   property specific. Refer to the section describing each property for
+   a definition of this format.
+
+   All names of properties, property parameters, enumerated property
+   values and property parameter values are case-insensitive. However,
+   all other property values are case-sensitive, unless otherwise
+   stated.
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 15]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.1.1 List and Field Separators
+
+   Some properties and parameters allow a list of values. Values in a
+   list of values MUST be separated by a COMMA character (US-ASCII
+   decimal 44). There is no significance to the order of values in a
+   list. For those parameter values (such as those that specify URI
+   values) that are specified in quoted-strings, the individual quoted-
+   strings are separated by a COMMA character (US-ASCII decimal 44).
+
+   Some property values are defined in terms of multiple parts. These
+   structured property values MUST have their value parts separated by a
+   SEMICOLON character (US-ASCII decimal 59).
+
+   Some properties allow a list of parameters. Each property parameter
+   in a list of property parameters MUST be separated by a SEMICOLON
+   character (US-ASCII decimal 59).
+
+   Property parameters with values containing a COLON, a SEMICOLON or a
+   COMMA character MUST be placed in quoted text.
+
+   For example, in the following properties a SEMICOLON is used to
+   separate property parameters from each other, and a COMMA is used to
+   separate property values in a value list.
+
+     ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO:
+      jsmith@host.com
+
+     RDATE;VALUE=DATE:19970304,19970504,19970704,19970904
+
+4.1.2 Multiple Values
+
+   Some properties defined in the iCalendar object can have multiple
+   values. The general rule for encoding multi-valued items is to simply
+   create a new content line for each value, including the property
+   name. However, it should be noted that some properties support
+   encoding multiple values in a single property by separating the
+   values with a COMMA character (US-ASCII decimal 44). Individual
+   property definitions should be consulted for determining whether a
+   specific property allows multiple values and in which of these two
+   forms.
+
+4.1.3 Binary Content
+
+   Binary content information in an iCalendar object SHOULD be
+   referenced using a URI within a property value. That is the binary
+   content information SHOULD be placed in an external MIME entity that
+   can be referenced by a URI from within the iCalendar object. In
+   applications where this is not feasible, binary content information
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 16]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   can be included within an iCalendar object, but only after first
+   encoding it into text using the "BASE64" encoding method defined in
+   [RFC 2045]. Inline binary contact SHOULD only be used in applications
+   whose special circumstances demand that an iCalendar object be
+   expressed as a single entity. A property containing inline binary
+   content information MUST specify the "ENCODING" property parameter.
+   Binary content information placed external to the iCalendar object
+   MUST be referenced by a uniform resource identifier (URI).
+
+   The following example specifies an "ATTACH" property that references
+   an attachment external to the iCalendar object with a URI reference:
+
+     ATTACH:http://xyz.com/public/quarterly-report.doc
+
+   The following example specifies an "ATTACH" property with inline
+   binary encoded content information:
+
+     ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY:
+      MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U
+      EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE
+        <...remainder of "BASE64" encoded binary data...>
+
+4.1.4 Character Set
+
+   There is not a property parameter to declare the character set used
+   in a property value. The default character set for an iCalendar
+   object is UTF-8 as defined in [RFC 2279].
+
+   The "charset" Content-Type parameter can be used in MIME transports
+   to specify any other IANA registered character set.
+
+4.2 Property Parameters
+
+   A property can have attributes associated with it. These "property
+   parameters" contain meta-information about the property or the
+   property value. Property parameters are provided to specify such
+   information as the location of an alternate text representation for a
+   property value, the language of a text property value, the data type
+   of the property value and other attributes.
+
+   Property parameter values that contain the COLON (US-ASCII decimal
+   58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44)
+   character separators MUST be specified as quoted-string text values.
+   Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII
+   decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22)
+   character is used as a delimiter for parameter values that contain
+   restricted characters or URI text. For example:
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 17]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards
+       Conference - - Las Vegas, NV, USA
+
+   Property parameter values that are not in quoted strings are case
+   insensitive.
+
+   The general property parameters defined by this memo are defined by
+   the following notation:
+
+     parameter  = altrepparam           ; Alternate text representation
+                / cnparam               ; Common name
+                / cutypeparam           ; Calendar user type
+                / delfromparam          ; Delegator
+                / deltoparam            ; Delegatee
+                / dirparam              ; Directory entry
+                / encodingparam         ; Inline encoding
+                / fmttypeparam          ; Format type
+                / fbtypeparam           ; Free/busy time type
+                / languageparam         ; Language for text
+                / memberparam           ; Group or list membership
+                / partstatparam         ; Participation status
+                / rangeparam            ; Recurrence identifier range
+                / trigrelparam          ; Alarm trigger relationship
+                / reltypeparam          ; Relationship type
+                / roleparam             ; Participation role
+                / rsvpparam             ; RSVP expectation
+                / sentbyparam           ; Sent by
+                / tzidparam             ; Reference to time zone object
+                / valuetypeparam        ; Property value data type
+                / ianaparam
+        ; Some other IANA registered iCalendar parameter.
+                / xparam
+        ; A non-standard, experimental parameter.
+
+     ianaparam  = iana-token "=" param-value *("," param-value)
+
+     xparam     =x-name "=" param-value *("," param-value)
+
+4.2.1 Alternate Text Representation
+
+   Parameter Name: ALTREP
+
+   Purpose: To specify an alternate text representation for the property
+   value.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 18]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     altrepparam        = "ALTREP" "=" DQUOTE uri DQUOTE
+
+   Description: The parameter specifies a URI that points to an
+   alternate representation for a textual property value. A property
+   specifying this parameter MUST also include a value that reflects the
+   default representation of the text value. The individual URI
+   parameter values MUST each be specified in a quoted-string.
+
+   Example:
+
+     DESCRIPTION;ALTREP="CID:<part3.msg.970415T083000@host.com>":Project
+       XYZ Review Meeting will include the following agenda items: (a)
+       Market Overview, (b) Finances, (c) Project Management
+
+   The "ALTREP" property parameter value might point to a "text/html"
+   content portion.
+
+     Content-Type:text/html
+     Content-Id:<part3.msg.970415T083000@host.com>
+
+     <html><body>
+     <p><b>Project XYZ Review Meeting</b> will include the following
+     agenda items:<ol><li>Market
+     Overview</li><li>Finances</li><li>Project Management</li></ol></p>
+     </body></html>
+
+4.2.2 Common Name
+
+   Parameter Name: CN
+
+   Purpose: To specify the common name to be associated with the
+   calendar user specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     cnparam    = "CN" "=" param-value
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter specifies the common name to be
+   associated with the calendar user specified by the property. The
+   parameter value is text. The parameter value can be used for display
+   text to be associated with the calendar address specified by the
+   property.
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 19]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Example:
+
+     ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com
+
+4.2.3 Calendar User Type
+
+   Parameter Name: CUTYPE
+
+   Purpose: To specify the type of calendar user specified by the
+   property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     cutypeparam        = "CUTYPE" "="
+                         ("INDIVIDUAL"          ; An individual
+                        / "GROUP"               ; A group of individuals
+                        / "RESOURCE"            ; A physical resource
+                        / "ROOM"                ; A room resource
+                        / "UNKNOWN"             ; Otherwise not known
+                        / x-name                ; Experimental type
+                        / iana-token)           ; Other IANA registered
+                                                ; type
+     ; Default is INDIVIDUAL
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter identifies the type of calendar
+   user specified by the property. If not specified on a property that
+   allows this parameter, the default is INDIVIDUAL.
+
+   Example:
+
+     ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org
+
+4.2.4 Delegators
+
+   Parameter Name: DELEGATED-FROM
+
+   Purpose: To specify the calendar users that have delegated their
+   participation to the calendar user specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     delfromparam       = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE
+                          *("," DQUOTE cal-address DQUOTE)
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 20]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. This parameter can be specified on a property
+   that has a value type of calendar address. This parameter specifies
+   those calendar uses that have delegated their participation in a
+   group scheduled event or to-do to the calendar user specified by the
+   property. The value MUST be a MAILTO URI as defined in [RFC 1738].
+   The individual calendar address parameter values MUST each be
+   specified in a quoted-string.
+
+   Example:
+
+     ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO:
+      jdoe@host.com
+
+4.2.5 Delegatees
+
+   Parameter Name: DELEGATED-TO
+
+   Purpose: To specify the calendar users to whom the calendar user
+   specified by the property has delegated participation.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE
+                  *("," DQUOTE cal-address DQUOTE)
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. This parameter specifies those calendar users
+   whom have been delegated participation in a group scheduled event or
+   to-do by the calendar user specified by the property. The value MUST
+   be a MAILTO URI as defined in [RFC 1738]. The individual calendar
+   address parameter values MUST each be specified in a quoted-string.
+
+   Example:
+
+     ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@
+      host.com":MAILTO:jsmith@host.com
+
+4.2.6 Directory Entry Reference
+
+   Parameter Name: DIR
+
+   Purpose: To specify reference to a directory entry associated with
+   the calendar user specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 21]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     dirparam   = "DIR" "=" DQUOTE uri DQUOTE
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter specifies a reference to the
+   directory entry associated with the calendar user specified by the
+   property. The parameter value is a URI. The individual URI parameter
+   values MUST each be specified in a quoted-string.
+
+   Example:
+
+     ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS??
+      (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com
+
+4.2.7 Inline Encoding
+
+   Parameter Name: ENCODING
+
+   Purpose: To specify an alternate inline encoding for the property
+   value.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     encodingparam      = "ENCODING" "="
+                          ("8BIT"
+        ; "8bit" text encoding is defined in [RFC 2045]
+                        / "BASE64"
+        ; "BASE64" binary encoding format is defined in [RFC 2045]
+                        / iana-token
+        ; Some other IANA registered iCalendar encoding type
+                        / x-name)
+        ; A non-standard, experimental encoding type
+
+   Description: The property parameter identifies the inline encoding
+   used in a property value. The default encoding is "8BIT",
+   corresponding to a property value consisting of text. The "BASE64"
+   encoding type corresponds to a property value encoded using the
+   "BASE64" encoding defined in [RFC 2045].
+
+   If the value type parameter is ";VALUE=BINARY", then the inline
+   encoding parameter MUST be specified with the value
+   ";ENCODING=BASE64".
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 22]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Example:
+
+     ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC
+      CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA
+      qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw
+      <...remainder of "BASE64" encoded binary data...>
+
+4.2.8 Format Type
+
+   Parameter Name: FMTTYPE
+
+   Purpose: To specify the content type of a referenced object.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     fmttypeparam       = "FMTTYPE" "=" iana-token
+                                        ; A IANA registered content type
+                                     / x-name
+                                        ; A non-standard content type
+
+   Description: This parameter can be specified on properties that are
+   used to reference an object. The parameter specifies the content type
+   of the referenced object. For example, on the "ATTACH" property, a
+   FTP type URI value does not, by itself, necessarily convey the type
+   of content associated with the resource. The parameter value MUST be
+   the TEXT for either an IANA registered content type or a non-standard
+   content type.
+
+     Example:
+
+      ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/
+       agenda.doc
+
+4.2.9 Free/Busy Time Type
+
+   Parameter Name: FBTYPE
+
+   Purpose: To specify the free or busy time type.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     fbtypeparam        = "FBTYPE" "=" ("FREE" / "BUSY"
+                        / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE"
+                        / x-name
+        ; Some experimental iCalendar data type.
+                        / iana-token)
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 23]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+        ; Some other IANA registered iCalendar data type.
+
+   Description: The parameter specifies the free or busy time type. The
+   value FREE indicates that the time interval is free for scheduling.
+   The value BUSY indicates that the time interval is busy because one
+   or more events have been scheduled for that interval. The value
+   BUSY-UNAVAILABLE indicates that the time interval is busy and that
+   the interval can not be scheduled. The value BUSY-TENTATIVE indicates
+   that the time interval is busy because one or more events have been
+   tentatively scheduled for that interval. If not specified on a
+   property that allows this parameter, the default is BUSY.
+
+   Example: The following is an example of this parameter on a FREEBUSY
+   property.
+
+     FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z
+
+4.2.10 Language
+
+   Parameter Name: LANGUAGE
+
+   Purpose: To specify the language for text values in a property or
+   property parameter.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     languageparam =    "LANGUAGE" "=" language
+
+     language = <Text identifying a language, as defined in [RFC 1766]>
+
+   Description: This parameter can be specified on properties with a
+   text value type. The parameter identifies the language of the text in
+   the property or property parameter value. The value of the "language"
+   property parameter is that defined in [RFC 1766].
+
+   For transport in a MIME entity, the Content-Language header field can
+   be used to set the default language for the entire body part.
+   Otherwise, no default language is assumed.
+
+   Example:
+
+     SUMMARY;LANGUAGE=us-EN:Company Holiday Party
+
+     LOCATION;LANGUAGE=en:Germany
+     LOCATION;LANGUAGE=no:Tyskland
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 24]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The following example makes use of the Quoted-Printable encoding in
+   order to represent non-ASCII characters.
+
+     LOCATION;LANGUAGE=da:K=F8benhavn
+     LOCATION;LANGUAGE=en:Copenhagen
+
+4.2.11  Group or List Membership
+
+   Parameter Name: MEMBER
+
+   Purpose: To specify the group or list membership of the calendar user
+   specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     memberparam        = "MEMBER" "=" DQUOTE cal-address DQUOTE
+                          *("," DQUOTE cal-address DQUOTE)
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter identifies the groups or list
+   membership for the calendar user specified by the property. The
+   parameter value either a single calendar address in a quoted-string
+   or a COMMA character (US-ASCII decimal 44) list of calendar
+   addresses, each in a quoted-string. The individual calendar address
+   parameter values MUST each be specified in a quoted-string.
+
+   Example:
+
+     ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com
+
+     ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host.
+      com":MAILTO:janedoe@host.com
+
+4.2.12 Participation Status
+
+   Parameter Name: PARTSTAT
+
+   Purpose: To specify the participation status for the calendar user
+   specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     partstatparam      = "PARTSTAT" "="
+                         ("NEEDS-ACTION"        ; Event needs action
+                        / "ACCEPTED"            ; Event accepted
+                        / "DECLINED"            ; Event declined
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 25]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                        / "TENTATIVE"           ; Event tentatively
+                                                ; accepted
+                        / "DELEGATED"           ; Event delegated
+                        / x-name                ; Experimental status
+                        / iana-token)           ; Other IANA registered
+                                                ; status
+     ; These are the participation statuses for a "VEVENT". Default is
+     ; NEEDS-ACTION
+     partstatparam      /= "PARTSTAT" "="
+                         ("NEEDS-ACTION"        ; To-do needs action
+                        / "ACCEPTED"            ; To-do accepted
+                        / "DECLINED"            ; To-do declined
+                        / "TENTATIVE"           ; To-do tentatively
+                                                ; accepted
+                        / "DELEGATED"           ; To-do delegated
+                        / "COMPLETED"           ; To-do completed.
+                                                ; COMPLETED property has
+                                                ;date/time completed.
+                        / "IN-PROCESS"          ; To-do in process of
+                                                ; being completed
+                        / x-name                ; Experimental status
+                        / iana-token)           ; Other IANA registered
+                                                ; status
+     ; These are the participation statuses for a "VTODO". Default is
+     ; NEEDS-ACTION
+
+     partstatparam      /= "PARTSTAT" "="
+                         ("NEEDS-ACTION"        ; Journal needs action
+                        / "ACCEPTED"            ; Journal accepted
+                        / "DECLINED"            ; Journal declined
+                        / x-name                ; Experimental status
+                        / iana-token)           ; Other IANA registered
+                                                ; status
+     ; These are the participation statuses for a "VJOURNAL". Default is
+     ; NEEDS-ACTION
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter identifies the participation
+   status for the calendar user specified by the property value. The
+   parameter values differ depending on whether they are associated with
+   a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST
+   match one of the values allowed for the given calendar component. If
+   not specified on a property that allows this parameter, the default
+   value is NEEDS-ACTION.
+
+   Example:
+
+     ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 26]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.2.13  Recurrence Identifier Range
+
+   Parameter Name: RANGE
+
+   Purpose: To specify the effective range of recurrence instances from
+   the instance specified by the recurrence identifier specified by the
+   property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     rangeparam = "RANGE" "=" ("THISANDPRIOR"
+        ; To specify all instances prior to the recurrence identifier
+                / "THISANDFUTURE")
+        ; To specify the instance specified by the recurrence identifier
+        ; and all subsequent recurrence instances
+
+   Description: The parameter can be specified on a property that
+   specifies a recurrence identifier. The parameter specifies the
+   effective range of recurrence instances that is specified by the
+   property. The effective range is from the recurrence identified
+   specified by the property. If this parameter is not specified an
+   allowed property, then the default range is the single instance
+   specified by the recurrence identifier value of the property. The
+   parameter value can be "THISANDPRIOR" to indicate a range defined by
+   the recurrence identified value of the property and all prior
+   instances. The parameter value can also be "THISANDFUTURE" to
+   indicate a range defined by the recurrence identifier and all
+   subsequent instances.
+
+   Example:
+
+     RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z
+
+4.2.14 Alarm Trigger Relationship
+
+   Parameter Name: RELATED
+
+   Purpose: To specify the relationship of the alarm trigger with
+   respect to the start or end of the calendar component.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     trigrelparam       = "RELATED" "="
+                         ("START"       ; Trigger off of start
+                        / "END")        ; Trigger off of end
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 27]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: The parameter can be specified on properties that
+   specify an alarm trigger with a DURATION value type. The parameter
+   specifies whether the alarm will trigger relative to the start or end
+   of the calendar component. The parameter value START will set the
+   alarm to trigger off the start of the calendar component; the
+   parameter value END will set the alarm to trigger off the end of the
+   calendar component. If the parameter is not specified on an allowable
+   property, then the default is START.
+
+   Example:
+
+     TRIGGER;RELATED=END:PT5M
+
+4.2.15 Relationship Type
+
+   Parameter Name: RELTYPE
+
+   Purpose: To specify the type of hierarchical relationship associated
+   with the calendar component specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     reltypeparam       = "RELTYPE" "="
+                         ("PARENT"      ; Parent relationship. Default.
+                        / "CHILD"       ; Child relationship
+                        / "SIBLING      ; Sibling relationship
+                        / iana-token    ; Some other IANA registered
+                                        ; iCalendar relationship type
+                        / x-name)       ; A non-standard, experimental
+                                        ; relationship type
+
+   Description: This parameter can be specified on a property that
+   references another related calendar. The parameter specifies the
+   hierarchical relationship type of the calendar component referenced
+   by the property. The parameter value can be PARENT, to indicate that
+   the referenced calendar component is a superior of calendar
+   component; CHILD to indicate that the referenced calendar component
+   is a subordinate of the calendar component; SIBLING to indicate that
+   the referenced calendar component is a peer of the calendar
+   component. If this parameter is not specified on an allowable
+   property, the default relationship type is PARENT.
+
+   Example:
+
+     RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com>
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 28]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.2.16 Participation Role
+
+   Parameter Name: ROLE
+
+   Purpose: To specify the participation role for the calendar user
+   specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     roleparam  = "ROLE" "="
+                 ("CHAIR"               ; Indicates chair of the
+                                        ; calendar entity
+                / "REQ-PARTICIPANT"     ; Indicates a participant whose
+                                        ; participation is required
+                / "OPT-PARTICIPANT"     ; Indicates a participant whose
+                                        ; participation is optional
+                / "NON-PARTICIPANT"     ; Indicates a participant who is
+                                        ; copied for information
+                                        ; purposes only
+                / x-name                ; Experimental role
+                / iana-token)           ; Other IANA role
+     ; Default is REQ-PARTICIPANT
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter specifies the participation
+   role for the calendar user specified by the property in the group
+   schedule calendar component. If not specified on a property that
+   allows this parameter, the default value is REQ-PARTICIPANT.
+
+   Example:
+
+     ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com
+
+4.2.17  RSVP Expectation
+
+   Parameter Name: RSVP
+
+   Purpose: To specify whether there is an expectation of a favor of a
+   reply from the calendar user specified by the property value.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     rsvpparam = "RSVP" "=" ("TRUE" / "FALSE")
+     ; Default is FALSE
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 29]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter identifies the expectation of a
+   reply from the calendar user specified by the property value. This
+   parameter is used by the "Organizer" to request a participation
+   status reply from an "Attendee" of a group scheduled event or to-do.
+   If not specified on a property that allows this parameter, the
+   default value is FALSE.
+
+   Example:
+
+     ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com
+
+4.2.18  Sent By
+
+   Parameter Name: SENT-BY
+
+   Purpose: To specify the calendar user that is acting on behalf of the
+   calendar user specified by the property.
+
+   Format Definition: The property parameter is defined by the following
+   notation:
+
+     sentbyparam        = "SENT-BY" "=" DQUOTE cal-address DQUOTE
+
+   Description: This parameter can be specified on properties with a
+   CAL-ADDRESS value type. The parameter specifies the calendar user
+   that is acting on behalf of the calendar user specified by the
+   property. The parameter value MUST be a MAILTO URI as defined in [RFC
+   1738]. The individual calendar address parameter values MUST each be
+   specified in a quoted-string.
+
+   Example:
+
+     ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com
+
+4.2.19 Time Zone Identifier
+
+   Parameter Name: TZID
+
+   Purpose: To specify the identifier for the time zone definition for a
+   time component in the property value.
+
+   Format Definition: This property parameter is defined by the
+   following notation:
+
+     tzidparam  = "TZID" "=" [tzidprefix] paramtext CRLF
+
+     tzidprefix = "/"
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 30]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: The parameter MUST be specified on the "DTSTART",
+   "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE-
+   TIME or TIME value type is specified and when the value is not either
+   a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type
+   definition for a description of UTC and "floating time" formats. This
+   property parameter specifies a text value which uniquely identifies
+   the "VTIMEZONE" calendar component to be used when evaluating the
+   time portion of the property. The value of the TZID property
+   parameter will be equal to the value of the TZID property for the
+   matching time zone definition. An individual "VTIMEZONE" calendar
+   component MUST be specified for each unique "TZID" parameter value
+   specified in the iCalendar object.
+
+   The parameter MUST be specified on properties with a DATE-TIME value
+   if the DATE-TIME is not either a UTC or a "floating" time.
+
+   The presence of the SOLIDUS character (US-ASCII decimal 47) as a
+   prefix, indicates that this TZID represents a unique ID in a globally
+   defined time zone registry (when such registry is defined).
+
+        Note: This document does not define a naming convention for time
+        zone identifiers. Implementers may want to use the naming
+        conventions defined in existing time zone specifications such as
+        the public-domain Olson database [TZ]. The specification of
+        globally unique time zone identifiers is not addressed by this
+        document and is left for future study.
+
+   The following are examples of this property parameter:
+
+     DTSTART;TZID=US-Eastern:19980119T020000
+
+     DTEND;TZID=US-Eastern:19980119T030000
+
+   The TZID property parameter MUST NOT be applied to DATE-TIME or TIME
+   properties whose time values are specified in UTC.
+
+   The use of local time in a DATE-TIME or TIME value without the TZID
+   property parameter is to be interpreted as a local time value,
+   regardless of the existence of "VTIMEZONE" calendar components in the
+   iCalendar object.
+
+   For more information see the sections on the data types DATE-TIME and
+   TIME.
+
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 31]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.2.20 Value Data Types
+
+   Parameter Name: VALUE
+
+   Purpose: To explicitly specify the data type format for a property
+   value.
+
+   Format Definition: The "VALUE" property parameter is defined by the
+   following notation:
+
+     valuetypeparam = "VALUE" "=" valuetype
+
+     valuetype  = ("BINARY"
+                / "BOOLEAN"
+                / "CAL-ADDRESS"
+                / "DATE"
+                / "DATE-TIME"
+                / "DURATION"
+                / "FLOAT"
+                / "INTEGER"
+                / "PERIOD"
+                / "RECUR"
+                / "TEXT"
+                / "TIME"
+                / "URI"
+                / "UTC-OFFSET"
+                / x-name
+                ; Some experimental iCalendar data type.
+                / iana-token)
+                ; Some other IANA registered iCalendar data type.
+
+   Description: The parameter specifies the data type and format of the
+   property value. The property values MUST be of a single value type.
+   For example, a "RDATE" property cannot have a combination of DATE-
+   TIME and TIME value types.
+
+   If the property's value is the default value type, then this
+   parameter need not be specified. However, if the property's default
+   value type is overridden by some other allowable value type, then
+   this parameter MUST be specified.
+
+4.3 Property Value Data Types
+
+   The properties in an iCalendar object are strongly typed. The
+   definition of each property restricts the value to be one of the
+   value data types, or simply value types, defined in this section. The
+   value type for a property will either be specified implicitly as the
+   default value type or will be explicitly specified with the "VALUE"
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 32]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   parameter. If the value type of a property is one of the alternate
+   valid types, then it MUST be explicitly specified with the "VALUE"
+   parameter.
+
+4.3.1   Binary
+
+   Value Name: BINARY
+
+   Purpose: This value type is used to identify properties that contain
+   a character encoding of inline binary data. For example, an inline
+   attachment of an object code might be included in an iCalendar
+   object.
+
+   Formal Definition: The value type is defined by the following
+   notation:
+
+     binary     = *(4b-char) [b-end]
+     ; A "BASE64" encoded character string, as defined by [RFC 2045].
+
+     b-end      = (2b-char "==") / (3b-char "=")
+
+     b-char = ALPHA / DIGIT / "+" / "/"
+
+   Description: Property values with this value type MUST also include
+   the inline encoding parameter sequence of ";ENCODING=BASE64". That
+   is, all inline binary data MUST first be character encoded using the
+   "BASE64" encoding method defined in [RFC 2045]. No additional content
+   value encoding (i.e., BACKSLASH character encoding) is defined for
+   this value type.
+
+   Example: The following is an abridged example of a "BASE64" encoded
+   binary value data.
+
+     ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY
+      JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI
+      ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv
+        <...remainder of "BASE64" encoded binary data...>
+
+4.3.2   Boolean
+
+   Value Name: BOOLEAN
+
+   Purpose: This value type is used to identify properties that contain
+   either a "TRUE" or "FALSE" Boolean value.
+
+   Formal Definition: The value type is defined by the following
+   notation:
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 33]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     boolean    = "TRUE" / "FALSE"
+
+   Description: These values are case insensitive text. No additional
+   content value encoding (i.e., BACKSLASH character encoding) is
+   defined for this value type.
+
+   Example: The following is an example of a hypothetical property that
+   has a BOOLEAN value type:
+
+   GIBBERISH:TRUE
+
+4.3.3   Calendar User Address
+
+   Value Name: CAL-ADDRESS
+
+   Purpose: This value type is used to identify properties that contain
+   a calendar user address.
+
+   Formal Definition: The value type is as defined by the following
+   notation:
+
+     cal-address        = uri
+
+   Description: The value is a URI as defined by [RFC 1738] or any other
+   IANA registered form for a URI. When used to address an Internet
+   email transport address for a calendar user, the value MUST be a
+   MAILTO URI, as defined by [RFC 1738]. No additional content value
+   encoding (i.e., BACKSLASH character encoding) is defined for this
+   value type.
+
+   Example:
+
+     ATTENDEE:MAILTO:jane_doe@host.com
+
+4.3.4 Date
+
+   Value Name: DATE
+
+   Purpose: This value type is used to identify values that contain a
+   calendar date.
+
+   Formal Definition: The value type is defined by the following
+   notation:
+
+     date               = date-value
+
+     date-value         = date-fullyear date-month date-mday
+     date-fullyear      = 4DIGIT
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 34]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     date-month         = 2DIGIT        ;01-12
+     date-mday          = 2DIGIT        ;01-28, 01-29, 01-30, 01-31
+                                        ;based on month/year
+
+   Description: If the property permits, multiple "date" values are
+   specified as a COMMA character (US-ASCII decimal 44) separated list
+   of values. The format for the value type is expressed as the [ISO
+   8601] complete representation, basic format for a calendar date. The
+   textual format specifies a four-digit year, two-digit month, and
+   two-digit day of the month. There are no separator characters between
+   the year, month and day component text.
+
+   No additional content value encoding (i.e., BACKSLASH character
+   encoding) is defined for this value type.
+
+   Example: The following represents July 14, 1997:
+
+     19970714
+
+4.3.5   Date-Time
+
+   Value Name: DATE-TIME
+
+   Purpose: This value type is used to identify values that specify a
+   precise calendar date and time of day.
+
+   Formal Definition: The value type is defined by the following
+   notation:
+
+     date-time  = date "T" time ;As specified in the date and time
+                                ;value definitions
+
+   Description: If the property permits, multiple "date-time" values are
+   specified as a COMMA character (US-ASCII decimal 44) separated list
+   of values. No additional content value encoding (i.e., BACKSLASH
+   character encoding) is defined for this value type.
+
+   The "DATE-TIME" data type is used to identify values that contain a
+   precise calendar date and time of day. The format is based on the
+   [ISO 8601] complete representation, basic format for a calendar date
+   and time of day. The text format is a concatenation of the "date",
+   followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal
+   84) time designator, followed by the "time" format.
+
+   The "DATE-TIME" data type expresses time values in three forms:
+
+   The form of date and time with UTC offset MUST NOT be used. For
+   example, the following is not valid for a date-time value:
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 35]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     DTSTART:19980119T230000-0800       ;Invalid time format
+
+   FORM #1: DATE WITH LOCAL TIME
+
+   The date with local time form is simply a date-time value that does
+   not contain the UTC designator nor does it reference a time zone. For
+   example, the following represents Janurary 18, 1998, at 11 PM:
+
+     DTSTART:19980118T230000
+
+   Date-time values of this type are said to be "floating" and are not
+   bound to any time zone in particular. They are used to represent the
+   same hour, minute, and second value regardless of which time zone is
+   currently being observed. For example, an event can be defined that
+   indicates that an individual will be busy from 11:00 AM to 1:00 PM
+   every day, no matter which time zone the person is in. In these
+   cases, a local time can be specified. The recipient of an iCalendar
+   object with a property value consisting of a local time, without any
+   relative time zone information, SHOULD interpret the value as being
+   fixed to whatever time zone the ATTENDEE is in at any given moment.
+   This means that two ATTENDEEs, in different time zones, receiving the
+   same event definition as a floating time, may be participating in the
+   event at different actual times. Floating time SHOULD only be used
+   where that is the reasonable behavior.
+
+   In most cases, a fixed time is desired. To properly communicate a
+   fixed time in a property value, either UTC time or local time with
+   time zone reference MUST be specified.
+
+   The use of local time in a DATE-TIME value without the TZID property
+   parameter is to be interpreted as floating time, regardless of the
+   existence of "VTIMEZONE" calendar components in the iCalendar object.
+
+   FORM #2: DATE WITH UTC TIME
+
+   The date with UTC time, or absolute time, is identified by a LATIN
+   CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC
+   designator, appended to the time value. For example, the following
+   represents January 19, 1998, at 0700 UTC:
+
+     DTSTART:19980119T070000Z
+
+   The TZID property parameter MUST NOT be applied to DATE-TIME
+   properties whose time values are specified in UTC.
+
+   FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 36]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The date and local time with reference to time zone information is
+   identified by the use the TZID property parameter to reference the
+   appropriate time zone definition. TZID is discussed in detail in the
+   section on Time Zone. For example, the following represents 2 AM in
+   New York on Janurary 19, 1998:
+
+          DTSTART;TZID=US-Eastern:19980119T020000
+
+   Example: The following represents July 14, 1997, at 1:30 PM in New
+   York City in each of the three time formats, using the "DTSTART"
+   property.
+
+     DTSTART:19970714T133000            ;Local time
+     DTSTART:19970714T173000Z           ;UTC time
+     DTSTART;TZID=US-Eastern:19970714T133000    ;Local time and time
+                        ; zone reference
+
+   A time value MUST ONLY specify 60 seconds when specifying the
+   periodic "leap second" in the time value. For example:
+
+     COMPLETED:19970630T235960Z
+
+4.3.6   Duration
+
+   Value Name: DURATION
+
+   Purpose: This value type is used to identify properties that contain
+   a duration of time.
+
+   Formal Definition: The value type is defined by the following
+   notation:
+
+     dur-value  = (["+"] / "-") "P" (dur-date / dur-time / dur-week)
+
+     dur-date   = dur-day [dur-time]
+     dur-time   = "T" (dur-hour / dur-minute / dur-second)
+     dur-week   = 1*DIGIT "W"
+     dur-hour   = 1*DIGIT "H" [dur-minute]
+     dur-minute = 1*DIGIT "M" [dur-second]
+     dur-second = 1*DIGIT "S"
+     dur-day    = 1*DIGIT "D"
+
+   Description: If the property permits, multiple "duration" values are
+   specified by a COMMA character (US-ASCII decimal 44) separated list
+   of values. The format is expressed as the [ISO 8601] basic format for
+   the duration of time. The format can represent durations in terms of
+   weeks, days, hours, minutes, and seconds.
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 37]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   No additional content value encoding (i.e., BACKSLASH character
+   encoding) are defined for this value type.
+
+   Example: A duration of 15 days, 5 hours and 20 seconds would be:
+
+     P15DT5H0M20S
+
+   A duration of 7 weeks would be:
+
+     P7W
+
+4.3.7   Float
+
+   Value Name: FLOAT
+
+   Purpose: This value type is used to identify properties that contain
+   a real number value.
+
+   Formal Definition: The value type is defined by the following
+   notation:
+
+     float      = (["+"] / "-") 1*DIGIT ["." 1*DIGIT]
+
+   Description: If the property permits, multiple "float" values are
+   specified by a COMMA character (US-ASCII decimal 44) separated list
+   of values.
+
+   No additional content value encoding (i.e., BACKSLASH character
+   encoding) is defined for this value type.
+
+   Example:
+
+     1000000.0000001
+     1.333
+     -3.14
+
+4.3.8 Integer
+
+     Value Name:INTEGER
+
+     Purpose: This value type is used to identify properties that contain
+     a signed integer value.
+
+     Formal Definition: The value type is defined by the following
+     notation:
+
+     integer    = (["+"] / "-") 1*DIGIT
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 38]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     Description: If the property permits, multiple "integer" values are
+     specified by a COMMA character (US-ASCII decimal 44) separated list
+     of values. The valid range for "integer" is -2147483648 to
+     2147483647. If the sign is not specified, then the value is assumed
+     to be positive.
+
+     No additional content value encoding (i.e., BACKSLASH character
+     encoding) is defined for this value type.
+
+     Example:
+
+     1234567890
+     -1234567890
+     +1234567890
+     432109876
+
+4.3.9 Period of Time
+
+   Value Name: PERIOD
+
+   Purpose: This value type is used to identify values that contain a
+   precise period of time.
+
+   Formal Definition: The data type is defined by the following
+   notation:
+
+     period     = period-explicit / period-start
+
+     period-explicit = date-time "/" date-time
+     ; [ISO 8601] complete representation basic format for a period of
+     ; time consisting of a start and end. The start MUST be before the
+     ; end.
+
+     period-start = date-time "/" dur-value
+     ; [ISO 8601] complete representation basic format for a period of
+     ; time consisting of a start and positive duration of time.
+
+   Description: If the property permits, multiple "period" values are
+   specified by a COMMA character (US-ASCII decimal 44) separated list
+   of values. There are two forms of a period of time. First, a period
+   of time is identified by its start and its end. This format is
+   expressed as the [ISO 8601] complete representation, basic format for
+   "DATE-TIME" start of the period, followed by a SOLIDUS character
+   (US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the
+   period. The start of the period MUST be before the end of the period.
+   Second, a period of time can also be defined by a start and a
+   positive duration of time. The format is expressed as the [ISO 8601]
+   complete representation, basic format for the "DATE-TIME" start of
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 39]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   the period, followed by a SOLIDUS character (US-ASCII decimal 47),
+   followed by the [ISO 8601] basic format for "DURATION" of the period.
+
+   Example: The period starting at 18:00:00 UTC, on January 1, 1997 and
+   ending at 07:00:00 UTC on January 2, 1997 would be:
+
+     19970101T180000Z/19970102T070000Z
+
+   The period start at 18:00:00 on January 1, 1997 and lasting 5 hours
+   and 30 minutes would be:
+
+     19970101T180000Z/PT5H30M
+
+   No additional content value encoding (i.e., BACKSLASH character
+   encoding) is defined for this value type.
+
+4.3.10 Recurrence Rule
+
+   Value Name: RECUR
+
+   Purpose: This value type is used to identify properties that contain
+   a recurrence rule specification.
+
+   Formal Definition: The value type is defined by the following
+   notation:
+
+     recur      = "FREQ"=freq *(
+
+                ; either UNTIL or COUNT may appear in a 'recur',
+                ; but UNTIL and COUNT MUST NOT occur in the same 'recur'
+
+                ( ";" "UNTIL" "=" enddate ) /
+                ( ";" "COUNT" "=" 1*DIGIT ) /
+
+                ; the rest of these keywords are optional,
+                ; but MUST NOT occur more than once
+
+                ( ";" "INTERVAL" "=" 1*DIGIT )          /
+                ( ";" "BYSECOND" "=" byseclist )        /
+                ( ";" "BYMINUTE" "=" byminlist )        /
+                ( ";" "BYHOUR" "=" byhrlist )           /
+                ( ";" "BYDAY" "=" bywdaylist )          /
+                ( ";" "BYMONTHDAY" "=" bymodaylist )    /
+                ( ";" "BYYEARDAY" "=" byyrdaylist )     /
+                ( ";" "BYWEEKNO" "=" bywknolist )       /
+                ( ";" "BYMONTH" "=" bymolist )          /
+                ( ";" "BYSETPOS" "=" bysplist )         /
+                ( ";" "WKST" "=" weekday )              /
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 40]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ( ";" x-name "=" text )
+                )
+
+     freq       = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY"
+                / "WEEKLY" / "MONTHLY" / "YEARLY"
+
+     enddate    = date
+     enddate    =/ date-time            ;An UTC value
+
+     byseclist  = seconds / ( seconds *("," seconds) )
+
+     seconds    = 1DIGIT / 2DIGIT       ;0 to 59
+
+     byminlist  = minutes / ( minutes *("," minutes) )
+
+     minutes    = 1DIGIT / 2DIGIT       ;0 to 59
+
+     byhrlist   = hour / ( hour *("," hour) )
+
+     hour       = 1DIGIT / 2DIGIT       ;0 to 23
+
+     bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) )
+
+     weekdaynum = [([plus] ordwk / minus ordwk)] weekday
+
+     plus       = "+"
+
+     minus      = "-"
+
+     ordwk      = 1DIGIT / 2DIGIT       ;1 to 53
+
+     weekday    = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA"
+     ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY,
+     ;FRIDAY, SATURDAY and SUNDAY days of the week.
+
+     bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) )
+
+     monthdaynum = ([plus] ordmoday) / (minus ordmoday)
+
+     ordmoday   = 1DIGIT / 2DIGIT       ;1 to 31
+
+     byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) )
+
+     yeardaynum = ([plus] ordyrday) / (minus ordyrday)
+
+     ordyrday   = 1DIGIT / 2DIGIT / 3DIGIT      ;1 to 366
+
+     bywknolist = weeknum / ( weeknum *("," weeknum) )
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 41]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     weeknum    = ([plus] ordwk) / (minus ordwk)
+
+     bymolist   = monthnum / ( monthnum *("," monthnum) )
+
+     monthnum   = 1DIGIT / 2DIGIT       ;1 to 12
+
+     bysplist   = setposday / ( setposday *("," setposday) )
+
+     setposday  = yeardaynum
+
+   Description: If the property permits, multiple "recur" values are
+   specified by a COMMA character (US-ASCII decimal 44) separated list
+   of values. The value type is a structured value consisting of a list
+   of one or more recurrence grammar parts. Each rule part is defined by
+   a NAME=VALUE pair. The rule parts are separated from each other by
+   the SEMICOLON character (US-ASCII decimal 59). The rule parts are not
+   ordered in any particular sequence. Individual rule parts MUST only
+   be specified once.
+
+   The FREQ rule part identifies the type of recurrence rule. This rule
+   part MUST be specified in the recurrence rule. Valid values include
+   SECONDLY, to specify repeating events based on an interval of a
+   second or more; MINUTELY, to specify repeating events based on an
+   interval of a minute or more; HOURLY, to specify repeating events
+   based on an interval of an hour or more; DAILY, to specify repeating
+   events based on an interval of a day or more; WEEKLY, to specify
+   repeating events based on an interval of a week or more; MONTHLY, to
+   specify repeating events based on an interval of a month or more; and
+   YEARLY, to specify repeating events based on an interval of a year or
+   more.
+
+   The INTERVAL rule part contains a positive integer representing how
+   often the recurrence rule repeats. The default value is "1", meaning
+   every second for a SECONDLY rule, or every minute for a MINUTELY
+   rule, every hour for an HOURLY rule, every day for a DAILY rule,
+   every week for a WEEKLY rule, every month for a MONTHLY rule and
+   every year for a YEARLY rule.
+
+   The UNTIL rule part defines a date-time value which bounds the
+   recurrence rule in an inclusive manner. If the value specified by
+   UNTIL is synchronized with the specified recurrence, this date or
+   date-time becomes the last instance of the recurrence. If specified
+   as a date-time value, then it MUST be specified in an UTC time
+   format. If not present, and the COUNT rule part is also not present,
+   the RRULE is considered to repeat forever.
+
+   The COUNT rule part defines the number of occurrences at which to
+   range-bound the recurrence. The "DTSTART" property value, if
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 42]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   specified, counts as the first occurrence.
+
+   The BYSECOND rule part specifies a COMMA character (US-ASCII decimal
+   44) separated list of seconds within a minute. Valid values are 0 to
+   59. The BYMINUTE rule part specifies a COMMA character (US-ASCII
+   decimal 44) separated list of minutes within an hour. Valid values
+   are 0 to 59. The BYHOUR rule part specifies a COMMA character (US-
+   ASCII decimal 44) separated list of hours of the day. Valid values
+   are 0 to 23.
+
+   The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44)
+   separated list of days of the week; MO indicates Monday; TU indicates
+   Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates
+   Friday; SA indicates Saturday; SU indicates Sunday.
+
+   Each BYDAY value can also be preceded by a positive (+n) or negative
+   (-n) integer. If present, this indicates the nth occurrence of the
+   specific day within the MONTHLY or YEARLY RRULE. For example, within
+   a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday
+   within the month, whereas -1MO represents the last Monday of the
+   month. If an integer modifier is not present, it means all days of
+   this type within the specified frequency. For example, within a
+   MONTHLY rule, MO represents all Mondays within the month.
+
+   The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal
+   44) separated list of days of the month. Valid values are 1 to 31 or
+   -31 to -1. For example, -10 represents the tenth to the last day of
+   the month.
+
+   The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal
+   44) separated list of days of the year. Valid values are 1 to 366 or
+   -366 to -1. For example, -1 represents the last day of the year
+   (December 31st) and -306 represents the 306th to the last day of the
+   year (March 1st).
+
+   The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal
+   44) separated list of ordinals specifying weeks of the year. Valid
+   values are 1 to 53 or -53 to -1. This corresponds to weeks according
+   to week numbering as defined in [ISO 8601]. A week is defined as a
+   seven day period, starting on the day of the week defined to be the
+   week start (see WKST). Week number one of the calendar year is the
+   first week which contains at least four (4) days in that calendar
+   year. This rule part is only valid for YEARLY rules. For example, 3
+   represents the third week of the year.
+
+        Note: Assuming a Monday week start, week 53 can only occur when
+        Thursday is January 1 or if it is a leap year and Wednesday is
+        January 1.
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 43]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The BYMONTH rule part specifies a COMMA character (US-ASCII decimal
+   44) separated list of months of the year. Valid values are 1 to 12.
+
+   The WKST rule part specifies the day on which the workweek starts.
+   Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant
+   when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule
+   part is specified. This is also significant when in a YEARLY RRULE
+   when a BYWEEKNO rule part is specified. The default value is MO.
+
+   The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal
+   44) separated list of values which corresponds to the nth occurrence
+   within the set of events specified by the rule. Valid values are 1 to
+   366 or -366 to -1. It MUST only be used in conjunction with another
+   BYxxx rule part. For example "the last work day of the month" could
+   be represented as:
+
+     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1
+
+   Each BYSETPOS value can include a positive (+n) or negative (-n)
+   integer. If present, this indicates the nth occurrence of the
+   specific occurrence within the set of events specified by the rule.
+
+   If BYxxx rule part values are found which are beyond the available
+   scope (ie, BYMONTHDAY=30 in February), they are simply ignored.
+
+   Information, not contained in the rule, necessary to determine the
+   various recurrence instance start time and dates are derived from the
+   Start Time (DTSTART) entry attribute. For example,
+   "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the
+   month or a time. This information would be the same as what is
+   specified for DTSTART.
+
+   BYxxx rule parts modify the recurrence in some manner. BYxxx rule
+   parts for a period of time which is the same or greater than the
+   frequency generally reduce or limit the number of occurrences of the
+   recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the
+   number of recurrence instances from all days (if BYMONTH tag is not
+   present) to all days in January. BYxxx rule parts for a period of
+   time less than the frequency generally increase or expand the number
+   of occurrences of the recurrence. For example,
+   "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the
+   yearly recurrence set from 1 (if BYMONTH tag is not present) to 2.
+
+   If multiple BYxxx rule parts are specified, then after evaluating the
+   specified FREQ and INTERVAL rule parts, the BYxxx rule parts are
+   applied to the current set of evaluated occurrences in the following
+   order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR,
+   BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated.
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 44]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Here is an example of evaluating multiple BYxxx rule parts.
+
+     DTSTART;TZID=US-Eastern:19970105T083000
+     RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9;
+      BYMINUTE=30
+
+   First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive
+   at "every other year". Then, "BYMONTH=1" would be applied to arrive
+   at "every January, every other year". Then, "BYDAY=SU" would be
+   applied to arrive at "every Sunday in January, every other year".
+   Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in
+   January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30"
+   would be applied to arrive at "every Sunday in January at 8:30 AM and
+   9:30 AM, every other year". Then, lacking information from RRULE, the
+   second is derived from DTSTART, to end up in "every Sunday in January
+   at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the
+   BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were
+   missing, the appropriate minute, hour, day or month would have been
+   retrieved from the "DTSTART" property.
+
+   No additional content value encoding (i.e., BACKSLASH character
+   encoding) is defined for this value type.
+
+   Example: The following is a rule which specifies 10 meetings which
+   occur every other day:
+
+     FREQ=DAILY;COUNT=10;INTERVAL=2
+
+   There are other examples specified in the "RRULE" specification.
+
+4.3.11 Text
+
+   Value Name: TEXT
+
+   Purpose This value type is used to identify values that contain human
+   readable text.
+
+   Formal Definition: The character sets supported by this revision of
+   iCalendar are UTF-8 and US ASCII thereof. The applicability to other
+   character sets is for future work. The value type is defined by the
+   following notation.
+
+     text       = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR)
+     ; Folded according to description above
+
+     ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n")
+        ; \\ encodes \, \N or \n encodes newline
+        ; \; encodes ;, \, encodes ,
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 45]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B
+                  %x5D-7E / NON-US-ASCII
+        ; Any character except CTLs not needed by the current
+        ; character set, DQUOTE, ";", ":", "\", ","
+
+     Note: Certain other character sets may require modification of the
+     above definitions, but this is beyond the scope of this document.
+
+   Description: If the property permits, multiple "text" values are
+   specified by a COMMA character (US-ASCII decimal 44) separated list
+   of values.
+
+   The language in which the text is represented can be controlled by
+   the "LANGUAGE" property parameter.
+
+   An intentional formatted text line break MUST only be included in a
+   "TEXT" property value by representing the line break with the
+   character sequence of BACKSLASH (US-ASCII decimal 92), followed by a
+   LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER
+   N (US-ASCII decimal 78), that is "\n" or "\N".
+
+   The "TEXT" property values may also contain special characters that
+   are used to signify delimiters, such as a COMMA character for lists
+   of values or a SEMICOLON character for structured values. In order to
+   support the inclusion of these special characters in "TEXT" property
+   values, they MUST be escaped with a BACKSLASH character. A BACKSLASH
+   character (US-ASCII decimal 92) in a "TEXT" property value MUST be
+   escaped with another BACKSLASH character. A COMMA character in a
+   "TEXT" property value MUST be escaped with a BACKSLASH character
+   (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property
+   value MUST be escaped with a BACKSLASH character (US-ASCII decimal
+   92).  However, a COLON character in a "TEXT" property value SHALL NOT
+   be escaped with a BACKSLASH character.Example: A multiple line value
+   of:
+
+     Project XYZ Final Review
+     Conference Room - 3B
+     Come Prepared.
+
+   would be represented as:
+
+     Project XYZ Final Review\nConference Room - 3B\nCome Prepared.
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 46]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.3.12 Time
+
+   Value Name: TIME
+
+   Purpose: This value type is used to identify values that contain a
+   time of day.
+
+   Formal Definition: The data type is defined by the following
+   notation:
+
+     time               = time-hour time-minute time-second [time-utc]
+
+     time-hour          = 2DIGIT        ;00-23
+     time-minute        = 2DIGIT        ;00-59
+     time-second        = 2DIGIT        ;00-60
+     ;The "60" value is used to account for "leap" seconds.
+
+     time-utc   = "Z"
+
+   Description: If the property permits, multiple "time" values are
+   specified by a COMMA character (US-ASCII decimal 44) separated list
+   of values. No additional content value encoding (i.e., BACKSLASH
+   character encoding) is defined for this value type.
+
+   The "TIME" data type is used to identify values that contain a time
+   of day. The format is based on the [ISO 8601] complete
+   representation, basic format for a time of day. The text format
+   consists of a two-digit 24-hour of the day (i.e., values 0-23), two-
+   digit minute in the hour (i.e., values 0-59), and two-digit seconds
+   in the minute (i.e., values 0-60). The seconds value of 60 MUST only
+   to be used to account for "leap" seconds. Fractions of a second are
+   not supported by this format.
+
+   In parallel to the "DATE-TIME" definition above, the "TIME" data type
+   expresses time values in three forms:
+
+   The form of time with UTC offset MUST NOT be used. For example, the
+   following is NOT VALID for a time value:
+
+     230000-0800        ;Invalid time format
+
+   FORM #1 LOCAL TIME
+
+   The local time form is simply a time value that does not contain the
+   UTC designator nor does it reference a time zone. For example, 11:00
+   PM:
+
+     230000
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 47]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Time values of this type are said to be "floating" and are not bound
+   to any time zone in particular. They are used to represent the same
+   hour, minute, and second value regardless of which time zone is
+   currently being observed. For example, an event can be defined that
+   indicates that an individual will be busy from 11:00 AM to 1:00 PM
+   every day, no matter which time zone the person is in. In these
+   cases, a local time can be specified. The recipient of an iCalendar
+   object with a property value consisting of a local time, without any
+   relative time zone information, SHOULD interpret the value as being
+   fixed to whatever time zone the ATTENDEE is in at any given moment.
+   This means that two ATTENDEEs may participate in the same event at
+   different UTC times; floating time SHOULD only be used where that is
+   reasonable behavior.
+
+   In most cases, a fixed time is desired. To properly communicate a
+   fixed time in a property value, either UTC time or local time with
+   time zone reference MUST be specified.
+
+   The use of local time in a TIME value without the TZID property
+   parameter is to be interpreted as a local time value, regardless of
+   the existence of "VTIMEZONE" calendar components in the iCalendar
+   object.
+
+   FORM #2: UTC TIME
+
+   UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z
+   suffix character (US-ASCII decimal 90), the UTC designator, appended
+   to the time value. For example, the following represents 07:00 AM
+   UTC:
+
+     070000Z
+
+   The TZID property parameter MUST NOT be applied to TIME properties
+   whose time values are specified in UTC.
+
+   FORM #3: LOCAL TIME AND TIME ZONE REFERENCE
+
+   The local time with reference to time zone information form is
+   identified by the use the TZID property parameter to reference the
+   appropriate time zone definition. TZID is discussed in detail in the
+   section on Time Zone.
+
+   Example: The following represents 8:30 AM in New York in Winter, five
+   hours behind UTC, in each of the three formats using the "X-
+   TIMEOFDAY" non-standard property:
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 48]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     X-TIMEOFDAY:083000
+
+     X-TIMEOFDAY:133000Z
+
+     X-TIMEOFDAY;TZID=US-Eastern:083000
+
+4.3.13 URI
+
+   Value Name: URI
+
+   Purpose: This value type is used to identify values that contain a
+   uniform resource identifier (URI) type of reference to the property
+   value.
+
+   Formal Definition: The data type is defined by the following
+   notation:
+
+     uri        = <As defined by any IETF RFC>
+
+   Description: This data type might be used to reference binary
+   information, for values that are large, or otherwise undesirable to
+   include directly in the iCalendar object.
+
+   The URI value formats in RFC 1738, RFC 2111 and any other IETF
+   registered value format can be specified.
+
+   Any IANA registered URI format can be used. These include, but are
+   not limited to, those defined in RFC 1738 and RFC 2111.
+
+   When a property parameter value is a URI value type, the URI MUST be
+   specified as a quoted-string value.
+
+   No additional content value encoding (i.e., BACKSLASH character
+   encoding) is defined for this value type.
+
+   Example: The following is a URI for a network file:
+
+     http://host1.com/my-report.txt
+
+4.3.14 UTC Offset
+
+   Value Name: UTC-OFFSET
+
+   Purpose: This value type is used to identify properties that contain
+   an offset from UTC to local time.
+
+   Formal Definition: The data type is defined by the following
+   notation:
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 49]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     utc-offset = time-numzone  ;As defined above in time data type
+
+     time-numzone       = ("+" / "-") time-hour time-minute [time-
+     second]
+
+   Description: The PLUS SIGN character MUST be specified for positive
+   UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000"
+   are not allowed. The time-second, if present, may not be 60; if
+   absent, it defaults to zero.
+
+   No additional content value encoding (i.e., BACKSLASH character
+   encoding) is defined for this value type.
+
+   Example: The following UTC offsets are given for standard time for
+   New York (five hours behind UTC) and Geneva (one hour ahead of UTC):
+
+     -0500
+
+     +0100
+
+4.4 iCalendar Object
+
+   The Calendaring and Scheduling Core Object is a collection of
+   calendaring and scheduling information. Typically, this information
+   will consist of a single iCalendar object. However, multiple
+   iCalendar objects can be sequentially grouped together. The first
+   line and last line of the iCalendar object MUST contain a pair of
+   iCalendar object delimiter strings. The syntax for an iCalendar
+   object is as follows:
+
+     icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF
+                  icalbody
+                  "END" ":" "VCALENDAR" CRLF)
+
+   The following is a simple example of an iCalendar object:
+
+     BEGIN:VCALENDAR
+     VERSION:2.0
+     PRODID:-//hacksw/handcal//NONSGML v1.0//EN
+     BEGIN:VEVENT
+     DTSTART:19970714T170000Z
+     DTEND:19970715T035959Z
+     SUMMARY:Bastille Day Party
+     END:VEVENT
+     END:VCALENDAR
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 50]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.5 Property
+
+   A property is the definition of an individual attribute describing a
+   calendar or a calendar component. A property takes the form defined
+   by the "contentline" notation defined in section 4.1.1.
+
+   The following is an example of a property:
+
+     DTSTART:19960415T133000Z
+
+   This memo imposes no ordering of properties within an iCalendar
+   object.
+
+   Property names, parameter names and enumerated parameter values are
+   case insensitive. For example, the property name "DUE" is the same as
+   "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same
+   as DtStart;TzID=US-Eastern:19980714T120000.
+
+4.6 Calendar Components
+
+   The body of the iCalendar object consists of a sequence of calendar
+   properties and one or more calendar components. The calendar
+   properties are attributes that apply to the calendar as a whole. The
+   calendar components are collections of properties that express a
+   particular calendar semantic. For example, the calendar component can
+   specify an event, a to-do, a journal entry, time zone information, or
+   free/busy time information, or an alarm.
+
+   The body of the iCalendar object is defined by the following
+   notation:
+
+     icalbody   = calprops component
+
+     calprops   = 2*(
+
+                ; 'prodid' and 'version' are both REQUIRED,
+                ; but MUST NOT occur more than once
+
+                prodid /version /
+
+                ; 'calscale' and 'method' are optional,
+                ; but MUST NOT occur more than once
+
+                calscale        /
+                method          /
+
+                x-prop
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 51]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                )
+
+     component  = 1*(eventc / todoc / journalc / freebusyc /
+                / timezonec / iana-comp / x-comp)
+
+     iana-comp  = "BEGIN" ":" iana-token CRLF
+
+                  1*contentline
+
+                  "END" ":" iana-token CRLF
+
+     x-comp     = "BEGIN" ":" x-name CRLF
+
+                  1*contentline
+
+                  "END" ":" x-name CRLF
+
+   An iCalendar object MUST include the "PRODID" and "VERSION" calendar
+   properties. In addition, it MUST include at least one calendar
+   component. Special forms of iCalendar objects are possible to publish
+   just busy time (i.e., only a "VFREEBUSY" calendar component) or time
+   zone (i.e., only a "VTIMEZONE" calendar component) information. In
+   addition, a complex iCalendar object is possible that is used to
+   capture a complete snapshot of the contents of a calendar (e.g.,
+   composite of many different calendar components). More commonly, an
+   iCalendar object will consist of just a single "VEVENT", "VTODO" or
+   "VJOURNAL" calendar component.
+
+4.6.1 Event Component
+
+   Component Name: "VEVENT"
+
+   Purpose: Provide a grouping of component properties that describe an
+   event.
+
+   Format Definition: A "VEVENT" calendar component is defined by the
+   following notation:
+
+     eventc     = "BEGIN" ":" "VEVENT" CRLF
+                  eventprop *alarmc
+                  "END" ":" "VEVENT" CRLF
+
+     eventprop  = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                class / created / description / dtstart / geo /
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 52]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                last-mod / location / organizer / priority /
+                dtstamp / seq / status / summary / transp /
+                uid / url / recurid /
+
+                ; either 'dtend' or 'duration' may appear in
+                ; a 'eventprop', but 'dtend' and 'duration'
+                ; MUST NOT occur in the same 'eventprop'
+
+                dtend / duration /
+
+                ; the following are optional,
+                ; and MAY occur more than once
+
+                attach / attendee / categories / comment /
+                contact / exdate / exrule / rstatus / related /
+                resources / rdate / rrule / x-prop
+
+                )
+
+   Description: A "VEVENT" calendar component is a grouping of component
+   properties, and possibly including "VALARM" calendar components, that
+   represents a scheduled amount of time on a calendar. For example, it
+   can be an activity; such as a one-hour long, department meeting from
+   8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time
+   on an individual calendar. Hence, the event will appear as an opaque
+   interval in a search for busy time. Alternately, the event can have
+   its Time Transparency set to "TRANSPARENT" in order to prevent
+   blocking of the event in searches for busy time.
+
+   The "VEVENT" is also the calendar component used to specify an
+   anniversary or daily reminder within a calendar. These events have a
+   DATE value type for the "DTSTART" property instead of the default
+   data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it
+   MUST be specified as a DATE value also. The anniversary type of
+   "VEVENT" can span more than one date (i.e, "DTEND" property value is
+   set to a calendar date after the "DTSTART" property value).
+
+   The "DTSTART" property for a "VEVENT" specifies the inclusive start
+   of the event. For recurring events, it also specifies the very first
+   instance in the recurrence set. The "DTEND" property for a "VEVENT"
+   calendar component specifies the non-inclusive end of the event. For
+   cases where a "VEVENT" calendar component specifies a "DTSTART"
+   property with a DATE data type but no "DTEND" property, the events
+   non-inclusive end is the end of the calendar date specified by the
+   "DTSTART" property. For cases where a "VEVENT" calendar component
+   specifies a "DTSTART" property with a DATE-TIME data type but no
+   "DTEND" property, the event ends on the same calendar date and time
+   of day specified by the "DTSTART" property.
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 53]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The "VEVENT" calendar component cannot be nested within another
+   calendar component. However, "VEVENT" calendar components can be
+   related to each other or to a "VTODO" or to a "VJOURNAL" calendar
+   component with the "RELATED-TO" property.
+
+   Example: The following is an example of the "VEVENT" calendar
+   component used to represent a meeting that will also be opaque to
+   searches for busy time:
+
+     BEGIN:VEVENT
+     UID:19970901T130000Z-123401@host.com
+     DTSTAMP:19970901T1300Z
+     DTSTART:19970903T163000Z
+     DTEND:19970903T190000Z
+     SUMMARY:Annual Employee Review
+     CLASS:PRIVATE
+     CATEGORIES:BUSINESS,HUMAN RESOURCES
+     END:VEVENT
+
+   The following is an example of the "VEVENT" calendar component used
+   to represent a reminder that will not be opaque, but rather
+   transparent, to searches for busy time:
+
+     BEGIN:VEVENT
+     UID:19970901T130000Z-123402@host.com
+     DTSTAMP:19970901T1300Z
+     DTSTART:19970401T163000Z
+     DTEND:19970402T010000Z
+     SUMMARY:Laurel is in sensitivity awareness class.
+     CLASS:PUBLIC
+     CATEGORIES:BUSINESS,HUMAN RESOURCES
+     TRANSP:TRANSPARENT
+     END:VEVENT
+
+   The following is an example of the "VEVENT" calendar component used
+   to represent an anniversary that will occur annually. Since it takes
+   up no time, it will not appear as opaque in a search for busy time;
+   no matter what the value of the "TRANSP" property indicates:
+
+     BEGIN:VEVENT
+     UID:19970901T130000Z-123403@host.com
+     DTSTAMP:19970901T1300Z
+     DTSTART:19971102
+     SUMMARY:Our Blissful Anniversary
+     CLASS:CONFIDENTIAL
+     CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION
+     RRULE:FREQ=YEARLY
+     END:VEVENT
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 54]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.6.2 To-do Component
+
+   Component Name: VTODO
+
+   Purpose: Provide a grouping of calendar properties that describe a
+   to-do.
+
+   Formal Definition: A "VTODO" calendar component is defined by the
+   following notation:
+
+     todoc      = "BEGIN" ":" "VTODO" CRLF
+                  todoprop *alarmc
+                  "END" ":" "VTODO" CRLF
+
+     todoprop   = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                class / completed / created / description / dtstamp /
+                dtstart / geo / last-mod / location / organizer /
+                percent / priority / recurid / seq / status /
+                summary / uid / url /
+
+                ; either 'due' or 'duration' may appear in
+                ; a 'todoprop', but 'due' and 'duration'
+                ; MUST NOT occur in the same 'todoprop'
+
+                due / duration /
+
+                ; the following are optional,
+                ; and MAY occur more than once
+                attach / attendee / categories / comment / contact /
+                exdate / exrule / rstatus / related / resources /
+                rdate / rrule / x-prop
+
+                )
+
+   Description: A "VTODO" calendar component is a grouping of component
+   properties and possibly "VALARM" calendar components that represent
+   an action-item or assignment. For example, it can be used to
+   represent an item of work assigned to an individual; such as "turn in
+   travel expense today".
+
+   The "VTODO" calendar component cannot be nested within another
+   calendar component. However, "VTODO" calendar components can be
+   related to each other or to a "VTODO" or to a "VJOURNAL" calendar
+   component with the "RELATED-TO" property.
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 55]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   A "VTODO" calendar component without the "DTSTART" and "DUE" (or
+   "DURATION") properties specifies a to-do that will be associated with
+   each successive calendar date, until it is completed.
+
+   Example: The following is an example of a "VTODO" calendar component:
+
+     BEGIN:VTODO
+     UID:19970901T130000Z-123404@host.com
+     DTSTAMP:19970901T1300Z
+     DTSTART:19970415T133000Z
+     DUE:19970416T045959Z
+     SUMMARY:1996 Income Tax Preparation
+     CLASS:CONFIDENTIAL
+     CATEGORIES:FAMILY,FINANCE
+     PRIORITY:1
+     STATUS:NEEDS-ACTION
+     END:VTODO
+
+4.6.3 Journal Component
+
+   Component Name: VJOURNAL
+
+   Purpose: Provide a grouping of component properties that describe a
+   journal entry.
+
+   Formal Definition: A "VJOURNAL" calendar component is defined by the
+   following notation:
+
+     journalc   = "BEGIN" ":" "VJOURNAL" CRLF
+                  jourprop
+                  "END" ":" "VJOURNAL" CRLF
+
+     jourprop   = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                class / created / description / dtstart / dtstamp /
+                last-mod / organizer / recurid / seq / status /
+                summary / uid / url /
+
+                ; the following are optional,
+                ; and MAY occur more than once
+
+                attach / attendee / categories / comment /
+                contact / exdate / exrule / related / rdate /
+                rrule / rstatus / x-prop
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 56]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                )
+
+   Description: A "VJOURNAL" calendar component is a grouping of
+   component properties that represent one or more descriptive text
+   notes associated with a particular calendar date. The "DTSTART"
+   property is used to specify the calendar date that the journal entry
+   is associated with. Generally, it will have a DATE value data type,
+   but it can also be used to specify a DATE-TIME value data type.
+   Examples of a journal entry include a daily record of a legislative
+   body or a journal entry of individual telephone contacts for the day
+   or an ordered list of accomplishments for the day. The "VJOURNAL"
+   calendar component can also be used to associate a document with a
+   calendar date.
+
+   The "VJOURNAL" calendar component does not take up time on a
+   calendar. Hence, it does not play a role in free or busy time
+   searches - - it is as though it has a time transparency value of
+   TRANSPARENT. It is transparent to any such searches.
+
+   The "VJOURNAL" calendar component cannot be nested within another
+   calendar component. However, "VJOURNAL" calendar components can be
+   related to each other or to a "VEVENT" or to a "VTODO" calendar
+   component, with the "RELATED-TO" property.
+
+   Example: The following is an example of the "VJOURNAL" calendar
+   component:
+
+     BEGIN:VJOURNAL
+     UID:19970901T130000Z-123405@host.com
+     DTSTAMP:19970901T1300Z
+     DTSTART;VALUE=DATE:19970317
+     SUMMARY:Staff meeting minutes
+     DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa
+       and Bob. Aurora project plans were reviewed. There is currently
+       no budget reserves for this project. Lisa will escalate to
+       management. Next meeting on Tuesday.\n
+       2. Telephone Conference: ABC Corp. sales representative called
+       to discuss new printer. Promised to get us a demo by Friday.\n
+       3. Henry Miller (Handsoff Insurance): Car was totaled by tree.
+       Is looking into a loaner car. 654-2323 (tel).
+     END:VJOURNAL
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 57]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.6.4 Free/Busy Component
+
+   Component Name: VFREEBUSY
+
+   Purpose: Provide a grouping of component properties that describe
+   either a request for free/busy time, describe a response to a request
+   for free/busy time or describe a published set of busy time.
+
+   Formal Definition: A "VFREEBUSY" calendar component is defined by the
+   following notation:
+
+     freebusyc  = "BEGIN" ":" "VFREEBUSY" CRLF
+                  fbprop
+                  "END" ":" "VFREEBUSY" CRLF
+
+     fbprop     = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                contact / dtstart / dtend / duration / dtstamp /
+                organizer / uid / url /
+
+                ; the following are optional,
+                ; and MAY occur more than once
+
+                attendee / comment / freebusy / rstatus / x-prop
+
+                )
+
+   Description: A "VFREEBUSY" calendar component is a grouping of
+   component properties that represents either a request for, a reply to
+   a request for free or busy time information or a published set of
+   busy time information.
+
+   When used to request free/busy time information, the "ATTENDEE"
+   property specifies the calendar users whose free/busy time is being
+   requested; the "ORGANIZER" property specifies the calendar user who
+   is requesting the free/busy time; the "DTSTART" and "DTEND"
+   properties specify the window of time for which the free/busy time is
+   being requested; the "UID" and "DTSTAMP" properties are specified to
+   assist in proper sequencing of multiple free/busy time requests.
+
+   When used to reply to a request for free/busy time, the "ATTENDEE"
+   property specifies the calendar user responding to the free/busy time
+   request; the "ORGANIZER" property specifies the calendar user that
+   originally requested the free/busy time; the "FREEBUSY" property
+   specifies the free/busy time information (if it exists); and the
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 58]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   "UID" and "DTSTAMP" properties are specified to assist in proper
+   sequencing of multiple free/busy time replies.
+
+   When used to publish busy time, the "ORGANIZER" property specifies
+   the calendar user associated with the published busy time; the
+   "DTSTART" and "DTEND" properties specify an inclusive time window
+   that surrounds the busy time information; the "FREEBUSY" property
+   specifies the published busy time information; and the "DTSTAMP"
+   property specifies the date/time that iCalendar object was created.
+
+   The "VFREEBUSY" calendar component cannot be nested within another
+   calendar component. Multiple "VFREEBUSY" calendar components can be
+   specified within an iCalendar object. This permits the grouping of
+   Free/Busy information into logical collections, such as monthly
+   groups of busy time information.
+
+   The "VFREEBUSY" calendar component is intended for use in iCalendar
+   object methods involving requests for free time, requests for busy
+   time, requests for both free and busy, and the associated replies.
+
+   Free/Busy information is represented with the "FREEBUSY" property.
+   This property provides a terse representation of time periods. One or
+   more "FREEBUSY" properties can be specified in the "VFREEBUSY"
+   calendar component.
+
+   When present in a "VFREEBUSY" calendar component, the "DTSTART" and
+   "DTEND" properties SHOULD be specified prior to any "FREEBUSY"
+   properties. In a free time request, these properties can be used in
+   combination with the "DURATION" property to represent a request for a
+   duration of free time within a specified window of time.
+
+   The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are
+   not permitted within a "VFREEBUSY" calendar component. Any recurring
+   events are resolved into their individual busy time periods using the
+   "FREEBUSY" property.
+
+   Example: The following is an example of a "VFREEBUSY" calendar
+   component used to request free or busy time information:
+
+     BEGIN:VFREEBUSY
+     ORGANIZER:MAILTO:jane_doe@host1.com
+     ATTENDEE:MAILTO:john_public@host2.com
+     DTSTART:19971015T050000Z
+     DTEND:19971016T050000Z
+     DTSTAMP:19970901T083000Z
+     END:VFREEBUSY
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 59]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The following is an example of a "VFREEBUSY" calendar component used
+   to reply to the request with busy time information:
+
+     BEGIN:VFREEBUSY
+     ORGANIZER:MAILTO:jane_doe@host1.com
+     ATTENDEE:MAILTO:john_public@host2.com
+     DTSTAMP:19970901T100000Z
+     FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M,
+      19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M
+     URL:http://host2.com/pub/busy/jpublic-01.ifb
+     COMMENT:This iCalendar file contains busy time information for
+       the next three months.
+     END:VFREEBUSY
+
+   The following is an example of a "VFREEBUSY" calendar component used
+   to publish busy time information.
+
+     BEGIN:VFREEBUSY
+     ORGANIZER:jsmith@host.com
+     DTSTART:19980313T141711Z
+     DTEND:19980410T141711Z
+     FREEBUSY:19980314T233000Z/19980315T003000Z
+     FREEBUSY:19980316T153000Z/19980316T163000Z
+     FREEBUSY:19980318T030000Z/19980318T040000Z
+     URL:http://www.host.com/calendar/busytime/jsmith.ifb
+     END:VFREEBUSY
+
+4.6.5 Time Zone Component
+
+   Component Name: VTIMEZONE
+
+   Purpose: Provide a grouping of component properties that defines a
+   time zone.
+
+   Formal Definition: A "VTIMEZONE" calendar component is defined by the
+   following notation:
+
+     timezonec  = "BEGIN" ":" "VTIMEZONE" CRLF
+
+                  2*(
+
+                  ; 'tzid' is required, but MUST NOT occur more
+                  ; than once
+
+                tzid /
+
+                  ; 'last-mod' and 'tzurl' are optional,
+                but MUST NOT occur more than once
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 60]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                last-mod / tzurl /
+
+                  ; one of 'standardc' or 'daylightc' MUST occur
+                ..; and each MAY occur more than once.
+
+                standardc / daylightc /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                  x-prop
+
+                  )
+
+                  "END" ":" "VTIMEZONE" CRLF
+
+     standardc  = "BEGIN" ":" "STANDARD" CRLF
+
+                  tzprop
+
+                  "END" ":" "STANDARD" CRLF
+
+     daylightc  = "BEGIN" ":" "DAYLIGHT" CRLF
+
+                  tzprop
+
+                  "END" ":" "DAYLIGHT" CRLF
+
+     tzprop     = 3*(
+
+                ; the following are each REQUIRED,
+                ; but MUST NOT occur more than once
+
+                dtstart / tzoffsetto / tzoffsetfrom /
+
+                ; the following are optional,
+                ; and MAY occur more than once
+
+                comment / rdate / rrule / tzname / x-prop
+
+                )
+
+   Description: A time zone is unambiguously defined by the set of time
+   measurement rules determined by the governing body for a given
+   geographic area. These rules describe at a minimum the base  offset
+   from UTC for the time zone, often referred to as the Standard Time
+   offset. Many locations adjust their Standard Time forward or backward
+   by one hour, in order to accommodate seasonal changes in number of
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 61]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   daylight hours, often referred to as Daylight  Saving Time. Some
+   locations adjust their time by a fraction of an hour. Standard Time
+   is also known as Winter Time. Daylight Saving Time is also known as
+   Advanced Time, Summer Time, or Legal Time in certain countries. The
+   following table shows the changes in time zone rules in effect for
+   New York City starting from 1967. Each line represents a description
+   or rule for a particular observance.
+
+     Effective Observance Rule
+
+     Date       (Date/Time)             Offset  Abbreviation
+
+     1967-*     last Sun in Oct, 02:00  -0500   EST
+
+     1967-1973  last Sun in Apr, 02:00  -0400   EDT
+
+     1974-1974  Jan 6,  02:00           -0400   EDT
+
+     1975-1975  Feb 23, 02:00           -0400   EDT
+
+     1976-1986  last Sun in Apr, 02:00  -0400   EDT
+
+     1987-*     first Sun in Apr, 02:00 -0400   EDT
+
+        Note: The specification of a global time zone registry is not
+        addressed by this document and is left for future study.
+        However, implementers may find the Olson time zone database [TZ]
+        a useful reference. It is an informal, public-domain collection
+        of time zone information, which is currently being maintained by
+        volunteer Internet participants, and is used in several
+        operating systems. This database contains current and historical
+        time zone information for a wide variety of locations around the
+        globe; it provides a time zone identifier for every unique time
+        zone rule set in actual use since 1970, with historical data
+        going back to the introduction of standard time.
+
+   Interoperability between two calendaring and scheduling applications,
+   especially for recurring events, to-dos or journal entries, is
+   dependent on the ability to capture and convey date and time
+   information in an unambiguous format. The specification of current
+   time zone information is integral to this behavior.
+
+   If present, the "VTIMEZONE" calendar component defines the set of
+   Standard Time and Daylight Saving Time observances (or rules) for a
+   particular time zone for a given interval of time. The "VTIMEZONE"
+   calendar component cannot be nested within other calendar components.
+   Multiple "VTIMEZONE" calendar components can exist in an iCalendar
+   object. In this situation, each "VTIMEZONE" MUST represent a unique
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 62]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   time zone definition. This is necessary for some classes of events,
+   such as airline flights, that start in one time zone and end in
+   another.
+
+   The "VTIMEZONE" calendar component MUST be present if the iCalendar
+   object contains an RRULE that generates dates on both sides of a time
+   zone shift (e.g. both in Standard Time and Daylight Saving Time)
+   unless the iCalendar object intends to convey a floating time (See
+   the section "4.1.10.11 Time" for proper interpretation of floating
+   time). It can be present if the iCalendar object does not contain
+   such a RRULE. In addition, if a RRULE is present, there MUST be valid
+   time zone information for all recurrence instances.
+
+   The "VTIMEZONE" calendar component MUST include the "TZID" property
+   and at least one definition of a standard or daylight component. The
+   standard or daylight component MUST include the "DTSTART",
+   "TZOFFSETFROM" and "TZOFFSETTO" properties.
+
+   An individual "VTIMEZONE" calendar component MUST be specified for
+   each unique "TZID" parameter value specified in the iCalendar object.
+
+   Each "VTIMEZONE" calendar component consists of a collection of one
+   or more sub-components that describe the rule for a particular
+   observance (either a Standard Time or a Daylight Saving Time
+   observance). The "STANDARD" sub-component consists of a collection of
+   properties that describe Standard Time. The "DAYLIGHT" sub-component
+   consists of a collection of properties that describe Daylight Saving
+   Time. In general this collection of properties consists of:
+
+        - the first onset date-time for the observance
+
+        - the last onset date-time for the observance, if a last onset
+          is known.
+
+        - the offset to be applied for the observance
+
+        - a rule that describes the day and time when the observance
+          takes effect
+
+        - an optional name for the observance
+
+   For a given time zone, there may be multiple unique definitions of
+   the observances over a period of time. Each observance is described
+   using either a "STANDARD" or "DAYLIGHT" sub-component. The collection
+   of these sub-components is used to describe the time zone for a given
+   period of time. The offset to apply at any given time is found by
+   locating the observance that has the last onset date and time before
+   the time in question, and using the offset value from that
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 63]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   observance.
+
+   The top-level properties in a "VTIMEZONE" calendar component are:
+
+   The mandatory "TZID" property is a text value that uniquely
+   identifies the VTIMZONE calendar component within the scope of an
+   iCalendar object.
+
+   The optional "LAST-MODIFIED" property is a UTC value that specifies
+   the date and time that this time zone definition was last updated.
+
+   The optional "TZURL" property is url value that points to a published
+   VTIMEZONE definition. TZURL SHOULD refer to a resource that is
+   accessible by anyone who might need to interpret the object. This
+   SHOULD NOT normally be a file: URL or other URL that is not widely-
+   accessible.
+
+   The collection of properties that are used to define the STANDARD and
+   DAYLIGHT sub-components include:
+
+   The mandatory "DTSTART" property gives the effective onset date and
+   local time for the time zone sub-component definition. "DTSTART" in
+   this usage MUST be specified as a local DATE-TIME value.
+
+   The mandatory "TZOFFSETFROM" property gives the UTC offset which is
+   in use when the onset of this time zone observance begins.
+   "TZOFFSETFROM" is combined with "DTSTART" to define the effective
+   onset for the time zone sub-component definition. For example, the
+   following represents the time at which the observance of Standard
+   Time took effect in Fall 1967 for New York City:
+
+     DTSTART:19671029T020000
+
+     TZOFFSETFROM:-0400
+
+   The mandatory "TZOFFSETTO " property gives the UTC offset for the
+   time zone sub-component (Standard Time or Daylight Saving Time) when
+   this observance is in use.
+
+   The optional "TZNAME" property is the customary name for the time
+   zone. It may be specified multiple times, to allow for specifying
+   multiple language variants of the time zone names. This could be used
+   for displaying dates.
+
+   If specified, the onset for the observance defined by the time zone
+   sub-component is defined by either the "RRULE" or "RDATE" property.
+   If neither is specified, only one sub-component can be specified in
+   the "VTIMEZONE" calendar component and it is assumed that the single
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 64]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   observance specified is always in effect.
+
+   The "RRULE" property defines the recurrence rule for the onset of the
+   observance defined by this time zone sub-component. Some specific
+   requirements for the usage of RRULE for this purpose include:
+
+        - If observance is known to have an effective end date, the
+        "UNTIL" recurrence rule parameter MUST be used to specify the
+        last valid onset of this observance (i.e., the UNTIL date-time
+        will be equal to the last instance generated by the recurrence
+        pattern). It MUST be specified in UTC time.
+
+        - The "DTSTART" and the "TZOFFSETTO" properties MUST be used
+        when generating the onset date-time values (instances) from the
+        RRULE.
+
+   Alternatively, the "RDATE" property can be used to define the onset
+   of the observance by giving the individual onset date and times.
+   "RDATE" in this usage MUST be specified as a local DATE-TIME value in
+   UTC time.
+
+   The optional "COMMENT" property is also allowed for descriptive
+   explanatory text.
+
+   Example: The following are examples of the "VTIMEZONE" calendar
+   component:
+
+   This is an example showing time zone information for the Eastern
+   United States using "RDATE" property. Note that this is only suitable
+   for a recurring event that starts on or later than April 6, 1997 at
+   03:00:00 EDT (i.e., the earliest effective transition date and time)
+   and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid
+   date and time for EST in this scenario). For example, this can be
+   used for a recurring event that occurs every Friday, 8am-9:00 AM,
+   starting June 1, 1997, ending December 31, 1997.
+
+     BEGIN:VTIMEZONE
+     TZID:US-Eastern
+     LAST-MODIFIED:19870101T000000Z
+     BEGIN:STANDARD
+     DTSTART:19971026T020000
+     RDATE:19971026T020000
+     TZOFFSETFROM:-0400
+     TZOFFSETTO:-0500
+     TZNAME:EST
+     END:STANDARD
+     BEGIN:DAYLIGHT
+     DTSTART:19971026T020000
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 65]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     RDATE:19970406T020000
+     TZOFFSETFROM:-0500
+     TZOFFSETTO:-0400
+     TZNAME:EDT
+     END:DAYLIGHT
+     END:VTIMEZONE
+
+   This is a simple example showing the current time zone rules for the
+   Eastern United States using a RRULE recurrence pattern. Note that
+   there is no effective end date to either of the Standard Time or
+   Daylight Time rules. This information would be valid for a recurring
+   event starting today and continuing indefinitely.
+
+     BEGIN:VTIMEZONE
+     TZID:US-Eastern
+     LAST-MODIFIED:19870101T000000Z
+     TZURL:http://zones.stds_r_us.net/tz/US-Eastern
+     BEGIN:STANDARD
+     DTSTART:19671029T020000
+     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+     TZOFFSETFROM:-0400
+     TZOFFSETTO:-0500
+     TZNAME:EST
+     END:STANDARD
+     BEGIN:DAYLIGHT
+     DTSTART:19870405T020000
+     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
+     TZOFFSETFROM:-0500
+     TZOFFSETTO:-0400
+     TZNAME:EDT
+     END:DAYLIGHT
+     END:VTIMEZONE
+
+   This is an example showing a fictitious set of rules for the Eastern
+   United States, where the Daylight Time rule has an effective end date
+   (i.e., after that date, Daylight Time is no longer observed).
+
+     BEGIN:VTIMEZONE
+     TZID:US--Fictitious-Eastern
+     LAST-MODIFIED:19870101T000000Z
+     BEGIN:STANDARD
+     DTSTART:19671029T020000
+     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+     TZOFFSETFROM:-0400
+     TZOFFSETTO:-0500
+     TZNAME:EST
+     END:STANDARD
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 66]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     BEGIN:DAYLIGHT
+     DTSTART:19870405T020000
+     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
+     TZOFFSETFROM:-0500
+     TZOFFSETTO:-0400
+     TZNAME:EDT
+     END:DAYLIGHT
+     END:VTIMEZONE
+
+   This is an example showing a fictitious set of rules for the Eastern
+   United States, where the first Daylight Time rule has an effective
+   end date. There is a second Daylight Time rule that picks up where
+   the other left off.
+
+     BEGIN:VTIMEZONE
+     TZID:US--Fictitious-Eastern
+     LAST-MODIFIED:19870101T000000Z
+     BEGIN:STANDARD
+     DTSTART:19671029T020000
+     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
+     TZOFFSETFROM:-0400
+     TZOFFSETTO:-0500
+     TZNAME:EST
+     END:STANDARD
+     BEGIN:DAYLIGHT
+     DTSTART:19870405T020000
+     RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z
+     TZOFFSETFROM:-0500
+     TZOFFSETTO:-0400
+     TZNAME:EDT
+     END:DAYLIGHT
+     BEGIN:DAYLIGHT
+     DTSTART:19990424T020000
+     RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4
+     TZOFFSETFROM:-0500
+     TZOFFSETTO:-0400
+     TZNAME:EDT
+     END:DAYLIGHT
+     END:VTIMEZONE
+
+4.6.6 Alarm Component
+
+   Component Name: VALARM
+
+   Purpose: Provide a grouping of component properties that define an
+   alarm.
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 67]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Formal Definition: A "VALARM" calendar component is defined by the
+   following notation:
+
+          alarmc     = "BEGIN" ":" "VALARM" CRLF
+                       (audioprop / dispprop / emailprop / procprop)
+                       "END" ":" "VALARM" CRLF
+
+     audioprop  = 2*(
+
+                ; 'action' and 'trigger' are both REQUIRED,
+                ; but MUST NOT occur more than once
+
+                action / trigger /
+
+                ; 'duration' and 'repeat' are both optional,
+                ; and MUST NOT occur more than once each,
+                ; but if one occurs, so MUST the other
+
+                duration / repeat /
+
+                ; the following is optional,
+                ; but MUST NOT occur more than once
+
+                attach /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                x-prop
+
+                )
+
+
+
+     dispprop   = 3*(
+
+                ; the following are all REQUIRED,
+                ; but MUST NOT occur more than once
+
+                action / description / trigger /
+
+                ; 'duration' and 'repeat' are both optional,
+                ; and MUST NOT occur more than once each,
+                ; but if one occurs, so MUST the other
+
+                duration / repeat /
+
+                ; the following is optional,
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 68]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ; and MAY occur more than once
+
+                *x-prop
+
+                )
+
+
+
+     emailprop  = 5*(
+
+                ; the following are all REQUIRED,
+                ; but MUST NOT occur more than once
+
+                action / description / trigger / summary
+
+                ; the following is REQUIRED,
+                ; and MAY occur more than once
+
+                attendee /
+
+                ; 'duration' and 'repeat' are both optional,
+                ; and MUST NOT occur more than once each,
+                ; but if one occurs, so MUST the other
+
+                duration / repeat /
+
+                ; the following are optional,
+                ; and MAY occur more than once
+
+                attach / x-prop
+
+                )
+
+
+
+     procprop   = 3*(
+
+                ; the following are all REQUIRED,
+                ; but MUST NOT occur more than once
+
+                action / attach / trigger /
+
+                ; 'duration' and 'repeat' are both optional,
+                ; and MUST NOT occur more than once each,
+                ; but if one occurs, so MUST the other
+
+                duration / repeat /
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 69]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ; 'description' is optional,
+                ; and MUST NOT occur more than once
+
+                description /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                x-prop
+
+                )
+
+   Description: A "VALARM" calendar component is a grouping of component
+   properties that is a reminder or alarm for an event or a to-do. For
+   example, it may be used to define a reminder for a pending event or
+   an overdue to-do.
+
+   The "VALARM" calendar component MUST include the "ACTION" and
+   "TRIGGER" properties. The "ACTION" property further constrains the
+   "VALARM" calendar component in the following ways:
+
+   When the action is "AUDIO", the alarm can also include one and only
+   one "ATTACH" property, which MUST point to a sound resource, which is
+   rendered when the alarm is triggered.
+
+   When the action is "DISPLAY", the alarm MUST also include a
+   "DESCRIPTION" property, which contains the text to be displayed when
+   the alarm is triggered.
+
+   When the action is "EMAIL", the alarm MUST include a "DESCRIPTION"
+   property, which contains the text to be used as the message body, a
+   "SUMMARY" property, which contains the text to be used as the message
+   subject, and one or more "ATTENDEE" properties, which contain the
+   email address of attendees to receive the message. It can also
+   include one or more "ATTACH" properties, which are intended to be
+   sent as message attachments. When the alarm is triggered, the email
+   message is sent.
+
+   When the action is "PROCEDURE", the alarm MUST include one and only
+   one "ATTACH" property, which MUST point to a procedure resource,
+   which is invoked when the alarm is triggered.
+
+   The "VALARM" calendar component MUST only appear within either a
+   "VEVENT" or "VTODO" calendar component. "VALARM" calendar components
+   cannot be nested. Multiple mutually independent "VALARM" calendar
+   components can be specified for a single "VEVENT" or "VTODO" calendar
+   component.
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 70]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The "TRIGGER" property specifies when the alarm will be triggered.
+   The "TRIGGER" property specifies a duration prior to the start of an
+   event or a to-do. The "TRIGGER" edge may be explicitly set to be
+   relative to the "START" or "END" of the event or to-do with the
+   "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property
+   value type can alternatively be set to an absolute calendar date and
+   time of day value.
+
+   In an alarm set to trigger on the "START" of an event or to-do, the
+   "DTSTART" property MUST be present in the associated event or to-do.
+   In an alarm in a "VEVENT" calendar component set to trigger on the
+   "END" of the event, either the "DTEND" property MUST be present, or
+   the "DTSTART" and "DURATION" properties MUST both be present. In an
+   alarm in a "VTODO" calendar component set to trigger on the "END" of
+   the to-do, either the "DUE" property MUST be present, or the
+   "DTSTART" and "DURATION" properties MUST both be present.
+
+   The alarm can be defined such that it triggers repeatedly. A
+   definition of an alarm with a repeating trigger MUST include both the
+   "DURATION" and "REPEAT" properties. The "DURATION" property specifies
+   the delay period, after which the alarm will repeat. The "REPEAT"
+   property specifies the number of additional repetitions that the
+   alarm will triggered. This repitition count is in addition to the
+   initial triggering of the alarm. Both of these properties MUST be
+   present in order to specify a repeating alarm. If one of these two
+   properties is absent, then the alarm will not repeat beyond the
+   initial trigger.
+
+   The "ACTION" property is used within the "VALARM" calendar component
+   to specify the type of action invoked when the alarm is triggered.
+   The "VALARM" properties provide enough information for a specific
+   action to be invoked. It is typically the responsibility of a
+   "Calendar User Agent" (CUA) to deliver the alarm in the specified
+   fashion. An "ACTION" property value of AUDIO specifies an alarm that
+   causes a sound to be played to alert the user; DISPLAY specifies an
+   alarm that causes a text message to be displayed to the user; EMAIL
+   specifies an alarm that causes an electronic email message to be
+   delivered to one or more email addresses; and PROCEDURE specifies an
+   alarm that causes a procedure to be executed. The "ACTION" property
+   MUST specify one and only one of these values.
+
+   In an AUDIO alarm, if the optional "ATTACH" property is included, it
+   MUST specify an audio sound resource. The intention is that the sound
+   will be played as the alarm effect. If an "ATTACH" property is
+   specified that does not refer to a sound resource, or if the
+   specified sound resource cannot be rendered (because its format is
+   unsupported, or because it cannot be retrieved), then the CUA or
+   other entity responsible for playing the sound may choose a fallback
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 71]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   action, such as playing a built-in default sound, or playing no sound
+   at all.
+
+   In a DISPLAY alarm, the intended alarm effect is for the text value
+   of the "DESCRIPTION" property to be displayed to the user.
+
+   In an EMAIL alarm, the intended alarm effect is for an email message
+   to be composed and delivered to all the addresses specified by the
+   "ATTENDEE" properties in the "VALARM" calendar component. The
+   "DESCRIPTION" property of the "VALARM" calendar component MUST be
+   used as the body text of the message, and the "SUMMARY" property MUST
+   be used as the subject text. Any "ATTACH" properties in the "VALARM"
+   calendar component SHOULD be sent as attachments to the message.
+
+   In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar
+   component MUST specify a procedure or program that is intended to be
+   invoked as the alarm effect. If the procedure or program is in a
+   format that cannot be rendered, then no procedure alarm will be
+   invoked. If the "DESCRIPTION" property is present, its value
+   specifies the argument string to be passed to the procedure or
+   program. "Calendar User Agents" that receive an iCalendar object with
+   this category of alarm, can disable or allow the "Calendar User" to
+   disable, or otherwise ignore this type of alarm. While a very useful
+   alarm capability, the PROCEDURE type of alarm SHOULD be treated by
+   the "Calendar User Agent" as a potential security risk.
+
+   Example: The following example is for a "VALARM" calendar component
+   that specifies an audio alarm that will sound at a precise time and
+   repeat 4 more times at 15 minute intervals:
+
+     BEGIN:VALARM
+     TRIGGER;VALUE=DATE-TIME:19970317T133000Z
+     REPEAT:4
+     DURATION:PT15M
+     ACTION:AUDIO
+     ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud
+     END:VALARM
+
+   The following example is for a "VALARM" calendar component that
+   specifies a display alarm that will trigger 30 minutes before the
+   scheduled start of the event or the due date/time of the to-do it is
+   associated with and will repeat 2 more times at 15 minute intervals:
+
+     BEGIN:VALARM
+     TRIGGER:-PT30M
+     REPEAT:2
+     DURATION:PT15M
+     ACTION:DISPLAY
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 72]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     DESCRIPTION:Breakfast meeting with executive\n
+      team at 8:30 AM EST.
+     END:VALARM
+
+   The following example is for a "VALARM" calendar component that
+   specifies an email alarm that will trigger 2 days before the
+   scheduled due date/time of a to-do it is associated with. It does not
+   repeat. The email has a subject, body and attachment link.
+
+     BEGIN:VALARM
+     TRIGGER:-P2D
+     ACTION:EMAIL
+     ATTENDEE:MAILTO:john_doe@host.com
+     SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING ***
+     DESCRIPTION:A draft agenda needs to be sent out to the attendees
+       to the weekly managers meeting (MGR-LIST). Attached is a
+       pointer the document template for the agenda file.
+     ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen
+      da.doc
+     END:VALARM
+
+   The following example is for a "VALARM" calendar component that
+   specifies a procedural alarm that will trigger at a precise date/time
+   and will repeat 23 more times at one hour intervals. The alarm will
+   invoke a procedure file.
+
+     BEGIN:VALARM
+     TRIGGER;VALUE=DATE-TIME:19980101T050000Z
+     REPEAT:23
+     DURATION:PT1H
+     ACTION:PROCEDURE
+     ATTACH;FMTTYPE=application/binary:ftp://host.com/novo-
+      procs/felizano.exe
+     END:VALARM
+
+4.7 Calendar Properties
+
+   The Calendar Properties are attributes that apply to the iCalendar
+   object, as a whole. These properties do not appear within a calendar
+   component. They SHOULD be specified after the "BEGIN:VCALENDAR"
+   property and prior to any calendar component.
+
+4.7.1 Calendar Scale
+
+   Property Name: CALSCALE
+
+   Purpose: This property defines the calendar scale used for the
+   calendar information specified in the iCalendar object.
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 73]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: Property can be specified in an iCalendar object. The
+   default value is "GREGORIAN".
+
+   Description: This memo is based on the Gregorian calendar scale. The
+   Gregorian calendar scale is assumed if this property is not specified
+   in the iCalendar object. It is expected that other calendar scales
+   will be defined in other specifications or by future versions of this
+   memo.
+
+   Format Definition: The property is defined by the following notation:
+
+     calscale   = "CALSCALE" calparam ":" calvalue CRLF
+
+     calparam   = *(";" xparam)
+
+     calvalue   = "GREGORIAN" / iana-token
+
+   Example: The following is an example of this property:
+
+     CALSCALE:GREGORIAN
+
+4.7.2 Method
+
+   Property Name: METHOD
+
+   Purpose: This property defines the iCalendar object method associated
+   with the calendar object.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property can be specified in an iCalendar object.
+
+   Description: When used in a MIME message entity, the value of this
+   property MUST be the same as the Content-Type "method" parameter
+   value. This property can only appear once within the iCalendar
+   object. If either the "METHOD" property or the Content-Type "method"
+   parameter is specified, then the other MUST also be specified.
+
+   No methods are defined by this specification. This is the subject of
+   other specifications, such as the iCalendar Transport-independent
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 74]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Interoperability Protocol (iTIP) defined by [ITIP].
+
+   If this property is not present in the iCalendar object, then a
+   scheduling transaction MUST NOT be assumed. In such cases, the
+   iCalendar object is merely being used to transport a snapshot of some
+   calendar information; without the intention of conveying a scheduling
+   semantic.
+
+   Format Definition: The property is defined by the following notation:
+
+     method     = "METHOD" metparam ":" metvalue CRLF
+
+     metparam   = *(";" xparam)
+
+     metvalue   = iana-token
+
+   Example: The following is a hypothetical example of this property to
+   convey that the iCalendar object is a request for a meeting:
+
+     METHOD:REQUEST
+
+4.7.3 Product Identifier
+
+   Property Name: PRODID
+
+   Purpose: This property specifies the identifier for the product that
+   created the iCalendar object.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property MUST be specified once in an iCalendar
+   object.
+
+   Description: The vendor of the implementation SHOULD assure that this
+   is a globally unique identifier; using some technique such as an FPI
+   value, as defined in [ISO 9070].
+
+   This property SHOULD not be used to alter the interpretation of an
+   iCalendar object beyond the semantics specified in this memo. For
+   example, it is not to be used to further the understanding of non-
+   standard properties.
+
+   Format Definition: The property is defined by the following notation:
+
+     prodid     = "PRODID" pidparam ":" pidvalue CRLF
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 75]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     pidparam   = *(";" xparam)
+
+     pidvalue   = text
+     ;Any text that describes the product and version
+     ;and that is generally assured of being unique.
+
+   Example: The following is an example of this property. It does not
+   imply that English is the default language.
+
+     PRODID:-//ABC Corporation//NONSGML My Product//EN
+
+4.7.4 Version
+
+   Property Name: VERSION
+
+   Purpose: This property specifies the identifier corresponding to the
+   highest version number or the minimum and maximum range of the
+   iCalendar specification that is required in order to interpret the
+   iCalendar object.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property MUST be specified by an iCalendar object,
+   but MUST only be specified once.
+
+   Description: A value of "2.0" corresponds to this memo.
+
+   Format Definition: The property is defined by the following notation:
+
+     version    = "VERSION" verparam ":" vervalue CRLF
+
+     verparam   = *(";" xparam)
+
+     vervalue   = "2.0"         ;This memo
+                / maxver
+                / (minver ";" maxver)
+
+     minver     = <A IANA registered iCalendar version identifier>
+     ;Minimum iCalendar version needed to parse the iCalendar object
+
+     maxver     = <A IANA registered iCalendar version identifier>
+     ;Maximum iCalendar version needed to parse the iCalendar object
+
+   Example: The following is an example of this property:
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 76]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     VERSION:2.0
+
+4.8 Component Properties
+
+   The following properties can appear within calendar components, as
+   specified by each component property definition.
+
+4.8.1 Descriptive Component Properties
+
+   The following properties specify descriptive information about
+   calendar components.
+
+4.8.1.1 Attachment
+
+   Property Name: ATTACH
+
+   Purpose: The property provides the capability to associate a document
+   object with a calendar component.
+
+   Value Type: The default value type for this property is URI. The
+   value type can also be set to BINARY to indicate inline binary
+   encoded content information.
+
+   Property Parameters: Non-standard, inline encoding, format type and
+   value data type property parameters can be specified on this
+   property.
+
+   Conformance: The property can be specified in a "VEVENT", "VTODO",
+   "VJOURNAL" or "VALARM" calendar components.
+
+   Description: The property can be specified within "VEVENT", "VTODO",
+   "VJOURNAL", or "VALARM" calendar components. This property can be
+   specified multiple times within an iCalendar object.
+
+   Format Definition: The property is defined by the following notation:
+
+     attach     = "ATTACH" attparam ":" uri  CRLF
+
+     attach     =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64"
+                   ";" "VALUE" "=" "BINARY" ":" binary
+
+     attparam   = *(
+
+                ; the following is optional,
+                ; but MUST NOT occur more than once
+
+                (";" fmttypeparam) /
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 77]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following are examples of this property:
+
+     ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com
+
+     ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
+      reports/r-960812.ps
+
+4.8.1.2 Categories
+
+   Property Name: CATEGORIES
+
+   Purpose: This property defines the categories for a calendar
+   component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard and language property parameters
+   can be specified on this property.
+
+   Conformance: The property can be specified within "VEVENT", "VTODO"
+   or "VJOURNAL" calendar components.
+
+   Description: This property is used to specify categories or subtypes
+   of the calendar component. The categories are useful in searching for
+   a calendar component of a particular type and category. Within the
+   "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one
+   category can be specified as a list of categories separated by the
+   COMMA character (US-ASCII decimal 44).
+
+   Format Definition: The property is defined by the following notation:
+
+     categories = "CATEGORIES" catparam ":" text *("," text)
+                  CRLF
+
+     catparam   = *(
+
+                ; the following is optional,
+                ; but MUST NOT occur more than once
+
+                (";" languageparam ) /
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 78]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following are examples of this property:
+
+     CATEGORIES:APPOINTMENT,EDUCATION
+
+     CATEGORIES:MEETING
+
+4.8.1.3 Classification
+
+   Property Name: CLASS
+
+   Purpose: This property defines the access classification for a
+   calendar component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property can be specified once in a "VEVENT",
+   "VTODO" or "VJOURNAL" calendar components.
+
+   Description: An access classification is only one component of the
+   general security system within a calendar application. It provides a
+   method of capturing the scope of the access the calendar owner
+   intends for information within an individual calendar entry. The
+   access classification of an individual iCalendar component is useful
+   when measured along with the other security components of a calendar
+   system (e.g., calendar user authentication, authorization, access
+   rights, access role, etc.). Hence, the semantics of the individual
+   access classifications cannot be completely defined by this memo
+   alone. Additionally, due to the "blind" nature of most exchange
+   processes using this memo, these access classifications cannot serve
+   as an enforcement statement for a system receiving an iCalendar
+   object. Rather, they provide a method for capturing the intention of
+   the calendar owner for the access to the calendar component.
+
+   Format Definition: The property is defined by the following notation:
+
+     class      = "CLASS" classparam ":" classvalue CRLF
+
+     classparam = *(";" xparam)
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 79]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token
+                / x-name
+     ;Default is PUBLIC
+
+   Example: The following is an example of this property:
+
+     CLASS:PUBLIC
+
+4.8.1.4 Comment
+
+   Property Name: COMMENT
+
+   Purpose: This property specifies non-processing information intended
+   to provide a comment to the calendar user.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard, alternate text representation and
+   language property parameters can be specified on this property.
+
+   Conformance: This property can be specified in "VEVENT", "VTODO",
+   "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components.
+
+   Description: The property can be specified multiple times.
+
+   Format Definition: The property is defined by the following notation:
+
+     comment    = "COMMENT" commparam ":" text CRLF
+
+     commparam  = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" altrepparam) / (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following is an example of this property:
+
+     COMMENT:The meeting really needs to include both ourselves
+       and the customer. We can't hold this  meeting without them.
+       As a matter of fact\, the venue for the meeting ought to be at
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 80]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+       their site. - - John
+
+   The data type for this property is TEXT.
+
+4.8.1.5 Description
+
+   Property Name: DESCRIPTION
+
+   Purpose: This property provides a more complete description of the
+   calendar component, than that provided by the "SUMMARY" property.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard, alternate text representation and
+   language property parameters can be specified on this property.
+
+   Conformance: The property can be specified in the "VEVENT", "VTODO",
+   "VJOURNAL" or "VALARM" calendar components. The property can be
+   specified multiple times only within a "VJOURNAL" calendar component.
+
+   Description: This property is used in the "VEVENT" and "VTODO" to
+   capture lengthy textual decriptions associated with the activity.
+
+   This property is used in the "VJOURNAL" calendar component to capture
+   one more textual journal entries.
+
+   This property is used in the "VALARM" calendar component to capture
+   the display text for a DISPLAY category of alarm, to capture the body
+   text for an EMAIL category of alarm and to capture the argument
+   string for a PROCEDURE category of alarm.
+
+   Format Definition: The property is defined by the following notation:
+
+     description        = "DESCRIPTION" descparam ":" text CRLF
+
+     descparam  = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" altrepparam) / (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 81]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Example: The following is an example of the property with formatted
+   line breaks in the property value:
+
+     DESCRIPTION:Meeting to provide technical review for "Phoenix"
+       design.\n Happy Face Conference Room. Phoenix design team
+       MUST attend this meeting.\n RSVP to team leader.
+
+   The following is an example of the property with folding of long
+   lines:
+
+     DESCRIPTION:Last draft of the new novel is to be completed
+       for the editor's proof today.
+
+4.8.1.6 Geographic Position
+
+   Property Name: GEO
+
+   Purpose: This property specifies information related to the global
+   position for the activity specified by a calendar component.
+
+   Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT
+   values.
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in  "VEVENT" or "VTODO"
+   calendar components.
+
+   Description: The property value specifies latitude and longitude, in
+   that order (i.e., "LAT LON" ordering). The longitude represents the
+   location east or west of the prime meridian as a positive or negative
+   real number, respectively. The longitude and latitude values MAY be
+   specified up to six decimal places, which will allow for accuracy to
+   within one meter of geographical position. Receiving applications
+   MUST accept values of this precision and MAY truncate values of
+   greater precision.
+
+   Values for latitude and longitude shall be expressed as decimal
+   fractions of degrees. Whole degrees of latitude shall be represented
+   by a two-digit decimal number ranging from 0 through 90. Whole
+   degrees of longitude shall be represented by a decimal number ranging
+   from 0 through 180. When a decimal fraction of a degree is specified,
+   it shall be separated from the whole number of degrees by a decimal
+   point.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 82]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Latitudes north of the equator shall be specified by a plus sign (+),
+   or by the absence of a minus sign (-), preceding the digits
+   designating degrees. Latitudes south of the Equator shall be
+   designated by a minus sign (-) preceding the digits designating
+   degrees. A point on the Equator shall be assigned to the Northern
+   Hemisphere.
+
+   Longitudes east of the prime meridian shall be specified by a plus
+   sign (+), or by the absence of a minus sign (-), preceding the digits
+   designating degrees. Longitudes west of the meridian shall be
+   designated by minus sign (-) preceding the digits designating
+   degrees. A point on the prime meridian shall be assigned to the
+   Eastern Hemisphere. A point on the 180th meridian shall be assigned
+   to the Western Hemisphere. One exception to this last convention is
+   permitted. For the special condition of describing a band of latitude
+   around the earth, the East Bounding Coordinate data element shall be
+   assigned the value +180 (180) degrees.
+
+   Any spatial address with a latitude of +90 (90) or -90 degrees will
+   specify the position at the North or South Pole, respectively. The
+   component for longitude may have any legal value.
+
+   With the exception of the special condition described above, this
+   form is specified in Department of Commerce, 1986, Representation of
+   geographic point locations for information interchange (Federal
+   Information Processing Standard 70-1):  Washington,  Department of
+   Commerce, National Institute of Standards and Technology.
+
+   The simple formula for converting degrees-minutes-seconds into
+   decimal degrees is:
+
+     decimal = degrees + minutes/60 + seconds/3600.
+
+   Format Definition: The property is defined by the following notation:
+
+     geo        = "GEO" geoparam ":" geovalue CRLF
+
+     geoparam   = *(";" xparam)
+
+     geovalue   = float ";" float
+     ;Latitude and Longitude components
+
+   Example: The following is an example of this property:
+
+     GEO:37.386013;-122.082932
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 83]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.8.1.7 Location
+
+   Property Name: LOCATION
+
+   Purpose: The property defines the intended venue for the activity
+   defined by a calendar component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard, alternate text representation and
+   language property parameters can be specified on this property.
+
+   Conformance: This property can be specified in "VEVENT" or "VTODO"
+   calendar component.
+
+   Description: Specific venues such as conference or meeting rooms may
+   be explicitly specified using this property. An alternate
+   representation may be specified that is a URI that points to
+   directory information with more structured specification of the
+   location. For example, the alternate representation may specify
+   either an LDAP URI pointing to an LDAP server entry or a CID URI
+   pointing to a MIME body part containing a vCard [RFC 2426] for the
+   location.
+
+   Format Definition: The property is defined by the following notation:
+
+     location   = "LOCATION locparam ":" text CRLF
+
+     locparam   = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" altrepparam) / (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following are some examples of this property:
+
+     LOCATION:Conference Room - F123, Bldg. 002
+
+     LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf":
+      Conference Room - F123, Bldg. 002
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 84]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.8.1.8 Percent Complete
+
+   Property Name: PERCENT-COMPLETE
+
+   Purpose: This property is used by an assignee or delegatee of a to-do
+   to convey the percent completion of a to-do to the Organizer.
+
+   Value Type: INTEGER
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in a "VTODO" calendar
+   component.
+
+   Description: The property value is a positive integer between zero
+   and one hundred. A value of "0" indicates the to-do has not yet been
+   started. A value of "100" indicates that the to-do has been
+   completed. Integer values in between indicate the percent partially
+   complete.
+
+   When a to-do is assigned to multiple individuals, the property value
+   indicates the percent complete for that portion of the to-do assigned
+   to the assignee or delegatee. For example, if a to-do is assigned to
+   both individuals "A" and "B". A reply from "A" with a percent
+   complete of "70" indicates that "A" has completed 70% of the to-do
+   assigned to them. A reply from "B" with a percent complete of "50"
+   indicates "B" has completed 50% of the to-do assigned to them.
+
+   Format Definition: The property is defined by the following notation:
+
+     percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF
+
+     pctparam   = *(";" xparam)
+
+   Example: The following is an example of this property to show 39%
+   completion:
+
+     PERCENT-COMPLETE:39
+
+4.8.1.9 Priority
+
+   Property Name: PRIORITY
+
+   Purpose: The property defines the relative priority for a calendar
+   component.
+
+   Value Type: INTEGER
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 85]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property can be specified in a "VEVENT" or "VTODO"
+   calendar component.
+
+   Description: The priority is specified as an integer in the range
+   zero to nine. A value of zero (US-ASCII decimal 48) specifies an
+   undefined priority. A value of one (US-ASCII decimal 49) is the
+   highest priority. A value of two (US-ASCII decimal 50) is the second
+   highest priority. Subsequent numbers specify a decreasing ordinal
+   priority. A value of nine (US-ASCII decimal 58) is the lowest
+   priority.
+
+   A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and
+   "LOW" is mapped into this property such that a property value in the
+   range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52)
+   specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is
+   the normal or "MEDIUM" priority. A value in the range of six (US-
+   ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority.
+
+   A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ...,
+   "C3" is mapped into this property such that a property value of one
+   (US-ASCII decimal 49) specifies "A1", a property value of two (US-
+   ASCII decimal 50) specifies "A2", a property value of three (US-ASCII
+   decimal 51) specifies "A3", and so forth up to a property value of 9
+   (US-ASCII decimal 58) specifies "C3".
+
+   Other integer values are reserved for future use.
+
+   Within a "VEVENT" calendar component, this property specifies a
+   priority for the event. This property may be useful when more than
+   one event is scheduled for a given time period.
+
+   Within a "VTODO" calendar component, this property specified a
+   priority for the to-do. This property is useful in prioritizing
+   multiple action items for a given time period.
+
+   Format Definition: The property is specified by the following
+   notation:
+
+     priority   = "PRIORITY" prioparam ":" privalue CRLF
+     ;Default is zero
+
+     prioparam  = *(";" xparam)
+
+     privalue   = integer       ;Must be in the range [0..9]
+        ; All other values are reserved for future use
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 86]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The following is an example of a property with the highest priority:
+
+     PRIORITY:1
+
+   The following is an example of a property with a next highest
+   priority:
+
+     PRIORITY:2
+
+   Example: The following is an example of a property with no priority.
+   This is equivalent to not specifying the "PRIORITY" property:
+
+     PRIORITY:0
+
+4.8.1.10 Resources
+
+   Property Name: RESOURCES
+
+   Purpose: This property defines the equipment or resources anticipated
+   for an activity specified by a calendar entity..
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard, alternate text representation and
+   language property parameters can be specified on this property.
+
+   Conformance: This property can be specified in "VEVENT" or "VTODO"
+   calendar component.
+
+   Description: The property value is an arbitrary text. More than one
+   resource can be specified as a list of resources separated by the
+   COMMA character (US-ASCII decimal 44).
+
+   Format Definition: The property is defined by the following notation:
+
+     resources  = "RESOURCES" resrcparam ":" text *("," text) CRLF
+
+     resrcparam = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" altrepparam) / (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 87]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                (";" xparam)
+
+                )
+
+   Example: The following is an example of this property:
+
+     RESOURCES:EASEL,PROJECTOR,VCR
+
+     RESOURCES;LANGUAGE=fr:1 raton-laveur
+
+4.8.1.11 Status
+
+   Property Name: STATUS
+
+   Purpose: This property defines the overall status or confirmation for
+   the calendar component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in "VEVENT", "VTODO" or
+   "VJOURNAL" calendar components.
+
+   Description: In a group scheduled calendar component, the property is
+   used by the "Organizer" to provide a confirmation of the event to the
+   "Attendees". For example in a "VEVENT" calendar component, the
+   "Organizer" can indicate that a meeting is tentative, confirmed or
+   cancelled. In a "VTODO" calendar component, the "Organizer" can
+   indicate that an action item needs action, is completed, is in
+   process or being worked on, or has been cancelled. In a "VJOURNAL"
+   calendar component, the "Organizer" can indicate that a journal entry
+   is draft, final or has been cancelled or removed.
+
+   Format Definition: The property is defined by the following notation:
+
+     status     = "STATUS" statparam] ":" statvalue CRLF
+
+     statparam  = *(";" xparam)
+
+     statvalue  = "TENTATIVE"           ;Indicates event is
+                                        ;tentative.
+                / "CONFIRMED"           ;Indicates event is
+                                        ;definite.
+                / "CANCELLED"           ;Indicates event was
+                                        ;cancelled.
+        ;Status values for a "VEVENT"
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 88]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     statvalue  =/ "NEEDS-ACTION"       ;Indicates to-do needs action.
+                / "COMPLETED"           ;Indicates to-do completed.
+                / "IN-PROCESS"          ;Indicates to-do in process of
+                / "CANCELLED"           ;Indicates to-do was cancelled.
+        ;Status values for "VTODO".
+
+     statvalue  =/ "DRAFT"              ;Indicates journal is draft.
+                / "FINAL"               ;Indicates journal is final.
+                / "CANCELLED"           ;Indicates journal is removed.
+        ;Status values for "VJOURNAL".
+
+   Example: The following is an example of this property for a "VEVENT"
+   calendar component:
+
+     STATUS:TENTATIVE
+
+   The following is an example of this property for a "VTODO" calendar
+   component:
+
+     STATUS:NEEDS-ACTION
+
+   The following is an example of this property for a "VJOURNAL"
+   calendar component:
+
+     STATUS:DRAFT
+
+4.8.1.12 Summary
+
+   Property Name: SUMMARY
+
+   Purpose: This property defines a short summary or subject for the
+   calendar component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard, alternate text representation and
+   language property parameters can be specified on this property.
+
+   Conformance: The property can be specified in "VEVENT", "VTODO",
+   "VJOURNAL" or "VALARM" calendar components.
+
+   Description: This property is used in the "VEVENT", "VTODO" and
+   "VJOURNAL" calendar components to capture a short, one line summary
+   about the activity or journal entry.
+
+   This property is used in the "VALARM" calendar component to capture
+   the subject of an EMAIL category of alarm.
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 89]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Format Definition: The property is defined by the following notation:
+
+     summary    = "SUMMARY" summparam ":" text CRLF
+
+     summparam  = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" altrepparam) / (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following is an example of this property:
+
+     SUMMARY:Department Party
+
+4.8.2 Date and Time Component Properties
+
+   The following properties specify date and time related information in
+   calendar components.
+
+4.8.2.1 Date/Time Completed
+
+   Property Name: COMPLETED
+
+   Purpose: This property defines the date and time that a to-do was
+   actually completed.
+
+   Value Type: DATE-TIME
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property can be specified in a "VTODO" calendar
+   component.
+
+   Description: The date and time MUST be in a UTC format.
+
+   Format Definition: The property is defined by the following notation:
+
+     completed  = "COMPLETED" compparam ":" date-time CRLF
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 90]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     compparam  = *(";" xparam)
+
+   Example: The following is an example of this property:
+
+     COMPLETED:19960401T235959Z
+
+4.8.2.2 Date/Time End
+
+   Property Name: DTEND
+
+   Purpose: This property specifies the date and time that a calendar
+   component ends.
+
+   Value Type: The default value type is DATE-TIME. The value type can
+   be set to a DATE value type.
+
+   Property Parameters: Non-standard, value data type, time zone
+   identifier property parameters can be specified on this property.
+
+   Conformance: This property can be specified in "VEVENT" or
+   "VFREEBUSY" calendar components.
+
+   Description: Within the "VEVENT" calendar component, this property
+   defines the date and time by which the event ends. The value MUST be
+   later in time than the value of the "DTSTART" property.
+
+   Within the "VFREEBUSY" calendar component, this property defines the
+   end date and time for the free or busy time information. The time
+   MUST be specified in the UTC time format. The value MUST be later in
+   time than the value of the "DTSTART" property.
+
+   Format Definition: The property is defined by the following notation:
+
+     dtend      = "DTEND" dtendparam":" dtendval CRLF
+
+     dtendparam = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+                (";" tzidparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 91]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                (";" xparam)
+
+                )
+
+
+
+     dtendval   = date-time / date
+     ;Value MUST match value type
+
+   Example: The following is an example of this property:
+
+     DTEND:19960401T235959Z
+
+     DTEND;VALUE=DATE:19980704
+
+4.8.2.3 Date/Time Due
+
+   Property Name: DUE
+
+   Purpose: This property defines the date and time that a to-do is
+   expected to be completed.
+
+   Value Type: The default value type is DATE-TIME. The value type can
+   be set to a DATE value type.
+
+   Property Parameters: Non-standard, value data type, time zone
+   identifier property parameters can be specified on this property.
+
+   Conformance: The property can be specified once in a "VTODO" calendar
+   component.
+
+   Description: The value MUST be a date/time equal to or after the
+   DTSTART value, if specified.
+
+   Format Definition: The property is defined by the following notation:
+
+     due        = "DUE" dueparam":" dueval CRLF
+
+     dueparam   = *(
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+                (";" tzidparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 92]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                  *(";" xparam)
+
+                )
+
+
+
+     dueval     = date-time / date
+     ;Value MUST match value type
+
+   Example: The following is an example of this property:
+
+     DUE:19980430T235959Z
+
+4.8.2.4 Date/Time Start
+
+   Property Name: DTSTART
+
+   Purpose: This property specifies when the calendar component begins.
+
+   Value Type: The default value type is DATE-TIME. The time value MUST
+   be one of the forms defined for the DATE-TIME value type. The value
+   type can be set to a DATE value type.
+
+   Property Parameters: Non-standard, value data type, time zone
+   identifier property parameters can be specified on this property.
+
+   Conformance: This property can be specified in the "VEVENT", "VTODO",
+   "VFREEBUSY", or "VTIMEZONE" calendar components.
+
+   Description: Within the "VEVENT" calendar component, this property
+   defines the start date and time for the event. The property is
+   REQUIRED in "VEVENT" calendar components. Events can have a start
+   date/time but no end date/time. In that case, the event does not take
+   up any time.
+
+   Within the "VFREEBUSY" calendar component, this property defines the
+   start date and time for the free or busy time information. The time
+   MUST be specified in UTC time.
+
+   Within the "VTIMEZONE" calendar component, this property defines the
+   effective start date and time for a time zone specification. This
+   property is REQUIRED within each STANDARD and DAYLIGHT part included
+   in "VTIMEZONE" calendar components and MUST be specified as a local
+   DATE-TIME without the "TZID" property parameter.
+
+   Format Definition: The property is defined by the following notation:
+
+     dtstart    = "DTSTART" dtstparam ":" dtstval CRLF
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 93]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     dtstparam  = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+                (";" tzidparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                  *(";" xparam)
+
+                )
+
+
+
+     dtstval    = date-time / date
+     ;Value MUST match value type
+
+   Example: The following is an example of this property:
+
+     DTSTART:19980118T073000Z
+
+4.8.2.5 Duration
+
+   Property Name: DURATION
+
+   Purpose: The property specifies a positive duration of time.
+
+   Value Type: DURATION
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property can be specified in "VEVENT", "VTODO",
+   "VFREEBUSY" or "VALARM" calendar components.
+
+   Description: In a "VEVENT" calendar component the property may be
+   used to specify a duration of the event, instead of an explicit end
+   date/time. In a "VTODO" calendar component the property may be used
+   to specify a duration for the to-do, instead of an explicit due
+   date/time. In a "VFREEBUSY" calendar component the property may be
+   used to specify the interval of free time being requested. In a
+   "VALARM" calendar component the property may be used to specify the
+   delay period prior to repeating an alarm.
+
+   Format Definition: The property is defined by the following notation:
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 94]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     duration   = "DURATION" durparam ":" dur-value CRLF
+                  ;consisting of a positive duration of time.
+
+     durparam   = *(";" xparam)
+
+   Example: The following is an example of this property that specifies
+   an interval of time of 1 hour and zero minutes and zero seconds:
+
+     DURATION:PT1H0M0S
+
+   The following is an example of this property that specifies an
+   interval of time of 15 minutes.
+
+     DURATION:PT15M
+
+4.8.2.6 Free/Busy Time
+
+   Property Name: FREEBUSY
+
+   Purpose: The property defines one or more free or busy time
+   intervals.
+
+   Value Type: PERIOD. The date and time values MUST be in an UTC time
+   format.
+
+   Property Parameters: Non-standard or free/busy time type property
+   parameters can be specified on this property.
+
+   Conformance: The property can be specified in a "VFREEBUSY" calendar
+   component.
+
+   Property Parameter: "FBTYPE" and non-standard parameters can be
+   specified on this property.
+
+   Description: These time periods can be specified as either a start
+   and end date-time or a start date-time and duration. The date and
+   time MUST be a UTC time format.
+
+   "FREEBUSY" properties within the "VFREEBUSY" calendar component
+   SHOULD be sorted in ascending order, based on start time and then end
+   time, with the earliest periods first.
+
+   The "FREEBUSY" property can specify more than one value, separated by
+   the COMMA character (US-ASCII decimal 44). In such cases, the
+   "FREEBUSY" property values SHOULD all be of the same "FBTYPE"
+   property parameter type (e.g., all values of a particular "FBTYPE"
+   listed together in a single property).
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 95]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Format Definition: The property is defined by the following notation:
+
+     freebusy   = "FREEBUSY" fbparam ":" fbvalue
+                  CRLF
+
+     fbparam    = *(
+                ; the following is optional,
+                ; but MUST NOT occur more than once
+
+                (";" fbtypeparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+     fbvalue    = period *["," period]
+     ;Time value MUST be in the UTC time format.
+
+   Example: The following are some examples of this property:
+
+     FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M
+
+     FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H
+
+     FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H,
+      19970308T230000Z/19970309T000000Z
+
+4.8.2.7 Time Transparency
+
+   Property Name: TRANSP
+
+   Purpose: This property defines whether an event is transparent or not
+   to busy time searches.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified once in a "VEVENT"
+   calendar component.
+
+   Description: Time Transparency is the characteristic of an event that
+   determines whether it appears to consume time on a calendar. Events
+   that consume actual time for the individual or resource associated
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 96]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   with the calendar SHOULD be recorded as OPAQUE, allowing them to be
+   detected by free-busy time searches. Other events, which do not take
+   up the individual's (or resource's) time SHOULD be recorded as
+   TRANSPARENT, making them invisible to free-busy time searches.
+
+   Format Definition: The property is specified by the following
+   notation:
+
+     transp     = "TRANSP" tranparam ":" transvalue CRLF
+
+     tranparam  = *(";" xparam)
+
+     transvalue = "OPAQUE"      ;Blocks or opaque on busy time searches.
+                / "TRANSPARENT" ;Transparent on busy time searches.
+        ;Default value is OPAQUE
+
+   Example: The following is an example of this property for an event
+   that is transparent or does not block on free/busy time searches:
+
+     TRANSP:TRANSPARENT
+
+   The following is an example of this property for an event that is
+   opaque or blocks on free/busy time searches:
+
+     TRANSP:OPAQUE
+
+4.8.3 Time Zone Component Properties
+
+   The following properties specify time zone information in calendar
+   components.
+
+4.8.3.1 Time Zone Identifier
+
+   Property Name: TZID
+
+   Purpose: This property specifies the text value that uniquely
+   identifies the "VTIMEZONE" calendar component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property MUST be specified in a "VTIMEZONE"
+   calendar component.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 97]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: This is the label by which a time zone calendar
+   component is referenced by any iCalendar properties whose data type
+   is either DATE-TIME or TIME and not intended to specify a UTC or a
+   "floating" time. The presence of the SOLIDUS character (US-ASCII
+   decimal 47) as a prefix, indicates that this TZID represents an
+   unique ID in a globally defined time zone registry (when such
+   registry is defined).
+
+        Note: This document does not define a naming convention for time
+        zone identifiers. Implementers may want to use the naming
+        conventions defined in existing time zone specifications such as
+        the public-domain Olson database [TZ]. The specification of
+        globally unique time zone identifiers is not addressed by this
+        document and is left for future study.
+
+   Format Definition: This property is defined by the following
+   notation:
+
+     tzid       = "TZID" tzidpropparam ":" [tzidprefix] text CRLF
+
+     tzidpropparam      = *(";" xparam)
+
+     ;tzidprefix        = "/"
+     ; Defined previously. Just listed here for reader convenience.
+
+   Example: The following are examples of non-globally unique time zone
+   identifiers:
+
+     TZID:US-Eastern
+
+     TZID:California-Los_Angeles
+
+   The following is an example of a fictitious globally unique time zone
+   identifier:
+
+     TZID:/US-New_York-New_York
+
+4.8.3.2 Time Zone Name
+
+   Property Name: TZNAME
+
+   Purpose: This property specifies the customary designation for a time
+   zone description.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard and language property parameters
+   can be specified on this property.
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 98]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Conformance: This property can be specified in a "VTIMEZONE" calendar
+   component.
+
+   Description: This property may be specified in multiple languages; in
+   order to provide for different language requirements.
+
+   Format Definition: This property is defined by the following
+   notation:
+
+     tzname     = "TZNAME" tznparam ":" text CRLF
+
+     tznparam   = *(
+
+                ; the following is optional,
+                ; but MUST NOT occur more than once
+
+                (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following are example of this property:
+
+     TZNAME:EST
+
+   The following is an example of this property when two different
+   languages for the time zone name are specified:
+
+     TZNAME;LANGUAGE=en:EST
+     TZNAME;LANGUAGE=fr-CA:HNE
+
+4.8.3.3 Time Zone Offset From
+
+   Property Name: TZOFFSETFROM
+
+   Purpose: This property specifies the offset which is in use prior to
+   this time zone observance.
+
+   Value Type: UTC-OFFSET
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+
+
+
+
+Dawson & Stenerson          Standards Track                    [Page 99]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Conformance: This property MUST be specified in a "VTIMEZONE"
+   calendar component.
+
+   Description: This property specifies the offset which is in use prior
+   to this time observance. It is used to calculate the absolute time at
+   which the transition to a given observance takes place. This property
+   MUST only be specified in a "VTIMEZONE" calendar component. A
+   "VTIMEZONE" calendar component MUST include this property. The
+   property value is a signed numeric indicating the number of hours and
+   possibly minutes from UTC. Positive numbers represent time zones east
+   of the prime meridian, or ahead of UTC. Negative numbers represent
+   time zones west of the prime meridian, or behind UTC.
+
+   Format Definition: The property is defined by the following notation:
+
+     tzoffsetfrom       = "TZOFFSETFROM" frmparam ":" utc-offset
+                          CRLF
+
+     frmparam   = *(";" xparam)
+
+   Example: The following are examples of this property:
+
+     TZOFFSETFROM:-0500
+
+     TZOFFSETFROM:+1345
+
+4.8.3.4 Time Zone Offset To
+
+   Property Name: TZOFFSETTO
+
+   Purpose: This property specifies the offset which is in use in this
+   time zone observance.
+
+   Value Type: UTC-OFFSET
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property MUST be specified in a "VTIMEZONE"
+   calendar component.
+
+   Description: This property specifies the offset which is in use in
+   this time zone observance. It is used to calculate the absolute time
+   for the new observance. The property value is a signed numeric
+   indicating the number of hours and possibly minutes from UTC.
+   Positive numbers represent time zones east of the prime meridian, or
+   ahead of UTC. Negative numbers represent time zones west of the prime
+   meridian, or behind UTC.
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 100]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Format Definition: The property is defined by the following notation:
+
+     tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF
+
+     toparam    = *(";" xparam)
+
+   Example: The following are examples of this property:
+
+     TZOFFSETTO:-0400
+
+     TZOFFSETTO:+1245
+
+4.8.3.5 Time Zone URL
+
+   Property Name: TZURL
+
+   Purpose: The TZURL provides a means for a VTIMEZONE component to
+   point to a network location that can be used to retrieve an up-to-
+   date version of itself.
+
+   Value Type: URI
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in a "VTIMEZONE" calendar
+   component.
+
+   Description: The TZURL provides a means for a VTIMEZONE component to
+   point to a network location that can be used to retrieve an up-to-
+   date version of itself. This provides a hook to handle changes
+   government bodies impose upon time zone definitions. Retrieval of
+   this resource results in an iCalendar object containing a single
+   VTIMEZONE component and a METHOD property set to PUBLISH.
+
+   Format Definition: The property is defined by the following notation:
+
+     tzurl      = "TZURL" tzurlparam ":" uri CRLF
+
+     tzurlparam = *(";" xparam)
+
+   Example: The following is an example of this property:
+
+     TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 101]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.8.4 Relationship Component Properties
+
+   The following properties specify relationship information in calendar
+   components.
+
+4.8.4.1 Attendee
+
+   Property Name: ATTENDEE
+
+   Purpose: The property defines an "Attendee" within a calendar
+   component.
+
+   Value Type: CAL-ADDRESS
+
+   Property Parameters: Non-standard, language, calendar user type,
+   group or list membership, participation role, participation status,
+   RSVP expectation, delegatee, delegator, sent by, common name or
+   directory entry reference property parameters can be specified on
+   this property.
+
+   Conformance: This property MUST be specified in an iCalendar object
+   that specifies a group scheduled calendar entity. This property MUST
+   NOT be specified in an iCalendar object when publishing the calendar
+   information (e.g., NOT in an iCalendar object that specifies the
+   publication of a calendar user's busy time, event, to-do or journal).
+   This property is not specified in an iCalendar object that specifies
+   only a time zone definition or that defines calendar entities that
+   are not group scheduled entities, but are entities only on a single
+   user's calendar.
+
+   Description: The property MUST only be specified within calendar
+   components to specify participants, non-participants and the chair of
+   a group scheduled calendar entity. The property is specified within
+   an "EMAIL" category of the "VALARM" calendar component to specify an
+   email address that is to receive the email type of iCalendar alarm.
+
+   The property parameter CN is for the common or displayable name
+   associated with the calendar address; ROLE, for the intended role
+   that the attendee will have in the calendar component; PARTSTAT, for
+   the status of the attendee's participation; RSVP, for indicating
+   whether the favor of a reply is requested; CUTYPE, to indicate the
+   type of calendar user; MEMBER, to indicate the groups that the
+   attendee belongs to; DELEGATED-TO, to indicate the calendar users
+   that the original request was delegated to; and DELEGATED-FROM, to
+   indicate whom the request was delegated from; SENT-BY, to indicate
+   whom is acting on behalf of the ATTENDEE; and DIR, to indicate the
+   URI that points to the directory information corresponding to the
+   attendee. These property parameters can be specified on an "ATTENDEE"
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 102]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar
+   component. They MUST not be specified in an "ATTENDEE" property in a
+   "VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property
+   parameter is specified, the identified language applies to the CN
+   parameter.
+
+   A recipient delegated a request MUST inherit the RSVP and ROLE values
+   from the attendee that delegated the request to them.
+
+   Multiple attendees can be specified by including multiple "ATTENDEE"
+   properties within the calendar component.
+
+   Format Definition: The property is defined by the following notation:
+
+     attendee   = "ATTENDEE" attparam ":" cal-address CRLF
+
+     attparam   = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" cutypeparam) / (";"memberparam) /
+                (";" roleparam) / (";" partstatparam) /
+                (";" rsvpparam) / (";" deltoparam) /
+                (";" delfromparam) / (";" sentbyparam) /
+                (";"cnparam) / (";" dirparam) /
+                (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following are examples of this property's use for a to-
+   do:
+
+     ORGANIZER:MAILTO:jsmith@host1.com
+     ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com":
+      MAILTO:joecool@host2.com
+     ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com":
+      MAILTO:ildoit@host1.com
+
+   The following is an example of this property used for specifying
+   multiple attendees to an event:
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 103]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     ORGANIZER:MAILTO:jsmith@host1.com
+     ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot
+      :MAILTO:hcabot@host2.com
+     ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com"
+      ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com
+
+   The following is an example of this property with a URI to the
+   directory information associated with the attendee:
+
+     ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC%
+      20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@
+      host1.com
+
+   The following is an example of this property with "delegatee" and
+   "delegator" information for an event:
+
+     ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com
+     ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM=
+      "MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@
+      host2.com
+     ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO=
+      "MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss
+      @host2.com
+     ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe
+      :MAILTO:jdoe@host1.com
+
+   Example: The following is an example of this property's use when
+   another calendar user is acting on behalf of the "Attendee":
+
+     ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO:
+      jsmith@host1.com
+
+4.8.4.2 Contact
+
+   Property Name: CONTACT
+
+   Purpose: The property is used to represent contact information or
+   alternately a reference to contact information associated with the
+   calendar component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard, alternate text representation and
+   language property parameters can be specified on this property.
+
+   Conformance: The property can be specified in a "VEVENT", "VTODO",
+   "VJOURNAL" or "VFREEBUSY" calendar component.
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 104]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: The property value consists of textual contact
+   information. An alternative representation for the property value can
+   also be specified that refers to a URI pointing to an alternate form,
+   such as a vCard [RFC 2426], for the contact information.
+
+   Format Definition: The property is defined by the following notation:
+
+     contact    = "CONTACT" contparam ":" text CRLF
+
+     contparam  = *(
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" altrepparam) / (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following is an example of this property referencing
+   textual contact information:
+
+     CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234
+
+   The following is an example of this property with an alternate
+   representation of a LDAP URI to a directory entry containing the
+   contact information:
+
+     CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\,
+      c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\,
+      +1-919-555-1234
+
+   The following is an example of this property with an alternate
+   representation of a MIME body part containing the contact
+   information, such as a vCard [RFC 2426] embedded in a [MIME-DIR]
+   content-type:
+
+     CONTACT;ALTREP="CID=<part3.msg970930T083000SILVER@host.com>":Jim
+       Dolittle\, ABC Industries\, +1-919-555-1234
+
+   The following is an example of this property referencing a network
+   resource, such as a vCard [RFC 2426] object containing the contact
+   information:
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 105]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim
+       Dolittle\, ABC Industries\, +1-919-555-1234
+
+4.8.4.3 Organizer
+
+   Property Name: ORGANIZER
+
+   Purpose: The property defines the organizer for a calendar component.
+
+   Value Type: CAL-ADDRESS
+
+   Property Parameters: Non-standard, language, common name, directory
+   entry reference, sent by property parameters can be specified on this
+   property.
+
+   Conformance: This property MUST be specified in an iCalendar object
+   that specifies a group scheduled calendar entity. This property MUST
+   be specified in an iCalendar object that specifies the publication of
+   a calendar user's busy time. This property MUST NOT be specified in
+   an iCalendar object that specifies only a time zone definition or
+   that defines calendar entities that are not group scheduled entities,
+   but are entities only on a single user's calendar.
+
+   Description: The property is specified within the "VEVENT", "VTODO",
+   "VJOURNAL calendar components to specify the organizer of a group
+   scheduled calendar entity. The property is specified within the
+   "VFREEBUSY" calendar component to specify the calendar user
+   requesting the free or busy time. When publishing a "VFREEBUSY"
+   calendar component, the property is used to specify the calendar that
+   the published busy time came from.
+
+   The property has the property parameters CN, for specifying the
+   common or display name associated with the "Organizer", DIR, for
+   specifying a pointer to the directory information associated with the
+   "Organizer", SENT-BY, for specifying another calendar user that is
+   acting on behalf of the "Organizer". The non-standard parameters may
+   also be specified on this property. If the LANGUAGE property
+   parameter is specified, the identified language applies to the CN
+   parameter value.
+
+   Format Definition: The property is defined by the following notation:
+
+     organizer  = "ORGANIZER" orgparam ":"
+                  cal-address CRLF
+
+     orgparam   = *(
+
+                ; the following are optional,
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 106]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ; but MUST NOT occur more than once
+
+                (";" cnparam) / (";" dirparam) / (";" sentbyparam) /
+                (";" languageparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+   Example: The following is an example of this property:
+
+     ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com
+
+   The following is an example of this property with a pointer to the
+   directory information associated with the organizer:
+
+     ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ
+      ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com
+
+   The following is an example of this property used by another calendar
+   user who is acting on behalf of the organizer, with responses
+   intended to be sent back to the organizer, not the other calendar
+   user:
+
+     ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com":
+      MAILTO:jsmith@host1.com
+
+4.8.4.4 Recurrence ID
+
+   Property Name: RECURRENCE-ID
+
+   Purpose: This property is used in conjunction with the "UID" and
+   "SEQUENCE" property to identify a specific instance of a recurring
+   "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property
+   value is the effective value of the "DTSTART" property of the
+   recurrence instance.
+
+   Value Type: The default value type for this property is DATE-TIME.
+   The time format can be any of the valid forms defined for a DATE-TIME
+   value type. See DATE-TIME value type definition for specific
+   interpretations of the various forms. The value type can be set to
+   DATE.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 107]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Property Parameters: Non-standard property, value data type, time
+   zone identifier and recurrence identifier range parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in an iCalendar object
+   containing a recurring calendar component.
+
+   Description: The full range of calendar components specified by a
+   recurrence set is referenced by referring to just the "UID" property
+   value corresponding to the calendar component. The "RECURRENCE-ID"
+   property allows the reference to an individual instance within the
+   recurrence set.
+
+   If the value of the "DTSTART" property is a DATE type value, then the
+   value MUST be the calendar date for the recurrence instance.
+
+   The date/time value is set to the time when the original recurrence
+   instance would occur; meaning that if the intent is to change a
+   Friday meeting to Thursday, the date/time is still set to the
+   original Friday meeting.
+
+   The "RECURRENCE-ID" property is used in conjunction with the "UID"
+   and "SEQUENCE" property to identify a particular instance of a
+   recurring event, to-do or journal. For a given pair of "UID" and
+   "SEQUENCE" property values, the "RECURRENCE-ID" value for a
+   recurrence instance is fixed. When the definition of the recurrence
+   set for a calendar component changes, and hence the "SEQUENCE"
+   property value changes, the "RECURRENCE-ID" for a given recurrence
+   instance might also change.The "RANGE" parameter is used to specify
+   the effective range of recurrence instances from the instance
+   specified by the "RECURRENCE-ID" property value. The default value
+   for the range parameter is the single recurrence instance only. The
+   value can also be "THISANDPRIOR" to indicate a range defined by the
+   given recurrence instance and all prior instances or the value can be
+   "THISANDFUTURE" to indicate a range defined by the given recurrence
+   instance and all subsequent instances.
+
+   Format Definition: The property is defined by the following notation:
+
+     recurid    = "RECURRENCE-ID" ridparam ":" ridval CRLF
+
+     ridparam   = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" "VALUE" "=" ("DATE-TIME" / "DATE)) /
+                (";" tzidparam) / (";" rangeparam) /
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 108]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+     ridval     = date-time / date
+     ;Value MUST match value type
+
+   Example: The following are examples of this property:
+
+     RECURRENCE-ID;VALUE=DATE:19960401
+
+     RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z
+
+4.8.4.5 Related To
+
+   Property Name: RELATED-TO
+
+   Purpose: The property is used to represent a relationship or
+   reference between one calendar component and another.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard and relationship type property
+   parameters can be specified on this property.
+
+   Conformance: The property can be specified one or more times in the
+   "VEVENT", "VTODO" or "VJOURNAL" calendar components.
+
+   Description: The property value consists of the persistent, globally
+   unique identifier of another calendar component. This value would be
+   represented in a calendar component by the "UID" property.
+
+   By default, the property value points to another calendar component
+   that has a PARENT relationship to the referencing object. The
+   "RELTYPE" property parameter is used to either explicitly state the
+   default PARENT relationship type to the referenced calendar component
+   or to override the default PARENT relationship type and specify
+   either a CHILD or SIBLING relationship. The PARENT relationship
+   indicates that the calendar component is a subordinate of the
+   referenced calendar component. The CHILD relationship indicates that
+   the calendar component is a superior of the referenced calendar
+   component. The SIBLING relationship indicates that the calendar
+   component is a peer of the referenced calendar component.
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 109]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Changes to a calendar component referenced by this property can have
+   an implicit impact on the related calendar component. For example, if
+   a group event changes its start or end date or time, then the
+   related, dependent events will need to have their start and end dates
+   changed in a corresponding way. Similarly, if a PARENT calendar
+   component is canceled or deleted, then there is an implied impact to
+   the related CHILD calendar components. This property is intended only
+   to provide information on the relationship of calendar components. It
+   is up to the target calendar system to maintain any property
+   implications of this relationship.
+
+   Format Definition: The property is defined by the following notation:
+
+     related    = "RELATED-TO" [relparam] ":" text CRLF
+
+     relparam   = *(
+
+                ; the following is optional,
+                ; but MUST NOT occur more than once
+
+                (";" reltypeparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparm)
+
+                )
+
+   The following is an example of this property:
+
+     RELATED-TO:<jsmith.part7.19960817T083000.xyzMail@host3.com>
+
+     RELATED-TO:<19960401-080045-4000F192713-0052@host1.com>
+
+4.8.4.6 Uniform Resource Locator
+
+   Property Name: URL
+
+   Purpose: This property defines a Uniform Resource Locator (URL)
+   associated with the iCalendar object.
+
+   Value Type: URI
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 110]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Conformance: This property can be specified once in the "VEVENT",
+   "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
+
+   Description: This property may be used in a calendar component to
+   convey a location where a more dynamic rendition of the calendar
+   information associated with the calendar component can be found. This
+   memo does not attempt to standardize the form of the URI, nor the
+   format of the resource pointed to by the property value. If the URL
+   property and Content-Location MIME header are both specified, they
+   MUST point to the same resource.
+
+   Format Definition: The property is defined by the following notation:
+
+     url        = "URL" urlparam ":" uri CRLF
+
+     urlparam   = *(";" xparam)
+
+   Example: The following is an example of this property:
+
+     URL:http://abc.com/pub/calendars/jsmith/mytime.ics
+
+4.8.4.7 Unique Identifier
+
+   Property Name: UID
+
+   Purpose: This property defines the persistent, globally unique
+   identifier for the calendar component.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property MUST be specified in the "VEVENT", "VTODO",
+   "VJOURNAL" or "VFREEBUSY" calendar components.
+
+   Description: The UID itself MUST be a globally unique identifier. The
+   generator of the identifier MUST guarantee that the identifier is
+   unique. There are several algorithms that can be used to accomplish
+   this. The identifier is RECOMMENDED to be the identical syntax to the
+   [RFC 822] addr-spec. A good method to assure uniqueness is to put the
+   domain name or a domain literal IP address of the host on which the
+   identifier was created on the right hand side of the "@", and on the
+   left hand side, put a combination of the current calendar date and
+   time of day (i.e., formatted in as a DATE-TIME value) along with some
+   other currently unique (perhaps sequential) identifier available on
+   the system (for example, a process id number). Using a date/time
+   value on the left hand side and a domain name or domain literal on
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 111]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   the right hand side makes it possible to guarantee uniqueness since
+   no two hosts should be using the same domain name or IP address at
+   the same time. Though other algorithms will work, it is RECOMMENDED
+   that the right hand side contain some domain identifier (either of
+   the host itself or otherwise) such that the generator of the message
+   identifier can guarantee the uniqueness of the left hand side within
+   the scope of that domain.
+
+   This is the method for correlating scheduling messages with the
+   referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component.
+
+   The full range of calendar components specified by a recurrence set
+   is referenced by referring to just the "UID" property value
+   corresponding to the calendar component. The "RECURRENCE-ID" property
+   allows the reference to an individual instance within the recurrence
+   set.
+
+   This property is an important method for group scheduling
+   applications to match requests with later replies, modifications or
+   deletion requests. Calendaring and scheduling applications MUST
+   generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar
+   components to assure interoperability with other group scheduling
+   applications. This identifier is created by the calendar system that
+   generates an iCalendar object.
+
+   Implementations MUST be able to receive and persist values of at
+   least 255 characters for this property.
+
+   Format Definition: The property is defined by the following notation:
+
+     uid        = "UID" uidparam ":" text CRLF
+
+     uidparam   = *(";" xparam)
+
+   Example: The following is an example of this property:
+
+     UID:19960401T080045Z-4000F192713-0052@host1.com
+
+4.8.5 Recurrence Component Properties
+
+   The following properties specify recurrence information in calendar
+   components.
+
+4.8.5.1 Exception Date/Times
+
+   Property Name: EXDATE
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 112]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Purpose: This property defines the list of date/time exceptions for a
+   recurring calendar component.
+
+   Value Type: The default value type for this property is DATE-TIME.
+   The value type can be set to DATE.
+
+   Property Parameters: Non-standard, value data type and time zone
+   identifier property parameters can be specified on this property.
+
+   Conformance: This property can be specified in an iCalendar object
+   that includes a recurring calendar component.
+
+   Description: The exception dates, if specified, are used in computing
+   the recurrence set. The recurrence set is the complete set of
+   recurrence instances for a calendar component. The recurrence set is
+   generated by considering the initial "DTSTART" property along with
+   the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
+   within the iCalendar object. The "DTSTART" property defines the first
+   instance in the recurrence set. Multiple instances of the "RRULE" and
+   "EXRULE" properties can also be specified to define more
+   sophisticated recurrence sets. The final recurrence set is generated
+   by gathering all of the start date-times generated by any of the
+   specified "RRULE" and "RDATE" properties, and then excluding any
+   start date and times which fall within the union of start date and
+   times generated by any specified "EXRULE" and "EXDATE" properties.
+   This implies that start date and times within exclusion related
+   properties (i.e., "EXDATE" and "EXRULE") take precedence over those
+   specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where
+   duplicate instances are generated by the "RRULE" and "RDATE"
+   properties, only one recurrence is considered. Duplicate instances
+   are ignored.
+
+   The "EXDATE" property can be used to exclude the value specified in
+   "DTSTART". However, in such cases the original "DTSTART" date MUST
+   still be maintained by the calendaring and scheduling system because
+   the original "DTSTART" value has inherent usage dependencies by other
+   properties such as the "RECURRENCE-ID".
+
+   Format Definition: The property is defined by the following notation:
+
+     exdate     = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF
+
+     exdtparam  = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" "VALUE" "=" ("DATE-TIME" / "DATE")) /
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 113]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                (";" tzidparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+     exdtval    = date-time / date
+     ;Value MUST match value type
+
+   Example: The following is an example of this property:
+
+     EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z
+
+4.8.5.2 Exception Rule
+
+   Property Name: EXRULE
+
+   Purpose: This property defines a rule or repeating pattern for an
+   exception to a recurrence set.
+
+   Value Type: RECUR
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in "VEVENT", "VTODO" or
+   "VJOURNAL" calendar components.
+
+   Description: The exception rule, if specified, is used in computing
+   the recurrence set. The recurrence set is the complete set of
+   recurrence instances for a calendar component. The recurrence set is
+   generated by considering the initial "DTSTART" property along with
+   the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
+   within the iCalendar object. The "DTSTART" defines the first instance
+   in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
+   properties can also be specified to define more sophisticated
+   recurrence sets. The final recurrence set is generated by gathering
+   all of the start date-times generated by any of the specified "RRULE"
+   and "RDATE" properties, and excluding any start date and times which
+   fall within the union of start date and times generated by any
+   specified "EXRULE" and "EXDATE" properties. This implies that start
+   date and times within exclusion related properties (i.e., "EXDATE"
+   and "EXRULE") take precedence over those specified by inclusion
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 114]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
+   generated by the "RRULE" and "RDATE" properties, only one recurrence
+   is considered. Duplicate instances are ignored.
+
+   The "EXRULE" property can be used to exclude the value specified in
+   "DTSTART". However, in such cases the original "DTSTART" date MUST
+   still be maintained by the calendaring and scheduling system because
+   the original "DTSTART" value has inherent usage dependencies by other
+   properties such as the "RECURRENCE-ID".
+
+   Format Definition: The property is defined by the following notation:
+
+     exrule     = "EXRULE" exrparam ":" recur CRLF
+
+     exrparam   = *(";" xparam)
+
+   Example: The following are examples of this property. Except every
+   other week, on Tuesday and Thursday for 4 occurrences:
+
+     EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH
+
+   Except daily for 10 occurrences:
+
+     EXRULE:FREQ=DAILY;COUNT=10
+
+   Except yearly in June and July for 8 occurrences:
+
+     EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7
+
+4.8.5.3 Recurrence Date/Times
+
+   Property Name: RDATE
+
+   Purpose: This property defines the list of date/times for a
+   recurrence set.
+
+   Value Type: The default value type for this property is DATE-TIME.
+   The value type can be set to DATE or PERIOD.
+
+   Property Parameters: Non-standard, value data type and time zone
+   identifier property parameters can be specified on this property.
+
+   Conformance: The property can be specified in "VEVENT", "VTODO",
+   "VJOURNAL" or "VTIMEZONE" calendar components.
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 115]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: This property can appear along with the "RRULE" property
+   to define an aggregate set of repeating occurrences. When they both
+   appear in an iCalendar object, the recurring events are defined by
+   the union of occurrences defined by both the "RDATE" and "RRULE".
+
+   The recurrence dates, if specified, are used in computing the
+   recurrence set. The recurrence set is the complete set of recurrence
+   instances for a calendar component. The recurrence set is generated
+   by considering the initial "DTSTART" property along with the "RRULE",
+   "RDATE", "EXDATE" and "EXRULE" properties contained within the
+   iCalendar object. The "DTSTART" property defines the first instance
+   in the recurrence set. Multiple instances of the "RRULE" and "EXRULE"
+   properties can also be specified to define more sophisticated
+   recurrence sets. The final recurrence set is generated by gathering
+   all of the start date/times generated by any of the specified "RRULE"
+   and "RDATE" properties, and excluding any start date/times which fall
+   within the union of start date/times generated by any specified
+   "EXRULE" and "EXDATE" properties. This implies that start date/times
+   within exclusion related properties (i.e., "EXDATE" and "EXRULE")
+   take precedence over those specified by inclusion properties (i.e.,
+   "RDATE" and "RRULE"). Where duplicate instances are generated by the
+   "RRULE" and "RDATE" properties, only one recurrence is considered.
+   Duplicate instances are ignored.
+
+   Format Definition: The property is defined by the following notation:
+
+     rdate      = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF
+
+     rdtparam   = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) /
+                (";" tzidparam) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+     rdtval     = date-time / date / period
+     ;Value MUST match value type
+
+   Example: The following are examples of this property:
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 116]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     RDATE:19970714T123000Z
+
+     RDATE;TZID=US-EASTERN:19970714T083000
+
+     RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z,
+      19960404T010000Z/PT3H
+
+     RDATE;VALUE=DATE:19970101,19970120,19970217,19970421
+      19970526,19970704,19970901,19971014,19971128,19971129,19971225
+
+4.8.5.4 Recurrence Rule
+
+   Property Name: RRULE
+
+   Purpose: This property defines a rule or repeating pattern for
+   recurring events, to-dos, or time zone definitions.
+
+   Value Type: RECUR
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified one or more times in
+   recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It
+   can also be specified once in each STANDARD or DAYLIGHT sub-component
+   of the "VTIMEZONE" calendar component.
+
+   Description: The recurrence rule, if specified, is used in computing
+   the recurrence set. The recurrence set is the complete set of
+   recurrence instances for a calendar component. The recurrence set is
+   generated by considering the initial "DTSTART" property along with
+   the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained
+   within the iCalendar object. The "DTSTART" property defines the first
+   instance in the recurrence set. Multiple instances of the "RRULE" and
+   "EXRULE" properties can also be specified to define more
+   sophisticated recurrence sets. The final recurrence set is generated
+   by gathering all of the start date/times generated by any of the
+   specified "RRULE" and "RDATE" properties, and excluding any start
+   date/times which fall within the union of start date/times generated
+   by any specified "EXRULE" and "EXDATE" properties. This implies that
+   start date/times within exclusion related properties (i.e., "EXDATE"
+   and "EXRULE") take precedence over those specified by inclusion
+   properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are
+   generated by the "RRULE" and "RDATE" properties, only one recurrence
+   is considered. Duplicate instances are ignored.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 117]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION"
+   property pair, specified within the iCalendar object defines the
+   first instance of the recurrence. When used with a recurrence rule,
+   the "DTSTART" and "DTEND" properties MUST be specified in local time
+   and the appropriate set of "VTIMEZONE" calendar components MUST be
+   included. For detail on the usage of the "VTIMEZONE" calendar
+   component, see the "VTIMEZONE" calendar component definition.
+
+   Any duration associated with the iCalendar object applies to all
+   members of the generated recurrence set. Any modified duration for
+   specific recurrences MUST be explicitly specified using the "RDATE"
+   property.
+
+   Format Definition: This property is defined by the following
+   notation:
+
+     rrule      = "RRULE" rrulparam ":" recur CRLF
+
+     rrulparam  = *(";" xparam)
+
+   Example: All examples assume the Eastern United States time zone.
+
+   Daily for 10 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=DAILY;COUNT=10
+
+     ==> (1997 9:00 AM EDT)September 2-11
+
+   Daily until December 24, 1997:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=DAILY;UNTIL=19971224T000000Z
+
+     ==> (1997 9:00 AM EDT)September 2-30;October 1-25
+         (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23
+
+   Every other day - forever:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=DAILY;INTERVAL=2
+     ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30;
+          October 2,4,6...20,22,24
+         (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29;
+          Dec 1,3,...
+
+   Every 10 days, 5 occurrences:
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 118]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5
+
+     ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12
+
+   Everyday in January, for 3 years:
+
+     DTSTART;TZID=US-Eastern:19980101T090000
+     RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z;
+      BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA
+     or
+     RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1
+
+     ==> (1998 9:00 AM EDT)January 1-31
+         (1999 9:00 AM EDT)January 1-31
+         (2000 9:00 AM EDT)January 1-31
+
+   Weekly for 10 occurrences
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=WEEKLY;COUNT=10
+
+     ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
+         (1997 9:00 AM EST)October 28;November 4
+
+   Weekly until December 24, 1997
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z
+
+     ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21
+         (1997 9:00 AM EST)October 28;November 4,11,18,25;
+                           December 2,9,16,23
+   Every other week - forever:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU
+
+     ==> (1997 9:00 AM EDT)September 2,16,30;October 14
+         (1997 9:00 AM EST)October 28;November 11,25;December 9,23
+         (1998 9:00 AM EST)January 6,20;February
+     ...
+
+   Weekly on Tuesday and Thursday for 5 weeks:
+
+    DTSTART;TZID=US-Eastern:19970902T090000
+    RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH
+    or
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 119]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+    RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH
+
+    ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2
+
+   Every other week on Monday, Wednesday and Friday until December 24,
+   1997, but starting on Tuesday, September 2, 1997:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU;
+      BYDAY=MO,WE,FR
+     ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October
+     1,3,13,15,17
+         (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28;
+                           December 8,10,12,22
+
+   Every other week on Tuesday and Thursday, for 8 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH
+
+     ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16
+
+   Monthly on the 1st Friday for ten occurrences:
+
+     DTSTART;TZID=US-Eastern:19970905T090000
+     RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
+
+     ==> (1997 9:00 AM EDT)September 5;October 3
+         (1997 9:00 AM EST)November 7;Dec 5
+         (1998 9:00 AM EST)January 2;February 6;March 6;April 3
+         (1998 9:00 AM EDT)May 1;June 5
+
+   Monthly on the 1st Friday until December 24, 1997:
+
+     DTSTART;TZID=US-Eastern:19970905T090000
+     RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR
+
+     ==> (1997 9:00 AM EDT)September 5;October 3
+         (1997 9:00 AM EST)November 7;December 5
+
+   Every other month on the 1st and last Sunday of the month for 10
+   occurrences:
+
+     DTSTART;TZID=US-Eastern:19970907T090000
+     RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU
+
+     ==> (1997 9:00 AM EDT)September 7,28
+         (1997 9:00 AM EST)November 2,30
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 120]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+         (1998 9:00 AM EST)January 4,25;March 1,29
+         (1998 9:00 AM EDT)May 3,31
+
+   Monthly on the second to last Monday of the month for 6 months:
+
+     DTSTART;TZID=US-Eastern:19970922T090000
+     RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO
+
+     ==> (1997 9:00 AM EDT)September 22;October 20
+         (1997 9:00 AM EST)November 17;December 22
+         (1998 9:00 AM EST)January 19;February 16
+
+   Monthly on the third to the last day of the month, forever:
+
+     DTSTART;TZID=US-Eastern:19970928T090000
+     RRULE:FREQ=MONTHLY;BYMONTHDAY=-3
+
+     ==> (1997 9:00 AM EDT)September 28
+         (1997 9:00 AM EST)October 29;November 28;December 29
+         (1998 9:00 AM EST)January 29;February 26
+     ...
+
+   Monthly on the 2nd and 15th of the month for 10 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15
+
+     ==> (1997 9:00 AM EDT)September 2,15;October 2,15
+         (1997 9:00 AM EST)November 2,15;December 2,15
+         (1998 9:00 AM EST)January 2,15
+
+   Monthly on the first and last day of the month for 10 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970930T090000
+     RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1
+
+     ==> (1997 9:00 AM EDT)September 30;October 1
+         (1997 9:00 AM EST)October 31;November 1,30;December 1,31
+         (1998 9:00 AM EST)January 1,31;February 1
+
+   Every 18 months on the 10th thru 15th of the month for 10
+   occurrences:
+
+     DTSTART;TZID=US-Eastern:19970910T090000
+     RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14,
+      15
+
+     ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 121]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+         (1999 9:00 AM EST)March 10,11,12,13
+
+   Every Tuesday, every other month:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU
+
+     ==> (1997 9:00 AM EDT)September 2,9,16,23,30
+         (1997 9:00 AM EST)November 4,11,18,25
+         (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31
+     ...
+
+   Yearly in June and July for 10 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970610T090000
+     RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7
+     ==> (1997 9:00 AM EDT)June 10;July 10
+         (1998 9:00 AM EDT)June 10;July 10
+         (1999 9:00 AM EDT)June 10;July 10
+         (2000 9:00 AM EDT)June 10;July 10
+         (2001 9:00 AM EDT)June 10;July 10
+     Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components
+     are specified, the day is gotten from DTSTART
+
+   Every other year on January, February, and March for 10 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970310T090000
+     RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3
+
+     ==> (1997 9:00 AM EST)March 10
+         (1999 9:00 AM EST)January 10;February 10;March 10
+         (2001 9:00 AM EST)January 10;February 10;March 10
+         (2003 9:00 AM EST)January 10;February 10;March 10
+
+   Every 3rd year on the 1st, 100th and 200th day for 10 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970101T090000
+     RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200
+
+     ==> (1997 9:00 AM EST)January 1
+         (1997 9:00 AM EDT)April 10;July 19
+         (2000 9:00 AM EST)January 1
+         (2000 9:00 AM EDT)April 9;July 18
+         (2003 9:00 AM EST)January 1
+         (2003 9:00 AM EDT)April 10;July 19
+         (2006 9:00 AM EST)January 1
+
+   Every 20th Monday of the year, forever:
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 122]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     DTSTART;TZID=US-Eastern:19970519T090000
+     RRULE:FREQ=YEARLY;BYDAY=20MO
+
+     ==> (1997 9:00 AM EDT)May 19
+         (1998 9:00 AM EDT)May 18
+         (1999 9:00 AM EDT)May 17
+     ...
+
+   Monday of week number 20 (where the default start of the week is
+   Monday), forever:
+
+     DTSTART;TZID=US-Eastern:19970512T090000
+     RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO
+
+     ==> (1997 9:00 AM EDT)May 12
+         (1998 9:00 AM EDT)May 11
+         (1999 9:00 AM EDT)May 17
+     ...
+
+   Every Thursday in March, forever:
+
+     DTSTART;TZID=US-Eastern:19970313T090000
+     RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH
+
+     ==> (1997 9:00 AM EST)March 13,20,27
+         (1998 9:00 AM EST)March 5,12,19,26
+         (1999 9:00 AM EST)March 4,11,18,25
+     ...
+
+   Every Thursday, but only during June, July, and August, forever:
+
+     DTSTART;TZID=US-Eastern:19970605T090000
+     RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8
+
+     ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31;
+                       August 7,14,21,28
+         (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30;
+                       August 6,13,20,27
+         (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29;
+                       August 5,12,19,26
+     ...
+
+   Every Friday the 13th, forever:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     EXDATE;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 123]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     ==> (1998 9:00 AM EST)February 13;March 13;November 13
+         (1999 9:00 AM EDT)August 13
+         (2000 9:00 AM EDT)October 13
+     ...
+
+   The first Saturday that follows the first Sunday of the month,
+    forever:
+
+     DTSTART;TZID=US-Eastern:19970913T090000
+     RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13
+
+     ==> (1997 9:00 AM EDT)September 13;October 11
+         (1997 9:00 AM EST)November 8;December 13
+         (1998 9:00 AM EST)January 10;February 7;March 7
+         (1998 9:00 AM EDT)April 11;May 9;June 13...
+     ...
+
+   Every four years, the first Tuesday after a Monday in November,
+   forever (U.S. Presidential Election day):
+
+     DTSTART;TZID=US-Eastern:19961105T090000
+     RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4,
+      5,6,7,8
+
+     ==> (1996 9:00 AM EST)November 5
+         (2000 9:00 AM EST)November 7
+         (2004 9:00 AM EST)November 2
+     ...
+
+   The 3rd instance into the month of one of Tuesday, Wednesday or
+   Thursday, for the next 3 months:
+
+     DTSTART;TZID=US-Eastern:19970904T090000
+     RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3
+
+     ==> (1997 9:00 AM EDT)September 4;October 7
+         (1997 9:00 AM EST)November 6
+
+   The 2nd to last weekday of the month:
+
+     DTSTART;TZID=US-Eastern:19970929T090000
+     RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2
+
+     ==> (1997 9:00 AM EDT)September 29
+         (1997 9:00 AM EST)October 30;November 27;December 30
+         (1998 9:00 AM EST)January 29;February 26;March 30
+     ...
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 124]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Every 3 hours from 9:00 AM to 5:00 PM on a specific day:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z
+
+     ==> (September 2, 1997 EDT)09:00,12:00,15:00
+
+   Every 15 minutes for 6 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6
+
+     ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15
+
+   Every hour and a half for 4 occurrences:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4
+
+     ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30
+
+   Every 20 minutes from 9:00 AM to 4:40 PM every day:
+
+     DTSTART;TZID=US-Eastern:19970902T090000
+     RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40
+     or
+     RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16
+
+     ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
+                                ... 16:00,16:20,16:40
+         (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20,
+                               ...16:00,16:20,16:40
+     ...
+
+   An example where the days generated makes a difference because of
+   WKST:
+
+     DTSTART;TZID=US-Eastern:19970805T090000
+     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO
+
+     ==> (1997 EDT)Aug 5,10,19,24
+
+     changing only WKST from MO to SU, yields different results...
+
+     DTSTART;TZID=US-Eastern:19970805T090000
+     RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU
+     ==> (1997 EDT)August 5,17,19,31
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 125]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+4.8.6 Alarm Component Properties
+
+   The following properties specify alarm information in calendar
+   components.
+
+4.8.6.1 Action
+
+   Property Name: ACTION
+
+   Purpose: This property defines the action to be invoked when an alarm
+   is triggered.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property MUST be specified once in a "VALARM"
+   calendar component.
+
+   Description: Each "VALARM" calendar component has a particular type
+   of action associated with it. This property specifies the type of
+   action
+
+   Format Definition: The property is defined by the following notation:
+
+     action     = "ACTION" actionparam ":" actionvalue CRLF
+
+     actionparam        = *(";" xparam)
+
+     actionvalue        = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE"
+                        / iana-token / x-name
+
+   Example: The following are examples of this property in a "VALARM"
+   calendar component:
+
+     ACTION:AUDIO
+
+     ACTION:DISPLAY
+
+     ACTION:PROCEDURE
+
+4.8.6.2 Repeat Count
+
+   Property Name: REPEAT
+
+   Purpose: This property defines the number of time the alarm should be
+   repeated, after the initial trigger.
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 126]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Value Type: INTEGER
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in a "VALARM" calendar
+   component.
+
+   Description: If the alarm triggers more than once, then this property
+   MUST be specified along with the "DURATION" property.
+
+   Format Definition: The property is defined by the following notation:
+
+     repeatcnt  = "REPEAT" repparam ":" integer CRLF
+     ;Default is "0", zero.
+
+     repparam   = *(";" xparam)
+
+   Example: The following is an example of this property for an alarm
+   that repeats 4 additional times with a 5 minute delay after the
+   initial triggering of the alarm:
+
+     REPEAT:4
+     DURATION:PT5M
+
+4.8.6.3 Trigger
+
+   Property Name: TRIGGER
+
+   Purpose: This property specifies when an alarm will trigger.
+
+   Value Type: The default value type is DURATION. The value type can be
+   set to a DATE-TIME value type, in which case the value MUST specify a
+   UTC formatted DATE-TIME value.
+
+   Property Parameters: Non-standard, value data type, time zone
+   identifier or trigger relationship property parameters can be
+   specified on this property. The trigger relationship property
+   parameter MUST only be specified when the value type is DURATION.
+
+   Conformance: This property MUST be specified in the "VALARM" calendar
+   component.
+
+   Description: Within the "VALARM" calendar component, this property
+   defines when the alarm will trigger. The default value type is
+   DURATION, specifying a relative time for the trigger of the alarm.
+   The default duration is relative to the start of an event or to-do
+   that the alarm is associated with. The duration can be explicitly set
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 127]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   to trigger from either the end or the start of the associated event
+   or to-do with the "RELATED" parameter. A value of START will set the
+   alarm to trigger off the start of the associated event or to-do. A
+   value of END will set the alarm to trigger off the end of the
+   associated event or to-do.
+
+   Either a positive or negative duration may be specified for the
+   "TRIGGER" property. An alarm with a positive duration is triggered
+   after the associated start or end of the event or to-do. An alarm
+   with a negative duration is triggered before the associated start or
+   end of the event or to-do.
+
+   The "RELATED" property parameter is not valid if the value type of
+   the property is set to DATE-TIME (i.e., for an absolute date and time
+   alarm trigger). If a value type of DATE-TIME is specified, then the
+   property value MUST be specified in the UTC time format. If an
+   absolute trigger is specified on an alarm for a recurring event or
+   to-do, then the alarm will only trigger for the specified absolute
+   date/time, along with any specified repeating instances.
+
+   If the trigger is set relative to START, then the "DTSTART" property
+   MUST be present in the associated "VEVENT" or "VTODO" calendar
+   component. If an alarm is specified for an event with the trigger set
+   relative to the END, then the "DTEND" property or the "DSTART" and
+   "DURATION' properties MUST be present in the associated "VEVENT"
+   calendar component. If the alarm is specified for a to-do with a
+   trigger set relative to the END, then either the "DUE" property or
+   the "DSTART" and "DURATION' properties MUST be present in the
+   associated "VTODO" calendar component.
+
+   Alarms specified in an event or to-do which is defined in terms of a
+   DATE value type will be triggered relative to 00:00:00 UTC on the
+   specified date. For example, if "DTSTART:19980205, then the duration
+   trigger will be relative to19980205T000000Z.
+
+   Format Definition: The property is defined by the following notation:
+
+     trigger    = "TRIGGER" (trigrel / trigabs)
+
+     trigrel    = *(
+
+                ; the following are optional,
+                ; but MUST NOT occur more than once
+
+                  (";" "VALUE" "=" "DURATION") /
+                  (";" trigrelparam) /
+
+                ; the following is optional,
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 128]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                ; and MAY occur more than once
+
+                  (";" xparam)
+                  ) ":"  dur-value
+
+     trigabs    = 1*(
+
+                ; the following is REQUIRED,
+                ; but MUST NOT occur more than once
+
+                  (";" "VALUE" "=" "DATE-TIME") /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                  (";" xparam)
+
+                  ) ":" date-time
+
+   Example: A trigger set 15 minutes prior to the start of the event or
+   to-do.
+
+     TRIGGER:-P15M
+
+   A trigger set 5 minutes after the end of the event or to-do.
+
+     TRIGGER;RELATED=END:P5M
+
+   A trigger set to an absolute date/time.
+
+     TRIGGER;VALUE=DATE-TIME:19980101T050000Z
+
+4.8.7 Change Management Component Properties
+
+   The following properties specify change management information in
+   calendar components.
+
+4.8.7.1 Date/Time Created
+
+   Property Name: CREATED
+
+   Purpose: This property specifies the date and time that the calendar
+   information was created by the calendar user agent in the calendar
+   store.
+
+        Note: This is analogous to the creation date and time for a file
+        in the file system.
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 129]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Value Type: DATE-TIME
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property can be specified once in "VEVENT", "VTODO"
+   or "VJOURNAL" calendar components.
+
+   Description: The date and time is a UTC value.
+
+   Format Definition: The property is defined by the following notation:
+
+     created    = "CREATED" creaparam ":" date-time CRLF
+
+     creaparam  = *(";" xparam)
+
+   Example: The following is an example of this property:
+
+     CREATED:19960329T133000Z
+
+4.8.7.2 Date/Time Stamp
+
+   Property Name: DTSTAMP
+
+   Purpose: The property indicates the date/time that the instance of
+   the iCalendar object was created.
+
+   Value Type: DATE-TIME
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property MUST be included in the "VEVENT", "VTODO",
+   "VJOURNAL" or "VFREEBUSY" calendar components.
+
+   Description: The value MUST be specified in the UTC time format.
+
+   This property is also useful to protocols such as [IMIP] that have
+   inherent latency issues with the delivery of content. This property
+   will assist in the proper sequencing of messages containing iCalendar
+   objects.
+
+   This property is different than the "CREATED" and "LAST-MODIFIED"
+   properties. These two properties are used to specify when the
+   particular calendar data in the calendar store was created and last
+   modified. This is different than when the iCalendar object
+   representation of the calendar service information was created or
+   last modified.
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 130]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Format Definition: The property is defined by the following notation:
+
+     dtstamp    = "DTSTAMP" stmparam ":" date-time CRLF
+
+     stmparam   = *(";" xparam)
+
+   Example:
+
+     DTSTAMP:19971210T080000Z
+
+4.8.7.3 Last Modified
+
+   Property Name: LAST-MODIFIED
+
+   Purpose: The property specifies the date and time that the
+   information associated with the calendar component was last revised
+   in the calendar store.
+
+        Note: This is analogous to the modification date and time for a
+        file in the file system.
+
+   Value Type: DATE-TIME
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: This property can be specified in the "EVENT", "VTODO",
+   "VJOURNAL" or "VTIMEZONE" calendar components.
+
+   Description: The property value MUST be specified in the UTC time
+   format.
+
+   Format Definition: The property is defined by the following notation:
+
+     last-mod   = "LAST-MODIFIED" lstparam ":" date-time CRLF
+
+     lstparam   = *(";" xparam)
+
+   Example: The following is are examples of this property:
+
+     LAST-MODIFIED:19960817T133000Z
+
+4.8.7.4 Sequence Number
+
+   Property Name: SEQUENCE
+
+   Purpose: This property defines the revision sequence number of the
+   calendar component within a sequence of revisions.
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 131]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Value Type: integer
+
+   Property Parameters: Non-standard property parameters can be
+   specified on this property.
+
+   Conformance: The property can be specified in "VEVENT", "VTODO" or
+   "VJOURNAL" calendar component.
+
+   Description: When a calendar component is created, its sequence
+   number is zero (US-ASCII decimal 48). It is monotonically incremented
+   by the "Organizer's" CUA each time the "Organizer" makes a
+   significant revision to the calendar component. When the "Organizer"
+   makes changes to one of the following properties, the sequence number
+   MUST be incremented:
+
+     .  "DTSTART"
+
+     .  "DTEND"
+
+     .  "DUE"
+
+     .  "RDATE"
+
+     .  "RRULE"
+
+     .  "EXDATE"
+
+     .  "EXRULE"
+
+     .  "STATUS"
+
+   In addition, changes made by the "Organizer" to other properties can
+   also force the sequence number to be incremented. The "Organizer" CUA
+   MUST increment the sequence number when ever it makes changes to
+   properties in the calendar component that the "Organizer" deems will
+   jeopardize the validity of the participation status of the
+   "Attendees". For example, changing the location of a meeting from one
+   locale to another distant locale could effectively impact the
+   participation status of the "Attendees".
+
+   The "Organizer" includes this property in an iCalendar object that it
+   sends to an "Attendee" to specify the current version of the calendar
+   component.
+
+   The "Attendee" includes this property in an iCalendar object that it
+   sends to the "Organizer" to specify the version of the calendar
+   component that the "Attendee" is referring to.
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 132]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   A change to the sequence number is not the mechanism that an
+   "Organizer" uses to request a response from the "Attendees". The
+   "RSVP" parameter on the "ATTENDEE" property is used by the
+   "Organizer" to indicate that a response from the "Attendees" is
+   requested.
+
+   Format Definition: This property is defined by the following
+   notation:
+
+     seq = "SEQUENCE" seqparam ":" integer CRLF
+     ; Default is "0"
+
+     seqparam   = *(";" xparam)
+
+   Example: The following is an example of this property for a calendar
+   component that was just created by the "Organizer".
+
+     SEQUENCE:0
+
+   The following is an example of this property for a calendar component
+   that has been revised two different times by the "Organizer".
+
+     SEQUENCE:2
+
+4.8.8 Miscellaneous Component Properties
+
+   The following properties specify information about a number of
+   miscellaneous features of calendar components.
+
+4.8.8.1 Non-standard Properties
+
+   Property Name: Any property name with a "X-" prefix
+
+   Purpose: This class of property provides a framework for defining
+   non-standard properties.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard and language property parameters
+   can be specified on this property.
+
+   Conformance: This property can be specified in any calendar
+   component.
+
+   Description: The MIME Calendaring and Scheduling Content Type
+   provides a "standard mechanism for doing non-standard things". This
+   extension support is provided for implementers to "push the envelope"
+   on the existing version of the memo. Extension properties are
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 133]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   specified by property and/or property parameter names that have the
+   prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER
+   X character followed by the HYPEN-MINUS character). It is recommended
+   that vendors concatenate onto this sentinel another short prefix text
+   to identify the vendor. This will facilitate readability of the
+   extensions and minimize possible collision of names between different
+   vendors. User agents that support this content type are expected to
+   be able to parse the extension properties and property parameters but
+   can ignore them.
+
+   At present, there is no registration authority for names of extension
+   properties and property parameters. The data type for this property
+   is TEXT. Optionally, the data type can be any of the other valid data
+   types.
+
+   Format Definition: The property is defined by the following notation:
+
+     x-prop     = x-name *(";" xparam) [";" languageparam] ":" text CRLF
+        ; Lines longer than 75 octets should be folded
+
+   Example: The following might be the ABC vendor's extension for an
+   audio-clip form of subject property:
+
+     X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav
+
+4.8.8.2 Request Status
+
+   Property Name: REQUEST-STATUS
+
+   Purpose: This property defines the status code returned for a
+   scheduling request.
+
+   Value Type: TEXT
+
+   Property Parameters: Non-standard and language property parameters
+   can be specified on this property.
+
+   Conformance: The property can be specified in "VEVENT", "VTODO",
+   "VJOURNAL" or "VFREEBUSY" calendar component.
+
+   Description: This property is used to return status code information
+   related to the processing of an associated iCalendar object. The data
+   type for this property is TEXT.
+
+   The value consists of a short return status component, a longer
+   return status description component, and optionally a status-specific
+   data component. The components of the value are separated by the
+   SEMICOLON character (US-ASCII decimal 59).
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 134]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The short return status is a PERIOD character (US-ASCII decimal 46)
+   separated 3-tuple of integers. For example, "3.1.1". The successive
+   levels of integers provide for a successive level of status code
+   granularity.
+
+   The following are initial classes for the return status code.
+   Individual iCalendar object methods will define specific return
+   status codes for these classes. In addition, other classes for the
+   return status code may be defined using the registration process
+   defined later in this memo.
+
+     |==============+===============================================|
+     | Short Return | Longer Return Status Description              |
+     | Status Code  |                                               |
+     |==============+===============================================|
+     |    1.xx      | Preliminary success. This class of status     |
+     |              | of status code indicates that the request has |
+     |              | request has been initially processed but that |
+     |              | completion is pending.                        |
+     |==============+===============================================|
+     |    2.xx      | Successful. This class of status code         |
+     |              | indicates that the request was completed      |
+     |              | successfuly. However, the exact status code   |
+     |              | can indicate that a fallback has been taken.  |
+     |==============+===============================================|
+     |    3.xx      | Client Error. This class of status code       |
+     |              | indicates that the request was not successful.|
+     |              | The error is the result of either a syntax or |
+     |              | a semantic error in the client formatted      |
+     |              | request. Request should not be retried until  |
+     |              | the condition in the request is corrected.    |
+     |==============+===============================================|
+     |    4.xx      | Scheduling Error. This class of status code   |
+     |              | indicates that the request was not successful.|
+     |              | Some sort of error occurred within the        |
+     |              | calendaring and scheduling service, not       |
+     |              | directly related to the request itself.       |
+     |==============+===============================================|
+
+   Format Definition: The property is defined by the following notation:
+
+     rstatus    = "REQUEST-STATUS" rstatparam ":"
+                  statcode ";" statdesc [";" extdata]
+
+     rstatparam = *(
+
+                ; the following is optional,
+                ; but MUST NOT occur more than once
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 135]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+                (";" languageparm) /
+
+                ; the following is optional,
+                ; and MAY occur more than once
+
+                (";" xparam)
+
+                )
+
+     statcode   = 1*DIGIT *("." 1*DIGIT)
+     ;Hierarchical, numeric return status code
+
+     statdesc   = text
+     ;Textual status description
+
+     extdata    = text
+     ;Textual exception data. For example, the offending property
+     ;name and value or complete property line.
+
+   Example: The following are some possible examples of this property.
+   The COMMA and SEMICOLON separator characters in the property value
+   are BACKSLASH character escaped because they appear in a  text value.
+
+     REQUEST-STATUS:2.0;Success
+
+     REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01
+
+     REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled
+      as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2
+
+     REQUEST-STATUS:4.1;Event conflict. Date/time is busy.
+
+     REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE:
+      MAILTO:jsmith@host.com
+
+5 iCalendar Object Examples
+
+   The following examples are provided as an informational source of
+   illustrative iCalendar objects consistent with this content type.
+
+   The following example specifies a three-day conference that begins at
+   8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20,
+   1996.
+
+     BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson
+     1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z
+     UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com
+     DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 136]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference
+     DESCRIPTION:Networld+Interop Conference
+       and Exhibit\nAtlanta World Congress Center\n
+      Atlanta, Georgia END:VEVENT END:VCALENDAR
+
+   The following example specifies a group scheduled meeting that begin
+   at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12,
+   1998. The "Organizer" has scheduled the meeting with one or more
+   calendar users in a group. A time zone specification for Eastern
+   United States has been specified.
+
+     BEGIN:VCALENDAR
+     PRODID:-//RDU Software//NONSGML HandCal//EN
+     VERSION:2.0
+     BEGIN:VTIMEZONE
+     TZID:US-Eastern
+     BEGIN:STANDARD
+     DTSTART:19981025T020000
+     RDATE:19981025T020000
+     TZOFFSETFROM:-0400
+     TZOFFSETTO:-0500
+     TZNAME:EST
+     END:STANDARD
+     BEGIN:DAYLIGHT
+     DTSTART:19990404T020000
+     RDATE:19990404T020000
+     TZOFFSETFROM:-0500
+     TZOFFSETTO:-0400
+     TZNAME:EDT
+     END:DAYLIGHT
+     END:VTIMEZONE
+     BEGIN:VEVENT
+     DTSTAMP:19980309T231000Z
+     UID:guid-1.host1.com
+     ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com
+     ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP:
+      MAILTO:employee-A@host.com
+     DESCRIPTION:Project XYZ Review Meeting
+     CATEGORIES:MEETING
+     CLASS:PUBLIC
+     CREATED:19980309T130000Z
+     SUMMARY:XYZ Project Review
+     DTSTART;TZID=US-Eastern:19980312T083000
+     DTEND;TZID=US-Eastern:19980312T093000
+     LOCATION:1CP Conference Room 4350
+     END:VEVENT
+     END:VCALENDAR
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 137]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The following is an example of an iCalendar object passed in a MIME
+   message with a single body part consisting of a "text/calendar"
+   Content Type.
+
+     TO:jsmith@host1.com
+     FROM:jdoe@host1.com
+     MIME-VERSION:1.0
+     MESSAGE-ID:<id3@host1.com>
+     CONTENT-TYPE:text/calendar
+
+     BEGIN:VCALENDAR
+     METHOD:xyz
+     VERSION:2.0
+     PRODID:-//ABC Corporation//NONSGML My Product//EN
+     BEGIN:VEVENT
+     DTSTAMP:19970324T1200Z
+     SEQUENCE:0
+     UID:uid3@host1.com
+     ORGANIZER:MAILTO:jdoe@host1.com
+     ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com
+     DTSTART:19970324T123000Z
+     DTEND:19970324T210000Z
+     CATEGORIES:MEETING,PROJECT
+     CLASS:PUBLIC
+     SUMMARY:Calendaring Interoperability Planning Meeting
+     DESCRIPTION:Discuss how we can test c&s interoperability\n
+      using iCalendar and other IETF standards.
+     LOCATION:LDB Lobby
+     ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/
+      conf/bkgrnd.ps
+     END:VEVENT
+     END:VCALENDAR
+
+   The following is an example of a to-do due on April 15, 1998. An
+   audio alarm has been specified to remind the calendar user at noon,
+   the day before the to-do is expected to be completed and repeat
+   hourly, four additional times. The to-do definition has been modified
+   twice since it was initially created.
+
+     BEGIN:VCALENDAR
+     VERSION:2.0
+     PRODID:-//ABC Corporation//NONSGML My Product//EN
+     BEGIN:VTODO
+     DTSTAMP:19980130T134500Z
+     SEQUENCE:2
+     UID:uid4@host1.com
+     ORGANIZER:MAILTO:unclesam@us.gov
+     ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 138]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     DUE:19980415T235959
+     STATUS:NEEDS-ACTION
+     SUMMARY:Submit Income Taxes
+     BEGIN:VALARM
+     ACTION:AUDIO
+     TRIGGER:19980403T120000
+     ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio-
+      files/ssbanner.aud
+     REPEAT:4
+     DURATION:PT1H
+     END:VALARM
+     END:VTODO
+     END:VCALENDAR
+
+   The following is an example of a journal entry.
+
+     BEGIN:VCALENDAR
+     VERSION:2.0
+     PRODID:-//ABC Corporation//NONSGML My Product//EN
+     BEGIN:VJOURNAL
+     DTSTAMP:19970324T120000Z
+     UID:uid5@host1.com
+     ORGANIZER:MAILTO:jsmith@host.com
+     STATUS:DRAFT
+     CLASS:PUBLIC
+     CATEGORY:Project Report, XYZ, Weekly Meeting
+     DESCRIPTION:Project xyz Review Meeting Minutes\n
+      Agenda\n1. Review of project version 1.0 requirements.\n2.
+     Definition
+      of project processes.\n3. Review of project schedule.\n
+      Participants: John Smith, Jane Doe, Jim Dandy\n-It was
+       decided that the requirements need to be signed off by
+       product marketing.\n-Project processes were accepted.\n
+      -Project schedule needs to account for scheduled holidays
+       and employee vacation time. Check with HR for specific
+       dates.\n-New schedule will be distributed by Friday.\n-
+      Next weeks meeting is cancelled. No meeting until 3/23.
+     END:VJOURNAL
+     END:VCALENDAR
+
+   The following is an example of published busy time information. The
+   iCalendar object might be placed in the network resource
+   www.host.com/calendar/busytime/jsmith.ifb.
+
+     BEGIN:VCALENDAR
+     VERSION:2.0
+     PRODID:-//RDU Software//NONSGML HandCal//EN
+     BEGIN:VFREEBUSY
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 139]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+     ORGANIZER:MAILTO:jsmith@host.com
+     DTSTART:19980313T141711Z
+     DTEND:19980410T141711Z
+     FREEBUSY:19980314T233000Z/19980315T003000Z
+     FREEBUSY:19980316T153000Z/19980316T163000Z
+     FREEBUSY:19980318T030000Z/19980318T040000Z
+     URL:http://www.host.com/calendar/busytime/jsmith.ifb
+     END:VFREEBUSY
+     END:VCALENDAR
+
+6 Recommended Practices
+
+   These recommended practices should be followed in order to assure
+   consistent handling of the following cases for an iCalendar object.
+
+   1.  Content lines longer than 75 octets SHOULD be folded.
+
+   2.  A calendar entry with a "DTSTART" property but no "DTEND"
+       property does not take up any time. It is intended to represent
+       an event that is associated with a given calendar date and time
+       of day, such as an anniversary. Since the event does not take up
+       any time, it MUST NOT be used to record busy time no matter what
+       the value for the "TRANSP" property.
+
+   3.  When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and
+       "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for
+       "VTODO" calendar components, have the same value data type (e.g.,
+       DATE-TIME), they SHOULD specify values in the same time format
+       (e.g., UTC time format).
+
+   4.  When the combination of the "RRULE" and "RDATE" properties on an
+       iCalendar object produces multiple instances having the same
+       start date/time, they should be collapsed to, and considered as,
+       a single instance.
+
+   5.  When a calendar user receives multiple requests for the same
+       calendar component (e.g., REQUEST for a "VEVENT" calendar
+       component) as a result of being on multiple mailing lists
+       specified by "ATTENDEE" properties in the request, they SHOULD
+       respond to only one of the requests. The calendar user SHOULD
+       also specify (using the "MEMBER" parameter of the "ATTENDEE"
+       property) which mailing list they are a member of.
+
+   6.  An implementation can truncate a "SUMMARY" property value to 255
+       characters.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 140]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   7.  If seconds of the minute are not supported by an implementation,
+       then a value of "00" SHOULD be specified for the seconds
+       component in a time value.
+
+   8.  If the value type parameter (VALUE=) contains an unknown value
+       type, it SHOULD be treated as TEXT.
+
+   9.  TZURL values SHOULD NOT be specified as a FILE URI type. This URI
+       form can be useful within an organization, but is problematic in
+       the Internet.
+
+   10.  Some possible English values for CATEGORIES property include
+        "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION",
+        "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT
+        IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL
+        OCCASION", "TRAVEL", "VACATION". Categories can be specified in
+        any registered language.
+
+   11.  Some possible English values for RESOURCES property include
+        "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD
+        PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO
+        PHONE", "VEHICLE". Resources can be specified in any registered
+        language.
+
+7 Registration of Content Type Elements
+
+   This section provides the process for registration of MIME
+   Calendaring and Scheduling Content Type iCalendar object methods and
+   new or modified properties.
+
+7.1 Registration of New and Modified iCalendar Object Methods
+
+   New MIME Calendaring and Scheduling Content Type iCalendar object
+   methods are registered by the publication of an IETF Request for
+   Comments (RFC). Changes to an iCalendar object method are registered
+   by the publication of a revision of the RFC defining the method.
+
+7.2 Registration of New Properties
+
+   This section defines procedures by which new properties or enumerated
+   property values for the MIME Calendaring and Scheduling Content Type
+   can be registered with the IANA. Non-IANA properties can be used by
+   bilateral agreement, provided the associated properties names follow
+   the "X-" convention.
+
+   The procedures defined here are designed to allow public comment and
+   review of new properties, while posing only a small impediment to the
+   definition of new properties.
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 141]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Registration of a new property is accomplished by the following
+   steps.
+
+7.2.1 Define the property
+
+   A property is defined by completing the following template.
+
+     To: ietf-calendar@imc.org
+
+     Subject: Registration of text/calendar MIME property XXX
+
+     Property name:
+
+     Property purpose:
+
+     Property value type(s):
+
+     Property parameter (s):
+
+     Conformance:
+
+     Description:
+
+     Format definition:
+
+     Examples:
+
+   The meaning of each field in the template is as follows.
+
+   Property name: The name of the property, as it will appear in the
+   body of an text/calendar MIME Content-Type "property: value" line to
+   the left of the colon ":".
+
+   Property purpose: The purpose of the property (e.g., to indicate a
+   delegate for the event or to-do, etc.). Give a short but clear
+   description.
+
+   Property value type (s): Any of the valid value types for the
+   property value needs to be specified. The default value type also
+   needs to be specified. If a new value type is specified, it needs to
+   be declared in this section.
+
+   Property parameter (s): Any of the valid property parameters for the
+   property needs to be specified.
+
+   Conformance: The calendar components that the property can appear in
+   needs to be specified.
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 142]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Description: Any special notes about the property, how it is to be
+   used, etc.
+
+   Format definition: The ABNF for the property definition needs to be
+   specified.
+
+   Examples: One or more examples of instances of the property needs to
+   be specified.
+
+7.2.2 Post the Property definition
+
+   The property description MUST be posted to the new property
+   discussion list, ietf-calendar@imc.org.
+
+7.2.3   Allow a comment period
+
+   Discussion on the new property MUST be allowed to take place on the
+   list for a minimum of two weeks. Consensus MUST be reached on the
+   property before proceeding to the next step.
+
+7.2.4 Submit the property for approval
+
+   Once the two-week comment period has elapsed, and the proposer is
+   convinced consensus has been reached on the property, the
+   registration application should be submitted to the Method Reviewer
+   for approval. The Method Reviewer is appointed to the Application
+   Area Directors and can either accept or reject the property
+   registration. An accepted registration should be passed on by the
+   Method Reviewer to the IANA for inclusion in the official IANA method
+   registry. The registration can be rejected for any of the following
+   reasons. 1) Insufficient comment period; 2) Consensus not reached; 3)
+   Technical deficiencies raised on the list or elsewhere have not been
+   addressed. The Method Reviewer's decision to reject a property can be
+   appealed by the proposer to the IESG, or the objections raised can be
+   addressed by the proposer and the property resubmitted.
+
+7.3 Property Change Control
+
+   Existing properties can be changed using the same process by which
+   they were registered.
+
+        1.           Define the change
+
+        2.           Post the change
+
+        3.           Allow a comment period
+
+        4.           Submit the property for approval
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 143]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   Note that the original author or any other interested party can
+   propose a change to an existing property, but that such changes
+   should only be proposed when there are serious omissions or errors in
+   the published memo. The Method Reviewer can object to a change if it
+   is not backward compatible, but is not required to do so.
+
+   Property definitions can never be deleted from the IANA registry, but
+   properties which are no longer believed to be useful can be declared
+   OBSOLETE by a change to their "intended use" field.
+
+8 References
+
+   [IMIP]     Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
+              Message-based Interoperability Protocol (IMIP)", RFC 2447,
+              November 1998.
+
+   [ITIP]     Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
+              "iCalendar Transport-Independent Interoperability Protocol
+              (iTIP) : Scheduling Events, Busy Time, To-dos and Journal
+              Entries", RFC 2446, November 1998.
+
+   [ISO 8601] ISO 8601, "Data elements and interchange formats-
+              Information interchange--Representation of dates and
+              times", International Organization for Standardization,
+              June, 1988.
+
+   [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support
+              Facilities--Registration Procedures for Public Text Owner
+              Identifiers", Second Edition, International Organization
+              for Standardization, April 1991.
+
+   [RFC 822]  Crocker, D., "Standard for the Format of ARPA Internet
+              Text Messages", STD 11, RFC 822, August 1982.
+
+   [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+              Resource Locators (URL)", RFC 1738, December 1994.
+
+   [RFC 1766] Alvestrand, H., "Tags for the Identification of
+              Languages", RFC 1766, March 1995.
+
+   [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
+              Extensions (MIME) - Part One: Format of Internet Message
+              Bodies", RFC 2045, November 1996.
+
+   [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail
+              Extensions (MIME) - Part Two: Media Types", RFC 2046,
+              November 1996.
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 144]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
+              Internet Mail Extensions (MIME) - Part Four: Registration
+              Procedures", RFC 2048, January 1997.
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", RFC 2234, November 1997.
+
+   [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO
+              10646", RFC 2279, January 1998.
+
+   [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type
+              for Directory Information", RFC 2425, September 1998.
+
+   [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
+              RFC 2426, September 1998.
+
+   [TZ]       Olson, A.D., et al, Time zone code and data,
+              ftp://elsie.nci.nih.gov/pub/, updated periodically.
+
+   [VCAL]     Internet Mail Consortium, "vCalendar - The Electronic
+              Calendaring and Scheduling Exchange Format",
+              http://www.imc.org/pdi/vcal-10.txt, September 18, 1996.
+
+9 Acknowledgments
+
+   A hearty thanks to the IETF Calendaring and Scheduling Working Group
+   and also the following individuals who have participated in the
+   drafting, review and discussion of this memo:
+
+   Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John
+   Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre
+   Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross
+   Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck
+   Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman,
+   Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch,
+   Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve
+   Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman,
+   John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert
+   Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod
+   Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg,
+   William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov,
+   James L. Weiner, Mike Weston, William Wyatt.
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 145]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+10 Authors' and Chairs' Addresses
+
+   The following address information is provided in a MIME-VCARD,
+   Electronic Business Card, format.
+
+   The authors of this memo are:
+
+   BEGIN:VCARD
+   VERSION:3.0
+   N:Dawson;Frank
+   FN:Frank Dawson
+   ORG:Lotus Development Corporation
+   ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive;
+    Raleigh;NC;27613-3502;USA
+   TEL;TYPE=WORK,MSG:+1-919-676-9515
+   TEL;TYPE=WORK,FAX:+1-919-676-9564
+   EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com
+   EMAIL;TYPE=INTERNET:fdawson@earthlink.net
+   URL:http://home.earthlink.net/~fdawson
+   END:VCARD
+
+   BEGIN:VCARD
+   VERSION:3.0
+   N:Stenerson;Derik
+   FN:Derik Stenerson
+   ORG:Microsoft Corporation
+   ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
+    Redmond;WA;98052-6399;USA
+   TEL;TYPE=WORK,MSG:+1-425-936-5522
+   TEL;TYPE=WORK,FAX:+1-425-936-7329
+   EMAIL;TYPE=INTERNET:deriks@Microsoft.com
+   END:VCARD
+
+   The iCalendar object is a result of the work of the Internet
+   Engineering Task Force Calendaring and Scheduling Working Group. The
+   chairmen of that working group are:
+
+   BEGIN:VCARD
+   VERSION:3.0
+   N:Ganguly;Anik
+   FN:Anik Ganguly
+   ORG: Open Text Inc.
+   ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
+    Livonia;MI;48152;USA
+   TEL;TYPE=WORK,MSG:+1-734-542-5955
+   EMAIL;TYPE=INTERNET:ganguly@acm.org
+   END:VCARD
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 146]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+   The co-chairman of that working group is:
+
+   BEGIN:VCARD
+   VERSION:3.0
+   N:Moskowitz;Robert
+   FN:Robert Moskowitz
+   EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
+   END:VCARD
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 147]
+
+RFC 2445                       iCalendar                   November 1998
+
+
+11.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dawson & Stenerson          Standards Track                   [Page 148]
+
+
+

+

+
+
\ No newline at end of file diff --git a/docs/rfc2445.txt b/docs/rfc2445.txt new file mode 100644 index 00000000..70a3bcdc --- /dev/null +++ b/docs/rfc2445.txt @@ -0,0 +1,8291 @@ + + + + + + +Network Working Group F. Dawson +Request for Comments: 2445 Lotus +Category: Standards Track D. Stenerson + Microsoft + November 1998 + + + Internet Calendaring and Scheduling Core Object Specification + (iCalendar) + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (1998). All Rights Reserved. + +Abstract + + There is a clear need to provide and deploy interoperable calendaring + and scheduling services for the Internet. Current group scheduling + and Personal Information Management (PIM) products are being extended + for use across the Internet, today, in proprietary ways. This memo + has been defined to provide the definition of a common format for + openly exchanging calendaring and scheduling information across the + Internet. + + This memo is formatted as a registration for a MIME media type per + [RFC 2048]. However, the format in this memo is equally applicable + for use outside of a MIME message content type. + + The proposed media type value is 'text/calendar'. This string would + label a media type containing calendaring and scheduling information + encoded as text characters formatted in a manner outlined below. + + This MIME media type provides a standard content type for capturing + calendar event, to-do and journal entry information. It also can be + used to convey free/busy time information. The content type is + suitable as a MIME message entity that can be transferred over MIME + based email systems, using HTTP or some other Internet transport. In + + + + + + +Dawson & Stenerson Standards Track [Page 1] + +RFC 2445 iCalendar November 1998 + + + addition, the content type is useful as an object for interactions + between desktop applications using the operating system clipboard, + drag/drop or file systems capabilities. + + This memo is based on the earlier work of the vCalendar specification + for the exchange of personal calendaring and scheduling information. + In order to avoid confusion with this referenced work, this memo is + to be known as the iCalendar specification. + + This memo defines the format for specifying iCalendar object methods. + An iCalendar object method is a set of usage constraints for the + iCalendar object. For example, these methods might define scheduling + messages that request an event be scheduled, reply to an event + request, send a cancellation notice for an event, modify or replace + the definition of an event, provide a counter proposal for an + original event request, delegate an event request to another + individual, request free or busy time, reply to a free or busy time + request, or provide similar scheduling messages for a to-do or + journal entry calendar component. The iCalendar Transport-indendent + Interoperability Protocol (iTIP) defined in [ITIP] is one such + scheduling protocol. + +Table of Contents + + 1 Introduction.....................................................5 + 2 Basic Grammar and Conventions....................................6 + 2.1 Formatting Conventions .......................................7 + 2.2 Related Memos ................................................8 + 2.3 International Considerations .................................8 + 3 Registration Information.........................................8 + 3.1 Content Type .................................................8 + 3.2 Parameters ...................................................9 + 3.3 Content Header Fields .......................................10 + 3.4 Encoding Considerations .....................................10 + 3.5 Security Considerations .....................................10 + 3.6 Interoperability Considerations .............................11 + 3.7 Applications Which Use This Media Type ......................11 + 3.8 Additional Information ......................................11 + 3.9 Magic Numbers ...............................................11 + 3.10 File Extensions ............................................11 + 3.11 Contact for Further Information: ...........................12 + 3.12 Intended Usage .............................................12 + 3.13 Authors/Change Controllers .................................12 + 4 iCalendar Object Specification..................................13 + 4.1 Content Lines ...............................................13 + 4.1.1 List and Field Separators ................................16 + 4.1.2 Multiple Values ..........................................16 + 4.1.3 Binary Content ...........................................16 + + + +Dawson & Stenerson Standards Track [Page 2] + +RFC 2445 iCalendar November 1998 + + + 4.1.4 Character Set ............................................17 + 4.2 Property Parameters .........................................17 + 4.2.1 Alternate Text Representation ............................18 + 4.2.2 Common Name ..............................................19 + 4.2.3 Calendar User Type .......................................20 + 4.2.4 Delegators ...............................................20 + 4.2.5 Delegatees ...............................................21 + 4.2.6 Directory Entry Reference ................................21 + 4.2.7 Inline Encoding ..........................................22 + 4.2.8 Format Type ..............................................23 + 4.2.9 Free/Busy Time Type ......................................23 + 4.2.10 Language ................................................24 + 4.2.11 Group or List Membership ................................25 + 4.2.12 Participation Status ....................................25 + 4.2.13 Recurrence Identifier Range .............................27 + 4.2.14 Alarm Trigger Relationship ..............................27 + 4.2.15 Relationship Type .......................................28 + 4.2.16 Participation Role ......................................29 + 4.2.17 RSVP Expectation ........................................29 + 4.2.18 Sent By .................................................30 + 4.2.19 Time Zone Identifier ....................................30 + 4.2.20 Value Data Types ........................................32 + 4.3 Property Value Data Types ...................................32 + 4.3.1 Binary ...................................................33 + 4.3.2 Boolean ..................................................33 + 4.3.3 Calendar User Address ....................................34 + 4.3.4 Date .....................................................34 + 4.3.5 Date-Time ................................................35 + 4.3.6 Duration .................................................37 + 4.3.7 Float ....................................................38 + 4.3.8 Integer ..................................................38 + 4.3.9 Period of Time ...........................................39 + 4.3.10 Recurrence Rule .........................................40 + 4.3.11 Text ....................................................45 + 4.3.12 Time ....................................................47 + 4.3.13 URI .....................................................49 + 4.3.14 UTC Offset ..............................................49 + 4.4 iCalendar Object ............................................50 + 4.5 Property ....................................................51 + 4.6 Calendar Components .........................................51 + 4.6.1 Event Component ..........................................52 + 4.6.2 To-do Component ..........................................55 + 4.6.3 Journal Component ........................................56 + 4.6.4 Free/Busy Component ......................................58 + 4.6.5 Time Zone Component ......................................60 + 4.6.6 Alarm Component ..........................................67 + 4.7 Calendar Properties .........................................73 + 4.7.1 Calendar Scale ...........................................73 + + + +Dawson & Stenerson Standards Track [Page 3] + +RFC 2445 iCalendar November 1998 + + + 4.7.2 Method ...................................................74 + 4.7.3 Product Identifier .......................................75 + 4.7.4 Version ..................................................76 + 4.8 Component Properties ........................................77 + 4.8.1 Descriptive Component Properties .........................77 + 4.8.1.1 Attachment ...........................................77 + 4.8.1.2 Categories ...........................................78 + 4.8.1.3 Classification .......................................79 + 4.8.1.4 Comment ..............................................80 + 4.8.1.5 Description ..........................................81 + 4.8.1.6 Geographic Position ..................................82 + 4.8.1.7 Location .............................................84 + 4.8.1.8 Percent Complete .....................................85 + 4.8.1.9 Priority .............................................85 + 4.8.1.10 Resources ...........................................87 + 4.8.1.11 Status ..............................................88 + 4.8.1.12 Summary .............................................89 + 4.8.2 Date and Time Component Properties .......................90 + 4.8.2.1 Date/Time Completed ..................................90 + 4.8.2.2 Date/Time End ........................................91 + 4.8.2.3 Date/Time Due ........................................92 + 4.8.2.4 Date/Time Start ......................................93 + 4.8.2.5 Duration .............................................94 + 4.8.2.6 Free/Busy Time .......................................95 + 4.8.2.7 Time Transparency ....................................96 + 4.8.3 Time Zone Component Properties ...........................97 + 4.8.3.1 Time Zone Identifier .................................97 + 4.8.3.2 Time Zone Name .......................................98 + 4.8.3.3 Time Zone Offset From ................................99 + 4.8.3.4 Time Zone Offset To .................................100 + 4.8.3.5 Time Zone URL .......................................101 + 4.8.4 Relationship Component Properties .......................102 + 4.8.4.1 Attendee ............................................102 + 4.8.4.2 Contact .............................................104 + 4.8.4.3 Organizer ...........................................106 + 4.8.4.4 Recurrence ID .......................................107 + 4.8.4.5 Related To ..........................................109 + 4.8.4.6 Uniform Resource Locator ............................110 + 4.8.4.7 Unique Identifier ...................................111 + 4.8.5 Recurrence Component Properties .........................112 + 4.8.5.1 Exception Date/Times ................................112 + 4.8.5.2 Exception Rule ......................................114 + 4.8.5.3 Recurrence Date/Times ...............................115 + 4.8.5.4 Recurrence Rule .....................................117 + 4.8.6 Alarm Component Properties ..............................126 + 4.8.6.1 Action ..............................................126 + 4.8.6.2 Repeat Count ........................................126 + 4.8.6.3 Trigger .............................................127 + + + +Dawson & Stenerson Standards Track [Page 4] + +RFC 2445 iCalendar November 1998 + + + 4.8.7 Change Management Component Properties ..................129 + 4.8.7.1 Date/Time Created ...................................129 + 4.8.7.2 Date/Time Stamp .....................................130 + 4.8.7.3 Last Modified .......................................131 + 4.8.7.4 Sequence Number .....................................131 + 4.8.8 Miscellaneous Component Properties ......................133 + 4.8.8.1 Non-standard Properties .............................133 + 4.8.8.2 Request Status ......................................134 + 5 iCalendar Object Examples......................................136 + 6 Recommended Practices..........................................140 + 7 Registration of Content Type Elements..........................141 + 7.1 Registration of New and Modified iCalendar Object Methods ..141 + 7.2 Registration of New Properties .............................141 + 7.2.1 Define the property .....................................142 + 7.2.2 Post the Property definition ............................143 + 7.2.3 Allow a comment period ..................................143 + 7.2.4 Submit the property for approval ........................143 + 7.3 Property Change Control ....................................143 + 8 References.....................................................144 + 9 Acknowledgments................................................145 + 10 Authors' and Chairs' Addresses................................146 + 11 Full Copyright Statement......................................148 + +1 Introduction + + The use of calendaring and scheduling has grown considerably in the + last decade. Enterprise and inter-enterprise business has become + dependent on rapid scheduling of events and actions using this + information technology. However, the longer term growth of + calendaring and scheduling, is currently limited by the lack of + Internet standards for the message content types that are central to + these knowledgeware applications. This memo is intended to progress + the level of interoperability possible between dissimilar calendaring + and scheduling applications. This memo defines a MIME content type + for exchanging electronic calendaring and scheduling information. The + Internet Calendaring and Scheduling Core Object Specification, or + iCalendar, allows for the capture and exchange of information + normally stored within a calendaring and scheduling application; such + as a Personal Information Manager (PIM) or a Group Scheduling + product. + + The iCalendar format is suitable as an exchange format between + applications or systems. The format is defined in terms of a MIME + content type. This will enable the object to be exchanged using + several transports, including but not limited to SMTP, HTTP, a file + system, desktop interactive protocols such as the use of a memory- + based clipboard or drag/drop interactions, point-to-point + asynchronous communication, wired-network transport, or some form of + + + +Dawson & Stenerson Standards Track [Page 5] + +RFC 2445 iCalendar November 1998 + + + unwired transport such as infrared might also be used. + + The memo also provides for the definition of iCalendar object methods + that will map this content type to a set of messages for supporting + calendaring and scheduling operations such as requesting, replying + to, modifying, and canceling meetings or appointments, to-dos and + journal entries. The iCalendar object methods can be used to define + other calendaring and scheduling operations such a requesting for and + replying with free/busy time data. Such a scheduling protocol is + defined in the iCalendar Transport-independent Interoperability + Protocol (iTIP) defined in [ITIP]. + + The memo also includes a formal grammar for the content type based on + the Internet ABNF defined in [RFC 2234]. This ABNF is required for + the implementation of parsers and to serve as the definitive + reference when ambiguities or questions arise in interpreting the + descriptive prose definition of the memo. + +2 Basic Grammar and Conventions + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and + "OPTIONAL" in this document are to be interoperated as described in + [RFC 2119]. + + This memo makes use of both a descriptive prose and a more formal + notation for defining the calendaring and scheduling format. + + The notation used in this memo is the ABNF notation of [RFC 2234]. + Readers intending on implementing this format defined in this memo + should be familiar with this notation in order to properly interpret + the specifications of this memo. + + All numeric and hexadecimal values used in this memo are given in + decimal notation. + + All names of properties, property parameters, enumerated property + values and property parameter values are case-insensitive. However, + all other property values are case-sensitive, unless otherwise + stated. + + Note: All indented editorial notes, such as this one, are + intended to provide the reader with additional information. The + information is not essential to the building of an + implementation conformant with this memo. The information is + provided to highlight a particular feature or characteristic of + the memo. + + + + +Dawson & Stenerson Standards Track [Page 6] + +RFC 2445 iCalendar November 1998 + + + The format for the iCalendar object is based on the syntax of the + [RFC 2425] content type. While the iCalendar object is not a profile + of the [RFC 2425] content type, it does reuse a number of the + elements from the [RFC 2425] specification. + +2.1 Formatting Conventions + + The mechanisms defined in this memo are defined in prose. Many of the + terms used to describe these have common usage that is different than + the standards usage of this memo. In order to reference within this + memo elements of the calendaring and scheduling model, core object + (this memo) or interoperability protocol [ITIP] some formatting + conventions have been used. Calendaring and scheduling roles are + referred to in quoted-strings of text with the first character of + each word in upper case. For example, "Organizer" refers to a role of + a "Calendar User" within the scheduling protocol defined by [ITIP]. + Calendar components defined by this memo are referred to with + capitalized, quoted-strings of text. All calendar components start + with the letter "V". For example, "VEVENT" refers to the event + calendar component, "VTODO" refers to the to-do calendar component + and "VJOURNAL" refers to the daily journal calendar component. + Scheduling methods defined by [ITIP] are referred to with + capitalized, quoted-strings of text. For example, "REQUEST" refers to + the method for requesting a scheduling calendar component be created + or modified, "REPLY" refers to the method a recipient of a request + uses to update their status with the "Organizer" of the calendar + component. + + The properties defined by this memo are referred to with capitalized, + quoted-strings of text, followed by the word "property". For example, + "ATTENDEE" property refers to the iCalendar property used to convey + the calendar address of a calendar user. Property parameters defined + by this memo are referred to with lowercase, quoted-strings of text, + followed by the word "parameter". For example, "value" parameter + refers to the iCalendar property parameter used to override the + default data type for a property value. Enumerated values defined by + this memo are referred to with capitalized text, either alone or + followed by the word "value". For example, the "MINUTELY" value can + be used with the "FREQ" component of the "RECUR" data type to specify + repeating components based on an interval of one minute or more. + + + + + + + + + + + +Dawson & Stenerson Standards Track [Page 7] + +RFC 2445 iCalendar November 1998 + + +2.2 Related Memos + + Implementers will need to be familiar with several other memos that, + along with this memo, form a framework for Internet calendaring and + scheduling standards. This memo, [ICAL], specifies a core + specification of objects, data types, properties and property + parameters. + + [ITIP] - specifies an interoperability protocol for scheduling + between different implementations; + + [IMIP] specifies an Internet email binding for [ITIP]. + + This memo does not attempt to repeat the specification of concepts or + definitions from these other memos. Where possible, references are + made to the memo that provides for the specification of these + concepts or definitions. + +2.3 International Considerations + + In the rest of this document, descriptions of characters are of the + form "character name (codepoint)", where "codepoint" is from the US- + ASCII character set. The "character name" is the authoritative + description; (codepoint) is a reference to that character in US-ASCII + or US-ASCII compatible sets (for example the ISO-8859-x family, UTF- + 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set + is used, appropriate code-point from that character set MUST be + chosen instead. Use of non-US-ASCII-compatible character sets is NOT + recommended. + +3 Registration Information + + The Calendaring and Scheduling Core Object Specification is intended + for use as a MIME content type. However, the implementation of the + memo is in no way limited solely as a MIME content type. + +3.1 Content Type + + The following text is intended to register this memo as the MIME + content type "text/calendar". + + To: ietf-types@uninett.no + + Subject: Registration of MIME content type text/calendar. + + MIME media type name: text + + MIME subtype name: calendar + + + +Dawson & Stenerson Standards Track [Page 8] + +RFC 2445 iCalendar November 1998 + + +3.2 Parameters + + Required parameters: none + + Optional parameters: charset, method, component and optinfo + + The "charset" parameter is defined in [RFC 2046] for other body + parts. It is used to identify the default character set used within + the body part. + + The "method" parameter is used to convey the iCalendar object method + or transaction semantics for the calendaring and scheduling + information. It also is an identifier for the restricted set of + properties and values that the iCalendar object consists of. The + parameter is to be used as a guide for applications interpreting the + information contained within the body part. It SHOULD NOT be used to + exclude or require particular pieces of information unless the + identified method definition specifically calls for this behavior. + Unless specifically forbidden by a particular method definition, a + text/calendar content type can contain any set of properties + permitted by the Calendaring and Scheduling Core Object + Specification. The "method" parameter MUST be the same value as that + specified in the "METHOD" component property in the iCalendar object. + If one is present, the other MUST also be present. + + The value for the "method" parameter is defined as follows: + + method = 1*(ALPHA / DIGIT / "-") + ; IANA registered iCalendar object method + + The "component" parameter conveys the type of iCalendar calendar + component within the body part. If the iCalendar object contains more + than one calendar component type, then multiple component parameters + MUST be specified. + + The value for the "component" parameter is defined as follows: + + component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" + / "VTIMEZONE" / x-name / iana-token) + + The "optinfo" parameter conveys optional information about the + iCalendar object within the body part. This parameter can only + specify semantics already specified by the iCalendar object and that + can be otherwise determined by parsing the body part. In addition, + the optional information specified by this parameter MUST be + consistent with that information specified by the iCalendar object. + For example, it can be used to convey the "Attendee" response status + to a meeting request. The parameter value consists of a string value. + + + +Dawson & Stenerson Standards Track [Page 9] + +RFC 2445 iCalendar November 1998 + + + The parameter can be specified multiple times. + + This parameter MAY only specify semantics already specified by the + iCalendar object and that can be otherwise determined by parsing the + body part. + + The value for the "optinfo" parameter is defined as follows: + + optinfo = infovalue / qinfovalue + + infovalue = iana-token / x-name + + qinfovalue = DQUOTE (infovalue) DQUOTE + +3.3 Content Header Fields + + Optional content header fields: Any header fields defined by [RFC + 2045]. + +3.4 Encoding Considerations + + This MIME content type can contain 8bit characters, so the use of + quoted-printable or BASE64 MIME content-transfer-encodings might be + necessary when iCalendar objects are transferred across protocols + restricted to the 7bit repertoire. Note that a text valued property + in the content entity can also have content encoding of special + characters using a BACKSLASH character (US-ASCII decimal 92) + escapement technique. This means that content values can end up + encoded twice. + +3.5 Security Considerations + + SPOOFING - - In this memo, the "Organizer" is the only person + authorized to make changes to an existing "VEVENT", "VTODO", + "VJOURNAL" calendar component and redistribute the updates to the + "Attendees". An iCalendar object that maliciously changes or cancels + an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar + component might be constructed by someone other than the "Organizer" + and sent to the "Attendees". In addition in this memo, other than the + "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" + calendar component is the only other person authorized to update any + parameter associated with their "ATTENDEE" property and send it to + the "Organizer". An iCalendar object that maliciously changes the + "ATTENDEE" parameters can be constructed by someone other than the + real "Attendee" and sent to the "Organizer". + + + + + + +Dawson & Stenerson Standards Track [Page 10] + +RFC 2445 iCalendar November 1998 + + + PROCEDURAL ALARMS - - An iCalendar object can be created that + contains a "VEVENT" and "VTODO" calendar component with "VALARM" + calendar components. The "VALARM" calendar component can be of type + PROCEDURE and can have an attachment containing some sort of + executable program. Implementations that incorporate these types of + alarms are subject to any virus or malicious attack that might occur + as a result of executing the attachment. + + ATTACHMENTS - - An iCalendar object can include references to Uniform + Resource Locators that can be programmed resources. + + Implementers and users of this memo should be aware of the network + security implications of accepting and parsing such information. In + addition, the security considerations observed by implementations of + electronic mail systems should be followed for this memo. + +3.6 Interoperability Considerations + + This MIME content type is intended to define a common format for + conveying calendaring and scheduling information between different + systems. It is heavily based on the earlier [VCAL] industry + specification. + +3.7 Applications Which Use This Media Type + + This content-type is designed for widespread use by Internet + calendaring and scheduling applications. In addition, applications in + the workflow and document management area might find this content- + type applicable. The [ITIP] and [IMIP] Internet protocols directly + use this content-type also. Future work on an Internet calendar + access protocol will utilize this content-type too. + +3.8 Additional Information + + This memo defines this content-type. + +3.9 Magic Numbers + + None. + +3.10 File Extensions + + The file extension of "ics" is to be used to designate a file + containing (an arbitrary set of) calendaring and scheduling + information consistent with this MIME content type. + + + + + + +Dawson & Stenerson Standards Track [Page 11] + +RFC 2445 iCalendar November 1998 + + + The file extension of "ifb" is to be used to designate a file + containing free or busy time information consistent with this MIME + content type. + + Macintosh file type codes: The file type code of "iCal" is to be used + in Apple MacIntosh operating system environments to designate a file + containing calendaring and scheduling information consistent with + this MIME media type. + + The file type code of "iFBf" is to be used in Apple MacIntosh + operating system environments to designate a file containing free or + busy time information consistent with this MIME media type. + +3.11 Contact for Further Information: + + Frank Dawson + 6544 Battleford Drive + Raleigh, NC 27613-3502 + 919-676-9515 (Telephone) + 919-676-9564 (Data/Facsimile) + Frank_Dawson@Lotus.com (Internet Mail) + + Derik Stenerson + One Microsoft Way + Redmond, WA 98052-6399 + 425-936-5522 (Telephone) + 425-936-7329 (Facsimile) + deriks@microsoft.com (Internet Mail) + +3.12 Intended Usage + + COMMON + +3.13 Authors/Change Controllers + + Frank Dawson + 6544 Battleford Drive + Raleigh, NC 27613-3502 + 919-676-9515 (Telephone) + 919-676-9564 (Data/Facsimile) + Frank_Dawson@Lotus.com (Internet Mail) + + Derik Stenerson + One Microsoft Way + Redmond, WA 98052-6399 + 425-936-5522 (Telephone) + 425-936-7329 (Facsimile) + deriks@microsoft.com (Internet Mail) + + + +Dawson & Stenerson Standards Track [Page 12] + +RFC 2445 iCalendar November 1998 + + +4 iCalendar Object Specification + + The following sections define the details of a Calendaring and + Scheduling Core Object Specification. This information is intended to + be an integral part of the MIME content type registration. In + addition, this information can be used independent of such content + registration. In particular, this memo has direct applicability for + use as a calendaring and scheduling exchange format in file-, memory- + or network-based transport mechanisms. + +4.1 Content Lines + + The iCalendar object is organized into individual lines of text, + called content lines. Content lines are delimited by a line break, + which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII + decimal 10). + + Lines of text SHOULD NOT be longer than 75 octets, excluding the line + break. Long content lines SHOULD be split into a multiple line + representations using a line "folding" technique. That is, a long + line can be split between any two characters by inserting a CRLF + immediately followed by a single linear white space character (i.e., + SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence + of CRLF followed immediately by a single linear white space character + is ignored (i.e., removed) when processing the content type. + + For example the line: + + DESCRIPTION:This is a long description that exists on a long line. + + Can be represented as: + + DESCRIPTION:This is a lo + ng description + that exists on a long line. + + The process of moving from this folded multiple line representation + to its single line representation is called "unfolding". Unfolding is + accomplished by removing the CRLF character and the linear white + space character that immediately follows. + + When parsing a content line, folded lines MUST first be unfolded + according to the unfolding procedure described above. When generating + a content line, lines longer than 75 octets SHOULD be folded + according to the folding procedure described above. + + + + + + +Dawson & Stenerson Standards Track [Page 13] + +RFC 2445 iCalendar November 1998 + + + The content information associated with an iCalendar object is + formatted using a syntax similar to that defined by [RFC 2425]. That + is, the content information consists of CRLF-separated content lines. + + The following notation defines the lines of content in an iCalendar + object: + + contentline = name *(";" param ) ":" value CRLF + ; This ABNF is just a general definition for an initial parsing + ; of the content line into its property name, parameter list, + ; and value string + + ; When parsing a content line, folded lines MUST first + ; be unfolded according to the unfolding procedure + ; described above. When generating a content line, lines + ; longer than 75 octets SHOULD be folded according to + ; the folding procedure described above. + + name = x-name / iana-token + + iana-token = 1*(ALPHA / DIGIT / "-") + ; iCalendar identifier registered with IANA + + x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") + ; Reservered for experimental use. Not intended for use in + ; released products. + + vendorid = 3*(ALPHA / DIGIT) ;Vendor identification + + param = param-name "=" param-value + *("," param-value) + ; Each property defines the specific ABNF for the parameters + ; allowed on the property. Refer to specific properties for + ; precise parameter ABNF. + + param-name = iana-token / x-token + + param-value = paramtext / quoted-string + + paramtext = *SAFE-CHAR + + value = *VALUE-CHAR + + quoted-string = DQUOTE *QSAFE-CHAR DQUOTE + + NON-US-ASCII = %x80-F8 + ; Use restricted by charset parameter + ; on outer MIME object (UTF-8 preferred) + + + +Dawson & Stenerson Standards Track [Page 14] + +RFC 2445 iCalendar November 1998 + + + QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII + ; Any character except CTLs and DQUOTE + + SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E + / NON-US-ASCII + ; Any character except CTLs, DQUOTE, ";", ":", "," + + VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII + ; Any textual character + + CR = %x0D + ; carriage return + + LF = %x0A + ; line feed + + CRLF = CR LF + ; Internet standard newline + + CTL = %x00-08 / %x0A-1F / %x7F + ; Controls + + ALPHA = %x41-5A / %x61-7A ; A-Z / a-z + + DIGIT = %x30-39 + ; 0-9 + + DQUOTE = %x22 + ; Quotation Mark + + WSP = SPACE / HTAB + + SPACE = %x20 + + HTAB = %x09 + + The property value component of a content line has a format that is + property specific. Refer to the section describing each property for + a definition of this format. + + All names of properties, property parameters, enumerated property + values and property parameter values are case-insensitive. However, + all other property values are case-sensitive, unless otherwise + stated. + + + + + + + +Dawson & Stenerson Standards Track [Page 15] + +RFC 2445 iCalendar November 1998 + + +4.1.1 List and Field Separators + + Some properties and parameters allow a list of values. Values in a + list of values MUST be separated by a COMMA character (US-ASCII + decimal 44). There is no significance to the order of values in a + list. For those parameter values (such as those that specify URI + values) that are specified in quoted-strings, the individual quoted- + strings are separated by a COMMA character (US-ASCII decimal 44). + + Some property values are defined in terms of multiple parts. These + structured property values MUST have their value parts separated by a + SEMICOLON character (US-ASCII decimal 59). + + Some properties allow a list of parameters. Each property parameter + in a list of property parameters MUST be separated by a SEMICOLON + character (US-ASCII decimal 59). + + Property parameters with values containing a COLON, a SEMICOLON or a + COMMA character MUST be placed in quoted text. + + For example, in the following properties a SEMICOLON is used to + separate property parameters from each other, and a COMMA is used to + separate property values in a value list. + + ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO: + jsmith@host.com + + RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 + +4.1.2 Multiple Values + + Some properties defined in the iCalendar object can have multiple + values. The general rule for encoding multi-valued items is to simply + create a new content line for each value, including the property + name. However, it should be noted that some properties support + encoding multiple values in a single property by separating the + values with a COMMA character (US-ASCII decimal 44). Individual + property definitions should be consulted for determining whether a + specific property allows multiple values and in which of these two + forms. + +4.1.3 Binary Content + + Binary content information in an iCalendar object SHOULD be + referenced using a URI within a property value. That is the binary + content information SHOULD be placed in an external MIME entity that + can be referenced by a URI from within the iCalendar object. In + applications where this is not feasible, binary content information + + + +Dawson & Stenerson Standards Track [Page 16] + +RFC 2445 iCalendar November 1998 + + + can be included within an iCalendar object, but only after first + encoding it into text using the "BASE64" encoding method defined in + [RFC 2045]. Inline binary contact SHOULD only be used in applications + whose special circumstances demand that an iCalendar object be + expressed as a single entity. A property containing inline binary + content information MUST specify the "ENCODING" property parameter. + Binary content information placed external to the iCalendar object + MUST be referenced by a uniform resource identifier (URI). + + The following example specifies an "ATTACH" property that references + an attachment external to the iCalendar object with a URI reference: + + ATTACH:http://xyz.com/public/quarterly-report.doc + + The following example specifies an "ATTACH" property with inline + binary encoded content information: + + ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: + MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U + EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE + <...remainder of "BASE64" encoded binary data...> + +4.1.4 Character Set + + There is not a property parameter to declare the character set used + in a property value. The default character set for an iCalendar + object is UTF-8 as defined in [RFC 2279]. + + The "charset" Content-Type parameter can be used in MIME transports + to specify any other IANA registered character set. + +4.2 Property Parameters + + A property can have attributes associated with it. These "property + parameters" contain meta-information about the property or the + property value. Property parameters are provided to specify such + information as the location of an alternate text representation for a + property value, the language of a text property value, the data type + of the property value and other attributes. + + Property parameter values that contain the COLON (US-ASCII decimal + 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) + character separators MUST be specified as quoted-string text values. + Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII + decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22) + character is used as a delimiter for parameter values that contain + restricted characters or URI text. For example: + + + + +Dawson & Stenerson Standards Track [Page 17] + +RFC 2445 iCalendar November 1998 + + + DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards + Conference - - Las Vegas, NV, USA + + Property parameter values that are not in quoted strings are case + insensitive. + + The general property parameters defined by this memo are defined by + the following notation: + + parameter = altrepparam ; Alternate text representation + / cnparam ; Common name + / cutypeparam ; Calendar user type + / delfromparam ; Delegator + / deltoparam ; Delegatee + / dirparam ; Directory entry + / encodingparam ; Inline encoding + / fmttypeparam ; Format type + / fbtypeparam ; Free/busy time type + / languageparam ; Language for text + / memberparam ; Group or list membership + / partstatparam ; Participation status + / rangeparam ; Recurrence identifier range + / trigrelparam ; Alarm trigger relationship + / reltypeparam ; Relationship type + / roleparam ; Participation role + / rsvpparam ; RSVP expectation + / sentbyparam ; Sent by + / tzidparam ; Reference to time zone object + / valuetypeparam ; Property value data type + / ianaparam + ; Some other IANA registered iCalendar parameter. + / xparam + ; A non-standard, experimental parameter. + + ianaparam = iana-token "=" param-value *("," param-value) + + xparam =x-name "=" param-value *("," param-value) + +4.2.1 Alternate Text Representation + + Parameter Name: ALTREP + + Purpose: To specify an alternate text representation for the property + value. + + Format Definition: The property parameter is defined by the following + notation: + + + + +Dawson & Stenerson Standards Track [Page 18] + +RFC 2445 iCalendar November 1998 + + + altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE + + Description: The parameter specifies a URI that points to an + alternate representation for a textual property value. A property + specifying this parameter MUST also include a value that reflects the + default representation of the text value. The individual URI + parameter values MUST each be specified in a quoted-string. + + Example: + + DESCRIPTION;ALTREP="CID:":Project + XYZ Review Meeting will include the following agenda items: (a) + Market Overview, (b) Finances, (c) Project Management + + The "ALTREP" property parameter value might point to a "text/html" + content portion. + + Content-Type:text/html + Content-Id: + + +

Project XYZ Review Meeting will include the following + agenda items:

  1. Market + Overview
  2. Finances
  3. Project Management

+ + +4.2.2 Common Name + + Parameter Name: CN + + Purpose: To specify the common name to be associated with the + calendar user specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + cnparam = "CN" "=" param-value + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter specifies the common name to be + associated with the calendar user specified by the property. The + parameter value is text. The parameter value can be used for display + text to be associated with the calendar address specified by the + property. + + + + + + + +Dawson & Stenerson Standards Track [Page 19] + +RFC 2445 iCalendar November 1998 + + + Example: + + ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com + +4.2.3 Calendar User Type + + Parameter Name: CUTYPE + + Purpose: To specify the type of calendar user specified by the + property. + + Format Definition: The property parameter is defined by the following + notation: + + cutypeparam = "CUTYPE" "=" + ("INDIVIDUAL" ; An individual + / "GROUP" ; A group of individuals + / "RESOURCE" ; A physical resource + / "ROOM" ; A room resource + / "UNKNOWN" ; Otherwise not known + / x-name ; Experimental type + / iana-token) ; Other IANA registered + ; type + ; Default is INDIVIDUAL + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter identifies the type of calendar + user specified by the property. If not specified on a property that + allows this parameter, the default is INDIVIDUAL. + + Example: + + ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org + +4.2.4 Delegators + + Parameter Name: DELEGATED-FROM + + Purpose: To specify the calendar users that have delegated their + participation to the calendar user specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE + *("," DQUOTE cal-address DQUOTE) + + + + + +Dawson & Stenerson Standards Track [Page 20] + +RFC 2445 iCalendar November 1998 + + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. This parameter can be specified on a property + that has a value type of calendar address. This parameter specifies + those calendar uses that have delegated their participation in a + group scheduled event or to-do to the calendar user specified by the + property. The value MUST be a MAILTO URI as defined in [RFC 1738]. + The individual calendar address parameter values MUST each be + specified in a quoted-string. + + Example: + + ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO: + jdoe@host.com + +4.2.5 Delegatees + + Parameter Name: DELEGATED-TO + + Purpose: To specify the calendar users to whom the calendar user + specified by the property has delegated participation. + + Format Definition: The property parameter is defined by the following + notation: + + deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE + *("," DQUOTE cal-address DQUOTE) + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. This parameter specifies those calendar users + whom have been delegated participation in a group scheduled event or + to-do by the calendar user specified by the property. The value MUST + be a MAILTO URI as defined in [RFC 1738]. The individual calendar + address parameter values MUST each be specified in a quoted-string. + + Example: + + ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@ + host.com":MAILTO:jsmith@host.com + +4.2.6 Directory Entry Reference + + Parameter Name: DIR + + Purpose: To specify reference to a directory entry associated with + the calendar user specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + + +Dawson & Stenerson Standards Track [Page 21] + +RFC 2445 iCalendar November 1998 + + + dirparam = "DIR" "=" DQUOTE uri DQUOTE + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter specifies a reference to the + directory entry associated with the calendar user specified by the + property. The parameter value is a URI. The individual URI parameter + values MUST each be specified in a quoted-string. + + Example: + + ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS?? + (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com + +4.2.7 Inline Encoding + + Parameter Name: ENCODING + + Purpose: To specify an alternate inline encoding for the property + value. + + Format Definition: The property parameter is defined by the following + notation: + + encodingparam = "ENCODING" "=" + ("8BIT" + ; "8bit" text encoding is defined in [RFC 2045] + / "BASE64" + ; "BASE64" binary encoding format is defined in [RFC 2045] + / iana-token + ; Some other IANA registered iCalendar encoding type + / x-name) + ; A non-standard, experimental encoding type + + Description: The property parameter identifies the inline encoding + used in a property value. The default encoding is "8BIT", + corresponding to a property value consisting of text. The "BASE64" + encoding type corresponds to a property value encoded using the + "BASE64" encoding defined in [RFC 2045]. + + If the value type parameter is ";VALUE=BINARY", then the inline + encoding parameter MUST be specified with the value + ";ENCODING=BASE64". + + + + + + + + + +Dawson & Stenerson Standards Track [Page 22] + +RFC 2445 iCalendar November 1998 + + + Example: + + ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC + CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA + qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw + <...remainder of "BASE64" encoded binary data...> + +4.2.8 Format Type + + Parameter Name: FMTTYPE + + Purpose: To specify the content type of a referenced object. + + Format Definition: The property parameter is defined by the following + notation: + + fmttypeparam = "FMTTYPE" "=" iana-token + ; A IANA registered content type + / x-name + ; A non-standard content type + + Description: This parameter can be specified on properties that are + used to reference an object. The parameter specifies the content type + of the referenced object. For example, on the "ATTACH" property, a + FTP type URI value does not, by itself, necessarily convey the type + of content associated with the resource. The parameter value MUST be + the TEXT for either an IANA registered content type or a non-standard + content type. + + Example: + + ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/ + agenda.doc + +4.2.9 Free/Busy Time Type + + Parameter Name: FBTYPE + + Purpose: To specify the free or busy time type. + + Format Definition: The property parameter is defined by the following + notation: + + fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" + / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" + / x-name + ; Some experimental iCalendar data type. + / iana-token) + + + +Dawson & Stenerson Standards Track [Page 23] + +RFC 2445 iCalendar November 1998 + + + ; Some other IANA registered iCalendar data type. + + Description: The parameter specifies the free or busy time type. The + value FREE indicates that the time interval is free for scheduling. + The value BUSY indicates that the time interval is busy because one + or more events have been scheduled for that interval. The value + BUSY-UNAVAILABLE indicates that the time interval is busy and that + the interval can not be scheduled. The value BUSY-TENTATIVE indicates + that the time interval is busy because one or more events have been + tentatively scheduled for that interval. If not specified on a + property that allows this parameter, the default is BUSY. + + Example: The following is an example of this parameter on a FREEBUSY + property. + + FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z + +4.2.10 Language + + Parameter Name: LANGUAGE + + Purpose: To specify the language for text values in a property or + property parameter. + + Format Definition: The property parameter is defined by the following + notation: + + languageparam = "LANGUAGE" "=" language + + language = + + Description: This parameter can be specified on properties with a + text value type. The parameter identifies the language of the text in + the property or property parameter value. The value of the "language" + property parameter is that defined in [RFC 1766]. + + For transport in a MIME entity, the Content-Language header field can + be used to set the default language for the entire body part. + Otherwise, no default language is assumed. + + Example: + + SUMMARY;LANGUAGE=us-EN:Company Holiday Party + + LOCATION;LANGUAGE=en:Germany + LOCATION;LANGUAGE=no:Tyskland + + + + + +Dawson & Stenerson Standards Track [Page 24] + +RFC 2445 iCalendar November 1998 + + + The following example makes use of the Quoted-Printable encoding in + order to represent non-ASCII characters. + + LOCATION;LANGUAGE=da:K=F8benhavn + LOCATION;LANGUAGE=en:Copenhagen + +4.2.11 Group or List Membership + + Parameter Name: MEMBER + + Purpose: To specify the group or list membership of the calendar user + specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE + *("," DQUOTE cal-address DQUOTE) + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter identifies the groups or list + membership for the calendar user specified by the property. The + parameter value either a single calendar address in a quoted-string + or a COMMA character (US-ASCII decimal 44) list of calendar + addresses, each in a quoted-string. The individual calendar address + parameter values MUST each be specified in a quoted-string. + + Example: + + ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com + + ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host. + com":MAILTO:janedoe@host.com + +4.2.12 Participation Status + + Parameter Name: PARTSTAT + + Purpose: To specify the participation status for the calendar user + specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + partstatparam = "PARTSTAT" "=" + ("NEEDS-ACTION" ; Event needs action + / "ACCEPTED" ; Event accepted + / "DECLINED" ; Event declined + + + +Dawson & Stenerson Standards Track [Page 25] + +RFC 2445 iCalendar November 1998 + + + / "TENTATIVE" ; Event tentatively + ; accepted + / "DELEGATED" ; Event delegated + / x-name ; Experimental status + / iana-token) ; Other IANA registered + ; status + ; These are the participation statuses for a "VEVENT". Default is + ; NEEDS-ACTION + partstatparam /= "PARTSTAT" "=" + ("NEEDS-ACTION" ; To-do needs action + / "ACCEPTED" ; To-do accepted + / "DECLINED" ; To-do declined + / "TENTATIVE" ; To-do tentatively + ; accepted + / "DELEGATED" ; To-do delegated + / "COMPLETED" ; To-do completed. + ; COMPLETED property has + ;date/time completed. + / "IN-PROCESS" ; To-do in process of + ; being completed + / x-name ; Experimental status + / iana-token) ; Other IANA registered + ; status + ; These are the participation statuses for a "VTODO". Default is + ; NEEDS-ACTION + + partstatparam /= "PARTSTAT" "=" + ("NEEDS-ACTION" ; Journal needs action + / "ACCEPTED" ; Journal accepted + / "DECLINED" ; Journal declined + / x-name ; Experimental status + / iana-token) ; Other IANA registered + ; status + ; These are the participation statuses for a "VJOURNAL". Default is + ; NEEDS-ACTION + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter identifies the participation + status for the calendar user specified by the property value. The + parameter values differ depending on whether they are associated with + a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST + match one of the values allowed for the given calendar component. If + not specified on a property that allows this parameter, the default + value is NEEDS-ACTION. + + Example: + + ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com + + + +Dawson & Stenerson Standards Track [Page 26] + +RFC 2445 iCalendar November 1998 + + +4.2.13 Recurrence Identifier Range + + Parameter Name: RANGE + + Purpose: To specify the effective range of recurrence instances from + the instance specified by the recurrence identifier specified by the + property. + + Format Definition: The property parameter is defined by the following + notation: + + rangeparam = "RANGE" "=" ("THISANDPRIOR" + ; To specify all instances prior to the recurrence identifier + / "THISANDFUTURE") + ; To specify the instance specified by the recurrence identifier + ; and all subsequent recurrence instances + + Description: The parameter can be specified on a property that + specifies a recurrence identifier. The parameter specifies the + effective range of recurrence instances that is specified by the + property. The effective range is from the recurrence identified + specified by the property. If this parameter is not specified an + allowed property, then the default range is the single instance + specified by the recurrence identifier value of the property. The + parameter value can be "THISANDPRIOR" to indicate a range defined by + the recurrence identified value of the property and all prior + instances. The parameter value can also be "THISANDFUTURE" to + indicate a range defined by the recurrence identifier and all + subsequent instances. + + Example: + + RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z + +4.2.14 Alarm Trigger Relationship + + Parameter Name: RELATED + + Purpose: To specify the relationship of the alarm trigger with + respect to the start or end of the calendar component. + + Format Definition: The property parameter is defined by the following + notation: + + trigrelparam = "RELATED" "=" + ("START" ; Trigger off of start + / "END") ; Trigger off of end + + + + +Dawson & Stenerson Standards Track [Page 27] + +RFC 2445 iCalendar November 1998 + + + Description: The parameter can be specified on properties that + specify an alarm trigger with a DURATION value type. The parameter + specifies whether the alarm will trigger relative to the start or end + of the calendar component. The parameter value START will set the + alarm to trigger off the start of the calendar component; the + parameter value END will set the alarm to trigger off the end of the + calendar component. If the parameter is not specified on an allowable + property, then the default is START. + + Example: + + TRIGGER;RELATED=END:PT5M + +4.2.15 Relationship Type + + Parameter Name: RELTYPE + + Purpose: To specify the type of hierarchical relationship associated + with the calendar component specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + reltypeparam = "RELTYPE" "=" + ("PARENT" ; Parent relationship. Default. + / "CHILD" ; Child relationship + / "SIBLING ; Sibling relationship + / iana-token ; Some other IANA registered + ; iCalendar relationship type + / x-name) ; A non-standard, experimental + ; relationship type + + Description: This parameter can be specified on a property that + references another related calendar. The parameter specifies the + hierarchical relationship type of the calendar component referenced + by the property. The parameter value can be PARENT, to indicate that + the referenced calendar component is a superior of calendar + component; CHILD to indicate that the referenced calendar component + is a subordinate of the calendar component; SIBLING to indicate that + the referenced calendar component is a peer of the calendar + component. If this parameter is not specified on an allowable + property, the default relationship type is PARENT. + + Example: + + RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com> + + + + + +Dawson & Stenerson Standards Track [Page 28] + +RFC 2445 iCalendar November 1998 + + +4.2.16 Participation Role + + Parameter Name: ROLE + + Purpose: To specify the participation role for the calendar user + specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + roleparam = "ROLE" "=" + ("CHAIR" ; Indicates chair of the + ; calendar entity + / "REQ-PARTICIPANT" ; Indicates a participant whose + ; participation is required + / "OPT-PARTICIPANT" ; Indicates a participant whose + ; participation is optional + / "NON-PARTICIPANT" ; Indicates a participant who is + ; copied for information + ; purposes only + / x-name ; Experimental role + / iana-token) ; Other IANA role + ; Default is REQ-PARTICIPANT + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter specifies the participation + role for the calendar user specified by the property in the group + schedule calendar component. If not specified on a property that + allows this parameter, the default value is REQ-PARTICIPANT. + + Example: + + ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com + +4.2.17 RSVP Expectation + + Parameter Name: RSVP + + Purpose: To specify whether there is an expectation of a favor of a + reply from the calendar user specified by the property value. + + Format Definition: The property parameter is defined by the following + notation: + + rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") + ; Default is FALSE + + + + + +Dawson & Stenerson Standards Track [Page 29] + +RFC 2445 iCalendar November 1998 + + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter identifies the expectation of a + reply from the calendar user specified by the property value. This + parameter is used by the "Organizer" to request a participation + status reply from an "Attendee" of a group scheduled event or to-do. + If not specified on a property that allows this parameter, the + default value is FALSE. + + Example: + + ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com + +4.2.18 Sent By + + Parameter Name: SENT-BY + + Purpose: To specify the calendar user that is acting on behalf of the + calendar user specified by the property. + + Format Definition: The property parameter is defined by the following + notation: + + sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE + + Description: This parameter can be specified on properties with a + CAL-ADDRESS value type. The parameter specifies the calendar user + that is acting on behalf of the calendar user specified by the + property. The parameter value MUST be a MAILTO URI as defined in [RFC + 1738]. The individual calendar address parameter values MUST each be + specified in a quoted-string. + + Example: + + ORGANIZER;SENT-BY:"MAILTO:sray@host.com":MAILTO:jsmith@host.com + +4.2.19 Time Zone Identifier + + Parameter Name: TZID + + Purpose: To specify the identifier for the time zone definition for a + time component in the property value. + + Format Definition: This property parameter is defined by the + following notation: + + tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF + + tzidprefix = "/" + + + +Dawson & Stenerson Standards Track [Page 30] + +RFC 2445 iCalendar November 1998 + + + Description: The parameter MUST be specified on the "DTSTART", + "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- + TIME or TIME value type is specified and when the value is not either + a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type + definition for a description of UTC and "floating time" formats. This + property parameter specifies a text value which uniquely identifies + the "VTIMEZONE" calendar component to be used when evaluating the + time portion of the property. The value of the TZID property + parameter will be equal to the value of the TZID property for the + matching time zone definition. An individual "VTIMEZONE" calendar + component MUST be specified for each unique "TZID" parameter value + specified in the iCalendar object. + + The parameter MUST be specified on properties with a DATE-TIME value + if the DATE-TIME is not either a UTC or a "floating" time. + + The presence of the SOLIDUS character (US-ASCII decimal 47) as a + prefix, indicates that this TZID represents a unique ID in a globally + defined time zone registry (when such registry is defined). + + Note: This document does not define a naming convention for time + zone identifiers. Implementers may want to use the naming + conventions defined in existing time zone specifications such as + the public-domain Olson database [TZ]. The specification of + globally unique time zone identifiers is not addressed by this + document and is left for future study. + + The following are examples of this property parameter: + + DTSTART;TZID=US-Eastern:19980119T020000 + + DTEND;TZID=US-Eastern:19980119T030000 + + The TZID property parameter MUST NOT be applied to DATE-TIME or TIME + properties whose time values are specified in UTC. + + The use of local time in a DATE-TIME or TIME value without the TZID + property parameter is to be interpreted as a local time value, + regardless of the existence of "VTIMEZONE" calendar components in the + iCalendar object. + + For more information see the sections on the data types DATE-TIME and + TIME. + + + + + + + + +Dawson & Stenerson Standards Track [Page 31] + +RFC 2445 iCalendar November 1998 + + +4.2.20 Value Data Types + + Parameter Name: VALUE + + Purpose: To explicitly specify the data type format for a property + value. + + Format Definition: The "VALUE" property parameter is defined by the + following notation: + + valuetypeparam = "VALUE" "=" valuetype + + valuetype = ("BINARY" + / "BOOLEAN" + / "CAL-ADDRESS" + / "DATE" + / "DATE-TIME" + / "DURATION" + / "FLOAT" + / "INTEGER" + / "PERIOD" + / "RECUR" + / "TEXT" + / "TIME" + / "URI" + / "UTC-OFFSET" + / x-name + ; Some experimental iCalendar data type. + / iana-token) + ; Some other IANA registered iCalendar data type. + + Description: The parameter specifies the data type and format of the + property value. The property values MUST be of a single value type. + For example, a "RDATE" property cannot have a combination of DATE- + TIME and TIME value types. + + If the property's value is the default value type, then this + parameter need not be specified. However, if the property's default + value type is overridden by some other allowable value type, then + this parameter MUST be specified. + +4.3 Property Value Data Types + + The properties in an iCalendar object are strongly typed. The + definition of each property restricts the value to be one of the + value data types, or simply value types, defined in this section. The + value type for a property will either be specified implicitly as the + default value type or will be explicitly specified with the "VALUE" + + + +Dawson & Stenerson Standards Track [Page 32] + +RFC 2445 iCalendar November 1998 + + + parameter. If the value type of a property is one of the alternate + valid types, then it MUST be explicitly specified with the "VALUE" + parameter. + +4.3.1 Binary + + Value Name: BINARY + + Purpose: This value type is used to identify properties that contain + a character encoding of inline binary data. For example, an inline + attachment of an object code might be included in an iCalendar + object. + + Formal Definition: The value type is defined by the following + notation: + + binary = *(4b-char) [b-end] + ; A "BASE64" encoded character string, as defined by [RFC 2045]. + + b-end = (2b-char "==") / (3b-char "=") + + b-char = ALPHA / DIGIT / "+" / "/" + + Description: Property values with this value type MUST also include + the inline encoding parameter sequence of ";ENCODING=BASE64". That + is, all inline binary data MUST first be character encoded using the + "BASE64" encoding method defined in [RFC 2045]. No additional content + value encoding (i.e., BACKSLASH character encoding) is defined for + this value type. + + Example: The following is an abridged example of a "BASE64" encoded + binary value data. + + ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY + JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI + ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv + <...remainder of "BASE64" encoded binary data...> + +4.3.2 Boolean + + Value Name: BOOLEAN + + Purpose: This value type is used to identify properties that contain + either a "TRUE" or "FALSE" Boolean value. + + Formal Definition: The value type is defined by the following + notation: + + + + +Dawson & Stenerson Standards Track [Page 33] + +RFC 2445 iCalendar November 1998 + + + boolean = "TRUE" / "FALSE" + + Description: These values are case insensitive text. No additional + content value encoding (i.e., BACKSLASH character encoding) is + defined for this value type. + + Example: The following is an example of a hypothetical property that + has a BOOLEAN value type: + + GIBBERISH:TRUE + +4.3.3 Calendar User Address + + Value Name: CAL-ADDRESS + + Purpose: This value type is used to identify properties that contain + a calendar user address. + + Formal Definition: The value type is as defined by the following + notation: + + cal-address = uri + + Description: The value is a URI as defined by [RFC 1738] or any other + IANA registered form for a URI. When used to address an Internet + email transport address for a calendar user, the value MUST be a + MAILTO URI, as defined by [RFC 1738]. No additional content value + encoding (i.e., BACKSLASH character encoding) is defined for this + value type. + + Example: + + ATTENDEE:MAILTO:jane_doe@host.com + +4.3.4 Date + + Value Name: DATE + + Purpose: This value type is used to identify values that contain a + calendar date. + + Formal Definition: The value type is defined by the following + notation: + + date = date-value + + date-value = date-fullyear date-month date-mday + date-fullyear = 4DIGIT + + + +Dawson & Stenerson Standards Track [Page 34] + +RFC 2445 iCalendar November 1998 + + + date-month = 2DIGIT ;01-12 + date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 + ;based on month/year + + Description: If the property permits, multiple "date" values are + specified as a COMMA character (US-ASCII decimal 44) separated list + of values. The format for the value type is expressed as the [ISO + 8601] complete representation, basic format for a calendar date. The + textual format specifies a four-digit year, two-digit month, and + two-digit day of the month. There are no separator characters between + the year, month and day component text. + + No additional content value encoding (i.e., BACKSLASH character + encoding) is defined for this value type. + + Example: The following represents July 14, 1997: + + 19970714 + +4.3.5 Date-Time + + Value Name: DATE-TIME + + Purpose: This value type is used to identify values that specify a + precise calendar date and time of day. + + Formal Definition: The value type is defined by the following + notation: + + date-time = date "T" time ;As specified in the date and time + ;value definitions + + Description: If the property permits, multiple "date-time" values are + specified as a COMMA character (US-ASCII decimal 44) separated list + of values. No additional content value encoding (i.e., BACKSLASH + character encoding) is defined for this value type. + + The "DATE-TIME" data type is used to identify values that contain a + precise calendar date and time of day. The format is based on the + [ISO 8601] complete representation, basic format for a calendar date + and time of day. The text format is a concatenation of the "date", + followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal + 84) time designator, followed by the "time" format. + + The "DATE-TIME" data type expresses time values in three forms: + + The form of date and time with UTC offset MUST NOT be used. For + example, the following is not valid for a date-time value: + + + +Dawson & Stenerson Standards Track [Page 35] + +RFC 2445 iCalendar November 1998 + + + DTSTART:19980119T230000-0800 ;Invalid time format + + FORM #1: DATE WITH LOCAL TIME + + The date with local time form is simply a date-time value that does + not contain the UTC designator nor does it reference a time zone. For + example, the following represents Janurary 18, 1998, at 11 PM: + + DTSTART:19980118T230000 + + Date-time values of this type are said to be "floating" and are not + bound to any time zone in particular. They are used to represent the + same hour, minute, and second value regardless of which time zone is + currently being observed. For example, an event can be defined that + indicates that an individual will be busy from 11:00 AM to 1:00 PM + every day, no matter which time zone the person is in. In these + cases, a local time can be specified. The recipient of an iCalendar + object with a property value consisting of a local time, without any + relative time zone information, SHOULD interpret the value as being + fixed to whatever time zone the ATTENDEE is in at any given moment. + This means that two ATTENDEEs, in different time zones, receiving the + same event definition as a floating time, may be participating in the + event at different actual times. Floating time SHOULD only be used + where that is the reasonable behavior. + + In most cases, a fixed time is desired. To properly communicate a + fixed time in a property value, either UTC time or local time with + time zone reference MUST be specified. + + The use of local time in a DATE-TIME value without the TZID property + parameter is to be interpreted as floating time, regardless of the + existence of "VTIMEZONE" calendar components in the iCalendar object. + + FORM #2: DATE WITH UTC TIME + + The date with UTC time, or absolute time, is identified by a LATIN + CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC + designator, appended to the time value. For example, the following + represents January 19, 1998, at 0700 UTC: + + DTSTART:19980119T070000Z + + The TZID property parameter MUST NOT be applied to DATE-TIME + properties whose time values are specified in UTC. + + FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE + + + + + +Dawson & Stenerson Standards Track [Page 36] + +RFC 2445 iCalendar November 1998 + + + The date and local time with reference to time zone information is + identified by the use the TZID property parameter to reference the + appropriate time zone definition. TZID is discussed in detail in the + section on Time Zone. For example, the following represents 2 AM in + New York on Janurary 19, 1998: + + DTSTART;TZID=US-Eastern:19980119T020000 + + Example: The following represents July 14, 1997, at 1:30 PM in New + York City in each of the three time formats, using the "DTSTART" + property. + + DTSTART:19970714T133000 ;Local time + DTSTART:19970714T173000Z ;UTC time + DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time + ; zone reference + + A time value MUST ONLY specify 60 seconds when specifying the + periodic "leap second" in the time value. For example: + + COMPLETED:19970630T235960Z + +4.3.6 Duration + + Value Name: DURATION + + Purpose: This value type is used to identify properties that contain + a duration of time. + + Formal Definition: The value type is defined by the following + notation: + + dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) + + dur-date = dur-day [dur-time] + dur-time = "T" (dur-hour / dur-minute / dur-second) + dur-week = 1*DIGIT "W" + dur-hour = 1*DIGIT "H" [dur-minute] + dur-minute = 1*DIGIT "M" [dur-second] + dur-second = 1*DIGIT "S" + dur-day = 1*DIGIT "D" + + Description: If the property permits, multiple "duration" values are + specified by a COMMA character (US-ASCII decimal 44) separated list + of values. The format is expressed as the [ISO 8601] basic format for + the duration of time. The format can represent durations in terms of + weeks, days, hours, minutes, and seconds. + + + + +Dawson & Stenerson Standards Track [Page 37] + +RFC 2445 iCalendar November 1998 + + + No additional content value encoding (i.e., BACKSLASH character + encoding) are defined for this value type. + + Example: A duration of 15 days, 5 hours and 20 seconds would be: + + P15DT5H0M20S + + A duration of 7 weeks would be: + + P7W + +4.3.7 Float + + Value Name: FLOAT + + Purpose: This value type is used to identify properties that contain + a real number value. + + Formal Definition: The value type is defined by the following + notation: + + float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] + + Description: If the property permits, multiple "float" values are + specified by a COMMA character (US-ASCII decimal 44) separated list + of values. + + No additional content value encoding (i.e., BACKSLASH character + encoding) is defined for this value type. + + Example: + + 1000000.0000001 + 1.333 + -3.14 + +4.3.8 Integer + + Value Name:INTEGER + + Purpose: This value type is used to identify properties that contain + a signed integer value. + + Formal Definition: The value type is defined by the following + notation: + + integer = (["+"] / "-") 1*DIGIT + + + + +Dawson & Stenerson Standards Track [Page 38] + +RFC 2445 iCalendar November 1998 + + + Description: If the property permits, multiple "integer" values are + specified by a COMMA character (US-ASCII decimal 44) separated list + of values. The valid range for "integer" is -2147483648 to + 2147483647. If the sign is not specified, then the value is assumed + to be positive. + + No additional content value encoding (i.e., BACKSLASH character + encoding) is defined for this value type. + + Example: + + 1234567890 + -1234567890 + +1234567890 + 432109876 + +4.3.9 Period of Time + + Value Name: PERIOD + + Purpose: This value type is used to identify values that contain a + precise period of time. + + Formal Definition: The data type is defined by the following + notation: + + period = period-explicit / period-start + + period-explicit = date-time "/" date-time + ; [ISO 8601] complete representation basic format for a period of + ; time consisting of a start and end. The start MUST be before the + ; end. + + period-start = date-time "/" dur-value + ; [ISO 8601] complete representation basic format for a period of + ; time consisting of a start and positive duration of time. + + Description: If the property permits, multiple "period" values are + specified by a COMMA character (US-ASCII decimal 44) separated list + of values. There are two forms of a period of time. First, a period + of time is identified by its start and its end. This format is + expressed as the [ISO 8601] complete representation, basic format for + "DATE-TIME" start of the period, followed by a SOLIDUS character + (US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the + period. The start of the period MUST be before the end of the period. + Second, a period of time can also be defined by a start and a + positive duration of time. The format is expressed as the [ISO 8601] + complete representation, basic format for the "DATE-TIME" start of + + + +Dawson & Stenerson Standards Track [Page 39] + +RFC 2445 iCalendar November 1998 + + + the period, followed by a SOLIDUS character (US-ASCII decimal 47), + followed by the [ISO 8601] basic format for "DURATION" of the period. + + Example: The period starting at 18:00:00 UTC, on January 1, 1997 and + ending at 07:00:00 UTC on January 2, 1997 would be: + + 19970101T180000Z/19970102T070000Z + + The period start at 18:00:00 on January 1, 1997 and lasting 5 hours + and 30 minutes would be: + + 19970101T180000Z/PT5H30M + + No additional content value encoding (i.e., BACKSLASH character + encoding) is defined for this value type. + +4.3.10 Recurrence Rule + + Value Name: RECUR + + Purpose: This value type is used to identify properties that contain + a recurrence rule specification. + + Formal Definition: The value type is defined by the following + notation: + + recur = "FREQ"=freq *( + + ; either UNTIL or COUNT may appear in a 'recur', + ; but UNTIL and COUNT MUST NOT occur in the same 'recur' + + ( ";" "UNTIL" "=" enddate ) / + ( ";" "COUNT" "=" 1*DIGIT ) / + + ; the rest of these keywords are optional, + ; but MUST NOT occur more than once + + ( ";" "INTERVAL" "=" 1*DIGIT ) / + ( ";" "BYSECOND" "=" byseclist ) / + ( ";" "BYMINUTE" "=" byminlist ) / + ( ";" "BYHOUR" "=" byhrlist ) / + ( ";" "BYDAY" "=" bywdaylist ) / + ( ";" "BYMONTHDAY" "=" bymodaylist ) / + ( ";" "BYYEARDAY" "=" byyrdaylist ) / + ( ";" "BYWEEKNO" "=" bywknolist ) / + ( ";" "BYMONTH" "=" bymolist ) / + ( ";" "BYSETPOS" "=" bysplist ) / + ( ";" "WKST" "=" weekday ) / + + + +Dawson & Stenerson Standards Track [Page 40] + +RFC 2445 iCalendar November 1998 + + + ( ";" x-name "=" text ) + ) + + freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" + / "WEEKLY" / "MONTHLY" / "YEARLY" + + enddate = date + enddate =/ date-time ;An UTC value + + byseclist = seconds / ( seconds *("," seconds) ) + + seconds = 1DIGIT / 2DIGIT ;0 to 59 + + byminlist = minutes / ( minutes *("," minutes) ) + + minutes = 1DIGIT / 2DIGIT ;0 to 59 + + byhrlist = hour / ( hour *("," hour) ) + + hour = 1DIGIT / 2DIGIT ;0 to 23 + + bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) ) + + weekdaynum = [([plus] ordwk / minus ordwk)] weekday + + plus = "+" + + minus = "-" + + ordwk = 1DIGIT / 2DIGIT ;1 to 53 + + weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" + ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, + ;FRIDAY, SATURDAY and SUNDAY days of the week. + + bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) ) + + monthdaynum = ([plus] ordmoday) / (minus ordmoday) + + ordmoday = 1DIGIT / 2DIGIT ;1 to 31 + + byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) ) + + yeardaynum = ([plus] ordyrday) / (minus ordyrday) + + ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366 + + bywknolist = weeknum / ( weeknum *("," weeknum) ) + + + +Dawson & Stenerson Standards Track [Page 41] + +RFC 2445 iCalendar November 1998 + + + weeknum = ([plus] ordwk) / (minus ordwk) + + bymolist = monthnum / ( monthnum *("," monthnum) ) + + monthnum = 1DIGIT / 2DIGIT ;1 to 12 + + bysplist = setposday / ( setposday *("," setposday) ) + + setposday = yeardaynum + + Description: If the property permits, multiple "recur" values are + specified by a COMMA character (US-ASCII decimal 44) separated list + of values. The value type is a structured value consisting of a list + of one or more recurrence grammar parts. Each rule part is defined by + a NAME=VALUE pair. The rule parts are separated from each other by + the SEMICOLON character (US-ASCII decimal 59). The rule parts are not + ordered in any particular sequence. Individual rule parts MUST only + be specified once. + + The FREQ rule part identifies the type of recurrence rule. This rule + part MUST be specified in the recurrence rule. Valid values include + SECONDLY, to specify repeating events based on an interval of a + second or more; MINUTELY, to specify repeating events based on an + interval of a minute or more; HOURLY, to specify repeating events + based on an interval of an hour or more; DAILY, to specify repeating + events based on an interval of a day or more; WEEKLY, to specify + repeating events based on an interval of a week or more; MONTHLY, to + specify repeating events based on an interval of a month or more; and + YEARLY, to specify repeating events based on an interval of a year or + more. + + The INTERVAL rule part contains a positive integer representing how + often the recurrence rule repeats. The default value is "1", meaning + every second for a SECONDLY rule, or every minute for a MINUTELY + rule, every hour for an HOURLY rule, every day for a DAILY rule, + every week for a WEEKLY rule, every month for a MONTHLY rule and + every year for a YEARLY rule. + + The UNTIL rule part defines a date-time value which bounds the + recurrence rule in an inclusive manner. If the value specified by + UNTIL is synchronized with the specified recurrence, this date or + date-time becomes the last instance of the recurrence. If specified + as a date-time value, then it MUST be specified in an UTC time + format. If not present, and the COUNT rule part is also not present, + the RRULE is considered to repeat forever. + + The COUNT rule part defines the number of occurrences at which to + range-bound the recurrence. The "DTSTART" property value, if + + + +Dawson & Stenerson Standards Track [Page 42] + +RFC 2445 iCalendar November 1998 + + + specified, counts as the first occurrence. + + The BYSECOND rule part specifies a COMMA character (US-ASCII decimal + 44) separated list of seconds within a minute. Valid values are 0 to + 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII + decimal 44) separated list of minutes within an hour. Valid values + are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- + ASCII decimal 44) separated list of hours of the day. Valid values + are 0 to 23. + + The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44) + separated list of days of the week; MO indicates Monday; TU indicates + Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates + Friday; SA indicates Saturday; SU indicates Sunday. + + Each BYDAY value can also be preceded by a positive (+n) or negative + (-n) integer. If present, this indicates the nth occurrence of the + specific day within the MONTHLY or YEARLY RRULE. For example, within + a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday + within the month, whereas -1MO represents the last Monday of the + month. If an integer modifier is not present, it means all days of + this type within the specified frequency. For example, within a + MONTHLY rule, MO represents all Mondays within the month. + + The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal + 44) separated list of days of the month. Valid values are 1 to 31 or + -31 to -1. For example, -10 represents the tenth to the last day of + the month. + + The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal + 44) separated list of days of the year. Valid values are 1 to 366 or + -366 to -1. For example, -1 represents the last day of the year + (December 31st) and -306 represents the 306th to the last day of the + year (March 1st). + + The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal + 44) separated list of ordinals specifying weeks of the year. Valid + values are 1 to 53 or -53 to -1. This corresponds to weeks according + to week numbering as defined in [ISO 8601]. A week is defined as a + seven day period, starting on the day of the week defined to be the + week start (see WKST). Week number one of the calendar year is the + first week which contains at least four (4) days in that calendar + year. This rule part is only valid for YEARLY rules. For example, 3 + represents the third week of the year. + + Note: Assuming a Monday week start, week 53 can only occur when + Thursday is January 1 or if it is a leap year and Wednesday is + January 1. + + + +Dawson & Stenerson Standards Track [Page 43] + +RFC 2445 iCalendar November 1998 + + + The BYMONTH rule part specifies a COMMA character (US-ASCII decimal + 44) separated list of months of the year. Valid values are 1 to 12. + + The WKST rule part specifies the day on which the workweek starts. + Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant + when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule + part is specified. This is also significant when in a YEARLY RRULE + when a BYWEEKNO rule part is specified. The default value is MO. + + The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal + 44) separated list of values which corresponds to the nth occurrence + within the set of events specified by the rule. Valid values are 1 to + 366 or -366 to -1. It MUST only be used in conjunction with another + BYxxx rule part. For example "the last work day of the month" could + be represented as: + + RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 + + Each BYSETPOS value can include a positive (+n) or negative (-n) + integer. If present, this indicates the nth occurrence of the + specific occurrence within the set of events specified by the rule. + + If BYxxx rule part values are found which are beyond the available + scope (ie, BYMONTHDAY=30 in February), they are simply ignored. + + Information, not contained in the rule, necessary to determine the + various recurrence instance start time and dates are derived from the + Start Time (DTSTART) entry attribute. For example, + "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the + month or a time. This information would be the same as what is + specified for DTSTART. + + BYxxx rule parts modify the recurrence in some manner. BYxxx rule + parts for a period of time which is the same or greater than the + frequency generally reduce or limit the number of occurrences of the + recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the + number of recurrence instances from all days (if BYMONTH tag is not + present) to all days in January. BYxxx rule parts for a period of + time less than the frequency generally increase or expand the number + of occurrences of the recurrence. For example, + "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the + yearly recurrence set from 1 (if BYMONTH tag is not present) to 2. + + If multiple BYxxx rule parts are specified, then after evaluating the + specified FREQ and INTERVAL rule parts, the BYxxx rule parts are + applied to the current set of evaluated occurrences in the following + order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, + BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated. + + + +Dawson & Stenerson Standards Track [Page 44] + +RFC 2445 iCalendar November 1998 + + + Here is an example of evaluating multiple BYxxx rule parts. + + DTSTART;TZID=US-Eastern:19970105T083000 + RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; + BYMINUTE=30 + + First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive + at "every other year". Then, "BYMONTH=1" would be applied to arrive + at "every January, every other year". Then, "BYDAY=SU" would be + applied to arrive at "every Sunday in January, every other year". + Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in + January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30" + would be applied to arrive at "every Sunday in January at 8:30 AM and + 9:30 AM, every other year". Then, lacking information from RRULE, the + second is derived from DTSTART, to end up in "every Sunday in January + at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the + BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were + missing, the appropriate minute, hour, day or month would have been + retrieved from the "DTSTART" property. + + No additional content value encoding (i.e., BACKSLASH character + encoding) is defined for this value type. + + Example: The following is a rule which specifies 10 meetings which + occur every other day: + + FREQ=DAILY;COUNT=10;INTERVAL=2 + + There are other examples specified in the "RRULE" specification. + +4.3.11 Text + + Value Name: TEXT + + Purpose This value type is used to identify values that contain human + readable text. + + Formal Definition: The character sets supported by this revision of + iCalendar are UTF-8 and US ASCII thereof. The applicability to other + character sets is for future work. The value type is defined by the + following notation. + + text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) + ; Folded according to description above + + ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n") + ; \\ encodes \, \N or \n encodes newline + ; \; encodes ;, \, encodes , + + + +Dawson & Stenerson Standards Track [Page 45] + +RFC 2445 iCalendar November 1998 + + + TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B + %x5D-7E / NON-US-ASCII + ; Any character except CTLs not needed by the current + ; character set, DQUOTE, ";", ":", "\", "," + + Note: Certain other character sets may require modification of the + above definitions, but this is beyond the scope of this document. + + Description: If the property permits, multiple "text" values are + specified by a COMMA character (US-ASCII decimal 44) separated list + of values. + + The language in which the text is represented can be controlled by + the "LANGUAGE" property parameter. + + An intentional formatted text line break MUST only be included in a + "TEXT" property value by representing the line break with the + character sequence of BACKSLASH (US-ASCII decimal 92), followed by a + LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER + N (US-ASCII decimal 78), that is "\n" or "\N". + + The "TEXT" property values may also contain special characters that + are used to signify delimiters, such as a COMMA character for lists + of values or a SEMICOLON character for structured values. In order to + support the inclusion of these special characters in "TEXT" property + values, they MUST be escaped with a BACKSLASH character. A BACKSLASH + character (US-ASCII decimal 92) in a "TEXT" property value MUST be + escaped with another BACKSLASH character. A COMMA character in a + "TEXT" property value MUST be escaped with a BACKSLASH character + (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property + value MUST be escaped with a BACKSLASH character (US-ASCII decimal + 92). However, a COLON character in a "TEXT" property value SHALL NOT + be escaped with a BACKSLASH character.Example: A multiple line value + of: + + Project XYZ Final Review + Conference Room - 3B + Come Prepared. + + would be represented as: + + Project XYZ Final Review\nConference Room - 3B\nCome Prepared. + + + + + + + + + +Dawson & Stenerson Standards Track [Page 46] + +RFC 2445 iCalendar November 1998 + + +4.3.12 Time + + Value Name: TIME + + Purpose: This value type is used to identify values that contain a + time of day. + + Formal Definition: The data type is defined by the following + notation: + + time = time-hour time-minute time-second [time-utc] + + time-hour = 2DIGIT ;00-23 + time-minute = 2DIGIT ;00-59 + time-second = 2DIGIT ;00-60 + ;The "60" value is used to account for "leap" seconds. + + time-utc = "Z" + + Description: If the property permits, multiple "time" values are + specified by a COMMA character (US-ASCII decimal 44) separated list + of values. No additional content value encoding (i.e., BACKSLASH + character encoding) is defined for this value type. + + The "TIME" data type is used to identify values that contain a time + of day. The format is based on the [ISO 8601] complete + representation, basic format for a time of day. The text format + consists of a two-digit 24-hour of the day (i.e., values 0-23), two- + digit minute in the hour (i.e., values 0-59), and two-digit seconds + in the minute (i.e., values 0-60). The seconds value of 60 MUST only + to be used to account for "leap" seconds. Fractions of a second are + not supported by this format. + + In parallel to the "DATE-TIME" definition above, the "TIME" data type + expresses time values in three forms: + + The form of time with UTC offset MUST NOT be used. For example, the + following is NOT VALID for a time value: + + 230000-0800 ;Invalid time format + + FORM #1 LOCAL TIME + + The local time form is simply a time value that does not contain the + UTC designator nor does it reference a time zone. For example, 11:00 + PM: + + 230000 + + + +Dawson & Stenerson Standards Track [Page 47] + +RFC 2445 iCalendar November 1998 + + + Time values of this type are said to be "floating" and are not bound + to any time zone in particular. They are used to represent the same + hour, minute, and second value regardless of which time zone is + currently being observed. For example, an event can be defined that + indicates that an individual will be busy from 11:00 AM to 1:00 PM + every day, no matter which time zone the person is in. In these + cases, a local time can be specified. The recipient of an iCalendar + object with a property value consisting of a local time, without any + relative time zone information, SHOULD interpret the value as being + fixed to whatever time zone the ATTENDEE is in at any given moment. + This means that two ATTENDEEs may participate in the same event at + different UTC times; floating time SHOULD only be used where that is + reasonable behavior. + + In most cases, a fixed time is desired. To properly communicate a + fixed time in a property value, either UTC time or local time with + time zone reference MUST be specified. + + The use of local time in a TIME value without the TZID property + parameter is to be interpreted as a local time value, regardless of + the existence of "VTIMEZONE" calendar components in the iCalendar + object. + + FORM #2: UTC TIME + + UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z + suffix character (US-ASCII decimal 90), the UTC designator, appended + to the time value. For example, the following represents 07:00 AM + UTC: + + 070000Z + + The TZID property parameter MUST NOT be applied to TIME properties + whose time values are specified in UTC. + + FORM #3: LOCAL TIME AND TIME ZONE REFERENCE + + The local time with reference to time zone information form is + identified by the use the TZID property parameter to reference the + appropriate time zone definition. TZID is discussed in detail in the + section on Time Zone. + + Example: The following represents 8:30 AM in New York in Winter, five + hours behind UTC, in each of the three formats using the "X- + TIMEOFDAY" non-standard property: + + + + + + +Dawson & Stenerson Standards Track [Page 48] + +RFC 2445 iCalendar November 1998 + + + X-TIMEOFDAY:083000 + + X-TIMEOFDAY:133000Z + + X-TIMEOFDAY;TZID=US-Eastern:083000 + +4.3.13 URI + + Value Name: URI + + Purpose: This value type is used to identify values that contain a + uniform resource identifier (URI) type of reference to the property + value. + + Formal Definition: The data type is defined by the following + notation: + + uri = + + Description: This data type might be used to reference binary + information, for values that are large, or otherwise undesirable to + include directly in the iCalendar object. + + The URI value formats in RFC 1738, RFC 2111 and any other IETF + registered value format can be specified. + + Any IANA registered URI format can be used. These include, but are + not limited to, those defined in RFC 1738 and RFC 2111. + + When a property parameter value is a URI value type, the URI MUST be + specified as a quoted-string value. + + No additional content value encoding (i.e., BACKSLASH character + encoding) is defined for this value type. + + Example: The following is a URI for a network file: + + http://host1.com/my-report.txt + +4.3.14 UTC Offset + + Value Name: UTC-OFFSET + + Purpose: This value type is used to identify properties that contain + an offset from UTC to local time. + + Formal Definition: The data type is defined by the following + notation: + + + +Dawson & Stenerson Standards Track [Page 49] + +RFC 2445 iCalendar November 1998 + + + utc-offset = time-numzone ;As defined above in time data type + + time-numzone = ("+" / "-") time-hour time-minute [time- + second] + + Description: The PLUS SIGN character MUST be specified for positive + UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000" + are not allowed. The time-second, if present, may not be 60; if + absent, it defaults to zero. + + No additional content value encoding (i.e., BACKSLASH character + encoding) is defined for this value type. + + Example: The following UTC offsets are given for standard time for + New York (five hours behind UTC) and Geneva (one hour ahead of UTC): + + -0500 + + +0100 + +4.4 iCalendar Object + + The Calendaring and Scheduling Core Object is a collection of + calendaring and scheduling information. Typically, this information + will consist of a single iCalendar object. However, multiple + iCalendar objects can be sequentially grouped together. The first + line and last line of the iCalendar object MUST contain a pair of + iCalendar object delimiter strings. The syntax for an iCalendar + object is as follows: + + icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF + icalbody + "END" ":" "VCALENDAR" CRLF) + + The following is a simple example of an iCalendar object: + + BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//hacksw/handcal//NONSGML v1.0//EN + BEGIN:VEVENT + DTSTART:19970714T170000Z + DTEND:19970715T035959Z + SUMMARY:Bastille Day Party + END:VEVENT + END:VCALENDAR + + + + + + +Dawson & Stenerson Standards Track [Page 50] + +RFC 2445 iCalendar November 1998 + + +4.5 Property + + A property is the definition of an individual attribute describing a + calendar or a calendar component. A property takes the form defined + by the "contentline" notation defined in section 4.1.1. + + The following is an example of a property: + + DTSTART:19960415T133000Z + + This memo imposes no ordering of properties within an iCalendar + object. + + Property names, parameter names and enumerated parameter values are + case insensitive. For example, the property name "DUE" is the same as + "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same + as DtStart;TzID=US-Eastern:19980714T120000. + +4.6 Calendar Components + + The body of the iCalendar object consists of a sequence of calendar + properties and one or more calendar components. The calendar + properties are attributes that apply to the calendar as a whole. The + calendar components are collections of properties that express a + particular calendar semantic. For example, the calendar component can + specify an event, a to-do, a journal entry, time zone information, or + free/busy time information, or an alarm. + + The body of the iCalendar object is defined by the following + notation: + + icalbody = calprops component + + calprops = 2*( + + ; 'prodid' and 'version' are both REQUIRED, + ; but MUST NOT occur more than once + + prodid /version / + + ; 'calscale' and 'method' are optional, + ; but MUST NOT occur more than once + + calscale / + method / + + x-prop + + + + +Dawson & Stenerson Standards Track [Page 51] + +RFC 2445 iCalendar November 1998 + + + ) + + component = 1*(eventc / todoc / journalc / freebusyc / + / timezonec / iana-comp / x-comp) + + iana-comp = "BEGIN" ":" iana-token CRLF + + 1*contentline + + "END" ":" iana-token CRLF + + x-comp = "BEGIN" ":" x-name CRLF + + 1*contentline + + "END" ":" x-name CRLF + + An iCalendar object MUST include the "PRODID" and "VERSION" calendar + properties. In addition, it MUST include at least one calendar + component. Special forms of iCalendar objects are possible to publish + just busy time (i.e., only a "VFREEBUSY" calendar component) or time + zone (i.e., only a "VTIMEZONE" calendar component) information. In + addition, a complex iCalendar object is possible that is used to + capture a complete snapshot of the contents of a calendar (e.g., + composite of many different calendar components). More commonly, an + iCalendar object will consist of just a single "VEVENT", "VTODO" or + "VJOURNAL" calendar component. + +4.6.1 Event Component + + Component Name: "VEVENT" + + Purpose: Provide a grouping of component properties that describe an + event. + + Format Definition: A "VEVENT" calendar component is defined by the + following notation: + + eventc = "BEGIN" ":" "VEVENT" CRLF + eventprop *alarmc + "END" ":" "VEVENT" CRLF + + eventprop = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + class / created / description / dtstart / geo / + + + +Dawson & Stenerson Standards Track [Page 52] + +RFC 2445 iCalendar November 1998 + + + last-mod / location / organizer / priority / + dtstamp / seq / status / summary / transp / + uid / url / recurid / + + ; either 'dtend' or 'duration' may appear in + ; a 'eventprop', but 'dtend' and 'duration' + ; MUST NOT occur in the same 'eventprop' + + dtend / duration / + + ; the following are optional, + ; and MAY occur more than once + + attach / attendee / categories / comment / + contact / exdate / exrule / rstatus / related / + resources / rdate / rrule / x-prop + + ) + + Description: A "VEVENT" calendar component is a grouping of component + properties, and possibly including "VALARM" calendar components, that + represents a scheduled amount of time on a calendar. For example, it + can be an activity; such as a one-hour long, department meeting from + 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time + on an individual calendar. Hence, the event will appear as an opaque + interval in a search for busy time. Alternately, the event can have + its Time Transparency set to "TRANSPARENT" in order to prevent + blocking of the event in searches for busy time. + + The "VEVENT" is also the calendar component used to specify an + anniversary or daily reminder within a calendar. These events have a + DATE value type for the "DTSTART" property instead of the default + data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it + MUST be specified as a DATE value also. The anniversary type of + "VEVENT" can span more than one date (i.e, "DTEND" property value is + set to a calendar date after the "DTSTART" property value). + + The "DTSTART" property for a "VEVENT" specifies the inclusive start + of the event. For recurring events, it also specifies the very first + instance in the recurrence set. The "DTEND" property for a "VEVENT" + calendar component specifies the non-inclusive end of the event. For + cases where a "VEVENT" calendar component specifies a "DTSTART" + property with a DATE data type but no "DTEND" property, the events + non-inclusive end is the end of the calendar date specified by the + "DTSTART" property. For cases where a "VEVENT" calendar component + specifies a "DTSTART" property with a DATE-TIME data type but no + "DTEND" property, the event ends on the same calendar date and time + of day specified by the "DTSTART" property. + + + +Dawson & Stenerson Standards Track [Page 53] + +RFC 2445 iCalendar November 1998 + + + The "VEVENT" calendar component cannot be nested within another + calendar component. However, "VEVENT" calendar components can be + related to each other or to a "VTODO" or to a "VJOURNAL" calendar + component with the "RELATED-TO" property. + + Example: The following is an example of the "VEVENT" calendar + component used to represent a meeting that will also be opaque to + searches for busy time: + + BEGIN:VEVENT + UID:19970901T130000Z-123401@host.com + DTSTAMP:19970901T1300Z + DTSTART:19970903T163000Z + DTEND:19970903T190000Z + SUMMARY:Annual Employee Review + CLASS:PRIVATE + CATEGORIES:BUSINESS,HUMAN RESOURCES + END:VEVENT + + The following is an example of the "VEVENT" calendar component used + to represent a reminder that will not be opaque, but rather + transparent, to searches for busy time: + + BEGIN:VEVENT + UID:19970901T130000Z-123402@host.com + DTSTAMP:19970901T1300Z + DTSTART:19970401T163000Z + DTEND:19970402T010000Z + SUMMARY:Laurel is in sensitivity awareness class. + CLASS:PUBLIC + CATEGORIES:BUSINESS,HUMAN RESOURCES + TRANSP:TRANSPARENT + END:VEVENT + + The following is an example of the "VEVENT" calendar component used + to represent an anniversary that will occur annually. Since it takes + up no time, it will not appear as opaque in a search for busy time; + no matter what the value of the "TRANSP" property indicates: + + BEGIN:VEVENT + UID:19970901T130000Z-123403@host.com + DTSTAMP:19970901T1300Z + DTSTART:19971102 + SUMMARY:Our Blissful Anniversary + CLASS:CONFIDENTIAL + CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION + RRULE:FREQ=YEARLY + END:VEVENT + + + +Dawson & Stenerson Standards Track [Page 54] + +RFC 2445 iCalendar November 1998 + + +4.6.2 To-do Component + + Component Name: VTODO + + Purpose: Provide a grouping of calendar properties that describe a + to-do. + + Formal Definition: A "VTODO" calendar component is defined by the + following notation: + + todoc = "BEGIN" ":" "VTODO" CRLF + todoprop *alarmc + "END" ":" "VTODO" CRLF + + todoprop = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + class / completed / created / description / dtstamp / + dtstart / geo / last-mod / location / organizer / + percent / priority / recurid / seq / status / + summary / uid / url / + + ; either 'due' or 'duration' may appear in + ; a 'todoprop', but 'due' and 'duration' + ; MUST NOT occur in the same 'todoprop' + + due / duration / + + ; the following are optional, + ; and MAY occur more than once + attach / attendee / categories / comment / contact / + exdate / exrule / rstatus / related / resources / + rdate / rrule / x-prop + + ) + + Description: A "VTODO" calendar component is a grouping of component + properties and possibly "VALARM" calendar components that represent + an action-item or assignment. For example, it can be used to + represent an item of work assigned to an individual; such as "turn in + travel expense today". + + The "VTODO" calendar component cannot be nested within another + calendar component. However, "VTODO" calendar components can be + related to each other or to a "VTODO" or to a "VJOURNAL" calendar + component with the "RELATED-TO" property. + + + +Dawson & Stenerson Standards Track [Page 55] + +RFC 2445 iCalendar November 1998 + + + A "VTODO" calendar component without the "DTSTART" and "DUE" (or + "DURATION") properties specifies a to-do that will be associated with + each successive calendar date, until it is completed. + + Example: The following is an example of a "VTODO" calendar component: + + BEGIN:VTODO + UID:19970901T130000Z-123404@host.com + DTSTAMP:19970901T1300Z + DTSTART:19970415T133000Z + DUE:19970416T045959Z + SUMMARY:1996 Income Tax Preparation + CLASS:CONFIDENTIAL + CATEGORIES:FAMILY,FINANCE + PRIORITY:1 + STATUS:NEEDS-ACTION + END:VTODO + +4.6.3 Journal Component + + Component Name: VJOURNAL + + Purpose: Provide a grouping of component properties that describe a + journal entry. + + Formal Definition: A "VJOURNAL" calendar component is defined by the + following notation: + + journalc = "BEGIN" ":" "VJOURNAL" CRLF + jourprop + "END" ":" "VJOURNAL" CRLF + + jourprop = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + class / created / description / dtstart / dtstamp / + last-mod / organizer / recurid / seq / status / + summary / uid / url / + + ; the following are optional, + ; and MAY occur more than once + + attach / attendee / categories / comment / + contact / exdate / exrule / related / rdate / + rrule / rstatus / x-prop + + + + +Dawson & Stenerson Standards Track [Page 56] + +RFC 2445 iCalendar November 1998 + + + ) + + Description: A "VJOURNAL" calendar component is a grouping of + component properties that represent one or more descriptive text + notes associated with a particular calendar date. The "DTSTART" + property is used to specify the calendar date that the journal entry + is associated with. Generally, it will have a DATE value data type, + but it can also be used to specify a DATE-TIME value data type. + Examples of a journal entry include a daily record of a legislative + body or a journal entry of individual telephone contacts for the day + or an ordered list of accomplishments for the day. The "VJOURNAL" + calendar component can also be used to associate a document with a + calendar date. + + The "VJOURNAL" calendar component does not take up time on a + calendar. Hence, it does not play a role in free or busy time + searches - - it is as though it has a time transparency value of + TRANSPARENT. It is transparent to any such searches. + + The "VJOURNAL" calendar component cannot be nested within another + calendar component. However, "VJOURNAL" calendar components can be + related to each other or to a "VEVENT" or to a "VTODO" calendar + component, with the "RELATED-TO" property. + + Example: The following is an example of the "VJOURNAL" calendar + component: + + BEGIN:VJOURNAL + UID:19970901T130000Z-123405@host.com + DTSTAMP:19970901T1300Z + DTSTART;VALUE=DATE:19970317 + SUMMARY:Staff meeting minutes + DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa + and Bob. Aurora project plans were reviewed. There is currently + no budget reserves for this project. Lisa will escalate to + management. Next meeting on Tuesday.\n + 2. Telephone Conference: ABC Corp. sales representative called + to discuss new printer. Promised to get us a demo by Friday.\n + 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. + Is looking into a loaner car. 654-2323 (tel). + END:VJOURNAL + + + + + + + + + + +Dawson & Stenerson Standards Track [Page 57] + +RFC 2445 iCalendar November 1998 + + +4.6.4 Free/Busy Component + + Component Name: VFREEBUSY + + Purpose: Provide a grouping of component properties that describe + either a request for free/busy time, describe a response to a request + for free/busy time or describe a published set of busy time. + + Formal Definition: A "VFREEBUSY" calendar component is defined by the + following notation: + + freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF + fbprop + "END" ":" "VFREEBUSY" CRLF + + fbprop = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + contact / dtstart / dtend / duration / dtstamp / + organizer / uid / url / + + ; the following are optional, + ; and MAY occur more than once + + attendee / comment / freebusy / rstatus / x-prop + + ) + + Description: A "VFREEBUSY" calendar component is a grouping of + component properties that represents either a request for, a reply to + a request for free or busy time information or a published set of + busy time information. + + When used to request free/busy time information, the "ATTENDEE" + property specifies the calendar users whose free/busy time is being + requested; the "ORGANIZER" property specifies the calendar user who + is requesting the free/busy time; the "DTSTART" and "DTEND" + properties specify the window of time for which the free/busy time is + being requested; the "UID" and "DTSTAMP" properties are specified to + assist in proper sequencing of multiple free/busy time requests. + + When used to reply to a request for free/busy time, the "ATTENDEE" + property specifies the calendar user responding to the free/busy time + request; the "ORGANIZER" property specifies the calendar user that + originally requested the free/busy time; the "FREEBUSY" property + specifies the free/busy time information (if it exists); and the + + + +Dawson & Stenerson Standards Track [Page 58] + +RFC 2445 iCalendar November 1998 + + + "UID" and "DTSTAMP" properties are specified to assist in proper + sequencing of multiple free/busy time replies. + + When used to publish busy time, the "ORGANIZER" property specifies + the calendar user associated with the published busy time; the + "DTSTART" and "DTEND" properties specify an inclusive time window + that surrounds the busy time information; the "FREEBUSY" property + specifies the published busy time information; and the "DTSTAMP" + property specifies the date/time that iCalendar object was created. + + The "VFREEBUSY" calendar component cannot be nested within another + calendar component. Multiple "VFREEBUSY" calendar components can be + specified within an iCalendar object. This permits the grouping of + Free/Busy information into logical collections, such as monthly + groups of busy time information. + + The "VFREEBUSY" calendar component is intended for use in iCalendar + object methods involving requests for free time, requests for busy + time, requests for both free and busy, and the associated replies. + + Free/Busy information is represented with the "FREEBUSY" property. + This property provides a terse representation of time periods. One or + more "FREEBUSY" properties can be specified in the "VFREEBUSY" + calendar component. + + When present in a "VFREEBUSY" calendar component, the "DTSTART" and + "DTEND" properties SHOULD be specified prior to any "FREEBUSY" + properties. In a free time request, these properties can be used in + combination with the "DURATION" property to represent a request for a + duration of free time within a specified window of time. + + The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are + not permitted within a "VFREEBUSY" calendar component. Any recurring + events are resolved into their individual busy time periods using the + "FREEBUSY" property. + + Example: The following is an example of a "VFREEBUSY" calendar + component used to request free or busy time information: + + BEGIN:VFREEBUSY + ORGANIZER:MAILTO:jane_doe@host1.com + ATTENDEE:MAILTO:john_public@host2.com + DTSTART:19971015T050000Z + DTEND:19971016T050000Z + DTSTAMP:19970901T083000Z + END:VFREEBUSY + + + + + +Dawson & Stenerson Standards Track [Page 59] + +RFC 2445 iCalendar November 1998 + + + The following is an example of a "VFREEBUSY" calendar component used + to reply to the request with busy time information: + + BEGIN:VFREEBUSY + ORGANIZER:MAILTO:jane_doe@host1.com + ATTENDEE:MAILTO:john_public@host2.com + DTSTAMP:19970901T100000Z + FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, + 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M + URL:http://host2.com/pub/busy/jpublic-01.ifb + COMMENT:This iCalendar file contains busy time information for + the next three months. + END:VFREEBUSY + + The following is an example of a "VFREEBUSY" calendar component used + to publish busy time information. + + BEGIN:VFREEBUSY + ORGANIZER:jsmith@host.com + DTSTART:19980313T141711Z + DTEND:19980410T141711Z + FREEBUSY:19980314T233000Z/19980315T003000Z + FREEBUSY:19980316T153000Z/19980316T163000Z + FREEBUSY:19980318T030000Z/19980318T040000Z + URL:http://www.host.com/calendar/busytime/jsmith.ifb + END:VFREEBUSY + +4.6.5 Time Zone Component + + Component Name: VTIMEZONE + + Purpose: Provide a grouping of component properties that defines a + time zone. + + Formal Definition: A "VTIMEZONE" calendar component is defined by the + following notation: + + timezonec = "BEGIN" ":" "VTIMEZONE" CRLF + + 2*( + + ; 'tzid' is required, but MUST NOT occur more + ; than once + + tzid / + + ; 'last-mod' and 'tzurl' are optional, + but MUST NOT occur more than once + + + +Dawson & Stenerson Standards Track [Page 60] + +RFC 2445 iCalendar November 1998 + + + last-mod / tzurl / + + ; one of 'standardc' or 'daylightc' MUST occur + ..; and each MAY occur more than once. + + standardc / daylightc / + + ; the following is optional, + ; and MAY occur more than once + + x-prop + + ) + + "END" ":" "VTIMEZONE" CRLF + + standardc = "BEGIN" ":" "STANDARD" CRLF + + tzprop + + "END" ":" "STANDARD" CRLF + + daylightc = "BEGIN" ":" "DAYLIGHT" CRLF + + tzprop + + "END" ":" "DAYLIGHT" CRLF + + tzprop = 3*( + + ; the following are each REQUIRED, + ; but MUST NOT occur more than once + + dtstart / tzoffsetto / tzoffsetfrom / + + ; the following are optional, + ; and MAY occur more than once + + comment / rdate / rrule / tzname / x-prop + + ) + + Description: A time zone is unambiguously defined by the set of time + measurement rules determined by the governing body for a given + geographic area. These rules describe at a minimum the base offset + from UTC for the time zone, often referred to as the Standard Time + offset. Many locations adjust their Standard Time forward or backward + by one hour, in order to accommodate seasonal changes in number of + + + +Dawson & Stenerson Standards Track [Page 61] + +RFC 2445 iCalendar November 1998 + + + daylight hours, often referred to as Daylight Saving Time. Some + locations adjust their time by a fraction of an hour. Standard Time + is also known as Winter Time. Daylight Saving Time is also known as + Advanced Time, Summer Time, or Legal Time in certain countries. The + following table shows the changes in time zone rules in effect for + New York City starting from 1967. Each line represents a description + or rule for a particular observance. + + Effective Observance Rule + + Date (Date/Time) Offset Abbreviation + + 1967-* last Sun in Oct, 02:00 -0500 EST + + 1967-1973 last Sun in Apr, 02:00 -0400 EDT + + 1974-1974 Jan 6, 02:00 -0400 EDT + + 1975-1975 Feb 23, 02:00 -0400 EDT + + 1976-1986 last Sun in Apr, 02:00 -0400 EDT + + 1987-* first Sun in Apr, 02:00 -0400 EDT + + Note: The specification of a global time zone registry is not + addressed by this document and is left for future study. + However, implementers may find the Olson time zone database [TZ] + a useful reference. It is an informal, public-domain collection + of time zone information, which is currently being maintained by + volunteer Internet participants, and is used in several + operating systems. This database contains current and historical + time zone information for a wide variety of locations around the + globe; it provides a time zone identifier for every unique time + zone rule set in actual use since 1970, with historical data + going back to the introduction of standard time. + + Interoperability between two calendaring and scheduling applications, + especially for recurring events, to-dos or journal entries, is + dependent on the ability to capture and convey date and time + information in an unambiguous format. The specification of current + time zone information is integral to this behavior. + + If present, the "VTIMEZONE" calendar component defines the set of + Standard Time and Daylight Saving Time observances (or rules) for a + particular time zone for a given interval of time. The "VTIMEZONE" + calendar component cannot be nested within other calendar components. + Multiple "VTIMEZONE" calendar components can exist in an iCalendar + object. In this situation, each "VTIMEZONE" MUST represent a unique + + + +Dawson & Stenerson Standards Track [Page 62] + +RFC 2445 iCalendar November 1998 + + + time zone definition. This is necessary for some classes of events, + such as airline flights, that start in one time zone and end in + another. + + The "VTIMEZONE" calendar component MUST be present if the iCalendar + object contains an RRULE that generates dates on both sides of a time + zone shift (e.g. both in Standard Time and Daylight Saving Time) + unless the iCalendar object intends to convey a floating time (See + the section "4.1.10.11 Time" for proper interpretation of floating + time). It can be present if the iCalendar object does not contain + such a RRULE. In addition, if a RRULE is present, there MUST be valid + time zone information for all recurrence instances. + + The "VTIMEZONE" calendar component MUST include the "TZID" property + and at least one definition of a standard or daylight component. The + standard or daylight component MUST include the "DTSTART", + "TZOFFSETFROM" and "TZOFFSETTO" properties. + + An individual "VTIMEZONE" calendar component MUST be specified for + each unique "TZID" parameter value specified in the iCalendar object. + + Each "VTIMEZONE" calendar component consists of a collection of one + or more sub-components that describe the rule for a particular + observance (either a Standard Time or a Daylight Saving Time + observance). The "STANDARD" sub-component consists of a collection of + properties that describe Standard Time. The "DAYLIGHT" sub-component + consists of a collection of properties that describe Daylight Saving + Time. In general this collection of properties consists of: + + - the first onset date-time for the observance + + - the last onset date-time for the observance, if a last onset + is known. + + - the offset to be applied for the observance + + - a rule that describes the day and time when the observance + takes effect + + - an optional name for the observance + + For a given time zone, there may be multiple unique definitions of + the observances over a period of time. Each observance is described + using either a "STANDARD" or "DAYLIGHT" sub-component. The collection + of these sub-components is used to describe the time zone for a given + period of time. The offset to apply at any given time is found by + locating the observance that has the last onset date and time before + the time in question, and using the offset value from that + + + +Dawson & Stenerson Standards Track [Page 63] + +RFC 2445 iCalendar November 1998 + + + observance. + + The top-level properties in a "VTIMEZONE" calendar component are: + + The mandatory "TZID" property is a text value that uniquely + identifies the VTIMZONE calendar component within the scope of an + iCalendar object. + + The optional "LAST-MODIFIED" property is a UTC value that specifies + the date and time that this time zone definition was last updated. + + The optional "TZURL" property is url value that points to a published + VTIMEZONE definition. TZURL SHOULD refer to a resource that is + accessible by anyone who might need to interpret the object. This + SHOULD NOT normally be a file: URL or other URL that is not widely- + accessible. + + The collection of properties that are used to define the STANDARD and + DAYLIGHT sub-components include: + + The mandatory "DTSTART" property gives the effective onset date and + local time for the time zone sub-component definition. "DTSTART" in + this usage MUST be specified as a local DATE-TIME value. + + The mandatory "TZOFFSETFROM" property gives the UTC offset which is + in use when the onset of this time zone observance begins. + "TZOFFSETFROM" is combined with "DTSTART" to define the effective + onset for the time zone sub-component definition. For example, the + following represents the time at which the observance of Standard + Time took effect in Fall 1967 for New York City: + + DTSTART:19671029T020000 + + TZOFFSETFROM:-0400 + + The mandatory "TZOFFSETTO " property gives the UTC offset for the + time zone sub-component (Standard Time or Daylight Saving Time) when + this observance is in use. + + The optional "TZNAME" property is the customary name for the time + zone. It may be specified multiple times, to allow for specifying + multiple language variants of the time zone names. This could be used + for displaying dates. + + If specified, the onset for the observance defined by the time zone + sub-component is defined by either the "RRULE" or "RDATE" property. + If neither is specified, only one sub-component can be specified in + the "VTIMEZONE" calendar component and it is assumed that the single + + + +Dawson & Stenerson Standards Track [Page 64] + +RFC 2445 iCalendar November 1998 + + + observance specified is always in effect. + + The "RRULE" property defines the recurrence rule for the onset of the + observance defined by this time zone sub-component. Some specific + requirements for the usage of RRULE for this purpose include: + + - If observance is known to have an effective end date, the + "UNTIL" recurrence rule parameter MUST be used to specify the + last valid onset of this observance (i.e., the UNTIL date-time + will be equal to the last instance generated by the recurrence + pattern). It MUST be specified in UTC time. + + - The "DTSTART" and the "TZOFFSETTO" properties MUST be used + when generating the onset date-time values (instances) from the + RRULE. + + Alternatively, the "RDATE" property can be used to define the onset + of the observance by giving the individual onset date and times. + "RDATE" in this usage MUST be specified as a local DATE-TIME value in + UTC time. + + The optional "COMMENT" property is also allowed for descriptive + explanatory text. + + Example: The following are examples of the "VTIMEZONE" calendar + component: + + This is an example showing time zone information for the Eastern + United States using "RDATE" property. Note that this is only suitable + for a recurring event that starts on or later than April 6, 1997 at + 03:00:00 EDT (i.e., the earliest effective transition date and time) + and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid + date and time for EST in this scenario). For example, this can be + used for a recurring event that occurs every Friday, 8am-9:00 AM, + starting June 1, 1997, ending December 31, 1997. + + BEGIN:VTIMEZONE + TZID:US-Eastern + LAST-MODIFIED:19870101T000000Z + BEGIN:STANDARD + DTSTART:19971026T020000 + RDATE:19971026T020000 + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + TZNAME:EST + END:STANDARD + BEGIN:DAYLIGHT + DTSTART:19971026T020000 + + + +Dawson & Stenerson Standards Track [Page 65] + +RFC 2445 iCalendar November 1998 + + + RDATE:19970406T020000 + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:EDT + END:DAYLIGHT + END:VTIMEZONE + + This is a simple example showing the current time zone rules for the + Eastern United States using a RRULE recurrence pattern. Note that + there is no effective end date to either of the Standard Time or + Daylight Time rules. This information would be valid for a recurring + event starting today and continuing indefinitely. + + BEGIN:VTIMEZONE + TZID:US-Eastern + LAST-MODIFIED:19870101T000000Z + TZURL:http://zones.stds_r_us.net/tz/US-Eastern + BEGIN:STANDARD + DTSTART:19671029T020000 + RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + TZNAME:EST + END:STANDARD + BEGIN:DAYLIGHT + DTSTART:19870405T020000 + RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:EDT + END:DAYLIGHT + END:VTIMEZONE + + This is an example showing a fictitious set of rules for the Eastern + United States, where the Daylight Time rule has an effective end date + (i.e., after that date, Daylight Time is no longer observed). + + BEGIN:VTIMEZONE + TZID:US--Fictitious-Eastern + LAST-MODIFIED:19870101T000000Z + BEGIN:STANDARD + DTSTART:19671029T020000 + RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + TZNAME:EST + END:STANDARD + + + + +Dawson & Stenerson Standards Track [Page 66] + +RFC 2445 iCalendar November 1998 + + + BEGIN:DAYLIGHT + DTSTART:19870405T020000 + RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:EDT + END:DAYLIGHT + END:VTIMEZONE + + This is an example showing a fictitious set of rules for the Eastern + United States, where the first Daylight Time rule has an effective + end date. There is a second Daylight Time rule that picks up where + the other left off. + + BEGIN:VTIMEZONE + TZID:US--Fictitious-Eastern + LAST-MODIFIED:19870101T000000Z + BEGIN:STANDARD + DTSTART:19671029T020000 + RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + TZNAME:EST + END:STANDARD + BEGIN:DAYLIGHT + DTSTART:19870405T020000 + RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:EDT + END:DAYLIGHT + BEGIN:DAYLIGHT + DTSTART:19990424T020000 + RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:EDT + END:DAYLIGHT + END:VTIMEZONE + +4.6.6 Alarm Component + + Component Name: VALARM + + Purpose: Provide a grouping of component properties that define an + alarm. + + + + + +Dawson & Stenerson Standards Track [Page 67] + +RFC 2445 iCalendar November 1998 + + + Formal Definition: A "VALARM" calendar component is defined by the + following notation: + + alarmc = "BEGIN" ":" "VALARM" CRLF + (audioprop / dispprop / emailprop / procprop) + "END" ":" "VALARM" CRLF + + audioprop = 2*( + + ; 'action' and 'trigger' are both REQUIRED, + ; but MUST NOT occur more than once + + action / trigger / + + ; 'duration' and 'repeat' are both optional, + ; and MUST NOT occur more than once each, + ; but if one occurs, so MUST the other + + duration / repeat / + + ; the following is optional, + ; but MUST NOT occur more than once + + attach / + + ; the following is optional, + ; and MAY occur more than once + + x-prop + + ) + + + + dispprop = 3*( + + ; the following are all REQUIRED, + ; but MUST NOT occur more than once + + action / description / trigger / + + ; 'duration' and 'repeat' are both optional, + ; and MUST NOT occur more than once each, + ; but if one occurs, so MUST the other + + duration / repeat / + + ; the following is optional, + + + +Dawson & Stenerson Standards Track [Page 68] + +RFC 2445 iCalendar November 1998 + + + ; and MAY occur more than once + + *x-prop + + ) + + + + emailprop = 5*( + + ; the following are all REQUIRED, + ; but MUST NOT occur more than once + + action / description / trigger / summary + + ; the following is REQUIRED, + ; and MAY occur more than once + + attendee / + + ; 'duration' and 'repeat' are both optional, + ; and MUST NOT occur more than once each, + ; but if one occurs, so MUST the other + + duration / repeat / + + ; the following are optional, + ; and MAY occur more than once + + attach / x-prop + + ) + + + + procprop = 3*( + + ; the following are all REQUIRED, + ; but MUST NOT occur more than once + + action / attach / trigger / + + ; 'duration' and 'repeat' are both optional, + ; and MUST NOT occur more than once each, + ; but if one occurs, so MUST the other + + duration / repeat / + + + + +Dawson & Stenerson Standards Track [Page 69] + +RFC 2445 iCalendar November 1998 + + + ; 'description' is optional, + ; and MUST NOT occur more than once + + description / + + ; the following is optional, + ; and MAY occur more than once + + x-prop + + ) + + Description: A "VALARM" calendar component is a grouping of component + properties that is a reminder or alarm for an event or a to-do. For + example, it may be used to define a reminder for a pending event or + an overdue to-do. + + The "VALARM" calendar component MUST include the "ACTION" and + "TRIGGER" properties. The "ACTION" property further constrains the + "VALARM" calendar component in the following ways: + + When the action is "AUDIO", the alarm can also include one and only + one "ATTACH" property, which MUST point to a sound resource, which is + rendered when the alarm is triggered. + + When the action is "DISPLAY", the alarm MUST also include a + "DESCRIPTION" property, which contains the text to be displayed when + the alarm is triggered. + + When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" + property, which contains the text to be used as the message body, a + "SUMMARY" property, which contains the text to be used as the message + subject, and one or more "ATTENDEE" properties, which contain the + email address of attendees to receive the message. It can also + include one or more "ATTACH" properties, which are intended to be + sent as message attachments. When the alarm is triggered, the email + message is sent. + + When the action is "PROCEDURE", the alarm MUST include one and only + one "ATTACH" property, which MUST point to a procedure resource, + which is invoked when the alarm is triggered. + + The "VALARM" calendar component MUST only appear within either a + "VEVENT" or "VTODO" calendar component. "VALARM" calendar components + cannot be nested. Multiple mutually independent "VALARM" calendar + components can be specified for a single "VEVENT" or "VTODO" calendar + component. + + + + +Dawson & Stenerson Standards Track [Page 70] + +RFC 2445 iCalendar November 1998 + + + The "TRIGGER" property specifies when the alarm will be triggered. + The "TRIGGER" property specifies a duration prior to the start of an + event or a to-do. The "TRIGGER" edge may be explicitly set to be + relative to the "START" or "END" of the event or to-do with the + "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property + value type can alternatively be set to an absolute calendar date and + time of day value. + + In an alarm set to trigger on the "START" of an event or to-do, the + "DTSTART" property MUST be present in the associated event or to-do. + In an alarm in a "VEVENT" calendar component set to trigger on the + "END" of the event, either the "DTEND" property MUST be present, or + the "DTSTART" and "DURATION" properties MUST both be present. In an + alarm in a "VTODO" calendar component set to trigger on the "END" of + the to-do, either the "DUE" property MUST be present, or the + "DTSTART" and "DURATION" properties MUST both be present. + + The alarm can be defined such that it triggers repeatedly. A + definition of an alarm with a repeating trigger MUST include both the + "DURATION" and "REPEAT" properties. The "DURATION" property specifies + the delay period, after which the alarm will repeat. The "REPEAT" + property specifies the number of additional repetitions that the + alarm will triggered. This repitition count is in addition to the + initial triggering of the alarm. Both of these properties MUST be + present in order to specify a repeating alarm. If one of these two + properties is absent, then the alarm will not repeat beyond the + initial trigger. + + The "ACTION" property is used within the "VALARM" calendar component + to specify the type of action invoked when the alarm is triggered. + The "VALARM" properties provide enough information for a specific + action to be invoked. It is typically the responsibility of a + "Calendar User Agent" (CUA) to deliver the alarm in the specified + fashion. An "ACTION" property value of AUDIO specifies an alarm that + causes a sound to be played to alert the user; DISPLAY specifies an + alarm that causes a text message to be displayed to the user; EMAIL + specifies an alarm that causes an electronic email message to be + delivered to one or more email addresses; and PROCEDURE specifies an + alarm that causes a procedure to be executed. The "ACTION" property + MUST specify one and only one of these values. + + In an AUDIO alarm, if the optional "ATTACH" property is included, it + MUST specify an audio sound resource. The intention is that the sound + will be played as the alarm effect. If an "ATTACH" property is + specified that does not refer to a sound resource, or if the + specified sound resource cannot be rendered (because its format is + unsupported, or because it cannot be retrieved), then the CUA or + other entity responsible for playing the sound may choose a fallback + + + +Dawson & Stenerson Standards Track [Page 71] + +RFC 2445 iCalendar November 1998 + + + action, such as playing a built-in default sound, or playing no sound + at all. + + In a DISPLAY alarm, the intended alarm effect is for the text value + of the "DESCRIPTION" property to be displayed to the user. + + In an EMAIL alarm, the intended alarm effect is for an email message + to be composed and delivered to all the addresses specified by the + "ATTENDEE" properties in the "VALARM" calendar component. The + "DESCRIPTION" property of the "VALARM" calendar component MUST be + used as the body text of the message, and the "SUMMARY" property MUST + be used as the subject text. Any "ATTACH" properties in the "VALARM" + calendar component SHOULD be sent as attachments to the message. + + In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar + component MUST specify a procedure or program that is intended to be + invoked as the alarm effect. If the procedure or program is in a + format that cannot be rendered, then no procedure alarm will be + invoked. If the "DESCRIPTION" property is present, its value + specifies the argument string to be passed to the procedure or + program. "Calendar User Agents" that receive an iCalendar object with + this category of alarm, can disable or allow the "Calendar User" to + disable, or otherwise ignore this type of alarm. While a very useful + alarm capability, the PROCEDURE type of alarm SHOULD be treated by + the "Calendar User Agent" as a potential security risk. + + Example: The following example is for a "VALARM" calendar component + that specifies an audio alarm that will sound at a precise time and + repeat 4 more times at 15 minute intervals: + + BEGIN:VALARM + TRIGGER;VALUE=DATE-TIME:19970317T133000Z + REPEAT:4 + DURATION:PT15M + ACTION:AUDIO + ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud + END:VALARM + + The following example is for a "VALARM" calendar component that + specifies a display alarm that will trigger 30 minutes before the + scheduled start of the event or the due date/time of the to-do it is + associated with and will repeat 2 more times at 15 minute intervals: + + BEGIN:VALARM + TRIGGER:-PT30M + REPEAT:2 + DURATION:PT15M + ACTION:DISPLAY + + + +Dawson & Stenerson Standards Track [Page 72] + +RFC 2445 iCalendar November 1998 + + + DESCRIPTION:Breakfast meeting with executive\n + team at 8:30 AM EST. + END:VALARM + + The following example is for a "VALARM" calendar component that + specifies an email alarm that will trigger 2 days before the + scheduled due date/time of a to-do it is associated with. It does not + repeat. The email has a subject, body and attachment link. + + BEGIN:VALARM + TRIGGER:-P2D + ACTION:EMAIL + ATTENDEE:MAILTO:john_doe@host.com + SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** + DESCRIPTION:A draft agenda needs to be sent out to the attendees + to the weekly managers meeting (MGR-LIST). Attached is a + pointer the document template for the agenda file. + ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen + da.doc + END:VALARM + + The following example is for a "VALARM" calendar component that + specifies a procedural alarm that will trigger at a precise date/time + and will repeat 23 more times at one hour intervals. The alarm will + invoke a procedure file. + + BEGIN:VALARM + TRIGGER;VALUE=DATE-TIME:19980101T050000Z + REPEAT:23 + DURATION:PT1H + ACTION:PROCEDURE + ATTACH;FMTTYPE=application/binary:ftp://host.com/novo- + procs/felizano.exe + END:VALARM + +4.7 Calendar Properties + + The Calendar Properties are attributes that apply to the iCalendar + object, as a whole. These properties do not appear within a calendar + component. They SHOULD be specified after the "BEGIN:VCALENDAR" + property and prior to any calendar component. + +4.7.1 Calendar Scale + + Property Name: CALSCALE + + Purpose: This property defines the calendar scale used for the + calendar information specified in the iCalendar object. + + + +Dawson & Stenerson Standards Track [Page 73] + +RFC 2445 iCalendar November 1998 + + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: Property can be specified in an iCalendar object. The + default value is "GREGORIAN". + + Description: This memo is based on the Gregorian calendar scale. The + Gregorian calendar scale is assumed if this property is not specified + in the iCalendar object. It is expected that other calendar scales + will be defined in other specifications or by future versions of this + memo. + + Format Definition: The property is defined by the following notation: + + calscale = "CALSCALE" calparam ":" calvalue CRLF + + calparam = *(";" xparam) + + calvalue = "GREGORIAN" / iana-token + + Example: The following is an example of this property: + + CALSCALE:GREGORIAN + +4.7.2 Method + + Property Name: METHOD + + Purpose: This property defines the iCalendar object method associated + with the calendar object. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in an iCalendar object. + + Description: When used in a MIME message entity, the value of this + property MUST be the same as the Content-Type "method" parameter + value. This property can only appear once within the iCalendar + object. If either the "METHOD" property or the Content-Type "method" + parameter is specified, then the other MUST also be specified. + + No methods are defined by this specification. This is the subject of + other specifications, such as the iCalendar Transport-independent + + + +Dawson & Stenerson Standards Track [Page 74] + +RFC 2445 iCalendar November 1998 + + + Interoperability Protocol (iTIP) defined by [ITIP]. + + If this property is not present in the iCalendar object, then a + scheduling transaction MUST NOT be assumed. In such cases, the + iCalendar object is merely being used to transport a snapshot of some + calendar information; without the intention of conveying a scheduling + semantic. + + Format Definition: The property is defined by the following notation: + + method = "METHOD" metparam ":" metvalue CRLF + + metparam = *(";" xparam) + + metvalue = iana-token + + Example: The following is a hypothetical example of this property to + convey that the iCalendar object is a request for a meeting: + + METHOD:REQUEST + +4.7.3 Product Identifier + + Property Name: PRODID + + Purpose: This property specifies the identifier for the product that + created the iCalendar object. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property MUST be specified once in an iCalendar + object. + + Description: The vendor of the implementation SHOULD assure that this + is a globally unique identifier; using some technique such as an FPI + value, as defined in [ISO 9070]. + + This property SHOULD not be used to alter the interpretation of an + iCalendar object beyond the semantics specified in this memo. For + example, it is not to be used to further the understanding of non- + standard properties. + + Format Definition: The property is defined by the following notation: + + prodid = "PRODID" pidparam ":" pidvalue CRLF + + + +Dawson & Stenerson Standards Track [Page 75] + +RFC 2445 iCalendar November 1998 + + + pidparam = *(";" xparam) + + pidvalue = text + ;Any text that describes the product and version + ;and that is generally assured of being unique. + + Example: The following is an example of this property. It does not + imply that English is the default language. + + PRODID:-//ABC Corporation//NONSGML My Product//EN + +4.7.4 Version + + Property Name: VERSION + + Purpose: This property specifies the identifier corresponding to the + highest version number or the minimum and maximum range of the + iCalendar specification that is required in order to interpret the + iCalendar object. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be specified by an iCalendar object, + but MUST only be specified once. + + Description: A value of "2.0" corresponds to this memo. + + Format Definition: The property is defined by the following notation: + + version = "VERSION" verparam ":" vervalue CRLF + + verparam = *(";" xparam) + + vervalue = "2.0" ;This memo + / maxver + / (minver ";" maxver) + + minver = + ;Minimum iCalendar version needed to parse the iCalendar object + + maxver = + ;Maximum iCalendar version needed to parse the iCalendar object + + Example: The following is an example of this property: + + + + +Dawson & Stenerson Standards Track [Page 76] + +RFC 2445 iCalendar November 1998 + + + VERSION:2.0 + +4.8 Component Properties + + The following properties can appear within calendar components, as + specified by each component property definition. + +4.8.1 Descriptive Component Properties + + The following properties specify descriptive information about + calendar components. + +4.8.1.1 Attachment + + Property Name: ATTACH + + Purpose: The property provides the capability to associate a document + object with a calendar component. + + Value Type: The default value type for this property is URI. The + value type can also be set to BINARY to indicate inline binary + encoded content information. + + Property Parameters: Non-standard, inline encoding, format type and + value data type property parameters can be specified on this + property. + + Conformance: The property can be specified in a "VEVENT", "VTODO", + "VJOURNAL" or "VALARM" calendar components. + + Description: The property can be specified within "VEVENT", "VTODO", + "VJOURNAL", or "VALARM" calendar components. This property can be + specified multiple times within an iCalendar object. + + Format Definition: The property is defined by the following notation: + + attach = "ATTACH" attparam ":" uri CRLF + + attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64" + ";" "VALUE" "=" "BINARY" ":" binary + + attparam = *( + + ; the following is optional, + ; but MUST NOT occur more than once + + (";" fmttypeparam) / + + + + +Dawson & Stenerson Standards Track [Page 77] + +RFC 2445 iCalendar November 1998 + + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following are examples of this property: + + ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com + + ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ + reports/r-960812.ps + +4.8.1.2 Categories + + Property Name: CATEGORIES + + Purpose: This property defines the categories for a calendar + component. + + Value Type: TEXT + + Property Parameters: Non-standard and language property parameters + can be specified on this property. + + Conformance: The property can be specified within "VEVENT", "VTODO" + or "VJOURNAL" calendar components. + + Description: This property is used to specify categories or subtypes + of the calendar component. The categories are useful in searching for + a calendar component of a particular type and category. Within the + "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one + category can be specified as a list of categories separated by the + COMMA character (US-ASCII decimal 44). + + Format Definition: The property is defined by the following notation: + + categories = "CATEGORIES" catparam ":" text *("," text) + CRLF + + catparam = *( + + ; the following is optional, + ; but MUST NOT occur more than once + + (";" languageparam ) / + + + + +Dawson & Stenerson Standards Track [Page 78] + +RFC 2445 iCalendar November 1998 + + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following are examples of this property: + + CATEGORIES:APPOINTMENT,EDUCATION + + CATEGORIES:MEETING + +4.8.1.3 Classification + + Property Name: CLASS + + Purpose: This property defines the access classification for a + calendar component. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified once in a "VEVENT", + "VTODO" or "VJOURNAL" calendar components. + + Description: An access classification is only one component of the + general security system within a calendar application. It provides a + method of capturing the scope of the access the calendar owner + intends for information within an individual calendar entry. The + access classification of an individual iCalendar component is useful + when measured along with the other security components of a calendar + system (e.g., calendar user authentication, authorization, access + rights, access role, etc.). Hence, the semantics of the individual + access classifications cannot be completely defined by this memo + alone. Additionally, due to the "blind" nature of most exchange + processes using this memo, these access classifications cannot serve + as an enforcement statement for a system receiving an iCalendar + object. Rather, they provide a method for capturing the intention of + the calendar owner for the access to the calendar component. + + Format Definition: The property is defined by the following notation: + + class = "CLASS" classparam ":" classvalue CRLF + + classparam = *(";" xparam) + + + +Dawson & Stenerson Standards Track [Page 79] + +RFC 2445 iCalendar November 1998 + + + classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token + / x-name + ;Default is PUBLIC + + Example: The following is an example of this property: + + CLASS:PUBLIC + +4.8.1.4 Comment + + Property Name: COMMENT + + Purpose: This property specifies non-processing information intended + to provide a comment to the calendar user. + + Value Type: TEXT + + Property Parameters: Non-standard, alternate text representation and + language property parameters can be specified on this property. + + Conformance: This property can be specified in "VEVENT", "VTODO", + "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components. + + Description: The property can be specified multiple times. + + Format Definition: The property is defined by the following notation: + + comment = "COMMENT" commparam ":" text CRLF + + commparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" altrepparam) / (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following is an example of this property: + + COMMENT:The meeting really needs to include both ourselves + and the customer. We can't hold this meeting without them. + As a matter of fact\, the venue for the meeting ought to be at + + + +Dawson & Stenerson Standards Track [Page 80] + +RFC 2445 iCalendar November 1998 + + + their site. - - John + + The data type for this property is TEXT. + +4.8.1.5 Description + + Property Name: DESCRIPTION + + Purpose: This property provides a more complete description of the + calendar component, than that provided by the "SUMMARY" property. + + Value Type: TEXT + + Property Parameters: Non-standard, alternate text representation and + language property parameters can be specified on this property. + + Conformance: The property can be specified in the "VEVENT", "VTODO", + "VJOURNAL" or "VALARM" calendar components. The property can be + specified multiple times only within a "VJOURNAL" calendar component. + + Description: This property is used in the "VEVENT" and "VTODO" to + capture lengthy textual decriptions associated with the activity. + + This property is used in the "VJOURNAL" calendar component to capture + one more textual journal entries. + + This property is used in the "VALARM" calendar component to capture + the display text for a DISPLAY category of alarm, to capture the body + text for an EMAIL category of alarm and to capture the argument + string for a PROCEDURE category of alarm. + + Format Definition: The property is defined by the following notation: + + description = "DESCRIPTION" descparam ":" text CRLF + + descparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" altrepparam) / (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + + +Dawson & Stenerson Standards Track [Page 81] + +RFC 2445 iCalendar November 1998 + + + Example: The following is an example of the property with formatted + line breaks in the property value: + + DESCRIPTION:Meeting to provide technical review for "Phoenix" + design.\n Happy Face Conference Room. Phoenix design team + MUST attend this meeting.\n RSVP to team leader. + + The following is an example of the property with folding of long + lines: + + DESCRIPTION:Last draft of the new novel is to be completed + for the editor's proof today. + +4.8.1.6 Geographic Position + + Property Name: GEO + + Purpose: This property specifies information related to the global + position for the activity specified by a calendar component. + + Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT + values. + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VEVENT" or "VTODO" + calendar components. + + Description: The property value specifies latitude and longitude, in + that order (i.e., "LAT LON" ordering). The longitude represents the + location east or west of the prime meridian as a positive or negative + real number, respectively. The longitude and latitude values MAY be + specified up to six decimal places, which will allow for accuracy to + within one meter of geographical position. Receiving applications + MUST accept values of this precision and MAY truncate values of + greater precision. + + Values for latitude and longitude shall be expressed as decimal + fractions of degrees. Whole degrees of latitude shall be represented + by a two-digit decimal number ranging from 0 through 90. Whole + degrees of longitude shall be represented by a decimal number ranging + from 0 through 180. When a decimal fraction of a degree is specified, + it shall be separated from the whole number of degrees by a decimal + point. + + + + + + +Dawson & Stenerson Standards Track [Page 82] + +RFC 2445 iCalendar November 1998 + + + Latitudes north of the equator shall be specified by a plus sign (+), + or by the absence of a minus sign (-), preceding the digits + designating degrees. Latitudes south of the Equator shall be + designated by a minus sign (-) preceding the digits designating + degrees. A point on the Equator shall be assigned to the Northern + Hemisphere. + + Longitudes east of the prime meridian shall be specified by a plus + sign (+), or by the absence of a minus sign (-), preceding the digits + designating degrees. Longitudes west of the meridian shall be + designated by minus sign (-) preceding the digits designating + degrees. A point on the prime meridian shall be assigned to the + Eastern Hemisphere. A point on the 180th meridian shall be assigned + to the Western Hemisphere. One exception to this last convention is + permitted. For the special condition of describing a band of latitude + around the earth, the East Bounding Coordinate data element shall be + assigned the value +180 (180) degrees. + + Any spatial address with a latitude of +90 (90) or -90 degrees will + specify the position at the North or South Pole, respectively. The + component for longitude may have any legal value. + + With the exception of the special condition described above, this + form is specified in Department of Commerce, 1986, Representation of + geographic point locations for information interchange (Federal + Information Processing Standard 70-1): Washington, Department of + Commerce, National Institute of Standards and Technology. + + The simple formula for converting degrees-minutes-seconds into + decimal degrees is: + + decimal = degrees + minutes/60 + seconds/3600. + + Format Definition: The property is defined by the following notation: + + geo = "GEO" geoparam ":" geovalue CRLF + + geoparam = *(";" xparam) + + geovalue = float ";" float + ;Latitude and Longitude components + + Example: The following is an example of this property: + + GEO:37.386013;-122.082932 + + + + + + +Dawson & Stenerson Standards Track [Page 83] + +RFC 2445 iCalendar November 1998 + + +4.8.1.7 Location + + Property Name: LOCATION + + Purpose: The property defines the intended venue for the activity + defined by a calendar component. + + Value Type: TEXT + + Property Parameters: Non-standard, alternate text representation and + language property parameters can be specified on this property. + + Conformance: This property can be specified in "VEVENT" or "VTODO" + calendar component. + + Description: Specific venues such as conference or meeting rooms may + be explicitly specified using this property. An alternate + representation may be specified that is a URI that points to + directory information with more structured specification of the + location. For example, the alternate representation may specify + either an LDAP URI pointing to an LDAP server entry or a CID URI + pointing to a MIME body part containing a vCard [RFC 2426] for the + location. + + Format Definition: The property is defined by the following notation: + + location = "LOCATION locparam ":" text CRLF + + locparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" altrepparam) / (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following are some examples of this property: + + LOCATION:Conference Room - F123, Bldg. 002 + + LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": + Conference Room - F123, Bldg. 002 + + + +Dawson & Stenerson Standards Track [Page 84] + +RFC 2445 iCalendar November 1998 + + +4.8.1.8 Percent Complete + + Property Name: PERCENT-COMPLETE + + Purpose: This property is used by an assignee or delegatee of a to-do + to convey the percent completion of a to-do to the Organizer. + + Value Type: INTEGER + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in a "VTODO" calendar + component. + + Description: The property value is a positive integer between zero + and one hundred. A value of "0" indicates the to-do has not yet been + started. A value of "100" indicates that the to-do has been + completed. Integer values in between indicate the percent partially + complete. + + When a to-do is assigned to multiple individuals, the property value + indicates the percent complete for that portion of the to-do assigned + to the assignee or delegatee. For example, if a to-do is assigned to + both individuals "A" and "B". A reply from "A" with a percent + complete of "70" indicates that "A" has completed 70% of the to-do + assigned to them. A reply from "B" with a percent complete of "50" + indicates "B" has completed 50% of the to-do assigned to them. + + Format Definition: The property is defined by the following notation: + + percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF + + pctparam = *(";" xparam) + + Example: The following is an example of this property to show 39% + completion: + + PERCENT-COMPLETE:39 + +4.8.1.9 Priority + + Property Name: PRIORITY + + Purpose: The property defines the relative priority for a calendar + component. + + Value Type: INTEGER + + + +Dawson & Stenerson Standards Track [Page 85] + +RFC 2445 iCalendar November 1998 + + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in a "VEVENT" or "VTODO" + calendar component. + + Description: The priority is specified as an integer in the range + zero to nine. A value of zero (US-ASCII decimal 48) specifies an + undefined priority. A value of one (US-ASCII decimal 49) is the + highest priority. A value of two (US-ASCII decimal 50) is the second + highest priority. Subsequent numbers specify a decreasing ordinal + priority. A value of nine (US-ASCII decimal 58) is the lowest + priority. + + A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and + "LOW" is mapped into this property such that a property value in the + range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52) + specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is + the normal or "MEDIUM" priority. A value in the range of six (US- + ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority. + + A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., + "C3" is mapped into this property such that a property value of one + (US-ASCII decimal 49) specifies "A1", a property value of two (US- + ASCII decimal 50) specifies "A2", a property value of three (US-ASCII + decimal 51) specifies "A3", and so forth up to a property value of 9 + (US-ASCII decimal 58) specifies "C3". + + Other integer values are reserved for future use. + + Within a "VEVENT" calendar component, this property specifies a + priority for the event. This property may be useful when more than + one event is scheduled for a given time period. + + Within a "VTODO" calendar component, this property specified a + priority for the to-do. This property is useful in prioritizing + multiple action items for a given time period. + + Format Definition: The property is specified by the following + notation: + + priority = "PRIORITY" prioparam ":" privalue CRLF + ;Default is zero + + prioparam = *(";" xparam) + + privalue = integer ;Must be in the range [0..9] + ; All other values are reserved for future use + + + +Dawson & Stenerson Standards Track [Page 86] + +RFC 2445 iCalendar November 1998 + + + The following is an example of a property with the highest priority: + + PRIORITY:1 + + The following is an example of a property with a next highest + priority: + + PRIORITY:2 + + Example: The following is an example of a property with no priority. + This is equivalent to not specifying the "PRIORITY" property: + + PRIORITY:0 + +4.8.1.10 Resources + + Property Name: RESOURCES + + Purpose: This property defines the equipment or resources anticipated + for an activity specified by a calendar entity.. + + Value Type: TEXT + + Property Parameters: Non-standard, alternate text representation and + language property parameters can be specified on this property. + + Conformance: This property can be specified in "VEVENT" or "VTODO" + calendar component. + + Description: The property value is an arbitrary text. More than one + resource can be specified as a list of resources separated by the + COMMA character (US-ASCII decimal 44). + + Format Definition: The property is defined by the following notation: + + resources = "RESOURCES" resrcparam ":" text *("," text) CRLF + + resrcparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" altrepparam) / (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + + + + +Dawson & Stenerson Standards Track [Page 87] + +RFC 2445 iCalendar November 1998 + + + (";" xparam) + + ) + + Example: The following is an example of this property: + + RESOURCES:EASEL,PROJECTOR,VCR + + RESOURCES;LANGUAGE=fr:1 raton-laveur + +4.8.1.11 Status + + Property Name: STATUS + + Purpose: This property defines the overall status or confirmation for + the calendar component. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VEVENT", "VTODO" or + "VJOURNAL" calendar components. + + Description: In a group scheduled calendar component, the property is + used by the "Organizer" to provide a confirmation of the event to the + "Attendees". For example in a "VEVENT" calendar component, the + "Organizer" can indicate that a meeting is tentative, confirmed or + cancelled. In a "VTODO" calendar component, the "Organizer" can + indicate that an action item needs action, is completed, is in + process or being worked on, or has been cancelled. In a "VJOURNAL" + calendar component, the "Organizer" can indicate that a journal entry + is draft, final or has been cancelled or removed. + + Format Definition: The property is defined by the following notation: + + status = "STATUS" statparam] ":" statvalue CRLF + + statparam = *(";" xparam) + + statvalue = "TENTATIVE" ;Indicates event is + ;tentative. + / "CONFIRMED" ;Indicates event is + ;definite. + / "CANCELLED" ;Indicates event was + ;cancelled. + ;Status values for a "VEVENT" + + + +Dawson & Stenerson Standards Track [Page 88] + +RFC 2445 iCalendar November 1998 + + + statvalue =/ "NEEDS-ACTION" ;Indicates to-do needs action. + / "COMPLETED" ;Indicates to-do completed. + / "IN-PROCESS" ;Indicates to-do in process of + / "CANCELLED" ;Indicates to-do was cancelled. + ;Status values for "VTODO". + + statvalue =/ "DRAFT" ;Indicates journal is draft. + / "FINAL" ;Indicates journal is final. + / "CANCELLED" ;Indicates journal is removed. + ;Status values for "VJOURNAL". + + Example: The following is an example of this property for a "VEVENT" + calendar component: + + STATUS:TENTATIVE + + The following is an example of this property for a "VTODO" calendar + component: + + STATUS:NEEDS-ACTION + + The following is an example of this property for a "VJOURNAL" + calendar component: + + STATUS:DRAFT + +4.8.1.12 Summary + + Property Name: SUMMARY + + Purpose: This property defines a short summary or subject for the + calendar component. + + Value Type: TEXT + + Property Parameters: Non-standard, alternate text representation and + language property parameters can be specified on this property. + + Conformance: The property can be specified in "VEVENT", "VTODO", + "VJOURNAL" or "VALARM" calendar components. + + Description: This property is used in the "VEVENT", "VTODO" and + "VJOURNAL" calendar components to capture a short, one line summary + about the activity or journal entry. + + This property is used in the "VALARM" calendar component to capture + the subject of an EMAIL category of alarm. + + + + +Dawson & Stenerson Standards Track [Page 89] + +RFC 2445 iCalendar November 1998 + + + Format Definition: The property is defined by the following notation: + + summary = "SUMMARY" summparam ":" text CRLF + + summparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" altrepparam) / (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following is an example of this property: + + SUMMARY:Department Party + +4.8.2 Date and Time Component Properties + + The following properties specify date and time related information in + calendar components. + +4.8.2.1 Date/Time Completed + + Property Name: COMPLETED + + Purpose: This property defines the date and time that a to-do was + actually completed. + + Value Type: DATE-TIME + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in a "VTODO" calendar + component. + + Description: The date and time MUST be in a UTC format. + + Format Definition: The property is defined by the following notation: + + completed = "COMPLETED" compparam ":" date-time CRLF + + + + +Dawson & Stenerson Standards Track [Page 90] + +RFC 2445 iCalendar November 1998 + + + compparam = *(";" xparam) + + Example: The following is an example of this property: + + COMPLETED:19960401T235959Z + +4.8.2.2 Date/Time End + + Property Name: DTEND + + Purpose: This property specifies the date and time that a calendar + component ends. + + Value Type: The default value type is DATE-TIME. The value type can + be set to a DATE value type. + + Property Parameters: Non-standard, value data type, time zone + identifier property parameters can be specified on this property. + + Conformance: This property can be specified in "VEVENT" or + "VFREEBUSY" calendar components. + + Description: Within the "VEVENT" calendar component, this property + defines the date and time by which the event ends. The value MUST be + later in time than the value of the "DTSTART" property. + + Within the "VFREEBUSY" calendar component, this property defines the + end date and time for the free or busy time information. The time + MUST be specified in the UTC time format. The value MUST be later in + time than the value of the "DTSTART" property. + + Format Definition: The property is defined by the following notation: + + dtend = "DTEND" dtendparam":" dtendval CRLF + + dtendparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / + (";" tzidparam) / + + ; the following is optional, + ; and MAY occur more than once + + + + + + +Dawson & Stenerson Standards Track [Page 91] + +RFC 2445 iCalendar November 1998 + + + (";" xparam) + + ) + + + + dtendval = date-time / date + ;Value MUST match value type + + Example: The following is an example of this property: + + DTEND:19960401T235959Z + + DTEND;VALUE=DATE:19980704 + +4.8.2.3 Date/Time Due + + Property Name: DUE + + Purpose: This property defines the date and time that a to-do is + expected to be completed. + + Value Type: The default value type is DATE-TIME. The value type can + be set to a DATE value type. + + Property Parameters: Non-standard, value data type, time zone + identifier property parameters can be specified on this property. + + Conformance: The property can be specified once in a "VTODO" calendar + component. + + Description: The value MUST be a date/time equal to or after the + DTSTART value, if specified. + + Format Definition: The property is defined by the following notation: + + due = "DUE" dueparam":" dueval CRLF + + dueparam = *( + ; the following are optional, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / + (";" tzidparam) / + + ; the following is optional, + ; and MAY occur more than once + + + + +Dawson & Stenerson Standards Track [Page 92] + +RFC 2445 iCalendar November 1998 + + + *(";" xparam) + + ) + + + + dueval = date-time / date + ;Value MUST match value type + + Example: The following is an example of this property: + + DUE:19980430T235959Z + +4.8.2.4 Date/Time Start + + Property Name: DTSTART + + Purpose: This property specifies when the calendar component begins. + + Value Type: The default value type is DATE-TIME. The time value MUST + be one of the forms defined for the DATE-TIME value type. The value + type can be set to a DATE value type. + + Property Parameters: Non-standard, value data type, time zone + identifier property parameters can be specified on this property. + + Conformance: This property can be specified in the "VEVENT", "VTODO", + "VFREEBUSY", or "VTIMEZONE" calendar components. + + Description: Within the "VEVENT" calendar component, this property + defines the start date and time for the event. The property is + REQUIRED in "VEVENT" calendar components. Events can have a start + date/time but no end date/time. In that case, the event does not take + up any time. + + Within the "VFREEBUSY" calendar component, this property defines the + start date and time for the free or busy time information. The time + MUST be specified in UTC time. + + Within the "VTIMEZONE" calendar component, this property defines the + effective start date and time for a time zone specification. This + property is REQUIRED within each STANDARD and DAYLIGHT part included + in "VTIMEZONE" calendar components and MUST be specified as a local + DATE-TIME without the "TZID" property parameter. + + Format Definition: The property is defined by the following notation: + + dtstart = "DTSTART" dtstparam ":" dtstval CRLF + + + +Dawson & Stenerson Standards Track [Page 93] + +RFC 2445 iCalendar November 1998 + + + dtstparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / + (";" tzidparam) / + + ; the following is optional, + ; and MAY occur more than once + + *(";" xparam) + + ) + + + + dtstval = date-time / date + ;Value MUST match value type + + Example: The following is an example of this property: + + DTSTART:19980118T073000Z + +4.8.2.5 Duration + + Property Name: DURATION + + Purpose: The property specifies a positive duration of time. + + Value Type: DURATION + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in "VEVENT", "VTODO", + "VFREEBUSY" or "VALARM" calendar components. + + Description: In a "VEVENT" calendar component the property may be + used to specify a duration of the event, instead of an explicit end + date/time. In a "VTODO" calendar component the property may be used + to specify a duration for the to-do, instead of an explicit due + date/time. In a "VFREEBUSY" calendar component the property may be + used to specify the interval of free time being requested. In a + "VALARM" calendar component the property may be used to specify the + delay period prior to repeating an alarm. + + Format Definition: The property is defined by the following notation: + + + +Dawson & Stenerson Standards Track [Page 94] + +RFC 2445 iCalendar November 1998 + + + duration = "DURATION" durparam ":" dur-value CRLF + ;consisting of a positive duration of time. + + durparam = *(";" xparam) + + Example: The following is an example of this property that specifies + an interval of time of 1 hour and zero minutes and zero seconds: + + DURATION:PT1H0M0S + + The following is an example of this property that specifies an + interval of time of 15 minutes. + + DURATION:PT15M + +4.8.2.6 Free/Busy Time + + Property Name: FREEBUSY + + Purpose: The property defines one or more free or busy time + intervals. + + Value Type: PERIOD. The date and time values MUST be in an UTC time + format. + + Property Parameters: Non-standard or free/busy time type property + parameters can be specified on this property. + + Conformance: The property can be specified in a "VFREEBUSY" calendar + component. + + Property Parameter: "FBTYPE" and non-standard parameters can be + specified on this property. + + Description: These time periods can be specified as either a start + and end date-time or a start date-time and duration. The date and + time MUST be a UTC time format. + + "FREEBUSY" properties within the "VFREEBUSY" calendar component + SHOULD be sorted in ascending order, based on start time and then end + time, with the earliest periods first. + + The "FREEBUSY" property can specify more than one value, separated by + the COMMA character (US-ASCII decimal 44). In such cases, the + "FREEBUSY" property values SHOULD all be of the same "FBTYPE" + property parameter type (e.g., all values of a particular "FBTYPE" + listed together in a single property). + + + + +Dawson & Stenerson Standards Track [Page 95] + +RFC 2445 iCalendar November 1998 + + + Format Definition: The property is defined by the following notation: + + freebusy = "FREEBUSY" fbparam ":" fbvalue + CRLF + + fbparam = *( + ; the following is optional, + ; but MUST NOT occur more than once + + (";" fbtypeparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + fbvalue = period *["," period] + ;Time value MUST be in the UTC time format. + + Example: The following are some examples of this property: + + FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M + + FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H + + FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H, + 19970308T230000Z/19970309T000000Z + +4.8.2.7 Time Transparency + + Property Name: TRANSP + + Purpose: This property defines whether an event is transparent or not + to busy time searches. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified once in a "VEVENT" + calendar component. + + Description: Time Transparency is the characteristic of an event that + determines whether it appears to consume time on a calendar. Events + that consume actual time for the individual or resource associated + + + +Dawson & Stenerson Standards Track [Page 96] + +RFC 2445 iCalendar November 1998 + + + with the calendar SHOULD be recorded as OPAQUE, allowing them to be + detected by free-busy time searches. Other events, which do not take + up the individual's (or resource's) time SHOULD be recorded as + TRANSPARENT, making them invisible to free-busy time searches. + + Format Definition: The property is specified by the following + notation: + + transp = "TRANSP" tranparam ":" transvalue CRLF + + tranparam = *(";" xparam) + + transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. + / "TRANSPARENT" ;Transparent on busy time searches. + ;Default value is OPAQUE + + Example: The following is an example of this property for an event + that is transparent or does not block on free/busy time searches: + + TRANSP:TRANSPARENT + + The following is an example of this property for an event that is + opaque or blocks on free/busy time searches: + + TRANSP:OPAQUE + +4.8.3 Time Zone Component Properties + + The following properties specify time zone information in calendar + components. + +4.8.3.1 Time Zone Identifier + + Property Name: TZID + + Purpose: This property specifies the text value that uniquely + identifies the "VTIMEZONE" calendar component. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be specified in a "VTIMEZONE" + calendar component. + + + + + + +Dawson & Stenerson Standards Track [Page 97] + +RFC 2445 iCalendar November 1998 + + + Description: This is the label by which a time zone calendar + component is referenced by any iCalendar properties whose data type + is either DATE-TIME or TIME and not intended to specify a UTC or a + "floating" time. The presence of the SOLIDUS character (US-ASCII + decimal 47) as a prefix, indicates that this TZID represents an + unique ID in a globally defined time zone registry (when such + registry is defined). + + Note: This document does not define a naming convention for time + zone identifiers. Implementers may want to use the naming + conventions defined in existing time zone specifications such as + the public-domain Olson database [TZ]. The specification of + globally unique time zone identifiers is not addressed by this + document and is left for future study. + + Format Definition: This property is defined by the following + notation: + + tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF + + tzidpropparam = *(";" xparam) + + ;tzidprefix = "/" + ; Defined previously. Just listed here for reader convenience. + + Example: The following are examples of non-globally unique time zone + identifiers: + + TZID:US-Eastern + + TZID:California-Los_Angeles + + The following is an example of a fictitious globally unique time zone + identifier: + + TZID:/US-New_York-New_York + +4.8.3.2 Time Zone Name + + Property Name: TZNAME + + Purpose: This property specifies the customary designation for a time + zone description. + + Value Type: TEXT + + Property Parameters: Non-standard and language property parameters + can be specified on this property. + + + +Dawson & Stenerson Standards Track [Page 98] + +RFC 2445 iCalendar November 1998 + + + Conformance: This property can be specified in a "VTIMEZONE" calendar + component. + + Description: This property may be specified in multiple languages; in + order to provide for different language requirements. + + Format Definition: This property is defined by the following + notation: + + tzname = "TZNAME" tznparam ":" text CRLF + + tznparam = *( + + ; the following is optional, + ; but MUST NOT occur more than once + + (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following are example of this property: + + TZNAME:EST + + The following is an example of this property when two different + languages for the time zone name are specified: + + TZNAME;LANGUAGE=en:EST + TZNAME;LANGUAGE=fr-CA:HNE + +4.8.3.3 Time Zone Offset From + + Property Name: TZOFFSETFROM + + Purpose: This property specifies the offset which is in use prior to + this time zone observance. + + Value Type: UTC-OFFSET + + Property Parameters: Non-standard property parameters can be + specified on this property. + + + + + +Dawson & Stenerson Standards Track [Page 99] + +RFC 2445 iCalendar November 1998 + + + Conformance: This property MUST be specified in a "VTIMEZONE" + calendar component. + + Description: This property specifies the offset which is in use prior + to this time observance. It is used to calculate the absolute time at + which the transition to a given observance takes place. This property + MUST only be specified in a "VTIMEZONE" calendar component. A + "VTIMEZONE" calendar component MUST include this property. The + property value is a signed numeric indicating the number of hours and + possibly minutes from UTC. Positive numbers represent time zones east + of the prime meridian, or ahead of UTC. Negative numbers represent + time zones west of the prime meridian, or behind UTC. + + Format Definition: The property is defined by the following notation: + + tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset + CRLF + + frmparam = *(";" xparam) + + Example: The following are examples of this property: + + TZOFFSETFROM:-0500 + + TZOFFSETFROM:+1345 + +4.8.3.4 Time Zone Offset To + + Property Name: TZOFFSETTO + + Purpose: This property specifies the offset which is in use in this + time zone observance. + + Value Type: UTC-OFFSET + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be specified in a "VTIMEZONE" + calendar component. + + Description: This property specifies the offset which is in use in + this time zone observance. It is used to calculate the absolute time + for the new observance. The property value is a signed numeric + indicating the number of hours and possibly minutes from UTC. + Positive numbers represent time zones east of the prime meridian, or + ahead of UTC. Negative numbers represent time zones west of the prime + meridian, or behind UTC. + + + +Dawson & Stenerson Standards Track [Page 100] + +RFC 2445 iCalendar November 1998 + + + Format Definition: The property is defined by the following notation: + + tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF + + toparam = *(";" xparam) + + Example: The following are examples of this property: + + TZOFFSETTO:-0400 + + TZOFFSETTO:+1245 + +4.8.3.5 Time Zone URL + + Property Name: TZURL + + Purpose: The TZURL provides a means for a VTIMEZONE component to + point to a network location that can be used to retrieve an up-to- + date version of itself. + + Value Type: URI + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in a "VTIMEZONE" calendar + component. + + Description: The TZURL provides a means for a VTIMEZONE component to + point to a network location that can be used to retrieve an up-to- + date version of itself. This provides a hook to handle changes + government bodies impose upon time zone definitions. Retrieval of + this resource results in an iCalendar object containing a single + VTIMEZONE component and a METHOD property set to PUBLISH. + + Format Definition: The property is defined by the following notation: + + tzurl = "TZURL" tzurlparam ":" uri CRLF + + tzurlparam = *(";" xparam) + + Example: The following is an example of this property: + + TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles + + + + + + + +Dawson & Stenerson Standards Track [Page 101] + +RFC 2445 iCalendar November 1998 + + +4.8.4 Relationship Component Properties + + The following properties specify relationship information in calendar + components. + +4.8.4.1 Attendee + + Property Name: ATTENDEE + + Purpose: The property defines an "Attendee" within a calendar + component. + + Value Type: CAL-ADDRESS + + Property Parameters: Non-standard, language, calendar user type, + group or list membership, participation role, participation status, + RSVP expectation, delegatee, delegator, sent by, common name or + directory entry reference property parameters can be specified on + this property. + + Conformance: This property MUST be specified in an iCalendar object + that specifies a group scheduled calendar entity. This property MUST + NOT be specified in an iCalendar object when publishing the calendar + information (e.g., NOT in an iCalendar object that specifies the + publication of a calendar user's busy time, event, to-do or journal). + This property is not specified in an iCalendar object that specifies + only a time zone definition or that defines calendar entities that + are not group scheduled entities, but are entities only on a single + user's calendar. + + Description: The property MUST only be specified within calendar + components to specify participants, non-participants and the chair of + a group scheduled calendar entity. The property is specified within + an "EMAIL" category of the "VALARM" calendar component to specify an + email address that is to receive the email type of iCalendar alarm. + + The property parameter CN is for the common or displayable name + associated with the calendar address; ROLE, for the intended role + that the attendee will have in the calendar component; PARTSTAT, for + the status of the attendee's participation; RSVP, for indicating + whether the favor of a reply is requested; CUTYPE, to indicate the + type of calendar user; MEMBER, to indicate the groups that the + attendee belongs to; DELEGATED-TO, to indicate the calendar users + that the original request was delegated to; and DELEGATED-FROM, to + indicate whom the request was delegated from; SENT-BY, to indicate + whom is acting on behalf of the ATTENDEE; and DIR, to indicate the + URI that points to the directory information corresponding to the + attendee. These property parameters can be specified on an "ATTENDEE" + + + +Dawson & Stenerson Standards Track [Page 102] + +RFC 2445 iCalendar November 1998 + + + property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar + component. They MUST not be specified in an "ATTENDEE" property in a + "VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property + parameter is specified, the identified language applies to the CN + parameter. + + A recipient delegated a request MUST inherit the RSVP and ROLE values + from the attendee that delegated the request to them. + + Multiple attendees can be specified by including multiple "ATTENDEE" + properties within the calendar component. + + Format Definition: The property is defined by the following notation: + + attendee = "ATTENDEE" attparam ":" cal-address CRLF + + attparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" cutypeparam) / (";"memberparam) / + (";" roleparam) / (";" partstatparam) / + (";" rsvpparam) / (";" deltoparam) / + (";" delfromparam) / (";" sentbyparam) / + (";"cnparam) / (";" dirparam) / + (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following are examples of this property's use for a to- + do: + + ORGANIZER:MAILTO:jsmith@host1.com + ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com": + MAILTO:joecool@host2.com + ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com": + MAILTO:ildoit@host1.com + + The following is an example of this property used for specifying + multiple attendees to an event: + + + + + +Dawson & Stenerson Standards Track [Page 103] + +RFC 2445 iCalendar November 1998 + + + ORGANIZER:MAILTO:jsmith@host1.com + ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot + :MAILTO:hcabot@host2.com + ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com" + ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com + + The following is an example of this property with a URI to the + directory information associated with the attendee: + + ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC% + 20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@ + host1.com + + The following is an example of this property with "delegatee" and + "delegator" information for an event: + + ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com + ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= + "MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@ + host2.com + ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= + "MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss + @host2.com + ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe + :MAILTO:jdoe@host1.com + + Example: The following is an example of this property's use when + another calendar user is acting on behalf of the "Attendee": + + ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO: + jsmith@host1.com + +4.8.4.2 Contact + + Property Name: CONTACT + + Purpose: The property is used to represent contact information or + alternately a reference to contact information associated with the + calendar component. + + Value Type: TEXT + + Property Parameters: Non-standard, alternate text representation and + language property parameters can be specified on this property. + + Conformance: The property can be specified in a "VEVENT", "VTODO", + "VJOURNAL" or "VFREEBUSY" calendar component. + + + + +Dawson & Stenerson Standards Track [Page 104] + +RFC 2445 iCalendar November 1998 + + + Description: The property value consists of textual contact + information. An alternative representation for the property value can + also be specified that refers to a URI pointing to an alternate form, + such as a vCard [RFC 2426], for the contact information. + + Format Definition: The property is defined by the following notation: + + contact = "CONTACT" contparam ":" text CRLF + + contparam = *( + ; the following are optional, + ; but MUST NOT occur more than once + + (";" altrepparam) / (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following is an example of this property referencing + textual contact information: + + CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 + + The following is an example of this property with an alternate + representation of a LDAP URI to a directory entry containing the + contact information: + + CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\, + c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\, + +1-919-555-1234 + + The following is an example of this property with an alternate + representation of a MIME body part containing the contact + information, such as a vCard [RFC 2426] embedded in a [MIME-DIR] + content-type: + + CONTACT;ALTREP="CID=":Jim + Dolittle\, ABC Industries\, +1-919-555-1234 + + The following is an example of this property referencing a network + resource, such as a vCard [RFC 2426] object containing the contact + information: + + + + + +Dawson & Stenerson Standards Track [Page 105] + +RFC 2445 iCalendar November 1998 + + + CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim + Dolittle\, ABC Industries\, +1-919-555-1234 + +4.8.4.3 Organizer + + Property Name: ORGANIZER + + Purpose: The property defines the organizer for a calendar component. + + Value Type: CAL-ADDRESS + + Property Parameters: Non-standard, language, common name, directory + entry reference, sent by property parameters can be specified on this + property. + + Conformance: This property MUST be specified in an iCalendar object + that specifies a group scheduled calendar entity. This property MUST + be specified in an iCalendar object that specifies the publication of + a calendar user's busy time. This property MUST NOT be specified in + an iCalendar object that specifies only a time zone definition or + that defines calendar entities that are not group scheduled entities, + but are entities only on a single user's calendar. + + Description: The property is specified within the "VEVENT", "VTODO", + "VJOURNAL calendar components to specify the organizer of a group + scheduled calendar entity. The property is specified within the + "VFREEBUSY" calendar component to specify the calendar user + requesting the free or busy time. When publishing a "VFREEBUSY" + calendar component, the property is used to specify the calendar that + the published busy time came from. + + The property has the property parameters CN, for specifying the + common or display name associated with the "Organizer", DIR, for + specifying a pointer to the directory information associated with the + "Organizer", SENT-BY, for specifying another calendar user that is + acting on behalf of the "Organizer". The non-standard parameters may + also be specified on this property. If the LANGUAGE property + parameter is specified, the identified language applies to the CN + parameter value. + + Format Definition: The property is defined by the following notation: + + organizer = "ORGANIZER" orgparam ":" + cal-address CRLF + + orgparam = *( + + ; the following are optional, + + + +Dawson & Stenerson Standards Track [Page 106] + +RFC 2445 iCalendar November 1998 + + + ; but MUST NOT occur more than once + + (";" cnparam) / (";" dirparam) / (";" sentbyparam) / + (";" languageparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + Example: The following is an example of this property: + + ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com + + The following is an example of this property with a pointer to the + directory information associated with the organizer: + + ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ + ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com + + The following is an example of this property used by another calendar + user who is acting on behalf of the organizer, with responses + intended to be sent back to the organizer, not the other calendar + user: + + ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com": + MAILTO:jsmith@host1.com + +4.8.4.4 Recurrence ID + + Property Name: RECURRENCE-ID + + Purpose: This property is used in conjunction with the "UID" and + "SEQUENCE" property to identify a specific instance of a recurring + "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property + value is the effective value of the "DTSTART" property of the + recurrence instance. + + Value Type: The default value type for this property is DATE-TIME. + The time format can be any of the valid forms defined for a DATE-TIME + value type. See DATE-TIME value type definition for specific + interpretations of the various forms. The value type can be set to + DATE. + + + + + + +Dawson & Stenerson Standards Track [Page 107] + +RFC 2445 iCalendar November 1998 + + + Property Parameters: Non-standard property, value data type, time + zone identifier and recurrence identifier range parameters can be + specified on this property. + + Conformance: This property can be specified in an iCalendar object + containing a recurring calendar component. + + Description: The full range of calendar components specified by a + recurrence set is referenced by referring to just the "UID" property + value corresponding to the calendar component. The "RECURRENCE-ID" + property allows the reference to an individual instance within the + recurrence set. + + If the value of the "DTSTART" property is a DATE type value, then the + value MUST be the calendar date for the recurrence instance. + + The date/time value is set to the time when the original recurrence + instance would occur; meaning that if the intent is to change a + Friday meeting to Thursday, the date/time is still set to the + original Friday meeting. + + The "RECURRENCE-ID" property is used in conjunction with the "UID" + and "SEQUENCE" property to identify a particular instance of a + recurring event, to-do or journal. For a given pair of "UID" and + "SEQUENCE" property values, the "RECURRENCE-ID" value for a + recurrence instance is fixed. When the definition of the recurrence + set for a calendar component changes, and hence the "SEQUENCE" + property value changes, the "RECURRENCE-ID" for a given recurrence + instance might also change.The "RANGE" parameter is used to specify + the effective range of recurrence instances from the instance + specified by the "RECURRENCE-ID" property value. The default value + for the range parameter is the single recurrence instance only. The + value can also be "THISANDPRIOR" to indicate a range defined by the + given recurrence instance and all prior instances or the value can be + "THISANDFUTURE" to indicate a range defined by the given recurrence + instance and all subsequent instances. + + Format Definition: The property is defined by the following notation: + + recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF + + ridparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" ("DATE-TIME" / "DATE)) / + (";" tzidparam) / (";" rangeparam) / + + + +Dawson & Stenerson Standards Track [Page 108] + +RFC 2445 iCalendar November 1998 + + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + ridval = date-time / date + ;Value MUST match value type + + Example: The following are examples of this property: + + RECURRENCE-ID;VALUE=DATE:19960401 + + RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z + +4.8.4.5 Related To + + Property Name: RELATED-TO + + Purpose: The property is used to represent a relationship or + reference between one calendar component and another. + + Value Type: TEXT + + Property Parameters: Non-standard and relationship type property + parameters can be specified on this property. + + Conformance: The property can be specified one or more times in the + "VEVENT", "VTODO" or "VJOURNAL" calendar components. + + Description: The property value consists of the persistent, globally + unique identifier of another calendar component. This value would be + represented in a calendar component by the "UID" property. + + By default, the property value points to another calendar component + that has a PARENT relationship to the referencing object. The + "RELTYPE" property parameter is used to either explicitly state the + default PARENT relationship type to the referenced calendar component + or to override the default PARENT relationship type and specify + either a CHILD or SIBLING relationship. The PARENT relationship + indicates that the calendar component is a subordinate of the + referenced calendar component. The CHILD relationship indicates that + the calendar component is a superior of the referenced calendar + component. The SIBLING relationship indicates that the calendar + component is a peer of the referenced calendar component. + + + + + +Dawson & Stenerson Standards Track [Page 109] + +RFC 2445 iCalendar November 1998 + + + Changes to a calendar component referenced by this property can have + an implicit impact on the related calendar component. For example, if + a group event changes its start or end date or time, then the + related, dependent events will need to have their start and end dates + changed in a corresponding way. Similarly, if a PARENT calendar + component is canceled or deleted, then there is an implied impact to + the related CHILD calendar components. This property is intended only + to provide information on the relationship of calendar components. It + is up to the target calendar system to maintain any property + implications of this relationship. + + Format Definition: The property is defined by the following notation: + + related = "RELATED-TO" [relparam] ":" text CRLF + + relparam = *( + + ; the following is optional, + ; but MUST NOT occur more than once + + (";" reltypeparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparm) + + ) + + The following is an example of this property: + + RELATED-TO: + + RELATED-TO:<19960401-080045-4000F192713-0052@host1.com> + +4.8.4.6 Uniform Resource Locator + + Property Name: URL + + Purpose: This property defines a Uniform Resource Locator (URL) + associated with the iCalendar object. + + Value Type: URI + + Property Parameters: Non-standard property parameters can be + specified on this property. + + + + + +Dawson & Stenerson Standards Track [Page 110] + +RFC 2445 iCalendar November 1998 + + + Conformance: This property can be specified once in the "VEVENT", + "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. + + Description: This property may be used in a calendar component to + convey a location where a more dynamic rendition of the calendar + information associated with the calendar component can be found. This + memo does not attempt to standardize the form of the URI, nor the + format of the resource pointed to by the property value. If the URL + property and Content-Location MIME header are both specified, they + MUST point to the same resource. + + Format Definition: The property is defined by the following notation: + + url = "URL" urlparam ":" uri CRLF + + urlparam = *(";" xparam) + + Example: The following is an example of this property: + + URL:http://abc.com/pub/calendars/jsmith/mytime.ics + +4.8.4.7 Unique Identifier + + Property Name: UID + + Purpose: This property defines the persistent, globally unique + identifier for the calendar component. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property MUST be specified in the "VEVENT", "VTODO", + "VJOURNAL" or "VFREEBUSY" calendar components. + + Description: The UID itself MUST be a globally unique identifier. The + generator of the identifier MUST guarantee that the identifier is + unique. There are several algorithms that can be used to accomplish + this. The identifier is RECOMMENDED to be the identical syntax to the + [RFC 822] addr-spec. A good method to assure uniqueness is to put the + domain name or a domain literal IP address of the host on which the + identifier was created on the right hand side of the "@", and on the + left hand side, put a combination of the current calendar date and + time of day (i.e., formatted in as a DATE-TIME value) along with some + other currently unique (perhaps sequential) identifier available on + the system (for example, a process id number). Using a date/time + value on the left hand side and a domain name or domain literal on + + + +Dawson & Stenerson Standards Track [Page 111] + +RFC 2445 iCalendar November 1998 + + + the right hand side makes it possible to guarantee uniqueness since + no two hosts should be using the same domain name or IP address at + the same time. Though other algorithms will work, it is RECOMMENDED + that the right hand side contain some domain identifier (either of + the host itself or otherwise) such that the generator of the message + identifier can guarantee the uniqueness of the left hand side within + the scope of that domain. + + This is the method for correlating scheduling messages with the + referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. + + The full range of calendar components specified by a recurrence set + is referenced by referring to just the "UID" property value + corresponding to the calendar component. The "RECURRENCE-ID" property + allows the reference to an individual instance within the recurrence + set. + + This property is an important method for group scheduling + applications to match requests with later replies, modifications or + deletion requests. Calendaring and scheduling applications MUST + generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar + components to assure interoperability with other group scheduling + applications. This identifier is created by the calendar system that + generates an iCalendar object. + + Implementations MUST be able to receive and persist values of at + least 255 characters for this property. + + Format Definition: The property is defined by the following notation: + + uid = "UID" uidparam ":" text CRLF + + uidparam = *(";" xparam) + + Example: The following is an example of this property: + + UID:19960401T080045Z-4000F192713-0052@host1.com + +4.8.5 Recurrence Component Properties + + The following properties specify recurrence information in calendar + components. + +4.8.5.1 Exception Date/Times + + Property Name: EXDATE + + + + + +Dawson & Stenerson Standards Track [Page 112] + +RFC 2445 iCalendar November 1998 + + + Purpose: This property defines the list of date/time exceptions for a + recurring calendar component. + + Value Type: The default value type for this property is DATE-TIME. + The value type can be set to DATE. + + Property Parameters: Non-standard, value data type and time zone + identifier property parameters can be specified on this property. + + Conformance: This property can be specified in an iCalendar object + that includes a recurring calendar component. + + Description: The exception dates, if specified, are used in computing + the recurrence set. The recurrence set is the complete set of + recurrence instances for a calendar component. The recurrence set is + generated by considering the initial "DTSTART" property along with + the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained + within the iCalendar object. The "DTSTART" property defines the first + instance in the recurrence set. Multiple instances of the "RRULE" and + "EXRULE" properties can also be specified to define more + sophisticated recurrence sets. The final recurrence set is generated + by gathering all of the start date-times generated by any of the + specified "RRULE" and "RDATE" properties, and then excluding any + start date and times which fall within the union of start date and + times generated by any specified "EXRULE" and "EXDATE" properties. + This implies that start date and times within exclusion related + properties (i.e., "EXDATE" and "EXRULE") take precedence over those + specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where + duplicate instances are generated by the "RRULE" and "RDATE" + properties, only one recurrence is considered. Duplicate instances + are ignored. + + The "EXDATE" property can be used to exclude the value specified in + "DTSTART". However, in such cases the original "DTSTART" date MUST + still be maintained by the calendaring and scheduling system because + the original "DTSTART" value has inherent usage dependencies by other + properties such as the "RECURRENCE-ID". + + Format Definition: The property is defined by the following notation: + + exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF + + exdtparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / + + + +Dawson & Stenerson Standards Track [Page 113] + +RFC 2445 iCalendar November 1998 + + + (";" tzidparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + exdtval = date-time / date + ;Value MUST match value type + + Example: The following is an example of this property: + + EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z + +4.8.5.2 Exception Rule + + Property Name: EXRULE + + Purpose: This property defines a rule or repeating pattern for an + exception to a recurrence set. + + Value Type: RECUR + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in "VEVENT", "VTODO" or + "VJOURNAL" calendar components. + + Description: The exception rule, if specified, is used in computing + the recurrence set. The recurrence set is the complete set of + recurrence instances for a calendar component. The recurrence set is + generated by considering the initial "DTSTART" property along with + the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained + within the iCalendar object. The "DTSTART" defines the first instance + in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" + properties can also be specified to define more sophisticated + recurrence sets. The final recurrence set is generated by gathering + all of the start date-times generated by any of the specified "RRULE" + and "RDATE" properties, and excluding any start date and times which + fall within the union of start date and times generated by any + specified "EXRULE" and "EXDATE" properties. This implies that start + date and times within exclusion related properties (i.e., "EXDATE" + and "EXRULE") take precedence over those specified by inclusion + + + + + +Dawson & Stenerson Standards Track [Page 114] + +RFC 2445 iCalendar November 1998 + + + properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are + generated by the "RRULE" and "RDATE" properties, only one recurrence + is considered. Duplicate instances are ignored. + + The "EXRULE" property can be used to exclude the value specified in + "DTSTART". However, in such cases the original "DTSTART" date MUST + still be maintained by the calendaring and scheduling system because + the original "DTSTART" value has inherent usage dependencies by other + properties such as the "RECURRENCE-ID". + + Format Definition: The property is defined by the following notation: + + exrule = "EXRULE" exrparam ":" recur CRLF + + exrparam = *(";" xparam) + + Example: The following are examples of this property. Except every + other week, on Tuesday and Thursday for 4 occurrences: + + EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH + + Except daily for 10 occurrences: + + EXRULE:FREQ=DAILY;COUNT=10 + + Except yearly in June and July for 8 occurrences: + + EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7 + +4.8.5.3 Recurrence Date/Times + + Property Name: RDATE + + Purpose: This property defines the list of date/times for a + recurrence set. + + Value Type: The default value type for this property is DATE-TIME. + The value type can be set to DATE or PERIOD. + + Property Parameters: Non-standard, value data type and time zone + identifier property parameters can be specified on this property. + + Conformance: The property can be specified in "VEVENT", "VTODO", + "VJOURNAL" or "VTIMEZONE" calendar components. + + + + + + + +Dawson & Stenerson Standards Track [Page 115] + +RFC 2445 iCalendar November 1998 + + + Description: This property can appear along with the "RRULE" property + to define an aggregate set of repeating occurrences. When they both + appear in an iCalendar object, the recurring events are defined by + the union of occurrences defined by both the "RDATE" and "RRULE". + + The recurrence dates, if specified, are used in computing the + recurrence set. The recurrence set is the complete set of recurrence + instances for a calendar component. The recurrence set is generated + by considering the initial "DTSTART" property along with the "RRULE", + "RDATE", "EXDATE" and "EXRULE" properties contained within the + iCalendar object. The "DTSTART" property defines the first instance + in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" + properties can also be specified to define more sophisticated + recurrence sets. The final recurrence set is generated by gathering + all of the start date/times generated by any of the specified "RRULE" + and "RDATE" properties, and excluding any start date/times which fall + within the union of start date/times generated by any specified + "EXRULE" and "EXDATE" properties. This implies that start date/times + within exclusion related properties (i.e., "EXDATE" and "EXRULE") + take precedence over those specified by inclusion properties (i.e., + "RDATE" and "RRULE"). Where duplicate instances are generated by the + "RRULE" and "RDATE" properties, only one recurrence is considered. + Duplicate instances are ignored. + + Format Definition: The property is defined by the following notation: + + rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF + + rdtparam = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / + (";" tzidparam) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + rdtval = date-time / date / period + ;Value MUST match value type + + Example: The following are examples of this property: + + + + +Dawson & Stenerson Standards Track [Page 116] + +RFC 2445 iCalendar November 1998 + + + RDATE:19970714T123000Z + + RDATE;TZID=US-EASTERN:19970714T083000 + + RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, + 19960404T010000Z/PT3H + + RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 + 19970526,19970704,19970901,19971014,19971128,19971129,19971225 + +4.8.5.4 Recurrence Rule + + Property Name: RRULE + + Purpose: This property defines a rule or repeating pattern for + recurring events, to-dos, or time zone definitions. + + Value Type: RECUR + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified one or more times in + recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It + can also be specified once in each STANDARD or DAYLIGHT sub-component + of the "VTIMEZONE" calendar component. + + Description: The recurrence rule, if specified, is used in computing + the recurrence set. The recurrence set is the complete set of + recurrence instances for a calendar component. The recurrence set is + generated by considering the initial "DTSTART" property along with + the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained + within the iCalendar object. The "DTSTART" property defines the first + instance in the recurrence set. Multiple instances of the "RRULE" and + "EXRULE" properties can also be specified to define more + sophisticated recurrence sets. The final recurrence set is generated + by gathering all of the start date/times generated by any of the + specified "RRULE" and "RDATE" properties, and excluding any start + date/times which fall within the union of start date/times generated + by any specified "EXRULE" and "EXDATE" properties. This implies that + start date/times within exclusion related properties (i.e., "EXDATE" + and "EXRULE") take precedence over those specified by inclusion + properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are + generated by the "RRULE" and "RDATE" properties, only one recurrence + is considered. Duplicate instances are ignored. + + + + + + +Dawson & Stenerson Standards Track [Page 117] + +RFC 2445 iCalendar November 1998 + + + The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" + property pair, specified within the iCalendar object defines the + first instance of the recurrence. When used with a recurrence rule, + the "DTSTART" and "DTEND" properties MUST be specified in local time + and the appropriate set of "VTIMEZONE" calendar components MUST be + included. For detail on the usage of the "VTIMEZONE" calendar + component, see the "VTIMEZONE" calendar component definition. + + Any duration associated with the iCalendar object applies to all + members of the generated recurrence set. Any modified duration for + specific recurrences MUST be explicitly specified using the "RDATE" + property. + + Format Definition: This property is defined by the following + notation: + + rrule = "RRULE" rrulparam ":" recur CRLF + + rrulparam = *(";" xparam) + + Example: All examples assume the Eastern United States time zone. + + Daily for 10 occurrences: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=DAILY;COUNT=10 + + ==> (1997 9:00 AM EDT)September 2-11 + + Daily until December 24, 1997: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=DAILY;UNTIL=19971224T000000Z + + ==> (1997 9:00 AM EDT)September 2-30;October 1-25 + (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23 + + Every other day - forever: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=DAILY;INTERVAL=2 + ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; + October 2,4,6...20,22,24 + (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29; + Dec 1,3,... + + Every 10 days, 5 occurrences: + + + + +Dawson & Stenerson Standards Track [Page 118] + +RFC 2445 iCalendar November 1998 + + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 + + ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12 + + Everyday in January, for 3 years: + + DTSTART;TZID=US-Eastern:19980101T090000 + RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; + BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA + or + RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 + + ==> (1998 9:00 AM EDT)January 1-31 + (1999 9:00 AM EDT)January 1-31 + (2000 9:00 AM EDT)January 1-31 + + Weekly for 10 occurrences + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=WEEKLY;COUNT=10 + + ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 + (1997 9:00 AM EST)October 28;November 4 + + Weekly until December 24, 1997 + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z + + ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 + (1997 9:00 AM EST)October 28;November 4,11,18,25; + December 2,9,16,23 + Every other week - forever: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU + + ==> (1997 9:00 AM EDT)September 2,16,30;October 14 + (1997 9:00 AM EST)October 28;November 11,25;December 9,23 + (1998 9:00 AM EST)January 6,20;February + ... + + Weekly on Tuesday and Thursday for 5 weeks: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH + or + + + +Dawson & Stenerson Standards Track [Page 119] + +RFC 2445 iCalendar November 1998 + + + RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH + + ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2 + + Every other week on Monday, Wednesday and Friday until December 24, + 1997, but starting on Tuesday, September 2, 1997: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; + BYDAY=MO,WE,FR + ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October + 1,3,13,15,17 + (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28; + December 8,10,12,22 + + Every other week on Tuesday and Thursday, for 8 occurrences: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH + + ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16 + + Monthly on the 1st Friday for ten occurrences: + + DTSTART;TZID=US-Eastern:19970905T090000 + RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR + + ==> (1997 9:00 AM EDT)September 5;October 3 + (1997 9:00 AM EST)November 7;Dec 5 + (1998 9:00 AM EST)January 2;February 6;March 6;April 3 + (1998 9:00 AM EDT)May 1;June 5 + + Monthly on the 1st Friday until December 24, 1997: + + DTSTART;TZID=US-Eastern:19970905T090000 + RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR + + ==> (1997 9:00 AM EDT)September 5;October 3 + (1997 9:00 AM EST)November 7;December 5 + + Every other month on the 1st and last Sunday of the month for 10 + occurrences: + + DTSTART;TZID=US-Eastern:19970907T090000 + RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU + + ==> (1997 9:00 AM EDT)September 7,28 + (1997 9:00 AM EST)November 2,30 + + + +Dawson & Stenerson Standards Track [Page 120] + +RFC 2445 iCalendar November 1998 + + + (1998 9:00 AM EST)January 4,25;March 1,29 + (1998 9:00 AM EDT)May 3,31 + + Monthly on the second to last Monday of the month for 6 months: + + DTSTART;TZID=US-Eastern:19970922T090000 + RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO + + ==> (1997 9:00 AM EDT)September 22;October 20 + (1997 9:00 AM EST)November 17;December 22 + (1998 9:00 AM EST)January 19;February 16 + + Monthly on the third to the last day of the month, forever: + + DTSTART;TZID=US-Eastern:19970928T090000 + RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 + + ==> (1997 9:00 AM EDT)September 28 + (1997 9:00 AM EST)October 29;November 28;December 29 + (1998 9:00 AM EST)January 29;February 26 + ... + + Monthly on the 2nd and 15th of the month for 10 occurrences: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 + + ==> (1997 9:00 AM EDT)September 2,15;October 2,15 + (1997 9:00 AM EST)November 2,15;December 2,15 + (1998 9:00 AM EST)January 2,15 + + Monthly on the first and last day of the month for 10 occurrences: + + DTSTART;TZID=US-Eastern:19970930T090000 + RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 + + ==> (1997 9:00 AM EDT)September 30;October 1 + (1997 9:00 AM EST)October 31;November 1,30;December 1,31 + (1998 9:00 AM EST)January 1,31;February 1 + + Every 18 months on the 10th thru 15th of the month for 10 + occurrences: + + DTSTART;TZID=US-Eastern:19970910T090000 + RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, + 15 + + ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15 + + + +Dawson & Stenerson Standards Track [Page 121] + +RFC 2445 iCalendar November 1998 + + + (1999 9:00 AM EST)March 10,11,12,13 + + Every Tuesday, every other month: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU + + ==> (1997 9:00 AM EDT)September 2,9,16,23,30 + (1997 9:00 AM EST)November 4,11,18,25 + (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31 + ... + + Yearly in June and July for 10 occurrences: + + DTSTART;TZID=US-Eastern:19970610T090000 + RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 + ==> (1997 9:00 AM EDT)June 10;July 10 + (1998 9:00 AM EDT)June 10;July 10 + (1999 9:00 AM EDT)June 10;July 10 + (2000 9:00 AM EDT)June 10;July 10 + (2001 9:00 AM EDT)June 10;July 10 + Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components + are specified, the day is gotten from DTSTART + + Every other year on January, February, and March for 10 occurrences: + + DTSTART;TZID=US-Eastern:19970310T090000 + RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 + + ==> (1997 9:00 AM EST)March 10 + (1999 9:00 AM EST)January 10;February 10;March 10 + (2001 9:00 AM EST)January 10;February 10;March 10 + (2003 9:00 AM EST)January 10;February 10;March 10 + + Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: + + DTSTART;TZID=US-Eastern:19970101T090000 + RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 + + ==> (1997 9:00 AM EST)January 1 + (1997 9:00 AM EDT)April 10;July 19 + (2000 9:00 AM EST)January 1 + (2000 9:00 AM EDT)April 9;July 18 + (2003 9:00 AM EST)January 1 + (2003 9:00 AM EDT)April 10;July 19 + (2006 9:00 AM EST)January 1 + + Every 20th Monday of the year, forever: + + + +Dawson & Stenerson Standards Track [Page 122] + +RFC 2445 iCalendar November 1998 + + + DTSTART;TZID=US-Eastern:19970519T090000 + RRULE:FREQ=YEARLY;BYDAY=20MO + + ==> (1997 9:00 AM EDT)May 19 + (1998 9:00 AM EDT)May 18 + (1999 9:00 AM EDT)May 17 + ... + + Monday of week number 20 (where the default start of the week is + Monday), forever: + + DTSTART;TZID=US-Eastern:19970512T090000 + RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO + + ==> (1997 9:00 AM EDT)May 12 + (1998 9:00 AM EDT)May 11 + (1999 9:00 AM EDT)May 17 + ... + + Every Thursday in March, forever: + + DTSTART;TZID=US-Eastern:19970313T090000 + RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH + + ==> (1997 9:00 AM EST)March 13,20,27 + (1998 9:00 AM EST)March 5,12,19,26 + (1999 9:00 AM EST)March 4,11,18,25 + ... + + Every Thursday, but only during June, July, and August, forever: + + DTSTART;TZID=US-Eastern:19970605T090000 + RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 + + ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; + August 7,14,21,28 + (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30; + August 6,13,20,27 + (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29; + August 5,12,19,26 + ... + + Every Friday the 13th, forever: + + DTSTART;TZID=US-Eastern:19970902T090000 + EXDATE;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 + + + + +Dawson & Stenerson Standards Track [Page 123] + +RFC 2445 iCalendar November 1998 + + + ==> (1998 9:00 AM EST)February 13;March 13;November 13 + (1999 9:00 AM EDT)August 13 + (2000 9:00 AM EDT)October 13 + ... + + The first Saturday that follows the first Sunday of the month, + forever: + + DTSTART;TZID=US-Eastern:19970913T090000 + RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 + + ==> (1997 9:00 AM EDT)September 13;October 11 + (1997 9:00 AM EST)November 8;December 13 + (1998 9:00 AM EST)January 10;February 7;March 7 + (1998 9:00 AM EDT)April 11;May 9;June 13... + ... + + Every four years, the first Tuesday after a Monday in November, + forever (U.S. Presidential Election day): + + DTSTART;TZID=US-Eastern:19961105T090000 + RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, + 5,6,7,8 + + ==> (1996 9:00 AM EST)November 5 + (2000 9:00 AM EST)November 7 + (2004 9:00 AM EST)November 2 + ... + + The 3rd instance into the month of one of Tuesday, Wednesday or + Thursday, for the next 3 months: + + DTSTART;TZID=US-Eastern:19970904T090000 + RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 + + ==> (1997 9:00 AM EDT)September 4;October 7 + (1997 9:00 AM EST)November 6 + + The 2nd to last weekday of the month: + + DTSTART;TZID=US-Eastern:19970929T090000 + RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 + + ==> (1997 9:00 AM EDT)September 29 + (1997 9:00 AM EST)October 30;November 27;December 30 + (1998 9:00 AM EST)January 29;February 26;March 30 + ... + + + + +Dawson & Stenerson Standards Track [Page 124] + +RFC 2445 iCalendar November 1998 + + + Every 3 hours from 9:00 AM to 5:00 PM on a specific day: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z + + ==> (September 2, 1997 EDT)09:00,12:00,15:00 + + Every 15 minutes for 6 occurrences: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 + + ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 + + Every hour and a half for 4 occurrences: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 + + ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 + + Every 20 minutes from 9:00 AM to 4:40 PM every day: + + DTSTART;TZID=US-Eastern:19970902T090000 + RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 + or + RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 + + ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20, + ... 16:00,16:20,16:40 + (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20, + ...16:00,16:20,16:40 + ... + + An example where the days generated makes a difference because of + WKST: + + DTSTART;TZID=US-Eastern:19970805T090000 + RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO + + ==> (1997 EDT)Aug 5,10,19,24 + + changing only WKST from MO to SU, yields different results... + + DTSTART;TZID=US-Eastern:19970805T090000 + RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU + ==> (1997 EDT)August 5,17,19,31 + + + + +Dawson & Stenerson Standards Track [Page 125] + +RFC 2445 iCalendar November 1998 + + +4.8.6 Alarm Component Properties + + The following properties specify alarm information in calendar + components. + +4.8.6.1 Action + + Property Name: ACTION + + Purpose: This property defines the action to be invoked when an alarm + is triggered. + + Value Type: TEXT + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be specified once in a "VALARM" + calendar component. + + Description: Each "VALARM" calendar component has a particular type + of action associated with it. This property specifies the type of + action + + Format Definition: The property is defined by the following notation: + + action = "ACTION" actionparam ":" actionvalue CRLF + + actionparam = *(";" xparam) + + actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" + / iana-token / x-name + + Example: The following are examples of this property in a "VALARM" + calendar component: + + ACTION:AUDIO + + ACTION:DISPLAY + + ACTION:PROCEDURE + +4.8.6.2 Repeat Count + + Property Name: REPEAT + + Purpose: This property defines the number of time the alarm should be + repeated, after the initial trigger. + + + +Dawson & Stenerson Standards Track [Page 126] + +RFC 2445 iCalendar November 1998 + + + Value Type: INTEGER + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in a "VALARM" calendar + component. + + Description: If the alarm triggers more than once, then this property + MUST be specified along with the "DURATION" property. + + Format Definition: The property is defined by the following notation: + + repeatcnt = "REPEAT" repparam ":" integer CRLF + ;Default is "0", zero. + + repparam = *(";" xparam) + + Example: The following is an example of this property for an alarm + that repeats 4 additional times with a 5 minute delay after the + initial triggering of the alarm: + + REPEAT:4 + DURATION:PT5M + +4.8.6.3 Trigger + + Property Name: TRIGGER + + Purpose: This property specifies when an alarm will trigger. + + Value Type: The default value type is DURATION. The value type can be + set to a DATE-TIME value type, in which case the value MUST specify a + UTC formatted DATE-TIME value. + + Property Parameters: Non-standard, value data type, time zone + identifier or trigger relationship property parameters can be + specified on this property. The trigger relationship property + parameter MUST only be specified when the value type is DURATION. + + Conformance: This property MUST be specified in the "VALARM" calendar + component. + + Description: Within the "VALARM" calendar component, this property + defines when the alarm will trigger. The default value type is + DURATION, specifying a relative time for the trigger of the alarm. + The default duration is relative to the start of an event or to-do + that the alarm is associated with. The duration can be explicitly set + + + +Dawson & Stenerson Standards Track [Page 127] + +RFC 2445 iCalendar November 1998 + + + to trigger from either the end or the start of the associated event + or to-do with the "RELATED" parameter. A value of START will set the + alarm to trigger off the start of the associated event or to-do. A + value of END will set the alarm to trigger off the end of the + associated event or to-do. + + Either a positive or negative duration may be specified for the + "TRIGGER" property. An alarm with a positive duration is triggered + after the associated start or end of the event or to-do. An alarm + with a negative duration is triggered before the associated start or + end of the event or to-do. + + The "RELATED" property parameter is not valid if the value type of + the property is set to DATE-TIME (i.e., for an absolute date and time + alarm trigger). If a value type of DATE-TIME is specified, then the + property value MUST be specified in the UTC time format. If an + absolute trigger is specified on an alarm for a recurring event or + to-do, then the alarm will only trigger for the specified absolute + date/time, along with any specified repeating instances. + + If the trigger is set relative to START, then the "DTSTART" property + MUST be present in the associated "VEVENT" or "VTODO" calendar + component. If an alarm is specified for an event with the trigger set + relative to the END, then the "DTEND" property or the "DSTART" and + "DURATION' properties MUST be present in the associated "VEVENT" + calendar component. If the alarm is specified for a to-do with a + trigger set relative to the END, then either the "DUE" property or + the "DSTART" and "DURATION' properties MUST be present in the + associated "VTODO" calendar component. + + Alarms specified in an event or to-do which is defined in terms of a + DATE value type will be triggered relative to 00:00:00 UTC on the + specified date. For example, if "DTSTART:19980205, then the duration + trigger will be relative to19980205T000000Z. + + Format Definition: The property is defined by the following notation: + + trigger = "TRIGGER" (trigrel / trigabs) + + trigrel = *( + + ; the following are optional, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" "DURATION") / + (";" trigrelparam) / + + ; the following is optional, + + + +Dawson & Stenerson Standards Track [Page 128] + +RFC 2445 iCalendar November 1998 + + + ; and MAY occur more than once + + (";" xparam) + ) ":" dur-value + + trigabs = 1*( + + ; the following is REQUIRED, + ; but MUST NOT occur more than once + + (";" "VALUE" "=" "DATE-TIME") / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) ":" date-time + + Example: A trigger set 15 minutes prior to the start of the event or + to-do. + + TRIGGER:-P15M + + A trigger set 5 minutes after the end of the event or to-do. + + TRIGGER;RELATED=END:P5M + + A trigger set to an absolute date/time. + + TRIGGER;VALUE=DATE-TIME:19980101T050000Z + +4.8.7 Change Management Component Properties + + The following properties specify change management information in + calendar components. + +4.8.7.1 Date/Time Created + + Property Name: CREATED + + Purpose: This property specifies the date and time that the calendar + information was created by the calendar user agent in the calendar + store. + + Note: This is analogous to the creation date and time for a file + in the file system. + + + + +Dawson & Stenerson Standards Track [Page 129] + +RFC 2445 iCalendar November 1998 + + + Value Type: DATE-TIME + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified once in "VEVENT", "VTODO" + or "VJOURNAL" calendar components. + + Description: The date and time is a UTC value. + + Format Definition: The property is defined by the following notation: + + created = "CREATED" creaparam ":" date-time CRLF + + creaparam = *(";" xparam) + + Example: The following is an example of this property: + + CREATED:19960329T133000Z + +4.8.7.2 Date/Time Stamp + + Property Name: DTSTAMP + + Purpose: The property indicates the date/time that the instance of + the iCalendar object was created. + + Value Type: DATE-TIME + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property MUST be included in the "VEVENT", "VTODO", + "VJOURNAL" or "VFREEBUSY" calendar components. + + Description: The value MUST be specified in the UTC time format. + + This property is also useful to protocols such as [IMIP] that have + inherent latency issues with the delivery of content. This property + will assist in the proper sequencing of messages containing iCalendar + objects. + + This property is different than the "CREATED" and "LAST-MODIFIED" + properties. These two properties are used to specify when the + particular calendar data in the calendar store was created and last + modified. This is different than when the iCalendar object + representation of the calendar service information was created or + last modified. + + + +Dawson & Stenerson Standards Track [Page 130] + +RFC 2445 iCalendar November 1998 + + + Format Definition: The property is defined by the following notation: + + dtstamp = "DTSTAMP" stmparam ":" date-time CRLF + + stmparam = *(";" xparam) + + Example: + + DTSTAMP:19971210T080000Z + +4.8.7.3 Last Modified + + Property Name: LAST-MODIFIED + + Purpose: The property specifies the date and time that the + information associated with the calendar component was last revised + in the calendar store. + + Note: This is analogous to the modification date and time for a + file in the file system. + + Value Type: DATE-TIME + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: This property can be specified in the "EVENT", "VTODO", + "VJOURNAL" or "VTIMEZONE" calendar components. + + Description: The property value MUST be specified in the UTC time + format. + + Format Definition: The property is defined by the following notation: + + last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF + + lstparam = *(";" xparam) + + Example: The following is are examples of this property: + + LAST-MODIFIED:19960817T133000Z + +4.8.7.4 Sequence Number + + Property Name: SEQUENCE + + Purpose: This property defines the revision sequence number of the + calendar component within a sequence of revisions. + + + +Dawson & Stenerson Standards Track [Page 131] + +RFC 2445 iCalendar November 1998 + + + Value Type: integer + + Property Parameters: Non-standard property parameters can be + specified on this property. + + Conformance: The property can be specified in "VEVENT", "VTODO" or + "VJOURNAL" calendar component. + + Description: When a calendar component is created, its sequence + number is zero (US-ASCII decimal 48). It is monotonically incremented + by the "Organizer's" CUA each time the "Organizer" makes a + significant revision to the calendar component. When the "Organizer" + makes changes to one of the following properties, the sequence number + MUST be incremented: + + . "DTSTART" + + . "DTEND" + + . "DUE" + + . "RDATE" + + . "RRULE" + + . "EXDATE" + + . "EXRULE" + + . "STATUS" + + In addition, changes made by the "Organizer" to other properties can + also force the sequence number to be incremented. The "Organizer" CUA + MUST increment the sequence number when ever it makes changes to + properties in the calendar component that the "Organizer" deems will + jeopardize the validity of the participation status of the + "Attendees". For example, changing the location of a meeting from one + locale to another distant locale could effectively impact the + participation status of the "Attendees". + + The "Organizer" includes this property in an iCalendar object that it + sends to an "Attendee" to specify the current version of the calendar + component. + + The "Attendee" includes this property in an iCalendar object that it + sends to the "Organizer" to specify the version of the calendar + component that the "Attendee" is referring to. + + + + +Dawson & Stenerson Standards Track [Page 132] + +RFC 2445 iCalendar November 1998 + + + A change to the sequence number is not the mechanism that an + "Organizer" uses to request a response from the "Attendees". The + "RSVP" parameter on the "ATTENDEE" property is used by the + "Organizer" to indicate that a response from the "Attendees" is + requested. + + Format Definition: This property is defined by the following + notation: + + seq = "SEQUENCE" seqparam ":" integer CRLF + ; Default is "0" + + seqparam = *(";" xparam) + + Example: The following is an example of this property for a calendar + component that was just created by the "Organizer". + + SEQUENCE:0 + + The following is an example of this property for a calendar component + that has been revised two different times by the "Organizer". + + SEQUENCE:2 + +4.8.8 Miscellaneous Component Properties + + The following properties specify information about a number of + miscellaneous features of calendar components. + +4.8.8.1 Non-standard Properties + + Property Name: Any property name with a "X-" prefix + + Purpose: This class of property provides a framework for defining + non-standard properties. + + Value Type: TEXT + + Property Parameters: Non-standard and language property parameters + can be specified on this property. + + Conformance: This property can be specified in any calendar + component. + + Description: The MIME Calendaring and Scheduling Content Type + provides a "standard mechanism for doing non-standard things". This + extension support is provided for implementers to "push the envelope" + on the existing version of the memo. Extension properties are + + + +Dawson & Stenerson Standards Track [Page 133] + +RFC 2445 iCalendar November 1998 + + + specified by property and/or property parameter names that have the + prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER + X character followed by the HYPEN-MINUS character). It is recommended + that vendors concatenate onto this sentinel another short prefix text + to identify the vendor. This will facilitate readability of the + extensions and minimize possible collision of names between different + vendors. User agents that support this content type are expected to + be able to parse the extension properties and property parameters but + can ignore them. + + At present, there is no registration authority for names of extension + properties and property parameters. The data type for this property + is TEXT. Optionally, the data type can be any of the other valid data + types. + + Format Definition: The property is defined by the following notation: + + x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF + ; Lines longer than 75 octets should be folded + + Example: The following might be the ABC vendor's extension for an + audio-clip form of subject property: + + X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav + +4.8.8.2 Request Status + + Property Name: REQUEST-STATUS + + Purpose: This property defines the status code returned for a + scheduling request. + + Value Type: TEXT + + Property Parameters: Non-standard and language property parameters + can be specified on this property. + + Conformance: The property can be specified in "VEVENT", "VTODO", + "VJOURNAL" or "VFREEBUSY" calendar component. + + Description: This property is used to return status code information + related to the processing of an associated iCalendar object. The data + type for this property is TEXT. + + The value consists of a short return status component, a longer + return status description component, and optionally a status-specific + data component. The components of the value are separated by the + SEMICOLON character (US-ASCII decimal 59). + + + +Dawson & Stenerson Standards Track [Page 134] + +RFC 2445 iCalendar November 1998 + + + The short return status is a PERIOD character (US-ASCII decimal 46) + separated 3-tuple of integers. For example, "3.1.1". The successive + levels of integers provide for a successive level of status code + granularity. + + The following are initial classes for the return status code. + Individual iCalendar object methods will define specific return + status codes for these classes. In addition, other classes for the + return status code may be defined using the registration process + defined later in this memo. + + |==============+===============================================| + | Short Return | Longer Return Status Description | + | Status Code | | + |==============+===============================================| + | 1.xx | Preliminary success. This class of status | + | | of status code indicates that the request has | + | | request has been initially processed but that | + | | completion is pending. | + |==============+===============================================| + | 2.xx | Successful. This class of status code | + | | indicates that the request was completed | + | | successfuly. However, the exact status code | + | | can indicate that a fallback has been taken. | + |==============+===============================================| + | 3.xx | Client Error. This class of status code | + | | indicates that the request was not successful.| + | | The error is the result of either a syntax or | + | | a semantic error in the client formatted | + | | request. Request should not be retried until | + | | the condition in the request is corrected. | + |==============+===============================================| + | 4.xx | Scheduling Error. This class of status code | + | | indicates that the request was not successful.| + | | Some sort of error occurred within the | + | | calendaring and scheduling service, not | + | | directly related to the request itself. | + |==============+===============================================| + + Format Definition: The property is defined by the following notation: + + rstatus = "REQUEST-STATUS" rstatparam ":" + statcode ";" statdesc [";" extdata] + + rstatparam = *( + + ; the following is optional, + ; but MUST NOT occur more than once + + + +Dawson & Stenerson Standards Track [Page 135] + +RFC 2445 iCalendar November 1998 + + + (";" languageparm) / + + ; the following is optional, + ; and MAY occur more than once + + (";" xparam) + + ) + + statcode = 1*DIGIT *("." 1*DIGIT) + ;Hierarchical, numeric return status code + + statdesc = text + ;Textual status description + + extdata = text + ;Textual exception data. For example, the offending property + ;name and value or complete property line. + + Example: The following are some possible examples of this property. + The COMMA and SEMICOLON separator characters in the property value + are BACKSLASH character escaped because they appear in a text value. + + REQUEST-STATUS:2.0;Success + + REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 + + REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled + as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 + + REQUEST-STATUS:4.1;Event conflict. Date/time is busy. + + REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: + MAILTO:jsmith@host.com + +5 iCalendar Object Examples + + The following examples are provided as an informational source of + illustrative iCalendar objects consistent with this content type. + + The following example specifies a three-day conference that begins at + 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, + 1996. + + BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson + 1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z + UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com + DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED + + + +Dawson & Stenerson Standards Track [Page 136] + +RFC 2445 iCalendar November 1998 + + + CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference + DESCRIPTION:Networld+Interop Conference + and Exhibit\nAtlanta World Congress Center\n + Atlanta, Georgia END:VEVENT END:VCALENDAR + + The following example specifies a group scheduled meeting that begin + at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, + 1998. The "Organizer" has scheduled the meeting with one or more + calendar users in a group. A time zone specification for Eastern + United States has been specified. + + BEGIN:VCALENDAR + PRODID:-//RDU Software//NONSGML HandCal//EN + VERSION:2.0 + BEGIN:VTIMEZONE + TZID:US-Eastern + BEGIN:STANDARD + DTSTART:19981025T020000 + RDATE:19981025T020000 + TZOFFSETFROM:-0400 + TZOFFSETTO:-0500 + TZNAME:EST + END:STANDARD + BEGIN:DAYLIGHT + DTSTART:19990404T020000 + RDATE:19990404T020000 + TZOFFSETFROM:-0500 + TZOFFSETTO:-0400 + TZNAME:EDT + END:DAYLIGHT + END:VTIMEZONE + BEGIN:VEVENT + DTSTAMP:19980309T231000Z + UID:guid-1.host1.com + ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com + ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: + MAILTO:employee-A@host.com + DESCRIPTION:Project XYZ Review Meeting + CATEGORIES:MEETING + CLASS:PUBLIC + CREATED:19980309T130000Z + SUMMARY:XYZ Project Review + DTSTART;TZID=US-Eastern:19980312T083000 + DTEND;TZID=US-Eastern:19980312T093000 + LOCATION:1CP Conference Room 4350 + END:VEVENT + END:VCALENDAR + + + + +Dawson & Stenerson Standards Track [Page 137] + +RFC 2445 iCalendar November 1998 + + + The following is an example of an iCalendar object passed in a MIME + message with a single body part consisting of a "text/calendar" + Content Type. + + TO:jsmith@host1.com + FROM:jdoe@host1.com + MIME-VERSION:1.0 + MESSAGE-ID: + CONTENT-TYPE:text/calendar + + BEGIN:VCALENDAR + METHOD:xyz + VERSION:2.0 + PRODID:-//ABC Corporation//NONSGML My Product//EN + BEGIN:VEVENT + DTSTAMP:19970324T1200Z + SEQUENCE:0 + UID:uid3@host1.com + ORGANIZER:MAILTO:jdoe@host1.com + ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com + DTSTART:19970324T123000Z + DTEND:19970324T210000Z + CATEGORIES:MEETING,PROJECT + CLASS:PUBLIC + SUMMARY:Calendaring Interoperability Planning Meeting + DESCRIPTION:Discuss how we can test c&s interoperability\n + using iCalendar and other IETF standards. + LOCATION:LDB Lobby + ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ + conf/bkgrnd.ps + END:VEVENT + END:VCALENDAR + + The following is an example of a to-do due on April 15, 1998. An + audio alarm has been specified to remind the calendar user at noon, + the day before the to-do is expected to be completed and repeat + hourly, four additional times. The to-do definition has been modified + twice since it was initially created. + + BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//ABC Corporation//NONSGML My Product//EN + BEGIN:VTODO + DTSTAMP:19980130T134500Z + SEQUENCE:2 + UID:uid4@host1.com + ORGANIZER:MAILTO:unclesam@us.gov + ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com + + + +Dawson & Stenerson Standards Track [Page 138] + +RFC 2445 iCalendar November 1998 + + + DUE:19980415T235959 + STATUS:NEEDS-ACTION + SUMMARY:Submit Income Taxes + BEGIN:VALARM + ACTION:AUDIO + TRIGGER:19980403T120000 + ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio- + files/ssbanner.aud + REPEAT:4 + DURATION:PT1H + END:VALARM + END:VTODO + END:VCALENDAR + + The following is an example of a journal entry. + + BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//ABC Corporation//NONSGML My Product//EN + BEGIN:VJOURNAL + DTSTAMP:19970324T120000Z + UID:uid5@host1.com + ORGANIZER:MAILTO:jsmith@host.com + STATUS:DRAFT + CLASS:PUBLIC + CATEGORY:Project Report, XYZ, Weekly Meeting + DESCRIPTION:Project xyz Review Meeting Minutes\n + Agenda\n1. Review of project version 1.0 requirements.\n2. + Definition + of project processes.\n3. Review of project schedule.\n + Participants: John Smith, Jane Doe, Jim Dandy\n-It was + decided that the requirements need to be signed off by + product marketing.\n-Project processes were accepted.\n + -Project schedule needs to account for scheduled holidays + and employee vacation time. Check with HR for specific + dates.\n-New schedule will be distributed by Friday.\n- + Next weeks meeting is cancelled. No meeting until 3/23. + END:VJOURNAL + END:VCALENDAR + + The following is an example of published busy time information. The + iCalendar object might be placed in the network resource + www.host.com/calendar/busytime/jsmith.ifb. + + BEGIN:VCALENDAR + VERSION:2.0 + PRODID:-//RDU Software//NONSGML HandCal//EN + BEGIN:VFREEBUSY + + + +Dawson & Stenerson Standards Track [Page 139] + +RFC 2445 iCalendar November 1998 + + + ORGANIZER:MAILTO:jsmith@host.com + DTSTART:19980313T141711Z + DTEND:19980410T141711Z + FREEBUSY:19980314T233000Z/19980315T003000Z + FREEBUSY:19980316T153000Z/19980316T163000Z + FREEBUSY:19980318T030000Z/19980318T040000Z + URL:http://www.host.com/calendar/busytime/jsmith.ifb + END:VFREEBUSY + END:VCALENDAR + +6 Recommended Practices + + These recommended practices should be followed in order to assure + consistent handling of the following cases for an iCalendar object. + + 1. Content lines longer than 75 octets SHOULD be folded. + + 2. A calendar entry with a "DTSTART" property but no "DTEND" + property does not take up any time. It is intended to represent + an event that is associated with a given calendar date and time + of day, such as an anniversary. Since the event does not take up + any time, it MUST NOT be used to record busy time no matter what + the value for the "TRANSP" property. + + 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and + "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for + "VTODO" calendar components, have the same value data type (e.g., + DATE-TIME), they SHOULD specify values in the same time format + (e.g., UTC time format). + + 4. When the combination of the "RRULE" and "RDATE" properties on an + iCalendar object produces multiple instances having the same + start date/time, they should be collapsed to, and considered as, + a single instance. + + 5. When a calendar user receives multiple requests for the same + calendar component (e.g., REQUEST for a "VEVENT" calendar + component) as a result of being on multiple mailing lists + specified by "ATTENDEE" properties in the request, they SHOULD + respond to only one of the requests. The calendar user SHOULD + also specify (using the "MEMBER" parameter of the "ATTENDEE" + property) which mailing list they are a member of. + + 6. An implementation can truncate a "SUMMARY" property value to 255 + characters. + + + + + + +Dawson & Stenerson Standards Track [Page 140] + +RFC 2445 iCalendar November 1998 + + + 7. If seconds of the minute are not supported by an implementation, + then a value of "00" SHOULD be specified for the seconds + component in a time value. + + 8. If the value type parameter (VALUE=) contains an unknown value + type, it SHOULD be treated as TEXT. + + 9. TZURL values SHOULD NOT be specified as a FILE URI type. This URI + form can be useful within an organization, but is problematic in + the Internet. + + 10. Some possible English values for CATEGORIES property include + "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", + "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT + IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL + OCCASION", "TRAVEL", "VACATION". Categories can be specified in + any registered language. + + 11. Some possible English values for RESOURCES property include + "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD + PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO + PHONE", "VEHICLE". Resources can be specified in any registered + language. + +7 Registration of Content Type Elements + + This section provides the process for registration of MIME + Calendaring and Scheduling Content Type iCalendar object methods and + new or modified properties. + +7.1 Registration of New and Modified iCalendar Object Methods + + New MIME Calendaring and Scheduling Content Type iCalendar object + methods are registered by the publication of an IETF Request for + Comments (RFC). Changes to an iCalendar object method are registered + by the publication of a revision of the RFC defining the method. + +7.2 Registration of New Properties + + This section defines procedures by which new properties or enumerated + property values for the MIME Calendaring and Scheduling Content Type + can be registered with the IANA. Non-IANA properties can be used by + bilateral agreement, provided the associated properties names follow + the "X-" convention. + + The procedures defined here are designed to allow public comment and + review of new properties, while posing only a small impediment to the + definition of new properties. + + + +Dawson & Stenerson Standards Track [Page 141] + +RFC 2445 iCalendar November 1998 + + + Registration of a new property is accomplished by the following + steps. + +7.2.1 Define the property + + A property is defined by completing the following template. + + To: ietf-calendar@imc.org + + Subject: Registration of text/calendar MIME property XXX + + Property name: + + Property purpose: + + Property value type(s): + + Property parameter (s): + + Conformance: + + Description: + + Format definition: + + Examples: + + The meaning of each field in the template is as follows. + + Property name: The name of the property, as it will appear in the + body of an text/calendar MIME Content-Type "property: value" line to + the left of the colon ":". + + Property purpose: The purpose of the property (e.g., to indicate a + delegate for the event or to-do, etc.). Give a short but clear + description. + + Property value type (s): Any of the valid value types for the + property value needs to be specified. The default value type also + needs to be specified. If a new value type is specified, it needs to + be declared in this section. + + Property parameter (s): Any of the valid property parameters for the + property needs to be specified. + + Conformance: The calendar components that the property can appear in + needs to be specified. + + + + +Dawson & Stenerson Standards Track [Page 142] + +RFC 2445 iCalendar November 1998 + + + Description: Any special notes about the property, how it is to be + used, etc. + + Format definition: The ABNF for the property definition needs to be + specified. + + Examples: One or more examples of instances of the property needs to + be specified. + +7.2.2 Post the Property definition + + The property description MUST be posted to the new property + discussion list, ietf-calendar@imc.org. + +7.2.3 Allow a comment period + + Discussion on the new property MUST be allowed to take place on the + list for a minimum of two weeks. Consensus MUST be reached on the + property before proceeding to the next step. + +7.2.4 Submit the property for approval + + Once the two-week comment period has elapsed, and the proposer is + convinced consensus has been reached on the property, the + registration application should be submitted to the Method Reviewer + for approval. The Method Reviewer is appointed to the Application + Area Directors and can either accept or reject the property + registration. An accepted registration should be passed on by the + Method Reviewer to the IANA for inclusion in the official IANA method + registry. The registration can be rejected for any of the following + reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) + Technical deficiencies raised on the list or elsewhere have not been + addressed. The Method Reviewer's decision to reject a property can be + appealed by the proposer to the IESG, or the objections raised can be + addressed by the proposer and the property resubmitted. + +7.3 Property Change Control + + Existing properties can be changed using the same process by which + they were registered. + + 1. Define the change + + 2. Post the change + + 3. Allow a comment period + + 4. Submit the property for approval + + + +Dawson & Stenerson Standards Track [Page 143] + +RFC 2445 iCalendar November 1998 + + + Note that the original author or any other interested party can + propose a change to an existing property, but that such changes + should only be proposed when there are serious omissions or errors in + the published memo. The Method Reviewer can object to a change if it + is not backward compatible, but is not required to do so. + + Property definitions can never be deleted from the IANA registry, but + properties which are no longer believed to be useful can be declared + OBSOLETE by a change to their "intended use" field. + +8 References + + [IMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar + Message-based Interoperability Protocol (IMIP)", RFC 2447, + November 1998. + + [ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, + "iCalendar Transport-Independent Interoperability Protocol + (iTIP) : Scheduling Events, Busy Time, To-dos and Journal + Entries", RFC 2446, November 1998. + + [ISO 8601] ISO 8601, "Data elements and interchange formats- + Information interchange--Representation of dates and + times", International Organization for Standardization, + June, 1988. + + [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support + Facilities--Registration Procedures for Public Text Owner + Identifiers", Second Edition, International Organization + for Standardization, April 1991. + + [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet + Text Messages", STD 11, RFC 822, August 1982. + + [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform + Resource Locators (URL)", RFC 1738, December 1994. + + [RFC 1766] Alvestrand, H., "Tags for the Identification of + Languages", RFC 1766, March 1995. + + [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail + Extensions (MIME) - Part One: Format of Internet Message + Bodies", RFC 2045, November 1996. + + [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail + Extensions (MIME) - Part Two: Media Types", RFC 2046, + November 1996. + + + + +Dawson & Stenerson Standards Track [Page 144] + +RFC 2445 iCalendar November 1998 + + + [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose + Internet Mail Extensions (MIME) - Part Four: Registration + Procedures", RFC 2048, January 1997. + + [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", RFC 2234, November 1997. + + [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", RFC 2279, January 1998. + + [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type + for Directory Information", RFC 2425, September 1998. + + [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", + RFC 2426, September 1998. + + [TZ] Olson, A.D., et al, Time zone code and data, + ftp://elsie.nci.nih.gov/pub/, updated periodically. + + [VCAL] Internet Mail Consortium, "vCalendar - The Electronic + Calendaring and Scheduling Exchange Format", + http://www.imc.org/pdi/vcal-10.txt, September 18, 1996. + +9 Acknowledgments + + A hearty thanks to the IETF Calendaring and Scheduling Working Group + and also the following individuals who have participated in the + drafting, review and discussion of this memo: + + Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John + Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre + Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross + Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck + Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman, + Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch, + Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve + Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman, + John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert + Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod + Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg, + William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov, + James L. Weiner, Mike Weston, William Wyatt. + + + + + + +Dawson & Stenerson Standards Track [Page 145] + +RFC 2445 iCalendar November 1998 + + +10 Authors' and Chairs' Addresses + + The following address information is provided in a MIME-VCARD, + Electronic Business Card, format. + + The authors of this memo are: + + BEGIN:VCARD + VERSION:3.0 + N:Dawson;Frank + FN:Frank Dawson + ORG:Lotus Development Corporation + ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; + Raleigh;NC;27613-3502;USA + TEL;TYPE=WORK,MSG:+1-919-676-9515 + TEL;TYPE=WORK,FAX:+1-919-676-9564 + EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com + EMAIL;TYPE=INTERNET:fdawson@earthlink.net + URL:http://home.earthlink.net/~fdawson + END:VCARD + + BEGIN:VCARD + VERSION:3.0 + N:Stenerson;Derik + FN:Derik Stenerson + ORG:Microsoft Corporation + ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; + Redmond;WA;98052-6399;USA + TEL;TYPE=WORK,MSG:+1-425-936-5522 + TEL;TYPE=WORK,FAX:+1-425-936-7329 + EMAIL;TYPE=INTERNET:deriks@Microsoft.com + END:VCARD + + The iCalendar object is a result of the work of the Internet + Engineering Task Force Calendaring and Scheduling Working Group. The + chairmen of that working group are: + + BEGIN:VCARD + VERSION:3.0 + N:Ganguly;Anik + FN:Anik Ganguly + ORG: Open Text Inc. + ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road; + Livonia;MI;48152;USA + TEL;TYPE=WORK,MSG:+1-734-542-5955 + EMAIL;TYPE=INTERNET:ganguly@acm.org + END:VCARD + + + + +Dawson & Stenerson Standards Track [Page 146] + +RFC 2445 iCalendar November 1998 + + + The co-chairman of that working group is: + + BEGIN:VCARD + VERSION:3.0 + N:Moskowitz;Robert + FN:Robert Moskowitz + EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com + END:VCARD + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Dawson & Stenerson Standards Track [Page 147] + +RFC 2445 iCalendar November 1998 + + +11. Full Copyright Statement + + Copyright (C) The Internet Society (1998). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + + + + + + + + + + + + + + + + + + + + + + + + +Dawson & Stenerson Standards Track [Page 148] + diff --git a/docs/rfc2518.html b/docs/rfc2518.html new file mode 100644 index 00000000..e8300f6c --- /dev/null +++ b/docs/rfc2518.html @@ -0,0 +1,5109 @@ + +RFC 2518 +
+Network Working Group
+Request for Comments: 2518
+Category: Standards Track
+		 +Y. Goland
+Microsoft
+E. Whitehead
+UC Irvine
+A. Faizi
+Netscape
+S. Carter
+Novell
+D. Jensen
+Novell
+February 1999
+
+Page 1

+

HTTP Extensions for Distributed Authoring -- WEBDAV

+

+

Status of this Memo
+

+ This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. +

+

Copyright Notice
+

+ Copyright © The Internet Society (1999). All Rights Reserved. +

+

Abstract
+

+ This document specifies a set of methods, headers, and content-types + ancillary to HTTP/1.1 for the management of resource properties, + creation and management of resource collections, namespace + manipulation, and resource locking (collision avoidance). +

+

Table of Contents
+

+ +ABSTRACT +
+ +1 INTRODUCTION +
+ +2 NOTATIONAL CONVENTIONS +
+ +3 TERMINOLOGY +
+ +4 DATA MODEL FOR RESOURCE PROPERTIES +
+ +4.1 The Resource Property Model +
+ +4.2 Existing Metadata Proposals +
+ +4.3 Properties and HTTP Headers +
+ +4.4 Property Values +
+ +4.5 Property Names +
+ +4.6 Media Independent Links +
+ +5 COLLECTIONS OF WEB RESOURCES + +

+

+Page 2

+ +5.1 HTTP URL Namespace Model +
+ +5.2 Collection Resources +
+ +5.3 Creation and Retrieval of Collection Resources +
+ +5.4 Source Resources and Output Resources +
+ +6 LOCKING +
+ +6.1 Exclusive Vs. Shared Locks +
+ +6.2 Required Support +
+ +6.3 Lock Tokens +
+ +6.4 opaquelocktoken Lock Token URI Scheme +
+ +6.4.1 Node Field Generation Without the IEEE 802 Address +
+ +6.5 Lock Capability Discovery +
+ +6.6 Active Lock Discovery +
+ +6.7 Usage Considerations +
+ +7 WRITE LOCK +
+ +7.1 Methods Restricted by Write Locks +
+ +7.2 Write Locks and Lock Tokens +
+ +7.3 Write Locks and Properties +
+ +7.4 Write Locks and Null Resources +
+ +7.5 Write Locks and Collections +
+ +7.6 Write Locks and the If Request Header +
+ +7.6.1 Example - Write Lock +
+ +7.7 Write Locks and COPY/MOVE +
+ +7.8 Refreshing Write Locks +
+ +8 HTTP METHODS FOR DISTRIBUTED AUTHORING +
+ +8.1 PROPFIND +
+ +8.1.1 Example - Retrieving Named Properties +
+ +8.1.2 Example - Using allprop to Retrieve All Properties +
+ 8.1.3 Example - Using propname to Retrieve all Property Names ...29 + +8.2 PROPPATCH +
+ +8.2.1 Status Codes for use with 207 (Multi-Status) +
+ +8.2.2 Example - PROPPATCH +
+ +8.3 MKCOL Method +
+ +8.3.1 Request +
+ +8.3.2 Status Codes +
+ +8.3.3 Example - MKCOL +
+ +8.4 GET, HEAD for Collections +
+ +8.5 POST for Collections +
+ +8.6 DELETE +
+ +8.6.1 DELETE for Non-Collection Resources +
+ +8.6.2 DELETE for Collections +
+ +8.7 PUT +
+ +8.7.1 PUT for Non-Collection Resources +
+ +8.7.2 PUT for Collections +
+ +8.8 COPY Method +
+ +8.8.1 COPY for HTTP/1.1 resources +
+ +8.8.2 COPY for Properties +
+ +8.8.3 COPY for Collections +
+ +8.8.4 COPY and the Overwrite Header + +

+

+Page 3

+ +8.8.5 Status Codes +
+ +8.8.6 Example - COPY with Overwrite +
+ +8.8.7 Example - COPY with No Overwrite +
+ +8.8.8 Example - COPY of a Collection +
+ +8.9 MOVE Method +
+ +8.9.1 MOVE for Properties +
+ +8.9.2 MOVE for Collections +
+ +8.9.3 MOVE and the Overwrite Header +
+ +8.9.4 Status Codes +
+ +8.9.5 Example - MOVE of a Non-Collection +
+ +8.9.6 Example - MOVE of a Collection +
+ +8.10 LOCK Method +
+ +8.10.1 Operation +
+ +8.10.2 The Effect of Locks on Properties and Collections +
+ +8.10.3 Locking Replicated Resources +
+ +8.10.4 Depth and Locking +
+ +8.10.5 Interaction with other Methods +
+ +8.10.6 Lock Compatibility Table +
+ +8.10.7 Status Codes +
+ +8.10.8 Example - Simple Lock Request +
+ +8.10.9 Example - Refreshing a Write Lock +
+ +8.10.10 Example - Multi-Resource Lock Request +
+ +8.11 UNLOCK Method +
+ +8.11.1 Example - UNLOCK +
+ +9 HTTP HEADERS FOR DISTRIBUTED AUTHORING +
+ +9.1 DAV Header +
+ +9.2 Depth Header +
+ +9.3 Destination Header +
+ +9.4 If Header +
+ +9.4.1 No-tag-list Production +
+ +9.4.2 Tagged-list Production +
+ +9.4.3 not Production +
+ +9.4.4 Matching Function +
+ +9.4.5 If Header and Non-DAV Compliant Proxies +
+ +9.5 Lock-Token Header +
+ +9.6 Overwrite Header +
+ +9.7 Status-URI Response Header +
+ +9.8 Timeout Request Header +
+ +10 STATUS CODE EXTENSIONS TO HTTP/1.1 +
+ +10.1 102 Processing +
+ +10.2 207 Multi-Status +
+ +10.3 422 Unprocessable Entity +
+ +10.4 423 Locked +
+ +10.5 424 Failed Dependency +
+ +10.6 507 Insufficient Storage +
+ +11 MULTI-STATUS RESPONSE +
+ +12 XML ELEMENT DEFINITIONS +
+ +12.1 activelock XML Element +
+

+Page 4

+ +12.1.1 depth XML Element +
+ +12.1.2 locktoken XML Element +
+ +12.1.3 timeout XML Element +
+ +12.2 collection XML Element +
+ +12.3 href XML Element +
+ +12.4 link XML Element +
+ +12.4.1 dst XML Element +
+ +12.4.2 src XML Element +
+ +12.5 lockentry XML Element +
+ +12.6 lockinfo XML Element +
+ +12.7 lockscope XML Element +
+ +12.7.1 exclusive XML Element +
+ +12.7.2 shared XML Element +
+ +12.8 locktype XML Element +
+ +12.8.1 write XML Element +
+ +12.9 multistatus XML Element +
+ +12.9.1 response XML Element +
+ +12.9.2 responsedescription XML Element +
+ +12.10 owner XML Element +
+ +12.11 prop XML element +
+ +12.12 propertybehavior XML element +
+ +12.12.1 keepalive XML element +
+ +12.12.2 omit XML element +
+ +12.13 propertyupdate XML element +
+ +12.13.1 remove XML element +
+ +12.13.2 set XML element +
+ +12.14 propfind XML Element +
+ +12.14.1 allprop XML Element +
+ +12.14.2 propname XML Element +
+ +13 DAV PROPERTIES +
+ +13.1 creationdate Property +
+ +13.2 displayname Property +
+ +13.3 getcontentlanguage Property +
+ +13.4 getcontentlength Property +
+ +13.5 getcontenttype Property +
+ +13.6 getetag Property +
+ +13.7 getlastmodified Property +
+ +13.8 lockdiscovery Property +
+ +13.8.1 Example - Retrieving the lockdiscovery Property +
+ +13.9 resourcetype Property +
+ +13.10 source Property +
+ +13.10.1 Example - A source Property +
+ +13.11 supportedlock Property +
+ +13.11.1 Example - Retrieving the supportedlock Property +
+ +14 INSTRUCTIONS FOR PROCESSING XML IN DAV +
+ +15 DAV COMPLIANCE CLASSES +
+ +15.1 Class 1 +
+ +15.2 Class 2 +
+

+Page 5

+ +16 INTERNATIONALIZATION CONSIDERATIONS +
+ +17 SECURITY CONSIDERATIONS +
+ +17.1 Authentication of Clients +
+ +17.2 Denial of Service +
+ +17.3 Security through Obscurity +
+ +17.4 Privacy Issues Connected to Locks +
+ +17.5 Privacy Issues Connected to Properties +
+ +17.6 Reduction of Security due to Source Link +
+ +17.7 Implications of XML External Entities +
+ +17.8 Risks Connected with Lock Tokens +
+ +18 IANA CONSIDERATIONS +
+ +19 INTELLECTUAL PROPERTY +
+ +20 ACKNOWLEDGEMENTS +
+ +21 REFERENCES +
+ +21.1 Normative References +
+ +21.2 Informational References +
+ +22 AUTHORS' ADDRESSES +
+ +23 APPENDICES +
+ +23.1 Appendix 1 - WebDAV Document Type Definition +
+ +23.2 Appendix 2 - ISO 8601 Date and Time Profile +
+ +23.3 Appendix 3 - Notes on Processing XML Elements +
+ +23.3.1 Notes on Empty XML Elements +
+ +23.3.2 Notes on Illegal XML Processing +
+ +23.4 Appendix 4 -- XML Namespaces for WebDAV +
+ +23.4.1 Introduction +
+ +23.4.2 Meaning of Qualified Names +
+ +24 FULL COPYRIGHT STATEMENT +
+

1 Introduction
+

+ This document describes an extension to the HTTP/1.1 protocol that + allows clients to perform remote web content authoring operations. + This extension provides a coherent set of methods, headers, request + entity body formats, and response entity body formats that provide + operations for: +

+ Properties: The ability to create, remove, and query information + about Web pages, such as their authors, creation dates, etc. Also, + the ability to link pages of any media type to related pages. +

+ Collections: The ability to create sets of documents and to retrieve + a hierarchical membership listing (like a directory listing in a file + system). +

+

+Page 6

+ Locking: The ability to keep more than one person from working on a + document at the same time. This prevents the "lost update problem," + in which modifications are lost as first one author then another + writes changes without merging the other author's changes. +

+ Namespace Operations: The ability to instruct the server to copy and + move Web resources. +

+ Requirements and rationale for these operations are described in a + companion document, "Requirements for a Distributed Authoring and + Versioning Protocol for the World Wide Web" [RFC2291]. +

+ The sections below provide a detailed introduction to resource + properties (section 4), collections of resources (section 5), and + locking operations (section 6). These sections introduce the + abstractions manipulated by the WebDAV-specific HTTP methods + described in section 8, "HTTP Methods for Distributed Authoring". +

+ In HTTP/1.1, method parameter information was exclusively encoded in + HTTP headers. Unlike HTTP/1.1, WebDAV encodes method parameter + information either in an Extensible Markup Language (XML) [REC-XML] + request entity body, or in an HTTP header. The use of XML to encode + method parameters was motivated by the ability to add extra XML + elements to existing structures, providing extensibility; and by + XML's ability to encode information in ISO 10646 character sets, + providing internationalization support. As a rule of thumb, + parameters are encoded in XML entity bodies when they have unbounded + length, or when they may be shown to a human user and hence require + encoding in an ISO 10646 character set. Otherwise, parameters are + encoded within HTTP headers. Section 9 describes the new HTTP + headers used with WebDAV methods. +

+ In addition to encoding method parameters, XML is used in WebDAV to + encode the responses from methods, providing the extensibility and + internationalization advantages of XML for method output, as well as + input. +

+ XML elements used in this specification are defined in section 12. +

+ The XML namespace extension (Appendix 4) is also used in this + specification in order to allow for new XML elements to be added + without fear of colliding with other element names. +

+ While the status codes provided by HTTP/1.1 are sufficient to + describe most error conditions encountered by WebDAV methods, there + are some errors that do not fall neatly into the existing categories. + New status codes developed for the WebDAV methods are defined in + section 10. Since some WebDAV methods may operate over many +

+

+Page 7

+ resources, the Multi-Status response has been introduced to return + status information for multiple resources. The Multi-Status response + is described in section 11. +

+ WebDAV employs the property mechanism to store information about the + current state of the resource. For example, when a lock is taken out + on a resource, a lock information property describes the current + state of the lock. Section 13 defines the properties used within the + WebDAV specification. +

+ Finishing off the specification are sections on what it means to be + compliant with this specification (section 15), on +
+ internationalization support (section 16), and on security (section + 17). +

+

2 Notational Conventions
+

+ Since this document describes a set of extensions to the HTTP/1.1 + protocol, the augmented BNF used herein to describe protocol elements + is exactly the same as described in section 2.1 of [RFC2068]. Since + this augmented BNF uses the basic production rules provided in + section 2.2 of [RFC2068], these rules apply to this document as well. +

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

+

3 Terminology
+

+ URI/URL - A Uniform Resource Identifier and Uniform Resource Locator, + respectively. These terms (and the distinction between them) are + defined in [RFC2396]. +

+ Collection - A resource that contains a set of URIs, termed member + URIs, which identify member resources and meets the requirements in + section 5 of this specification. +

+ Member URI - A URI which is a member of the set of URIs contained by + a collection. +

+ Internal Member URI - A Member URI that is immediately relative to + the URI of the collection (the definition of immediately relative is + given in section 5.2). +

+ Property - A name/value pair that contains descriptive information + about a resource. +

+

+Page 8

+ Live Property - A property whose semantics and syntax are enforced by + the server. For example, the live "getcontentlength" property has + its value, the length of the entity returned by a GET request, + automatically calculated by the server. +

+ Dead Property - A property whose semantics and syntax are not + enforced by the server. The server only records the value of a dead + property; the client is responsible for maintaining the consistency + of the syntax and semantics of a dead property. +

+ Null Resource - A resource which responds with a 404 (Not Found) to + any HTTP/1.1 or DAV method except for PUT, MKCOL, OPTIONS and LOCK. + A NULL resource MUST NOT appear as a member of its parent collection. +

+

4 Data Model for Resource Properties
+

+

4.1 The Resource Property Model
+

+ Properties are pieces of data that describe the state of a resource. + Properties are data about data. +

+ Properties are used in distributed authoring environments to provide + for efficient discovery and management of resources. For example, a + 'subject' property might allow for the indexing of all resources by + their subject, and an 'author' property might allow for the discovery + of what authors have written which documents. +

+ The DAV property model consists of name/value pairs. The name of a + property identifies the property's syntax and semantics, and provides + an address by which to refer to its syntax and semantics. +

+ There are two categories of properties: "live" and "dead". A live + property has its syntax and semantics enforced by the server. Live + properties include cases where a) the value of a property is read- + only, maintained by the server, and b) the value of the property is + maintained by the client, but the server performs syntax checking on + submitted values. All instances of a given live property MUST comply + with the definition associated with that property name. A dead + property has its syntax and semantics enforced by the client; the + server merely records the value of the property verbatim. +

+

4.2 Existing Metadata Proposals
+

+ Properties have long played an essential role in the maintenance of + large document repositories, and many current proposals contain some + notion of a property, or discuss web metadata more generally. These + include PICS [REC-PICS], PICS-NG, XML, Web Collections, and several + proposals on representing relationships within HTML. Work on PICS-NG +

+

+Page 9

+ and Web Collections has been subsumed by the Resource Description + Framework (RDF) metadata activity of the World Wide Web Consortium. + RDF consists of a network-based data model and an XML representation + of that model. +

+ Some proposals come from a digital library perspective. These + include the Dublin Core [RFC2413] metadata set and the Warwick + Framework [WF], a container architecture for different metadata + schemas. The literature includes many examples of metadata, + including MARC [USMARC], a bibliographic metadata format, and a + technical report bibliographic format employed by the Dienst system + [RFC1807]. Additionally, the proceedings from the first IEEE Metadata + conference describe many community-specific metadata sets. +

+ Participants of the 1996 Metadata II Workshop in Warwick, UK [WF], + noted that "new metadata sets will develop as the networked + infrastructure matures" and "different communities will propose, + design, and be responsible for different types of metadata." These + observations can be corroborated by noting that many community- + specific sets of metadata already exist, and there is significant + motivation for the development of new forms of metadata as many + communities increasingly make their data available in digital form, + requiring a metadata format to assist data location and cataloging. +

+

4.3 Properties and HTTP Headers
+

+ Properties already exist, in a limited sense, in HTTP message + headers. However, in distributed authoring environments a relatively + large number of properties are needed to describe the state of a + resource, and setting/returning them all through HTTP headers is + inefficient. Thus a mechanism is needed which allows a principal to + identify a set of properties in which the principal is interested and + to set or retrieve just those properties. +

+

4.4 Property Values
+

+ The value of a property when expressed in XML MUST be well formed. +

+ XML has been chosen because it is a flexible, self-describing, + structured data format that supports rich schema definitions, and + because of its support for multiple character sets. XML's self- + describing nature allows any property's value to be extended by + adding new elements. Older clients will not break when they + encounter extensions because they will still have the data specified + in the original schema and will ignore elements they do not + understand. XML's support for multiple character sets allows any + human-readable property to be encoded and read in a character set + familiar to the user. XML's support for multiple human languages, +

+

+Page 10

+ using the "xml:lang" attribute, handles cases where the same + character set is employed by multiple human languages. +

+

4.5 Property Names
+

+ A property name is a universally unique identifier that is associated + with a schema that provides information about the syntax and + semantics of the property. +

+ Because a property's name is universally unique, clients can depend + upon consistent behavior for a particular property across multiple + resources, on the same and across different servers, so long as that + property is "live" on the resources in question, and the +
+ implementation of the live property is faithful to its definition. +

+ The XML namespace mechanism, which is based on URIs [RFC2396], is + used to name properties because it prevents namespace collisions and + provides for varying degrees of administrative control. +

+ The property namespace is flat; that is, no hierarchy of properties + is explicitly recognized. Thus, if a property A and a property A/B + exist on a resource, there is no recognition of any relationship + between the two properties. It is expected that a separate + specification will eventually be produced which will address issues + relating to hierarchical properties. +

+ Finally, it is not possible to define the same property twice on a + single resource, as this would cause a collision in the resource's + property namespace. +

+

4.6 Media Independent Links
+

+ Although HTML resources support links to other resources, the Web + needs more general support for links between resources of any media + type (media types are also known as MIME types, or content types). + WebDAV provides such links. A WebDAV link is a special type of + property value, formally defined in section 12.4, that allows typed + connections to be established between resources of any media type. + The property value consists of source and destination Uniform + Resource Identifiers (URIs); the property name identifies the link + type. +

+

+Page 11

+

5 Collections of Web Resources
+

+ This section provides a description of a new type of Web resource, + the collection, and discusses its interactions with the HTTP URL + namespace. The purpose of a collection resource is to model + collection-like objects (e.g., file system directories) within a + server's namespace. +

+ All DAV compliant resources MUST support the HTTP URL namespace model + specified herein. +

+

5.1 HTTP URL Namespace Model
+

+ The HTTP URL namespace is a hierarchical namespace where the + hierarchy is delimited with the "/" character. +

+ An HTTP URL namespace is said to be consistent if it meets the + following conditions: for every URL in the HTTP hierarchy there + exists a collection that contains that URL as an internal member. + The root, or top-level collection of the namespace under +
+ consideration is exempt from the previous rule. +

+ Neither HTTP/1.1 nor WebDAV require that the entire HTTP URL + namespace be consistent. However, certain WebDAV methods are + prohibited from producing results that cause namespace +
+ inconsistencies. +

+ Although implicit in [RFC2068] and [RFC2396], any resource, including + collection resources, MAY be identified by more than one URI. For + example, a resource could be identified by multiple HTTP URLs. +

+

5.2 Collection Resources
+

+ A collection is a resource whose state consists of at least a list of + internal member URIs and a set of properties, but which may have + additional state such as entity bodies returned by GET. An internal + member URI MUST be immediately relative to a base URI of the + collection. That is, the internal member URI is equal to a + containing collection's URI plus an additional segment for non- + collection resources, or additional segment plus trailing slash "/" + for collection resources, where segment is defined in section 3.3 of + [RFC2396]. +

+ Any given internal member URI MUST only belong to the collection + once, i.e., it is illegal to have multiple instances of the same URI + in a collection. Properties defined on collections behave exactly as + do properties on non-collection resources. +

+

+Page 12

+ For all WebDAV compliant resources A and B, identified by URIs U and + V, for which U is immediately relative to V, B MUST be a collection + that has U as an internal member URI. So, if the resource with URL + http://foo.com/bar/blah is WebDAV compliant and if the resource with + URL http://foo.com/bar/ is WebDAV compliant then the resource with + URL http://foo.com/bar/ must be a collection and must contain URL + http://foo.com/bar/blah as an internal member. +

+ Collection resources MAY list the URLs of non-WebDAV compliant + children in the HTTP URL namespace hierarchy as internal members but + are not required to do so. For example, if the resource with URL + http://foo.com/bar/blah is not WebDAV compliant and the URL + http://foo.com/bar/ identifies a collection then URL +
+ http://foo.com/bar/blah may or may not be an internal member of the + collection with URL http://foo.com/bar/. +

+ If a WebDAV compliant resource has no WebDAV compliant children in + the HTTP URL namespace hierarchy then the WebDAV compliant resource + is not required to be a collection. +

+ There is a standing convention that when a collection is referred to + by its name without a trailing slash, the trailing slash is + automatically appended. Due to this, a resource may accept a URI + without a trailing "/" to point to a collection. In this case it + SHOULD return a content-location header in the response pointing to + the URI ending with the "/". For example, if a client invokes a + method on http://foo.bar/blah (no trailing slash), the resource + http://foo.bar/blah/ (trailing slash) may respond as if the operation + were invoked on it, and should return a content-location header with + http://foo.bar/blah/ in it. In general clients SHOULD use the "/" + form of collection names. +

+ A resource MAY be a collection but not be WebDAV compliant. That is, + the resource may comply with all the rules set out in this + specification regarding how a collection is to behave without + necessarily supporting all methods that a WebDAV compliant resource + is required to support. In such a case the resource may return the + DAV:resourcetype property with the value DAV:collection but MUST NOT + return a DAV header containing the value "1" on an OPTIONS response. +

+

5.3 Creation and Retrieval of Collection Resources
+

+ This document specifies the MKCOL method to create new collection + resources, rather than using the existing HTTP/1.1 PUT or POST + method, for the following reasons: +

+

+Page 13

+ In HTTP/1.1, the PUT method is defined to store the request body at + the location specified by the Request-URI. While a description + format for a collection can readily be constructed for use with PUT, + the implications of sending such a description to the server are + undesirable. For example, if a description of a collection that + omitted some existing resources were PUT to a server, this might be + interpreted as a command to remove those members. This would extend + PUT to perform DELETE functionality, which is undesirable since it + changes the semantics of PUT, and makes it difficult to control + DELETE functionality with an access control scheme based on methods. +

+ While the POST method is sufficiently open-ended that a "create a + collection" POST command could be constructed, this is undesirable + because it would be difficult to separate access control for + collection creation from other uses of POST. +

+ The exact definition of the behavior of GET and PUT on collections is + defined later in this document. +

+

5.4 Source Resources and Output Resources
+

+ For many resources, the entity returned by a GET method exactly + matches the persistent state of the resource, for example, a GIF file + stored on a disk. For this simple case, the URI at which a resource + is accessed is identical to the URI at which the source (the + persistent state) of the resource is accessed. This is also the case + for HTML source files that are not processed by the server prior to + transmission. +

+ However, the server can sometimes process HTML resources before they + are transmitted as a return entity body. For example, a server- + side-include directive within an HTML file might instruct a server to + replace the directive with another value, such as the current date. + In this case, what is returned by GET (HTML plus date) differs from + the persistent state of the resource (HTML plus directive). + Typically there is no way to access the HTML resource containing the + unprocessed directive. +

+ Sometimes the entity returned by GET is the output of a data- + producing process that is described by one or more source resources + (that may not even have a location in the URI namespace). A single + data-producing process may dynamically generate the state of a + potentially large number of output resources. An example of this is + a CGI script that describes a "finger" gateway process that maps part + of the namespace of a server into finger requests, such as + http://www.foo.bar.org/finger_gateway/user@host. +

+

+Page 14

+ In the absence of distributed authoring capabilities, it is + acceptable to have no mapping of source resource(s) to the URI + namespace. In fact, preventing access to the source resource(s) has + desirable security benefits. However, if remote editing of the + source resource(s) is desired, the source resource(s) should be given + a location in the URI namespace. This source location should not be + one of the locations at which the generated output is retrievable, + since in general it is impossible for the server to differentiate + requests for source resources from requests for process output + resources. There is often a many-to-many relationship between source + resources and output resources. +

+ On WebDAV compliant servers the URI of the source resource(s) may be + stored in a link on the output resource with type DAV:source (see + section 13.10 for a description of the source link property). + Storing the source URIs in links on the output resources places the + burden of discovering the source on the authoring client. Note that + the value of a source link is not guaranteed to point to the correct + source. Source links may break or incorrect values may be entered. + Also note that not all servers will allow the client to set the + source link value. For example a server which generates source links + on the fly for its CGI files will most likely not allow a client to + set the source link value. +

+

6 Locking
+

+ The ability to lock a resource provides a mechanism for serializing + access to that resource. Using a lock, an authoring client can + provide a reasonable guarantee that another principal will not modify + a resource while it is being edited. In this way, a client can + prevent the "lost update" problem. +

+ This specification allows locks to vary over two client-specified + parameters, the number of principals involved (exclusive vs. shared) + and the type of access to be granted. This document defines locking + for only one access type, write. However, the syntax is extensible, + and permits the eventual specification of locking for other access + types. +

+

6.1 Exclusive Vs. Shared Locks
+

+ The most basic form of lock is an exclusive lock. This is a lock + where the access right in question is only granted to a single + principal. The need for this arbitration results from a desire to + avoid having to merge results. +

+

+Page 15

+ However, there are times when the goal of a lock is not to exclude + others from exercising an access right but rather to provide a + mechanism for principals to indicate that they intend to exercise + their access rights. Shared locks are provided for this case. A + shared lock allows multiple principals to receive a lock. Hence any + principal with appropriate access can get the lock. +

+ With shared locks there are two trust sets that affect a resource. + The first trust set is created by access permissions. Principals who + are trusted, for example, may have permission to write to the + resource. Among those who have access permission to write to the + resource, the set of principals who have taken out a shared lock also + must trust each other, creating a (typically) smaller trust set + within the access permission write set. +

+ Starting with every possible principal on the Internet, in most + situations the vast majority of these principals will not have write + access to a given resource. Of the small number who do have write + access, some principals may decide to guarantee their edits are free + from overwrite conflicts by using exclusive write locks. Others may + decide they trust their collaborators will not overwrite their work + (the potential set of collaborators being the set of principals who + have write permission) and use a shared lock, which informs their + collaborators that a principal may be working on the resource. +

+ The WebDAV extensions to HTTP do not need to provide all of the + communications paths necessary for principals to coordinate their + activities. When using shared locks, principals may use any out of + band communication channel to coordinate their work (e.g., face-to- + face interaction, written notes, post-it notes on the screen, + telephone conversation, Email, etc.) The intent of a shared lock is + to let collaborators know who else may be working on a resource. +

+ Shared locks are included because experience from web distributed + authoring systems has indicated that exclusive locks are often too + rigid. An exclusive lock is used to enforce a particular editing + process: take out an exclusive lock, read the resource, perform + edits, write the resource, release the lock. This editing process + has the problem that locks are not always properly released, for + example when a program crashes, or when a lock owner leaves without + unlocking a resource. While both timeouts and administrative action + can be used to remove an offending lock, neither mechanism may be + available when needed; the timeout may be long or the administrator + may not be available. +

+

+Page 16

+

6.2 Required Support
+

+ A WebDAV compliant server is not required to support locking in any + form. If the server does support locking it may choose to support + any combination of exclusive and shared locks for any access types. +

+ The reason for this flexibility is that locking policy strikes to the + very heart of the resource management and versioning systems employed + by various storage repositories. These repositories require control + over what sort of locking will be made available. For example, some + repositories only support shared write locks while others only + provide support for exclusive write locks while yet others use no + locking at all. As each system is sufficiently different to merit + exclusion of certain locking features, this specification leaves + locking as the sole axis of negotiation within WebDAV. +

+

6.3 Lock Tokens
+

+ A lock token is a type of state token, represented as a URI, which + identifies a particular lock. A lock token is returned by every + successful LOCK operation in the lockdiscovery property in the + response body, and can also be found through lock discovery on a + resource. +

+ Lock token URIs MUST be unique across all resources for all time. + This uniqueness constraint allows lock tokens to be submitted across + resources and servers without fear of confusion. +

+ This specification provides a lock token URI scheme called + opaquelocktoken that meets the uniqueness requirements. However + resources are free to return any URI scheme so long as it meets the + uniqueness requirements. +

+ Having a lock token provides no special access rights. Anyone can + find out anyone else's lock token by performing lock discovery. + Locks MUST be enforced based upon whatever authentication mechanism + is used by the server, not based on the secrecy of the token values. +

+

6.4 opaquelocktoken Lock Token URI Scheme
+

+ The opaquelocktoken URI scheme is designed to be unique across all + resources for all time. Due to this uniqueness quality, a client may + submit an opaque lock token in an If header on a resource other than + the one that returned it. +

+ All resources MUST recognize the opaquelocktoken scheme and, at + minimum, recognize that the lock token does not refer to an + outstanding lock on the resource. +

+

+Page 17

+ In order to guarantee uniqueness across all resources for all time + the opaquelocktoken requires the use of the Universal Unique + Identifier (UUID) mechanism, as described in [ISO-11578]. +

+ Opaquelocktoken generators, however, have a choice of how they create + these tokens. They can either generate a new UUID for every lock + token they create or they can create a single UUID and then add + extension characters. If the second method is selected then the + program generating the extensions MUST guarantee that the same + extension will never be used twice with the associated UUID. +

+

   OpaqueLockToken-URI = "opaquelocktoken:" UUID [Extension]  ; The UUID
+   production is the string representation of a UUID, as defined in
+   [ISO-11578]. Note that white space (LWS) is not allowed between
+   elements of this production.
+
+   Extension = path  ; path is defined in section 3.2.1 of RFC 2068
+   [RFC2068]
+
+

+

6.4.1 Node Field Generation Without the IEEE 802 Address
+

+ UUIDs, as defined in [ISO-11578], contain a "node" field that + contains one of the IEEE 802 addresses for the server machine. As + noted in section 17.8, there are several security risks associated + with exposing a machine's IEEE 802 address. This section provides an + alternate mechanism for generating the "node" field of a UUID which + does not employ an IEEE 802 address. WebDAV servers MAY use this + algorithm for creating the node field when generating UUIDs. The + text in this section is originally from an Internet-Draft by Paul + Leach and Rich Salz, who are noted here to properly attribute their + work. +

+ The ideal solution is to obtain a 47 bit cryptographic quality random + number, and use it as the low 47 bits of the node ID, with the most + significant bit of the first octet of the node ID set to 1. This bit + is the unicast/multicast bit, which will never be set in IEEE 802 + addresses obtained from network cards; hence, there can never be a + conflict between UUIDs generated by machines with and without network + cards. +

+ If a system does not have a primitive to generate cryptographic + quality random numbers, then in most systems there are usually a + fairly large number of sources of randomness available from which one + can be generated. Such sources are system specific, but often + include: +

+

+Page 18

+

     - the percent of memory in use
+     - the size of main memory in bytes
+     - the amount of free main memory in bytes
+     - the size of the paging or swap file in bytes
+     - free bytes of paging or swap file
+     - the total size of user virtual address space in bytes
+     - the total available user address space bytes
+     - the size of boot disk drive in bytes
+     - the free disk space on boot drive in bytes
+     - the current time
+     - the amount of time since the system booted
+     - the individual sizes of files in various system directories
+     - the creation, last read, and modification times of files in
+       various system directories
+     - the utilization factors of various system resources (heap, etc.)
+     - current mouse cursor position
+     - current caret position
+     - current number of running processes, threads
+     - handles or IDs of the desktop window and the active window
+     - the value of stack pointer of the caller
+     - the process and thread ID of caller
+     - various processor architecture specific performance counters
+       (instructions executed, cache misses, TLB misses)
+
+

+ (Note that it is precisely the above kinds of sources of randomness + that are used to seed cryptographic quality random number generators + on systems without special hardware for their construction.) +

+ In addition, items such as the computer's name and the name of the + operating system, while not strictly speaking random, will help + differentiate the results from those obtained by other systems. +

+ The exact algorithm to generate a node ID using these data is system + specific, because both the data available and the functions to obtain + them are often very system specific. However, assuming that one can + concatenate all the values from the randomness sources into a buffer, + and that a cryptographic hash function such as MD5 is available, then + any 6 bytes of the MD5 hash of the buffer, with the multicast bit + (the high bit of the first byte) set will be an appropriately random + node ID. +

+ Other hash functions, such as SHA-1, can also be used. The only + requirement is that the result be suitably random _ in the sense that + the outputs from a set uniformly distributed inputs are themselves + uniformly distributed, and that a single bit change in the input can + be expected to cause half of the output bits to change. +

+

+Page 19

+

6.5 Lock Capability Discovery
+

+ Since server lock support is optional, a client trying to lock a + resource on a server can either try the lock and hope for the best, + or perform some form of discovery to determine what lock capabilities + the server supports. This is known as lock capability discovery. + Lock capability discovery differs from discovery of supported access + control types, since there may be access control types without + corresponding lock types. A client can determine what lock types the + server supports by retrieving the supportedlock property. +

+ Any DAV compliant resource that supports the LOCK method MUST support + the supportedlock property. +

+

6.6 Active Lock Discovery
+

+ If another principal locks a resource that a principal wishes to + access, it is useful for the second principal to be able to find out + who the first principal is. For this purpose the lockdiscovery + property is provided. This property lists all outstanding locks, + describes their type, and where available, provides their lock token. +

+ Any DAV compliant resource that supports the LOCK method MUST support + the lockdiscovery property. +

+

6.7 Usage Considerations
+

+ Although the locking mechanisms specified here provide some help in + preventing lost updates, they cannot guarantee that updates will + never be lost. Consider the following scenario: +

+ Two clients A and B are interested in editing the resource ' + index.html'. Client A is an HTTP client rather than a WebDAV client, + and so does not know how to perform locking. +
+ Client A doesn't lock the document, but does a GET and begins + editing. +
+ Client B does LOCK, performs a GET and begins editing. +
+ Client B finishes editing, performs a PUT, then an UNLOCK. + Client A performs a PUT, overwriting and losing all of B's changes. +

+ There are several reasons why the WebDAV protocol itself cannot + prevent this situation. First, it cannot force all clients to use + locking because it must be compatible with HTTP clients that do not + comprehend locking. Second, it cannot require servers to support + locking because of the variety of repository implementations, some of + which rely on reservations and merging rather than on locking. + Finally, being stateless, it cannot enforce a sequence of operations + like LOCK / GET / PUT / UNLOCK. +

+

+Page 20

+ WebDAV servers that support locking can reduce the likelihood that + clients will accidentally overwrite each other's changes by requiring + clients to lock resources before modifying them. Such servers would + effectively prevent HTTP 1.0 and HTTP 1.1 clients from modifying + resources. +

+ WebDAV clients can be good citizens by using a lock / retrieve / + write /unlock sequence of operations (at least by default) whenever + they interact with a WebDAV server that supports locking. +

+ HTTP 1.1 clients can be good citizens, avoiding overwriting other + clients' changes, by using entity tags in If-Match headers with any + requests that would modify resources. +

+ Information managers may attempt to prevent overwrites by + implementing client-side procedures requiring locking before + modifying WebDAV resources. +

+

7 Write Lock
+

+ This section describes the semantics specific to the write lock type. + The write lock is a specific instance of a lock type, and is the only + lock type described in this specification. +

+

7.1 Methods Restricted by Write Locks
+

+ A write lock MUST prevent a principal without the lock from + successfully executing a PUT, POST, PROPPATCH, LOCK, UNLOCK, MOVE, + DELETE, or MKCOL on the locked resource. All other current methods, + GET in particular, function independently of the lock. +

+ Note, however, that as new methods are created it will be necessary + to specify how they interact with a write lock. +

+

7.2 Write Locks and Lock Tokens
+

+ A successful request for an exclusive or shared write lock MUST + result in the generation of a unique lock token associated with the + requesting principal. Thus if five principals have a shared write + lock on the same resource there will be five lock tokens, one for + each principal. +

+

7.3 Write Locks and Properties
+

+ While those without a write lock may not alter a property on a + resource it is still possible for the values of live properties to + change, even while locked, due to the requirements of their schemas. +

+

+Page 21

+ Only dead properties and live properties defined to respect locks are + guaranteed not to change while write locked. +

+

7.4 Write Locks and Null Resources
+

+ It is possible to assert a write lock on a null resource in order to + lock the name. +

+ A write locked null resource, referred to as a lock-null resource, + MUST respond with a 404 (Not Found) or 405 (Method Not Allowed) to + any HTTP/1.1 or DAV methods except for PUT, MKCOL, OPTIONS, PROPFIND, + LOCK, and UNLOCK. A lock-null resource MUST appear as a member of + its parent collection. Additionally the lock-null resource MUST have + defined on it all mandatory DAV properties. Most of these + properties, such as all the get* properties, will have no value as a + lock-null resource does not support the GET method. Lock-Null + resources MUST have defined values for lockdiscovery and +
+ supportedlock properties. +

+ Until a method such as PUT or MKCOL is successfully executed on the + lock-null resource the resource MUST stay in the lock-null state. + However, once a PUT or MKCOL is successfully executed on a lock-null + resource the resource ceases to be in the lock-null state. +

+ If the resource is unlocked, for any reason, without a PUT, MKCOL, or + similar method having been successfully executed upon it then the + resource MUST return to the null state. +

+

7.5 Write Locks and Collections
+

+ A write lock on a collection, whether created by a "Depth: 0" or + "Depth: infinity" lock request, prevents the addition or removal of + member URIs of the collection by non-lock owners. As a consequence, + when a principal issues a PUT or POST request to create a new + resource under a URI which needs to be an internal member of a write + locked collection to maintain HTTP namespace consistency, or issues a + DELETE to remove a resource which has a URI which is an existing + internal member URI of a write locked collection, this request MUST + fail if the principal does not have a write lock on the collection. +

+ However, if a write lock request is issued to a collection containing + member URIs identifying resources that are currently locked in a + manner which conflicts with the write lock, the request MUST fail + with a 423 (Locked) status code. +

+ If a lock owner causes the URI of a resource to be added as an + internal member URI of a locked collection then the new resource MUST + be automatically added to the lock. This is the only mechanism that +

+

+Page 22

+ allows a resource to be added to a write lock. Thus, for example, if + the collection /a/b/ is write locked and the resource /c is moved to +

   /a/b/c then resource /a/b/c will be added to the write lock.
+
+

+

7.6 Write Locks and the If Request Header
+

+ If a user agent is not required to have knowledge about a lock when + requesting an operation on a locked resource, the following scenario + might occur. Program A, run by User A, takes out a write lock on a + resource. Program B, also run by User A, has no knowledge of the + lock taken out by Program A, yet performs a PUT to the locked + resource. In this scenario, the PUT succeeds because locks are + associated with a principal, not a program, and thus program B, + because it is acting with principal A's credential, is allowed to + perform the PUT. However, had program B known about the lock, it + would not have overwritten the resource, preferring instead to + present a dialog box describing the conflict to the user. Due to + this scenario, a mechanism is needed to prevent different programs + from accidentally ignoring locks taken out by other programs with the + same authorization. +

+ In order to prevent these collisions a lock token MUST be submitted + by an authorized principal in the If header for all locked resources + that a method may interact with or the method MUST fail. For + example, if a resource is to be moved and both the source and + destination are locked then two lock tokens must be submitted, one + for the source and the other for the destination. +

+

7.6.1 Example - Write Lock
+

+ >>Request +

+ COPY /~fielding/index.html HTTP/1.1 +
+ Host: www.ics.uci.edu +
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html + If: <http://www.ics.uci.edu/users/f/fielding/index.html> +
+ (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>) +

+ >>Response +

+ HTTP/1.1 204 No Content +

+ In this example, even though both the source and destination are + locked, only one lock token must be submitted, for the lock on the + destination. This is because the source resource is not modified by + a COPY, and hence unaffected by the write lock. In this example, user + agent authentication has previously occurred via a mechanism outside + the scope of the HTTP protocol, in the underlying transport layer. +

+

+Page 23

+

7.7 Write Locks and COPY/MOVE
+

+ A COPY method invocation MUST NOT duplicate any write locks active on + the source. However, as previously noted, if the COPY copies the + resource into a collection that is locked with "Depth: infinity", + then the resource will be added to the lock. +

+ A successful MOVE request on a write locked resource MUST NOT move + the write lock with the resource. However, the resource is subject to + being added to an existing lock at the destination, as specified in + section 7.5. For example, if the MOVE makes the resource a child of a + collection that is locked with "Depth: infinity", then the resource + will be added to that collection's lock. Additionally, if a resource + locked with "Depth: infinity" is moved to a destination that is + within the scope of the same lock (e.g., within the namespace tree + covered by the lock), the moved resource will again be a added to the + lock. In both these examples, as specified in section 7.6, an If + header must be submitted containing a lock token for both the source + and destination. +

+

7.8 Refreshing Write Locks
+

+ A client MUST NOT submit the same write lock request twice. Note + that a client is always aware it is resubmitting the same lock + request because it must include the lock token in the If header in + order to make the request for a resource that is already locked. +

+ However, a client may submit a LOCK method with an If header but + without a body. This form of LOCK MUST only be used to "refresh" a + lock. Meaning, at minimum, that any timers associated with the lock + MUST be re-set. +

+ A server may return a Timeout header with a lock refresh that is + different than the Timeout header returned when the lock was + originally requested. Additionally clients may submit Timeout + headers of arbitrary value with their lock refresh requests. + Servers, as always, may ignore Timeout headers submitted by the + client. +

+ If an error is received in response to a refresh LOCK request the + client SHOULD assume that the lock was not refreshed. +

+

8 HTTP Methods for Distributed Authoring
+

+ The following new HTTP methods use XML as a request and response + format. All DAV compliant clients and resources MUST use XML parsers + that are compliant with [REC-XML]. All XML used in either requests + or responses MUST be, at minimum, well formed. If a server receives +

+

+Page 24

+ ill-formed XML in a request it MUST reject the entire request with a + 400 (Bad Request). If a client receives ill-formed XML in a response + then it MUST NOT assume anything about the outcome of the executed + method and SHOULD treat the server as malfunctioning. +

+

8.1 PROPFIND
+

+ The PROPFIND method retrieves properties defined on the resource + identified by the Request-URI, if the resource does not have any + internal members, or on the resource identified by the Request-URI + and potentially its member resources, if the resource is a collection + that has internal member URIs. All DAV compliant resources MUST + support the PROPFIND method and the propfind XML element (section + 12.14) along with all XML elements defined for use with that element. +

+ A client may submit a Depth header with a value of "0", "1", or + "infinity" with a PROPFIND on a collection resource with internal + member URIs. DAV compliant servers MUST support the "0", "1" and + "infinity" behaviors. By default, the PROPFIND method without a Depth + header MUST act as if a "Depth: infinity" header was included. +

+ A client may submit a propfind XML element in the body of the request + method describing what information is being requested. It is + possible to request particular property values, all property values, + or a list of the names of the resource's properties. A client may + choose not to submit a request body. An empty PROPFIND request body + MUST be treated as a request for the names and values of all + properties. +

+ All servers MUST support returning a response of content type + text/xml or application/xml that contains a multistatus XML element + that describes the results of the attempts to retrieve the various + properties. +

+ If there is an error retrieving a property then a proper error result + MUST be included in the response. A request to retrieve the value of + a property which does not exist is an error and MUST be noted, if the + response uses a multistatus XML element, with a response XML element + which contains a 404 (Not Found) status value. +

+ Consequently, the multistatus XML element for a collection resource + with member URIs MUST include a response XML element for each member + URI of the collection, to whatever depth was requested. Each response + XML element MUST contain an href XML element that gives the URI of + the resource on which the properties in the prop XML element are + defined. Results for a PROPFIND on a collection resource with + internal member URIs are returned as a flat list whose order of + entries is not significant. +

+

+Page 25

+ In the case of allprop and propname, if a principal does not have the + right to know whether a particular property exists then the property + should be silently excluded from the response. +

+ The results of this method SHOULD NOT be cached. +

+

8.1.1 Example - Retrieving Named Properties
+

+ >>Request +

+ PROPFIND /file HTTP/1.1 +
+ Host: www.foo.bar +
+ Content-type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:">
+     <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+          <R:bigbox/>
+          <R:author/>
+          <R:DingALing/>
+          <R:Random/>
+     </D:prop>
+   </D:propfind>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:">
+     <D:response>
+          <D:href>http://www.foo.bar/file>
+          <D:propstat>
+               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox>
+                         <R:BoxType>Box type A</R:BoxType>
+                    </R:bigbox>
+                    <R:author>
+                         <R:Name>J.J. Johnson</R:Name>
+                    </R:author>
+               </D:prop>
+               <D:status>HTTP/1.1 200 OK</D:status>
+          </D:propstat>
+          <D:propstat>
+               <D:prop><R:DingALing/><R:Random/></D:prop>
+
+

+

+Page 26

+

               <D:status>HTTP/1.1 403 Forbidden</D:status>
+               <D:responsedescription> The user does not have access to
+   the DingALing property.
+               </D:responsedescription>
+          </D:propstat>
+     </D:response>
+     <D:responsedescription> There has been an access violation error.
+     </D:responsedescription>
+   </D:multistatus>
+
+

+ In this example, PROPFIND is executed on a non-collection resource + http://www.foo.bar/file. The propfind XML element specifies the name + of four properties whose values are being requested. In this case + only two properties were returned, since the principal issuing the + request did not have sufficient access rights to see the third and + fourth properties. +

+

8.1.2 Example - Using allprop to Retrieve All Properties
+

+ >>Request +

+ PROPFIND /container/ HTTP/1.1 +
+ Host: www.foo.bar +
+ Depth: 1 +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:">
+     <D:allprop/>
+   </D:propfind>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:">
+     <D:response>
+          <D:href>http://www.foo.bar/container/>
+          <D:propstat>
+               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox>
+                         <R:BoxType>Box type A</R:BoxType>
+                    </R:bigbox>
+                    <R:author>
+
+

+

+Page 27

+

                         <R:Name>Hadrian</R:Name>
+                    </R:author>
+                    <D:creationdate>
+                         1997-12-01T17:42:21-08:00
+                    </D:creationdate>
+                    <D:displayname>
+                         Example collection
+                    </D:displayname>
+                    <D:resourcetype><D:collection/></D:resourcetype>
+                    <D:supportedlock>
+                         <D:lockentry>
+                              <D:lockscope><D:exclusive/></D:lockscope>
+                              <D:locktype><D:write/></D:locktype>
+                         </D:lockentry>
+                         <D:lockentry>
+                              <D:lockscope><D:shared/></D:lockscope>
+                              <D:locktype><D:write/></D:locktype>
+                         </D:lockentry>
+                    </D:supportedlock>
+               </D:prop>
+               <D:status>HTTP/1.1 200 OK</D:status>
+          </D:propstat>
+     </D:response>
+     <D:response>
+          <D:href>http://www.foo.bar/container/front.html>
+          <D:propstat>
+               <D:prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox>
+                         <R:BoxType>Box type B</R:BoxType>
+                    </R:bigbox>
+                    <D:creationdate>
+                         1997-12-01T18:27:21-08:00
+                    </D:creationdate>
+                    <D:displayname>
+                         Example HTML resource
+                    </D:displayname>
+                    <D:getcontentlength>
+                         4525
+                    </D:getcontentlength>
+                    <D:getcontenttype>
+                         text/html
+                    </D:getcontenttype>
+                    <D:getetag>
+                         zzyzx
+                    </D:getetag>
+                    <D:getlastmodified>
+                         Monday, 12-Jan-98 09:25:56 GMT
+                    </D:getlastmodified>
+
+

+

+Page 28

+

                    <D:resourcetype/>
+                    <D:supportedlock>
+                         <D:lockentry>
+                              <D:lockscope><D:exclusive/></D:lockscope>
+                              <D:locktype><D:write/></D:locktype>
+                         </D:lockentry>
+                         <D:lockentry>
+                              <D:lockscope><D:shared/></D:lockscope>
+                              <D:locktype><D:write/></D:locktype>
+                         </D:lockentry>
+                    </D:supportedlock>
+               </D:prop>
+               <D:status>HTTP/1.1 200 OK</D:status>
+          </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+

+ In this example, PROPFIND was invoked on the resource +
+ http://www.foo.bar/container/ with a Depth header of 1, meaning the + request applies to the resource and its children, and a propfind XML + element containing the allprop XML element, meaning the request + should return the name and value of all properties defined on each + resource. +

+ The resource http://www.foo.bar/container/ has six properties defined + on it: +

+ http://www.foo.bar/boxschema/bigbox, +
+ http://www.foo.bar/boxschema/author, DAV:creationdate, +
+ DAV:displayname, DAV:resourcetype, and DAV:supportedlock. +

+ The last four properties are WebDAV-specific, defined in section 13. + Since GET is not supported on this resource, the get* properties + (e.g., getcontentlength) are not defined on this resource. The DAV- + specific properties assert that "container" was created on December + 1, 1997, at 5:42:21PM, in a time zone 8 hours west of GMT + (creationdate), has a name of "Example collection" (displayname), a + collection resource type (resourcetype), and supports exclusive write + and shared write locks (supportedlock). +

+ The resource http://www.foo.bar/container/front.html has nine + properties defined on it: +

+ http://www.foo.bar/boxschema/bigbox (another instance of the "bigbox" + property type), DAV:creationdate, DAV:displayname, +
+ DAV:getcontentlength, DAV:getcontenttype, DAV:getetag, +
+ DAV:getlastmodified, DAV:resourcetype, and DAV:supportedlock. +

+

+Page 29

+ The DAV-specific properties assert that "front.html" was created on + December 1, 1997, at 6:27:21PM, in a time zone 8 hours west of GMT + (creationdate), has a name of "Example HTML resource" (displayname), + a content length of 4525 bytes (getcontentlength), a MIME type of + "text/html" (getcontenttype), an entity tag of "zzyzx" (getetag), was + last modified on Monday, January 12, 1998, at 09:25:56 GMT + (getlastmodified), has an empty resource type, meaning that it is not + a collection (resourcetype), and supports both exclusive write and + shared write locks (supportedlock). +

+

8.1.3 Example - Using propname to Retrieve all Property Names
+

+ >>Request +

+ PROPFIND /container/ HTTP/1.1 +
+ Host: www.foo.bar +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <propfind xmlns="DAV:">
+     <propname/>
+   </propfind>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <multistatus xmlns="DAV:">
+     <response>
+          <href>http://www.foo.bar/container/>
+          <propstat>
+               <prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox/>
+                    <R:author/>
+                    <creationdate/>
+                    <displayname/>
+                    <resourcetype/>
+                    <supportedlock/>
+               </prop>
+               <status>HTTP/1.1 200 OK</status>
+          </propstat>
+     </response>
+     <response>
+          <href>http://www.foo.bar/container/front.html>
+
+

+

+Page 30

+

          <propstat>
+               <prop xmlns:R="http://www.foo.bar/boxschema/">
+                    <R:bigbox/>
+                    <creationdate/>
+                    <displayname/>
+                    <getcontentlength/>
+                    <getcontenttype/>
+                    <getetag/>
+                    <getlastmodified/>
+                    <resourcetype/>
+                    <supportedlock/>
+               </prop>
+               <status>HTTP/1.1 200 OK</status>
+          </propstat>
+     </response>
+   </multistatus>
+
+

+ In this example, PROPFIND is invoked on the collection resource + http://www.foo.bar/container/, with a propfind XML element containing + the propname XML element, meaning the name of all properties should + be returned. Since no Depth header is present, it assumes its + default value of "infinity", meaning the name of the properties on + the collection and all its progeny should be returned. +

+ Consistent with the previous example, resource +
+ http://www.foo.bar/container/ has six properties defined on it, + http://www.foo.bar/boxschema/bigbox, +
+ http://www.foo.bar/boxschema/author, DAV:creationdate, +
+ DAV:displayname, DAV:resourcetype, and DAV:supportedlock. +

+ The resource http://www.foo.bar/container/index.html, a member of the + "container" collection, has nine properties defined on it, + http://www.foo.bar/boxschema/bigbox, DAV:creationdate, +
+ DAV:displayname, DAV:getcontentlength, DAV:getcontenttype, + DAV:getetag, DAV:getlastmodified, DAV:resourcetype, and +
+ DAV:supportedlock. +

+ This example also demonstrates the use of XML namespace scoping, and + the default namespace. Since the "xmlns" attribute does not contain + an explicit "shorthand name" (prefix) letter, the namespace applies + by default to all enclosed elements. Hence, all elements which do + not explicitly state the namespace to which they belong are members + of the "DAV:" namespace schema. +

+

+Page 31

+

8.2 PROPPATCH
+

+ The PROPPATCH method processes instructions specified in the request + body to set and/or remove properties defined on the resource + identified by the Request-URI. +

+ All DAV compliant resources MUST support the PROPPATCH method and + MUST process instructions that are specified using the +
+ propertyupdate, set, and remove XML elements of the DAV schema. + Execution of the directives in this method is, of course, subject to + access control constraints. DAV compliant resources SHOULD support + the setting of arbitrary dead properties. +

+ The request message body of a PROPPATCH method MUST contain the + propertyupdate XML element. Instruction processing MUST occur in the + order instructions are received (i.e., from top to bottom). + Instructions MUST either all be executed or none executed. Thus if + any error occurs during processing all executed instructions MUST be + undone and a proper error result returned. Instruction processing + details can be found in the definition of the set and remove + instructions in section 12.13. +

+

8.2.1 Status Codes for use with 207 (Multi-Status)
+

+ The following are examples of response codes one would expect to be + used in a 207 (Multi-Status) response for this method. Note, + however, that unless explicitly prohibited any 2/3/4/5xx series + response code may be used in a 207 (Multi-Status) response. +

+ 200 (OK) - The command succeeded. As there can be a mixture of sets + and removes in a body, a 201 (Created) seems inappropriate. +

+ 403 (Forbidden) - The client, for reasons the server chooses not to + specify, cannot alter one of the properties. +

+ 409 (Conflict) - The client has provided a value whose semantics are + not appropriate for the property. This includes trying to set read- + only properties. +

+ 423 (Locked) - The specified resource is locked and the client either + is not a lock owner or the lock type requires a lock token to be + submitted and the client did not submit it. +

+ 507 (Insufficient Storage) - The server did not have sufficient space + to record the property. +

+

+Page 32

+

8.2.2 Example - PROPPATCH
+

+ >>Request +

+ PROPPATCH /bar.html HTTP/1.1 +
+ Host: www.foo.com +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propertyupdate xmlns:D="DAV:"
+   xmlns:Z="http://www.w3.com/standards/z39.50/">
+     <D:set>
+          <D:prop>
+               <Z:authors>
+                    <Z:Author>Jim Whitehead</Z:Author>
+                    <Z:Author>Roy Fielding</Z:Author>
+               </Z:authors>
+          </D:prop>
+     </D:set>
+     <D:remove>
+          <D:prop><Z:Copyright-Owner/></D:prop>
+     </D:remove>
+   </D:propertyupdate>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:"
+   xmlns:Z="http://www.w3.com/standards/z39.50">
+     <D:response>
+          <D:href>http://www.foo.com/bar.html>
+          <D:propstat>
+               <D:prop><Z:Authors/></D:prop>
+               <D:status>HTTP/1.1 424 Failed Dependency</D:status>
+          </D:propstat>
+          <D:propstat>
+               <D:prop><Z:Copyright-Owner/></D:prop>
+               <D:status>HTTP/1.1 409 Conflict</D:status>
+          </D:propstat>
+          <D:responsedescription> Copyright Owner can not be deleted or
+   altered.</D:responsedescription>
+     </D:response>
+   </D:multistatus>
+
+

+

+Page 33

+ In this example, the client requests the server to set the value of + the http://www.w3.com/standards/z39.50/Authors property, and to + remove the property http://www.w3.com/standards/z39.50/Copyright- + Owner. Since the Copyright-Owner property could not be removed, no + property modifications occur. The 424 (Failed Dependency) status + code for the Authors property indicates this action would have + succeeded if it were not for the conflict with removing the + Copyright-Owner property. +

+

8.3 MKCOL Method
+

+ The MKCOL method is used to create a new collection. All DAV + compliant resources MUST support the MKCOL method. +

+

8.3.1 Request
+

+ MKCOL creates a new collection resource at the location specified by + the Request-URI. If the resource identified by the Request-URI is + non-null then the MKCOL MUST fail. During MKCOL processing, a server + MUST make the Request-URI a member of its parent collection, unless + the Request-URI is "/". If no such ancestor exists, the method MUST + fail. When the MKCOL operation creates a new collection resource, + all ancestors MUST already exist, or the method MUST fail with a 409 + (Conflict) status code. For example, if a request to create + collection /a/b/c/d/ is made, and neither /a/b/ nor /a/b/c/ exists, + the request must fail. +

+ When MKCOL is invoked without a request body, the newly created + collection SHOULD have no members. +

+ A MKCOL request message may contain a message body. The behavior of + a MKCOL request when the body is present is limited to creating + collections, members of a collection, bodies of members and + properties on the collections or members. If the server receives a + MKCOL request entity type it does not support or understand it MUST + respond with a 415 (Unsupported Media Type) status code. The exact + behavior of MKCOL for various request media types is undefined in + this document, and will be specified in separate documents. +

+

8.3.2 Status Codes
+

+ Responses from a MKCOL request MUST NOT be cached as MKCOL has non- + idempotent semantics. +

+ 201 (Created) - The collection or structured resource was created in + its entirety. +

+

+Page 34

+ 403 (Forbidden) - This indicates at least one of two conditions: 1) + the server does not allow the creation of collections at the given + location in its namespace, or 2) the parent collection of the + Request-URI exists but cannot accept members. +

+ 405 (Method Not Allowed) - MKCOL can only be executed on a + deleted/non-existent resource. +

+ 409 (Conflict) - A collection cannot be made at the Request-URI until + one or more intermediate collections have been created. +

+ 415 (Unsupported Media Type)- The server does not support the request + type of the body. +

+ 507 (Insufficient Storage) - The resource does not have sufficient + space to record the state of the resource after the execution of this + method. +

+

8.3.3 Example - MKCOL
+

+ This example creates a collection called /webdisc/xfiles/ on the + server www.server.org. +

+ >>Request +

+ MKCOL /webdisc/xfiles/ HTTP/1.1 +
+ Host: www.server.org +

+ >>Response +

+ HTTP/1.1 201 Created +

+

8.4 GET, HEAD for Collections
+

+ The semantics of GET are unchanged when applied to a collection, + since GET is defined as, "retrieve whatever information (in the form + of an entity) is identified by the Request-URI" [RFC2068]. GET when + applied to a collection may return the contents of an "index.html" + resource, a human-readable view of the contents of the collection, or + something else altogether. Hence it is possible that the result of a + GET on a collection will bear no correlation to the membership of the + collection. +

+ Similarly, since the definition of HEAD is a GET without a response + message body, the semantics of HEAD are unmodified when applied to + collection resources. +

+

+Page 35

+

8.5 POST for Collections
+

+ Since by definition the actual function performed by POST is + determined by the server and often depends on the particular + resource, the behavior of POST when applied to collections cannot be + meaningfully modified because it is largely undefined. Thus the + semantics of POST are unmodified when applied to a collection. +

+

8.6 DELETE
+

+

8.6.1 DELETE for Non-Collection Resources
+

+ If the DELETE method is issued to a non-collection resource whose + URIs are an internal member of one or more collections, then during + DELETE processing a server MUST remove any URI for the resource + identified by the Request-URI from collections which contain it as a + member. +

+

8.6.2 DELETE for Collections
+

+ The DELETE method on a collection MUST act as if a "Depth: infinity" + header was used on it. A client MUST NOT submit a Depth header with + a DELETE on a collection with any value but infinity. +

+ DELETE instructs that the collection specified in the Request-URI and + all resources identified by its internal member URIs are to be + deleted. +

+ If any resource identified by a member URI cannot be deleted then all + of the member's ancestors MUST NOT be deleted, so as to maintain + namespace consistency. +

+ Any headers included with DELETE MUST be applied in processing every + resource to be deleted. +

+ When the DELETE method has completed processing it MUST result in a + consistent namespace. +

+ If an error occurs with a resource other than the resource identified + in the Request-URI then the response MUST be a 207 (Multi-Status). + 424 (Failed Dependency) errors SHOULD NOT be in the 207 (Multi- + Status). They can be safely left out because the client will know + that the ancestors of a resource could not be deleted when the client + receives an error for the ancestor's progeny. Additionally 204 (No + Content) errors SHOULD NOT be returned in the 207 (Multi-Status). + The reason for this prohibition is that 204 (No Content) is the + default success code. +

+

+Page 36

+

8.6.2.1 Example - DELETE
+

+ >>Request +

+ DELETE /container/ HTTP/1.1 +
+ Host: www.foo.bar +

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <d:multistatus xmlns:d="DAV:">
+     <d:response>
+          <d:href>http://www.foo.bar/container/resource3>
+          <d:status>HTTP/1.1 423 Locked</d:status>
+     </d:response>
+   </d:multistatus>
+
+

+ In this example the attempt to delete +
+ http://www.foo.bar/container/resource3 failed because it is locked, + and no lock token was submitted with the request. Consequently, the + attempt to delete http://www.foo.bar/container/ also failed. Thus the + client knows that the attempt to delete http://www.foo.bar/container/ + must have also failed since the parent can not be deleted unless its + child has also been deleted. Even though a Depth header has not been + included, a depth of infinity is assumed because the method is on a + collection. +

+

8.7 PUT
+

+

8.7.1 PUT for Non-Collection Resources
+

+ A PUT performed on an existing resource replaces the GET response + entity of the resource. Properties defined on the resource may be + recomputed during PUT processing but are not otherwise affected. For + example, if a server recognizes the content type of the request body, + it may be able to automatically extract information that could be + profitably exposed as properties. +

+ A PUT that would result in the creation of a resource without an + appropriately scoped parent collection MUST fail with a 409 + (Conflict). +

+

+Page 37

+

8.7.2 PUT for Collections
+

+ As defined in the HTTP/1.1 specification [RFC2068], the "PUT method + requests that the enclosed entity be stored under the supplied + Request-URI." Since submission of an entity representing a + collection would implicitly encode creation and deletion of + resources, this specification intentionally does not define a + transmission format for creating a collection using PUT. Instead, + the MKCOL method is defined to create collections. +

+ When the PUT operation creates a new non-collection resource all + ancestors MUST already exist. If all ancestors do not exist, the + method MUST fail with a 409 (Conflict) status code. For example, if + resource /a/b/c/d.html is to be created and /a/b/c/ does not exist, + then the request must fail. +

+

8.8 COPY Method
+

+ The COPY method creates a duplicate of the source resource, + identified by the Request-URI, in the destination resource, + identified by the URI in the Destination header. The Destination + header MUST be present. The exact behavior of the COPY method + depends on the type of the source resource. +

+ All WebDAV compliant resources MUST support the COPY method. + However, support for the COPY method does not guarantee the ability + to copy a resource. For example, separate programs may control + resources on the same server. As a result, it may not be possible to + copy a resource to a location that appears to be on the same server. +

+

8.8.1 COPY for HTTP/1.1 resources
+

+ When the source resource is not a collection the result of the COPY + method is the creation of a new resource at the destination whose + state and behavior match that of the source resource as closely as + possible. After a successful COPY invocation, all properties on the + source resource MUST be duplicated on the destination resource, + subject to modifying headers and XML elements, following the + definition for copying properties. Since the environment at the + destination may be different than at the source due to factors + outside the scope of control of the server, such as the absence of + resources required for correct operation, it may not be possible to + completely duplicate the behavior of the resource at the destination. + Subsequent alterations to the destination resource will not modify + the source resource. Subsequent alterations to the source resource + will not modify the destination resource. +

+

+Page 38

+

8.8.2 COPY for Properties
+

+ The following section defines how properties on a resource are + handled during a COPY operation. +

+ Live properties SHOULD be duplicated as identically behaving live + properties at the destination resource. If a property cannot be + copied live, then its value MUST be duplicated, octet-for-octet, in + an identically named, dead property on the destination resource + subject to the effects of the propertybehavior XML element. +

+ The propertybehavior XML element can specify that properties are + copied on best effort, that all live properties must be successfully + copied or the method must fail, or that a specified list of live + properties must be successfully copied or the method must fail. The + propertybehavior XML element is defined in section 12.12. +

+

8.8.3 COPY for Collections
+

+ The COPY method on a collection without a Depth header MUST act as if + a Depth header with value "infinity" was included. A client may + submit a Depth header on a COPY on a collection with a value of "0" + or "infinity". DAV compliant servers MUST support the "0" and + "infinity" Depth header behaviors. +

+ A COPY of depth infinity instructs that the collection resource + identified by the Request-URI is to be copied to the location + identified by the URI in the Destination header, and all its internal + member resources are to be copied to a location relative to it, + recursively through all levels of the collection hierarchy. +

+ A COPY of "Depth: 0" only instructs that the collection and its + properties but not resources identified by its internal member URIs, + are to be copied. +

+ Any headers included with a COPY MUST be applied in processing every + resource to be copied with the exception of the Destination header. +

+ The Destination header only specifies the destination URI for the + Request-URI. When applied to members of the collection identified by + the Request-URI the value of Destination is to be modified to reflect + the current location in the hierarchy. So, if the Request- URI is +

   /a/ with Host header value http://fun.com/ and the Destination is
+   http://fun.com/b/ then when http://fun.com/a/c/d is processed it must
+   use a Destination of http://fun.com/b/c/d.
+
+

+

+Page 39

+ When the COPY method has completed processing it MUST have created a + consistent namespace at the destination (see section 5.1 for the + definition of namespace consistency). However, if an error occurs + while copying an internal collection, the server MUST NOT copy any + resources identified by members of this collection (i.e., the server + must skip this subtree), as this would create an inconsistent + namespace. After detecting an error, the COPY operation SHOULD try to + finish as much of the original copy operation as possible (i.e., the + server should still attempt to copy other subtrees and their members, + that are not descendents of an error-causing collection). So, for + example, if an infinite depth copy operation is performed on + collection /a/, which contains collections /a/b/ and /a/c/, and an + error occurs copying /a/b/, an attempt should still be made to copy +

   /a/c/. Similarly, after encountering an error copying a non-
+   collection resource as part of an infinite depth copy, the server
+   SHOULD try to finish as much of the original copy operation as
+   possible.
+
+

+ If an error in executing the COPY method occurs with a resource other + than the resource identified in the Request-URI then the response + MUST be a 207 (Multi-Status). +

+ The 424 (Failed Dependency) status code SHOULD NOT be returned in the + 207 (Multi-Status) response from a COPY method. These responses can + be safely omitted because the client will know that the progeny of a + resource could not be copied when the client receives an error for + the parent. Additionally 201 (Created)/204 (No Content) status codes + SHOULD NOT be returned as values in 207 (Multi-Status) responses from + COPY methods. They, too, can be safely omitted because they are the + default success codes. +

+

8.8.4 COPY and the Overwrite Header
+

+ If a resource exists at the destination and the Overwrite header is + "T" then prior to performing the copy the server MUST perform a + DELETE with "Depth: infinity" on the destination resource. If the + Overwrite header is set to "F" then the operation will fail. +

+

8.8.5 Status Codes
+

+ 201 (Created) - The source resource was successfully copied. The + copy operation resulted in the creation of a new resource. +

+ 204 (No Content) - The source resource was successfully copied to a + pre-existing destination resource. +

+ 403 (Forbidden) _ The source and destination URIs are the same. +

+

+Page 40

+ 409 (Conflict) _ A resource cannot be created at the destination + until one or more intermediate collections have been created. +

+ 412 (Precondition Failed) - The server was unable to maintain the + liveness of the properties listed in the propertybehavior XML element + or the Overwrite header is "F" and the state of the destination + resource is non-null. +

+ 423 (Locked) - The destination resource was locked. +

+ 502 (Bad Gateway) - This may occur when the destination is on another + server and the destination server refuses to accept the resource. +

+ 507 (Insufficient Storage) - The destination resource does not have + sufficient space to record the state of the resource after the + execution of this method. +

+

8.8.6 Example - COPY with Overwrite
+

+ This example shows resource +
+ http://www.ics.uci.edu/~fielding/index.html being copied to the + location http://www.ics.uci.edu/users/f/fielding/index.html. The 204 + (No Content) status code indicates the existing resource at the + destination was overwritten. +

+ >>Request +

+ COPY /~fielding/index.html HTTP/1.1 +
+ Host: www.ics.uci.edu +
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html +

+ >>Response +

+ HTTP/1.1 204 No Content +

+

8.8.7 Example - COPY with No Overwrite
+

+ The following example shows the same copy operation being performed, + but with the Overwrite header set to "F." A response of 412 + (Precondition Failed) is returned because the destination resource + has a non-null state. +

+ >>Request +

+ COPY /~fielding/index.html HTTP/1.1 +
+ Host: www.ics.uci.edu +
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html + Overwrite: F +

+

+Page 41

+ >>Response +

+ HTTP/1.1 412 Precondition Failed +

+

8.8.8 Example - COPY of a Collection
+

+ >>Request +

+ COPY /container/ HTTP/1.1 +
+ Host: www.foo.bar +
+ Destination: http://www.foo.bar/othercontainer/ +
+ Depth: infinity +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

      <?xml version="1.0" encoding="utf-8" ?>
+      <d:propertybehavior xmlns:d="DAV:">
+        <d:keepalive>*</d:keepalive>
+      </d:propertybehavior>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

      <?xml version="1.0" encoding="utf-8" ?>
+      <d:multistatus xmlns:d="DAV:">
+        <d:response>
+             <d:href>http://www.foo.bar/othercontainer/R2/>
+             <d:status>HTTP/1.1 412 Precondition Failed</d:status>
+        </d:response>
+      </d:multistatus>
+
+

+ The Depth header is unnecessary as the default behavior of COPY on a + collection is to act as if a "Depth: infinity" header had been + submitted. In this example most of the resources, along with the + collection, were copied successfully. However the collection R2 + failed, most likely due to a problem with maintaining the liveness of + properties (this is specified by the propertybehavior XML element). + Because there was an error copying R2, none of R2's members were + copied. However no errors were listed for those members due to the + error minimization rules given in section 8.8.3. +

+

+Page 42

+

8.9 MOVE Method
+

+ The MOVE operation on a non-collection resource is the logical + equivalent of a copy (COPY), followed by consistency maintenance + processing, followed by a delete of the source, where all three + actions are performed atomically. The consistency maintenance step + allows the server to perform updates caused by the move, such as + updating all URIs other than the Request-URI which identify the + source resource, to point to the new destination resource. + Consequently, the Destination header MUST be present on all MOVE + methods and MUST follow all COPY requirements for the COPY part of + the MOVE method. All DAV compliant resources MUST support the MOVE + method. However, support for the MOVE method does not guarantee the + ability to move a resource to a particular destination. +

+ For example, separate programs may actually control different sets of + resources on the same server. Therefore, it may not be possible to + move a resource within a namespace that appears to belong to the same + server. +

+ If a resource exists at the destination, the destination resource + will be DELETEd as a side-effect of the MOVE operation, subject to + the restrictions of the Overwrite header. +

+

8.9.1 MOVE for Properties
+

+ The behavior of properties on a MOVE, including the effects of the + propertybehavior XML element, MUST be the same as specified in + section 8.8.2. +

+

8.9.2 MOVE for Collections
+

+ A MOVE with "Depth: infinity" instructs that the collection + identified by the Request-URI be moved to the URI specified in the + Destination header, and all resources identified by its internal + member URIs are to be moved to locations relative to it, recursively + through all levels of the collection hierarchy. +

+ The MOVE method on a collection MUST act as if a "Depth: infinity" + header was used on it. A client MUST NOT submit a Depth header on a + MOVE on a collection with any value but "infinity". +

+ Any headers included with MOVE MUST be applied in processing every + resource to be moved with the exception of the Destination header. +

+ The behavior of the Destination header is the same as given for COPY + on collections. +

+

+Page 43

+ When the MOVE method has completed processing it MUST have created a + consistent namespace at both the source and destination (see section + 5.1 for the definition of namespace consistency). However, if an + error occurs while moving an internal collection, the server MUST NOT + move any resources identified by members of the failed collection + (i.e., the server must skip the error-causing subtree), as this would + create an inconsistent namespace. In this case, after detecting the + error, the move operation SHOULD try to finish as much of the + original move as possible (i.e., the server should still attempt to + move other subtrees and the resources identified by their members, + that are not descendents of an error-causing collection). So, for + example, if an infinite depth move is performed on collection /a/, + which contains collections /a/b/ and /a/c/, and an error occurs + moving /a/b/, an attempt should still be made to try moving /a/c/. + Similarly, after encountering an error moving a non-collection + resource as part of an infinite depth move, the server SHOULD try to + finish as much of the original move operation as possible. +

+ If an error occurs with a resource other than the resource identified + in the Request-URI then the response MUST be a 207 (Multi-Status). +

+ The 424 (Failed Dependency) status code SHOULD NOT be returned in the + 207 (Multi-Status) response from a MOVE method. These errors can be + safely omitted because the client will know that the progeny of a + resource could not be moved when the client receives an error for the + parent. Additionally 201 (Created)/204 (No Content) responses SHOULD + NOT be returned as values in 207 (Multi-Status) responses from a + MOVE. These responses can be safely omitted because they are the + default success codes. +

+

8.9.3 MOVE and the Overwrite Header
+

+ If a resource exists at the destination and the Overwrite header is + "T" then prior to performing the move the server MUST perform a + DELETE with "Depth: infinity" on the destination resource. If the + Overwrite header is set to "F" then the operation will fail. +

+

8.9.4 Status Codes
+

+ 201 (Created) - The source resource was successfully moved, and a new + resource was created at the destination. +

+ 204 (No Content) - The source resource was successfully moved to a + pre-existing destination resource. +

+ 403 (Forbidden) _ The source and destination URIs are the same. +

+

+Page 44

+ 409 (Conflict) _ A resource cannot be created at the destination + until one or more intermediate collections have been created. +

+ 412 (Precondition Failed) - The server was unable to maintain the + liveness of the properties listed in the propertybehavior XML element + or the Overwrite header is "F" and the state of the destination + resource is non-null. +

+ 423 (Locked) - The source or the destination resource was locked. +

+ 502 (Bad Gateway) - This may occur when the destination is on another + server and the destination server refuses to accept the resource. +

+

8.9.5 Example - MOVE of a Non-Collection
+

+ This example shows resource +
+ http://www.ics.uci.edu/~fielding/index.html being moved to the + location http://www.ics.uci.edu/users/f/fielding/index.html. The + contents of the destination resource would have been overwritten if + the destination resource had been non-null. In this case, since + there was nothing at the destination resource, the response code is + 201 (Created). +

+ >>Request +

+ MOVE /~fielding/index.html HTTP/1.1 +
+ Host: www.ics.uci.edu +
+ Destination: http://www.ics.uci.edu/users/f/fielding/index.html +

+ >>Response +

+ HTTP/1.1 201 Created +
+ Location: http://www.ics.uci.edu/users/f/fielding/index.html +

+

8.9.6 Example - MOVE of a Collection
+

+ >>Request +

+ MOVE /container/ HTTP/1.1 +
+ Host: www.foo.bar +
+ Destination: http://www.foo.bar/othercontainer/ +
+ Overwrite: F +
+ If: (<opaquelocktoken:fe184f2e-6eec-41d0-c765-01adc56e6bb4>) + (<opaquelocktoken:e454f3f3-acdc-452a-56c7-00a5c91e4b77>) + Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

+Page 45

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <d:propertybehavior xmlns:d='DAV:'>
+     <d:keepalive>*</d:keepalive>
+   </d:propertybehavior>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <d:multistatus xmlns:d='DAV:'>
+     <d:response>
+          <d:href>http://www.foo.bar/othercontainer/C2/>
+          <d:status>HTTP/1.1 423 Locked</d:status>
+     </d:response>
+   </d:multistatus>
+
+

+ In this example the client has submitted a number of lock tokens with + the request. A lock token will need to be submitted for every + resource, both source and destination, anywhere in the scope of the + method, that is locked. In this case the proper lock token was not + submitted for the destination http://www.foo.bar/othercontainer/C2/. + This means that the resource /container/C2/ could not be moved. + Because there was an error copying /container/C2/, none of +

   /container/C2's members were copied.  However no errors were listed
+   for those members due to the error minimization rules given in
+   section 8.8.3.  User agent authentication has previously occurred via
+   a mechanism outside the scope of the HTTP protocol, in an underlying
+   transport layer.
+
+

+

8.10 LOCK Method
+

+ The following sections describe the LOCK method, which is used to + take out a lock of any access type. These sections on the LOCK + method describe only those semantics that are specific to the LOCK + method and are independent of the access type of the lock being + requested. +

+ Any resource which supports the LOCK method MUST, at minimum, support + the XML request and response formats defined herein. +

+

+Page 46

+

8.10.1 Operation
+

+ A LOCK method invocation creates the lock specified by the lockinfo + XML element on the Request-URI. Lock method requests SHOULD have a + XML request body which contains an owner XML element for this lock + request, unless this is a refresh request. The LOCK request may have + a Timeout header. +

+ Clients MUST assume that locks may arbitrarily disappear at any time, + regardless of the value given in the Timeout header. The Timeout + header only indicates the behavior of the server if "extraordinary" + circumstances do not occur. For example, an administrator may remove + a lock at any time or the system may crash in such a way that it + loses the record of the lock's existence. The response MUST contain + the value of the lockdiscovery property in a prop XML element. +

+ In order to indicate the lock token associated with a newly created + lock, a Lock-Token response header MUST be included in the response + for every successful LOCK request for a new lock. Note that the + Lock-Token header would not be returned in the response for a + successful refresh LOCK request because a new lock was not created. +

+

8.10.2 The Effect of Locks on Properties and Collections
+

+ The scope of a lock is the entire state of the resource, including + its body and associated properties. As a result, a lock on a + resource MUST also lock the resource's properties. +

+ For collections, a lock also affects the ability to add or remove + members. The nature of the effect depends upon the type of access + control involved. +

+

8.10.3 Locking Replicated Resources
+

+ A resource may be made available through more than one URI. However + locks apply to resources, not URIs. Therefore a LOCK request on a + resource MUST NOT succeed if can not be honored by all the URIs + through which the resource is addressable. +

+

8.10.4 Depth and Locking
+

+ The Depth header may be used with the LOCK method. Values other than + 0 or infinity MUST NOT be used with the Depth header on a LOCK + method. All resources that support the LOCK method MUST support the + Depth header. +

+ A Depth header of value 0 means to just lock the resource specified + by the Request-URI. +

+

+Page 47

+ If the Depth header is set to infinity then the resource specified in + the Request-URI along with all its internal members, all the way down + the hierarchy, are to be locked. A successful result MUST return a + single lock token which represents all the resources that have been + locked. If an UNLOCK is successfully executed on this token, all + associated resources are unlocked. If the lock cannot be granted to + all resources, a 409 (Conflict) status code MUST be returned with a + response entity body containing a multistatus XML element describing + which resource(s) prevented the lock from being granted. Hence, + partial success is not an option. Either the entire hierarchy is + locked or no resources are locked. +

+ If no Depth header is submitted on a LOCK request then the request + MUST act as if a "Depth:infinity" had been submitted. +

+

8.10.5 Interaction with other Methods
+

+ The interaction of a LOCK with various methods is dependent upon the + lock type. However, independent of lock type, a successful DELETE of + a resource MUST cause all of its locks to be removed. +

+

8.10.6 Lock Compatibility Table
+

+ The table below describes the behavior that occurs when a lock + request is made on a resource. +

+

   Current lock state/  |   Shared Lock   |   Exclusive
+   Lock request         |                 |   Lock
+   =====================+=================+==============
+   None                 |   True          |   True
+   ---------------------+-----------------+--------------
+   Shared Lock          |   True          |   False
+   ---------------------+-----------------+--------------
+   Exclusive Lock       |   False         |   False*
+   ------------------------------------------------------
+
+   Legend: True = lock may be granted.  False = lock MUST NOT be
+   granted. *=It is illegal for a principal to request the same lock
+   twice.
+
+

+ The current lock state of a resource is given in the leftmost column, + and lock requests are listed in the first row. The intersection of a + row and column gives the result of a lock request. For example, if a + shared lock is held on a resource, and an exclusive lock is + requested, the table entry is "false", indicating the lock must not + be granted. +

+

+Page 48

+

8.10.7 Status Codes
+

+ 200 (OK) - The lock request succeeded and the value of the + lockdiscovery property is included in the body. +

+ 412 (Precondition Failed) - The included lock token was not + enforceable on this resource or the server could not satisfy the + request in the lockinfo XML element. +

+ 423 (Locked) - The resource is locked, so the method has been + rejected. +

+

8.10.8 Example - Simple Lock Request
+

+ >>Request +

+ LOCK /workspace/webdav/proposal.doc HTTP/1.1 +
+ Host: webdav.sb.aol.com +
+ Timeout: Infinite, Second-4100000000 +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +
+ Authorization: Digest username="ejw", +
+ realm="ejw@webdav.sb.aol.com", nonce="...", +
+ uri="/workspace/webdav/proposal.doc", +
+ response="...", opaque="..." +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:lockinfo xmlns:D='DAV:'>
+     <D:lockscope><D:exclusive/></D:lockscope>
+     <D:locktype><D:write/></D:locktype>
+     <D:owner>
+          <D:href>http://www.ics.uci.edu/~ejw/contact.html>
+     </D:owner>
+   </D:lockinfo>
+
+

+ >>Response +

+ HTTP/1.1 200 OK +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:prop xmlns:D="DAV:">
+     <D:lockdiscovery>
+          <D:activelock>
+               <D:locktype><D:write/></D:locktype>
+               <D:lockscope><D:exclusive/></D:lockscope>
+               <D:depth>Infinity</D:depth>
+
+

+

+Page 49

+

               <D:owner>
+                    <D:href>
+                         http://www.ics.uci.edu/~ejw/contact.html
+                    </D:href>
+               </D:owner>
+               <D:timeout>Second-604800</D:timeout>
+               <D:locktoken>
+                    <D:href>
+               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
+                    </D:href>
+               </D:locktoken>
+          </D:activelock>
+     </D:lockdiscovery>
+   </D:prop>
+
+

+ This example shows the successful creation of an exclusive write lock + on resource http://webdav.sb.aol.com/workspace/webdav/proposal.doc. + The resource http://www.ics.uci.edu/~ejw/contact.html contains + contact information for the owner of the lock. The server has an + activity-based timeout policy in place on this resource, which causes + the lock to automatically be removed after 1 week (604800 seconds). + Note that the nonce, response, and opaque fields have not been + calculated in the Authorization request header. +

+

8.10.9 Example - Refreshing a Write Lock
+

+ >>Request +

+ LOCK /workspace/webdav/proposal.doc HTTP/1.1 +
+ Host: webdav.sb.aol.com +
+ Timeout: Infinite, Second-4100000000 +
+ If: (<opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4>) + Authorization: Digest username="ejw", +
+ realm="ejw@webdav.sb.aol.com", nonce="...", +
+ uri="/workspace/webdav/proposal.doc", +
+ response="...", opaque="..." +

+ >>Response +

+ HTTP/1.1 200 OK +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:prop xmlns:D="DAV:">
+     <D:lockdiscovery>
+          <D:activelock>
+               <D:locktype><D:write/></D:locktype>
+
+

+

+Page 50

+

               <D:lockscope><D:exclusive/></D:lockscope>
+               <D:depth>Infinity</D:depth>
+               <D:owner>
+                    <D:href>
+                    http://www.ics.uci.edu/~ejw/contact.html
+                    </D:href>
+               </D:owner>
+               <D:timeout>Second-604800</D:timeout>
+               <D:locktoken>
+                    <D:href>
+               opaquelocktoken:e71d4fae-5dec-22d6-fea5-00a0c91e6be4
+                    </D:href>
+               </D:locktoken>
+          </D:activelock>
+     </D:lockdiscovery>
+   </D:prop>
+
+

+ This request would refresh the lock, resetting any time outs. Notice + that the client asked for an infinite time out but the server choose + to ignore the request. In this example, the nonce, response, and + opaque fields have not been calculated in the Authorization request + header. +

+

8.10.10 Example - Multi-Resource Lock Request
+

+ >>Request +

+ LOCK /webdav/ HTTP/1.1 +
+ Host: webdav.sb.aol.com +
+ Timeout: Infinite, Second-4100000000 +
+ Depth: infinity +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +
+ Authorization: Digest username="ejw", +
+ realm="ejw@webdav.sb.aol.com", nonce="...", +
+ uri="/workspace/webdav/proposal.doc", +
+ response="...", opaque="..." +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:lockinfo xmlns:D="DAV:">
+     <D:locktype><D:write/></D:locktype>
+     <D:lockscope><D:exclusive/></D:lockscope>
+     <D:owner>
+          <D:href>http://www.ics.uci.edu/~ejw/contact.html>
+     </D:owner>
+   </D:lockinfo>
+
+

+ >>Response +

+

+Page 51

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:">
+     <D:response>
+          <D:href>http://webdav.sb.aol.com/webdav/secret>
+          <D:status>HTTP/1.1 403 Forbidden</D:status>
+     </D:response>
+     <D:response>
+          <D:href>http://webdav.sb.aol.com/webdav/>
+          <D:propstat>
+               <D:prop><D:lockdiscovery/></D:prop>
+               <D:status>HTTP/1.1 424 Failed Dependency</D:status>
+          </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+

+ This example shows a request for an exclusive write lock on a + collection and all its children. In this request, the client has + specified that it desires an infinite length lock, if available, + otherwise a timeout of 4.1 billion seconds, if available. The request + entity body contains the contact information for the principal taking + out the lock, in this case a web page URL. +

+ The error is a 403 (Forbidden) response on the resource +
+ http://webdav.sb.aol.com/webdav/secret. Because this resource could + not be locked, none of the resources were locked. Note also that the + lockdiscovery property for the Request-URI has been included as + required. In this example the lockdiscovery property is empty which + means that there are no outstanding locks on the resource. +

+ In this example, the nonce, response, and opaque fields have not been + calculated in the Authorization request header. +

+

8.11 UNLOCK Method
+

+ The UNLOCK method removes the lock identified by the lock token in + the Lock-Token request header from the Request-URI, and all other + resources included in the lock. If all resources which have been + locked under the submitted lock token can not be unlocked then the + UNLOCK request MUST fail. +

+ Any DAV compliant resource which supports the LOCK method MUST + support the UNLOCK method. +

+

+Page 52

+

8.11.1 Example - UNLOCK
+

+ >>Request +

+ UNLOCK /workspace/webdav/info.doc HTTP/1.1 +
+ Host: webdav.sb.aol.com +
+ Lock-Token: <opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7> + Authorization: Digest username="ejw", +
+ realm="ejw@webdav.sb.aol.com", nonce="...", +
+ uri="/workspace/webdav/proposal.doc", +
+ response="...", opaque="..." +

+ >>Response +

+ HTTP/1.1 204 No Content +

+ In this example, the lock identified by the lock token +
+ "opaquelocktoken:a515cfa4-5da4-22e1-f5b5-00a0451e6bf7" is + successfully removed from the resource +
+ http://webdav.sb.aol.com/workspace/webdav/info.doc. If this lock + included more than just one resource, the lock is removed from all + resources included in the lock. The 204 (No Content) status code is + used instead of 200 (OK) because there is no response entity body. +

+ In this example, the nonce, response, and opaque fields have not been + calculated in the Authorization request header. +

+

9 HTTP Headers for Distributed Authoring
+

+

9.1 DAV Header
+

+

   DAV = "DAV" ":" "1" ["," "2"] ["," 1#extend]
+
+

+ This header indicates that the resource supports the DAV schema and + protocol as specified. All DAV compliant resources MUST return the + DAV header on all OPTIONS responses. +

+ The value is a list of all compliance classes that the resource + supports. Note that above a comma has already been added to the 2. + This is because a resource can not be level 2 compliant unless it is + also level 1 compliant. Please refer to section 15 for more details. + In general, however, support for one compliance class does not entail + support for any other. +

+

9.2 Depth Header
+

+

   Depth = "Depth" ":" ("0" | "1" | "infinity")
+
+

+

+Page 53

+ The Depth header is used with methods executed on resources which + could potentially have internal members to indicate whether the + method is to be applied only to the resource ("Depth: 0"), to the + resource and its immediate children, ("Depth: 1"), or the resource + and all its progeny ("Depth: infinity"). +

+ The Depth header is only supported if a method's definition + explicitly provides for such support. +

+ The following rules are the default behavior for any method that + supports the Depth header. A method may override these defaults by + defining different behavior in its definition. +

+ Methods which support the Depth header may choose not to support all + of the header's values and may define, on a case by case basis, the + behavior of the method if a Depth header is not present. For example, + the MOVE method only supports "Depth: infinity" and if a Depth header + is not present will act as if a "Depth: infinity" header had been + applied. +

+ Clients MUST NOT rely upon methods executing on members of their + hierarchies in any particular order or on the execution being atomic + unless the particular method explicitly provides such guarantees. +

+ Upon execution, a method with a Depth header will perform as much of + its assigned task as possible and then return a response specifying + what it was able to accomplish and what it failed to do. +

+ So, for example, an attempt to COPY a hierarchy may result in some of + the members being copied and some not. +

+ Any headers on a method that has a defined interaction with the Depth + header MUST be applied to all resources in the scope of the method + except where alternative behavior is explicitly defined. For example, + an If-Match header will have its value applied against every resource + in the method's scope and will cause the method to fail if the header + fails to match. +

+ If a resource, source or destination, within the scope of the method + with a Depth header is locked in such a way as to prevent the + successful execution of the method, then the lock token for that + resource MUST be submitted with the request in the If request header. +

+ The Depth header only specifies the behavior of the method with + regards to internal children. If a resource does not have internal + children then the Depth header MUST be ignored. +

+

+Page 54

+ Please note, however, that it is always an error to submit a value + for the Depth header that is not allowed by the method's definition. + Thus submitting a "Depth: 1" on a COPY, even if the resource does not + have internal members, will result in a 400 (Bad Request). The method + should fail not because the resource doesn't have internal members, + but because of the illegal value in the header. +

+

9.3 Destination Header
+

+

   Destination = "Destination" ":" absoluteURI
+
+

+ The Destination header specifies the URI which identifies a + destination resource for methods such as COPY and MOVE, which take + two URIs as parameters. Note that the absoluteURI production is + defined in [RFC2396]. +

+

9.4 If Header
+

+

   If = "If" ":" ( 1*No-tag-list | 1*Tagged-list)
+   No-tag-list = List
+   Tagged-list = Resource 1*List
+   Resource = Coded-URL
+   List = "(" 1*(["Not"](State-token | "[" entity-tag "]")) ")"
+   State-token = Coded-URL
+   Coded-URL = "<" absoluteURI ">"
+
+

+ The If header is intended to have similar functionality to the If- + Match header defined in section 14.25 of [RFC2068]. However the If + header is intended for use with any URI which represents state + information, referred to as a state token, about a resource as well + as ETags. A typical example of a state token is a lock token, and + lock tokens are the only state tokens defined in this specification. +

+ All DAV compliant resources MUST honor the If header. +

+ The If header's purpose is to describe a series of state lists. If + the state of the resource to which the header is applied does not + match any of the specified state lists then the request MUST fail + with a 412 (Precondition Failed). If one of the described state + lists matches the state of the resource then the request may succeed. +

+ Note that the absoluteURI production is defined in [RFC2396]. +

+

+Page 55

+

9.4.1 No-tag-list Production
+

+ The No-tag-list production describes a series of state tokens and + ETags. If multiple No-tag-list productions are used then one only + needs to match the state of the resource for the method to be allowed + to continue. +

+ If a method, due to the presence of a Depth or Destination header, is + applied to multiple resources then the No-tag-list production MUST be + applied to each resource the method is applied to. +

+

9.4.1.1 Example - No-tag-list If Header
+

+ If: (<locktoken:a-write-lock-token> ["I am an ETag"]) (["I am another + ETag"]) +

+ The previous header would require that any resources within the scope + of the method must either be locked with the specified lock token and + in the state identified by the "I am an ETag" ETag or in the state + identified by the second ETag "I am another ETag". To put the matter + more plainly one can think of the previous If header as being in the + form (or (and <locktoken:a-write-lock-token> ["I am an ETag"]) (and + ["I am another ETag"])). +

+

9.4.2 Tagged-list Production
+

+ The tagged-list production scopes a list production. That is, it + specifies that the lists following the resource specification only + apply to the specified resource. The scope of the resource + production begins with the list production immediately following the + resource production and ends with the next resource production, if + any. +

+ When the If header is applied to a particular resource, the Tagged- + list productions MUST be searched to determine if any of the listed + resources match the operand resource(s) for the current method. If + none of the resource productions match the current resource then the + header MUST be ignored. If one of the resource productions does + match the name of the resource under consideration then the list + productions following the resource production MUST be applied to the + resource in the manner specified in the previous section. +

+ The same URI MUST NOT appear more than once in a resource production + in an If header. +

+

+Page 56

+

9.4.2.1 Example - Tagged List If header
+

+ COPY /resource1 HTTP/1.1 +
+ Host: www.foo.bar +
+ Destination: http://www.foo.bar/resource2 +
+ If: <http://www.foo.bar/resource1> (<locktoken:a-write-lock-token> + [W/"A weak ETag"]) (["strong ETag"]) +

   <http://www.bar.bar/random>(["another strong ETag"])
+
+

+ In this example http://www.foo.bar/resource1 is being copied to + http://www.foo.bar/resource2. When the method is first applied to + http://www.foo.bar/resource1, resource1 must be in the state + specified by "(<locktoken:a-write-lock-token> [W/"A weak ETag"]) + (["strong ETag"])", that is, it either must be locked with a lock + token of "locktoken:a-write-lock-token" and have a weak entity tag + W/"A weak ETag" or it must have a strong entity tag "strong ETag". +

+ That is the only success condition since the resource +
+ http://www.bar.bar/random never has the method applied to it (the + only other resource listed in the If header) and +
+ http://www.foo.bar/resource2 is not listed in the If header. +

+

9.4.3 not Production
+

+ Every state token or ETag is either current, and hence describes the + state of a resource, or is not current, and does not describe the + state of a resource. The boolean operation of matching a state token + or ETag to the current state of a resource thus resolves to a true or + false value. The not production is used to reverse that value. The + scope of the not production is the state-token or entity-tag + immediately following it. +

+ If: (Not <locktoken:write1> <locktoken:write2>) +

+ When submitted with a request, this If header requires that all + operand resources must not be locked with locktoken:write1 and must + be locked with locktoken:write2. +

+

9.4.4 Matching Function
+

+ When performing If header processing, the definition of a matching + state token or entity tag is as follows. +

+ Matching entity tag: Where the entity tag matches an entity tag + associated with that resource. +

+ Matching state token: Where there is an exact match between the state + token in the If header and any state token on the resource. +

+

+Page 57

+

9.4.5 If Header and Non-DAV Compliant Proxies
+

+ Non-DAV compliant proxies will not honor the If header, since they + will not understand the If header, and HTTP requires non-understood + headers to be ignored. When communicating with HTTP/1.1 proxies, the + "Cache-Control: no-cache" request header MUST be used so as to + prevent the proxy from improperly trying to service the request from + its cache. When dealing with HTTP/1.0 proxies the "Pragma: no-cache" + request header MUST be used for the same reason. +

+

9.5 Lock-Token Header
+

+

   Lock-Token = "Lock-Token" ":" Coded-URL
+
+

+ The Lock-Token request header is used with the UNLOCK method to + identify the lock to be removed. The lock token in the Lock-Token + request header MUST identify a lock that contains the resource + identified by Request-URI as a member. +

+ The Lock-Token response header is used with the LOCK method to + indicate the lock token created as a result of a successful LOCK + request to create a new lock. +

+

9.6 Overwrite Header
+

+

   Overwrite = "Overwrite" ":" ("T" | "F")
+
+

+ The Overwrite header specifies whether the server should overwrite + the state of a non-null destination resource during a COPY or MOVE. + A value of "F" states that the server must not perform the COPY or + MOVE operation if the state of the destination resource is non-null. + If the overwrite header is not included in a COPY or MOVE request + then the resource MUST treat the request as if it has an overwrite + header of value "T". While the Overwrite header appears to duplicate + the functionality of the If-Match: * header of HTTP/1.1, If-Match + applies only to the Request-URI, and not to the Destination of a COPY + or MOVE. +

+ If a COPY or MOVE is not performed due to the value of the Overwrite + header, the method MUST fail with a 412 (Precondition Failed) status + code. +

+ All DAV compliant resources MUST support the Overwrite header. +

+

9.7 Status-URI Response Header
+

+ The Status-URI response header may be used with the 102 (Processing) + status code to inform the client as to the status of a method. +

+

+Page 58

+

   Status-URI = "Status-URI" ":" *(Status-Code Coded-URL) ; Status-Code
+   is defined in 6.1.1 of [RFC2068]
+
+

+ The URIs listed in the header are source resources which have been + affected by the outstanding method. The status code indicates the + resolution of the method on the identified resource. So, for + example, if a MOVE method on a collection is outstanding and a 102 + (Processing) response with a Status-URI response header is returned, + the included URIs will indicate resources that have had move + attempted on them and what the result was. +

+

9.8 Timeout Request Header
+

+

   TimeOut = "Timeout" ":" 1#TimeType
+   TimeType = ("Second-" DAVTimeOutVal | "Infinite" | Other)
+   DAVTimeOutVal = 1*digit
+   Other = "Extend" field-value   ; See section 4.2 of [RFC2068]
+
+

+ Clients may include Timeout headers in their LOCK requests. However, + the server is not required to honor or even consider these requests. + Clients MUST NOT submit a Timeout request header with any method + other than a LOCK method. +

+ A Timeout request header MUST contain at least one TimeType and may + contain multiple TimeType entries. The purpose of listing multiple + TimeType entries is to indicate multiple different values and value + types that are acceptable to the client. The client lists the + TimeType entries in order of preference. +

+ Timeout response values MUST use a Second value, Infinite, or a + TimeType the client has indicated familiarity with. The server may + assume a client is familiar with any TimeType submitted in a Timeout + header. +

+ The "Second" TimeType specifies the number of seconds that will + elapse between granting of the lock at the server, and the automatic + removal of the lock. The timeout value for TimeType "Second" MUST + NOT be greater than 2^32-1. +

+ The timeout counter SHOULD be restarted any time an owner of the lock + sends a method to any member of the lock, including unsupported + methods, or methods which are unsuccessful. However the lock MUST be + refreshed if a refresh LOCK method is successfully received. +

+ If the timeout expires then the lock may be lost. Specifically, if + the server wishes to harvest the lock upon time-out, the server + SHOULD act as if an UNLOCK method was executed by the server on the + resource using the lock token of the timed-out lock, performed with +

+

+Page 59

+ its override authority. Thus logs should be updated with the + disposition of the lock, notifications should be sent, etc., just as + they would be for an UNLOCK request. +

+ Servers are advised to pay close attention to the values submitted by + clients, as they will be indicative of the type of activity the + client intends to perform. For example, an applet running in a + browser may need to lock a resource, but because of the instability + of the environment within which the applet is running, the applet may + be turned off without warning. As a result, the applet is likely to + ask for a relatively small timeout value so that if the applet dies, + the lock can be quickly harvested. However, a document management + system is likely to ask for an extremely long timeout because its + user may be planning on going off-line. +

+ A client MUST NOT assume that just because the time-out has expired + the lock has been lost. +

+

10 Status Code Extensions to HTTP/1.1
+

+ The following status codes are added to those defined in HTTP/1.1 + [RFC2068]. +

+

10.1 102 Processing
+

+ The 102 (Processing) status code is an interim response used to + inform the client that the server has accepted the complete request, + but has not yet completed it. This status code SHOULD only be sent + when the server has a reasonable expectation that the request will + take significant time to complete. As guidance, if a method is taking + longer than 20 seconds (a reasonable, but arbitrary value) to process + the server SHOULD return a 102 (Processing) response. The server MUST + send a final response after the request has been completed. +

+ Methods can potentially take a long period of time to process, + especially methods that support the Depth header. In such cases the + client may time-out the connection while waiting for a response. To + prevent this the server may return a 102 (Processing) status code to + indicate to the client that the server is still processing the + method. +

+

10.2 207 Multi-Status
+

+ The 207 (Multi-Status) status code provides status for multiple + independent operations (see section 11 for more information). +

+

+Page 60

+

10.3 422 Unprocessable Entity
+

+ The 422 (Unprocessable Entity) status code means the server + understands the content type of the request entity (hence a + 415(Unsupported Media Type) status code is inappropriate), and the + syntax of the request entity is correct (thus a 400 (Bad Request) + status code is inappropriate) but was unable to process the contained + instructions. For example, this error condition may occur if an XML + request body contains well-formed (i.e., syntactically correct), but + semantically erroneous XML instructions. +

+

10.4 423 Locked
+

+ The 423 (Locked) status code means the source or destination resource + of a method is locked. +

+

10.5 424 Failed Dependency
+

+ The 424 (Failed Dependency) status code means that the method could + not be performed on the resource because the requested action + depended on another action and that action failed. For example, if a + command in a PROPPATCH method fails then, at minimum, the rest of the + commands will also fail with 424 (Failed Dependency). +

+

10.6 507 Insufficient Storage
+

+ The 507 (Insufficient Storage) status code means the method could not + be performed on the resource because the server is unable to store + the representation needed to successfully complete the request. This + condition is considered to be temporary. If the request which + received this status code was the result of a user action, the + request MUST NOT be repeated until it is requested by a separate user + action. +

+

11 Multi-Status Response
+

+ The default 207 (Multi-Status) response body is a text/xml or + application/xml HTTP entity that contains a single XML element called + multistatus, which contains a set of XML elements called response + which contain 200, 300, 400, and 500 series status codes generated + during the method invocation. 100 series status codes SHOULD NOT be + recorded in a response XML element. +

+

+Page 61

+

12 XML Element Definitions
+

+ In the section below, the final line of each section gives the + element type declaration using the format defined in [REC-XML]. The + "Value" field, where present, specifies further restrictions on the + allowable contents of the XML element using BNF (i.e., to further + restrict the values of a PCDATA element). +

+

12.1 activelock XML Element
+

+

   Name:       activelock
+   Namespace:  DAV:
+   Purpose:    Describes a lock on a resource.
+
+   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
+   locktoken?) >
+
+

+

12.1.1 depth XML Element
+

+

   Name:       depth
+   Namespace:  DAV:
+   Purpose:    The value of the Depth header.
+   Value:      "0" | "1" | "infinity"
+
+   <!ELEMENT depth (#PCDATA) >
+
+

+

12.1.2 locktoken XML Element
+

+

   Name:       locktoken
+   Namespace:  DAV:
+   Purpose:    The lock token associated with a lock.
+   Description: The href contains one or more opaque lock token URIs
+   which all refer to the same lock (i.e., the OpaqueLockToken-URI
+   production in section 6.4).
+
+   <!ELEMENT locktoken (href+) >
+
+

+

12.1.3 timeout XML Element
+

+

   Name:       timeout
+   Namespace:  DAV:
+   Purpose:    The timeout associated with a lock
+   Value:      TimeType ;Defined in section 9.8
+
+   <!ELEMENT timeout (#PCDATA) >
+
+

+

+Page 62

+

12.2 collection XML Element
+

+

   Name:       collection
+   Namespace:  DAV:
+   Purpose:    Identifies the associated resource as a collection. The
+   resourcetype property of a collection resource MUST have this value.
+
+   <!ELEMENT collection EMPTY >
+
+

+

12.3 href XML Element
+

+

   Name:       href
+   Namespace:  DAV:
+   Purpose:    Identifies the content of the element as a URI.
+   Value:      URI ; See section 3.2.1 of [RFC2068]
+
+   <!ELEMENT href (#PCDATA)>
+
+

+

12.4 link XML Element
+

+

   Name:       link
+   Namespace:  DAV:
+   Purpose:    Identifies the property as a link and contains the source
+   and destination of that link.
+   Description: The link XML element is used to provide the sources and
+   destinations of a link.  The name of the property containing the link
+   XML element provides the type of the link.  Link is a multi-valued
+   element, so multiple links may be used together to indicate multiple
+   links with the same type.  The values in the href XML elements inside
+   the src and dst XML elements of the link XML element MUST NOT be
+   rejected if they point to resources which do not exist.
+
+   <!ELEMENT link (src+, dst+) >
+
+

+

12.4.1 dst XML Element
+

+

   Name:       dst
+   Namespace:  DAV:
+   Purpose:    Indicates the destination of a link
+   Value:      URI
+
+   <!ELEMENT dst (#PCDATA) >
+
+

+

12.4.2 src XML Element
+

+

   Name:       src
+   Namespace:  DAV:
+   Purpose:    Indicates the source of a link.
+
+

+

+Page 63

+

   Value:      URI
+
+   <!ELEMENT src (#PCDATA) >
+
+

+

12.5 lockentry XML Element
+

+

   Name:       lockentry
+   Namespace:  DAV:
+   Purpose:    Defines the types of locks that can be used with the
+   resource.
+
+   <!ELEMENT lockentry (lockscope, locktype) >
+
+

+

12.6 lockinfo XML Element
+

+

   Name:       lockinfo
+   Namespace:  DAV:
+   Purpose:    The lockinfo XML element is used with a LOCK method to
+   specify the type of lock the client wishes to have created.
+
+   <!ELEMENT lockinfo (lockscope, locktype, owner?) >
+
+

+

12.7 lockscope XML Element
+

+

   Name:       lockscope
+   Namespace:  DAV:
+   Purpose:    Specifies whether a lock is an exclusive lock, or a
+   shared lock.
+
+   <!ELEMENT lockscope (exclusive | shared) >
+
+

+

12.7.1 exclusive XML Element
+

+

   Name:       exclusive
+   Namespace:  DAV:
+   Purpose:    Specifies an exclusive lock
+
+   <!ELEMENT exclusive EMPTY >
+
+

+

12.7.2 shared XML Element
+

+

   Name:       shared
+   Namespace:  DAV:
+   Purpose:    Specifies a shared lock
+
+   <!ELEMENT shared EMPTY >
+
+

+

+Page 64

+

12.8 locktype XML Element
+

+

   Name:       locktype
+   Namespace:  DAV:
+   Purpose:    Specifies the access type of a lock.  At present, this
+   specification only defines one lock type, the write lock.
+
+   <!ELEMENT locktype (write) >
+
+

+

12.8.1 write XML Element
+

+

   Name:       write
+   Namespace:  DAV:
+   Purpose:    Specifies a write lock.
+
+   <!ELEMENT write EMPTY >
+
+

+

12.9 multistatus XML Element
+

+

   Name:       multistatus
+   Namespace:  DAV:
+   Purpose:    Contains multiple response messages.
+   Description: The responsedescription at the top level is used to
+   provide a general message describing the overarching nature of the
+   response.  If this value is available an application may use it
+   instead of presenting the individual response descriptions contained
+   within the responses.
+
+   <!ELEMENT multistatus (response+, responsedescription?) >
+
+

+

12.9.1 response XML Element
+

+

   Name:       response
+   Namespace:  DAV:
+   Purpose:    Holds a single response describing the effect of a
+   method on resource and/or its properties.
+   Description: A particular href MUST NOT appear more than once as the
+   child of a response XML element under a multistatus XML element.
+   This requirement is necessary in order to keep processing costs for a
+   response to linear time.  Essentially, this prevents having to search
+   in order to group together all the responses by href.  There are,
+   however, no requirements regarding ordering based on href values.
+
+   <!ELEMENT response (href, ((href*, status)|(propstat+)),
+   responsedescription?) >
+
+

+

+Page 65

+

12.9.1.1 propstat XML Element
+

+

   Name:       propstat
+   Namespace:  DAV:
+   Purpose:    Groups together a prop and status element that is
+   associated with a particular href element.
+   Description: The propstat XML element MUST contain one prop XML
+   element and one status XML element.  The contents of the prop XML
+   element MUST only list the names of properties to which the result in
+   the status element applies.
+
+   <!ELEMENT propstat (prop, status, responsedescription?) >
+
+

+

12.9.1.2 status XML Element
+

+

   Name:       status
+   Namespace:  DAV:
+   Purpose:    Holds a single HTTP status-line
+   Value:      status-line   ;status-line defined in [RFC2068]
+
+   <!ELEMENT status (#PCDATA) >
+
+

+

12.9.2 responsedescription XML Element
+

+

   Name:       responsedescription
+   Namespace:  DAV:
+   Purpose:    Contains a message that can be displayed to the user
+   explaining the nature of the response.
+   Description: This XML element provides information suitable to be
+   presented to a user.
+
+   <!ELEMENT responsedescription (#PCDATA) >
+
+

+

12.10 owner XML Element
+

+

   Name:       owner
+   Namespace:  DAV:
+   Purpose:    Provides information about the principal taking out a
+   lock.
+   Description: The owner XML element provides information sufficient
+   for either directly contacting a principal (such as a telephone
+   number or Email URI), or for discovering the principal (such as the
+   URL of a homepage) who owns a lock.
+
+   <!ELEMENT owner ANY>
+
+

+

+Page 66

+

12.11 prop XML element
+

+

   Name:       prop
+   Namespace:  DAV:
+   Purpose:    Contains properties related to a resource.
+   Description: The prop XML element is a generic container for
+   properties defined on resources.  All elements inside a prop XML
+   element MUST define properties related to the resource.  No other
+   elements may be used inside of a prop element.
+
+   <!ELEMENT prop ANY>
+
+

+

12.12 propertybehavior XML element
+

+

   Name:       propertybehavior Namespace:  DAV:  Purpose:    Specifies
+   how properties are handled during a COPY or MOVE.
+   Description: The propertybehavior XML element specifies how
+   properties are handled during a COPY or MOVE.  If this XML element is
+   not included in the request body then the server is expected to act
+   as defined by the default property handling behavior of the
+   associated method.  All WebDAV compliant resources MUST support the
+   propertybehavior XML element.
+
+   <!ELEMENT propertybehavior (omit | keepalive) >
+
+

+

12.12.1 keepalive XML element
+

+

   Name:       keepalive
+   Namespace:  DAV:
+   Purpose:    Specifies requirements for the copying/moving of live
+   properties.
+   Description: If a list of URIs is included as the value of keepalive
+   then the named properties MUST be "live" after they are copied
+   (moved) to the destination resource of a COPY (or MOVE).  If the
+   value "*" is given for the keepalive XML element, this designates
+   that all live properties on the source resource MUST be live on the
+   destination.  If the requirements specified by the keepalive element
+   can not be honored then the method MUST fail with a 412 (Precondition
+   Failed).  All DAV compliant resources MUST support the keepalive XML
+   element for use with the COPY and MOVE methods.
+   Value:      "*" ; #PCDATA value can only be "*"
+
+   <!ELEMENT keepalive (#PCDATA | href+) >
+
+

+

+Page 67

+

12.12.2 omit XML element
+

+

   Name:       omit
+   Namespace:  DAV:
+   Purpose:    The omit XML element instructs the server that it should
+   use best effort to copy properties but a failure to copy a property
+   MUST NOT cause the method to fail.  Description: The default behavior
+   for a COPY or MOVE is to copy/move all properties or fail the method.
+   In certain circumstances, such as when a server copies a resource
+   over another protocol such as FTP, it may not be possible to
+   copy/move the properties associated with the resource. Thus any
+   attempt to copy/move over FTP would always have to fail because
+   properties could not be moved over, even as dead properties.  All DAV
+   compliant resources MUST support the omit XML element on COPY/MOVE
+   methods.
+
+   <!ELEMENT omit EMPTY >
+
+

+

12.13 propertyupdate XML element
+

+

   Name:       propertyupdate
+   Namespace:  DAV:
+   Purpose:    Contains a request to alter the properties on a
+   resource.
+   Description: This XML element is a container for the information
+   required to modify the properties on the resource.  This XML element
+   is multi-valued.
+
+   <!ELEMENT propertyupdate (remove | set)+ >
+
+

+

12.13.1 remove XML element
+

+

   Name:       remove
+   Namespace:  DAV:
+   Purpose:    Lists the DAV properties to be removed from a resource.
+   Description: Remove instructs that the properties specified in prop
+   should be removed.  Specifying the removal of a property that does
+   not exist is not an error.  All the XML elements in a prop XML
+   element inside of a remove XML element MUST be empty, as only the
+   names of properties to be removed are required.
+
+   <!ELEMENT remove (prop) >
+
+

+

12.13.2 set XML element
+

+

   Name:       set
+   Namespace:  DAV:
+   Purpose:    Lists the DAV property values to be set for a resource.
+
+

+

+Page 68

+ Description: The set XML element MUST contain only a prop XML + element. The elements contained by the prop XML element inside the + set XML element MUST specify the name and value of properties that + are set on the resource identified by Request-URI. If a property + already exists then its value is replaced. Language tagging + information in the property's value (in the "xml:lang" attribute, if + present) MUST be persistently stored along with the property, and + MUST be subsequently retrievable using PROPFIND. +

+

   <!ELEMENT set (prop) >
+
+

+

12.14 propfind XML Element
+

+

   Name:       propfind
+   Namespace:  DAV:
+   Purpose:    Specifies the properties to be returned from a PROPFIND
+   method.  Two special elements are specified for use with propfind,
+   allprop and propname.  If prop is used inside propfind it MUST only
+   contain property names, not values.
+
+   <!ELEMENT propfind (allprop | propname | prop) >
+
+

+

12.14.1 allprop XML Element
+

+

   Name:       allprop Namespace:  DAV:  Purpose:    The allprop XML
+   element specifies that all property names and values on the resource
+   are to be returned.
+
+   <!ELEMENT allprop EMPTY >
+
+

+

12.14.2 propname XML Element
+

+

   Name:       propname Namespace:  DAV:  Purpose:    The propname XML
+   element specifies that only a list of property names on the resource
+   is to be returned.
+
+   <!ELEMENT propname EMPTY >
+
+

+

13 DAV Properties
+

+ For DAV properties, the name of the property is also the same as the + name of the XML element that contains its value. In the section + below, the final line of each section gives the element type + declaration using the format defined in [REC-XML]. The "Value" field, + where present, specifies further restrictions on the allowable + contents of the XML element using BNF (i.e., to further restrict the + values of a PCDATA element). +

+

+Page 69

+

13.1 creationdate Property
+

+

   Name:       creationdate
+   Namespace:  DAV:
+   Purpose:    Records the time and date the resource was created.
+   Value:      date-time ; See Appendix 2
+   Description: The creationdate property should be defined on all DAV
+   compliant resources.  If present, it contains a timestamp of the
+   moment when the resource was created (i.e., the moment it had non-
+   null state).
+
+   <!ELEMENT creationdate (#PCDATA) >
+
+

+

13.2 displayname Property
+

+

   Name:       displayname
+   Namespace:  DAV:
+   Purpose:    Provides a name for the resource that is suitable for
+   presentation to a user.
+   Description: The displayname property should be defined on all DAV
+   compliant resources.  If present, the property contains a description
+   of the resource that is suitable for presentation to a user.
+
+   <!ELEMENT displayname (#PCDATA) >
+
+

+

13.3 getcontentlanguage Property
+

+

   Name:       getcontentlanguage
+   Namespace:  DAV:
+   Purpose:    Contains the Content-Language header returned by a GET
+   without accept headers
+   Description: The getcontentlanguage property MUST be defined on any
+   DAV compliant resource that returns the Content-Language header on a
+   GET.
+   Value:      language-tag   ;language-tag is defined in section 14.13
+   of [RFC2068]
+
+   <!ELEMENT getcontentlanguage (#PCDATA) >
+
+

+

13.4 getcontentlength Property
+

+

   Name:       getcontentlength
+   Namespace:  DAV:
+   Purpose:    Contains the Content-Length header returned by a GET
+   without accept headers.
+   Description: The getcontentlength property MUST be defined on any
+   DAV compliant resource that returns the Content-Length header in
+   response to a GET.
+
+

+

+Page 70

+

   Value:      content-length ; see section 14.14 of [RFC2068]
+
+   <!ELEMENT getcontentlength (#PCDATA) >
+
+

+

13.5 getcontenttype Property
+

+

   Name:       getcontenttype
+   Namespace:  DAV:
+   Purpose:    Contains the Content-Type header returned by a GET
+   without accept headers.
+   Description: This getcontenttype property MUST be defined on any DAV
+   compliant resource that returns the Content-Type header in response
+   to a GET.
+   Value:      media-type   ; defined in section 3.7 of [RFC2068]
+
+   <!ELEMENT getcontenttype (#PCDATA) >
+
+

+

13.6 getetag Property
+

+

   Name:       getetag
+   Namespace:  DAV:
+   Purpose:    Contains the ETag header returned by a GET without
+   accept headers.
+   Description: The getetag property MUST be defined on any DAV
+   compliant resource that returns the Etag header.
+   Value:      entity-tag  ; defined in section 3.11 of [RFC2068]
+
+   <!ELEMENT getetag (#PCDATA) >
+
+

+

13.7 getlastmodified Property
+

+

   Name:       getlastmodified
+   Namespace:  DAV:
+   Purpose:    Contains the Last-Modified header returned by a GET
+   method without accept headers.
+   Description: Note that the last-modified date on a resource may
+   reflect changes in any part of the state of the resource, not
+   necessarily just a change to the response to the GET method.  For
+   example, a change in a property may cause the last-modified date to
+   change. The getlastmodified property MUST be defined on any DAV
+   compliant resource that returns the Last-Modified header in response
+   to a GET.
+   Value:      HTTP-date  ; defined in section 3.3.1 of [RFC2068]
+
+   <!ELEMENT getlastmodified (#PCDATA) >
+
+

+

+Page 71

+

13.8 lockdiscovery Property
+

+

   Name:       lockdiscovery
+   Namespace:  DAV:
+   Purpose:    Describes the active locks on a resource
+   Description: The lockdiscovery property returns a listing of who has
+   a lock, what type of lock he has, the timeout type and the time
+   remaining on the timeout, and the associated lock token.  The server
+   is free to withhold any or all of this information if the requesting
+   principal does not have sufficient access rights to see the requested
+   data.
+
+   <!ELEMENT lockdiscovery (activelock)* >
+
+

+

13.8.1 Example - Retrieving the lockdiscovery Property
+

+ >>Request +

+ PROPFIND /container/ HTTP/1.1 +
+ Host: www.foo.bar +
+ Content-Length: xxxx +
+ Content-Type: text/xml; charset="utf-8" +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D='DAV:'>
+     <D:prop><D:lockdiscovery/></D:prop>
+   </D:propfind>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D='DAV:'>
+     <D:response>
+          <D:href>http://www.foo.bar/container/>
+          <D:propstat>
+               <D:prop>
+                    <D:lockdiscovery>
+                         <D:activelock>
+                              <D:locktype><D:write/></D:locktype>
+                              <D:lockscope><D:exclusive/></D:lockscope>
+                              <D:depth>0</D:depth>
+                              <D:owner>Jane Smith</D:owner>
+                              <D:timeout>Infinite</D:timeout>
+                              <D:locktoken>
+
+

+

+Page 72

+

                                   <D:href>
+               opaquelocktoken:f81de2ad-7f3d-a1b2-4f3c-00a0c91a9d76
+                                   </D:href>
+                              </D:locktoken>
+                         </D:activelock>
+                    </D:lockdiscovery>
+               </D:prop>
+               <D:status>HTTP/1.1 200 OK</D:status>
+          </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+

+ This resource has a single exclusive write lock on it, with an + infinite timeout. +

+

13.9 resourcetype Property
+

+

   Name:       resourcetype
+   Namespace:  DAV:
+   Purpose:    Specifies the nature of the resource.
+   Description: The resourcetype property MUST be defined on all DAV
+   compliant resources.  The default value is empty.
+
+   <!ELEMENT resourcetype ANY >
+
+

+

13.10 source Property
+

+

   Name:       source
+   Namespace:  DAV:
+   Purpose:    The destination of the source link identifies the
+   resource that contains the unprocessed source of the link's source.
+   Description: The source of the link (src) is typically the URI of the
+   output resource on which the link is defined, and there is typically
+   only one destination (dst) of the link, which is the URI where the
+   unprocessed source of the resource may be accessed.  When more than
+   one link destination exists, this specification asserts no policy on
+   ordering.
+
+   <!ELEMENT source (link)* >
+
+

+

13.10.1 Example - A source Property
+

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:prop xmlns:D="DAV:" xmlns:F="http://www.foocorp.com/Project/">
+     <D:source>
+          <D:link>
+               <F:projfiles>Source</F:projfiles>
+               <D:src>http://foo.bar/program>
+
+

+

+Page 73

+

               <D:dst>http://foo.bar/src/main.c>
+          </D:link>
+          <D:link>
+               <F:projfiles>Library</F:projfiles>
+               <D:src>http://foo.bar/program>
+               <D:dst>http://foo.bar/src/main.lib>
+          </D:link>
+          <D:link>
+               <F:projfiles>Makefile</F:projfiles>
+               <D:src>http://foo.bar/program>
+               <D:dst>http://foo.bar/src/makefile>
+          </D:link>
+     </D:source>
+   </D:prop>
+
+

+ In this example the resource http://foo.bar/program has a source + property that contains three links. Each link contains three + elements, two of which, src and dst, are part of the DAV schema + defined in this document, and one which is defined by the schema + http://www.foocorp.com/project/ (Source, Library, and Makefile). A + client which only implements the elements in the DAV spec will not + understand the foocorp elements and will ignore them, thus seeing the + expected source and destination links. An enhanced client may know + about the foocorp elements and be able to present the user with + additional information about the links. This example demonstrates + the power of XML markup, allowing element values to be enhanced + without breaking older clients. +

+

13.11 supportedlock Property
+

+

   Name:       supportedlock
+   Namespace:  DAV:
+   Purpose:    To provide a listing of the lock capabilities supported
+   by the resource.
+   Description: The supportedlock property of a resource returns a
+   listing of the combinations of scope and access types which may be
+   specified in a lock request on the resource.  Note that the actual
+   contents are themselves controlled by access controls so a server is
+   not required to provide information the client is not authorized to
+   see.
+
+   <!ELEMENT supportedlock (lockentry)* >
+
+

+

13.11.1 Example - Retrieving the supportedlock Property
+

+ >>Request +

+ PROPFIND /container/ HTTP/1.1 +

+

+Page 74

+ Host: www.foo.bar +
+ Content-Length: xxxx +
+ Content-Type: text/xml; charset="utf-8" +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:">
+     <D:prop><D:supportedlock/></D:prop>
+   </D:propfind>
+
+

+ >>Response +

+ HTTP/1.1 207 Multi-Status +
+ Content-Type: text/xml; charset="utf-8" +
+ Content-Length: xxxx +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:multistatus xmlns:D="DAV:">
+     <D:response>
+          <D:href>http://www.foo.bar/container/>
+          <D:propstat>
+               <D:prop>
+                    <D:supportedlock>
+                         <D:lockentry>
+                              <D:lockscope><D:exclusive/></D:lockscope>
+                              <D:locktype><D:write/></D:locktype>
+                         </D:lockentry>
+                         <D:lockentry>
+                              <D:lockscope><D:shared/></D:lockscope>
+                              <D:locktype><D:write/></D:locktype>
+                         </D:lockentry>
+                    </D:supportedlock>
+               </D:prop>
+               <D:status>HTTP/1.1 200 OK</D:status>
+          </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+

+

14 Instructions for Processing XML in DAV
+

+ All DAV compliant resources MUST ignore any unknown XML element and + all its children encountered while processing a DAV method that uses + XML as its command language. +

+ This restriction also applies to the processing, by clients, of DAV + property values where unknown XML elements SHOULD be ignored unless + the property's schema declares otherwise. +

+

+Page 75

+ This restriction does not apply to setting dead DAV properties on the + server where the server MUST record unknown XML elements. +

+ Additionally, this restriction does not apply to the use of XML where + XML happens to be the content type of the entity body, for example, + when used as the body of a PUT. +

+ Since XML can be transported as text/xml or application/xml, a DAV + server MUST accept DAV method requests with XML parameters + transported as either text/xml or application/xml, and DAV client + MUST accept XML responses using either text/xml or application/xml. +

+

15 DAV Compliance Classes
+

+ A DAV compliant resource can choose from two classes of compliance. + A client can discover the compliance classes of a resource by + executing OPTIONS on the resource, and examining the "DAV" header + which is returned. +

+ Since this document describes extensions to the HTTP/1.1 protocol, + minimally all DAV compliant resources, clients, and proxies MUST be + compliant with [RFC2068]. +

+ Compliance classes are not necessarily sequential. A resource that is + class 2 compliant must also be class 1 compliant; but if additional + compliance classes are defined later, a resource that is class 1, 2, + and 4 compliant might not be class 3 compliant. Also note that + identifiers other than numbers may be used as compliance class + identifiers. +

+

15.1 Class 1
+

+ A class 1 compliant resource MUST meet all "MUST" requirements in all + sections of this document. +

+ Class 1 compliant resources MUST return, at minimum, the value "1" in + the DAV header on all responses to the OPTIONS method. +

+

15.2 Class 2
+

+ A class 2 compliant resource MUST meet all class 1 requirements and + support the LOCK method, the supportedlock property, the +
+ lockdiscovery property, the Time-Out response header and the Lock- + Token request header. A class "2" compliant resource SHOULD also + support the Time-Out request header and the owner XML element. +

+ Class 2 compliant resources MUST return, at minimum, the values "1" + and "2" in the DAV header on all responses to the OPTIONS method. +

+

+Page 76

+

16 Internationalization Considerations
+

+ In the realm of internationalization, this specification complies + with the IETF Character Set Policy [RFC2277]. In this specification, + human-readable fields can be found either in the value of a property, + or in an error message returned in a response entity body. In both + cases, the human-readable content is encoded using XML, which has + explicit provisions for character set tagging and encoding, and + requires that XML processors read XML elements encoded, at minimum, + using the UTF-8 [UTF-8] encoding of the ISO 10646 multilingual plane. + XML examples in this specification demonstrate use of the charset + parameter of the Content-Type header, as defined in [RFC2376], as + well as the XML "encoding" attribute, which together provide charset + identification information for MIME and XML processors. +

+ XML also provides a language tagging capability for specifying the + language of the contents of a particular XML element. XML uses + either IANA registered language tags (see [RFC1766]) or ISO 639 + language tags [ISO-639] in the "xml:lang" attribute of an XML element + to identify the language of its content and attributes. +

+ WebDAV applications MUST support the character set tagging, character + set encoding, and the language tagging functionality of the XML + specification. Implementors of WebDAV applications are strongly + encouraged to read "XML Media Types" [RFC2376] for instruction on + which MIME media type to use for XML transport, and on use of the + charset parameter of the Content-Type header. +

+ Names used within this specification fall into three categories: + names of protocol elements such as methods and headers, names of XML + elements, and names of properties. Naming of protocol elements + follows the precedent of HTTP, using English names encoded in USASCII + for methods and headers. Since these protocol elements are not + visible to users, and are in fact simply long token identifiers, they + do not need to support encoding in multiple character sets. + Similarly, though the names of XML elements used in this +
+ specification are English names encoded in UTF-8, these names are not + visible to the user, and hence do not need to support multiple + character set encodings. +

+ The name of a property defined on a resource is a URI. Although some + applications (e.g., a generic property viewer) will display property + URIs directly to their users, it is expected that the typical + application will use a fixed set of properties, and will provide a + mapping from the property name URI to a human-readable field when + displaying the property name to a user. It is only in the case where +

+

+Page 77

+ the set of properties is not known ahead of time that an application + need display a property name URI to a user. We recommend that + applications provide human-readable property names wherever feasible. +

+ For error reporting, we follow the convention of HTTP/1.1 status + codes, including with each status code a short, English description + of the code (e.g., 423 (Locked)). While the possibility exists that + a poorly crafted user agent would display this message to a user, + internationalized applications will ignore this message, and display + an appropriate message in the user's language and character set. +

+ Since interoperation of clients and servers does not require locale + information, this specification does not specify any mechanism for + transmission of this information. +

+

17 Security Considerations
+

+ This section is provided to detail issues concerning security + implications of which WebDAV applications need to be aware. +

+ All of the security considerations of HTTP/1.1 (discussed in + [RFC2068]) and XML (discussed in [RFC2376]) also apply to WebDAV. In + addition, the security risks inherent in remote authoring require + stronger authentication technology, introduce several new privacy + concerns, and may increase the hazards from poor server design. + These issues are detailed below. +

+

17.1 Authentication of Clients
+

+ Due to their emphasis on authoring, WebDAV servers need to use + authentication technology to protect not just access to a network + resource, but the integrity of the resource as well. Furthermore, + the introduction of locking functionality requires support for + authentication. +

+ A password sent in the clear over an insecure channel is an + inadequate means for protecting the accessibility and integrity of a + resource as the password may be intercepted. Since Basic + authentication for HTTP/1.1 performs essentially clear text + transmission of a password, Basic authentication MUST NOT be used to + authenticate a WebDAV client to a server unless the connection is + secure. Furthermore, a WebDAV server MUST NOT send Basic +
+ authentication credentials in a WWW-Authenticate header unless the + connection is secure. Examples of secure connections include a + Transport Layer Security (TLS) connection employing a strong cipher + suite with mutual authentication of client and server, or a + connection over a network which is physically secure, for example, an + isolated network in a building with restricted access. +

+

+Page 78

+ WebDAV applications MUST support the Digest authentication scheme + [RFC2069]. Since Digest authentication verifies that both parties to + a communication know a shared secret, a password, without having to + send that secret in the clear, Digest authentication avoids the + security problems inherent in Basic authentication while providing a + level of authentication which is useful in a wide range of scenarios. +

+

17.2 Denial of Service
+

+ Denial of service attacks are of special concern to WebDAV servers. + WebDAV plus HTTP enables denial of service attacks on every part of a + system's resources. +

+ The underlying storage can be attacked by PUTting extremely large + files. +

+ Asking for recursive operations on large collections can attack + processing time. +

+ Making multiple pipelined requests on multiple connections can attack + network connections. +

+ WebDAV servers need to be aware of the possibility of a denial of + service attack at all levels. +

+

17.3 Security through Obscurity
+

+ WebDAV provides, through the PROPFIND method, a mechanism for listing + the member resources of a collection. This greatly diminishes the + effectiveness of security or privacy techniques that rely only on the + difficulty of discovering the names of network resources. Users of + WebDAV servers are encouraged to use access control techniques to + prevent unwanted access to resources, rather than depending on the + relative obscurity of their resource names. +

+

17.4 Privacy Issues Connected to Locks
+

+ When submitting a lock request a user agent may also submit an owner + XML field giving contact information for the person taking out the + lock (for those cases where a person, rather than a robot, is taking + out the lock). This contact information is stored in a lockdiscovery + property on the resource, and can be used by other collaborators to + begin negotiation over access to the resource. However, in many + cases this contact information can be very private, and should not be + widely disseminated. Servers SHOULD limit read access to the + lockdiscovery property as appropriate. Furthermore, user agents +

+

+Page 79

+ SHOULD provide control over whether contact information is sent at + all, and if contact information is sent, control over exactly what + information is sent. +

+

17.5 Privacy Issues Connected to Properties
+

+ Since property values are typically used to hold information such as + the author of a document, there is the possibility that privacy + concerns could arise stemming from widespread access to a resource's + property data. To reduce the risk of inadvertent release of private + information via properties, servers are encouraged to develop access + control mechanisms that separate read access to the resource body and + read access to the resource's properties. This allows a user to + control the dissemination of their property data without overly + restricting access to the resource's contents. +

+

17.6 Reduction of Security due to Source Link
+

+ HTTP/1.1 warns against providing read access to script code because + it may contain sensitive information. Yet WebDAV, via its source + link facility, can potentially provide a URI for script resources so + they may be authored. For HTTP/1.1, a server could reasonably + prevent access to source resources due to the predominance of read- + only access. WebDAV, with its emphasis on authoring, encourages read + and write access to source resources, and provides the source link + facility to identify the source. This reduces the security benefits + of eliminating access to source resources. Users and administrators + of WebDAV servers should be very cautious when allowing remote + authoring of scripts, limiting read and write access to the source + resources to authorized principals. +

+

17.7 Implications of XML External Entities
+

+ XML supports a facility known as "external entities", defined in + section 4.2.2 of [REC-XML], which instruct an XML processor to + retrieve and perform an inline include of XML located at a particular + URI. An external XML entity can be used to append or modify the + document type declaration (DTD) associated with an XML document. An + external XML entity can also be used to include XML within the + content of an XML document. For non-validating XML, such as the XML + used in this specification, including an external XML entity is not + required by [REC-XML]. However, [REC-XML] does state that an XML + processor may, at its discretion, include the external XML entity. +

+ External XML entities have no inherent trustworthiness and are + subject to all the attacks that are endemic to any HTTP GET request. + Furthermore, it is possible for an external XML entity to modify the + DTD, and hence affect the final form of an XML document, in the worst +

+

+Page 80

+ case significantly modifying its semantics, or exposing the XML + processor to the security risks discussed in [RFC2376]. Therefore, + implementers must be aware that external XML entities should be + treated as untrustworthy. +

+ There is also the scalability risk that would accompany a widely + deployed application which made use of external XML entities. In + this situation, it is possible that there would be significant + numbers of requests for one external XML entity, potentially + overloading any server which fields requests for the resource + containing the external XML entity. +

+

17.8 Risks Connected with Lock Tokens
+

+ This specification, in section 6.4, requires the use of Universal + Unique Identifiers (UUIDs) for lock tokens, in order to guarantee + their uniqueness across space and time. UUIDs, as defined in [ISO- + 11578], contain a "node" field which "consists of the IEEE address, + usually the host address. For systems with multiple IEEE 802 nodes, + any available node address can be used." Since a WebDAV server will + issue many locks over its lifetime, the implication is that it will + also be publicly exposing its IEEE 802 address. +

+ There are several risks associated with exposure of IEEE 802 + addresses. Using the IEEE 802 address: +

+

   * It is possible to track the movement of hardware from subnet to
+   subnet.
+
+   * It may be possible to identify the manufacturer of the hardware
+   running a WebDAV server.
+
+   * It may be possible to determine the number of each type of computer
+   running WebDAV.
+
+

+ Section 6.4.1 of this specification details an alternate mechanism + for generating the "node" field of a UUID without using an IEEE 802 + address, which alleviates the risks associated with exposure of IEEE + 802 addresses by using an alternate source of uniqueness. +

+

18 IANA Considerations
+

+ This document defines two namespaces, the namespace of property + names, and the namespace of WebDAV-specific XML elements used within + property values. +

+

+Page 81

+ URIs are used for both names, for several reasons. Assignment of a + URI does not require a request to a central naming authority, and + hence allow WebDAV property names and XML elements to be quickly + defined by any WebDAV user or application. URIs also provide a + unique address space, ensuring that the distributed users of WebDAV + will not have collisions among the property names and XML elements + they create. +

+ This specification defines a distinguished set of property names and + XML elements that are understood by all WebDAV applications. The + property names and XML elements in this specification are all derived + from the base URI DAV: by adding a suffix to this URI, for example, + DAV:creationdate for the "creationdate" property. +

+ This specification also defines a URI scheme for the encoding of lock + tokens, the opaquelocktoken URI scheme described in section 6.4. +

+ To ensure correct interoperation based on this specification, IANA + must reserve the URI namespaces starting with "DAV:" and with + "opaquelocktoken:" for use by this specification, its revisions, and + related WebDAV specifications. +

+

19 Intellectual Property
+

+ The following notice is copied from RFC 2026 [RFC2026], section 10.4, + and describes the position of the IETF concerning intellectual + property claims made against this document. +

+ The IETF takes no position regarding the validity or scope of any + intellectual property or other rights that might be claimed to + pertain to the implementation or use other technology described in + this document or the extent to which any license under such rights + might or might not be available; neither does it represent that it + has made any effort to identify any such rights. Information on the + IETF's procedures with respect to rights in standards-track and + standards-related documentation can be found in BCP-11. Copies of + claims of rights made available for publication and any assurances of + licenses to be made available, or the result of an attempt made to + obtain a general license or permission for the use of such + proprietary rights by implementors or users of this specification can + be obtained from the IETF Secretariat. +

+ The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights which may cover technology that may be required to practice + this standard. Please address the information to the IETF Executive + Director. +

+

+Page 82

+

20 Acknowledgements
+

+ A specification such as this thrives on piercing critical review and + withers from apathetic neglect. The authors gratefully acknowledge + the contributions of the following people, whose insights were so + valuable at every stage of our work. +

+ Terry Allen, Harald Alvestrand, Jim Amsden, Becky Anderson, Alan + Babich, Sanford Barr, Dylan Barrell, Bernard Chester, Tim Berners- + Lee, Dan Connolly, Jim Cunningham, Ron Daniel, Jr., Jim Davis, Keith + Dawson, Mark Day, Brian Deen, Martin Duerst, David Durand, Lee + Farrell, Chuck Fay, Wesley Felter, Roy Fielding, Mark Fisher, Alan + Freier, George Florentine, Jim Gettys, Phill Hallam-Baker, Dennis + Hamilton, Steve Henning, Mead Himelstein, Alex Hopmann, Andre van der + Hoek, Ben Laurie, Paul Leach, Ora Lassila, Karen MacArthur, Steven + Martin, Larry Masinter, Michael Mealling, Keith Moore, Thomas Narten, + Henrik Nielsen, Kenji Ota, Bob Parker, Glenn Peterson, Jon Radoff, + Saveen Reddy, Henry Sanders, Christopher Seiwald, Judith Slein, Mike + Spreitzer, Einar Stefferud, Greg Stein, Ralph Swick, Kenji Takahashi, + Richard N. Taylor, Robert Thau, John Turner, Sankar Virdhagriswaran, + Fabio Vitali, Gregory Woodhouse, and Lauren Wood. +

+ Two from this list deserve special mention. The contributions by + Larry Masinter have been invaluable, both in helping the formation of + the working group and in patiently coaching the authors along the + way. In so many ways he has set high standards we have toiled to + meet. The contributions of Judith Slein in clarifying the + requirements, and in patiently reviewing draft after draft, both + improved this specification and expanded our minds on document + management. +

+ We would also like to thank John Turner for developing the XML DTD. +

+

21 References
+

+

21.1 Normative References
+

+

   [RFC1766]       Alvestrand, H., "Tags for the Identification of
+                   Languages", RFC 1766, March 1995.
+
+   [RFC2277]       Alvestrand, H., "IETF Policy on Character Sets and
+                   Languages", BCP 18, RFC 2277, January 1998.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+

+

+Page 83

+

   [RFC2396]       Berners-Lee, T., Fielding, R. and L. Masinter,
+                   "Uniform Resource Identifiers (URI): Generic Syntax",
+                   RFC 2396, August 1998.
+
+   [REC-XML]       T. Bray, J. Paoli, C. M. Sperberg-McQueen,
+                   "Extensible Markup Language (XML)." World Wide Web
+                   Consortium Recommendation REC-xml-19980210.
+                   http://www.w3.org/TR/1998/REC-xml-19980210.
+
+

+ [REC-XML-NAMES] T. Bray, D. Hollander, A. Layman, "Namespaces in + XML". World Wide Web Consortium Recommendation REC- + xml-names-19990114. http://www.w3.org/TR/1999/REC- + xml-names-19990114/ +

+

   [RFC2069]       Franks, J., Hallam-Baker, P., Hostetler, J., Leach,
+                   P, Luotonen, A., Sink, E. and L. Stewart, "An
+                   Extension to HTTP :  Digest Access Authentication",
+                   RFC 2069, January 1997.
+
+   [RFC2068]       Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and
+                   T. Berners-Lee, "Hypertext Transfer Protocol --
+                   HTTP/1.1", RFC 2068, January 1997.
+
+   [ISO-639]       ISO (International Organization for Standardization).
+                   ISO 639:1988. "Code for the representation of names
+                   of languages."
+
+   [ISO-8601]      ISO (International Organization for Standardization).
+                   ISO 8601:1988. "Data elements and interchange formats
+                   - Information interchange - Representation of dates
+                   and times."
+
+   [ISO-11578]     ISO (International Organization for Standardization).
+                   ISO/IEC 11578:1996. "Information technology - Open
+                   Systems Interconnection - Remote Procedure Call
+                   (RPC)"
+
+   [RFC2141]       Moats, R., "URN Syntax", RFC 2141, May 1997.
+
+   [UTF-8]         Yergeau, F., "UTF-8, a transformation format of
+                   Unicode and ISO 10646", RFC 2279, January 1998.
+
+

+

21.2 Informational References
+

+ [RFC2026] Bradner, S., "The Internet Standards Process - Revision + 3", BCP 9, RFC 2026, October 1996. +

+

+Page 84

+ [RFC1807] Lasher, R. and D. Cohen, "A Format for Bibliographic + Records", RFC 1807, June 1995. +

+

   [WF]       C. Lagoze, "The Warwick Framework: A Container
+              Architecture for Diverse Sets of Metadata", D-Lib
+              Magazine, July/August 1996.
+              http://www.dlib.org/dlib/july96/lagoze/07lagoze.html
+
+   [USMARC]   Network Development and MARC Standards, Office, ed. 1994.
+              "USMARC Format for Bibliographic Data", 1994. Washington,
+              DC: Cataloging Distribution Service, Library of Congress.
+
+

+ [REC-PICS] J. Miller, T. Krauskopf, P. Resnick, W. Treese, "PICS + Label Distribution Label Syntax and Communication + Protocols" Version 1.1, World Wide Web Consortium + Recommendation REC-PICS-labels-961031. +
+ http://www.w3.org/pub/WWW/TR/REC-PICS-labels-961031.html. +

+ [RFC2291] Slein, J., Vitali, F., Whitehead, E. and D. Durand, + "Requirements for Distributed Authoring and Versioning + Protocol for the World Wide Web", RFC 2291, February 1998. +

+ [RFC2413] Weibel, S., Kunze, J., Lagoze, C. and M. Wolf, "Dublin + Core Metadata for Resource Discovery", RFC 2413, September + 1998. +

+ [RFC2376] Whitehead, E. and M. Murata, "XML Media Types", RFC 2376, + July 1998. +

+

22 Authors' Addresses
+

+

Y Y. Goland
+ Microsoft Corporation +
+ One Microsoft Way +
+ Redmond, WA 98052-6399 +

+ EMail: yarong@microsoft.com +

+

E J. Whitehead, Jr.
+ Dept. Of Information and Computer Science +
+ University of California, Irvine +
+ Irvine, CA 92697-3425 +

+ EMail: ejw@ics.uci.edu +

+

+Page 85

+

A Faizi
+ Netscape +
+ 685 East Middlefield Road +
+ Mountain View, CA 94043 +

+ EMail: asad@netscape.com +

+

S R. Carter
+ Novell +
+ 1555 N. Technology Way +
+ M/S ORM F111 +
+ Orem, UT 84097-2399 +

+ EMail: srcarter@novell.com +

+

D Jensen
+ Novell +
+ 1555 N. Technology Way +
+ M/S ORM F111 +
+ Orem, UT 84097-2399 +

+ EMail: dcjensen@novell.com +

+

+Page 86

+

23 Appendices
+

+

23.1 Appendix 1 - WebDAV Document Type Definition
+

+ This section provides a document type definition, following the rules + in [REC-XML], for the XML elements used in the protocol stream and in + the values of properties. It collects the element definitions given + in sections 12 and 13. +

+

   <!DOCTYPE webdav-1.0 [
+
+   <!--============ XML Elements from Section 12 ==================-->
+
+   <!ELEMENT activelock (lockscope, locktype, depth, owner?, timeout?,
+   locktoken?) >
+
+   <!ELEMENT lockentry (lockscope, locktype) >
+   <!ELEMENT lockinfo (lockscope, locktype, owner?) >
+
+   <!ELEMENT locktype (write) >
+   <!ELEMENT write EMPTY >
+
+   <!ELEMENT lockscope (exclusive | shared) >
+   <!ELEMENT exclusive EMPTY >
+   <!ELEMENT shared EMPTY >
+
+   <!ELEMENT depth (#PCDATA) >
+
+   <!ELEMENT owner ANY >
+
+   <!ELEMENT timeout (#PCDATA) >
+
+   <!ELEMENT locktoken (href+) >
+
+   <!ELEMENT href (#PCDATA) >
+
+   <!ELEMENT link (src+, dst+) >
+   <!ELEMENT dst (#PCDATA) >
+   <!ELEMENT src (#PCDATA) >
+
+   <!ELEMENT multistatus (response+, responsedescription?) >
+
+   <!ELEMENT response (href, ((href*, status)|(propstat+)),
+   responsedescription?) >
+   <!ELEMENT status (#PCDATA) >
+   <!ELEMENT propstat (prop, status, responsedescription?) >
+   <!ELEMENT responsedescription (#PCDATA) >
+
+

+

+Page 87

+

   <!ELEMENT prop ANY >
+
+   <!ELEMENT propertybehavior (omit | keepalive) >
+   <!ELEMENT omit EMPTY >
+
+   <!ELEMENT keepalive (#PCDATA | href+) >
+
+   <!ELEMENT propertyupdate (remove | set)+ >
+   <!ELEMENT remove (prop) >
+   <!ELEMENT set (prop) >
+
+   <!ELEMENT propfind (allprop | propname | prop) >
+   <!ELEMENT allprop EMPTY >
+   <!ELEMENT propname EMPTY >
+
+   <!ELEMENT collection EMPTY >
+
+   <!--=========== Property Elements from Section 13 ===============-->
+   <!ELEMENT creationdate (#PCDATA) >
+   <!ELEMENT displayname (#PCDATA) >
+   <!ELEMENT getcontentlanguage (#PCDATA) >
+   <!ELEMENT getcontentlength (#PCDATA) >
+   <!ELEMENT getcontenttype (#PCDATA) >
+   <!ELEMENT getetag (#PCDATA) >
+   <!ELEMENT getlastmodified (#PCDATA) >
+   <!ELEMENT lockdiscovery (activelock)* >
+   <!ELEMENT resourcetype ANY >
+   <!ELEMENT source (link)* >
+   <!ELEMENT supportedlock (lockentry)* >
+   ]>
+
+

+

+Page 88

+

23.2 Appendix 2 - ISO 8601 Date and Time Profile
+

+ The creationdate property specifies the use of the ISO 8601 date + format [ISO-8601]. This section defines a profile of the ISO 8601 + date format for use with this specification. This profile is quoted + from an Internet-Draft by Chris Newman, and is mentioned here to + properly attribute his work. +

+

   date-time       = full-date "T" full-time
+
+   full-date       = date-fullyear "-" date-month "-" date-mday
+   full-time       = partial-time time-offset
+
+   date-fullyear   = 4DIGIT
+   date-month      = 2DIGIT  ; 01-12
+   date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
+   month/year
+   time-hour       = 2DIGIT  ; 00-23
+   time-minute     = 2DIGIT  ; 00-59
+   time-second     = 2DIGIT  ; 00-59, 00-60 based on leap second rules
+   time-secfrac    = "." 1*DIGIT
+   time-numoffset  = ("+" / "-") time-hour ":" time-minute
+   time-offset     = "Z" / time-numoffset
+
+   partial-time    = time-hour ":" time-minute ":" time-second
+                    [time-secfrac]
+
+

+ Numeric offsets are calculated as local time minus UTC (Coordinated + Universal Time). So the equivalent time in UTC can be determined by + subtracting the offset from the local time. For example, 18:50:00- + 04:00 is the same time as 22:58:00Z. +

+ If the time in UTC is known, but the offset to local time is unknown, + this can be represented with an offset of "-00:00". This differs + from an offset of "Z" which implies that UTC is the preferred + reference point for the specified time. +

+

+Page 89

+

23.3 Appendix 3 - Notes on Processing XML Elements
+

+

23.3.1 Notes on Empty XML Elements
+

+ XML supports two mechanisms for indicating that an XML element does + not have any content. The first is to declare an XML element of the + form <A></A>. The second is to declare an XML element of the form +

   <A/>.  The two XML elements are semantically identical.
+
+

+ It is a violation of the XML specification to use the <A></A> form if + the associated DTD declares the element to be EMPTY (e.g., <!ELEMENT + A EMPTY>). If such a statement is included, then the empty element + format, <A/> must be used. If the element is not declared to be + EMPTY, then either form <A></A> or <A/> may be used for empty + elements. +

+

23.3.2 Notes on Illegal XML Processing
+

+ XML is a flexible data format that makes it easy to submit data that + appears legal but in fact is not. The philosophy of "Be flexible in + what you accept and strict in what you send" still applies, but it + must not be applied inappropriately. XML is extremely flexible in + dealing with issues of white space, element ordering, inserting new + elements, etc. This flexibility does not require extension, + especially not in the area of the meaning of elements. +

+ There is no kindness in accepting illegal combinations of XML + elements. At best it will cause an unwanted result and at worst it + can cause real damage. +

+

23.3.2.1 Example - XML Syntax Error
+

+ The following request body for a PROPFIND method is illegal. +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:">
+     <D:allprop/>
+     <D:propname/>
+   </D:propfind>
+
+

+ The definition of the propfind element only allows for the allprop or + the propname element, not both. Thus the above is an error and must + be responded to with a 400 (Bad Request). +

+

+Page 90

+ Imagine, however, that a server wanted to be "kind" and decided to + pick the allprop element as the true element and respond to it. A + client running over a bandwidth limited line who intended to execute + a propname would be in for a big surprise if the server treated the + command as an allprop. +

+ Additionally, if a server were lenient and decided to reply to this + request, the results would vary randomly from server to server, with + some servers executing the allprop directive, and others executing + the propname directive. This reduces interoperability rather than + increasing it. +

+

23.3.2.2 Example - Unknown XML Element
+

+ The previous example was illegal because it contained two elements + that were explicitly banned from appearing together in the propfind + element. However, XML is an extensible language, so one can imagine + new elements being defined for use with propfind. Below is the + request body of a PROPFIND and, like the previous example, must be + rejected with a 400 (Bad Request) by a server that does not + understand the expired-props element. +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:"
+   xmlns:E="http://www.foo.bar/standards/props/">
+     <E:expired-props/>
+   </D:propfind>
+
+

+ To understand why a 400 (Bad Request) is returned let us look at the + request body as the server unfamiliar with expired-props sees it. +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:"
+               xmlns:E="http://www.foo.bar/standards/props/">
+   </D:propfind>
+
+

+ As the server does not understand the expired-props element, + according to the WebDAV-specific XML processing rules specified in + section 14, it must ignore it. Thus the server sees an empty + propfind, which by the definition of the propfind element is illegal. +

+ Please note that had the extension been additive it would not + necessarily have resulted in a 400 (Bad Request). For example, + imagine the following request body for a PROPFIND: +

+

   <?xml version="1.0" encoding="utf-8" ?>
+   <D:propfind xmlns:D="DAV:"
+               xmlns:E="http://www.foo.bar/standards/props/">
+
+

+

+Page 91

+

     <D:propname/>
+     <E:leave-out>*boss*</E:leave-out>
+   </D:propfind>
+
+

+ The previous example contains the fictitious element leave-out. Its + purpose is to prevent the return of any property whose name matches + the submitted pattern. If the previous example were submitted to a + server unfamiliar with leave-out, the only result would be that the + leave-out element would be ignored and a propname would be executed. +

+

+Page 92

+

23.4 Appendix 4 -- XML Namespaces for WebDAV
+

+

23.4.1 Introduction
+

+ All DAV compliant systems MUST support the XML namespace extensions + as specified in [REC-XML-NAMES]. +

+

23.4.2 Meaning of Qualified Names
+

+ [Note to the reader: This section does not appear in [REC-XML-NAMES], + but is necessary to avoid ambiguity for WebDAV XML processors.] +

+ WebDAV compliant XML processors MUST interpret a qualified name as a + URI constructed by appending the LocalPart to the namespace name URI. +

+ Example +

+

   <del:glider xmlns:del="http://www.del.jensen.org/">
+     <del:glidername>
+          Johnny Updraft
+     </del:glidername>
+     <del:glideraccidents/>
+   </del:glider>
+
+

+ In this example, the qualified element name "del:glider" is + interpreted as the URL "http://www.del.jensen.org/glider". +

+

   <bar:glider xmlns:del="http://www.del.jensen.org/">
+     <bar:glidername>
+          Johnny Updraft
+     </bar:glidername>
+     <bar:glideraccidents/>
+   </bar:glider>
+
+

+ Even though this example is syntactically different from the previous + example, it is semantically identical. Each instance of the + namespace name "bar" is replaced with "http://www.del.jensen.org/" + and then appended to the local name for each element tag. The + resulting tag names in this example are exactly the same as for the + previous example. +

+

   <foo:r xmlns:foo="http://www.del.jensen.org/glide">
+     <foo:rname>
+          Johnny Updraft
+     </foo:rname>
+     <foo:raccidents/>
+   </foo:r>
+
+

+

+Page 93

+ This example is semantically identical to the two previous ones. + Each instance of the namespace name "foo" is replaced with + "http://www.del.jensen.org/glide" which is then appended to the local + name for each element tag, the resulting tag names are identical to + those in the previous examples. +

+

+Page 94

+

24 Full Copyright Statement
+

+ Copyright © The Internet Society (1999). All Rights Reserved. +

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

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

+ This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. +

+

+
+ \ No newline at end of file diff --git a/docs/rfc2616.html b/docs/rfc2616.html new file mode 100644 index 00000000..28385665 --- /dev/null +++ b/docs/rfc2616.html @@ -0,0 +1,9901 @@ + + + + + +rfc2616 + + +

rfc2616

+


+
+
+
+
+
+
+Network Working Group                                      R. Fielding
+Request for Comments: 2616                                   UC Irvine
+Obsoletes: 2068                                              J. Gettys
+Category: Standards Track                                   Compaq/W3C
+                                                              J. Mogul
+                                                                Compaq
+                                                            H. Frystyk
+                                                               W3C/MIT
+                                                           L. Masinter
+                                                                 Xerox
+                                                              P. Leach
+                                                             Microsoft
+                                                        T. Berners-Lee
+                                                               W3C/MIT
+                                                             June 1999
+
+
+                Hypertext Transfer Protocol -- HTTP/1.1
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Hypertext Transfer Protocol (HTTP) is an application-level
+   protocol for distributed, collaborative, hypermedia information
+   systems. It is a generic, stateless, protocol which can be used for
+   many tasks beyond its use for hypertext, such as name servers and
+   distributed object management systems, through extension of its
+   request methods, error codes and headers [47]. A feature of HTTP is
+   the typing and negotiation of data representation, allowing systems
+   to be built independently of the data being transferred.
+
+   HTTP has been in use by the World-Wide Web global information
+   initiative since 1990. This specification defines the protocol
+   referred to as "HTTP/1.1", and is an update to RFC 2068 [33].
+
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 1]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+Table of Contents
+
+   1   Introduction ...................................................7
+   1.1    Purpose......................................................7
+   1.2   Requirements .................................................8
+   1.3   Terminology ..................................................8
+   1.4   Overall Operation ...........................................12
+   2   Notational Conventions and Generic Grammar ....................14
+   2.1   Augmented BNF ...............................................14
+   2.2   Basic Rules .................................................15
+   3   Protocol Parameters ...........................................17
+   3.1   HTTP Version ................................................17
+   3.2   Uniform Resource Identifiers ................................18
+   3.2.1    General Syntax ...........................................19
+   3.2.2    http URL .................................................19
+   3.2.3    URI Comparison ...........................................20
+   3.3   Date/Time Formats ...........................................20
+   3.3.1    Full Date ................................................20
+   3.3.2    Delta Seconds ............................................21
+   3.4   Character Sets ..............................................21
+   3.4.1    Missing Charset ..........................................22
+   3.5   Content Codings .............................................23
+   3.6   Transfer Codings ............................................24
+   3.6.1    Chunked Transfer Coding ..................................25
+   3.7   Media Types .................................................26
+   3.7.1    Canonicalization and Text Defaults .......................27
+   3.7.2    Multipart Types ..........................................27
+   3.8   Product Tokens ..............................................28
+   3.9   Quality Values ..............................................29
+   3.10  Language Tags ...............................................29
+   3.11  Entity Tags .................................................30
+   3.12  Range Units .................................................30
+   4   HTTP Message ..................................................31
+   4.1   Message Types ...............................................31
+   4.2   Message Headers .............................................31
+   4.3   Message Body ................................................32
+   4.4   Message Length ..............................................33
+   4.5   General Header Fields .......................................34
+   5   Request .......................................................35
+   5.1   Request-Line ................................................35
+   5.1.1    Method ...................................................36
+   5.1.2    Request-URI ..............................................36
+   5.2   The Resource Identified by a Request ........................38
+   5.3   Request Header Fields .......................................38
+   6   Response ......................................................39
+   6.1   Status-Line .................................................39
+   6.1.1    Status Code and Reason Phrase ............................39
+   6.2   Response Header Fields ......................................41
+
+
+
+Fielding, et al.            Standards Track                     [Page 2]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   7   Entity ........................................................42
+   7.1   Entity Header Fields ........................................42
+   7.2   Entity Body .................................................43
+   7.2.1    Type .....................................................43
+   7.2.2    Entity Length ............................................43
+   8   Connections ...................................................44
+   8.1   Persistent Connections ......................................44
+   8.1.1    Purpose ..................................................44
+   8.1.2    Overall Operation ........................................45
+   8.1.3    Proxy Servers ............................................46
+   8.1.4    Practical Considerations .................................46
+   8.2   Message Transmission Requirements ...........................47
+   8.2.1    Persistent Connections and Flow Control ..................47
+   8.2.2    Monitoring Connections for Error Status Messages .........48
+   8.2.3    Use of the 100 (Continue) Status .........................48
+   8.2.4    Client Behavior if Server Prematurely Closes Connection ..50
+   9   Method Definitions ............................................51
+   9.1   Safe and Idempotent Methods .................................51
+   9.1.1    Safe Methods .............................................51
+   9.1.2    Idempotent Methods .......................................51
+   9.2   OPTIONS .....................................................52
+   9.3   GET .........................................................53
+   9.4   HEAD ........................................................54
+   9.5   POST ........................................................54
+   9.6   PUT .........................................................55
+   9.7   DELETE ......................................................56
+   9.8   TRACE .......................................................56
+   9.9   CONNECT .....................................................57
+   10   Status Code Definitions ......................................57
+   10.1  Informational 1xx ...........................................57
+   10.1.1   100 Continue .............................................58
+   10.1.2   101 Switching Protocols ..................................58
+   10.2  Successful 2xx ..............................................58
+   10.2.1   200 OK ...................................................58
+   10.2.2   201 Created ..............................................59
+   10.2.3   202 Accepted .............................................59
+   10.2.4   203 Non-Authoritative Information ........................59
+   10.2.5   204 No Content ...........................................60
+   10.2.6   205 Reset Content ........................................60
+   10.2.7   206 Partial Content ......................................60
+   10.3  Redirection 3xx .............................................61
+   10.3.1   300 Multiple Choices .....................................61
+   10.3.2   301 Moved Permanently ....................................62
+   10.3.3   302 Found ................................................62
+   10.3.4   303 See Other ............................................63
+   10.3.5   304 Not Modified .........................................63
+   10.3.6   305 Use Proxy ............................................64
+   10.3.7   306 (Unused) .............................................64
+
+
+
+Fielding, et al.            Standards Track                     [Page 3]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   10.3.8   307 Temporary Redirect ...................................65
+   10.4  Client Error 4xx ............................................65
+   10.4.1    400 Bad Request .........................................65
+   10.4.2    401 Unauthorized ........................................66
+   10.4.3    402 Payment Required ....................................66
+   10.4.4    403 Forbidden ...........................................66
+   10.4.5    404 Not Found ...........................................66
+   10.4.6    405 Method Not Allowed ..................................66
+   10.4.7    406 Not Acceptable ......................................67
+   10.4.8    407 Proxy Authentication Required .......................67
+   10.4.9    408 Request Timeout .....................................67
+   10.4.10   409 Conflict ............................................67
+   10.4.11   410 Gone ................................................68
+   10.4.12   411 Length Required .....................................68
+   10.4.13   412 Precondition Failed .................................68
+   10.4.14   413 Request Entity Too Large ............................69
+   10.4.15   414 Request-URI Too Long ................................69
+   10.4.16   415 Unsupported Media Type ..............................69
+   10.4.17   416 Requested Range Not Satisfiable .....................69
+   10.4.18   417 Expectation Failed ..................................70
+   10.5  Server Error 5xx ............................................70
+   10.5.1   500 Internal Server Error ................................70
+   10.5.2   501 Not Implemented ......................................70
+   10.5.3   502 Bad Gateway ..........................................70
+   10.5.4   503 Service Unavailable ..................................70
+   10.5.5   504 Gateway Timeout ......................................71
+   10.5.6   505 HTTP Version Not Supported ...........................71
+   11   Access Authentication ........................................71
+   12   Content Negotiation ..........................................71
+   12.1  Server-driven Negotiation ...................................72
+   12.2  Agent-driven Negotiation ....................................73
+   12.3  Transparent Negotiation .....................................74
+   13   Caching in HTTP ..............................................74
+   13.1.1   Cache Correctness ........................................75
+   13.1.2   Warnings .................................................76
+   13.1.3   Cache-control Mechanisms .................................77
+   13.1.4   Explicit User Agent Warnings .............................78
+   13.1.5   Exceptions to the Rules and Warnings .....................78
+   13.1.6   Client-controlled Behavior ...............................79
+   13.2  Expiration Model ............................................79
+   13.2.1   Server-Specified Expiration ..............................79
+   13.2.2   Heuristic Expiration .....................................80
+   13.2.3   Age Calculations .........................................80
+   13.2.4   Expiration Calculations ..................................83
+   13.2.5   Disambiguating Expiration Values .........................84
+   13.2.6   Disambiguating Multiple Responses ........................84
+   13.3  Validation Model ............................................85
+   13.3.1   Last-Modified Dates ......................................86
+
+
+
+Fielding, et al.            Standards Track                     [Page 4]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   13.3.2   Entity Tag Cache Validators ..............................86
+   13.3.3   Weak and Strong Validators ...............................86
+   13.3.4   Rules for When to Use Entity Tags and Last-Modified Dates.89
+   13.3.5   Non-validating Conditionals ..............................90
+   13.4  Response Cacheability .......................................91
+   13.5  Constructing Responses From Caches ..........................92
+   13.5.1   End-to-end and Hop-by-hop Headers ........................92
+   13.5.2   Non-modifiable Headers ...................................92
+   13.5.3   Combining Headers ........................................94
+   13.5.4   Combining Byte Ranges ....................................95
+   13.6  Caching Negotiated Responses ................................95
+   13.7  Shared and Non-Shared Caches ................................96
+   13.8  Errors or Incomplete Response Cache Behavior ................97
+   13.9  Side Effects of GET and HEAD ................................97
+   13.10   Invalidation After Updates or Deletions ...................97
+   13.11   Write-Through Mandatory ...................................98
+   13.12   Cache Replacement .........................................99
+   13.13   History Lists .............................................99
+   14   Header Field Definitions ....................................100
+   14.1  Accept .....................................................100
+   14.2  Accept-Charset .............................................102
+   14.3  Accept-Encoding ............................................102
+   14.4  Accept-Language ............................................104
+   14.5  Accept-Ranges ..............................................105
+   14.6  Age ........................................................106
+   14.7  Allow ......................................................106
+   14.8  Authorization ..............................................107
+   14.9  Cache-Control ..............................................108
+   14.9.1   What is Cacheable .......................................109
+   14.9.2   What May be Stored by Caches ............................110
+   14.9.3   Modifications of the Basic Expiration Mechanism .........111
+   14.9.4   Cache Revalidation and Reload Controls ..................113
+   14.9.5   No-Transform Directive ..................................115
+   14.9.6   Cache Control Extensions ................................116
+   14.10   Connection ...............................................117
+   14.11   Content-Encoding .........................................118
+   14.12   Content-Language .........................................118
+   14.13   Content-Length ...........................................119
+   14.14   Content-Location .........................................120
+   14.15   Content-MD5 ..............................................121
+   14.16   Content-Range ............................................122
+   14.17   Content-Type .............................................124
+   14.18   Date .....................................................124
+   14.18.1   Clockless Origin Server Operation ......................125
+   14.19   ETag .....................................................126
+   14.20   Expect ...................................................126
+   14.21   Expires ..................................................127
+   14.22   From .....................................................128
+
+
+
+Fielding, et al.            Standards Track                     [Page 5]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   14.23   Host .....................................................128
+   14.24   If-Match .................................................129
+   14.25   If-Modified-Since ........................................130
+   14.26   If-None-Match ............................................132
+   14.27   If-Range .................................................133
+   14.28   If-Unmodified-Since ......................................134
+   14.29   Last-Modified ............................................134
+   14.30   Location .................................................135
+   14.31   Max-Forwards .............................................136
+   14.32   Pragma ...................................................136
+   14.33   Proxy-Authenticate .......................................137
+   14.34   Proxy-Authorization ......................................137
+   14.35   Range ....................................................138
+   14.35.1    Byte Ranges ...........................................138
+   14.35.2    Range Retrieval Requests ..............................139
+   14.36   Referer ..................................................140
+   14.37   Retry-After ..............................................141
+   14.38   Server ...................................................141
+   14.39   TE .......................................................142
+   14.40   Trailer ..................................................143
+   14.41  Transfer-Encoding..........................................143
+   14.42   Upgrade ..................................................144
+   14.43   User-Agent ...............................................145
+   14.44   Vary .....................................................145
+   14.45   Via ......................................................146
+   14.46   Warning ..................................................148
+   14.47   WWW-Authenticate .........................................150
+   15 Security Considerations .......................................150
+   15.1      Personal Information....................................151
+   15.1.1   Abuse of Server Log Information .........................151
+   15.1.2   Transfer of Sensitive Information .......................151
+   15.1.3   Encoding Sensitive Information in URI's .................152
+   15.1.4   Privacy Issues Connected to Accept Headers ..............152
+   15.2  Attacks Based On File and Path Names .......................153
+   15.3  DNS Spoofing ...............................................154
+   15.4  Location Headers and Spoofing ..............................154
+   15.5  Content-Disposition Issues .................................154
+   15.6  Authentication Credentials and Idle Clients ................155
+   15.7  Proxies and Caching ........................................155
+   15.7.1    Denial of Service Attacks on Proxies....................156
+   16   Acknowledgments .............................................156
+   17   References ..................................................158
+   18   Authors' Addresses ..........................................162
+   19   Appendices ..................................................164
+   19.1  Internet Media Type message/http and application/http ......164
+   19.2  Internet Media Type multipart/byteranges ...................165
+   19.3  Tolerant Applications ......................................166
+   19.4  Differences Between HTTP Entities and RFC 2045 Entities ....167
+
+
+
+Fielding, et al.            Standards Track                     [Page 6]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   19.4.1   MIME-Version ............................................167
+   19.4.2   Conversion to Canonical Form ............................167
+   19.4.3   Conversion of Date Formats ..............................168
+   19.4.4   Introduction of Content-Encoding ........................168
+   19.4.5   No Content-Transfer-Encoding ............................168
+   19.4.6   Introduction of Transfer-Encoding .......................169
+   19.4.7   MHTML and Line Length Limitations .......................169
+   19.5  Additional Features ........................................169
+   19.5.1   Content-Disposition .....................................170
+   19.6  Compatibility with Previous Versions .......................170
+   19.6.1   Changes from HTTP/1.0 ...................................171
+   19.6.2   Compatibility with HTTP/1.0 Persistent Connections ......172
+   19.6.3   Changes from RFC 2068 ...................................172
+   20   Index .......................................................175
+   21   Full Copyright Statement ....................................176
+
+1 Introduction
+
+1.1 Purpose
+
+   The Hypertext Transfer Protocol (HTTP) is an application-level
+   protocol for distributed, collaborative, hypermedia information
+   systems. HTTP has been in use by the World-Wide Web global
+   information initiative since 1990. The first version of HTTP,
+   referred to as HTTP/0.9, was a simple protocol for raw data transfer
+   across the Internet. HTTP/1.0, as defined by RFC 1945 [6], improved
+   the protocol by allowing messages to be in the format of MIME-like
+   messages, containing metainformation about the data transferred and
+   modifiers on the request/response semantics. However, HTTP/1.0 does
+   not sufficiently take into consideration the effects of hierarchical
+   proxies, caching, the need for persistent connections, or virtual
+   hosts. In addition, the proliferation of incompletely-implemented
+   applications calling themselves "HTTP/1.0" has necessitated a
+   protocol version change in order for two communicating applications
+   to determine each other's true capabilities.
+
+   This specification defines the protocol referred to as "HTTP/1.1".
+   This protocol includes more stringent requirements than HTTP/1.0 in
+   order to ensure reliable implementation of its features.
+
+   Practical information systems require more functionality than simple
+   retrieval, including search, front-end update, and annotation. HTTP
+   allows an open-ended set of methods and headers that indicate the
+   purpose of a request [47]. It builds on the discipline of reference
+   provided by the Uniform Resource Identifier (URI) [3], as a location
+   (URL) [4] or name (URN) [20], for indicating the resource to which a
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 7]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   method is to be applied. Messages are passed in a format similar to
+   that used by Internet mail [9] as defined by the Multipurpose
+   Internet Mail Extensions (MIME) [7].
+
+   HTTP is also used as a generic protocol for communication between
+   user agents and proxies/gateways to other Internet systems, including
+   those supported by the SMTP [16], NNTP [13], FTP [18], Gopher [2],
+   and WAIS [10] protocols. In this way, HTTP allows basic hypermedia
+   access to resources available from diverse applications.
+
+1.2 Requirements
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [34].
+
+   An implementation is not compliant if it fails to satisfy one or more
+   of the MUST or REQUIRED level requirements for the protocols it
+   implements. An implementation that satisfies all the MUST or REQUIRED
+   level and all the SHOULD level requirements for its protocols is said
+   to be "unconditionally compliant"; one that satisfies all the MUST
+   level requirements but not all the SHOULD level requirements for its
+   protocols is said to be "conditionally compliant."
+
+1.3 Terminology
+
+   This specification uses a number of terms to refer to the roles
+   played by participants in, and objects of, the HTTP communication.
+
+   connection
+      A transport layer virtual circuit established between two programs
+      for the purpose of communication.
+
+   message
+      The basic unit of HTTP communication, consisting of a structured
+      sequence of octets matching the syntax defined in section 4 and
+      transmitted via the connection.
+
+   request
+      An HTTP request message, as defined in section 5.
+
+   response
+      An HTTP response message, as defined in section 6.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 8]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   resource
+      A network data object or service that can be identified by a URI,
+      as defined in section 3.2. Resources may be available in multiple
+      representations (e.g. multiple languages, data formats, size, and
+      resolutions) or vary in other ways.
+
+   entity
+      The information transferred as the payload of a request or
+      response. An entity consists of metainformation in the form of
+      entity-header fields and content in the form of an entity-body, as
+      described in section 7.
+
+   representation
+      An entity included with a response that is subject to content
+      negotiation, as described in section 12. There may exist multiple
+      representations associated with a particular response status.
+
+   content negotiation
+      The mechanism for selecting the appropriate representation when
+      servicing a request, as described in section 12. The
+      representation of entities in any response can be negotiated
+      (including error responses).
+
+   variant
+      A resource may have one, or more than one, representation(s)
+      associated with it at any given instant. Each of these
+      representations is termed a `varriant'.  Use of the term `variant'
+      does not necessarily imply that the resource is subject to content
+      negotiation.
+
+   client
+      A program that establishes connections for the purpose of sending
+      requests.
+
+   user agent
+      The client which initiates a request. These are often browsers,
+      editors, spiders (web-traversing robots), or other end user tools.
+
+   server
+      An application program that accepts connections in order to
+      service requests by sending back responses. Any given program may
+      be capable of being both a client and a server; our use of these
+      terms refers only to the role being performed by the program for a
+      particular connection, rather than to the program's capabilities
+      in general. Likewise, any server may act as an origin server,
+      proxy, gateway, or tunnel, switching behavior based on the nature
+      of each request.
+
+
+
+
+Fielding, et al.            Standards Track                     [Page 9]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   origin server
+      The server on which a given resource resides or is to be created.
+
+   proxy
+      An intermediary program which acts as both a server and a client
+      for the purpose of making requests on behalf of other clients.
+      Requests are serviced internally or by passing them on, with
+      possible translation, to other servers. A proxy MUST implement
+      both the client and server requirements of this specification. A
+      "transparent proxy" is a proxy that does not modify the request or
+      response beyond what is required for proxy authentication and
+      identification. A "non-transparent proxy" is a proxy that modifies
+      the request or response in order to provide some added service to
+      the user agent, such as group annotation services, media type
+      transformation, protocol reduction, or anonymity filtering. Except
+      where either transparent or non-transparent behavior is explicitly
+      stated, the HTTP proxy requirements apply to both types of
+      proxies.
+
+   gateway
+      A server which acts as an intermediary for some other server.
+      Unlike a proxy, a gateway receives requests as if it were the
+      origin server for the requested resource; the requesting client
+      may not be aware that it is communicating with a gateway.
+
+   tunnel
+      An intermediary program which is acting as a blind relay between
+      two connections. Once active, a tunnel is not considered a party
+      to the HTTP communication, though the tunnel may have been
+      initiated by an HTTP request. The tunnel ceases to exist when both
+      ends of the relayed connections are closed.
+
+   cache
+      A program's local store of response messages and the subsystem
+      that controls its message storage, retrieval, and deletion. A
+      cache stores cacheable responses in order to reduce the response
+      time and network bandwidth consumption on future, equivalent
+      requests. Any client or server may include a cache, though a cache
+      cannot be used by a server that is acting as a tunnel.
+
+   cacheable
+      A response is cacheable if a cache is allowed to store a copy of
+      the response message for use in answering subsequent requests. The
+      rules for determining the cacheability of HTTP responses are
+      defined in section 13. Even if a resource is cacheable, there may
+      be additional constraints on whether a cache can use the cached
+      copy for a particular request.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 10]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   first-hand
+      A response is first-hand if it comes directly and without
+      unnecessary delay from the origin server, perhaps via one or more
+      proxies. A response is also first-hand if its validity has just
+      been checked directly with the origin server.
+
+   explicit expiration time
+      The time at which the origin server intends that an entity should
+      no longer be returned by a cache without further validation.
+
+   heuristic expiration time
+      An expiration time assigned by a cache when no explicit expiration
+      time is available.
+
+   age
+      The age of a response is the time since it was sent by, or
+      successfully validated with, the origin server.
+
+   freshness lifetime
+      The length of time between the generation of a response and its
+      expiration time.
+
+   fresh
+      A response is fresh if its age has not yet exceeded its freshness
+      lifetime.
+
+   stale
+      A response is stale if its age has passed its freshness lifetime.
+
+   semantically transparent
+      A cache behaves in a "semantically transparent" manner, with
+      respect to a particular response, when its use affects neither the
+      requesting client nor the origin server, except to improve
+      performance. When a cache is semantically transparent, the client
+      receives exactly the same response (except for hop-by-hop headers)
+      that it would have received had its request been handled directly
+      by the origin server.
+
+   validator
+      A protocol element (e.g., an entity tag or a Last-Modified time)
+      that is used to find out whether a cache entry is an equivalent
+      copy of an entity.
+
+   upstream/downstream
+      Upstream and downstream describe the flow of a message: all
+      messages flow from upstream to downstream.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 11]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   inbound/outbound
+      Inbound and outbound refer to the request and response paths for
+      messages: "inbound" means "traveling toward the origin server",
+      and "outbound" means "traveling toward the user agent"
+
+1.4 Overall Operation
+
+   The HTTP protocol is a request/response protocol. A client sends a
+   request to the server in the form of a request method, URI, and
+   protocol version, followed by a MIME-like message containing request
+   modifiers, client information, and possible body content over a
+   connection with a server. The server responds with a status line,
+   including the message's protocol version and a success or error code,
+   followed by a MIME-like message containing server information, entity
+   metainformation, and possible entity-body content. The relationship
+   between HTTP and MIME is described in appendix 19.4.
+
+   Most HTTP communication is initiated by a user agent and consists of
+   a request to be applied to a resource on some origin server. In the
+   simplest case, this may be accomplished via a single connection (v)
+   between the user agent (UA) and the origin server (O).
+
+          request chain ------------------------>
+       UA -------------------v------------------- O
+          <----------------------- response chain
+
+   A more complicated situation occurs when one or more intermediaries
+   are present in the request/response chain. There are three common
+   forms of intermediary: proxy, gateway, and tunnel. A proxy is a
+   forwarding agent, receiving requests for a URI in its absolute form,
+   rewriting all or part of the message, and forwarding the reformatted
+   request toward the server identified by the URI. A gateway is a
+   receiving agent, acting as a layer above some other server(s) and, if
+   necessary, translating the requests to the underlying server's
+   protocol. A tunnel acts as a relay point between two connections
+   without changing the messages; tunnels are used when the
+   communication needs to pass through an intermediary (such as a
+   firewall) even when the intermediary cannot understand the contents
+   of the messages.
+
+          request chain -------------------------------------->
+       UA -----v----- A -----v----- B -----v----- C -----v----- O
+          <------------------------------------- response chain
+
+   The figure above shows three intermediaries (A, B, and C) between the
+   user agent and origin server. A request or response message that
+   travels the whole chain will pass through four separate connections.
+   This distinction is important because some HTTP communication options
+
+
+
+Fielding, et al.            Standards Track                    [Page 12]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   may apply only to the connection with the nearest, non-tunnel
+   neighbor, only to the end-points of the chain, or to all connections
+   along the chain. Although the diagram is linear, each participant may
+   be engaged in multiple, simultaneous communications. For example, B
+   may be receiving requests from many clients other than A, and/or
+   forwarding requests to servers other than C, at the same time that it
+   is handling A's request.
+
+   Any party to the communication which is not acting as a tunnel may
+   employ an internal cache for handling requests. The effect of a cache
+   is that the request/response chain is shortened if one of the
+   participants along the chain has a cached response applicable to that
+   request. The following illustrates the resulting chain if B has a
+   cached copy of an earlier response from O (via C) for a request which
+   has not been cached by UA or A.
+
+          request chain ---------->
+       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
+          <--------- response chain
+
+   Not all responses are usefully cacheable, and some requests may
+   contain modifiers which place special requirements on cache behavior.
+   HTTP requirements for cache behavior and cacheable responses are
+   defined in section 13.
+
+   In fact, there are a wide variety of architectures and configurations
+   of caches and proxies currently being experimented with or deployed
+   across the World Wide Web. These systems include national hierarchies
+   of proxy caches to save transoceanic bandwidth, systems that
+   broadcast or multicast cache entries, organizations that distribute
+   subsets of cached data via CD-ROM, and so on. HTTP systems are used
+   in corporate intranets over high-bandwidth links, and for access via
+   PDAs with low-power radio links and intermittent connectivity. The
+   goal of HTTP/1.1 is to support the wide diversity of configurations
+   already deployed while introducing protocol constructs that meet the
+   needs of those who build web applications that require high
+   reliability and, failing that, at least reliable indications of
+   failure.
+
+   HTTP communication usually takes place over TCP/IP connections. The
+   default port is TCP 80 [19], but other ports can be used. This does
+   not preclude HTTP from being implemented on top of any other protocol
+   on the Internet, or on other networks. HTTP only presumes a reliable
+   transport; any protocol that provides such guarantees can be used;
+   the mapping of the HTTP/1.1 request and response structures onto the
+   transport data units of the protocol in question is outside the scope
+   of this specification.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 13]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   In HTTP/1.0, most implementations used a new connection for each
+   request/response exchange. In HTTP/1.1, a connection may be used for
+   one or more request/response exchanges, although connections may be
+   closed for a variety of reasons (see section 8.1).
+
+2 Notational Conventions and Generic Grammar
+
+2.1 Augmented BNF
+
+   All of the mechanisms specified in this document are described in
+   both prose and an augmented Backus-Naur Form (BNF) similar to that
+   used by RFC 822 [9]. Implementors will need to be familiar with the
+   notation in order to understand this specification. The augmented BNF
+   includes the following constructs:
+
+   name = definition
+      The name of a rule is simply the name itself (without any
+      enclosing "<" and ">") and is separated from its definition by the
+      equal "=" character. White space is only significant in that
+      indentation of continuation lines is used to indicate a rule
+      definition that spans more than one line. Certain basic rules are
+      in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc. Angle
+      brackets are used within definitions whenever their presence will
+      facilitate discerning the use of rule names.
+
+   "literal"
+      Quotation marks surround literal text. Unless stated otherwise,
+      the text is case-insensitive.
+
+   rule1 | rule2
+      Elements separated by a bar ("|") are alternatives, e.g., "yes |
+      no" will accept yes or no.
+
+   (rule1 rule2)
+      Elements enclosed in parentheses are treated as a single element.
+      Thus, "(elem (foo | bar) elem)" allows the token sequences "elem
+      foo elem" and "elem bar elem".
+
+   *rule
+      The character "*" preceding an element indicates repetition. The
+      full form is "<n>*<m>element" indicating at least <n> and at most
+      <m> occurrences of element. Default values are 0 and infinity so
+      that "*(element)" allows any number, including zero; "1*element"
+      requires at least one; and "1*2element" allows one or two.
+
+   [rule]
+      Square brackets enclose optional elements; "[foo bar]" is
+      equivalent to "*1(foo bar)".
+
+
+
+Fielding, et al.            Standards Track                    [Page 14]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   N rule
+      Specific repetition: "<n>(element)" is equivalent to
+      "<n>*<n>(element)"; that is, exactly <n> occurrences of (element).
+      Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
+      alphabetic characters.
+
+   #rule
+      A construct "#" is defined, similar to "*", for defining lists of
+      elements. The full form is "<n>#<m>element" indicating at least
+      <n> and at most <m> elements, each separated by one or more commas
+      (",") and OPTIONAL linear white space (LWS). This makes the usual
+      form of lists very easy; a rule such as
+         ( *LWS element *( *LWS "," *LWS element ))
+      can be shown as
+         1#element
+      Wherever this construct is used, null elements are allowed, but do
+      not contribute to the count of elements present. That is,
+      "(element), , (element) " is permitted, but counts as only two
+      elements. Therefore, where at least one element is required, at
+      least one non-null element MUST be present. Default values are 0
+      and infinity so that "#element" allows any number, including zero;
+      "1#element" requires at least one; and "1#2element" allows one or
+      two.
+
+   ; comment
+      A semi-colon, set off some distance to the right of rule text,
+      starts a comment that continues to the end of line. This is a
+      simple way of including useful notes in parallel with the
+      specifications.
+
+   implied *LWS
+      The grammar described by this specification is word-based. Except
+      where noted otherwise, linear white space (LWS) can be included
+      between any two adjacent words (token or quoted-string), and
+      between adjacent words and separators, without changing the
+      interpretation of a field. At least one delimiter (LWS and/or
+
+      separators) MUST exist between any two tokens (for the definition
+      of "token" below), since they would otherwise be interpreted as a
+      single token.
+
+2.2 Basic Rules
+
+   The following rules are used throughout this specification to
+   describe basic parsing constructs. The US-ASCII coded character set
+   is defined by ANSI X3.4-1986 [21].
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 15]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       OCTET          = <any 8-bit sequence of data>
+       CHAR           = <any US-ASCII character (octets 0 - 127)>
+       UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
+       LOALPHA        = <any US-ASCII lowercase letter "a".."z">
+       ALPHA          = UPALPHA | LOALPHA
+       DIGIT          = <any US-ASCII digit "0".."9">
+       CTL            = <any US-ASCII control character
+                        (octets 0 - 31) and DEL (127)>
+       CR             = <US-ASCII CR, carriage return (13)>
+       LF             = <US-ASCII LF, linefeed (10)>
+       SP             = <US-ASCII SP, space (32)>
+       HT             = <US-ASCII HT, horizontal-tab (9)>
+       <">            = <US-ASCII double-quote mark (34)>
+
+   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
+   protocol elements except the entity-body (see appendix 19.3 for
+   tolerant applications). The end-of-line marker within an entity-body
+   is defined by its associated media type, as described in section 3.7.
+
+       CRLF           = CR LF
+
+   HTTP/1.1 header field values can be folded onto multiple lines if the
+   continuation line begins with a space or horizontal tab. All linear
+   white space, including folding, has the same semantics as SP. A
+   recipient MAY replace any linear white space with a single SP before
+   interpreting the field value or forwarding the message downstream.
+
+       LWS            = [CRLF] 1*( SP | HT )
+
+   The TEXT rule is only used for descriptive field contents and values
+   that are not intended to be interpreted by the message parser. Words
+   of *TEXT MAY contain characters from character sets other than ISO-
+   8859-1 [22] only when encoded according to the rules of RFC 2047
+   [14].
+
+       TEXT           = <any OCTET except CTLs,
+                        but including LWS>
+
+   A CRLF is allowed in the definition of TEXT only as part of a header
+   field continuation. It is expected that the folding LWS will be
+   replaced with a single SP before interpretation of the TEXT value.
+
+   Hexadecimal numeric characters are used in several protocol elements.
+
+       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
+                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 16]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Many HTTP/1.1 header field values consist of words separated by LWS
+   or special characters. These special characters MUST be in a quoted
+   string to be used within a parameter value (as defined in section
+   3.6).
+
+       token          = 1*<any CHAR except CTLs or separators>
+       separators     = "(" | ")" | "<" | ">" | "@"
+                      | "," | ";" | ":" | "\" | <">
+                      | "/" | "[" | "]" | "?" | "="
+                      | "{" | "}" | SP | HT
+
+   Comments can be included in some HTTP header fields by surrounding
+   the comment text with parentheses. Comments are only allowed in
+   fields containing "comment" as part of their field value definition.
+   In all other fields, parentheses are considered part of the field
+   value.
+
+       comment        = "(" *( ctext | quoted-pair | comment ) ")"
+       ctext          = <any TEXT excluding "(" and ")">
+
+   A string of text is parsed as a single word if it is quoted using
+   double-quote marks.
+
+       quoted-string  = ( <"> *(qdtext | quoted-pair ) <"> )
+       qdtext         = <any TEXT except <">>
+
+   The backslash character ("\") MAY be used as a single-character
+   quoting mechanism only within quoted-string and comment constructs.
+
+       quoted-pair    = "\" CHAR
+
+3 Protocol Parameters
+
+3.1 HTTP Version
+
+   HTTP uses a "<major>.<minor>" numbering scheme to indicate versions
+   of the protocol. The protocol versioning policy is intended to allow
+   the sender to indicate the format of a message and its capacity for
+   understanding further HTTP communication, rather than the features
+   obtained via that communication. No change is made to the version
+   number for the addition of message components which do not affect
+   communication behavior or which only add to extensible field values.
+   The <minor> number is incremented when the changes made to the
+   protocol add features which do not change the general message parsing
+   algorithm, but which may add to the message semantics and imply
+   additional capabilities of the sender. The <major> number is
+   incremented when the format of a message within the protocol is
+   changed. See RFC 2145 [36] for a fuller explanation.
+
+
+
+Fielding, et al.            Standards Track                    [Page 17]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The version of an HTTP message is indicated by an HTTP-Version field
+   in the first line of the message.
+
+       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
+
+   Note that the major and minor numbers MUST be treated as separate
+   integers and that each MAY be incremented higher than a single digit.
+   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
+   lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
+   MUST NOT be sent.
+
+   An application that sends a request or response message that includes
+   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
+   with this specification. Applications that are at least conditionally
+   compliant with this specification SHOULD use an HTTP-Version of
+   "HTTP/1.1" in their messages, and MUST do so for any message that is
+   not compatible with HTTP/1.0. For more details on when to send
+   specific HTTP-Version values, see RFC 2145 [36].
+
+   The HTTP version of an application is the highest HTTP version for
+   which the application is at least conditionally compliant.
+
+   Proxy and gateway applications need to be careful when forwarding
+   messages in protocol versions different from that of the application.
+   Since the protocol version indicates the protocol capability of the
+   sender, a proxy/gateway MUST NOT send a message with a version
+   indicator which is greater than its actual version. If a higher
+   version request is received, the proxy/gateway MUST either downgrade
+   the request version, or respond with an error, or switch to tunnel
+   behavior.
+
+   Due to interoperability problems with HTTP/1.0 proxies discovered
+   since the publication of RFC 2068[33], caching proxies MUST, gateways
+   MAY, and tunnels MUST NOT upgrade the request to the highest version
+   they support. The proxy/gateway's response to that request MUST be in
+   the same major version as the request.
+
+      Note: Converting between versions of HTTP may involve modification
+      of header fields required or forbidden by the versions involved.
+
+3.2 Uniform Resource Identifiers
+
+   URIs have been known by many names: WWW addresses, Universal Document
+   Identifiers, Universal Resource Identifiers [3], and finally the
+   combination of Uniform Resource Locators (URL) [4] and Names (URN)
+   [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
+   simply formatted strings which identify--via name, location, or any
+   other characteristic--a resource.
+
+
+
+Fielding, et al.            Standards Track                    [Page 18]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+3.2.1 General Syntax
+
+   URIs in HTTP can be represented in absolute form or relative to some
+   known base URI [11], depending upon the context of their use. The two
+   forms are differentiated by the fact that absolute URIs always begin
+   with a scheme name followed by a colon. For definitive information on
+   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
+   Generic Syntax and Semantics," RFC 2396 [42] (which replaces RFCs
+   1738 [4] and RFC 1808 [11]). This specification adopts the
+   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
+   "host","abs_path", "rel_path", and "authority" from that
+   specification.
+
+   The HTTP protocol does not place any a priori limit on the length of
+   a URI. Servers MUST be able to handle the URI of any resource they
+   serve, and SHOULD be able to handle URIs of unbounded length if they
+   provide GET-based forms that could generate such URIs. A server
+   SHOULD return 414 (Request-URI Too Long) status if a URI is longer
+   than the server can handle (see section 10.4.15).
+
+      Note: Servers ought to be cautious about depending on URI lengths
+      above 255 bytes, because some older client or proxy
+      implementations might not properly support these lengths.
+
+3.2.2 http URL
+
+   The "http" scheme is used to locate network resources via the HTTP
+   protocol. This section defines the scheme-specific syntax and
+   semantics for http URLs.
+
+   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
+
+   If the port is empty or not given, port 80 is assumed. The semantics
+   are that the identified resource is located at the server listening
+   for TCP connections on that port of that host, and the Request-URI
+   for the resource is abs_path (section 5.1.2). The use of IP addresses
+   in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). If
+   the abs_path is not present in the URL, it MUST be given as "/" when
+   used as a Request-URI for a resource (section 5.1.2). If a proxy
+   receives a host name which is not a fully qualified domain name, it
+   MAY add its domain to the host name it received. If a proxy receives
+   a fully qualified domain name, the proxy MUST NOT change the host
+   name.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 19]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+3.2.3 URI Comparison
+
+   When comparing two URIs to decide if they match or not, a client
+   SHOULD use a case-sensitive octet-by-octet comparison of the entire
+   URIs, with these exceptions:
+
+      - A port that is empty or not given is equivalent to the default
+        port for that URI-reference;
+
+        - Comparisons of host names MUST be case-insensitive;
+
+        - Comparisons of scheme names MUST be case-insensitive;
+
+        - An empty abs_path is equivalent to an abs_path of "/".
+
+   Characters other than those in the "reserved" and "unsafe" sets (see
+   RFC 2396 [42]) are equivalent to their ""%" HEX HEX" encoding.
+
+   For example, the following three URIs are equivalent:
+
+      http://abc.com:80/~smith/home.html
+      http://ABC.com/%7Esmith/home.html
+      http://ABC.com:/%7esmith/home.html
+
+3.3 Date/Time Formats
+
+3.3.1 Full Date
+
+   HTTP applications have historically allowed three different formats
+   for the representation of date/time stamps:
+
+      Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
+      Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
+      Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
+
+   The first format is preferred as an Internet standard and represents
+   a fixed-length subset of that defined by RFC 1123 [8] (an update to
+   RFC 822 [9]). The second format is in common use, but is based on the
+   obsolete RFC 850 [12] date format and lacks a four-digit year.
+   HTTP/1.1 clients and servers that parse the date value MUST accept
+   all three formats (for compatibility with HTTP/1.0), though they MUST
+   only generate the RFC 1123 format for representing HTTP-date values
+   in header fields. See section 19.3 for further information.
+
+      Note: Recipients of date values are encouraged to be robust in
+      accepting date values that may have been sent by non-HTTP
+      applications, as is sometimes the case when retrieving or posting
+      messages via proxies/gateways to SMTP or NNTP.
+
+
+
+Fielding, et al.            Standards Track                    [Page 20]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   All HTTP date/time stamps MUST be represented in Greenwich Mean Time
+   (GMT), without exception. For the purposes of HTTP, GMT is exactly
+   equal to UTC (Coordinated Universal Time). This is indicated in the
+   first two formats by the inclusion of "GMT" as the three-letter
+   abbreviation for time zone, and MUST be assumed when reading the
+   asctime format. HTTP-date is case sensitive and MUST NOT include
+   additional LWS beyond that specifically included as SP in the
+   grammar.
+
+       HTTP-date    = rfc1123-date | rfc850-date | asctime-date
+       rfc1123-date = wkday "," SP date1 SP time SP "GMT"
+       rfc850-date  = weekday "," SP date2 SP time SP "GMT"
+       asctime-date = wkday SP date3 SP time SP 4DIGIT
+       date1        = 2DIGIT SP month SP 4DIGIT
+                      ; day month year (e.g., 02 Jun 1982)
+       date2        = 2DIGIT "-" month "-" 2DIGIT
+                      ; day-month-year (e.g., 02-Jun-82)
+       date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
+                      ; month day (e.g., Jun  2)
+       time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
+                      ; 00:00:00 - 23:59:59
+       wkday        = "Mon" | "Tue" | "Wed"
+                    | "Thu" | "Fri" | "Sat" | "Sun"
+       weekday      = "Monday" | "Tuesday" | "Wednesday"
+                    | "Thursday" | "Friday" | "Saturday" | "Sunday"
+       month        = "Jan" | "Feb" | "Mar" | "Apr"
+                    | "May" | "Jun" | "Jul" | "Aug"
+                    | "Sep" | "Oct" | "Nov" | "Dec"
+
+      Note: HTTP requirements for the date/time stamp format apply only
+      to their usage within the protocol stream. Clients and servers are
+      not required to use these formats for user presentation, request
+      logging, etc.
+
+3.3.2 Delta Seconds
+
+   Some HTTP header fields allow a time value to be specified as an
+   integer number of seconds, represented in decimal, after the time
+   that the message was received.
+
+       delta-seconds  = 1*DIGIT
+
+3.4 Character Sets
+
+   HTTP uses the same definition of the term "character set" as that
+   described for MIME:
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 21]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The term "character set" is used in this document to refer to a
+   method used with one or more tables to convert a sequence of octets
+   into a sequence of characters. Note that unconditional conversion in
+   the other direction is not required, in that not all characters may
+   be available in a given character set and a character set may provide
+   more than one sequence of octets to represent a particular character.
+   This definition is intended to allow various kinds of character
+   encoding, from simple single-table mappings such as US-ASCII to
+   complex table switching methods such as those that use ISO-2022's
+   techniques. However, the definition associated with a MIME character
+   set name MUST fully specify the mapping to be performed from octets
+   to characters. In particular, use of external profiling information
+   to determine the exact mapping is not permitted.
+
+      Note: This use of the term "character set" is more commonly
+      referred to as a "character encoding." However, since HTTP and
+      MIME share the same registry, it is important that the terminology
+      also be shared.
+
+   HTTP character sets are identified by case-insensitive tokens. The
+   complete set of tokens is defined by the IANA Character Set registry
+   [19].
+
+       charset = token
+
+   Although HTTP allows an arbitrary token to be used as a charset
+   value, any token that has a predefined value within the IANA
+   Character Set registry [19] MUST represent the character set defined
+   by that registry. Applications SHOULD limit their use of character
+   sets to those defined by the IANA registry.
+
+   Implementors should be aware of IETF character set requirements [38]
+   [41].
+
+3.4.1 Missing Charset
+
+   Some HTTP/1.0 software has interpreted a Content-Type header without
+   charset parameter incorrectly to mean "recipient should guess."
+   Senders wishing to defeat this behavior MAY include a charset
+   parameter even when the charset is ISO-8859-1 and SHOULD do so when
+   it is known that it will not confuse the recipient.
+
+   Unfortunately, some older HTTP/1.0 clients did not deal properly with
+   an explicit charset parameter. HTTP/1.1 recipients MUST respect the
+   charset label provided by the sender; and those user agents that have
+   a provision to "guess" a charset MUST use the charset from the
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 22]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   content-type field if they support that charset, rather than the
+   recipient's preference, when initially displaying a document. See
+   section 3.7.1.
+
+3.5 Content Codings
+
+   Content coding values indicate an encoding transformation that has
+   been or can be applied to an entity. Content codings are primarily
+   used to allow a document to be compressed or otherwise usefully
+   transformed without losing the identity of its underlying media type
+   and without loss of information. Frequently, the entity is stored in
+   coded form, transmitted directly, and only decoded by the recipient.
+
+       content-coding   = token
+
+   All content-coding values are case-insensitive. HTTP/1.1 uses
+   content-coding values in the Accept-Encoding (section 14.3) and
+   Content-Encoding (section 14.11) header fields. Although the value
+   describes the content-coding, what is more important is that it
+   indicates what decoding mechanism will be required to remove the
+   encoding.
+
+   The Internet Assigned Numbers Authority (IANA) acts as a registry for
+   content-coding value tokens. Initially, the registry contains the
+   following tokens:
+
+   gzip An encoding format produced by the file compression program
+        "gzip" (GNU zip) as described in RFC 1952 [25]. This format is a
+        Lempel-Ziv coding (LZ77) with a 32 bit CRC.
+
+   compress
+        The encoding format produced by the common UNIX file compression
+        program "compress". This format is an adaptive Lempel-Ziv-Welch
+        coding (LZW).
+
+        Use of program names for the identification of encoding formats
+        is not desirable and is discouraged for future encodings. Their
+        use here is representative of historical practice, not good
+        design. For compatibility with previous implementations of HTTP,
+        applications SHOULD consider "x-gzip" and "x-compress" to be
+        equivalent to "gzip" and "compress" respectively.
+
+   deflate
+        The "zlib" format defined in RFC 1950 [31] in combination with
+        the "deflate" compression mechanism described in RFC 1951 [29].
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 23]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   identity
+        The default (identity) encoding; the use of no transformation
+        whatsoever. This content-coding is used only in the Accept-
+        Encoding header, and SHOULD NOT be used in the Content-Encoding
+        header.
+
+   New content-coding value tokens SHOULD be registered; to allow
+   interoperability between clients and servers, specifications of the
+   content coding algorithms needed to implement a new value SHOULD be
+   publicly available and adequate for independent implementation, and
+   conform to the purpose of content coding defined in this section.
+
+3.6 Transfer Codings
+
+   Transfer-coding values are used to indicate an encoding
+   transformation that has been, can be, or may need to be applied to an
+   entity-body in order to ensure "safe transport" through the network.
+   This differs from a content coding in that the transfer-coding is a
+   property of the message, not of the original entity.
+
+       transfer-coding         = "chunked" | transfer-extension
+       transfer-extension      = token *( ";" parameter )
+
+   Parameters are in  the form of attribute/value pairs.
+
+       parameter               = attribute "=" value
+       attribute               = token
+       value                   = token | quoted-string
+
+   All transfer-coding values are case-insensitive. HTTP/1.1 uses
+   transfer-coding values in the TE header field (section 14.39) and in
+   the Transfer-Encoding header field (section 14.41).
+
+   Whenever a transfer-coding is applied to a message-body, the set of
+   transfer-codings MUST include "chunked", unless the message is
+   terminated by closing the connection. When the "chunked" transfer-
+   coding is used, it MUST be the last transfer-coding applied to the
+   message-body. The "chunked" transfer-coding MUST NOT be applied more
+   than once to a message-body. These rules allow the recipient to
+   determine the transfer-length of the message (section 4.4).
+
+   Transfer-codings are analogous to the Content-Transfer-Encoding
+   values of MIME [7], which were designed to enable safe transport of
+   binary data over a 7-bit transport service. However, safe transport
+   has a different focus for an 8bit-clean transfer protocol. In HTTP,
+   the only unsafe characteristic of message-bodies is the difficulty in
+   determining the exact body length (section 7.2.2), or the desire to
+   encrypt data over a shared transport.
+
+
+
+Fielding, et al.            Standards Track                    [Page 24]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Internet Assigned Numbers Authority (IANA) acts as a registry for
+   transfer-coding value tokens. Initially, the registry contains the
+   following tokens: "chunked" (section 3.6.1), "identity" (section
+   3.6.2), "gzip" (section 3.5), "compress" (section 3.5), and "deflate"
+   (section 3.5).
+
+   New transfer-coding value tokens SHOULD be registered in the same way
+   as new content-coding value tokens (section 3.5).
+
+   A server which receives an entity-body with a transfer-coding it does
+   not understand SHOULD return 501 (Unimplemented), and close the
+   connection. A server MUST NOT send transfer-codings to an HTTP/1.0
+   client.
+
+3.6.1 Chunked Transfer Coding
+
+   The chunked encoding modifies the body of a message in order to
+   transfer it as a series of chunks, each with its own size indicator,
+   followed by an OPTIONAL trailer containing entity-header fields. This
+   allows dynamically produced content to be transferred along with the
+   information necessary for the recipient to verify that it has
+   received the full message.
+
+       Chunked-Body   = *chunk
+                        last-chunk
+                        trailer
+                        CRLF
+
+       chunk          = chunk-size [ chunk-extension ] CRLF
+                        chunk-data CRLF
+       chunk-size     = 1*HEX
+       last-chunk     = 1*("0") [ chunk-extension ] CRLF
+
+       chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
+       chunk-ext-name = token
+       chunk-ext-val  = token | quoted-string
+       chunk-data     = chunk-size(OCTET)
+       trailer        = *(entity-header CRLF)
+
+   The chunk-size field is a string of hex digits indicating the size of
+   the chunk. The chunked encoding is ended by any chunk whose size is
+   zero, followed by the trailer, which is terminated by an empty line.
+
+   The trailer allows the sender to include additional HTTP header
+   fields at the end of the message. The Trailer header field can be
+   used to indicate which header fields are included in a trailer (see
+   section 14.40).
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 25]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A server using chunked transfer-coding in a response MUST NOT use the
+   trailer for any header fields unless at least one of the following is
+   true:
+
+   a)the request included a TE header field that indicates "trailers" is
+     acceptable in the transfer-coding of the  response, as described in
+     section 14.39; or,
+
+   b)the server is the origin server for the response, the trailer
+     fields consist entirely of optional metadata, and the recipient
+     could use the message (in a manner acceptable to the origin server)
+     without receiving this metadata.  In other words, the origin server
+     is willing to accept the possibility that the trailer fields might
+     be silently discarded along the path to the client.
+
+   This requirement prevents an interoperability failure when the
+   message is being received by an HTTP/1.1 (or later) proxy and
+   forwarded to an HTTP/1.0 recipient. It avoids a situation where
+   compliance with the protocol would have necessitated a possibly
+   infinite buffer on the proxy.
+
+   An example process for decoding a Chunked-Body is presented in
+   appendix 19.4.6.
+
+   All HTTP/1.1 applications MUST be able to receive and decode the
+   "chunked" transfer-coding, and MUST ignore chunk-extension extensions
+   they do not understand.
+
+3.7 Media Types
+
+   HTTP uses Internet Media Types [17] in the Content-Type (section
+   14.17) and Accept (section 14.1) header fields in order to provide
+   open and extensible data typing and type negotiation.
+
+       media-type     = type "/" subtype *( ";" parameter )
+       type           = token
+       subtype        = token
+
+   Parameters MAY follow the type/subtype in the form of attribute/value
+   pairs (as defined in section 3.6).
+
+   The type, subtype, and parameter attribute names are case-
+   insensitive. Parameter values might or might not be case-sensitive,
+   depending on the semantics of the parameter name. Linear white space
+   (LWS) MUST NOT be used between the type and subtype, nor between an
+   attribute and its value. The presence or absence of a parameter might
+   be significant to the processing of a media-type, depending on its
+   definition within the media type registry.
+
+
+
+Fielding, et al.            Standards Track                    [Page 26]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Note that some older HTTP applications do not recognize media type
+   parameters. When sending data to older HTTP applications,
+   implementations SHOULD only use media type parameters when they are
+   required by that type/subtype definition.
+
+   Media-type values are registered with the Internet Assigned Number
+   Authority (IANA [19]). The media type registration process is
+   outlined in RFC 1590 [17]. Use of non-registered media types is
+   discouraged.
+
+3.7.1 Canonicalization and Text Defaults
+
+   Internet media types are registered with a canonical form. An
+   entity-body transferred via HTTP messages MUST be represented in the
+   appropriate canonical form prior to its transmission except for
+   "text" types, as defined in the next paragraph.
+
+   When in canonical form, media subtypes of the "text" type use CRLF as
+   the text line break. HTTP relaxes this requirement and allows the
+   transport of text media with plain CR or LF alone representing a line
+   break when it is done consistently for an entire entity-body. HTTP
+   applications MUST accept CRLF, bare CR, and bare LF as being
+   representative of a line break in text media received via HTTP. In
+   addition, if the text is represented in a character set that does not
+   use octets 13 and 10 for CR and LF respectively, as is the case for
+   some multi-byte character sets, HTTP allows the use of whatever octet
+   sequences are defined by that character set to represent the
+   equivalent of CR and LF for line breaks. This flexibility regarding
+   line breaks applies only to text media in the entity-body; a bare CR
+   or LF MUST NOT be substituted for CRLF within any of the HTTP control
+   structures (such as header fields and multipart boundaries).
+
+   If an entity-body is encoded with a content-coding, the underlying
+   data MUST be in a form defined above prior to being encoded.
+
+   The "charset" parameter is used with some media types to define the
+   character set (section 3.4) of the data. When no explicit charset
+   parameter is provided by the sender, media subtypes of the "text"
+   type are defined to have a default charset value of "ISO-8859-1" when
+   received via HTTP. Data in character sets other than "ISO-8859-1" or
+   its subsets MUST be labeled with an appropriate charset value. See
+   section 3.4.1 for compatibility problems.
+
+3.7.2 Multipart Types
+
+   MIME provides for a number of "multipart" types -- encapsulations of
+   one or more entities within a single message-body. All multipart
+   types share a common syntax, as defined in section 5.1.1 of RFC 2046
+
+
+
+Fielding, et al.            Standards Track                    [Page 27]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [40], and MUST include a boundary parameter as part of the media type
+   value. The message body is itself a protocol element and MUST
+   therefore use only CRLF to represent line breaks between body-parts.
+   Unlike in RFC 2046, the epilogue of any multipart message MUST be
+   empty; HTTP applications MUST NOT transmit the epilogue (even if the
+   original multipart contains an epilogue). These restrictions exist in
+   order to preserve the self-delimiting nature of a multipart message-
+   body, wherein the "end" of the message-body is indicated by the
+   ending multipart boundary.
+
+   In general, HTTP treats a multipart message-body no differently than
+   any other media type: strictly as payload. The one exception is the
+   "multipart/byteranges" type (appendix 19.2) when it appears in a 206
+   (Partial Content) response, which will be interpreted by some HTTP
+   caching mechanisms as described in sections 13.5.4 and 14.16. In all
+   other cases, an HTTP user agent SHOULD follow the same or similar
+   behavior as a MIME user agent would upon receipt of a multipart type.
+   The MIME header fields within each body-part of a multipart message-
+   body do not have any significance to HTTP beyond that defined by
+   their MIME semantics.
+
+   In general, an HTTP user agent SHOULD follow the same or similar
+   behavior as a MIME user agent would upon receipt of a multipart type.
+   If an application receives an unrecognized multipart subtype, the
+   application MUST treat it as being equivalent to "multipart/mixed".
+
+      Note: The "multipart/form-data" type has been specifically defined
+      for carrying form data suitable for processing via the POST
+      request method, as described in RFC 1867 [15].
+
+3.8 Product Tokens
+
+   Product tokens are used to allow communicating applications to
+   identify themselves by software name and version. Most fields using
+   product tokens also allow sub-products which form a significant part
+   of the application to be listed, separated by white space. By
+   convention, the products are listed in order of their significance
+   for identifying the application.
+
+       product         = token ["/" product-version]
+       product-version = token
+
+   Examples:
+
+       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+       Server: Apache/0.8.4
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 28]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Product tokens SHOULD be short and to the point. They MUST NOT be
+   used for advertising or other non-essential information. Although any
+   token character MAY appear in a product-version, this token SHOULD
+   only be used for a version identifier (i.e., successive versions of
+   the same product SHOULD only differ in the product-version portion of
+   the product value).
+
+3.9 Quality Values
+
+   HTTP content negotiation (section 12) uses short "floating point"
+   numbers to indicate the relative importance ("weight") of various
+   negotiable parameters.  A weight is normalized to a real number in
+   the range 0 through 1, where 0 is the minimum and 1 the maximum
+   value. If a parameter has a quality value of 0, then content with
+   this parameter is `not acceptable' for the client. HTTP/1.1
+   applications MUST NOT generate more than three digits after the
+   decimal point. User configuration of these values SHOULD also be
+   limited in this fashion.
+
+       qvalue         = ( "0" [ "." 0*3DIGIT ] )
+                      | ( "1" [ "." 0*3("0") ] )
+
+   "Quality values" is a misnomer, since these values merely represent
+   relative degradation in desired quality.
+
+3.10 Language Tags
+
+   A language tag identifies a natural language spoken, written, or
+   otherwise conveyed by human beings for communication of information
+   to other human beings. Computer languages are explicitly excluded.
+   HTTP uses language tags within the Accept-Language and Content-
+   Language fields.
+
+   The syntax and registry of HTTP language tags is the same as that
+   defined by RFC 1766 [1]. In summary, a language tag is composed of 1
+   or more parts: A primary language tag and a possibly empty series of
+   subtags:
+
+        language-tag  = primary-tag *( "-" subtag )
+        primary-tag   = 1*8ALPHA
+        subtag        = 1*8ALPHA
+
+   White space is not allowed within the tag and all tags are case-
+   insensitive. The name space of language tags is administered by the
+   IANA. Example tags include:
+
+       en, en-US, en-cockney, i-cherokee, x-pig-latin
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 29]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   where any two-letter primary-tag is an ISO-639 language abbreviation
+   and any two-letter initial subtag is an ISO-3166 country code. (The
+   last three tags above are not registered tags; all but the last are
+   examples of tags which could be registered in future.)
+
+3.11 Entity Tags
+
+   Entity tags are used for comparing two or more entities from the same
+   requested resource. HTTP/1.1 uses entity tags in the ETag (section
+   14.19), If-Match (section 14.24), If-None-Match (section 14.26), and
+   If-Range (section 14.27) header fields. The definition of how they
+   are used and compared as cache validators is in section 13.3.3. An
+   entity tag consists of an opaque quoted string, possibly prefixed by
+   a weakness indicator.
+
+      entity-tag = [ weak ] opaque-tag
+      weak       = "W/"
+      opaque-tag = quoted-string
+
+   A "strong entity tag" MAY be shared by two entities of a resource
+   only if they are equivalent by octet equality.
+
+   A "weak entity tag," indicated by the "W/" prefix, MAY be shared by
+   two entities of a resource only if the entities are equivalent and
+   could be substituted for each other with no significant change in
+   semantics. A weak entity tag can only be used for weak comparison.
+
+   An entity tag MUST be unique across all versions of all entities
+   associated with a particular resource. A given entity tag value MAY
+   be used for entities obtained by requests on different URIs. The use
+   of the same entity tag value in conjunction with entities obtained by
+   requests on different URIs does not imply the equivalence of those
+   entities.
+
+3.12 Range Units
+
+   HTTP/1.1 allows a client to request that only part (a range of) the
+   response entity be included within the response. HTTP/1.1 uses range
+   units in the Range (section 14.35) and Content-Range (section 14.16)
+   header fields. An entity can be broken down into subranges according
+   to various structural units.
+
+      range-unit       = bytes-unit | other-range-unit
+      bytes-unit       = "bytes"
+      other-range-unit = token
+
+   The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
+   implementations MAY ignore ranges specified using other units.
+
+
+
+Fielding, et al.            Standards Track                    [Page 30]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 has been designed to allow implementations of applications
+   that do not depend on knowledge of ranges.
+
+4 HTTP Message
+
+4.1 Message Types
+
+   HTTP messages consist of requests from client to server and responses
+   from server to client.
+
+       HTTP-message   = Request | Response     ; HTTP/1.1 messages
+
+   Request (section 5) and Response (section 6) messages use the generic
+   message format of RFC 822 [9] for transferring entities (the payload
+   of the message). Both types of message consist of a start-line, zero
+   or more header fields (also known as "headers"), an empty line (i.e.,
+   a line with nothing preceding the CRLF) indicating the end of the
+   header fields, and possibly a message-body.
+
+        generic-message = start-line
+                          *(message-header CRLF)
+                          CRLF
+                          [ message-body ]
+        start-line      = Request-Line | Status-Line
+
+   In the interest of robustness, servers SHOULD ignore any empty
+   line(s) received where a Request-Line is expected. In other words, if
+   the server is reading the protocol stream at the beginning of a
+   message and receives a CRLF first, it should ignore the CRLF.
+
+   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
+   after a POST request. To restate what is explicitly forbidden by the
+   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
+   extra CRLF.
+
+4.2 Message Headers
+
+   HTTP header fields, which include general-header (section 4.5),
+   request-header (section 5.3), response-header (section 6.2), and
+   entity-header (section 7.1) fields, follow the same generic format as
+   that given in Section 3.1 of RFC 822 [9]. Each header field consists
+   of a name followed by a colon (":") and the field value. Field names
+   are case-insensitive. The field value MAY be preceded by any amount
+   of LWS, though a single SP is preferred. Header fields can be
+   extended over multiple lines by preceding each extra line with at
+   least one SP or HT. Applications ought to follow "common form", where
+   one is known or indicated, when generating HTTP constructs, since
+   there might exist some implementations that fail to accept anything
+
+
+
+Fielding, et al.            Standards Track                    [Page 31]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   beyond the common forms.
+
+       message-header = field-name ":" [ field-value ]
+       field-name     = token
+       field-value    = *( field-content | LWS )
+       field-content  = <the OCTETs making up the field-value
+                        and consisting of either *TEXT or combinations
+                        of token, separators, and quoted-string>
+
+   The field-content does not include any leading or trailing LWS:
+   linear white space occurring before the first non-whitespace
+   character of the field-value or after the last non-whitespace
+   character of the field-value. Such leading or trailing LWS MAY be
+   removed without changing the semantics of the field value. Any LWS
+   that occurs between field-content MAY be replaced with a single SP
+   before interpreting the field value or forwarding the message
+   downstream.
+
+   The order in which header fields with differing field names are
+   received is not significant. However, it is "good practice" to send
+   general-header fields first, followed by request-header or response-
+   header fields, and ending with the entity-header fields.
+
+   Multiple message-header fields with the same field-name MAY be
+   present in a message if and only if the entire field-value for that
+   header field is defined as a comma-separated list [i.e., #(values)].
+   It MUST be possible to combine the multiple header fields into one
+   "field-name: field-value" pair, without changing the semantics of the
+   message, by appending each subsequent field-value to the first, each
+   separated by a comma. The order in which header fields with the same
+   field-name are received is therefore significant to the
+   interpretation of the combined field value, and thus a proxy MUST NOT
+   change the order of these field values when a message is forwarded.
+
+4.3 Message Body
+
+   The message-body (if any) of an HTTP message is used to carry the
+   entity-body associated with the request or response. The message-body
+   differs from the entity-body only when a transfer-coding has been
+   applied, as indicated by the Transfer-Encoding header field (section
+   14.41).
+
+       message-body = entity-body
+                    | <entity-body encoded as per Transfer-Encoding>
+
+   Transfer-Encoding MUST be used to indicate any transfer-codings
+   applied by an application to ensure safe and proper transfer of the
+   message. Transfer-Encoding is a property of the message, not of the
+
+
+
+Fielding, et al.            Standards Track                    [Page 32]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   entity, and thus MAY be added or removed by any application along the
+   request/response chain. (However, section 3.6 places restrictions on
+   when certain transfer-codings may be used.)
+
+   The rules for when a message-body is allowed in a message differ for
+   requests and responses.
+
+   The presence of a message-body in a request is signaled by the
+   inclusion of a Content-Length or Transfer-Encoding header field in
+   the request's message-headers. A message-body MUST NOT be included in
+   a request if the specification of the request method (section 5.1.1)
+   does not allow sending an entity-body in requests. A server SHOULD
+   read and forward a message-body on any request; if the request method
+   does not include defined semantics for an entity-body, then the
+   message-body SHOULD be ignored when handling the request.
+
+   For response messages, whether or not a message-body is included with
+   a message is dependent on both the request method and the response
+   status code (section 6.1.1). All responses to the HEAD request method
+   MUST NOT include a message-body, even though the presence of entity-
+   header fields might lead one to believe they do. All 1xx
+   (informational), 204 (no content), and 304 (not modified) responses
+   MUST NOT include a message-body. All other responses do include a
+   message-body, although it MAY be of zero length.
+
+4.4 Message Length
+
+   The transfer-length of a message is the length of the message-body as
+   it appears in the message; that is, after any transfer-codings have
+   been applied. When a message-body is included with a message, the
+   transfer-length of that body is determined by one of the following
+   (in order of precedence):
+
+   1.Any response message which "MUST NOT" include a message-body (such
+     as the 1xx, 204, and 304 responses and any response to a HEAD
+     request) is always terminated by the first empty line after the
+     header fields, regardless of the entity-header fields present in
+     the message.
+
+   2.If a Transfer-Encoding header field (section 14.41) is present and
+     has any value other than "identity", then the transfer-length is
+     defined by use of the "chunked" transfer-coding (section 3.6),
+     unless the message is terminated by closing the connection.
+
+   3.If a Content-Length header field (section 14.13) is present, its
+     decimal value in OCTETs represents both the entity-length and the
+     transfer-length. The Content-Length header field MUST NOT be sent
+     if these two lengths are different (i.e., if a Transfer-Encoding
+
+
+
+Fielding, et al.            Standards Track                    [Page 33]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+     header field is present). If a message is received with both a
+     Transfer-Encoding header field and a Content-Length header field,
+     the latter MUST be ignored.
+
+   4.If the message uses the media type "multipart/byteranges", and the
+     ransfer-length is not otherwise specified, then this self-
+     elimiting media type defines the transfer-length. This media type
+     UST NOT be used unless the sender knows that the recipient can arse
+     it; the presence in a request of a Range header with ultiple byte-
+     range specifiers from a 1.1 client implies that the lient can parse
+     multipart/byteranges responses.
+
+       A range header might be forwarded by a 1.0 proxy that does not
+       understand multipart/byteranges; in this case the server MUST
+       delimit the message using methods defined in items 1,3 or 5 of
+       this section.
+
+   5.By the server closing the connection. (Closing the connection
+     cannot be used to indicate the end of a request body, since that
+     would leave no possibility for the server to send back a response.)
+
+   For compatibility with HTTP/1.0 applications, HTTP/1.1 requests
+   containing a message-body MUST include a valid Content-Length header
+   field unless the server is known to be HTTP/1.1 compliant. If a
+   request contains a message-body and a Content-Length is not given,
+   the server SHOULD respond with 400 (bad request) if it cannot
+   determine the length of the message, or with 411 (length required) if
+   it wishes to insist on receiving a valid Content-Length.
+
+   All HTTP/1.1 applications that receive entities MUST accept the
+   "chunked" transfer-coding (section 3.6), thus allowing this mechanism
+   to be used for messages when the message length cannot be determined
+   in advance.
+
+   Messages MUST NOT include both a Content-Length header field and a
+   non-identity transfer-coding. If the message does include a non-
+   identity transfer-coding, the Content-Length MUST be ignored.
+
+   When a Content-Length is given in a message where a message-body is
+   allowed, its field value MUST exactly match the number of OCTETs in
+   the message-body. HTTP/1.1 user agents MUST notify the user when an
+   invalid length is received and detected.
+
+4.5 General Header Fields
+
+   There are a few header fields which have general applicability for
+   both request and response messages, but which do not apply to the
+   entity being transferred. These header fields apply only to the
+
+
+
+Fielding, et al.            Standards Track                    [Page 34]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   message being transmitted.
+
+       general-header = Cache-Control            ; Section 14.9
+                      | Connection               ; Section 14.10
+                      | Date                     ; Section 14.18
+                      | Pragma                   ; Section 14.32
+                      | Trailer                  ; Section 14.40
+                      | Transfer-Encoding        ; Section 14.41
+                      | Upgrade                  ; Section 14.42
+                      | Via                      ; Section 14.45
+                      | Warning                  ; Section 14.46
+
+   General-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields may be given the semantics of general
+   header fields if all parties in the communication recognize them to
+   be general-header fields. Unrecognized header fields are treated as
+   entity-header fields.
+
+5 Request
+
+   A request message from a client to a server includes, within the
+   first line of that message, the method to be applied to the resource,
+   the identifier of the resource, and the protocol version in use.
+
+        Request       = Request-Line              ; Section 5.1
+                        *(( general-header        ; Section 4.5
+                         | request-header         ; Section 5.3
+                         | entity-header ) CRLF)  ; Section 7.1
+                        CRLF
+                        [ message-body ]          ; Section 4.3
+
+5.1 Request-Line
+
+   The Request-Line begins with a method token, followed by the
+   Request-URI and the protocol version, and ending with CRLF. The
+   elements are separated by SP characters. No CR or LF is allowed
+   except in the final CRLF sequence.
+
+        Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 35]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+5.1.1 Method
+
+   The Method  token indicates the method to be performed on the
+   resource identified by the Request-URI. The method is case-sensitive.
+
+       Method         = "OPTIONS"                ; Section 9.2
+                      | "GET"                    ; Section 9.3
+                      | "HEAD"                   ; Section 9.4
+                      | "POST"                   ; Section 9.5
+                      | "PUT"                    ; Section 9.6
+                      | "DELETE"                 ; Section 9.7
+                      | "TRACE"                  ; Section 9.8
+                      | "CONNECT"                ; Section 9.9
+                      | extension-method
+       extension-method = token
+
+   The list of methods allowed by a resource can be specified in an
+   Allow header field (section 14.7). The return code of the response
+   always notifies the client whether a method is currently allowed on a
+   resource, since the set of allowed methods can change dynamically. An
+   origin server SHOULD return the status code 405 (Method Not Allowed)
+   if the method is known by the origin server but not allowed for the
+   requested resource, and 501 (Not Implemented) if the method is
+   unrecognized or not implemented by the origin server. The methods GET
+   and HEAD MUST be supported by all general-purpose servers. All other
+   methods are OPTIONAL; however, if the above methods are implemented,
+   they MUST be implemented with the same semantics as those specified
+   in section 9.
+
+5.1.2 Request-URI
+
+   The Request-URI is a Uniform Resource Identifier (section 3.2) and
+   identifies the resource upon which to apply the request.
+
+       Request-URI    = "*" | absoluteURI | abs_path | authority
+
+   The four options for Request-URI are dependent on the nature of the
+   request. The asterisk "*" means that the request does not apply to a
+   particular resource, but to the server itself, and is only allowed
+   when the method used does not necessarily apply to a resource. One
+   example would be
+
+       OPTIONS * HTTP/1.1
+
+   The absoluteURI form is REQUIRED when the request is being made to a
+   proxy. The proxy is requested to forward the request or service it
+   from a valid cache, and return the response. Note that the proxy MAY
+   forward the request on to another proxy or directly to the server
+
+
+
+Fielding, et al.            Standards Track                    [Page 36]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   specified by the absoluteURI. In order to avoid request loops, a
+   proxy MUST be able to recognize all of its server names, including
+   any aliases, local variations, and the numeric IP address. An example
+   Request-Line would be:
+
+       GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1
+
+   To allow for transition to absoluteURIs in all requests in future
+   versions of HTTP, all HTTP/1.1 servers MUST accept the absoluteURI
+   form in requests, even though HTTP/1.1 clients will only generate
+   them in requests to proxies.
+
+   The authority form is only used by the CONNECT method (section 9.9).
+
+   The most common form of Request-URI is that used to identify a
+   resource on an origin server or gateway. In this case the absolute
+   path of the URI MUST be transmitted (see section 3.2.1, abs_path) as
+   the Request-URI, and the network location of the URI (authority) MUST
+   be transmitted in a Host header field. For example, a client wishing
+   to retrieve the resource above directly from the origin server would
+   create a TCP connection to port 80 of the host "www.w3.org" and send
+   the lines:
+
+       GET /pub/WWW/TheProject.html HTTP/1.1
+       Host: www.w3.org
+
+   followed by the remainder of the Request. Note that the absolute path
+   cannot be empty; if none is present in the original URI, it MUST be
+   given as "/" (the server root).
+
+   The Request-URI is transmitted in the format specified in section
+   3.2.1. If the Request-URI is encoded using the "% HEX HEX" encoding
+   [42], the origin server MUST decode the Request-URI in order to
+   properly interpret the request. Servers SHOULD respond to invalid
+   Request-URIs with an appropriate status code.
+
+   A transparent proxy MUST NOT rewrite the "abs_path" part of the
+   received Request-URI when forwarding it to the next inbound server,
+   except as noted above to replace a null abs_path with "/".
+
+      Note: The "no rewrite" rule prevents the proxy from changing the
+      meaning of the request when the origin server is improperly using
+      a non-reserved URI character for a reserved purpose.  Implementors
+      should be aware that some pre-HTTP/1.1 proxies have been known to
+      rewrite the Request-URI.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 37]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+5.2 The Resource Identified by a Request
+
+   The exact resource identified by an Internet request is determined by
+   examining both the Request-URI and the Host header field.
+
+   An origin server that does not allow resources to differ by the
+   requested host MAY ignore the Host header field value when
+   determining the resource identified by an HTTP/1.1 request. (But see
+   section 19.6.1.1 for other requirements on Host support in HTTP/1.1.)
+
+   An origin server that does differentiate resources based on the host
+   requested (sometimes referred to as virtual hosts or vanity host
+   names) MUST use the following rules for determining the requested
+   resource on an HTTP/1.1 request:
+
+   1. If Request-URI is an absoluteURI, the host is part of the
+     Request-URI. Any Host header field value in the request MUST be
+     ignored.
+
+   2. If the Request-URI is not an absoluteURI, and the request includes
+     a Host header field, the host is determined by the Host header
+     field value.
+
+   3. If the host as determined by rule 1 or 2 is not a valid host on
+     the server, the response MUST be a 400 (Bad Request) error message.
+
+   Recipients of an HTTP/1.0 request that lacks a Host header field MAY
+   attempt to use heuristics (e.g., examination of the URI path for
+   something unique to a particular host) in order to determine what
+   exact resource is being requested.
+
+5.3 Request Header Fields
+
+   The request-header fields allow the client to pass additional
+   information about the request, and about the client itself, to the
+   server. These fields act as request modifiers, with semantics
+   equivalent to the parameters on a programming language method
+   invocation.
+
+       request-header = Accept                   ; Section 14.1
+                      | Accept-Charset           ; Section 14.2
+                      | Accept-Encoding          ; Section 14.3
+                      | Accept-Language          ; Section 14.4
+                      | Authorization            ; Section 14.8
+                      | Expect                   ; Section 14.20
+                      | From                     ; Section 14.22
+                      | Host                     ; Section 14.23
+                      | If-Match                 ; Section 14.24
+
+
+
+Fielding, et al.            Standards Track                    [Page 38]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                      | If-Modified-Since        ; Section 14.25
+                      | If-None-Match            ; Section 14.26
+                      | If-Range                 ; Section 14.27
+                      | If-Unmodified-Since      ; Section 14.28
+                      | Max-Forwards             ; Section 14.31
+                      | Proxy-Authorization      ; Section 14.34
+                      | Range                    ; Section 14.35
+                      | Referer                  ; Section 14.36
+                      | TE                       ; Section 14.39
+                      | User-Agent               ; Section 14.43
+
+   Request-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields MAY be given the semantics of request-
+   header fields if all parties in the communication recognize them to
+   be request-header fields. Unrecognized header fields are treated as
+   entity-header fields.
+
+6 Response
+
+   After receiving and interpreting a request message, a server responds
+   with an HTTP response message.
+
+       Response      = Status-Line               ; Section 6.1
+                       *(( general-header        ; Section 4.5
+                        | response-header        ; Section 6.2
+                        | entity-header ) CRLF)  ; Section 7.1
+                       CRLF
+                       [ message-body ]          ; Section 7.2
+
+6.1 Status-Line
+
+   The first line of a Response message is the Status-Line, consisting
+   of the protocol version followed by a numeric status code and its
+   associated textual phrase, with each element separated by SP
+   characters. No CR or LF is allowed except in the final CRLF sequence.
+
+       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
+
+6.1.1 Status Code and Reason Phrase
+
+   The Status-Code element is a 3-digit integer result code of the
+   attempt to understand and satisfy the request. These codes are fully
+   defined in section 10. The Reason-Phrase is intended to give a short
+   textual description of the Status-Code. The Status-Code is intended
+   for use by automata and the Reason-Phrase is intended for the human
+   user. The client is not required to examine or display the Reason-
+   Phrase.
+
+
+
+Fielding, et al.            Standards Track                    [Page 39]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The first digit of the Status-Code defines the class of response. The
+   last two digits do not have any categorization role. There are 5
+   values for the first digit:
+
+      - 1xx: Informational - Request received, continuing process
+
+      - 2xx: Success - The action was successfully received,
+        understood, and accepted
+
+      - 3xx: Redirection - Further action must be taken in order to
+        complete the request
+
+      - 4xx: Client Error - The request contains bad syntax or cannot
+        be fulfilled
+
+      - 5xx: Server Error - The server failed to fulfill an apparently
+        valid request
+
+   The individual values of the numeric status codes defined for
+   HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
+   presented below. The reason phrases listed here are only
+   recommendations -- they MAY be replaced by local equivalents without
+   affecting the protocol.
+
+      Status-Code    =
+            "100"  ; Section 10.1.1: Continue
+          | "101"  ; Section 10.1.2: Switching Protocols
+          | "200"  ; Section 10.2.1: OK
+          | "201"  ; Section 10.2.2: Created
+          | "202"  ; Section 10.2.3: Accepted
+          | "203"  ; Section 10.2.4: Non-Authoritative Information
+          | "204"  ; Section 10.2.5: No Content
+          | "205"  ; Section 10.2.6: Reset Content
+          | "206"  ; Section 10.2.7: Partial Content
+          | "300"  ; Section 10.3.1: Multiple Choices
+          | "301"  ; Section 10.3.2: Moved Permanently
+          | "302"  ; Section 10.3.3: Found
+          | "303"  ; Section 10.3.4: See Other
+          | "304"  ; Section 10.3.5: Not Modified
+          | "305"  ; Section 10.3.6: Use Proxy
+          | "307"  ; Section 10.3.8: Temporary Redirect
+          | "400"  ; Section 10.4.1: Bad Request
+          | "401"  ; Section 10.4.2: Unauthorized
+          | "402"  ; Section 10.4.3: Payment Required
+          | "403"  ; Section 10.4.4: Forbidden
+          | "404"  ; Section 10.4.5: Not Found
+          | "405"  ; Section 10.4.6: Method Not Allowed
+          | "406"  ; Section 10.4.7: Not Acceptable
+
+
+
+Fielding, et al.            Standards Track                    [Page 40]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+          | "407"  ; Section 10.4.8: Proxy Authentication Required
+          | "408"  ; Section 10.4.9: Request Time-out
+          | "409"  ; Section 10.4.10: Conflict
+          | "410"  ; Section 10.4.11: Gone
+          | "411"  ; Section 10.4.12: Length Required
+          | "412"  ; Section 10.4.13: Precondition Failed
+          | "413"  ; Section 10.4.14: Request Entity Too Large
+          | "414"  ; Section 10.4.15: Request-URI Too Large
+          | "415"  ; Section 10.4.16: Unsupported Media Type
+          | "416"  ; Section 10.4.17: Requested range not satisfiable
+          | "417"  ; Section 10.4.18: Expectation Failed
+          | "500"  ; Section 10.5.1: Internal Server Error
+          | "501"  ; Section 10.5.2: Not Implemented
+          | "502"  ; Section 10.5.3: Bad Gateway
+          | "503"  ; Section 10.5.4: Service Unavailable
+          | "504"  ; Section 10.5.5: Gateway Time-out
+          | "505"  ; Section 10.5.6: HTTP Version not supported
+          | extension-code
+
+      extension-code = 3DIGIT
+      Reason-Phrase  = *<TEXT, excluding CR, LF>
+
+   HTTP status codes are extensible. HTTP applications are not required
+   to understand the meaning of all registered status codes, though such
+   understanding is obviously desirable. However, applications MUST
+   understand the class of any status code, as indicated by the first
+   digit, and treat any unrecognized response as being equivalent to the
+   x00 status code of that class, with the exception that an
+   unrecognized response MUST NOT be cached. For example, if an
+   unrecognized status code of 431 is received by the client, it can
+   safely assume that there was something wrong with its request and
+   treat the response as if it had received a 400 status code. In such
+   cases, user agents SHOULD present to the user the entity returned
+   with the response, since that entity is likely to include human-
+   readable information which will explain the unusual status.
+
+6.2 Response Header Fields
+
+   The response-header fields allow the server to pass additional
+   information about the response which cannot be placed in the Status-
+   Line. These header fields give information about the server and about
+   further access to the resource identified by the Request-URI.
+
+       response-header = Accept-Ranges           ; Section 14.5
+                       | Age                     ; Section 14.6
+                       | ETag                    ; Section 14.19
+                       | Location                ; Section 14.30
+                       | Proxy-Authenticate      ; Section 14.33
+
+
+
+Fielding, et al.            Standards Track                    [Page 41]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                       | Retry-After             ; Section 14.37
+                       | Server                  ; Section 14.38
+                       | Vary                    ; Section 14.44
+                       | WWW-Authenticate        ; Section 14.47
+
+   Response-header field names can be extended reliably only in
+   combination with a change in the protocol version. However, new or
+   experimental header fields MAY be given the semantics of response-
+   header fields if all parties in the communication recognize them to
+   be response-header fields. Unrecognized header fields are treated as
+   entity-header fields.
+
+7 Entity
+
+   Request and Response messages MAY transfer an entity if not otherwise
+   restricted by the request method or response status code. An entity
+   consists of entity-header fields and an entity-body, although some
+   responses will only include the entity-headers.
+
+   In this section, both sender and recipient refer to either the client
+   or the server, depending on who sends and who receives the entity.
+
+7.1 Entity Header Fields
+
+   Entity-header fields define metainformation about the entity-body or,
+   if no body is present, about the resource identified by the request.
+   Some of this metainformation is OPTIONAL; some might be REQUIRED by
+   portions of this specification.
+
+       entity-header  = Allow                    ; Section 14.7
+                      | Content-Encoding         ; Section 14.11
+                      | Content-Language         ; Section 14.12
+                      | Content-Length           ; Section 14.13
+                      | Content-Location         ; Section 14.14
+                      | Content-MD5              ; Section 14.15
+                      | Content-Range            ; Section 14.16
+                      | Content-Type             ; Section 14.17
+                      | Expires                  ; Section 14.21
+                      | Last-Modified            ; Section 14.29
+                      | extension-header
+
+       extension-header = message-header
+
+   The extension-header mechanism allows additional entity-header fields
+   to be defined without changing the protocol, but these fields cannot
+   be assumed to be recognizable by the recipient. Unrecognized header
+   fields SHOULD be ignored by the recipient and MUST be forwarded by
+   transparent proxies.
+
+
+
+Fielding, et al.            Standards Track                    [Page 42]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+7.2 Entity Body
+
+   The entity-body (if any) sent with an HTTP request or response is in
+   a format and encoding defined by the entity-header fields.
+
+       entity-body    = *OCTET
+
+   An entity-body is only present in a message when a message-body is
+   present, as described in section 4.3. The entity-body is obtained
+   from the message-body by decoding any Transfer-Encoding that might
+   have been applied to ensure safe and proper transfer of the message.
+
+7.2.1 Type
+
+   When an entity-body is included with a message, the data type of that
+   body is determined via the header fields Content-Type and Content-
+   Encoding. These define a two-layer, ordered encoding model:
+
+       entity-body := Content-Encoding( Content-Type( data ) )
+
+   Content-Type specifies the media type of the underlying data.
+   Content-Encoding may be used to indicate any additional content
+   codings applied to the data, usually for the purpose of data
+   compression, that are a property of the requested resource. There is
+   no default encoding.
+
+   Any HTTP/1.1 message containing an entity-body SHOULD include a
+   Content-Type header field defining the media type of that body. If
+   and only if the media type is not given by a Content-Type field, the
+   recipient MAY attempt to guess the media type via inspection of its
+   content and/or the name extension(s) of the URI used to identify the
+   resource. If the media type remains unknown, the recipient SHOULD
+   treat it as type "application/octet-stream".
+
+7.2.2 Entity Length
+
+   The entity-length of a message is the length of the message-body
+   before any transfer-codings have been applied. Section 4.4 defines
+   how the transfer-length of a message-body is determined.
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 43]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8 Connections
+
+8.1 Persistent Connections
+
+8.1.1 Purpose
+
+   Prior to persistent connections, a separate TCP connection was
+   established to fetch each URL, increasing the load on HTTP servers
+   and causing congestion on the Internet. The use of inline images and
+   other associated data often require a client to make multiple
+   requests of the same server in a short amount of time. Analysis of
+   these performance problems and results from a prototype
+   implementation are available [26] [30]. Implementation experience and
+   measurements of actual HTTP/1.1 (RFC 2068) implementations show good
+   results [39]. Alternatives have also been explored, for example,
+   T/TCP [27].
+
+   Persistent HTTP connections have a number of advantages:
+
+      - By opening and closing fewer TCP connections, CPU time is saved
+        in routers and hosts (clients, servers, proxies, gateways,
+        tunnels, or caches), and memory used for TCP protocol control
+        blocks can be saved in hosts.
+
+      - HTTP requests and responses can be pipelined on a connection.
+        Pipelining allows a client to make multiple requests without
+        waiting for each response, allowing a single TCP connection to
+        be used much more efficiently, with much lower elapsed time.
+
+      - Network congestion is reduced by reducing the number of packets
+        caused by TCP opens, and by allowing TCP sufficient time to
+        determine the congestion state of the network.
+
+      - Latency on subsequent requests is reduced since there is no time
+        spent in TCP's connection opening handshake.
+
+      - HTTP can evolve more gracefully, since errors can be reported
+        without the penalty of closing the TCP connection. Clients using
+        future versions of HTTP might optimistically try a new feature,
+        but if communicating with an older server, retry with old
+        semantics after an error is reported.
+
+   HTTP implementations SHOULD implement persistent connections.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 44]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.1.2 Overall Operation
+
+   A significant difference between HTTP/1.1 and earlier versions of
+   HTTP is that persistent connections are the default behavior of any
+   HTTP connection. That is, unless otherwise indicated, the client
+   SHOULD assume that the server will maintain a persistent connection,
+   even after error responses from the server.
+
+   Persistent connections provide a mechanism by which a client and a
+   server can signal the close of a TCP connection. This signaling takes
+   place using the Connection header field (section 14.10). Once a close
+   has been signaled, the client MUST NOT send any more requests on that
+   connection.
+
+8.1.2.1 Negotiation
+
+   An HTTP/1.1 server MAY assume that a HTTP/1.1 client intends to
+   maintain a persistent connection unless a Connection header including
+   the connection-token "close" was sent in the request. If the server
+   chooses to close the connection immediately after sending the
+   response, it SHOULD send a Connection header including the
+   connection-token close.
+
+   An HTTP/1.1 client MAY expect a connection to remain open, but would
+   decide to keep it open based on whether the response from a server
+   contains a Connection header with the connection-token close. In case
+   the client does not want to maintain a connection for more than that
+   request, it SHOULD send a Connection header including the
+   connection-token close.
+
+   If either the client or the server sends the close token in the
+   Connection header, that request becomes the last one for the
+   connection.
+
+   Clients and servers SHOULD NOT assume that a persistent connection is
+   maintained for HTTP versions less than 1.1 unless it is explicitly
+   signaled. See section 19.6.2 for more information on backward
+   compatibility with HTTP/1.0 clients.
+
+   In order to remain persistent, all messages on the connection MUST
+   have a self-defined message length (i.e., one not defined by closure
+   of the connection), as described in section 4.4.
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 45]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.1.2.2 Pipelining
+
+   A client that supports persistent connections MAY "pipeline" its
+   requests (i.e., send multiple requests without waiting for each
+   response). A server MUST send its responses to those requests in the
+   same order that the requests were received.
+
+   Clients which assume persistent connections and pipeline immediately
+   after connection establishment SHOULD be prepared to retry their
+   connection if the first pipelined attempt fails. If a client does
+   such a retry, it MUST NOT pipeline before it knows the connection is
+   persistent. Clients MUST also be prepared to resend their requests if
+   the server closes the connection before sending all of the
+   corresponding responses.
+
+   Clients SHOULD NOT pipeline requests using non-idempotent methods or
+   non-idempotent sequences of methods (see section 9.1.2). Otherwise, a
+   premature termination of the transport connection could lead to
+   indeterminate results. A client wishing to send a non-idempotent
+   request SHOULD wait to send that request until it has received the
+   response status for the previous request.
+
+8.1.3 Proxy Servers
+
+   It is especially important that proxies correctly implement the
+   properties of the Connection header field as specified in section
+   14.10.
+
+   The proxy server MUST signal persistent connections separately with
+   its clients and the origin servers (or other proxy servers) that it
+   connects to. Each persistent connection applies to only one transport
+   link.
+
+   A proxy server MUST NOT establish a HTTP/1.1 persistent connection
+   with an HTTP/1.0 client (but see RFC 2068 [33] for information and
+   discussion of the problems with the Keep-Alive header implemented by
+   many HTTP/1.0 clients).
+
+8.1.4 Practical Considerations
+
+   Servers will usually have some time-out value beyond which they will
+   no longer maintain an inactive connection. Proxy servers might make
+   this a higher value since it is likely that the client will be making
+   more connections through the same server. The use of persistent
+   connections places no requirements on the length (or existence) of
+   this time-out for either the client or the server.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 46]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   When a client or server wishes to time-out it SHOULD issue a graceful
+   close on the transport connection. Clients and servers SHOULD both
+   constantly watch for the other side of the transport close, and
+   respond to it as appropriate. If a client or server does not detect
+   the other side's close promptly it could cause unnecessary resource
+   drain on the network.
+
+   A client, server, or proxy MAY close the transport connection at any
+   time. For example, a client might have started to send a new request
+   at the same time that the server has decided to close the "idle"
+   connection. From the server's point of view, the connection is being
+   closed while it was idle, but from the client's point of view, a
+   request is in progress.
+
+   This means that clients, servers, and proxies MUST be able to recover
+   from asynchronous close events. Client software SHOULD reopen the
+   transport connection and retransmit the aborted sequence of requests
+   without user interaction so long as the request sequence is
+   idempotent (see section 9.1.2). Non-idempotent methods or sequences
+   MUST NOT be automatically retried, although user agents MAY offer a
+   human operator the choice of retrying the request(s). Confirmation by
+   user-agent software with semantic understanding of the application
+   MAY substitute for user confirmation. The automatic retry SHOULD NOT
+   be repeated if the second sequence of requests fails.
+
+   Servers SHOULD always respond to at least one request per connection,
+   if at all possible. Servers SHOULD NOT close a connection in the
+   middle of transmitting a response, unless a network or client failure
+   is suspected.
+
+   Clients that use persistent connections SHOULD limit the number of
+   simultaneous connections that they maintain to a given server. A
+   single-user client SHOULD NOT maintain more than 2 connections with
+   any server or proxy. A proxy SHOULD use up to 2*N connections to
+   another server or proxy, where N is the number of simultaneously
+   active users. These guidelines are intended to improve HTTP response
+   times and avoid congestion.
+
+8.2 Message Transmission Requirements
+
+8.2.1 Persistent Connections and Flow Control
+
+   HTTP/1.1 servers SHOULD maintain persistent connections and use TCP's
+   flow control mechanisms to resolve temporary overloads, rather than
+   terminating connections with the expectation that clients will retry.
+   The latter technique can exacerbate network congestion.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 47]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+8.2.2 Monitoring Connections for Error Status Messages
+
+   An HTTP/1.1 (or later) client sending a message-body SHOULD monitor
+   the network connection for an error status while it is transmitting
+   the request. If the client sees an error status, it SHOULD
+   immediately cease transmitting the body. If the body is being sent
+   using a "chunked" encoding (section 3.6), a zero length chunk and
+   empty trailer MAY be used to prematurely mark the end of the message.
+   If the body was preceded by a Content-Length header, the client MUST
+   close the connection.
+
+8.2.3 Use of the 100 (Continue) Status
+
+   The purpose of the 100 (Continue) status (see section 10.1.1) is to
+   allow a client that is sending a request message with a request body
+   to determine if the origin server is willing to accept the request
+   (based on the request headers) before the client sends the request
+   body. In some cases, it might either be inappropriate or highly
+   inefficient for the client to send the body if the server will reject
+   the message without looking at the body.
+
+   Requirements for HTTP/1.1 clients:
+
+      - If a client will wait for a 100 (Continue) response before
+        sending the request body, it MUST send an Expect request-header
+        field (section 14.20) with the "100-continue" expectation.
+
+      - A client MUST NOT send an Expect request-header field (section
+        14.20) with the "100-continue" expectation if it does not intend
+        to send a request body.
+
+   Because of the presence of older implementations, the protocol allows
+   ambiguous situations in which a client may send "Expect: 100-
+   continue" without receiving either a 417 (Expectation Failed) status
+   or a 100 (Continue) status. Therefore, when a client sends this
+   header field to an origin server (possibly via a proxy) from which it
+   has never seen a 100 (Continue) status, the client SHOULD NOT wait
+   for an indefinite period before sending the request body.
+
+   Requirements for HTTP/1.1 origin servers:
+
+      - Upon receiving a request which includes an Expect request-header
+        field with the "100-continue" expectation, an origin server MUST
+        either respond with 100 (Continue) status and continue to read
+        from the input stream, or respond with a final status code. The
+        origin server MUST NOT wait for the request body before sending
+        the 100 (Continue) response. If it responds with a final status
+        code, it MAY close the transport connection or it MAY continue
+
+
+
+Fielding, et al.            Standards Track                    [Page 48]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+        to read and discard the rest of the request.  It MUST NOT
+        perform the requested method if it returns a final status code.
+
+      - An origin server SHOULD NOT send a 100 (Continue) response if
+        the request message does not include an Expect request-header
+        field with the "100-continue" expectation, and MUST NOT send a
+        100 (Continue) response if such a request comes from an HTTP/1.0
+        (or earlier) client. There is an exception to this rule: for
+        compatibility with RFC 2068, a server MAY send a 100 (Continue)
+        status in response to an HTTP/1.1 PUT or POST request that does
+        not include an Expect request-header field with the "100-
+        continue" expectation. This exception, the purpose of which is
+        to minimize any client processing delays associated with an
+        undeclared wait for 100 (Continue) status, applies only to
+        HTTP/1.1 requests, and not to requests with any other HTTP-
+        version value.
+
+      - An origin server MAY omit a 100 (Continue) response if it has
+        already received some or all of the request body for the
+        corresponding request.
+
+      - An origin server that sends a 100 (Continue) response MUST
+        ultimately send a final status code, once the request body is
+        received and processed, unless it terminates the transport
+        connection prematurely.
+
+      - If an origin server receives a request that does not include an
+        Expect request-header field with the "100-continue" expectation,
+        the request includes a request body, and the server responds
+        with a final status code before reading the entire request body
+        from the transport connection, then the server SHOULD NOT close
+        the transport connection until it has read the entire request,
+        or until the client closes the connection. Otherwise, the client
+        might not reliably receive the response message. However, this
+        requirement is not be construed as preventing a server from
+        defending itself against denial-of-service attacks, or from
+        badly broken client implementations.
+
+   Requirements for HTTP/1.1 proxies:
+
+      - If a proxy receives a request that includes an Expect request-
+        header field with the "100-continue" expectation, and the proxy
+        either knows that the next-hop server complies with HTTP/1.1 or
+        higher, or does not know the HTTP version of the next-hop
+        server, it MUST forward the request, including the Expect header
+        field.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 49]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - If the proxy knows that the version of the next-hop server is
+        HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST
+        respond with a 417 (Expectation Failed) status.
+
+      - Proxies SHOULD maintain a cache recording the HTTP version
+        numbers received from recently-referenced next-hop servers.
+
+      - A proxy MUST NOT forward a 100 (Continue) response if the
+        request message was received from an HTTP/1.0 (or earlier)
+        client and did not include an Expect request-header field with
+        the "100-continue" expectation. This requirement overrides the
+        general rule for forwarding of 1xx responses (see section 10.1).
+
+8.2.4 Client Behavior if Server Prematurely Closes Connection
+
+   If an HTTP/1.1 client sends a request which includes a request body,
+   but which does not include an Expect request-header field with the
+   "100-continue" expectation, and if the client is not directly
+   connected to an HTTP/1.1 origin server, and if the client sees the
+   connection close before receiving any status from the server, the
+   client SHOULD retry the request.  If the client does retry this
+   request, it MAY use the following "binary exponential backoff"
+   algorithm to be assured of obtaining a reliable response:
+
+      1. Initiate a new connection to the server
+
+      2. Transmit the request-headers
+
+      3. Initialize a variable R to the estimated round-trip time to the
+         server (e.g., based on the time it took to establish the
+         connection), or to a constant value of 5 seconds if the round-
+         trip time is not available.
+
+      4. Compute T = R * (2**N), where N is the number of previous
+         retries of this request.
+
+      5. Wait either for an error response from the server, or for T
+         seconds (whichever comes first)
+
+      6. If no error response is received, after T seconds transmit the
+         body of the request.
+
+      7. If client sees that the connection is closed prematurely,
+         repeat from step 1 until the request is accepted, an error
+         response is received, or the user becomes impatient and
+         terminates the retry process.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 50]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If at any point an error status is received, the client
+
+      - SHOULD NOT continue and
+
+      - SHOULD close the connection if it has not completed sending the
+        request message.
+
+9 Method Definitions
+
+   The set of common methods for HTTP/1.1 is defined below. Although
+   this set can be expanded, additional methods cannot be assumed to
+   share the same semantics for separately extended clients and servers.
+
+   The Host request-header field (section 14.23) MUST accompany all
+   HTTP/1.1 requests.
+
+9.1 Safe and Idempotent Methods
+
+9.1.1 Safe Methods
+
+   Implementors should be aware that the software represents the user in
+   their interactions over the Internet, and should be careful to allow
+   the user to be aware of any actions they might take which may have an
+   unexpected significance to themselves or others.
+
+   In particular, the convention has been established that the GET and
+   HEAD methods SHOULD NOT have the significance of taking an action
+   other than retrieval. These methods ought to be considered "safe".
+   This allows user agents to represent other methods, such as POST, PUT
+   and DELETE, in a special way, so that the user is made aware of the
+   fact that a possibly unsafe action is being requested.
+
+   Naturally, it is not possible to ensure that the server does not
+   generate side-effects as a result of performing a GET request; in
+   fact, some dynamic resources consider that a feature. The important
+   distinction here is that the user did not request the side-effects,
+   so therefore cannot be held accountable for them.
+
+9.1.2 Idempotent Methods
+
+   Methods can also have the property of "idempotence" in that (aside
+   from error or expiration issues) the side-effects of N > 0 identical
+   requests is the same as for a single request. The methods GET, HEAD,
+   PUT and DELETE share this property. Also, the methods OPTIONS and
+   TRACE SHOULD NOT have side effects, and so are inherently idempotent.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 51]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   However, it is possible that a sequence of several requests is non-
+   idempotent, even if all of the methods executed in that sequence are
+   idempotent. (A sequence is idempotent if a single execution of the
+   entire sequence always yields a result that is not changed by a
+   reexecution of all, or part, of that sequence.) For example, a
+   sequence is non-idempotent if its result depends on a value that is
+   later modified in the same sequence.
+
+   A sequence that never has side effects is idempotent, by definition
+   (provided that no concurrent operations are being executed on the
+   same set of resources).
+
+9.2 OPTIONS
+
+   The OPTIONS method represents a request for information about the
+   communication options available on the request/response chain
+   identified by the Request-URI. This method allows the client to
+   determine the options and/or requirements associated with a resource,
+   or the capabilities of a server, without implying a resource action
+   or initiating a resource retrieval.
+
+   Responses to this method are not cacheable.
+
+   If the OPTIONS request includes an entity-body (as indicated by the
+   presence of Content-Length or Transfer-Encoding), then the media type
+   MUST be indicated by a Content-Type field. Although this
+   specification does not define any use for such a body, future
+   extensions to HTTP might use the OPTIONS body to make more detailed
+   queries on the server. A server that does not support such an
+   extension MAY discard the request body.
+
+   If the Request-URI is an asterisk ("*"), the OPTIONS request is
+   intended to apply to the server in general rather than to a specific
+   resource. Since a server's communication options typically depend on
+   the resource, the "*" request is only useful as a "ping" or "no-op"
+   type of method; it does nothing beyond allowing the client to test
+   the capabilities of the server. For example, this can be used to test
+   a proxy for HTTP/1.1 compliance (or lack thereof).
+
+   If the Request-URI is not an asterisk, the OPTIONS request applies
+   only to the options that are available when communicating with that
+   resource.
+
+   A 200 response SHOULD include any header fields that indicate
+   optional features implemented by the server and applicable to that
+   resource (e.g., Allow), possibly including extensions not defined by
+   this specification. The response body, if any, SHOULD also include
+   information about the communication options. The format for such a
+
+
+
+Fielding, et al.            Standards Track                    [Page 52]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   body is not defined by this specification, but might be defined by
+   future extensions to HTTP. Content negotiation MAY be used to select
+   the appropriate response format. If no response body is included, the
+   response MUST include a Content-Length field with a field-value of
+   "0".
+
+   The Max-Forwards request-header field MAY be used to target a
+   specific proxy in the request chain. When a proxy receives an OPTIONS
+   request on an absoluteURI for which request forwarding is permitted,
+   the proxy MUST check for a Max-Forwards field. If the Max-Forwards
+   field-value is zero ("0"), the proxy MUST NOT forward the message;
+   instead, the proxy SHOULD respond with its own communication options.
+   If the Max-Forwards field-value is an integer greater than zero, the
+   proxy MUST decrement the field-value when it forwards the request. If
+   no Max-Forwards field is present in the request, then the forwarded
+   request MUST NOT include a Max-Forwards field.
+
+9.3 GET
+
+   The GET method means retrieve whatever information (in the form of an
+   entity) is identified by the Request-URI. If the Request-URI refers
+   to a data-producing process, it is the produced data which shall be
+   returned as the entity in the response and not the source text of the
+   process, unless that text happens to be the output of the process.
+
+   The semantics of the GET method change to a "conditional GET" if the
+   request message includes an If-Modified-Since, If-Unmodified-Since,
+   If-Match, If-None-Match, or If-Range header field. A conditional GET
+   method requests that the entity be transferred only under the
+   circumstances described by the conditional header field(s). The
+   conditional GET method is intended to reduce unnecessary network
+   usage by allowing cached entities to be refreshed without requiring
+   multiple requests or transferring data already held by the client.
+
+   The semantics of the GET method change to a "partial GET" if the
+   request message includes a Range header field. A partial GET requests
+   that only part of the entity be transferred, as described in section
+   14.35. The partial GET method is intended to reduce unnecessary
+   network usage by allowing partially-retrieved entities to be
+   completed without transferring data already held by the client.
+
+   The response to a GET request is cacheable if and only if it meets
+   the requirements for HTTP caching described in section 13.
+
+   See section 15.1.3 for security considerations when used for forms.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 53]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+9.4 HEAD
+
+   The HEAD method is identical to GET except that the server MUST NOT
+   return a message-body in the response. The metainformation contained
+   in the HTTP headers in response to a HEAD request SHOULD be identical
+   to the information sent in response to a GET request. This method can
+   be used for obtaining metainformation about the entity implied by the
+   request without transferring the entity-body itself. This method is
+   often used for testing hypertext links for validity, accessibility,
+   and recent modification.
+
+   The response to a HEAD request MAY be cacheable in the sense that the
+   information contained in the response MAY be used to update a
+   previously cached entity from that resource. If the new field values
+   indicate that the cached entity differs from the current entity (as
+   would be indicated by a change in Content-Length, Content-MD5, ETag
+   or Last-Modified), then the cache MUST treat the cache entry as
+   stale.
+
+9.5 POST
+
+   The POST method is used to request that the origin server accept the
+   entity enclosed in the request as a new subordinate of the resource
+   identified by the Request-URI in the Request-Line. POST is designed
+   to allow a uniform method to cover the following functions:
+
+      - Annotation of existing resources;
+
+      - Posting a message to a bulletin board, newsgroup, mailing list,
+        or similar group of articles;
+
+      - Providing a block of data, such as the result of submitting a
+        form, to a data-handling process;
+
+      - Extending a database through an append operation.
+
+   The actual function performed by the POST method is determined by the
+   server and is usually dependent on the Request-URI. The posted entity
+   is subordinate to that URI in the same way that a file is subordinate
+   to a directory containing it, a news article is subordinate to a
+   newsgroup to which it is posted, or a record is subordinate to a
+   database.
+
+   The action performed by the POST method might not result in a
+   resource that can be identified by a URI. In this case, either 200
+   (OK) or 204 (No Content) is the appropriate response status,
+   depending on whether or not the response includes an entity that
+   describes the result.
+
+
+
+Fielding, et al.            Standards Track                    [Page 54]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If a resource has been created on the origin server, the response
+   SHOULD be 201 (Created) and contain an entity which describes the
+   status of the request and refers to the new resource, and a Location
+   header (see section 14.30).
+
+   Responses to this method are not cacheable, unless the response
+   includes appropriate Cache-Control or Expires header fields. However,
+   the 303 (See Other) response can be used to direct the user agent to
+   retrieve a cacheable resource.
+
+   POST requests MUST obey the message transmission requirements set out
+   in section 8.2.
+
+   See section 15.1.3 for security considerations.
+
+9.6 PUT
+
+   The PUT method requests that the enclosed entity be stored under the
+   supplied Request-URI. If the Request-URI refers to an already
+   existing resource, the enclosed entity SHOULD be considered as a
+   modified version of the one residing on the origin server. If the
+   Request-URI does not point to an existing resource, and that URI is
+   capable of being defined as a new resource by the requesting user
+   agent, the origin server can create the resource with that URI. If a
+   new resource is created, the origin server MUST inform the user agent
+   via the 201 (Created) response. If an existing resource is modified,
+   either the 200 (OK) or 204 (No Content) response codes SHOULD be sent
+   to indicate successful completion of the request. If the resource
+   could not be created or modified with the Request-URI, an appropriate
+   error response SHOULD be given that reflects the nature of the
+   problem. The recipient of the entity MUST NOT ignore any Content-*
+   (e.g. Content-Range) headers that it does not understand or implement
+   and MUST return a 501 (Not Implemented) response in such cases.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries SHOULD be
+   treated as stale. Responses to this method are not cacheable.
+
+   The fundamental difference between the POST and PUT requests is
+   reflected in the different meaning of the Request-URI. The URI in a
+   POST request identifies the resource that will handle the enclosed
+   entity. That resource might be a data-accepting process, a gateway to
+   some other protocol, or a separate entity that accepts annotations.
+   In contrast, the URI in a PUT request identifies the entity enclosed
+   with the request -- the user agent knows what URI is intended and the
+   server MUST NOT attempt to apply the request to some other resource.
+   If the server desires that the request be applied to a different URI,
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 55]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   it MUST send a 301 (Moved Permanently) response; the user agent MAY
+   then make its own decision regarding whether or not to redirect the
+   request.
+
+   A single resource MAY be identified by many different URIs. For
+   example, an article might have a URI for identifying "the current
+   version" which is separate from the URI identifying each particular
+   version. In this case, a PUT request on a general URI might result in
+   several other URIs being defined by the origin server.
+
+   HTTP/1.1 does not define how a PUT method affects the state of an
+   origin server.
+
+   PUT requests MUST obey the message transmission requirements set out
+   in section 8.2.
+
+   Unless otherwise specified for a particular entity-header, the
+   entity-headers in the PUT request SHOULD be applied to the resource
+   created or modified by the PUT.
+
+9.7 DELETE
+
+   The DELETE method requests that the origin server delete the resource
+   identified by the Request-URI. This method MAY be overridden by human
+   intervention (or other means) on the origin server. The client cannot
+   be guaranteed that the operation has been carried out, even if the
+   status code returned from the origin server indicates that the action
+   has been completed successfully. However, the server SHOULD NOT
+   indicate success unless, at the time the response is given, it
+   intends to delete the resource or move it to an inaccessible
+   location.
+
+   A successful response SHOULD be 200 (OK) if the response includes an
+   entity describing the status, 202 (Accepted) if the action has not
+   yet been enacted, or 204 (No Content) if the action has been enacted
+   but the response does not include an entity.
+
+   If the request passes through a cache and the Request-URI identifies
+   one or more currently cached entities, those entries SHOULD be
+   treated as stale. Responses to this method are not cacheable.
+
+9.8 TRACE
+
+   The TRACE method is used to invoke a remote, application-layer loop-
+   back of the request message. The final recipient of the request
+   SHOULD reflect the message received back to the client as the
+   entity-body of a 200 (OK) response. The final recipient is either the
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 56]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   origin server or the first proxy or gateway to receive a Max-Forwards
+   value of zero (0) in the request (see section 14.31). A TRACE request
+   MUST NOT include an entity.
+
+   TRACE allows the client to see what is being received at the other
+   end of the request chain and use that data for testing or diagnostic
+   information. The value of the Via header field (section 14.45) is of
+   particular interest, since it acts as a trace of the request chain.
+   Use of the Max-Forwards header field allows the client to limit the
+   length of the request chain, which is useful for testing a chain of
+   proxies forwarding messages in an infinite loop.
+
+   If the request is valid, the response SHOULD contain the entire
+   request message in the entity-body, with a Content-Type of
+   "message/http". Responses to this method MUST NOT be cached.
+
+9.9 CONNECT
+
+   This specification reserves the method name CONNECT for use with a
+   proxy that can dynamically switch to being a tunnel (e.g. SSL
+   tunneling [44]).
+
+10 Status Code Definitions
+
+   Each Status-Code is described below, including a description of which
+   method(s) it can follow and any metainformation required in the
+   response.
+
+10.1 Informational 1xx
+
+   This class of status code indicates a provisional response,
+   consisting only of the Status-Line and optional headers, and is
+   terminated by an empty line. There are no required headers for this
+   class of status code. Since HTTP/1.0 did not define any 1xx status
+   codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
+   except under experimental conditions.
+
+   A client MUST be prepared to accept one or more 1xx status responses
+   prior to a regular response, even if the client does not expect a 100
+   (Continue) status message. Unexpected 1xx status responses MAY be
+   ignored by a user agent.
+
+   Proxies MUST forward 1xx responses, unless the connection between the
+   proxy and its client has been closed, or unless the proxy itself
+   requested the generation of the 1xx response. (For example, if a
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 57]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   proxy adds a "Expect: 100-continue" field when it forwards a request,
+   then it need not forward the corresponding 100 (Continue)
+   response(s).)
+
+10.1.1 100 Continue
+
+   The client SHOULD continue with its request. This interim response is
+   used to inform the client that the initial part of the request has
+   been received and has not yet been rejected by the server. The client
+   SHOULD continue by sending the remainder of the request or, if the
+   request has already been completed, ignore this response. The server
+   MUST send a final response after the request has been completed. See
+   section 8.2.3 for detailed discussion of the use and handling of this
+   status code.
+
+10.1.2 101 Switching Protocols
+
+   The server understands and is willing to comply with the client's
+   request, via the Upgrade message header field (section 14.42), for a
+   change in the application protocol being used on this connection. The
+   server will switch protocols to those defined by the response's
+   Upgrade header field immediately after the empty line which
+   terminates the 101 response.
+
+   The protocol SHOULD be switched only when it is advantageous to do
+   so. For example, switching to a newer version of HTTP is advantageous
+   over older versions, and switching to a real-time, synchronous
+   protocol might be advantageous when delivering resources that use
+   such features.
+
+10.2 Successful 2xx
+
+   This class of status code indicates that the client's request was
+   successfully received, understood, and accepted.
+
+10.2.1 200 OK
+
+   The request has succeeded. The information returned with the response
+   is dependent on the method used in the request, for example:
+
+   GET    an entity corresponding to the requested resource is sent in
+          the response;
+
+   HEAD   the entity-header fields corresponding to the requested
+          resource are sent in the response without any message-body;
+
+   POST   an entity describing or containing the result of the action;
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 58]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   TRACE  an entity containing the request message as received by the
+          end server.
+
+10.2.2 201 Created
+
+   The request has been fulfilled and resulted in a new resource being
+   created. The newly created resource can be referenced by the URI(s)
+   returned in the entity of the response, with the most specific URI
+   for the resource given by a Location header field. The response
+   SHOULD include an entity containing a list of resource
+   characteristics and location(s) from which the user or user agent can
+   choose the one most appropriate. The entity format is specified by
+   the media type given in the Content-Type header field. The origin
+   server MUST create the resource before returning the 201 status code.
+   If the action cannot be carried out immediately, the server SHOULD
+   respond with 202 (Accepted) response instead.
+
+   A 201 response MAY contain an ETag response header field indicating
+   the current value of the entity tag for the requested variant just
+   created, see section 14.19.
+
+10.2.3 202 Accepted
+
+   The request has been accepted for processing, but the processing has
+   not been completed.  The request might or might not eventually be
+   acted upon, as it might be disallowed when processing actually takes
+   place. There is no facility for re-sending a status code from an
+   asynchronous operation such as this.
+
+   The 202 response is intentionally non-committal. Its purpose is to
+   allow a server to accept a request for some other process (perhaps a
+   batch-oriented process that is only run once per day) without
+   requiring that the user agent's connection to the server persist
+   until the process is completed. The entity returned with this
+   response SHOULD include an indication of the request's current status
+   and either a pointer to a status monitor or some estimate of when the
+   user can expect the request to be fulfilled.
+
+10.2.4 203 Non-Authoritative Information
+
+   The returned metainformation in the entity-header is not the
+   definitive set as available from the origin server, but is gathered
+   from a local or a third-party copy. The set presented MAY be a subset
+   or superset of the original version. For example, including local
+   annotation information about the resource might result in a superset
+   of the metainformation known by the origin server. Use of this
+   response code is not required and is only appropriate when the
+   response would otherwise be 200 (OK).
+
+
+
+Fielding, et al.            Standards Track                    [Page 59]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.2.5 204 No Content
+
+   The server has fulfilled the request but does not need to return an
+   entity-body, and might want to return updated metainformation. The
+   response MAY include new or updated metainformation in the form of
+   entity-headers, which if present SHOULD be associated with the
+   requested variant.
+
+   If the client is a user agent, it SHOULD NOT change its document view
+   from that which caused the request to be sent. This response is
+   primarily intended to allow input for actions to take place without
+   causing a change to the user agent's active document view, although
+   any new or updated metainformation SHOULD be applied to the document
+   currently in the user agent's active view.
+
+   The 204 response MUST NOT include a message-body, and thus is always
+   terminated by the first empty line after the header fields.
+
+10.2.6 205 Reset Content
+
+   The server has fulfilled the request and the user agent SHOULD reset
+   the document view which caused the request to be sent. This response
+   is primarily intended to allow input for actions to take place via
+   user input, followed by a clearing of the form in which the input is
+   given so that the user can easily initiate another input action. The
+   response MUST NOT include an entity.
+
+10.2.7 206 Partial Content
+
+   The server has fulfilled the partial GET request for the resource.
+   The request MUST have included a Range header field (section 14.35)
+   indicating the desired range, and MAY have included an If-Range
+   header field (section 14.27) to make the request conditional.
+
+   The response MUST include the following header fields:
+
+      - Either a Content-Range header field (section 14.16) indicating
+        the range included with this response, or a multipart/byteranges
+        Content-Type including Content-Range fields for each part. If a
+        Content-Length header field is present in the response, its
+        value MUST match the actual number of OCTETs transmitted in the
+        message-body.
+
+      - Date
+
+      - ETag and/or Content-Location, if the header would have been sent
+        in a 200 response to the same request
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 60]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - Expires, Cache-Control, and/or Vary, if the field-value might
+        differ from that sent in any previous response for the same
+        variant
+
+   If the 206 response is the result of an If-Range request that used a
+   strong cache validator (see section 13.3.3), the response SHOULD NOT
+   include other entity-headers. If the response is the result of an
+   If-Range request that used a weak validator, the response MUST NOT
+   include other entity-headers; this prevents inconsistencies between
+   cached entity-bodies and updated headers. Otherwise, the response
+   MUST include all of the entity-headers that would have been returned
+   with a 200 (OK) response to the same request.
+
+   A cache MUST NOT combine a 206 response with other previously cached
+   content if the ETag or Last-Modified headers do not match exactly,
+   see 13.5.4.
+
+   A cache that does not support the Range and Content-Range headers
+   MUST NOT cache 206 (Partial) responses.
+
+10.3 Redirection 3xx
+
+   This class of status code indicates that further action needs to be
+   taken by the user agent in order to fulfill the request.  The action
+   required MAY be carried out by the user agent without interaction
+   with the user if and only if the method used in the second request is
+   GET or HEAD. A client SHOULD detect infinite redirection loops, since
+   such loops generate network traffic for each redirection.
+
+      Note: previous versions of this specification recommended a
+      maximum of five redirections. Content developers should be aware
+      that there might be clients that implement such a fixed
+      limitation.
+
+10.3.1 300 Multiple Choices
+
+   The requested resource corresponds to any one of a set of
+   representations, each with its own specific location, and agent-
+   driven negotiation information (section 12) is being provided so that
+   the user (or user agent) can select a preferred representation and
+   redirect its request to that location.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of resource characteristics and location(s) from
+   which the user or user agent can choose the one most appropriate. The
+   entity format is specified by the media type given in the Content-
+   Type header field. Depending upon the format and the capabilities of
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 61]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the user agent, selection of the most appropriate choice MAY be
+   performed automatically. However, this specification does not define
+   any standard for such automatic selection.
+
+   If the server has a preferred choice of representation, it SHOULD
+   include the specific URI for that representation in the Location
+   field; user agents MAY use the Location field value for automatic
+   redirection. This response is cacheable unless indicated otherwise.
+
+10.3.2 301 Moved Permanently
+
+   The requested resource has been assigned a new permanent URI and any
+   future references to this resource SHOULD use one of the returned
+   URIs.  Clients with link editing capabilities ought to automatically
+   re-link references to the Request-URI to one or more of the new
+   references returned by the server, where possible. This response is
+   cacheable unless indicated otherwise.
+
+   The new permanent URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+   If the 301 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+      Note: When automatically redirecting a POST request after
+      receiving a 301 status code, some existing HTTP/1.0 user agents
+      will erroneously change it into a GET request.
+
+10.3.3 302 Found
+
+   The requested resource resides temporarily under a different URI.
+   Since the redirection might be altered on occasion, the client SHOULD
+   continue to use the Request-URI for future requests.  This response
+   is only cacheable if indicated by a Cache-Control or Expires header
+   field.
+
+   The temporary URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 62]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the 302 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+      Note: RFC 1945 and RFC 2068 specify that the client is not allowed
+      to change the method on the redirected request.  However, most
+      existing user agent implementations treat 302 as if it were a 303
+      response, performing a GET on the Location field-value regardless
+      of the original request method. The status codes 303 and 307 have
+      been added for servers that wish to make unambiguously clear which
+      kind of reaction is expected of the client.
+
+10.3.4 303 See Other
+
+   The response to the request can be found under a different URI and
+   SHOULD be retrieved using a GET method on that resource. This method
+   exists primarily to allow the output of a POST-activated script to
+   redirect the user agent to a selected resource. The new URI is not a
+   substitute reference for the originally requested resource. The 303
+   response MUST NOT be cached, but the response to the second
+   (redirected) request might be cacheable.
+
+   The different URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s).
+
+      Note: Many pre-HTTP/1.1 user agents do not understand the 303
+      status. When interoperability with such clients is a concern, the
+      302 status code may be used instead, since most user agents react
+      to a 302 response as described here for 303.
+
+10.3.5 304 Not Modified
+
+   If the client has performed a conditional GET request and access is
+   allowed, but the document has not been modified, the server SHOULD
+   respond with this status code. The 304 response MUST NOT contain a
+   message-body, and thus is always terminated by the first empty line
+   after the header fields.
+
+   The response MUST include the following header fields:
+
+      - Date, unless its omission is required by section 14.18.1
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 63]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If a clockless origin server obeys these rules, and proxies and
+   clients add their own Date to any response received without one (as
+   already specified by [RFC 2068], section 14.19), caches will operate
+   correctly.
+
+      - ETag and/or Content-Location, if the header would have been sent
+        in a 200 response to the same request
+
+      - Expires, Cache-Control, and/or Vary, if the field-value might
+        differ from that sent in any previous response for the same
+        variant
+
+   If the conditional GET used a strong cache validator (see section
+   13.3.3), the response SHOULD NOT include other entity-headers.
+   Otherwise (i.e., the conditional GET used a weak validator), the
+   response MUST NOT include other entity-headers; this prevents
+   inconsistencies between cached entity-bodies and updated headers.
+
+   If a 304 response indicates an entity not currently cached, then the
+   cache MUST disregard the response and repeat the request without the
+   conditional.
+
+   If a cache uses a received 304 response to update a cache entry, the
+   cache MUST update the entry to reflect any new field values given in
+   the response.
+
+10.3.6 305 Use Proxy
+
+   The requested resource MUST be accessed through the proxy given by
+   the Location field. The Location field gives the URI of the proxy.
+   The recipient is expected to repeat this single request via the
+   proxy. 305 responses MUST only be generated by origin servers.
+
+      Note: RFC 2068 was not clear that 305 was intended to redirect a
+      single request, and to be generated by origin servers only.  Not
+      observing these limitations has significant security consequences.
+
+10.3.7 306 (Unused)
+
+   The 306 status code was used in a previous version of the
+   specification, is no longer used, and the code is reserved.
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 64]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.3.8 307 Temporary Redirect
+
+   The requested resource resides temporarily under a different URI.
+   Since the redirection MAY be altered on occasion, the client SHOULD
+   continue to use the Request-URI for future requests.  This response
+   is only cacheable if indicated by a Cache-Control or Expires header
+   field.
+
+   The temporary URI SHOULD be given by the Location field in the
+   response. Unless the request method was HEAD, the entity of the
+   response SHOULD contain a short hypertext note with a hyperlink to
+   the new URI(s) , since many pre-HTTP/1.1 user agents do not
+   understand the 307 status. Therefore, the note SHOULD contain the
+   information necessary for a user to repeat the original request on
+   the new URI.
+
+   If the 307 status code is received in response to a request other
+   than GET or HEAD, the user agent MUST NOT automatically redirect the
+   request unless it can be confirmed by the user, since this might
+   change the conditions under which the request was issued.
+
+10.4 Client Error 4xx
+
+   The 4xx class of status code is intended for cases in which the
+   client seems to have erred. Except when responding to a HEAD request,
+   the server SHOULD include an entity containing an explanation of the
+   error situation, and whether it is a temporary or permanent
+   condition. These status codes are applicable to any request method.
+   User agents SHOULD display any included entity to the user.
+
+   If the client is sending data, a server implementation using TCP
+   SHOULD be careful to ensure that the client acknowledges receipt of
+   the packet(s) containing the response, before the server closes the
+   input connection. If the client continues sending data to the server
+   after the close, the server's TCP stack will send a reset packet to
+   the client, which may erase the client's unacknowledged input buffers
+   before they can be read and interpreted by the HTTP application.
+
+10.4.1 400 Bad Request
+
+   The request could not be understood by the server due to malformed
+   syntax. The client SHOULD NOT repeat the request without
+   modifications.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 65]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.2 401 Unauthorized
+
+   The request requires user authentication. The response MUST include a
+   WWW-Authenticate header field (section 14.47) containing a challenge
+   applicable to the requested resource. The client MAY repeat the
+   request with a suitable Authorization header field (section 14.8). If
+   the request already included Authorization credentials, then the 401
+   response indicates that authorization has been refused for those
+   credentials. If the 401 response contains the same challenge as the
+   prior response, and the user agent has already attempted
+   authentication at least once, then the user SHOULD be presented the
+   entity that was given in the response, since that entity might
+   include relevant diagnostic information. HTTP access authentication
+   is explained in "HTTP Authentication: Basic and Digest Access
+   Authentication" [43].
+
+10.4.3 402 Payment Required
+
+   This code is reserved for future use.
+
+10.4.4 403 Forbidden
+
+   The server understood the request, but is refusing to fulfill it.
+   Authorization will not help and the request SHOULD NOT be repeated.
+   If the request method was not HEAD and the server wishes to make
+   public why the request has not been fulfilled, it SHOULD describe the
+   reason for the refusal in the entity.  If the server does not wish to
+   make this information available to the client, the status code 404
+   (Not Found) can be used instead.
+
+10.4.5 404 Not Found
+
+   The server has not found anything matching the Request-URI. No
+   indication is given of whether the condition is temporary or
+   permanent. The 410 (Gone) status code SHOULD be used if the server
+   knows, through some internally configurable mechanism, that an old
+   resource is permanently unavailable and has no forwarding address.
+   This status code is commonly used when the server does not wish to
+   reveal exactly why the request has been refused, or when no other
+   response is applicable.
+
+10.4.6 405 Method Not Allowed
+
+   The method specified in the Request-Line is not allowed for the
+   resource identified by the Request-URI. The response MUST include an
+   Allow header containing a list of valid methods for the requested
+   resource.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 66]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.7 406 Not Acceptable
+
+   The resource identified by the request is only capable of generating
+   response entities which have content characteristics not acceptable
+   according to the accept headers sent in the request.
+
+   Unless it was a HEAD request, the response SHOULD include an entity
+   containing a list of available entity characteristics and location(s)
+   from which the user or user agent can choose the one most
+   appropriate. The entity format is specified by the media type given
+   in the Content-Type header field. Depending upon the format and the
+   capabilities of the user agent, selection of the most appropriate
+   choice MAY be performed automatically. However, this specification
+   does not define any standard for such automatic selection.
+
+      Note: HTTP/1.1 servers are allowed to return responses which are
+      not acceptable according to the accept headers sent in the
+      request. In some cases, this may even be preferable to sending a
+      406 response. User agents are encouraged to inspect the headers of
+      an incoming response to determine if it is acceptable.
+
+   If the response could be unacceptable, a user agent SHOULD
+   temporarily stop receipt of more data and query the user for a
+   decision on further actions.
+
+10.4.8 407 Proxy Authentication Required
+
+   This code is similar to 401 (Unauthorized), but indicates that the
+   client must first authenticate itself with the proxy. The proxy MUST
+   return a Proxy-Authenticate header field (section 14.33) containing a
+   challenge applicable to the proxy for the requested resource. The
+   client MAY repeat the request with a suitable Proxy-Authorization
+   header field (section 14.34). HTTP access authentication is explained
+   in "HTTP Authentication: Basic and Digest Access Authentication"
+   [43].
+
+10.4.9 408 Request Timeout
+
+   The client did not produce a request within the time that the server
+   was prepared to wait. The client MAY repeat the request without
+   modifications at any later time.
+
+10.4.10 409 Conflict
+
+   The request could not be completed due to a conflict with the current
+   state of the resource. This code is only allowed in situations where
+   it is expected that the user might be able to resolve the conflict
+   and resubmit the request. The response body SHOULD include enough
+
+
+
+Fielding, et al.            Standards Track                    [Page 67]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   information for the user to recognize the source of the conflict.
+   Ideally, the response entity would include enough information for the
+   user or user agent to fix the problem; however, that might not be
+   possible and is not required.
+
+   Conflicts are most likely to occur in response to a PUT request. For
+   example, if versioning were being used and the entity being PUT
+   included changes to a resource which conflict with those made by an
+   earlier (third-party) request, the server might use the 409 response
+   to indicate that it can't complete the request. In this case, the
+   response entity would likely contain a list of the differences
+   between the two versions in a format defined by the response
+   Content-Type.
+
+10.4.11 410 Gone
+
+   The requested resource is no longer available at the server and no
+   forwarding address is known. This condition is expected to be
+   considered permanent. Clients with link editing capabilities SHOULD
+   delete references to the Request-URI after user approval. If the
+   server does not know, or has no facility to determine, whether or not
+   the condition is permanent, the status code 404 (Not Found) SHOULD be
+   used instead. This response is cacheable unless indicated otherwise.
+
+   The 410 response is primarily intended to assist the task of web
+   maintenance by notifying the recipient that the resource is
+   intentionally unavailable and that the server owners desire that
+   remote links to that resource be removed. Such an event is common for
+   limited-time, promotional services and for resources belonging to
+   individuals no longer working at the server's site. It is not
+   necessary to mark all permanently unavailable resources as "gone" or
+   to keep the mark for any length of time -- that is left to the
+   discretion of the server owner.
+
+10.4.12 411 Length Required
+
+   The server refuses to accept the request without a defined Content-
+   Length. The client MAY repeat the request if it adds a valid
+   Content-Length header field containing the length of the message-body
+   in the request message.
+
+10.4.13 412 Precondition Failed
+
+   The precondition given in one or more of the request-header fields
+   evaluated to false when it was tested on the server. This response
+   code allows the client to place preconditions on the current resource
+   metainformation (header field data) and thus prevent the requested
+   method from being applied to a resource other than the one intended.
+
+
+
+Fielding, et al.            Standards Track                    [Page 68]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.14 413 Request Entity Too Large
+
+   The server is refusing to process a request because the request
+   entity is larger than the server is willing or able to process. The
+   server MAY close the connection to prevent the client from continuing
+   the request.
+
+   If the condition is temporary, the server SHOULD include a Retry-
+   After header field to indicate that it is temporary and after what
+   time the client MAY try again.
+
+10.4.15 414 Request-URI Too Long
+
+   The server is refusing to service the request because the Request-URI
+   is longer than the server is willing to interpret. This rare
+   condition is only likely to occur when a client has improperly
+   converted a POST request to a GET request with long query
+   information, when the client has descended into a URI "black hole" of
+   redirection (e.g., a redirected URI prefix that points to a suffix of
+   itself), or when the server is under attack by a client attempting to
+   exploit security holes present in some servers using fixed-length
+   buffers for reading or manipulating the Request-URI.
+
+10.4.16 415 Unsupported Media Type
+
+   The server is refusing to service the request because the entity of
+   the request is in a format not supported by the requested resource
+   for the requested method.
+
+10.4.17 416 Requested Range Not Satisfiable
+
+   A server SHOULD return a response with this status code if a request
+   included a Range request-header field (section 14.35), and none of
+   the range-specifier values in this field overlap the current extent
+   of the selected resource, and the request did not include an If-Range
+   request-header field. (For byte-ranges, this means that the first-
+   byte-pos of all of the byte-range-spec values were greater than the
+   current length of the selected resource.)
+
+   When this status code is returned for a byte-range request, the
+   response SHOULD include a Content-Range entity-header field
+   specifying the current length of the selected resource (see section
+   14.16). This response MUST NOT use the multipart/byteranges content-
+   type.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 69]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.4.18 417 Expectation Failed
+
+   The expectation given in an Expect request-header field (see section
+   14.20) could not be met by this server, or, if the server is a proxy,
+   the server has unambiguous evidence that the request could not be met
+   by the next-hop server.
+
+10.5 Server Error 5xx
+
+   Response status codes beginning with the digit "5" indicate cases in
+   which the server is aware that it has erred or is incapable of
+   performing the request. Except when responding to a HEAD request, the
+   server SHOULD include an entity containing an explanation of the
+   error situation, and whether it is a temporary or permanent
+   condition. User agents SHOULD display any included entity to the
+   user. These response codes are applicable to any request method.
+
+10.5.1 500 Internal Server Error
+
+   The server encountered an unexpected condition which prevented it
+   from fulfilling the request.
+
+10.5.2 501 Not Implemented
+
+   The server does not support the functionality required to fulfill the
+   request. This is the appropriate response when the server does not
+   recognize the request method and is not capable of supporting it for
+   any resource.
+
+10.5.3 502 Bad Gateway
+
+   The server, while acting as a gateway or proxy, received an invalid
+   response from the upstream server it accessed in attempting to
+   fulfill the request.
+
+10.5.4 503 Service Unavailable
+
+   The server is currently unable to handle the request due to a
+   temporary overloading or maintenance of the server. The implication
+   is that this is a temporary condition which will be alleviated after
+   some delay. If known, the length of the delay MAY be indicated in a
+   Retry-After header. If no Retry-After is given, the client SHOULD
+   handle the response as it would for a 500 response.
+
+      Note: The existence of the 503 status code does not imply that a
+      server must use it when becoming overloaded. Some servers may wish
+      to simply refuse the connection.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 70]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+10.5.5 504 Gateway Timeout
+
+   The server, while acting as a gateway or proxy, did not receive a
+   timely response from the upstream server specified by the URI (e.g.
+   HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
+   to access in attempting to complete the request.
+
+      Note: Note to implementors: some deployed proxies are known to
+      return 400 or 500 when DNS lookups time out.
+
+10.5.6 505 HTTP Version Not Supported
+
+   The server does not support, or refuses to support, the HTTP protocol
+   version that was used in the request message. The server is
+   indicating that it is unable or unwilling to complete the request
+   using the same major version as the client, as described in section
+   3.1, other than with this error message. The response SHOULD contain
+   an entity describing why that version is not supported and what other
+   protocols are supported by that server.
+
+11 Access Authentication
+
+   HTTP provides several OPTIONAL challenge-response authentication
+   mechanisms which can be used by a server to challenge a client
+   request and by a client to provide authentication information. The
+   general framework for access authentication, and the specification of
+   "basic" and "digest" authentication, are specified in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. This
+   specification adopts the definitions of "challenge" and "credentials"
+   from that specification.
+
+12 Content Negotiation
+
+   Most HTTP responses include an entity which contains information for
+   interpretation by a human user. Naturally, it is desirable to supply
+   the user with the "best available" entity corresponding to the
+   request. Unfortunately for servers and caches, not all users have the
+   same preferences for what is "best," and not all user agents are
+   equally capable of rendering all entity types. For that reason, HTTP
+   has provisions for several mechanisms for "content negotiation" --
+   the process of selecting the best representation for a given response
+   when there are multiple representations available.
+
+      Note: This is not called "format negotiation" because the
+      alternate representations may be of the same media type, but use
+      different capabilities of that type, be in different languages,
+      etc.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 71]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Any response containing an entity-body MAY be subject to negotiation,
+   including error responses.
+
+   There are two kinds of content negotiation which are possible in
+   HTTP: server-driven and agent-driven negotiation. These two kinds of
+   negotiation are orthogonal and thus may be used separately or in
+   combination. One method of combination, referred to as transparent
+   negotiation, occurs when a cache uses the agent-driven negotiation
+   information provided by the origin server in order to provide
+   server-driven negotiation for subsequent requests.
+
+12.1 Server-driven Negotiation
+
+   If the selection of the best representation for a response is made by
+   an algorithm located at the server, it is called server-driven
+   negotiation. Selection is based on the available representations of
+   the response (the dimensions over which it can vary; e.g. language,
+   content-coding, etc.) and the contents of particular header fields in
+   the request message or on other information pertaining to the request
+   (such as the network address of the client).
+
+   Server-driven negotiation is advantageous when the algorithm for
+   selecting from among the available representations is difficult to
+   describe to the user agent, or when the server desires to send its
+   "best guess" to the client along with the first response (hoping to
+   avoid the round-trip delay of a subsequent request if the "best
+   guess" is good enough for the user). In order to improve the server's
+   guess, the user agent MAY include request header fields (Accept,
+   Accept-Language, Accept-Encoding, etc.) which describe its
+   preferences for such a response.
+
+   Server-driven negotiation has disadvantages:
+
+      1. It is impossible for the server to accurately determine what
+         might be "best" for any given user, since that would require
+         complete knowledge of both the capabilities of the user agent
+         and the intended use for the response (e.g., does the user want
+         to view it on screen or print it on paper?).
+
+      2. Having the user agent describe its capabilities in every
+         request can be both very inefficient (given that only a small
+         percentage of responses have multiple representations) and a
+         potential violation of the user's privacy.
+
+      3. It complicates the implementation of an origin server and the
+         algorithms for generating responses to a request.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 72]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      4. It may limit a public cache's ability to use the same response
+         for multiple user's requests.
+
+   HTTP/1.1 includes the following request-header fields for enabling
+   server-driven negotiation through description of user agent
+   capabilities and user preferences: Accept (section 14.1), Accept-
+   Charset (section 14.2), Accept-Encoding (section 14.3), Accept-
+   Language (section 14.4), and User-Agent (section 14.43). However, an
+   origin server is not limited to these dimensions and MAY vary the
+   response based on any aspect of the request, including information
+   outside the request-header fields or within extension header fields
+   not defined by this specification.
+
+   The Vary  header field can be used to express the parameters the
+   server uses to select a representation that is subject to server-
+   driven negotiation. See section 13.6 for use of the Vary header field
+   by caches and section 14.44 for use of the Vary header field by
+   servers.
+
+12.2 Agent-driven Negotiation
+
+   With agent-driven negotiation, selection of the best representation
+   for a response is performed by the user agent after receiving an
+   initial response from the origin server. Selection is based on a list
+   of the available representations of the response included within the
+   header fields or entity-body of the initial response, with each
+   representation identified by its own URI. Selection from among the
+   representations may be performed automatically (if the user agent is
+   capable of doing so) or manually by the user selecting from a
+   generated (possibly hypertext) menu.
+
+   Agent-driven negotiation is advantageous when the response would vary
+   over commonly-used dimensions (such as type, language, or encoding),
+   when the origin server is unable to determine a user agent's
+   capabilities from examining the request, and generally when public
+   caches are used to distribute server load and reduce network usage.
+
+   Agent-driven negotiation suffers from the disadvantage of needing a
+   second request to obtain the best alternate representation. This
+   second request is only efficient when caching is used. In addition,
+   this specification does not define any mechanism for supporting
+   automatic selection, though it also does not prevent any such
+   mechanism from being developed as an extension and used within
+   HTTP/1.1.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 73]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 defines the 300 (Multiple Choices) and 406 (Not Acceptable)
+   status codes for enabling agent-driven negotiation when the server is
+   unwilling or unable to provide a varying response using server-driven
+   negotiation.
+
+12.3 Transparent Negotiation
+
+   Transparent negotiation is a combination of both server-driven and
+   agent-driven negotiation. When a cache is supplied with a form of the
+   list of available representations of the response (as in agent-driven
+   negotiation) and the dimensions of variance are completely understood
+   by the cache, then the cache becomes capable of performing server-
+   driven negotiation on behalf of the origin server for subsequent
+   requests on that resource.
+
+   Transparent negotiation has the advantage of distributing the
+   negotiation work that would otherwise be required of the origin
+   server and also removing the second request delay of agent-driven
+   negotiation when the cache is able to correctly guess the right
+   response.
+
+   This specification does not define any mechanism for transparent
+   negotiation, though it also does not prevent any such mechanism from
+   being developed as an extension that could be used within HTTP/1.1.
+
+13 Caching in HTTP
+
+   HTTP is typically used for distributed information systems, where
+   performance can be improved by the use of response caches. The
+   HTTP/1.1 protocol includes a number of elements intended to make
+   caching work as well as possible. Because these elements are
+   inextricable from other aspects of the protocol, and because they
+   interact with each other, it is useful to describe the basic caching
+   design of HTTP separately from the detailed descriptions of methods,
+   headers, response codes, etc.
+
+   Caching would be useless if it did not significantly improve
+   performance. The goal of caching in HTTP/1.1 is to eliminate the need
+   to send requests in many cases, and to eliminate the need to send
+   full responses in many other cases. The former reduces the number of
+   network round-trips required for many operations; we use an
+   "expiration" mechanism for this purpose (see section 13.2). The
+   latter reduces network bandwidth requirements; we use a "validation"
+   mechanism for this purpose (see section 13.3).
+
+   Requirements for performance, availability, and disconnected
+   operation require us to be able to relax the goal of semantic
+   transparency. The HTTP/1.1 protocol allows origin servers, caches,
+
+
+
+Fielding, et al.            Standards Track                    [Page 74]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   and clients to explicitly reduce transparency when necessary.
+   However, because non-transparent operation may confuse non-expert
+   users, and might be incompatible with certain server applications
+   (such as those for ordering merchandise), the protocol requires that
+   transparency be relaxed
+
+      - only by an explicit protocol-level request when relaxed by
+        client or origin server
+
+      - only with an explicit warning to the end user when relaxed by
+        cache or client
+
+   Therefore, the HTTP/1.1 protocol provides these important elements:
+
+      1. Protocol features that provide full semantic transparency when
+         this is required by all parties.
+
+      2. Protocol features that allow an origin server or user agent to
+         explicitly request and control non-transparent operation.
+
+      3. Protocol features that allow a cache to attach warnings to
+         responses that do not preserve the requested approximation of
+         semantic transparency.
+
+   A basic principle is that it must be possible for the clients to
+   detect any potential relaxation of semantic transparency.
+
+      Note: The server, cache, or client implementor might be faced with
+      design decisions not explicitly discussed in this specification.
+      If a decision might affect semantic transparency, the implementor
+      ought to err on the side of maintaining transparency unless a
+      careful and complete analysis shows significant benefits in
+      breaking transparency.
+
+13.1.1 Cache Correctness
+
+   A correct cache MUST respond to a request with the most up-to-date
+   response held by the cache that is appropriate to the request (see
+   sections 13.2.5, 13.2.6, and 13.12) which meets one of the following
+   conditions:
+
+      1. It has been checked for equivalence with what the origin server
+         would have returned by revalidating the response with the
+         origin server (section 13.3);
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 75]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      2. It is "fresh enough" (see section 13.2). In the default case,
+         this means it meets the least restrictive freshness requirement
+         of the client, origin server, and cache (see section 14.9); if
+         the origin server so specifies, it is the freshness requirement
+         of the origin server alone.
+
+         If a stored response is not "fresh enough" by the most
+         restrictive freshness requirement of both the client and the
+         origin server, in carefully considered circumstances the cache
+         MAY still return the response with the appropriate Warning
+         header (see section 13.1.5 and 14.46), unless such a response
+         is prohibited (e.g., by a "no-store" cache-directive, or by a
+         "no-cache" cache-request-directive; see section 14.9).
+
+      3. It is an appropriate 304 (Not Modified), 305 (Proxy Redirect),
+         or error (4xx or 5xx) response message.
+
+   If the cache can not communicate with the origin server, then a
+   correct cache SHOULD respond as above if the response can be
+   correctly served from the cache; if not it MUST return an error or
+   warning indicating that there was a communication failure.
+
+   If a cache receives a response (either an entire response, or a 304
+   (Not Modified) response) that it would normally forward to the
+   requesting client, and the received response is no longer fresh, the
+   cache SHOULD forward it to the requesting client without adding a new
+   Warning (but without removing any existing Warning headers). A cache
+   SHOULD NOT attempt to revalidate a response simply because that
+   response became stale in transit; this might lead to an infinite
+   loop. A user agent that receives a stale response without a Warning
+   MAY display a warning indication to the user.
+
+13.1.2 Warnings
+
+   Whenever a cache returns a response that is neither first-hand nor
+   "fresh enough" (in the sense of condition 2 in section 13.1.1), it
+   MUST attach a warning to that effect, using a Warning general-header.
+   The Warning header and the currently defined warnings are described
+   in section 14.46. The warning allows clients to take appropriate
+   action.
+
+   Warnings MAY be used for other purposes, both cache-related and
+   otherwise. The use of a warning, rather than an error status code,
+   distinguish these responses from true failures.
+
+   Warnings are assigned three digit warn-codes. The first digit
+   indicates whether the Warning MUST or MUST NOT be deleted from a
+   stored cache entry after a successful revalidation:
+
+
+
+Fielding, et al.            Standards Track                    [Page 76]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   1xx  Warnings that describe the freshness or revalidation status of
+     the response, and so MUST be deleted after a successful
+     revalidation. 1XX warn-codes MAY be generated by a cache only when
+     validating a cached entry. It MUST NOT be generated by clients.
+
+   2xx  Warnings that describe some aspect of the entity body or entity
+     headers that is not rectified by a revalidation (for example, a
+     lossy compression of the entity bodies) and which MUST NOT be
+     deleted after a successful revalidation.
+
+   See section 14.46 for the definitions of the codes themselves.
+
+   HTTP/1.0 caches will cache all Warnings in responses, without
+   deleting the ones in the first category. Warnings in responses that
+   are passed to HTTP/1.0 caches carry an extra warning-date field,
+   which prevents a future HTTP/1.1 recipient from believing an
+   erroneously cached Warning.
+
+   Warnings also carry a warning text. The text MAY be in any
+   appropriate natural language (perhaps based on the client's Accept
+   headers), and include an OPTIONAL indication of what character set is
+   used.
+
+   Multiple warnings MAY be attached to a response (either by the origin
+   server or by a cache), including multiple warnings with the same code
+   number. For example, a server might provide the same warning with
+   texts in both English and Basque.
+
+   When multiple warnings are attached to a response, it might not be
+   practical or reasonable to display all of them to the user. This
+   version of HTTP does not specify strict priority rules for deciding
+   which warnings to display and in what order, but does suggest some
+   heuristics.
+
+13.1.3 Cache-control Mechanisms
+
+   The basic cache mechanisms in HTTP/1.1 (server-specified expiration
+   times and validators) are implicit directives to caches. In some
+   cases, a server or client might need to provide explicit directives
+   to the HTTP caches. We use the Cache-Control header for this purpose.
+
+   The Cache-Control header allows a client or server to transmit a
+   variety of directives in either requests or responses. These
+   directives typically override the default caching algorithms. As a
+   general rule, if there is any apparent conflict between header
+   values, the most restrictive interpretation is applied (that is, the
+   one that is most likely to preserve semantic transparency). However,
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 77]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   in some cases, cache-control directives are explicitly specified as
+   weakening the approximation of semantic transparency (for example,
+   "max-stale" or "public").
+
+   The cache-control directives are described in detail in section 14.9.
+
+13.1.4 Explicit User Agent Warnings
+
+   Many user agents make it possible for users to override the basic
+   caching mechanisms. For example, the user agent might allow the user
+   to specify that cached entities (even explicitly stale ones) are
+   never validated. Or the user agent might habitually add "Cache-
+   Control: max-stale=3600" to every request. The user agent SHOULD NOT
+   default to either non-transparent behavior, or behavior that results
+   in abnormally ineffective caching, but MAY be explicitly configured
+   to do so by an explicit action of the user.
+
+   If the user has overridden the basic caching mechanisms, the user
+   agent SHOULD explicitly indicate to the user whenever this results in
+   the display of information that might not meet the server's
+   transparency requirements (in particular, if the displayed entity is
+   known to be stale). Since the protocol normally allows the user agent
+   to determine if responses are stale or not, this indication need only
+   be displayed when this actually happens. The indication need not be a
+   dialog box; it could be an icon (for example, a picture of a rotting
+   fish) or some other indicator.
+
+   If the user has overridden the caching mechanisms in a way that would
+   abnormally reduce the effectiveness of caches, the user agent SHOULD
+   continually indicate this state to the user (for example, by a
+   display of a picture of currency in flames) so that the user does not
+   inadvertently consume excess resources or suffer from excessive
+   latency.
+
+13.1.5 Exceptions to the Rules and Warnings
+
+   In some cases, the operator of a cache MAY choose to configure it to
+   return stale responses even when not requested by clients. This
+   decision ought not be made lightly, but may be necessary for reasons
+   of availability or performance, especially when the cache is poorly
+   connected to the origin server. Whenever a cache returns a stale
+   response, it MUST mark it as such (using a Warning header) enabling
+   the client software to alert the user that there might be a potential
+   problem.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 78]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   It also allows the user agent to take steps to obtain a first-hand or
+   fresh response. For this reason, a cache SHOULD NOT return a stale
+   response if the client explicitly requests a first-hand or fresh one,
+   unless it is impossible to comply for technical or policy reasons.
+
+13.1.6 Client-controlled Behavior
+
+   While the origin server (and to a lesser extent, intermediate caches,
+   by their contribution to the age of a response) are the primary
+   source of expiration information, in some cases the client might need
+   to control a cache's decision about whether to return a cached
+   response without validating it. Clients do this using several
+   directives of the Cache-Control header.
+
+   A client's request MAY specify the maximum age it is willing to
+   accept of an unvalidated response; specifying a value of zero forces
+   the cache(s) to revalidate all responses. A client MAY also specify
+   the minimum time remaining before a response expires. Both of these
+   options increase constraints on the behavior of caches, and so cannot
+   further relax the cache's approximation of semantic transparency.
+
+   A client MAY also specify that it will accept stale responses, up to
+   some maximum amount of staleness. This loosens the constraints on the
+   caches, and so might violate the origin server's specified
+   constraints on semantic transparency, but might be necessary to
+   support disconnected operation, or high availability in the face of
+   poor connectivity.
+
+13.2 Expiration Model
+
+13.2.1 Server-Specified Expiration
+
+   HTTP caching works best when caches can entirely avoid making
+   requests to the origin server. The primary mechanism for avoiding
+   requests is for an origin server to provide an explicit expiration
+   time in the future, indicating that a response MAY be used to satisfy
+   subsequent requests. In other words, a cache can return a fresh
+   response without first contacting the server.
+
+   Our expectation is that servers will assign future explicit
+   expiration times to responses in the belief that the entity is not
+   likely to change, in a semantically significant way, before the
+   expiration time is reached. This normally preserves semantic
+   transparency, as long as the server's expiration times are carefully
+   chosen.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 79]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The expiration mechanism applies only to responses taken from a cache
+   and not to first-hand responses forwarded immediately to the
+   requesting client.
+
+   If an origin server wishes to force a semantically transparent cache
+   to validate every request, it MAY assign an explicit expiration time
+   in the past. This means that the response is always stale, and so the
+   cache SHOULD validate it before using it for subsequent requests. See
+   section 14.9.4 for a more restrictive way to force revalidation.
+
+   If an origin server wishes to force any HTTP/1.1 cache, no matter how
+   it is configured, to validate every request, it SHOULD use the "must-
+   revalidate" cache-control directive (see section 14.9).
+
+   Servers specify explicit expiration times using either the Expires
+   header, or the max-age directive of the Cache-Control header.
+
+   An expiration time cannot be used to force a user agent to refresh
+   its display or reload a resource; its semantics apply only to caching
+   mechanisms, and such mechanisms need only check a resource's
+   expiration status when a new request for that resource is initiated.
+   See section 13.13 for an explanation of the difference between caches
+   and history mechanisms.
+
+13.2.2 Heuristic Expiration
+
+   Since origin servers do not always provide explicit expiration times,
+   HTTP caches typically assign heuristic expiration times, employing
+   algorithms that use other header values (such as the Last-Modified
+   time) to estimate a plausible expiration time. The HTTP/1.1
+   specification does not provide specific algorithms, but does impose
+   worst-case constraints on their results. Since heuristic expiration
+   times might compromise semantic transparency, they ought to used
+   cautiously, and we encourage origin servers to provide explicit
+   expiration times as much as possible.
+
+13.2.3 Age Calculations
+
+   In order to know if a cached entry is fresh, a cache needs to know if
+   its age exceeds its freshness lifetime. We discuss how to calculate
+   the latter in section 13.2.4; this section describes how to calculate
+   the age of a response or cache entry.
+
+   In this discussion, we use the term "now" to mean "the current value
+   of the clock at the host performing the calculation." Hosts that use
+   HTTP, but especially hosts running origin servers and caches, SHOULD
+   use NTP [28] or some similar protocol to synchronize their clocks to
+   a globally accurate time standard.
+
+
+
+Fielding, et al.            Standards Track                    [Page 80]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   HTTP/1.1 requires origin servers to send a Date header, if possible,
+   with every response, giving the time at which the response was
+   generated (see section 14.18). We use the term "date_value" to denote
+   the value of the Date header, in a form appropriate for arithmetic
+   operations.
+
+   HTTP/1.1 uses the Age response-header to convey the estimated age of
+   the response message when obtained from a cache. The Age field value
+   is the cache's estimate of the amount of time since the response was
+   generated or revalidated by the origin server.
+
+   In essence, the Age value is the sum of the time that the response
+   has been resident in each of the caches along the path from the
+   origin server, plus the amount of time it has been in transit along
+   network paths.
+
+   We use the term "age_value" to denote the value of the Age header, in
+   a form appropriate for arithmetic operations.
+
+   A response's age can be calculated in two entirely independent ways:
+
+      1. now minus date_value, if the local clock is reasonably well
+         synchronized to the origin server's clock. If the result is
+         negative, the result is replaced by zero.
+
+      2. age_value, if all of the caches along the response path
+         implement HTTP/1.1.
+
+   Given that we have two independent ways to compute the age of a
+   response when it is received, we can combine these as
+
+       corrected_received_age = max(now - date_value, age_value)
+
+   and as long as we have either nearly synchronized clocks or all-
+   HTTP/1.1 paths, one gets a reliable (conservative) result.
+
+   Because of network-imposed delays, some significant interval might
+   pass between the time that a server generates a response and the time
+   it is received at the next outbound cache or client. If uncorrected,
+   this delay could result in improperly low ages.
+
+   Because the request that resulted in the returned Age value must have
+   been initiated prior to that Age value's generation, we can correct
+   for delays imposed by the network by recording the time at which the
+   request was initiated. Then, when an Age value is received, it MUST
+   be interpreted relative to the time the request was initiated, not
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 81]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the time that the response was received. This algorithm results in
+   conservative behavior no matter how much delay is experienced. So, we
+   compute:
+
+      corrected_initial_age = corrected_received_age
+                            + (now - request_time)
+
+   where "request_time" is the time (according to the local clock) when
+   the request that elicited this response was sent.
+
+   Summary of age calculation algorithm, when a cache receives a
+   response:
+
+      /*
+       * age_value
+       *      is the value of Age: header received by the cache with
+       *              this response.
+       * date_value
+       *      is the value of the origin server's Date: header
+       * request_time
+       *      is the (local) time when the cache made the request
+       *              that resulted in this cached response
+       * response_time
+       *      is the (local) time when the cache received the
+       *              response
+       * now
+       *      is the current (local) time
+       */
+
+      apparent_age = max(0, response_time - date_value);
+      corrected_received_age = max(apparent_age, age_value);
+      response_delay = response_time - request_time;
+      corrected_initial_age = corrected_received_age + response_delay;
+      resident_time = now - response_time;
+      current_age   = corrected_initial_age + resident_time;
+
+   The current_age of a cache entry is calculated by adding the amount
+   of time (in seconds) since the cache entry was last validated by the
+   origin server to the corrected_initial_age. When a response is
+   generated from a cache entry, the cache MUST include a single Age
+   header field in the response with a value equal to the cache entry's
+   current_age.
+
+   The presence of an Age header field in a response implies that a
+   response is not first-hand. However, the converse is not true, since
+   the lack of an Age header field in a response does not imply that the
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 82]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   response is first-hand unless all caches along the request path are
+   compliant with HTTP/1.1 (i.e., older HTTP caches did not implement
+   the Age header field).
+
+13.2.4 Expiration Calculations
+
+   In order to decide whether a response is fresh or stale, we need to
+   compare its freshness lifetime to its age. The age is calculated as
+   described in section 13.2.3; this section describes how to calculate
+   the freshness lifetime, and to determine if a response has expired.
+   In the discussion below, the values can be represented in any form
+   appropriate for arithmetic operations.
+
+   We use the term "expires_value" to denote the value of the Expires
+   header. We use the term "max_age_value" to denote an appropriate
+   value of the number of seconds carried by the "max-age" directive of
+   the Cache-Control header in a response (see section 14.9.3).
+
+   The max-age directive takes priority over Expires, so if max-age is
+   present in a response, the calculation is simply:
+
+      freshness_lifetime = max_age_value
+
+   Otherwise, if Expires is present in the response, the calculation is:
+
+      freshness_lifetime = expires_value - date_value
+
+   Note that neither of these calculations is vulnerable to clock skew,
+   since all of the information comes from the origin server.
+
+   If none of Expires, Cache-Control: max-age, or Cache-Control: s-
+   maxage (see section 14.9.3) appears in the response, and the response
+   does not include other restrictions on caching, the cache MAY compute
+   a freshness lifetime using a heuristic. The cache MUST attach Warning
+   113 to any response whose age is more than 24 hours if such warning
+   has not already been added.
+
+   Also, if the response does have a Last-Modified time, the heuristic
+   expiration value SHOULD be no more than some fraction of the interval
+   since that time. A typical setting of this fraction might be 10%.
+
+   The calculation to determine if a response has expired is quite
+   simple:
+
+      response_is_fresh = (freshness_lifetime > current_age)
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 83]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.2.5 Disambiguating Expiration Values
+
+   Because expiration values are assigned optimistically, it is possible
+   for two caches to contain fresh values for the same resource that are
+   different.
+
+   If a client performing a retrieval receives a non-first-hand response
+   for a request that was already fresh in its own cache, and the Date
+   header in its existing cache entry is newer than the Date on the new
+   response, then the client MAY ignore the response. If so, it MAY
+   retry the request with a "Cache-Control: max-age=0" directive (see
+   section 14.9), to force a check with the origin server.
+
+   If a cache has two fresh responses for the same representation with
+   different validators, it MUST use the one with the more recent Date
+   header. This situation might arise because the cache is pooling
+   responses from other caches, or because a client has asked for a
+   reload or a revalidation of an apparently fresh cache entry.
+
+13.2.6 Disambiguating Multiple Responses
+
+   Because a client might be receiving responses via multiple paths, so
+   that some responses flow through one set of caches and other
+   responses flow through a different set of caches, a client might
+   receive responses in an order different from that in which the origin
+   server sent them. We would like the client to use the most recently
+   generated response, even if older responses are still apparently
+   fresh.
+
+   Neither the entity tag nor the expiration value can impose an
+   ordering on responses, since it is possible that a later response
+   intentionally carries an earlier expiration time. The Date values are
+   ordered to a granularity of one second.
+
+   When a client tries to revalidate a cache entry, and the response it
+   receives contains a Date header that appears to be older than the one
+   for the existing entry, then the client SHOULD repeat the request
+   unconditionally, and include
+
+       Cache-Control: max-age=0
+
+   to force any intermediate caches to validate their copies directly
+   with the origin server, or
+
+       Cache-Control: no-cache
+
+   to force any intermediate caches to obtain a new copy from the origin
+   server.
+
+
+
+Fielding, et al.            Standards Track                    [Page 84]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the Date values are equal, then the client MAY use either response
+   (or MAY, if it is being extremely prudent, request a new response).
+   Servers MUST NOT depend on clients being able to choose
+   deterministically between responses generated during the same second,
+   if their expiration times overlap.
+
+13.3 Validation Model
+
+   When a cache has a stale entry that it would like to use as a
+   response to a client's request, it first has to check with the origin
+   server (or possibly an intermediate cache with a fresh response) to
+   see if its cached entry is still usable. We call this "validating"
+   the cache entry. Since we do not want to have to pay the overhead of
+   retransmitting the full response if the cached entry is good, and we
+   do not want to pay the overhead of an extra round trip if the cached
+   entry is invalid, the HTTP/1.1 protocol supports the use of
+   conditional methods.
+
+   The key protocol features for supporting conditional methods are
+   those concerned with "cache validators." When an origin server
+   generates a full response, it attaches some sort of validator to it,
+   which is kept with the cache entry. When a client (user agent or
+   proxy cache) makes a conditional request for a resource for which it
+   has a cache entry, it includes the associated validator in the
+   request.
+
+   The server then checks that validator against the current validator
+   for the entity, and, if they match (see section 13.3.3), it responds
+   with a special status code (usually, 304 (Not Modified)) and no
+   entity-body. Otherwise, it returns a full response (including
+   entity-body). Thus, we avoid transmitting the full response if the
+   validator matches, and we avoid an extra round trip if it does not
+   match.
+
+   In HTTP/1.1, a conditional request looks exactly the same as a normal
+   request for the same resource, except that it carries a special
+   header (which includes the validator) that implicitly turns the
+   method (usually, GET) into a conditional.
+
+   The protocol includes both positive and negative senses of cache-
+   validating conditions. That is, it is possible to request either that
+   a method be performed if and only if a validator matches or if and
+   only if no validators match.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 85]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      Note: a response that lacks a validator may still be cached, and
+      served from cache until it expires, unless this is explicitly
+      prohibited by a cache-control directive. However, a cache cannot
+      do a conditional retrieval if it does not have a validator for the
+      entity, which means it will not be refreshable after it expires.
+
+13.3.1 Last-Modified Dates
+
+   The Last-Modified entity-header field value is often used as a cache
+   validator. In simple terms, a cache entry is considered to be valid
+   if the entity has not been modified since the Last-Modified value.
+
+13.3.2 Entity Tag Cache Validators
+
+   The ETag response-header field value, an entity tag, provides for an
+   "opaque" cache validator. This might allow more reliable validation
+   in situations where it is inconvenient to store modification dates,
+   where the one-second resolution of HTTP date values is not
+   sufficient, or where the origin server wishes to avoid certain
+   paradoxes that might arise from the use of modification dates.
+
+   Entity Tags are described in section 3.11. The headers used with
+   entity tags are described in sections 14.19, 14.24, 14.26 and 14.44.
+
+13.3.3 Weak and Strong Validators
+
+   Since both origin servers and caches will compare two validators to
+   decide if they represent the same or different entities, one normally
+   would expect that if the entity (the entity-body or any entity-
+   headers) changes in any way, then the associated validator would
+   change as well. If this is true, then we call this validator a
+   "strong validator."
+
+   However, there might be cases when a server prefers to change the
+   validator only on semantically significant changes, and not when
+   insignificant aspects of the entity change. A validator that does not
+   always change when the resource changes is a "weak validator."
+
+   Entity tags are normally "strong validators," but the protocol
+   provides a mechanism to tag an entity tag as "weak." One can think of
+   a strong validator as one that changes whenever the bits of an entity
+   changes, while a weak value changes whenever the meaning of an entity
+   changes. Alternatively, one can think of a strong validator as part
+   of an identifier for a specific entity, while a weak validator is
+   part of an identifier for a set of semantically equivalent entities.
+
+      Note: One example of a strong validator is an integer that is
+      incremented in stable storage every time an entity is changed.
+
+
+
+Fielding, et al.            Standards Track                    [Page 86]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      An entity's modification time, if represented with one-second
+      resolution, could be a weak validator, since it is possible that
+      the resource might be modified twice during a single second.
+
+      Support for weak validators is optional. However, weak validators
+      allow for more efficient caching of equivalent objects; for
+      example, a hit counter on a site is probably good enough if it is
+      updated every few days or weeks, and any value during that period
+      is likely "good enough" to be equivalent.
+
+   A "use" of a validator is either when a client generates a request
+   and includes the validator in a validating header field, or when a
+   server compares two validators.
+
+   Strong validators are usable in any context. Weak validators are only
+   usable in contexts that do not depend on exact equality of an entity.
+   For example, either kind is usable for a conditional GET of a full
+   entity. However, only a strong validator is usable for a sub-range
+   retrieval, since otherwise the client might end up with an internally
+   inconsistent entity.
+
+   Clients MAY issue simple (non-subrange) GET requests with either weak
+   validators or strong validators. Clients MUST NOT use weak validators
+   in other forms of request.
+
+   The only function that the HTTP/1.1 protocol defines on validators is
+   comparison. There are two validator comparison functions, depending
+   on whether the comparison context allows the use of weak validators
+   or not:
+
+      - The strong comparison function: in order to be considered equal,
+        both validators MUST be identical in every way, and both MUST
+        NOT be weak.
+
+      - The weak comparison function: in order to be considered equal,
+        both validators MUST be identical in every way, but either or
+        both of them MAY be tagged as "weak" without affecting the
+        result.
+
+   An entity tag is strong unless it is explicitly tagged as weak.
+   Section 3.11 gives the syntax for entity tags.
+
+   A Last-Modified time, when used as a validator in a request, is
+   implicitly weak unless it is possible to deduce that it is strong,
+   using the following rules:
+
+      - The validator is being compared by an origin server to the
+        actual current validator for the entity and,
+
+
+
+Fielding, et al.            Standards Track                    [Page 87]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - That origin server reliably knows that the associated entity did
+        not change twice during the second covered by the presented
+        validator.
+
+   or
+
+      - The validator is about to be used by a client in an If-
+        Modified-Since or If-Unmodified-Since header, because the client
+        has a cache entry for the associated entity, and
+
+      - That cache entry includes a Date value, which gives the time
+        when the origin server sent the original response, and
+
+      - The presented Last-Modified time is at least 60 seconds before
+        the Date value.
+
+   or
+
+      - The validator is being compared by an intermediate cache to the
+        validator stored in its cache entry for the entity, and
+
+      - That cache entry includes a Date value, which gives the time
+        when the origin server sent the original response, and
+
+      - The presented Last-Modified time is at least 60 seconds before
+        the Date value.
+
+   This method relies on the fact that if two different responses were
+   sent by the origin server during the same second, but both had the
+   same Last-Modified time, then at least one of those responses would
+   have a Date value equal to its Last-Modified time. The arbitrary 60-
+   second limit guards against the possibility that the Date and Last-
+   Modified values are generated from different clocks, or at somewhat
+   different times during the preparation of the response. An
+   implementation MAY use a value larger than 60 seconds, if it is
+   believed that 60 seconds is too short.
+
+   If a client wishes to perform a sub-range retrieval on a value for
+   which it has only a Last-Modified time and no opaque validator, it
+   MAY do this only if the Last-Modified time is strong in the sense
+   described here.
+
+   A cache or origin server receiving a conditional request, other than
+   a full-body GET request, MUST use the strong comparison function to
+   evaluate the condition.
+
+   These rules allow HTTP/1.1 caches and clients to safely perform sub-
+   range retrievals on values that have been obtained from HTTP/1.0
+
+
+
+Fielding, et al.            Standards Track                    [Page 88]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   servers.
+
+13.3.4 Rules for When to Use Entity Tags and Last-Modified Dates
+
+   We adopt a set of rules and recommendations for origin servers,
+   clients, and caches regarding when various validator types ought to
+   be used, and for what purposes.
+
+   HTTP/1.1 origin servers:
+
+      - SHOULD send an entity tag validator unless it is not feasible to
+        generate one.
+
+      - MAY send a weak entity tag instead of a strong entity tag, if
+        performance considerations support the use of weak entity tags,
+        or if it is unfeasible to send a strong entity tag.
+
+      - SHOULD send a Last-Modified value if it is feasible to send one,
+        unless the risk of a breakdown in semantic transparency that
+        could result from using this date in an If-Modified-Since header
+        would lead to serious problems.
+
+   In other words, the preferred behavior for an HTTP/1.1 origin server
+   is to send both a strong entity tag and a Last-Modified value.
+
+   In order to be legal, a strong entity tag MUST change whenever the
+   associated entity value changes in any way. A weak entity tag SHOULD
+   change whenever the associated entity changes in a semantically
+   significant way.
+
+      Note: in order to provide semantically transparent caching, an
+      origin server must avoid reusing a specific strong entity tag
+      value for two different entities, or reusing a specific weak
+      entity tag value for two semantically different entities. Cache
+      entries might persist for arbitrarily long periods, regardless of
+      expiration times, so it might be inappropriate to expect that a
+      cache will never again attempt to validate an entry using a
+      validator that it obtained at some point in the past.
+
+   HTTP/1.1 clients:
+
+      - If an entity tag has been provided by the origin server, MUST
+        use that entity tag in any cache-conditional request (using If-
+        Match or If-None-Match).
+
+      - If only a Last-Modified value has been provided by the origin
+        server, SHOULD use that value in non-subrange cache-conditional
+        requests (using If-Modified-Since).
+
+
+
+Fielding, et al.            Standards Track                    [Page 89]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - If only a Last-Modified value has been provided by an HTTP/1.0
+        origin server, MAY use that value in subrange cache-conditional
+        requests (using If-Unmodified-Since:). The user agent SHOULD
+        provide a way to disable this, in case of difficulty.
+
+      - If both an entity tag and a Last-Modified value have been
+        provided by the origin server, SHOULD use both validators in
+        cache-conditional requests. This allows both HTTP/1.0 and
+        HTTP/1.1 caches to respond appropriately.
+
+   An HTTP/1.1 origin server, upon receiving a conditional request that
+   includes both a Last-Modified date (e.g., in an If-Modified-Since or
+   If-Unmodified-Since header field) and one or more entity tags (e.g.,
+   in an If-Match, If-None-Match, or If-Range header field) as cache
+   validators, MUST NOT return a response status of 304 (Not Modified)
+   unless doing so is consistent with all of the conditional header
+   fields in the request.
+
+   An HTTP/1.1 caching proxy, upon receiving a conditional request that
+   includes both a Last-Modified date and one or more entity tags as
+   cache validators, MUST NOT return a locally cached response to the
+   client unless that cached response is consistent with all of the
+   conditional header fields in the request.
+
+      Note: The general principle behind these rules is that HTTP/1.1
+      servers and clients should transmit as much non-redundant
+      information as is available in their responses and requests.
+      HTTP/1.1 systems receiving this information will make the most
+      conservative assumptions about the validators they receive.
+
+      HTTP/1.0 clients and caches will ignore entity tags. Generally,
+      last-modified values received or used by these systems will
+      support transparent and efficient caching, and so HTTP/1.1 origin
+      servers should provide Last-Modified values. In those rare cases
+      where the use of a Last-Modified value as a validator by an
+      HTTP/1.0 system could result in a serious problem, then HTTP/1.1
+      origin servers should not provide one.
+
+13.3.5 Non-validating Conditionals
+
+   The principle behind entity tags is that only the service author
+   knows the semantics of a resource well enough to select an
+   appropriate cache validation mechanism, and the specification of any
+   validator comparison function more complex than byte-equality would
+   open up a can of worms. Thus, comparisons of any other headers
+   (except Last-Modified, for compatibility with HTTP/1.0) are never
+   used for purposes of validating a cache entry.
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 90]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.4 Response Cacheability
+
+   Unless specifically constrained by a cache-control (section 14.9)
+   directive, a caching system MAY always store a successful response
+   (see section 13.8) as a cache entry, MAY return it without validation
+   if it is fresh, and MAY return it after successful validation. If
+   there is neither a cache validator nor an explicit expiration time
+   associated with a response, we do not expect it to be cached, but
+   certain caches MAY violate this expectation (for example, when little
+   or no network connectivity is available). A client can usually detect
+   that such a response was taken from a cache by comparing the Date
+   header to the current time.
+
+      Note: some HTTP/1.0 caches are known to violate this expectation
+      without providing any Warning.
+
+   However, in some cases it might be inappropriate for a cache to
+   retain an entity, or to return it in response to a subsequent
+   request. This might be because absolute semantic transparency is
+   deemed necessary by the service author, or because of security or
+   privacy considerations. Certain cache-control directives are
+   therefore provided so that the server can indicate that certain
+   resource entities, or portions thereof, are not to be cached
+   regardless of other considerations.
+
+   Note that section 14.8 normally prevents a shared cache from saving
+   and returning a response to a previous request if that request
+   included an Authorization header.
+
+   A response received with a status code of 200, 203, 206, 300, 301 or
+   410 MAY be stored by a cache and used in reply to a subsequent
+   request, subject to the expiration mechanism, unless a cache-control
+   directive prohibits caching. However, a cache that does not support
+   the Range and Content-Range headers MUST NOT cache 206 (Partial
+   Content) responses.
+
+   A response received with any other status code (e.g. status codes 302
+   and 307) MUST NOT be returned in a reply to a subsequent request
+   unless there are cache-control directives or another header(s) that
+   explicitly allow it. For example, these include the following: an
+   Expires header (section 14.21); a "max-age", "s-maxage",  "must-
+   revalidate", "proxy-revalidate", "public" or "private" cache-control
+   directive (section 14.9).
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 91]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5 Constructing Responses From Caches
+
+   The purpose of an HTTP cache is to store information received in
+   response to requests for use in responding to future requests. In
+   many cases, a cache simply returns the appropriate parts of a
+   response to the requester. However, if the cache holds a cache entry
+   based on a previous response, it might have to combine parts of a new
+   response with what is held in the cache entry.
+
+13.5.1 End-to-end and Hop-by-hop Headers
+
+   For the purpose of defining the behavior of caches and non-caching
+   proxies, we divide HTTP headers into two categories:
+
+      - End-to-end headers, which are  transmitted to the ultimate
+        recipient of a request or response. End-to-end headers in
+        responses MUST be stored as part of a cache entry and MUST be
+        transmitted in any response formed from a cache entry.
+
+      - Hop-by-hop headers, which are meaningful only for a single
+        transport-level connection, and are not stored by caches or
+        forwarded by proxies.
+
+   The following HTTP/1.1 headers are hop-by-hop headers:
+
+      - Connection
+      - Keep-Alive
+      - Proxy-Authenticate
+      - Proxy-Authorization
+      - TE
+      - Trailers
+      - Transfer-Encoding
+      - Upgrade
+
+   All other headers defined by HTTP/1.1 are end-to-end headers.
+
+   Other hop-by-hop headers MUST be listed in a Connection header,
+   (section 14.10) to be introduced into HTTP/1.1 (or later).
+
+13.5.2 Non-modifiable Headers
+
+   Some features of the HTTP/1.1 protocol, such as Digest
+   Authentication, depend on the value of certain end-to-end headers. A
+   transparent proxy SHOULD NOT modify an end-to-end header unless the
+   definition of that header requires or specifically allows that.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 92]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A transparent proxy MUST NOT modify any of the following fields in a
+   request or response, and it MUST NOT add any of these fields if not
+   already present:
+
+      - Content-Location
+
+      - Content-MD5
+
+      - ETag
+
+      - Last-Modified
+
+   A transparent proxy MUST NOT modify any of the following fields in a
+   response:
+
+      - Expires
+
+   but it MAY add any of these fields if not already present. If an
+   Expires header is added, it MUST be given a field-value identical to
+   that of the Date header in that response.
+
+   A  proxy MUST NOT modify or add any of the following fields in a
+   message that contains the no-transform cache-control directive, or in
+   any request:
+
+      - Content-Encoding
+
+      - Content-Range
+
+      - Content-Type
+
+   A non-transparent proxy MAY modify or add these fields to a message
+   that does not include no-transform, but if it does so, it MUST add a
+   Warning 214 (Transformation applied) if one does not already appear
+   in the message (see section 14.46).
+
+      Warning: unnecessary modification of end-to-end headers might
+      cause authentication failures if stronger authentication
+      mechanisms are introduced in later versions of HTTP. Such
+      authentication mechanisms MAY rely on the values of header fields
+      not listed here.
+
+   The Content-Length field of a request or response is added or deleted
+   according to the rules in section 4.4. A transparent proxy MUST
+   preserve the entity-length (section 7.2.2) of the entity-body,
+   although it MAY change the transfer-length (section 4.4).
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 93]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5.3 Combining Headers
+
+   When a cache makes a validating request to a server, and the server
+   provides a 304 (Not Modified) response or a 206 (Partial Content)
+   response, the cache then constructs a response to send to the
+   requesting client.
+
+   If the status code is 304 (Not Modified), the cache uses the entity-
+   body stored in the cache entry as the entity-body of this outgoing
+   response. If the status code is 206 (Partial Content) and the ETag or
+   Last-Modified headers match exactly, the cache MAY combine the
+   contents stored in the cache entry with the new contents received in
+   the response and use the result as the entity-body of this outgoing
+   response, (see 13.5.4).
+
+   The end-to-end headers stored in the cache entry are used for the
+   constructed response, except that
+
+      - any stored Warning headers with warn-code 1xx (see section
+        14.46) MUST be deleted from the cache entry and the forwarded
+        response.
+
+      - any stored Warning headers with warn-code 2xx MUST be retained
+        in the cache entry and the forwarded response.
+
+      - any end-to-end headers provided in the 304 or 206 response MUST
+        replace the corresponding headers from the cache entry.
+
+   Unless the cache decides to remove the cache entry, it MUST also
+   replace the end-to-end headers stored with the cache entry with
+   corresponding headers received in the incoming response, except for
+   Warning headers as described immediately above. If a header field-
+   name in the incoming response matches more than one header in the
+   cache entry, all such old headers MUST be replaced.
+
+   In other words, the set of end-to-end headers received in the
+   incoming response overrides all corresponding end-to-end headers
+   stored with the cache entry (except for stored Warning headers with
+   warn-code 1xx, which are deleted even if not overridden).
+
+      Note: this rule allows an origin server to use a 304 (Not
+      Modified) or a 206 (Partial Content) response to update any header
+      associated with a previous response for the same entity or sub-
+      ranges thereof, although it might not always be meaningful or
+      correct to do so. This rule does not allow an origin server to use
+      a 304 (Not Modified) or a 206 (Partial Content) response to
+      entirely delete a header that it had provided with a previous
+      response.
+
+
+
+Fielding, et al.            Standards Track                    [Page 94]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.5.4 Combining Byte Ranges
+
+   A response might transfer only a subrange of the bytes of an entity-
+   body, either because the request included one or more Range
+   specifications, or because a connection was broken prematurely. After
+   several such transfers, a cache might have received several ranges of
+   the same entity-body.
+
+   If a cache has a stored non-empty set of subranges for an entity, and
+   an incoming response transfers another subrange, the cache MAY
+   combine the new subrange with the existing set if both the following
+   conditions are met:
+
+      - Both the incoming response and the cache entry have a cache
+        validator.
+
+      - The two cache validators match using the strong comparison
+        function (see section 13.3.3).
+
+   If either requirement is not met, the cache MUST use only the most
+   recent partial response (based on the Date values transmitted with
+   every response, and using the incoming response if these values are
+   equal or missing), and MUST discard the other partial information.
+
+13.6 Caching Negotiated Responses
+
+   Use of server-driven content negotiation (section 12.1), as indicated
+   by the presence of a Vary header field in a response, alters the
+   conditions and procedure by which a cache can use the response for
+   subsequent requests. See section 14.44 for use of the Vary header
+   field by servers.
+
+   A server SHOULD use the Vary header field to inform a cache of what
+   request-header fields were used to select among multiple
+   representations of a cacheable response subject to server-driven
+   negotiation. The set of header fields named by the Vary field value
+   is known as the "selecting" request-headers.
+
+   When the cache receives a subsequent request whose Request-URI
+   specifies one or more cache entries including a Vary header field,
+   the cache MUST NOT use such a cache entry to construct a response to
+   the new request unless all of the selecting request-headers present
+   in the new request match the corresponding stored request-headers in
+   the original request.
+
+   The selecting request-headers from two requests are defined to match
+   if and only if the selecting request-headers in the first request can
+   be transformed to the selecting request-headers in the second request
+
+
+
+Fielding, et al.            Standards Track                    [Page 95]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   by adding or removing linear white space (LWS) at places where this
+   is allowed by the corresponding BNF, and/or combining multiple
+   message-header fields with the same field name following the rules
+   about message headers in section 4.2.
+
+   A Vary header field-value of "*" always fails to match and subsequent
+   requests on that resource can only be properly interpreted by the
+   origin server.
+
+   If the selecting request header fields for the cached entry do not
+   match the selecting request header fields of the new request, then
+   the cache MUST NOT use a cached entry to satisfy the request unless
+   it first relays the new request to the origin server in a conditional
+   request and the server responds with 304 (Not Modified), including an
+   entity tag or Content-Location that indicates the entity to be used.
+
+   If an entity tag was assigned to a cached representation, the
+   forwarded request SHOULD be conditional and include the entity tags
+   in an If-None-Match header field from all its cache entries for the
+   resource. This conveys to the server the set of entities currently
+   held by the cache, so that if any one of these entities matches the
+   requested entity, the server can use the ETag header field in its 304
+   (Not Modified) response to tell the cache which entry is appropriate.
+   If the entity-tag of the new response matches that of an existing
+   entry, the new response SHOULD be used to update the header fields of
+   the existing entry, and the result MUST be returned to the client.
+
+   If any of the existing cache entries contains only partial content
+   for the associated entity, its entity-tag SHOULD NOT be included in
+   the If-None-Match header field unless the request is for a range that
+   would be fully satisfied by that entry.
+
+   If a cache receives a successful response whose Content-Location
+   field matches that of an existing cache entry for the same Request-
+   ]URI, whose entity-tag differs from that of the existing entry, and
+   whose Date is more recent than that of the existing entry, the
+   existing entry SHOULD NOT be returned in response to future requests
+   and SHOULD be deleted from the cache.
+
+13.7 Shared and Non-Shared Caches
+
+   For reasons of security and privacy, it is necessary to make a
+   distinction between "shared" and "non-shared" caches. A non-shared
+   cache is one that is accessible only to a single user. Accessibility
+   in this case SHOULD be enforced by appropriate security mechanisms.
+   All other caches are considered to be "shared." Other sections of
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 96]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   this specification place certain constraints on the operation of
+   shared caches in order to prevent loss of privacy or failure of
+   access controls.
+
+13.8 Errors or Incomplete Response Cache Behavior
+
+   A cache that receives an incomplete response (for example, with fewer
+   bytes of data than specified in a Content-Length header) MAY store
+   the response. However, the cache MUST treat this as a partial
+   response. Partial responses MAY be combined as described in section
+   13.5.4; the result might be a full response or might still be
+   partial. A cache MUST NOT return a partial response to a client
+   without explicitly marking it as such, using the 206 (Partial
+   Content) status code. A cache MUST NOT return a partial response
+   using a status code of 200 (OK).
+
+   If a cache receives a 5xx response while attempting to revalidate an
+   entry, it MAY either forward this response to the requesting client,
+   or act as if the server failed to respond. In the latter case, it MAY
+   return a previously received response unless the cached entry
+   includes the "must-revalidate" cache-control directive (see section
+   14.9).
+
+13.9 Side Effects of GET and HEAD
+
+   Unless the origin server explicitly prohibits the caching of their
+   responses, the application of GET and HEAD methods to any resources
+   SHOULD NOT have side effects that would lead to erroneous behavior if
+   these responses are taken from a cache. They MAY still have side
+   effects, but a cache is not required to consider such side effects in
+   its caching decisions. Caches are always expected to observe an
+   origin server's explicit restrictions on caching.
+
+   We note one exception to this rule: since some applications have
+   traditionally used GETs and HEADs with query URLs (those containing a
+   "?" in the rel_path part) to perform operations with significant side
+   effects, caches MUST NOT treat responses to such URIs as fresh unless
+   the server provides an explicit expiration time. This specifically
+   means that responses from HTTP/1.0 servers for such URIs SHOULD NOT
+   be taken from a cache. See section 9.1.1 for related information.
+
+13.10 Invalidation After Updates or Deletions
+
+   The effect of certain methods performed on a resource at the origin
+   server might cause one or more existing cache entries to become non-
+   transparently invalid. That is, although they might continue to be
+   "fresh," they do not accurately reflect what the origin server would
+   return for a new request on that resource.
+
+
+
+Fielding, et al.            Standards Track                    [Page 97]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   There is no way for the HTTP protocol to guarantee that all such
+   cache entries are marked invalid. For example, the request that
+   caused the change at the origin server might not have gone through
+   the proxy where a cache entry is stored. However, several rules help
+   reduce the likelihood of erroneous behavior.
+
+   In this section, the phrase "invalidate an entity" means that the
+   cache will either remove all instances of that entity from its
+   storage, or will mark these as "invalid" and in need of a mandatory
+   revalidation before they can be returned in response to a subsequent
+   request.
+
+   Some HTTP methods MUST cause a cache to invalidate an entity. This is
+   either the entity referred to by the Request-URI, or by the Location
+   or Content-Location headers (if present). These methods are:
+
+      - PUT
+
+      - DELETE
+
+      - POST
+
+   In order to prevent denial of service attacks, an invalidation based
+   on the URI in a Location or Content-Location header MUST only be
+   performed if the host part is the same as in the Request-URI.
+
+   A cache that passes through requests for methods it does not
+   understand SHOULD invalidate any entities referred to by the
+   Request-URI.
+
+13.11 Write-Through Mandatory
+
+   All methods that might be expected to cause modifications to the
+   origin server's resources MUST be written through to the origin
+   server. This currently includes all methods except for GET and HEAD.
+   A cache MUST NOT reply to such a request from a client before having
+   transmitted the request to the inbound server, and having received a
+   corresponding response from the inbound server. This does not prevent
+   a proxy cache from sending a 100 (Continue) response before the
+   inbound server has sent its final reply.
+
+   The alternative (known as "write-back" or "copy-back" caching) is not
+   allowed in HTTP/1.1, due to the difficulty of providing consistent
+   updates and the problems arising from server, cache, or network
+   failure prior to write-back.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 98]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+13.12 Cache Replacement
+
+   If a new cacheable (see sections 14.9.2, 13.2.5, 13.2.6 and 13.8)
+   response is received from a resource while any existing responses for
+   the same resource are cached, the cache SHOULD use the new response
+   to reply to the current request. It MAY insert it into cache storage
+   and MAY, if it meets all other requirements, use it to respond to any
+   future requests that would previously have caused the old response to
+   be returned. If it inserts the new response into cache storage  the
+   rules in section 13.5.3 apply.
+
+      Note: a new response that has an older Date header value than
+      existing cached responses is not cacheable.
+
+13.13 History Lists
+
+   User agents often have history mechanisms, such as "Back" buttons and
+   history lists, which can be used to redisplay an entity retrieved
+   earlier in a session.
+
+   History mechanisms and caches are different. In particular history
+   mechanisms SHOULD NOT try to show a semantically transparent view of
+   the current state of a resource. Rather, a history mechanism is meant
+   to show exactly what the user saw at the time when the resource was
+   retrieved.
+
+   By default, an expiration time does not apply to history mechanisms.
+   If the entity is still in storage, a history mechanism SHOULD display
+   it even if the entity has expired, unless the user has specifically
+   configured the agent to refresh expired history documents.
+
+   This is not to be construed to prohibit the history mechanism from
+   telling the user that a view might be stale.
+
+      Note: if history list mechanisms unnecessarily prevent users from
+      viewing stale resources, this will tend to force service authors
+      to avoid using HTTP expiration controls and cache controls when
+      they would otherwise like to. Service authors may consider it
+      important that users not be presented with error messages or
+      warning messages when they use navigation controls (such as BACK)
+      to view previously fetched resources. Even though sometimes such
+      resources ought not to cached, or ought to expire quickly, user
+      interface considerations may force service authors to resort to
+      other means of preventing caching (e.g. "once-only" URLs) in order
+      not to suffer the effects of improperly functioning history
+      mechanisms.
+
+
+
+
+
+Fielding, et al.            Standards Track                    [Page 99]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14 Header Field Definitions
+
+   This section defines the syntax and semantics of all standard
+   HTTP/1.1 header fields. For entity-header fields, both sender and
+   recipient refer to either the client or the server, depending on who
+   sends and who receives the entity.
+
+14.1 Accept
+
+   The Accept request-header field can be used to specify certain media
+   types which are acceptable for the response. Accept headers can be
+   used to indicate that the request is specifically limited to a small
+   set of desired types, as in the case of a request for an in-line
+   image.
+
+       Accept         = "Accept" ":"
+                        #( media-range [ accept-params ] )
+
+       media-range    = ( "*/*"
+                        | ( type "/" "*" )
+                        | ( type "/" subtype )
+                        ) *( ";" parameter )
+       accept-params  = ";" "q" "=" qvalue *( accept-extension )
+       accept-extension = ";" token [ "=" ( token | quoted-string ) ]
+
+   The asterisk "*" character is used to group media types into ranges,
+   with "*/*" indicating all media types and "type/*" indicating all
+   subtypes of that type. The media-range MAY include media type
+   parameters that are applicable to that range.
+
+   Each media-range MAY be followed by one or more accept-params,
+   beginning with the "q" parameter for indicating a relative quality
+   factor. The first "q" parameter (if any) separates the media-range
+   parameter(s) from the accept-params. Quality factors allow the user
+   or user agent to indicate the relative degree of preference for that
+   media-range, using the qvalue scale from 0 to 1 (section 3.9). The
+   default value is q=1.
+
+      Note: Use of the "q" parameter name to separate media type
+      parameters from Accept extension parameters is due to historical
+      practice. Although this prevents any media type parameter named
+      "q" from being used with a media range, such an event is believed
+      to be unlikely given the lack of any "q" parameters in the IANA
+      media type registry and the rare usage of any media type
+      parameters in Accept. Future media types are discouraged from
+      registering any parameter named "q".
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 100]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The example
+
+       Accept: audio/*; q=0.2, audio/basic
+
+   SHOULD be interpreted as "I prefer audio/basic, but send me any audio
+   type if it is the best available after an 80% mark-down in quality."
+
+   If no Accept header field is present, then it is assumed that the
+   client accepts all media types. If an Accept header field is present,
+   and if the server cannot send a response which is acceptable
+   according to the combined Accept field value, then the server SHOULD
+   send a 406 (not acceptable) response.
+
+   A more elaborate example is
+
+       Accept: text/plain; q=0.5, text/html,
+               text/x-dvi; q=0.8, text/x-c
+
+   Verbally, this would be interpreted as "text/html and text/x-c are
+   the preferred media types, but if they do not exist, then send the
+   text/x-dvi entity, and if that does not exist, send the text/plain
+   entity."
+
+   Media ranges can be overridden by more specific media ranges or
+   specific media types. If more than one media range applies to a given
+   type, the most specific reference has precedence. For example,
+
+       Accept: text/*, text/html, text/html;level=1, */*
+
+   have the following precedence:
+
+       1) text/html;level=1
+       2) text/html
+       3) text/*
+       4) */*
+
+   The media type quality factor associated with a given type is
+   determined by finding the media range with the highest precedence
+   which matches that type. For example,
+
+       Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
+               text/html;level=2;q=0.4, */*;q=0.5
+
+   would cause the following values to be associated:
+
+       text/html;level=1         = 1
+       text/html                 = 0.7
+       text/plain                = 0.3
+
+
+
+Fielding, et al.            Standards Track                   [Page 101]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       image/jpeg                = 0.5
+       text/html;level=2         = 0.4
+       text/html;level=3         = 0.7
+
+      Note: A user agent might be provided with a default set of quality
+      values for certain media ranges. However, unless the user agent is
+      a closed system which cannot interact with other rendering agents,
+      this default set ought to be configurable by the user.
+
+14.2 Accept-Charset
+
+   The Accept-Charset request-header field can be used to indicate what
+   character sets are acceptable for the response. This field allows
+   clients capable of understanding more comprehensive or special-
+   purpose character sets to signal that capability to a server which is
+   capable of representing documents in those character sets.
+
+      Accept-Charset = "Accept-Charset" ":"
+              1#( ( charset | "*" )[ ";" "q" "=" qvalue ] )
+
+
+   Character set values are described in section 3.4. Each charset MAY
+   be given an associated quality value which represents the user's
+   preference for that charset. The default value is q=1. An example is
+
+      Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+
+   The special value "*", if present in the Accept-Charset field,
+   matches every character set (including ISO-8859-1) which is not
+   mentioned elsewhere in the Accept-Charset field. If no "*" is present
+   in an Accept-Charset field, then all character sets not explicitly
+   mentioned get a quality value of 0, except for ISO-8859-1, which gets
+   a quality value of 1 if not explicitly mentioned.
+
+   If no Accept-Charset header is present, the default is that any
+   character set is acceptable. If an Accept-Charset header is present,
+   and if the server cannot send a response which is acceptable
+   according to the Accept-Charset header, then the server SHOULD send
+   an error response with the 406 (not acceptable) status code, though
+   the sending of an unacceptable response is also allowed.
+
+14.3 Accept-Encoding
+
+   The Accept-Encoding request-header field is similar to Accept, but
+   restricts the content-codings (section 3.5) that are acceptable in
+   the response.
+
+       Accept-Encoding  = "Accept-Encoding" ":"
+
+
+
+Fielding, et al.            Standards Track                   [Page 102]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+                          1#( codings [ ";" "q" "=" qvalue ] )
+       codings          = ( content-coding | "*" )
+
+   Examples of its use are:
+
+       Accept-Encoding: compress, gzip
+       Accept-Encoding:
+       Accept-Encoding: *
+       Accept-Encoding: compress;q=0.5, gzip;q=1.0
+       Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
+
+   A server tests whether a content-coding is acceptable, according to
+   an Accept-Encoding field, using these rules:
+
+      1. If the content-coding is one of the content-codings listed in
+         the Accept-Encoding field, then it is acceptable, unless it is
+         accompanied by a qvalue of 0. (As defined in section 3.9, a
+         qvalue of 0 means "not acceptable.")
+
+      2. The special "*" symbol in an Accept-Encoding field matches any
+         available content-coding not explicitly listed in the header
+         field.
+
+      3. If multiple content-codings are acceptable, then the acceptable
+         content-coding with the highest non-zero qvalue is preferred.
+
+      4. The "identity" content-coding is always acceptable, unless
+         specifically refused because the Accept-Encoding field includes
+         "identity;q=0", or because the field includes "*;q=0" and does
+         not explicitly include the "identity" content-coding. If the
+         Accept-Encoding field-value is empty, then only the "identity"
+         encoding is acceptable.
+
+   If an Accept-Encoding field is present in a request, and if the
+   server cannot send a response which is acceptable according to the
+   Accept-Encoding header, then the server SHOULD send an error response
+   with the 406 (Not Acceptable) status code.
+
+   If no Accept-Encoding field is present in a request, the server MAY
+   assume that the client will accept any content coding. In this case,
+   if "identity" is one of the available content-codings, then the
+   server SHOULD use the "identity" content-coding, unless it has
+   additional information that a different content-coding is meaningful
+   to the client.
+
+      Note: If the request does not include an Accept-Encoding field,
+      and if the "identity" content-coding is unavailable, then
+      content-codings commonly understood by HTTP/1.0 clients (i.e.,
+
+
+
+Fielding, et al.            Standards Track                   [Page 103]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      "gzip" and "compress") are preferred; some older clients
+      improperly display messages sent with other content-codings.  The
+      server might also make this decision based on information about
+      the particular user-agent or client.
+
+      Note: Most HTTP/1.0 applications do not recognize or obey qvalues
+      associated with content-codings. This means that qvalues will not
+      work and are not permitted with x-gzip or x-compress.
+
+14.4 Accept-Language
+
+   The Accept-Language request-header field is similar to Accept, but
+   restricts the set of natural languages that are preferred as a
+   response to the request. Language tags are defined in section 3.10.
+
+       Accept-Language = "Accept-Language" ":"
+                         1#( language-range [ ";" "q" "=" qvalue ] )
+       language-range  = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) | "*" )
+
+   Each language-range MAY be given an associated quality value which
+   represents an estimate of the user's preference for the languages
+   specified by that range. The quality value defaults to "q=1". For
+   example,
+
+       Accept-Language: da, en-gb;q=0.8, en;q=0.7
+
+   would mean: "I prefer Danish, but will accept British English and
+   other types of English." A language-range matches a language-tag if
+   it exactly equals the tag, or if it exactly equals a prefix of the
+   tag such that the first tag character following the prefix is "-".
+   The special range "*", if present in the Accept-Language field,
+   matches every tag not matched by any other range present in the
+   Accept-Language field.
+
+      Note: This use of a prefix matching rule does not imply that
+      language tags are assigned to languages in such a way that it is
+      always true that if a user understands a language with a certain
+      tag, then this user will also understand all languages with tags
+      for which this tag is a prefix. The prefix rule simply allows the
+      use of prefix tags if this is the case.
+
+   The language quality factor assigned to a language-tag by the
+   Accept-Language field is the quality value of the longest language-
+   range in the field that matches the language-tag. If no language-
+   range in the field matches the tag, the language quality factor
+   assigned is 0. If no Accept-Language header is present in the
+   request, the server
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 104]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   SHOULD assume that all languages are equally acceptable. If an
+   Accept-Language header is present, then all languages which are
+   assigned a quality factor greater than 0 are acceptable.
+
+   It might be contrary to the privacy expectations of the user to send
+   an Accept-Language header with the complete linguistic preferences of
+   the user in every request. For a discussion of this issue, see
+   section 15.1.4.
+
+   As intelligibility is highly dependent on the individual user, it is
+   recommended that client applications make the choice of linguistic
+   preference available to the user. If the choice is not made
+   available, then the Accept-Language header field MUST NOT be given in
+   the request.
+
+      Note: When making the choice of linguistic preference available to
+      the user, we remind implementors of  the fact that users are not
+      familiar with the details of language matching as described above,
+      and should provide appropriate guidance. As an example, users
+      might assume that on selecting "en-gb", they will be served any
+      kind of English document if British English is not available. A
+      user agent might suggest in such a case to add "en" to get the
+      best matching behavior.
+
+14.5 Accept-Ranges
+
+      The Accept-Ranges response-header field allows the server to
+      indicate its acceptance of range requests for a resource:
+
+          Accept-Ranges     = "Accept-Ranges" ":" acceptable-ranges
+          acceptable-ranges = 1#range-unit | "none"
+
+      Origin servers that accept byte-range requests MAY send
+
+          Accept-Ranges: bytes
+
+      but are not required to do so. Clients MAY generate byte-range
+      requests without having received this header for the resource
+      involved. Range units are defined in section 3.12.
+
+      Servers that do not accept any kind of range request for a
+      resource MAY send
+
+          Accept-Ranges: none
+
+      to advise the client not to attempt a range request.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 105]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.6 Age
+
+      The Age response-header field conveys the sender's estimate of the
+      amount of time since the response (or its revalidation) was
+      generated at the origin server. A cached response is "fresh" if
+      its age does not exceed its freshness lifetime. Age values are
+      calculated as specified in section 13.2.3.
+
+           Age = "Age" ":" age-value
+           age-value = delta-seconds
+
+      Age values are non-negative decimal integers, representing time in
+      seconds.
+
+      If a cache receives a value larger than the largest positive
+      integer it can represent, or if any of its age calculations
+      overflows, it MUST transmit an Age header with a value of
+      2147483648 (2^31). An HTTP/1.1 server that includes a cache MUST
+      include an Age header field in every response generated from its
+      own cache. Caches SHOULD use an arithmetic type of at least 31
+      bits of range.
+
+14.7 Allow
+
+      The Allow entity-header field lists the set of methods supported
+      by the resource identified by the Request-URI. The purpose of this
+      field is strictly to inform the recipient of valid methods
+      associated with the resource. An Allow header field MUST be
+      present in a 405 (Method Not Allowed) response.
+
+          Allow   = "Allow" ":" #Method
+
+      Example of use:
+
+          Allow: GET, HEAD, PUT
+
+      This field cannot prevent a client from trying other methods.
+      However, the indications given by the Allow header field value
+      SHOULD be followed. The actual set of allowed methods is defined
+      by the origin server at the time of each request.
+
+      The Allow header field MAY be provided with a PUT request to
+      recommend the methods to be supported by the new or modified
+      resource. The server is not required to support these methods and
+      SHOULD include an Allow header in the response giving the actual
+      supported methods.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 106]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      A proxy MUST NOT modify the Allow header field even if it does not
+      understand all the methods specified, since the user agent might
+      have other means of communicating with the origin server.
+
+14.8 Authorization
+
+      A user agent that wishes to authenticate itself with a server--
+      usually, but not necessarily, after receiving a 401 response--does
+      so by including an Authorization request-header field with the
+      request.  The Authorization field value consists of credentials
+      containing the authentication information of the user agent for
+      the realm of the resource being requested.
+
+          Authorization  = "Authorization" ":" credentials
+
+      HTTP access authentication is described in "HTTP Authentication:
+      Basic and Digest Access Authentication" [43]. If a request is
+      authenticated and a realm specified, the same credentials SHOULD
+      be valid for all other requests within this realm (assuming that
+      the authentication scheme itself does not require otherwise, such
+      as credentials that vary according to a challenge value or using
+      synchronized clocks).
+
+      When a shared cache (see section 13.7) receives a request
+      containing an Authorization field, it MUST NOT return the
+      corresponding response as a reply to any other request, unless one
+      of the following specific exceptions holds:
+
+      1. If the response includes the "s-maxage" cache-control
+         directive, the cache MAY use that response in replying to a
+         subsequent request. But (if the specified maximum age has
+         passed) a proxy cache MUST first revalidate it with the origin
+         server, using the request-headers from the new request to allow
+         the origin server to authenticate the new request. (This is the
+         defined behavior for s-maxage.) If the response includes "s-
+         maxage=0", the proxy MUST always revalidate it before re-using
+         it.
+
+      2. If the response includes the "must-revalidate" cache-control
+         directive, the cache MAY use that response in replying to a
+         subsequent request. But if the response is stale, all caches
+         MUST first revalidate it with the origin server, using the
+         request-headers from the new request to allow the origin server
+         to authenticate the new request.
+
+      3. If the response includes the "public" cache-control directive,
+         it MAY be returned in reply to any subsequent request.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 107]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.9 Cache-Control
+
+   The Cache-Control general-header field is used to specify directives
+   that MUST be obeyed by all caching mechanisms along the
+   request/response chain. The directives specify behavior intended to
+   prevent caches from adversely interfering with the request or
+   response. These directives typically override the default caching
+   algorithms. Cache directives are unidirectional in that the presence
+   of a directive in a request does not imply that the same directive is
+   to be given in the response.
+
+      Note that HTTP/1.0 caches might not implement Cache-Control and
+      might only implement Pragma: no-cache (see section 14.32).
+
+   Cache directives MUST be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives might be applicable to all recipients along the
+   request/response chain. It is not possible to specify a cache-
+   directive for a specific cache.
+
+    Cache-Control   = "Cache-Control" ":" 1#cache-directive
+
+    cache-directive = cache-request-directive
+         | cache-response-directive
+
+    cache-request-directive =
+           "no-cache"                          ; Section 14.9.1
+         | "no-store"                          ; Section 14.9.2
+         | "max-age" "=" delta-seconds         ; Section 14.9.3, 14.9.4
+         | "max-stale" [ "=" delta-seconds ]   ; Section 14.9.3
+         | "min-fresh" "=" delta-seconds       ; Section 14.9.3
+         | "no-transform"                      ; Section 14.9.5
+         | "only-if-cached"                    ; Section 14.9.4
+         | cache-extension                     ; Section 14.9.6
+
+     cache-response-directive =
+           "public"                               ; Section 14.9.1
+         | "private" [ "=" <"> 1#field-name <"> ] ; Section 14.9.1
+         | "no-cache" [ "=" <"> 1#field-name <"> ]; Section 14.9.1
+         | "no-store"                             ; Section 14.9.2
+         | "no-transform"                         ; Section 14.9.5
+         | "must-revalidate"                      ; Section 14.9.4
+         | "proxy-revalidate"                     ; Section 14.9.4
+         | "max-age" "=" delta-seconds            ; Section 14.9.3
+         | "s-maxage" "=" delta-seconds           ; Section 14.9.3
+         | cache-extension                        ; Section 14.9.6
+
+    cache-extension = token [ "=" ( token | quoted-string ) ]
+
+
+
+Fielding, et al.            Standards Track                   [Page 108]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   When a directive appears without any 1#field-name parameter, the
+   directive applies to the entire request or response. When such a
+   directive appears with a 1#field-name parameter, it applies only to
+   the named field or fields, and not to the rest of the request or
+   response. This mechanism supports extensibility; implementations of
+   future versions of the HTTP protocol might apply these directives to
+   header fields not defined in HTTP/1.1.
+
+   The cache-control directives can be broken down into these general
+   categories:
+
+      - Restrictions on what are cacheable; these may only be imposed by
+        the origin server.
+
+      - Restrictions on what may be stored by a cache; these may be
+        imposed by either the origin server or the user agent.
+
+      - Modifications of the basic expiration mechanism; these may be
+        imposed by either the origin server or the user agent.
+
+      - Controls over cache revalidation and reload; these may only be
+        imposed by a user agent.
+
+      - Control over transformation of entities.
+
+      - Extensions to the caching system.
+
+14.9.1 What is Cacheable
+
+   By default, a response is cacheable if the requirements of the
+   request method, request header fields, and the response status
+   indicate that it is cacheable. Section 13.4 summarizes these defaults
+   for cacheability. The following Cache-Control response directives
+   allow an origin server to override the default cacheability of a
+   response:
+
+   public
+      Indicates that the response MAY be cached by any cache, even if it
+      would normally be non-cacheable or cacheable only within a non-
+      shared cache. (See also Authorization, section 14.8, for
+      additional details.)
+
+   private
+      Indicates that all or part of the response message is intended for
+      a single user and MUST NOT be cached by a shared cache. This
+      allows an origin server to state that the specified parts of the
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 109]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      response are intended for only one user and are not a valid
+      response for requests by other users. A private (non-shared) cache
+      MAY cache the response.
+
+       Note: This usage of the word private only controls where the
+       response may be cached, and cannot ensure the privacy of the
+       message content.
+
+   no-cache
+       If the no-cache directive does not specify a field-name, then a
+      cache MUST NOT use the response to satisfy a subsequent request
+      without successful revalidation with the origin server. This
+      allows an origin server to prevent caching even by caches that
+      have been configured to return stale responses to client requests.
+
+      If the no-cache directive does specify one or more field-names,
+      then a cache MAY use the response to satisfy a subsequent request,
+      subject to any other restrictions on caching. However, the
+      specified field-name(s) MUST NOT be sent in the response to a
+      subsequent request without successful revalidation with the origin
+      server. This allows an origin server to prevent the re-use of
+      certain header fields in a response, while still allowing caching
+      of the rest of the response.
+
+       Note: Most HTTP/1.0 caches will not recognize or obey this
+       directive.
+
+14.9.2 What May be Stored by Caches
+
+   no-store
+      The purpose of the no-store directive is to prevent the
+      inadvertent release or retention of sensitive information (for
+      example, on backup tapes). The no-store directive applies to the
+      entire message, and MAY be sent either in a response or in a
+      request. If sent in a request, a cache MUST NOT store any part of
+      either this request or any response to it. If sent in a response,
+      a cache MUST NOT store any part of either this response or the
+      request that elicited it. This directive applies to both non-
+      shared and shared caches. "MUST NOT store" in this context means
+      that the cache MUST NOT intentionally store the information in
+      non-volatile storage, and MUST make a best-effort attempt to
+      remove the information from volatile storage as promptly as
+      possible after forwarding it.
+
+      Even when this directive is associated with a response, users
+      might explicitly store such a response outside of the caching
+      system (e.g., with a "Save As" dialog). History buffers MAY store
+      such responses as part of their normal operation.
+
+
+
+Fielding, et al.            Standards Track                   [Page 110]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      The purpose of this directive is to meet the stated requirements
+      of certain users and service authors who are concerned about
+      accidental releases of information via unanticipated accesses to
+      cache data structures. While the use of this directive might
+      improve privacy in some cases, we caution that it is NOT in any
+      way a reliable or sufficient mechanism for ensuring privacy. In
+      particular, malicious or compromised caches might not recognize or
+      obey this directive, and communications networks might be
+      vulnerable to eavesdropping.
+
+14.9.3 Modifications of the Basic Expiration Mechanism
+
+   The expiration time of an entity MAY be specified by the origin
+   server using the Expires header (see section 14.21). Alternatively,
+   it MAY be specified using the max-age directive in a response. When
+   the max-age cache-control directive is present in a cached response,
+   the response is stale if its current age is greater than the age
+   value given (in seconds) at the time of a new request for that
+   resource. The max-age directive on a response implies that the
+   response is cacheable (i.e., "public") unless some other, more
+   restrictive cache directive is also present.
+
+   If a response includes both an Expires header and a max-age
+   directive, the max-age directive overrides the Expires header, even
+   if the Expires header is more restrictive. This rule allows an origin
+   server to provide, for a given response, a longer expiration time to
+   an HTTP/1.1 (or later) cache than to an HTTP/1.0 cache. This might be
+   useful if certain HTTP/1.0 caches improperly calculate ages or
+   expiration times, perhaps due to desynchronized clocks.
+
+   Many HTTP/1.0 cache implementations will treat an Expires value that
+   is less than or equal to the response Date value as being equivalent
+   to the Cache-Control response directive "no-cache". If an HTTP/1.1
+   cache receives such a response, and the response does not include a
+   Cache-Control header field, it SHOULD consider the response to be
+   non-cacheable in order to retain compatibility with HTTP/1.0 servers.
+
+       Note: An origin server might wish to use a relatively new HTTP
+       cache control feature, such as the "private" directive, on a
+       network including older caches that do not understand that
+       feature. The origin server will need to combine the new feature
+       with an Expires field whose value is less than or equal to the
+       Date value. This will prevent older caches from improperly
+       caching the response.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 111]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   s-maxage
+       If a response includes an s-maxage directive, then for a shared
+       cache (but not for a private cache), the maximum age specified by
+       this directive overrides the maximum age specified by either the
+       max-age directive or the Expires header. The s-maxage directive
+       also implies the semantics of the proxy-revalidate directive (see
+       section 14.9.4), i.e., that the shared cache must not use the
+       entry after it becomes stale to respond to a subsequent request
+       without first revalidating it with the origin server. The s-
+       maxage directive is always ignored by a private cache.
+
+   Note that most older caches, not compliant with this specification,
+   do not implement any cache-control directives. An origin server
+   wishing to use a cache-control directive that restricts, but does not
+   prevent, caching by an HTTP/1.1-compliant cache MAY exploit the
+   requirement that the max-age directive overrides the Expires header,
+   and the fact that pre-HTTP/1.1-compliant caches do not observe the
+   max-age directive.
+
+   Other directives allow a user agent to modify the basic expiration
+   mechanism. These directives MAY be specified on a request:
+
+   max-age
+      Indicates that the client is willing to accept a response whose
+      age is no greater than the specified time in seconds. Unless max-
+      stale directive is also included, the client is not willing to
+      accept a stale response.
+
+   min-fresh
+      Indicates that the client is willing to accept a response whose
+      freshness lifetime is no less than its current age plus the
+      specified time in seconds. That is, the client wants a response
+      that will still be fresh for at least the specified number of
+      seconds.
+
+   max-stale
+      Indicates that the client is willing to accept a response that has
+      exceeded its expiration time. If max-stale is assigned a value,
+      then the client is willing to accept a response that has exceeded
+      its expiration time by no more than the specified number of
+      seconds. If no value is assigned to max-stale, then the client is
+      willing to accept a stale response of any age.
+
+   If a cache returns a stale response, either because of a max-stale
+   directive on a request, or because the cache is configured to
+   override the expiration time of a response, the cache MUST attach a
+   Warning header to the stale response, using Warning 110 (Response is
+   stale).
+
+
+
+Fielding, et al.            Standards Track                   [Page 112]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A cache MAY be configured to return stale responses without
+   validation, but only if this does not conflict with any "MUST"-level
+   requirements concerning cache validation (e.g., a "must-revalidate"
+   cache-control directive).
+
+   If both the new request and the cached entry include "max-age"
+   directives, then the lesser of the two values is used for determining
+   the freshness of the cached entry for that request.
+
+14.9.4 Cache Revalidation and Reload Controls
+
+   Sometimes a user agent might want or need to insist that a cache
+   revalidate its cache entry with the origin server (and not just with
+   the next cache along the path to the origin server), or to reload its
+   cache entry from the origin server. End-to-end revalidation might be
+   necessary if either the cache or the origin server has overestimated
+   the expiration time of the cached response. End-to-end reload may be
+   necessary if the cache entry has become corrupted for some reason.
+
+   End-to-end revalidation may be requested either when the client does
+   not have its own local cached copy, in which case we call it
+   "unspecified end-to-end revalidation", or when the client does have a
+   local cached copy, in which case we call it "specific end-to-end
+   revalidation."
+
+   The client can specify these three kinds of action using Cache-
+   Control request directives:
+
+   End-to-end reload
+      The request includes a "no-cache" cache-control directive or, for
+      compatibility with HTTP/1.0 clients, "Pragma: no-cache". Field
+      names MUST NOT be included with the no-cache directive in a
+      request. The server MUST NOT use a cached copy when responding to
+      such a request.
+
+   Specific end-to-end revalidation
+      The request includes a "max-age=0" cache-control directive, which
+      forces each cache along the path to the origin server to
+      revalidate its own entry, if any, with the next cache or server.
+      The initial request includes a cache-validating conditional with
+      the client's current validator.
+
+   Unspecified end-to-end revalidation
+      The request includes "max-age=0" cache-control directive, which
+      forces each cache along the path to the origin server to
+      revalidate its own entry, if any, with the next cache or server.
+      The initial request does not include a cache-validating
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 113]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      conditional; the first cache along the path (if any) that holds a
+      cache entry for this resource includes a cache-validating
+      conditional with its current validator.
+
+   max-age
+      When an intermediate cache is forced, by means of a max-age=0
+      directive, to revalidate its own cache entry, and the client has
+      supplied its own validator in the request, the supplied validator
+      might differ from the validator currently stored with the cache
+      entry. In this case, the cache MAY use either validator in making
+      its own request without affecting semantic transparency.
+
+      However, the choice of validator might affect performance. The
+      best approach is for the intermediate cache to use its own
+      validator when making its request. If the server replies with 304
+      (Not Modified), then the cache can return its now validated copy
+      to the client with a 200 (OK) response. If the server replies with
+      a new entity and cache validator, however, the intermediate cache
+      can compare the returned validator with the one provided in the
+      client's request, using the strong comparison function. If the
+      client's validator is equal to the origin server's, then the
+      intermediate cache simply returns 304 (Not Modified). Otherwise,
+      it returns the new entity with a 200 (OK) response.
+
+      If a request includes the no-cache directive, it SHOULD NOT
+      include min-fresh, max-stale, or max-age.
+
+   only-if-cached
+      In some cases, such as times of extremely poor network
+      connectivity, a client may want a cache to return only those
+      responses that it currently has stored, and not to reload or
+      revalidate with the origin server. To do this, the client may
+      include the only-if-cached directive in a request. If it receives
+      this directive, a cache SHOULD either respond using a cached entry
+      that is consistent with the other constraints of the request, or
+      respond with a 504 (Gateway Timeout) status. However, if a group
+      of caches is being operated as a unified system with good internal
+      connectivity, such a request MAY be forwarded within that group of
+      caches.
+
+   must-revalidate
+      Because a cache MAY be configured to ignore a server's specified
+      expiration time, and because a client request MAY include a max-
+      stale directive (which has a similar effect), the protocol also
+      includes a mechanism for the origin server to require revalidation
+      of a cache entry on any subsequent use. When the must-revalidate
+      directive is present in a response received by a cache, that cache
+      MUST NOT use the entry after it becomes stale to respond to a
+
+
+
+Fielding, et al.            Standards Track                   [Page 114]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      subsequent request without first revalidating it with the origin
+      server. (I.e., the cache MUST do an end-to-end revalidation every
+      time, if, based solely on the origin server's Expires or max-age
+      value, the cached response is stale.)
+
+      The must-revalidate directive is necessary to support reliable
+      operation for certain protocol features. In all circumstances an
+      HTTP/1.1 cache MUST obey the must-revalidate directive; in
+      particular, if the cache cannot reach the origin server for any
+      reason, it MUST generate a 504 (Gateway Timeout) response.
+
+      Servers SHOULD send the must-revalidate directive if and only if
+      failure to revalidate a request on the entity could result in
+      incorrect operation, such as a silently unexecuted financial
+      transaction. Recipients MUST NOT take any automated action that
+      violates this directive, and MUST NOT automatically provide an
+      unvalidated copy of the entity if revalidation fails.
+
+      Although this is not recommended, user agents operating under
+      severe connectivity constraints MAY violate this directive but, if
+      so, MUST explicitly warn the user that an unvalidated response has
+      been provided. The warning MUST be provided on each unvalidated
+      access, and SHOULD require explicit user confirmation.
+
+   proxy-revalidate
+      The proxy-revalidate directive has the same meaning as the must-
+      revalidate directive, except that it does not apply to non-shared
+      user agent caches. It can be used on a response to an
+      authenticated request to permit the user's cache to store and
+      later return the response without needing to revalidate it (since
+      it has already been authenticated once by that user), while still
+      requiring proxies that service many users to revalidate each time
+      (in order to make sure that each user has been authenticated).
+      Note that such authenticated responses also need the public cache
+      control directive in order to allow them to be cached at all.
+
+14.9.5 No-Transform Directive
+
+   no-transform
+      Implementors of intermediate caches (proxies) have found it useful
+      to convert the media type of certain entity bodies. A non-
+      transparent proxy might, for example, convert between image
+      formats in order to save cache space or to reduce the amount of
+      traffic on a slow link.
+
+      Serious operational problems occur, however, when these
+      transformations are applied to entity bodies intended for certain
+      kinds of applications. For example, applications for medical
+
+
+
+Fielding, et al.            Standards Track                   [Page 115]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      imaging, scientific data analysis and those using end-to-end
+      authentication, all depend on receiving an entity body that is bit
+      for bit identical to the original entity-body.
+
+      Therefore, if a message includes the no-transform directive, an
+      intermediate cache or proxy MUST NOT change those headers that are
+      listed in section 13.5.2 as being subject to the no-transform
+      directive. This implies that the cache or proxy MUST NOT change
+      any aspect of the entity-body that is specified by these headers,
+      including the value of the entity-body itself.
+
+14.9.6 Cache Control Extensions
+
+   The Cache-Control header field can be extended through the use of one
+   or more cache-extension tokens, each with an optional assigned value.
+   Informational extensions (those which do not require a change in
+   cache behavior) MAY be added without changing the semantics of other
+   directives. Behavioral extensions are designed to work by acting as
+   modifiers to the existing base of cache directives. Both the new
+   directive and the standard directive are supplied, such that
+   applications which do not understand the new directive will default
+   to the behavior specified by the standard directive, and those that
+   understand the new directive will recognize it as modifying the
+   requirements associated with the standard directive. In this way,
+   extensions to the cache-control directives can be made without
+   requiring changes to the base protocol.
+
+   This extension mechanism depends on an HTTP cache obeying all of the
+   cache-control directives defined for its native HTTP-version, obeying
+   certain extensions, and ignoring all directives that it does not
+   understand.
+
+   For example, consider a hypothetical new response directive called
+   community which acts as a modifier to the private directive. We
+   define this new directive to mean that, in addition to any non-shared
+   cache, any cache which is shared only by members of the community
+   named within its value may cache the response. An origin server
+   wishing to allow the UCI community to use an otherwise private
+   response in their shared cache(s) could do so by including
+
+       Cache-Control: private, community="UCI"
+
+   A cache seeing this header field will act correctly even if the cache
+   does not understand the community cache-extension, since it will also
+   see and understand the private directive and thus default to the safe
+   behavior.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 116]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Unrecognized cache-directives MUST be ignored; it is assumed that any
+   cache-directive likely to be unrecognized by an HTTP/1.1 cache will
+   be combined with standard directives (or the response's default
+   cacheability) such that the cache behavior will remain minimally
+   correct even if the cache does not understand the extension(s).
+
+14.10 Connection
+
+   The Connection general-header field allows the sender to specify
+   options that are desired for that particular connection and MUST NOT
+   be communicated by proxies over further connections.
+
+   The Connection header has the following grammar:
+
+       Connection = "Connection" ":" 1#(connection-token)
+       connection-token  = token
+
+   HTTP/1.1 proxies MUST parse the Connection header field before a
+   message is forwarded and, for each connection-token in this field,
+   remove any header field(s) from the message with the same name as the
+   connection-token. Connection options are signaled by the presence of
+   a connection-token in the Connection header field, not by any
+   corresponding additional header field(s), since the additional header
+   field may not be sent if there are no parameters associated with that
+   connection option.
+
+   Message headers listed in the Connection header MUST NOT include
+   end-to-end headers, such as Cache-Control.
+
+   HTTP/1.1 defines the "close" connection option for the sender to
+   signal that the connection will be closed after completion of the
+   response. For example,
+
+       Connection: close
+
+   in either the request or the response header fields indicates that
+   the connection SHOULD NOT be considered `persistent' (section 8.1)
+   after the current request/response is complete.
+
+   HTTP/1.1 applications that do not support persistent connections MUST
+   include the "close" connection option in every message.
+
+   A system receiving an HTTP/1.0 (or lower-version) message that
+   includes a Connection header MUST, for each connection-token in this
+   field, remove and ignore any header field(s) from the message with
+   the same name as the connection-token. This protects against mistaken
+   forwarding of such header fields by pre-HTTP/1.1 proxies. See section
+   19.6.2.
+
+
+
+Fielding, et al.            Standards Track                   [Page 117]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.11 Content-Encoding
+
+   The Content-Encoding entity-header field is used as a modifier to the
+   media-type. When present, its value indicates what additional content
+   codings have been applied to the entity-body, and thus what decoding
+   mechanisms must be applied in order to obtain the media-type
+   referenced by the Content-Type header field. Content-Encoding is
+   primarily used to allow a document to be compressed without losing
+   the identity of its underlying media type.
+
+       Content-Encoding  = "Content-Encoding" ":" 1#content-coding
+
+   Content codings are defined in section 3.5. An example of its use is
+
+       Content-Encoding: gzip
+
+   The content-coding is a characteristic of the entity identified by
+   the Request-URI. Typically, the entity-body is stored with this
+   encoding and is only decoded before rendering or analogous usage.
+   However, a non-transparent proxy MAY modify the content-coding if the
+   new coding is known to be acceptable to the recipient, unless the
+   "no-transform" cache-control directive is present in the message.
+
+   If the content-coding of an entity is not "identity", then the
+   response MUST include a Content-Encoding entity-header (section
+   14.11) that lists the non-identity content-coding(s) used.
+
+   If the content-coding of an entity in a request message is not
+   acceptable to the origin server, the server SHOULD respond with a
+   status code of 415 (Unsupported Media Type).
+
+   If multiple encodings have been applied to an entity, the content
+   codings MUST be listed in the order in which they were applied.
+   Additional information about the encoding parameters MAY be provided
+   by other entity-header fields not defined by this specification.
+
+14.12 Content-Language
+
+   The Content-Language entity-header field describes the natural
+   language(s) of the intended audience for the enclosed entity. Note
+   that this might not be equivalent to all the languages used within
+   the entity-body.
+
+       Content-Language  = "Content-Language" ":" 1#language-tag
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 118]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Language tags are defined in section 3.10. The primary purpose of
+   Content-Language is to allow a user to identify and differentiate
+   entities according to the user's own preferred language. Thus, if the
+   body content is intended only for a Danish-literate audience, the
+   appropriate field is
+
+       Content-Language: da
+
+   If no Content-Language is specified, the default is that the content
+   is intended for all language audiences. This might mean that the
+   sender does not consider it to be specific to any natural language,
+   or that the sender does not know for which language it is intended.
+
+   Multiple languages MAY be listed for content that is intended for
+   multiple audiences. For example, a rendition of the "Treaty of
+   Waitangi," presented simultaneously in the original Maori and English
+   versions, would call for
+
+       Content-Language: mi, en
+
+   However, just because multiple languages are present within an entity
+   does not mean that it is intended for multiple linguistic audiences.
+   An example would be a beginner's language primer, such as "A First
+   Lesson in Latin," which is clearly intended to be used by an
+   English-literate audience. In this case, the Content-Language would
+   properly only include "en".
+
+   Content-Language MAY be applied to any media type -- it is not
+   limited to textual documents.
+
+14.13 Content-Length
+
+   The Content-Length entity-header field indicates the size of the
+   entity-body, in decimal number of OCTETs, sent to the recipient or,
+   in the case of the HEAD method, the size of the entity-body that
+   would have been sent had the request been a GET.
+
+       Content-Length    = "Content-Length" ":" 1*DIGIT
+
+   An example is
+
+       Content-Length: 3495
+
+   Applications SHOULD use this field to indicate the transfer-length of
+   the message-body, unless this is prohibited by the rules in section
+   4.4.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 119]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Any Content-Length greater than or equal to zero is a valid value.
+   Section 4.4 describes how to determine the length of a message-body
+   if a Content-Length is not given.
+
+   Note that the meaning of this field is significantly different from
+   the corresponding definition in MIME, where it is an optional field
+   used within the "message/external-body" content-type. In HTTP, it
+   SHOULD be sent whenever the message's length can be determined prior
+   to being transferred, unless this is prohibited by the rules in
+   section 4.4.
+
+14.14 Content-Location
+
+   The Content-Location entity-header field MAY be used to supply the
+   resource location for the entity enclosed in the message when that
+   entity is accessible from a location separate from the requested
+   resource's URI. A server SHOULD provide a Content-Location for the
+   variant corresponding to the response entity; especially in the case
+   where a resource has multiple entities associated with it, and those
+   entities actually have separate locations by which they might be
+   individually accessed, the server SHOULD provide a Content-Location
+   for the particular variant which is returned.
+
+       Content-Location = "Content-Location" ":"
+                         ( absoluteURI | relativeURI )
+
+   The value of Content-Location also defines the base URI for the
+   entity.
+
+   The Content-Location value is not a replacement for the original
+   requested URI; it is only a statement of the location of the resource
+   corresponding to this particular entity at the time of the request.
+   Future requests MAY specify the Content-Location URI as the request-
+   URI if the desire is to identify the source of that particular
+   entity.
+
+   A cache cannot assume that an entity with a Content-Location
+   different from the URI used to retrieve it can be used to respond to
+   later requests on that Content-Location URI. However, the Content-
+   Location can be used to differentiate between multiple entities
+   retrieved from a single requested resource, as described in section
+   13.6.
+
+   If the Content-Location is a relative URI, the relative URI is
+   interpreted relative to the Request-URI.
+
+   The meaning of the Content-Location header in PUT or POST requests is
+   undefined; servers are free to ignore it in those cases.
+
+
+
+Fielding, et al.            Standards Track                   [Page 120]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.15 Content-MD5
+
+   The Content-MD5 entity-header field, as defined in RFC 1864 [23], is
+   an MD5 digest of the entity-body for the purpose of providing an
+   end-to-end message integrity check (MIC) of the entity-body. (Note: a
+   MIC is good for detecting accidental modification of the entity-body
+   in transit, but is not proof against malicious attacks.)
+
+        Content-MD5   = "Content-MD5" ":" md5-digest
+        md5-digest   = <base64 of 128 bit MD5 digest as per RFC 1864>
+
+   The Content-MD5 header field MAY be generated by an origin server or
+   client to function as an integrity check of the entity-body. Only
+   origin servers or clients MAY generate the Content-MD5 header field;
+   proxies and gateways MUST NOT generate it, as this would defeat its
+   value as an end-to-end integrity check. Any recipient of the entity-
+   body, including gateways and proxies, MAY check that the digest value
+   in this header field matches that of the entity-body as received.
+
+   The MD5 digest is computed based on the content of the entity-body,
+   including any content-coding that has been applied, but not including
+   any transfer-encoding applied to the message-body. If the message is
+   received with a transfer-encoding, that encoding MUST be removed
+   prior to checking the Content-MD5 value against the received entity.
+
+   This has the result that the digest is computed on the octets of the
+   entity-body exactly as, and in the order that, they would be sent if
+   no transfer-encoding were being applied.
+
+   HTTP extends RFC 1864 to permit the digest to be computed for MIME
+   composite media-types (e.g., multipart/* and message/rfc822), but
+   this does not change how the digest is computed as defined in the
+   preceding paragraph.
+
+   There are several consequences of this. The entity-body for composite
+   types MAY contain many body-parts, each with its own MIME and HTTP
+   headers (including Content-MD5, Content-Transfer-Encoding, and
+   Content-Encoding headers). If a body-part has a Content-Transfer-
+   Encoding or Content-Encoding header, it is assumed that the content
+   of the body-part has had the encoding applied, and the body-part is
+   included in the Content-MD5 digest as is -- i.e., after the
+   application. The Transfer-Encoding header field is not allowed within
+   body-parts.
+
+   Conversion of all line breaks to CRLF MUST NOT be done before
+   computing or checking the digest: the line break convention used in
+   the text actually transmitted MUST be left unaltered when computing
+   the digest.
+
+
+
+Fielding, et al.            Standards Track                   [Page 121]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      Note: while the definition of Content-MD5 is exactly the same for
+      HTTP as in RFC 1864 for MIME entity-bodies, there are several ways
+      in which the application of Content-MD5 to HTTP entity-bodies
+      differs from its application to MIME entity-bodies. One is that
+      HTTP, unlike MIME, does not use Content-Transfer-Encoding, and
+      does use Transfer-Encoding and Content-Encoding. Another is that
+      HTTP more frequently uses binary content types than MIME, so it is
+      worth noting that, in such cases, the byte order used to compute
+      the digest is the transmission byte order defined for the type.
+      Lastly, HTTP allows transmission of text types with any of several
+      line break conventions and not just the canonical form using CRLF.
+
+14.16 Content-Range
+
+   The Content-Range entity-header is sent with a partial entity-body to
+   specify where in the full entity-body the partial body should be
+   applied. Range units are defined in section 3.12.
+
+       Content-Range = "Content-Range" ":" content-range-spec
+
+       content-range-spec      = byte-content-range-spec
+       byte-content-range-spec = bytes-unit SP
+                                 byte-range-resp-spec "/"
+                                 ( instance-length | "*" )
+
+       byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
+                                      | "*"
+       instance-length           = 1*DIGIT
+
+   The header SHOULD indicate the total length of the full entity-body,
+   unless this length is unknown or difficult to determine. The asterisk
+   "*" character means that the instance-length is unknown at the time
+   when the response was generated.
+
+   Unlike byte-ranges-specifier values (see section 14.35.1), a byte-
+   range-resp-spec MUST only specify one range, and MUST contain
+   absolute byte positions for both the first and last byte of the
+   range.
+
+   A byte-content-range-spec with a byte-range-resp-spec whose last-
+   byte-pos value is less than its first-byte-pos value, or whose
+   instance-length value is less than or equal to its last-byte-pos
+   value, is invalid. The recipient of an invalid byte-content-range-
+   spec MUST ignore it and any content transferred along with it.
+
+   A server sending a response with status code 416 (Requested range not
+   satisfiable) SHOULD include a Content-Range field with a byte-range-
+   resp-spec of "*". The instance-length specifies the current length of
+
+
+
+Fielding, et al.            Standards Track                   [Page 122]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the selected resource. A response with status code 206 (Partial
+   Content) MUST NOT include a Content-Range field with a byte-range-
+   resp-spec of "*".
+
+   Examples of byte-content-range-spec values, assuming that the entity
+   contains a total of 1234 bytes:
+
+      . The first 500 bytes:
+       bytes 0-499/1234
+
+      . The second 500 bytes:
+       bytes 500-999/1234
+
+      . All except for the first 500 bytes:
+       bytes 500-1233/1234
+
+      . The last 500 bytes:
+       bytes 734-1233/1234
+
+   When an HTTP message includes the content of a single range (for
+   example, a response to a request for a single range, or to a request
+   for a set of ranges that overlap without any holes), this content is
+   transmitted with a Content-Range header, and a Content-Length header
+   showing the number of bytes actually transferred. For example,
+
+       HTTP/1.1 206 Partial content
+       Date: Wed, 15 Nov 1995 06:25:24 GMT
+       Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+       Content-Range: bytes 21010-47021/47022
+       Content-Length: 26012
+       Content-Type: image/gif
+
+   When an HTTP message includes the content of multiple ranges (for
+   example, a response to a request for multiple non-overlapping
+   ranges), these are transmitted as a multipart message. The multipart
+   media type used for this purpose is "multipart/byteranges" as defined
+   in appendix 19.2. See appendix 19.6.3 for a compatibility issue.
+
+   A response to a request for a single range MUST NOT be sent using the
+   multipart/byteranges media type.  A response to a request for
+   multiple ranges, whose result is a single range, MAY be sent as a
+   multipart/byteranges media type with one part. A client that cannot
+   decode a multipart/byteranges message MUST NOT ask for multiple
+   byte-ranges in a single request.
+
+   When a client requests multiple byte-ranges in one request, the
+   server SHOULD return them in the order that they appeared in the
+   request.
+
+
+
+Fielding, et al.            Standards Track                   [Page 123]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the server ignores a byte-range-spec because it is syntactically
+   invalid, the server SHOULD treat the request as if the invalid Range
+   header field did not exist. (Normally, this means return a 200
+   response containing the full entity).
+
+   If the server receives a request (other than one including an If-
+   Range request-header field) with an unsatisfiable Range request-
+   header field (that is, all of whose byte-range-spec values have a
+   first-byte-pos value greater than the current length of the selected
+   resource), it SHOULD return a response code of 416 (Requested range
+   not satisfiable) (section 10.4.17).
+
+      Note: clients cannot depend on servers to send a 416 (Requested
+      range not satisfiable) response instead of a 200 (OK) response for
+      an unsatisfiable Range request-header, since not all servers
+      implement this request-header.
+
+14.17 Content-Type
+
+   The Content-Type entity-header field indicates the media type of the
+   entity-body sent to the recipient or, in the case of the HEAD method,
+   the media type that would have been sent had the request been a GET.
+
+       Content-Type   = "Content-Type" ":" media-type
+
+   Media types are defined in section 3.7. An example of the field is
+
+       Content-Type: text/html; charset=ISO-8859-4
+
+   Further discussion of methods for identifying the media type of an
+   entity is provided in section 7.2.1.
+
+14.18 Date
+
+   The Date general-header field represents the date and time at which
+   the message was originated, having the same semantics as orig-date in
+   RFC 822. The field value is an HTTP-date, as described in section
+   3.3.1; it MUST be sent in RFC 1123 [8]-date format.
+
+       Date  = "Date" ":" HTTP-date
+
+   An example is
+
+       Date: Tue, 15 Nov 1994 08:12:31 GMT
+
+   Origin servers MUST include a Date header field in all responses,
+   except in these cases:
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 124]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      1. If the response status code is 100 (Continue) or 101 (Switching
+         Protocols), the response MAY include a Date header field, at
+         the server's option.
+
+      2. If the response status code conveys a server error, e.g. 500
+         (Internal Server Error) or 503 (Service Unavailable), and it is
+         inconvenient or impossible to generate a valid Date.
+
+      3. If the server does not have a clock that can provide a
+         reasonable approximation of the current time, its responses
+         MUST NOT include a Date header field. In this case, the rules
+         in section 14.18.1 MUST be followed.
+
+   A received message that does not have a Date header field MUST be
+   assigned one by the recipient if the message will be cached by that
+   recipient or gatewayed via a protocol which requires a Date. An HTTP
+   implementation without a clock MUST NOT cache responses without
+   revalidating them on every use. An HTTP cache, especially a shared
+   cache, SHOULD use a mechanism, such as NTP [28], to synchronize its
+   clock with a reliable external standard.
+
+   Clients SHOULD only send a Date header field in messages that include
+   an entity-body, as in the case of the PUT and POST requests, and even
+   then it is optional. A client without a clock MUST NOT send a Date
+   header field in a request.
+
+   The HTTP-date sent in a Date header SHOULD NOT represent a date and
+   time subsequent to the generation of the message. It SHOULD represent
+   the best available approximation of the date and time of message
+   generation, unless the implementation has no means of generating a
+   reasonably accurate date and time. In theory, the date ought to
+   represent the moment just before the entity is generated. In
+   practice, the date can be generated at any time during the message
+   origination without affecting its semantic value.
+
+14.18.1 Clockless Origin Server Operation
+
+   Some origin server implementations might not have a clock available.
+   An origin server without a clock MUST NOT assign Expires or Last-
+   Modified values to a response, unless these values were associated
+   with the resource by a system or user with a reliable clock. It MAY
+   assign an Expires value that is known, at or before server
+   configuration time, to be in the past (this allows "pre-expiration"
+   of responses without storing separate Expires values for each
+   resource).
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 125]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.19 ETag
+
+   The ETag response-header field provides the current value of the
+   entity tag for the requested variant. The headers used with entity
+   tags are described in sections 14.24, 14.26 and 14.44. The entity tag
+   MAY be used for comparison with other entities from the same resource
+   (see section 13.3.3).
+
+      ETag = "ETag" ":" entity-tag
+
+   Examples:
+
+      ETag: "xyzzy"
+      ETag: W/"xyzzy"
+      ETag: ""
+
+14.20 Expect
+
+   The Expect request-header field is used to indicate that particular
+   server behaviors are required by the client.
+
+      Expect       =  "Expect" ":" 1#expectation
+
+      expectation  =  "100-continue" | expectation-extension
+      expectation-extension =  token [ "=" ( token | quoted-string )
+                               *expect-params ]
+      expect-params =  ";" token [ "=" ( token | quoted-string ) ]
+
+
+   A server that does not understand or is unable to comply with any of
+   the expectation values in the Expect field of a request MUST respond
+   with appropriate error status. The server MUST respond with a 417
+   (Expectation Failed) status if any of the expectations cannot be met
+   or, if there are other problems with the request, some other 4xx
+   status.
+
+   This header field is defined with extensible syntax to allow for
+   future extensions. If a server receives a request containing an
+   Expect field that includes an expectation-extension that it does not
+   support, it MUST respond with a 417 (Expectation Failed) status.
+
+   Comparison of expectation values is case-insensitive for unquoted
+   tokens (including the 100-continue token), and is case-sensitive for
+   quoted-string expectation-extensions.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 126]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
+   return a 417 (Expectation Failed) status if it receives a request
+   with an expectation that it cannot meet. However, the Expect
+   request-header itself is end-to-end; it MUST be forwarded if the
+   request is forwarded.
+
+   Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
+   Expect header.
+
+   See section 8.2.3 for the use of the 100 (continue) status.
+
+14.21 Expires
+
+   The Expires entity-header field gives the date/time after which the
+   response is considered stale. A stale cache entry may not normally be
+   returned by a cache (either a proxy cache or a user agent cache)
+   unless it is first validated with the origin server (or with an
+   intermediate cache that has a fresh copy of the entity). See section
+   13.2 for further discussion of the expiration model.
+
+   The presence of an Expires field does not imply that the original
+   resource will change or cease to exist at, before, or after that
+   time.
+
+   The format is an absolute date and time as defined by HTTP-date in
+   section 3.3.1; it MUST be in RFC 1123 date format:
+
+      Expires = "Expires" ":" HTTP-date
+
+   An example of its use is
+
+      Expires: Thu, 01 Dec 1994 16:00:00 GMT
+
+      Note: if a response includes a Cache-Control field with the max-
+      age directive (see section 14.9.3), that directive overrides the
+      Expires field.
+
+   HTTP/1.1 clients and caches MUST treat other invalid date formats,
+   especially including the value "0", as in the past (i.e., "already
+   expired").
+
+   To mark a response as "already expired," an origin server sends an
+   Expires date that is equal to the Date header value. (See the rules
+   for expiration calculations in section 13.2.4.)
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 127]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   To mark a response as "never expires," an origin server sends an
+   Expires date approximately one year from the time the response is
+   sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
+   year in the future.
+
+   The presence of an Expires header field with a date value of some
+   time in the future on a response that otherwise would by default be
+   non-cacheable indicates that the response is cacheable, unless
+   indicated otherwise by a Cache-Control header field (section 14.9).
+
+14.22 From
+
+   The From request-header field, if given, SHOULD contain an Internet
+   e-mail address for the human user who controls the requesting user
+   agent. The address SHOULD be machine-usable, as defined by "mailbox"
+   in RFC 822 [9] as updated by RFC 1123 [8]:
+
+       From   = "From" ":" mailbox
+
+   An example is:
+
+       From: webmaster@w3.org
+
+   This header field MAY be used for logging purposes and as a means for
+   identifying the source of invalid or unwanted requests. It SHOULD NOT
+   be used as an insecure form of access protection. The interpretation
+   of this field is that the request is being performed on behalf of the
+   person given, who accepts responsibility for the method performed. In
+   particular, robot agents SHOULD include this header so that the
+   person responsible for running the robot can be contacted if problems
+   occur on the receiving end.
+
+   The Internet e-mail address in this field MAY be separate from the
+   Internet host which issued the request. For example, when a request
+   is passed through a proxy the original issuer's address SHOULD be
+   used.
+
+   The client SHOULD NOT send the From header field without the user's
+   approval, as it might conflict with the user's privacy interests or
+   their site's security policy. It is strongly recommended that the
+   user be able to disable, enable, and modify the value of this field
+   at any time prior to a request.
+
+14.23 Host
+
+   The Host request-header field specifies the Internet host and port
+   number of the resource being requested, as obtained from the original
+   URI given by the user or referring resource (generally an HTTP URL,
+
+
+
+Fielding, et al.            Standards Track                   [Page 128]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   as described in section 3.2.2). The Host field value MUST represent
+   the naming authority of the origin server or gateway given by the
+   original URL. This allows the origin server or gateway to
+   differentiate between internally-ambiguous URLs, such as the root "/"
+   URL of a server for multiple host names on a single IP address.
+
+       Host = "Host" ":" host [ ":" port ] ; Section 3.2.2
+
+   A "host" without any trailing port information implies the default
+   port for the service requested (e.g., "80" for an HTTP URL). For
+   example, a request on the origin server for
+   <http://www.w3.org/pub/WWW/> would properly include:
+
+       GET /pub/WWW/ HTTP/1.1
+       Host: www.w3.org
+
+   A client MUST include a Host header field in all HTTP/1.1 request
+   messages . If the requested URI does not include an Internet host
+   name for the service being requested, then the Host header field MUST
+   be given with an empty value. An HTTP/1.1 proxy MUST ensure that any
+   request message it forwards does contain an appropriate Host header
+   field that identifies the service being requested by the proxy. All
+   Internet-based HTTP/1.1 servers MUST respond with a 400 (Bad Request)
+   status code to any HTTP/1.1 request message which lacks a Host header
+   field.
+
+   See sections 5.2 and 19.6.1.1 for other requirements relating to
+   Host.
+
+14.24 If-Match
+
+   The If-Match request-header field is used with a method to make it
+   conditional. A client that has one or more entities previously
+   obtained from the resource can verify that one of those entities is
+   current by including a list of their associated entity tags in the
+   If-Match header field. Entity tags are defined in section 3.11. The
+   purpose of this feature is to allow efficient updates of cached
+   information with a minimum amount of transaction overhead. It is also
+   used, on updating requests, to prevent inadvertent modification of
+   the wrong version of a resource. As a special case, the value "*"
+   matches any current entity of the resource.
+
+       If-Match = "If-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-Match header) on that resource, or if "*" is given
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 129]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   and any current entity exists for that resource, then the server MAY
+   perform the requested method as if the If-Match header field did not
+   exist.
+
+   A server MUST use the strong comparison function (see section 13.3.3)
+   to compare the entity tags in If-Match.
+
+   If none of the entity tags match, or if "*" is given and no current
+   entity exists, the server MUST NOT perform the requested method, and
+   MUST return a 412 (Precondition Failed) response. This behavior is
+   most useful when the client wants to prevent an updating method, such
+   as PUT, from modifying a resource that has changed since the client
+   last retrieved it.
+
+   If the request would, without the If-Match header field, result in
+   anything other than a 2xx or 412 status, then the If-Match header
+   MUST be ignored.
+
+   The meaning of "If-Match: *" is that the method SHOULD be performed
+   if the representation selected by the origin server (or by a cache,
+   possibly using the Vary mechanism, see section 14.44) exists, and
+   MUST NOT be performed if the representation does not exist.
+
+   A request intended to update a resource (e.g., a PUT) MAY include an
+   If-Match header field to signal that the request method MUST NOT be
+   applied if the entity corresponding to the If-Match value (a single
+   entity tag) is no longer a representation of that resource. This
+   allows the user to indicate that they do not wish the request to be
+   successful if the resource has been changed without their knowledge.
+   Examples:
+
+       If-Match: "xyzzy"
+       If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+       If-Match: *
+
+   The result of a request having both an If-Match header field and
+   either an If-None-Match or an If-Modified-Since header fields is
+   undefined by this specification.
+
+14.25 If-Modified-Since
+
+   The If-Modified-Since request-header field is used with a method to
+   make it conditional: if the requested variant has not been modified
+   since the time specified in this field, an entity will not be
+   returned from the server; instead, a 304 (not modified) response will
+   be returned without any message-body.
+
+       If-Modified-Since = "If-Modified-Since" ":" HTTP-date
+
+
+
+Fielding, et al.            Standards Track                   [Page 130]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   An example of the field is:
+
+       If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+   A GET method with an If-Modified-Since header and no Range header
+   requests that the identified entity be transferred only if it has
+   been modified since the date given by the If-Modified-Since header.
+   The algorithm for determining this includes the following cases:
+
+      a) If the request would normally result in anything other than a
+         200 (OK) status, or if the passed If-Modified-Since date is
+         invalid, the response is exactly the same as for a normal GET.
+         A date which is later than the server's current time is
+         invalid.
+
+      b) If the variant has been modified since the If-Modified-Since
+         date, the response is exactly the same as for a normal GET.
+
+      c) If the variant has not been modified since a valid If-
+         Modified-Since date, the server SHOULD return a 304 (Not
+         Modified) response.
+
+   The purpose of this feature is to allow efficient updates of cached
+   information with a minimum amount of transaction overhead.
+
+      Note: The Range request-header field modifies the meaning of If-
+      Modified-Since; see section 14.35 for full details.
+
+      Note: If-Modified-Since times are interpreted by the server, whose
+      clock might not be synchronized with the client.
+
+      Note: When handling an If-Modified-Since header field, some
+      servers will use an exact date comparison function, rather than a
+      less-than function, for deciding whether to send a 304 (Not
+      Modified) response. To get best results when sending an If-
+      Modified-Since header field for cache validation, clients are
+      advised to use the exact date string received in a previous Last-
+      Modified header field whenever possible.
+
+      Note: If a client uses an arbitrary date in the If-Modified-Since
+      header instead of a date taken from the Last-Modified header for
+      the same request, the client should be aware of the fact that this
+      date is interpreted in the server's understanding of time. The
+      client should consider unsynchronized clocks and rounding problems
+      due to the different encodings of time between the client and
+      server. This includes the possibility of race conditions if the
+      document has changed between the time it was first requested and
+      the If-Modified-Since date of a subsequent request, and the
+
+
+
+Fielding, et al.            Standards Track                   [Page 131]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      possibility of clock-skew-related problems if the If-Modified-
+      Since date is derived from the client's clock without correction
+      to the server's clock. Corrections for different time bases
+      between client and server are at best approximate due to network
+      latency.
+
+   The result of a request having both an If-Modified-Since header field
+   and either an If-Match or an If-Unmodified-Since header fields is
+   undefined by this specification.
+
+14.26 If-None-Match
+
+   The If-None-Match request-header field is used with a method to make
+   it conditional. A client that has one or more entities previously
+   obtained from the resource can verify that none of those entities is
+   current by including a list of their associated entity tags in the
+   If-None-Match header field. The purpose of this feature is to allow
+   efficient updates of cached information with a minimum amount of
+   transaction overhead. It is also used to prevent a method (e.g. PUT)
+   from inadvertently modifying an existing resource when the client
+   believes that the resource does not exist.
+
+   As a special case, the value "*" matches any current entity of the
+   resource.
+
+       If-None-Match = "If-None-Match" ":" ( "*" | 1#entity-tag )
+
+   If any of the entity tags match the entity tag of the entity that
+   would have been returned in the response to a similar GET request
+   (without the If-None-Match header) on that resource, or if "*" is
+   given and any current entity exists for that resource, then the
+   server MUST NOT perform the requested method, unless required to do
+   so because the resource's modification date fails to match that
+   supplied in an If-Modified-Since header field in the request.
+   Instead, if the request method was GET or HEAD, the server SHOULD
+   respond with a 304 (Not Modified) response, including the cache-
+   related header fields (particularly ETag) of one of the entities that
+   matched. For all other request methods, the server MUST respond with
+   a status of 412 (Precondition Failed).
+
+   See section 13.3.3 for rules on how to determine if two entities tags
+   match. The weak comparison function can only be used with GET or HEAD
+   requests.
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 132]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If none of the entity tags match, then the server MAY perform the
+   requested method as if the If-None-Match header field did not exist,
+   but MUST also ignore any If-Modified-Since header field(s) in the
+   request. That is, if no entity tags match, then the server MUST NOT
+   return a 304 (Not Modified) response.
+
+   If the request would, without the If-None-Match header field, result
+   in anything other than a 2xx or 304 status, then the If-None-Match
+   header MUST be ignored. (See section 13.3.4 for a discussion of
+   server behavior when both If-Modified-Since and If-None-Match appear
+   in the same request.)
+
+   The meaning of "If-None-Match: *" is that the method MUST NOT be
+   performed if the representation selected by the origin server (or by
+   a cache, possibly using the Vary mechanism, see section 14.44)
+   exists, and SHOULD be performed if the representation does not exist.
+   This feature is intended to be useful in preventing races between PUT
+   operations.
+
+   Examples:
+
+       If-None-Match: "xyzzy"
+       If-None-Match: W/"xyzzy"
+       If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
+       If-None-Match: W/"xyzzy", W/"r2d2xxxx", W/"c3piozzzz"
+       If-None-Match: *
+
+   The result of a request having both an If-None-Match header field and
+   either an If-Match or an If-Unmodified-Since header fields is
+   undefined by this specification.
+
+14.27 If-Range
+
+   If a client has a partial copy of an entity in its cache, and wishes
+   to have an up-to-date copy of the entire entity in its cache, it
+   could use the Range request-header with a conditional GET (using
+   either or both of If-Unmodified-Since and If-Match.) However, if the
+   condition fails because the entity has been modified, the client
+   would then have to make a second request to obtain the entire current
+   entity-body.
+
+   The If-Range header allows a client to "short-circuit" the second
+   request. Informally, its meaning is `if the entity is unchanged, send
+   me the part(s) that I am missing; otherwise, send me the entire new
+   entity'.
+
+        If-Range = "If-Range" ":" ( entity-tag | HTTP-date )
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 133]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the client has no entity tag for an entity, but does have a Last-
+   Modified date, it MAY use that date in an If-Range header. (The
+   server can distinguish between a valid HTTP-date and any form of
+   entity-tag by examining no more than two characters.) The If-Range
+   header SHOULD only be used together with a Range header, and MUST be
+   ignored if the request does not include a Range header, or if the
+   server does not support the sub-range operation.
+
+   If the entity tag given in the If-Range header matches the current
+   entity tag for the entity, then the server SHOULD provide the
+   specified sub-range of the entity using a 206 (Partial content)
+   response. If the entity tag does not match, then the server SHOULD
+   return the entire entity using a 200 (OK) response.
+
+14.28 If-Unmodified-Since
+
+   The If-Unmodified-Since request-header field is used with a method to
+   make it conditional. If the requested resource has not been modified
+   since the time specified in this field, the server SHOULD perform the
+   requested operation as if the If-Unmodified-Since header were not
+   present.
+
+   If the requested variant has been modified since the specified time,
+   the server MUST NOT perform the requested operation, and MUST return
+   a 412 (Precondition Failed).
+
+      If-Unmodified-Since = "If-Unmodified-Since" ":" HTTP-date
+
+   An example of the field is:
+
+       If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT
+
+   If the request normally (i.e., without the If-Unmodified-Since
+   header) would result in anything other than a 2xx or 412 status, the
+   If-Unmodified-Since header SHOULD be ignored.
+
+   If the specified date is invalid, the header is ignored.
+
+   The result of a request having both an If-Unmodified-Since header
+   field and either an If-None-Match or an If-Modified-Since header
+   fields is undefined by this specification.
+
+14.29 Last-Modified
+
+   The Last-Modified entity-header field indicates the date and time at
+   which the origin server believes the variant was last modified.
+
+       Last-Modified  = "Last-Modified" ":" HTTP-date
+
+
+
+Fielding, et al.            Standards Track                   [Page 134]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   An example of its use is
+
+       Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
+
+   The exact meaning of this header field depends on the implementation
+   of the origin server and the nature of the original resource. For
+   files, it may be just the file system last-modified time. For
+   entities with dynamically included parts, it may be the most recent
+   of the set of last-modify times for its component parts. For database
+   gateways, it may be the last-update time stamp of the record. For
+   virtual objects, it may be the last time the internal state changed.
+
+   An origin server MUST NOT send a Last-Modified date which is later
+   than the server's time of message origination. In such cases, where
+   the resource's last modification would indicate some time in the
+   future, the server MUST replace that date with the message
+   origination date.
+
+   An origin server SHOULD obtain the Last-Modified value of the entity
+   as close as possible to the time that it generates the Date value of
+   its response. This allows a recipient to make an accurate assessment
+   of the entity's modification time, especially if the entity changes
+   near the time that the response is generated.
+
+   HTTP/1.1 servers SHOULD send Last-Modified whenever feasible.
+
+14.30 Location
+
+   The Location response-header field is used to redirect the recipient
+   to a location other than the Request-URI for completion of the
+   request or identification of a new resource. For 201 (Created)
+   responses, the Location is that of the new resource which was created
+   by the request. For 3xx responses, the location SHOULD indicate the
+   server's preferred URI for automatic redirection to the resource. The
+   field value consists of a single absolute URI.
+
+       Location       = "Location" ":" absoluteURI
+
+   An example is:
+
+       Location: http://www.w3.org/pub/WWW/People.html
+
+      Note: The Content-Location header field (section 14.14) differs
+      from Location in that the Content-Location identifies the original
+      location of the entity enclosed in the request. It is therefore
+      possible for a response to contain header fields for both Location
+      and Content-Location. Also see section 13.10 for cache
+      requirements of some methods.
+
+
+
+Fielding, et al.            Standards Track                   [Page 135]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.31 Max-Forwards
+
+   The Max-Forwards request-header field provides a mechanism with the
+   TRACE (section 9.8) and OPTIONS (section 9.2) methods to limit the
+   number of proxies or gateways that can forward the request to the
+   next inbound server. This can be useful when the client is attempting
+   to trace a request chain which appears to be failing or looping in
+   mid-chain.
+
+       Max-Forwards   = "Max-Forwards" ":" 1*DIGIT
+
+   The Max-Forwards value is a decimal integer indicating the remaining
+   number of times this request message may be forwarded.
+
+   Each proxy or gateway recipient of a TRACE or OPTIONS request
+   containing a Max-Forwards header field MUST check and update its
+   value prior to forwarding the request. If the received value is zero
+   (0), the recipient MUST NOT forward the request; instead, it MUST
+   respond as the final recipient. If the received Max-Forwards value is
+   greater than zero, then the forwarded message MUST contain an updated
+   Max-Forwards field with a value decremented by one (1).
+
+   The Max-Forwards header field MAY be ignored for all other methods
+   defined by this specification and for any extension methods for which
+   it is not explicitly referred to as part of that method definition.
+
+14.32 Pragma
+
+   The Pragma general-header field is used to include implementation-
+   specific directives that might apply to any recipient along the
+   request/response chain. All pragma directives specify optional
+   behavior from the viewpoint of the protocol; however, some systems
+   MAY require that behavior be consistent with the directives.
+
+       Pragma            = "Pragma" ":" 1#pragma-directive
+       pragma-directive  = "no-cache" | extension-pragma
+       extension-pragma  = token [ "=" ( token | quoted-string ) ]
+
+   When the no-cache directive is present in a request message, an
+   application SHOULD forward the request toward the origin server even
+   if it has a cached copy of what is being requested. This pragma
+   directive has the same semantics as the no-cache cache-directive (see
+   section 14.9) and is defined here for backward compatibility with
+   HTTP/1.0. Clients SHOULD include both header fields when a no-cache
+   request is sent to a server not known to be HTTP/1.1 compliant.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 136]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Pragma directives MUST be passed through by a proxy or gateway
+   application, regardless of their significance to that application,
+   since the directives might be applicable to all recipients along the
+   request/response chain. It is not possible to specify a pragma for a
+   specific recipient; however, any pragma directive not relevant to a
+   recipient SHOULD be ignored by that recipient.
+
+   HTTP/1.1 caches SHOULD treat "Pragma: no-cache" as if the client had
+   sent "Cache-Control: no-cache". No new Pragma directives will be
+   defined in HTTP.
+
+      Note: because the meaning of "Pragma: no-cache as a response
+      header field is not actually specified, it does not provide a
+      reliable replacement for "Cache-Control: no-cache" in a response
+
+14.33 Proxy-Authenticate
+
+   The Proxy-Authenticate response-header field MUST be included as part
+   of a 407 (Proxy Authentication Required) response. The field value
+   consists of a challenge that indicates the authentication scheme and
+   parameters applicable to the proxy for this Request-URI.
+
+       Proxy-Authenticate  = "Proxy-Authenticate" ":" 1#challenge
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. Unlike
+   WWW-Authenticate, the Proxy-Authenticate header field applies only to
+   the current connection and SHOULD NOT be passed on to downstream
+   clients. However, an intermediate proxy might need to obtain its own
+   credentials by requesting them from the downstream client, which in
+   some circumstances will appear as if the proxy is forwarding the
+   Proxy-Authenticate header field.
+
+14.34 Proxy-Authorization
+
+   The Proxy-Authorization request-header field allows the client to
+   identify itself (or its user) to a proxy which requires
+   authentication. The Proxy-Authorization field value consists of
+   credentials containing the authentication information of the user
+   agent for the proxy and/or realm of the resource being requested.
+
+       Proxy-Authorization     = "Proxy-Authorization" ":" credentials
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43] . Unlike
+   Authorization, the Proxy-Authorization header field applies only to
+   the next outbound proxy that demanded authentication using the Proxy-
+   Authenticate field. When multiple proxies are used in a chain, the
+
+
+
+Fielding, et al.            Standards Track                   [Page 137]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Proxy-Authorization header field is consumed by the first outbound
+   proxy that was expecting to receive credentials. A proxy MAY relay
+   the credentials from the client request to the next proxy if that is
+   the mechanism by which the proxies cooperatively authenticate a given
+   request.
+
+14.35 Range
+
+14.35.1 Byte Ranges
+
+   Since all HTTP entities are represented in HTTP messages as sequences
+   of bytes, the concept of a byte range is meaningful for any HTTP
+   entity. (However, not all clients and servers need to support byte-
+   range operations.)
+
+   Byte range specifications in HTTP apply to the sequence of bytes in
+   the entity-body (not necessarily the same as the message-body).
+
+   A byte range operation MAY specify a single range of bytes, or a set
+   of ranges within a single entity.
+
+       ranges-specifier = byte-ranges-specifier
+       byte-ranges-specifier = bytes-unit "=" byte-range-set
+       byte-range-set  = 1#( byte-range-spec | suffix-byte-range-spec )
+       byte-range-spec = first-byte-pos "-" [last-byte-pos]
+       first-byte-pos  = 1*DIGIT
+       last-byte-pos   = 1*DIGIT
+
+   The first-byte-pos value in a byte-range-spec gives the byte-offset
+   of the first byte in a range. The last-byte-pos value gives the
+   byte-offset of the last byte in the range; that is, the byte
+   positions specified are inclusive. Byte offsets start at zero.
+
+   If the last-byte-pos value is present, it MUST be greater than or
+   equal to the first-byte-pos in that byte-range-spec, or the byte-
+   range-spec is syntactically invalid. The recipient of a byte-range-
+   set that includes one or more syntactically invalid byte-range-spec
+   values MUST ignore the header field that includes that byte-range-
+   set.
+
+   If the last-byte-pos value is absent, or if the value is greater than
+   or equal to the current length of the entity-body, last-byte-pos is
+   taken to be equal to one less than the current length of the entity-
+   body in bytes.
+
+   By its choice of last-byte-pos, a client can limit the number of
+   bytes retrieved without knowing the size of the entity.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 138]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       suffix-byte-range-spec = "-" suffix-length
+       suffix-length = 1*DIGIT
+
+   A suffix-byte-range-spec is used to specify the suffix of the
+   entity-body, of a length given by the suffix-length value. (That is,
+   this form specifies the last N bytes of an entity-body.) If the
+   entity is shorter than the specified suffix-length, the entire
+   entity-body is used.
+
+   If a syntactically valid byte-range-set includes at least one byte-
+   range-spec whose first-byte-pos is less than the current length of
+   the entity-body, or at least one suffix-byte-range-spec with a non-
+   zero suffix-length, then the byte-range-set is satisfiable.
+   Otherwise, the byte-range-set is unsatisfiable. If the byte-range-set
+   is unsatisfiable, the server SHOULD return a response with a status
+   of 416 (Requested range not satisfiable). Otherwise, the server
+   SHOULD return a response with a status of 206 (Partial Content)
+   containing the satisfiable ranges of the entity-body.
+
+   Examples of byte-ranges-specifier values (assuming an entity-body of
+   length 10000):
+
+      - The first 500 bytes (byte offsets 0-499, inclusive):  bytes=0-
+        499
+
+      - The second 500 bytes (byte offsets 500-999, inclusive):
+        bytes=500-999
+
+      - The final 500 bytes (byte offsets 9500-9999, inclusive):
+        bytes=-500
+
+      - Or bytes=9500-
+
+      - The first and last bytes only (bytes 0 and 9999):  bytes=0-0,-1
+
+      - Several legal but not canonical specifications of the second 500
+        bytes (byte offsets 500-999, inclusive):
+         bytes=500-600,601-999
+         bytes=500-700,601-999
+
+14.35.2 Range Retrieval Requests
+
+   HTTP retrieval requests using conditional or unconditional GET
+   methods MAY request one or more sub-ranges of the entity, instead of
+   the entire entity, using the Range request header, which applies to
+   the entity returned as the result of the request:
+
+      Range = "Range" ":" ranges-specifier
+
+
+
+Fielding, et al.            Standards Track                   [Page 139]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   A server MAY ignore the Range header. However, HTTP/1.1 origin
+   servers and intermediate caches ought to support byte ranges when
+   possible, since Range supports efficient recovery from partially
+   failed transfers, and supports efficient partial retrieval of large
+   entities.
+
+   If the server supports the Range header and the specified range or
+   ranges are appropriate for the entity:
+
+      - The presence of a Range header in an unconditional GET modifies
+        what is returned if the GET is otherwise successful. In other
+        words, the response carries a status code of 206 (Partial
+        Content) instead of 200 (OK).
+
+      - The presence of a Range header in a conditional GET (a request
+        using one or both of If-Modified-Since and If-None-Match, or
+        one or both of If-Unmodified-Since and If-Match) modifies what
+        is returned if the GET is otherwise successful and the
+        condition is true. It does not affect the 304 (Not Modified)
+        response returned if the conditional is false.
+
+   In some cases, it might be more appropriate to use the If-Range
+   header (see section 14.27) in addition to the Range header.
+
+   If a proxy that supports ranges receives a Range request, forwards
+   the request to an inbound server, and receives an entire entity in
+   reply, it SHOULD only return the requested range to its client. It
+   SHOULD store the entire received response in its cache if that is
+   consistent with its cache allocation policies.
+
+14.36 Referer
+
+   The Referer[sic] request-header field allows the client to specify,
+   for the server's benefit, the address (URI) of the resource from
+   which the Request-URI was obtained (the "referrer", although the
+   header field is misspelled.) The Referer request-header allows a
+   server to generate lists of back-links to resources for interest,
+   logging, optimized caching, etc. It also allows obsolete or mistyped
+   links to be traced for maintenance. The Referer field MUST NOT be
+   sent if the Request-URI was obtained from a source that does not have
+   its own URI, such as input from the user keyboard.
+
+       Referer        = "Referer" ":" ( absoluteURI | relativeURI )
+
+   Example:
+
+       Referer: http://www.w3.org/hypertext/DataSources/Overview.html
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 140]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If the field value is a relative URI, it SHOULD be interpreted
+   relative to the Request-URI. The URI MUST NOT include a fragment. See
+   section 15.1.3 for security considerations.
+
+14.37 Retry-After
+
+   The Retry-After response-header field can be used with a 503 (Service
+   Unavailable) response to indicate how long the service is expected to
+   be unavailable to the requesting client. This field MAY also be used
+   with any 3xx (Redirection) response to indicate the minimum time the
+   user-agent is asked wait before issuing the redirected request. The
+   value of this field can be either an HTTP-date or an integer number
+   of seconds (in decimal) after the time of the response.
+
+       Retry-After  = "Retry-After" ":" ( HTTP-date | delta-seconds )
+
+   Two examples of its use are
+
+       Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
+       Retry-After: 120
+
+   In the latter example, the delay is 2 minutes.
+
+14.38 Server
+
+   The Server response-header field contains information about the
+   software used by the origin server to handle the request. The field
+   can contain multiple product tokens (section 3.8) and comments
+   identifying the server and any significant subproducts. The product
+   tokens are listed in order of their significance for identifying the
+   application.
+
+       Server         = "Server" ":" 1*( product | comment )
+
+   Example:
+
+       Server: CERN/3.0 libwww/2.17
+
+   If the response is being forwarded through a proxy, the proxy
+   application MUST NOT modify the Server response-header. Instead, it
+   SHOULD include a Via field (as described in section 14.45).
+
+      Note: Revealing the specific software version of the server might
+      allow the server machine to become more vulnerable to attacks
+      against software that is known to contain security holes. Server
+      implementors are encouraged to make this field a configurable
+      option.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 141]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+14.39 TE
+
+   The TE request-header field indicates what extension transfer-codings
+   it is willing to accept in the response and whether or not it is
+   willing to accept trailer fields in a chunked transfer-coding. Its
+   value may consist of the keyword "trailers" and/or a comma-separated
+   list of extension transfer-coding names with optional accept
+   parameters (as described in section 3.6).
+
+       TE        = "TE" ":" #( t-codings )
+       t-codings = "trailers" | ( transfer-extension [ accept-params ] )
+
+   The presence of the keyword "trailers" indicates that the client is
+   willing to accept trailer fields in a chunked transfer-coding, as
+   defined in section 3.6.1. This keyword is reserved for use with
+   transfer-coding values even though it does not itself represent a
+   transfer-coding.
+
+   Examples of its use are:
+
+       TE: deflate
+       TE:
+       TE: trailers, deflate;q=0.5
+
+   The TE header field only applies to the immediate connection.
+   Therefore, the keyword MUST be supplied within a Connection header
+   field (section 14.10) whenever TE is present in an HTTP/1.1 message.
+
+   A server tests whether a transfer-coding is acceptable, according to
+   a TE field, using these rules:
+
+      1. The "chunked" transfer-coding is always acceptable. If the
+         keyword "trailers" is listed, the client indicates that it is
+         willing to accept trailer fields in the chunked response on
+         behalf of itself and any downstream clients. The implication is
+         that, if given, the client is stating that either all
+         downstream clients are willing to accept trailer fields in the
+         forwarded response, or that it will attempt to buffer the
+         response on behalf of downstream recipients.
+
+         Note: HTTP/1.1 does not define any means to limit the size of a
+         chunked response such that a client can be assured of buffering
+         the entire response.
+
+      2. If the transfer-coding being tested is one of the transfer-
+         codings listed in the TE field, then it is acceptable unless it
+         is accompanied by a qvalue of 0. (As defined in section 3.9, a
+         qvalue of 0 means "not acceptable.")
+
+
+
+Fielding, et al.            Standards Track                   [Page 142]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      3. If multiple transfer-codings are acceptable, then the
+         acceptable transfer-coding with the highest non-zero qvalue is
+         preferred.  The "chunked" transfer-coding always has a qvalue
+         of 1.
+
+   If the TE field-value is empty or if no TE field is present, the only
+   transfer-coding  is "chunked". A message with no transfer-coding is
+   always acceptable.
+
+14.40 Trailer
+
+   The Trailer general field value indicates that the given set of
+   header fields is present in the trailer of a message encoded with
+   chunked transfer-coding.
+
+       Trailer  = "Trailer" ":" 1#field-name
+
+   An HTTP/1.1 message SHOULD include a Trailer header field in a
+   message using chunked transfer-coding with a non-empty trailer. Doing
+   so allows the recipient to know which header fields to expect in the
+   trailer.
+
+   If no Trailer header field is present, the trailer SHOULD NOT include
+   any header fields. See section 3.6.1 for restrictions on the use of
+   trailer fields in a "chunked" transfer-coding.
+
+   Message header fields listed in the Trailer header field MUST NOT
+   include the following header fields:
+
+      . Transfer-Encoding
+
+      . Content-Length
+
+      . Trailer
+
+14.41 Transfer-Encoding
+
+   The Transfer-Encoding general-header field indicates what (if any)
+   type of transformation has been applied to the message body in order
+   to safely transfer it between the sender and the recipient. This
+   differs from the content-coding in that the transfer-coding is a
+   property of the message, not of the entity.
+
+     Transfer-Encoding       = "Transfer-Encoding" ":" 1#transfer-coding
+
+   Transfer-codings are defined in section 3.6. An example is:
+
+     Transfer-Encoding: chunked
+
+
+
+Fielding, et al.            Standards Track                   [Page 143]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   If multiple encodings have been applied to an entity, the transfer-
+   codings MUST be listed in the order in which they were applied.
+   Additional information about the encoding parameters MAY be provided
+   by other entity-header fields not defined by this specification.
+
+   Many older HTTP/1.0 applications do not understand the Transfer-
+   Encoding header.
+
+14.42 Upgrade
+
+   The Upgrade general-header allows the client to specify what
+   additional communication protocols it supports and would like to use
+   if the server finds it appropriate to switch protocols. The server
+   MUST use the Upgrade header field within a 101 (Switching Protocols)
+   response to indicate which protocol(s) are being switched.
+
+       Upgrade        = "Upgrade" ":" 1#product
+
+   For example,
+
+       Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
+
+   The Upgrade header field is intended to provide a simple mechanism
+   for transition from HTTP/1.1 to some other, incompatible protocol. It
+   does so by allowing the client to advertise its desire to use another
+   protocol, such as a later version of HTTP with a higher major version
+   number, even though the current request has been made using HTTP/1.1.
+   This eases the difficult transition between incompatible protocols by
+   allowing the client to initiate a request in the more commonly
+   supported protocol while indicating to the server that it would like
+   to use a "better" protocol if available (where "better" is determined
+   by the server, possibly according to the nature of the method and/or
+   resource being requested).
+
+   The Upgrade header field only applies to switching application-layer
+   protocols upon the existing transport-layer connection. Upgrade
+   cannot be used to insist on a protocol change; its acceptance and use
+   by the server is optional. The capabilities and nature of the
+   application-layer communication after the protocol change is entirely
+   dependent upon the new protocol chosen, although the first action
+   after changing the protocol MUST be a response to the initial HTTP
+   request containing the Upgrade header field.
+
+   The Upgrade header field only applies to the immediate connection.
+   Therefore, the upgrade keyword MUST be supplied within a Connection
+   header field (section 14.10) whenever Upgrade is present in an
+   HTTP/1.1 message.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 144]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Upgrade header field cannot be used to indicate a switch to a
+   protocol on a different connection. For that purpose, it is more
+   appropriate to use a 301, 302, 303, or 305 redirection response.
+
+   This specification only defines the protocol name "HTTP" for use by
+   the family of Hypertext Transfer Protocols, as defined by the HTTP
+   version rules of section 3.1 and future updates to this
+   specification. Any token can be used as a protocol name; however, it
+   will only be useful if both the client and server associate the name
+   with the same protocol.
+
+14.43 User-Agent
+
+   The User-Agent request-header field contains information about the
+   user agent originating the request. This is for statistical purposes,
+   the tracing of protocol violations, and automated recognition of user
+   agents for the sake of tailoring responses to avoid particular user
+   agent limitations. User agents SHOULD include this field with
+   requests. The field can contain multiple product tokens (section 3.8)
+   and comments identifying the agent and any subproducts which form a
+   significant part of the user agent. By convention, the product tokens
+   are listed in order of their significance for identifying the
+   application.
+
+       User-Agent     = "User-Agent" ":" 1*( product | comment )
+
+   Example:
+
+       User-Agent: CERN-LineMode/2.15 libwww/2.17b3
+
+14.44 Vary
+
+   The Vary field value indicates the set of request-header fields that
+   fully determines, while the response is fresh, whether a cache is
+   permitted to use the response to reply to a subsequent request
+   without revalidation. For uncacheable or stale responses, the Vary
+   field value advises the user agent about the criteria that were used
+   to select the representation. A Vary field value of "*" implies that
+   a cache cannot determine from the request headers of a subsequent
+   request whether this response is the appropriate representation. See
+   section 13.6 for use of the Vary header field by caches.
+
+       Vary  = "Vary" ":" ( "*" | 1#field-name )
+
+   An HTTP/1.1 server SHOULD include a Vary header field with any
+   cacheable response that is subject to server-driven negotiation.
+   Doing so allows a cache to properly interpret future requests on that
+   resource and informs the user agent about the presence of negotiation
+
+
+
+Fielding, et al.            Standards Track                   [Page 145]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   on that resource. A server MAY include a Vary header field with a
+   non-cacheable response that is subject to server-driven negotiation,
+   since this might provide the user agent with useful information about
+   the dimensions over which the response varies at the time of the
+   response.
+
+   A Vary field value consisting of a list of field-names signals that
+   the representation selected for the response is based on a selection
+   algorithm which considers ONLY the listed request-header field values
+   in selecting the most appropriate representation. A cache MAY assume
+   that the same selection will be made for future requests with the
+   same values for the listed field names, for the duration of time for
+   which the response is fresh.
+
+   The field-names given are not limited to the set of standard
+   request-header fields defined by this specification. Field names are
+   case-insensitive.
+
+   A Vary field value of "*" signals that unspecified parameters not
+   limited to the request-headers (e.g., the network address of the
+   client), play a role in the selection of the response representation.
+   The "*" value MUST NOT be generated by a proxy server; it may only be
+   generated by an origin server.
+
+14.45  Via
+
+   The Via general-header field MUST be used by gateways and proxies to
+   indicate the intermediate protocols and recipients between the user
+   agent and the server on requests, and between the origin server and
+   the client on responses. It is analogous to the "Received" field of
+   RFC 822 [9] and is intended to be used for tracking message forwards,
+   avoiding request loops, and identifying the protocol capabilities of
+   all senders along the request/response chain.
+
+      Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
+      received-protocol = [ protocol-name "/" ] protocol-version
+      protocol-name     = token
+      protocol-version  = token
+      received-by       = ( host [ ":" port ] ) | pseudonym
+      pseudonym         = token
+
+   The received-protocol indicates the protocol version of the message
+   received by the server or client along each segment of the
+   request/response chain. The received-protocol version is appended to
+   the Via field value when the message is forwarded so that information
+   about the protocol capabilities of upstream applications remains
+   visible to all recipients.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 146]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The protocol-name is optional if and only if it would be "HTTP". The
+   received-by field is normally the host and optional port number of a
+   recipient server or client that subsequently forwarded the message.
+   However, if the real host is considered to be sensitive information,
+   it MAY be replaced by a pseudonym. If the port is not given, it MAY
+   be assumed to be the default port of the received-protocol.
+
+   Multiple Via field values represents each proxy or gateway that has
+   forwarded the message. Each recipient MUST append its information
+   such that the end result is ordered according to the sequence of
+   forwarding applications.
+
+   Comments MAY be used in the Via header field to identify the software
+   of the recipient proxy or gateway, analogous to the User-Agent and
+   Server header fields. However, all comments in the Via field are
+   optional and MAY be removed by any recipient prior to forwarding the
+   message.
+
+   For example, a request message could be sent from an HTTP/1.0 user
+   agent to an internal proxy code-named "fred", which uses HTTP/1.1 to
+   forward the request to a public proxy at nowhere.com, which completes
+   the request by forwarding it to the origin server at www.ics.uci.edu.
+   The request received by www.ics.uci.edu would then have the following
+   Via header field:
+
+       Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)
+
+   Proxies and gateways used as a portal through a network firewall
+   SHOULD NOT, by default, forward the names and ports of hosts within
+   the firewall region. This information SHOULD only be propagated if
+   explicitly enabled. If not enabled, the received-by host of any host
+   behind the firewall SHOULD be replaced by an appropriate pseudonym
+   for that host.
+
+   For organizations that have strong privacy requirements for hiding
+   internal structures, a proxy MAY combine an ordered subsequence of
+   Via header field entries with identical received-protocol values into
+   a single such entry. For example,
+
+       Via: 1.0 ricky, 1.1 ethel, 1.1 fred, 1.0 lucy
+
+        could be collapsed to
+
+       Via: 1.0 ricky, 1.1 mertz, 1.0 lucy
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 147]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Applications SHOULD NOT combine multiple entries unless they are all
+   under the same organizational control and the hosts have already been
+   replaced by pseudonyms. Applications MUST NOT combine entries which
+   have different received-protocol values.
+
+14.46 Warning
+
+   The Warning general-header field is used to carry additional
+   information about the status or transformation of a message which
+   might not be reflected in the message. This information is typically
+   used to warn about a possible lack of semantic transparency from
+   caching operations or transformations applied to the entity body of
+   the message.
+
+   Warning headers are sent with responses using:
+
+       Warning    = "Warning" ":" 1#warning-value
+
+       warning-value = warn-code SP warn-agent SP warn-text
+                                             [SP warn-date]
+
+       warn-code  = 3DIGIT
+       warn-agent = ( host [ ":" port ] ) | pseudonym
+                       ; the name or pseudonym of the server adding
+                       ; the Warning header, for use in debugging
+       warn-text  = quoted-string
+       warn-date  = <"> HTTP-date <">
+
+   A response MAY carry more than one Warning header.
+
+   The warn-text SHOULD be in a natural language and character set that
+   is most likely to be intelligible to the human user receiving the
+   response. This decision MAY be based on any available knowledge, such
+   as the location of the cache or user, the Accept-Language field in a
+   request, the Content-Language field in a response, etc. The default
+   language is English and the default character set is ISO-8859-1.
+
+   If a character set other than ISO-8859-1 is used, it MUST be encoded
+   in the warn-text using the method described in RFC 2047 [14].
+
+   Warning headers can in general be applied to any message, however
+   some specific warn-codes are specific to caches and can only be
+   applied to response messages. New Warning headers SHOULD be added
+   after any existing Warning headers. A cache MUST NOT delete any
+   Warning header that it received with a message. However, if a cache
+   successfully validates a cache entry, it SHOULD remove any Warning
+   headers previously attached to that entry except as specified for
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 148]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   specific Warning codes. It MUST then add any Warning headers received
+   in the validating response. In other words, Warning headers are those
+   that would be attached to the most recent relevant response.
+
+   When multiple Warning headers are attached to a response, the user
+   agent ought to inform the user of as many of them as possible, in the
+   order that they appear in the response. If it is not possible to
+   inform the user of all of the warnings, the user agent SHOULD follow
+   these heuristics:
+
+      - Warnings that appear early in the response take priority over
+        those appearing later in the response.
+
+      - Warnings in the user's preferred character set take priority
+        over warnings in other character sets but with identical warn-
+        codes and warn-agents.
+
+   Systems that generate multiple Warning headers SHOULD order them with
+   this user agent behavior in mind.
+
+   Requirements for the behavior of caches with respect to Warnings are
+   stated in section 13.1.2.
+
+   This is a list of the currently-defined warn-codes, each with a
+   recommended warn-text in English, and a description of its meaning.
+
+   110 Response is stale
+     MUST be included whenever the returned response is stale.
+
+   111 Revalidation failed
+     MUST be included if a cache returns a stale response because an
+     attempt to revalidate the response failed, due to an inability to
+     reach the server.
+
+   112 Disconnected operation
+     SHOULD be included if the cache is intentionally disconnected from
+     the rest of the network for a period of time.
+
+   113 Heuristic expiration
+     MUST be included if the cache heuristically chose a freshness
+     lifetime greater than 24 hours and the response's age is greater
+     than 24 hours.
+
+   199 Miscellaneous warning
+     The warning text MAY include arbitrary information to be presented
+     to a human user, or logged. A system receiving this warning MUST
+     NOT take any automated action, besides presenting the warning to
+     the user.
+
+
+
+Fielding, et al.            Standards Track                   [Page 149]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   214 Transformation applied
+     MUST be added by an intermediate cache or proxy if it applies any
+     transformation changing the content-coding (as specified in the
+     Content-Encoding header) or media-type (as specified in the
+     Content-Type header) of the response, or the entity-body of the
+     response, unless this Warning code already appears in the response.
+
+   299 Miscellaneous persistent warning
+     The warning text MAY include arbitrary information to be presented
+     to a human user, or logged. A system receiving this warning MUST
+     NOT take any automated action.
+
+   If an implementation sends a message with one or more Warning headers
+   whose version is HTTP/1.0 or lower, then the sender MUST include in
+   each warning-value a warn-date that matches the date in the response.
+
+   If an implementation receives a message with a warning-value that
+   includes a warn-date, and that warn-date is different from the Date
+   value in the response, then that warning-value MUST be deleted from
+   the message before storing, forwarding, or using it. (This prevents
+   bad consequences of naive caching of Warning header fields.) If all
+   of the warning-values are deleted for this reason, the Warning header
+   MUST be deleted as well.
+
+14.47 WWW-Authenticate
+
+   The WWW-Authenticate response-header field MUST be included in 401
+   (Unauthorized) response messages. The field value consists of at
+   least one challenge that indicates the authentication scheme(s) and
+   parameters applicable to the Request-URI.
+
+       WWW-Authenticate  = "WWW-Authenticate" ":" 1#challenge
+
+   The HTTP access authentication process is described in "HTTP
+   Authentication: Basic and Digest Access Authentication" [43]. User
+   agents are advised to take special care in parsing the WWW-
+   Authenticate field value as it might contain more than one challenge,
+   or if more than one WWW-Authenticate header field is provided, the
+   contents of a challenge itself can contain a comma-separated list of
+   authentication parameters.
+
+15 Security Considerations
+
+   This section is meant to inform application developers, information
+   providers, and users of the security limitations in HTTP/1.1 as
+   described by this document. The discussion does not include
+   definitive solutions to the problems revealed, though it does make
+   some suggestions for reducing security risks.
+
+
+
+Fielding, et al.            Standards Track                   [Page 150]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.1 Personal Information
+
+   HTTP clients are often privy to large amounts of personal information
+   (e.g. the user's name, location, mail address, passwords, encryption
+   keys, etc.), and SHOULD be very careful to prevent unintentional
+   leakage of this information via the HTTP protocol to other sources.
+   We very strongly recommend that a convenient interface be provided
+   for the user to control dissemination of such information, and that
+   designers and implementors be particularly careful in this area.
+   History shows that errors in this area often create serious security
+   and/or privacy problems and generate highly adverse publicity for the
+   implementor's company.
+
+15.1.1 Abuse of Server Log Information
+
+   A server is in the position to save personal data about a user's
+   requests which might identify their reading patterns or subjects of
+   interest. This information is clearly confidential in nature and its
+   handling can be constrained by law in certain countries. People using
+   the HTTP protocol to provide data are responsible for ensuring that
+   such material is not distributed without the permission of any
+   individuals that are identifiable by the published results.
+
+15.1.2 Transfer of Sensitive Information
+
+   Like any generic data transfer protocol, HTTP cannot regulate the
+   content of the data that is transferred, nor is there any a priori
+   method of determining the sensitivity of any particular piece of
+   information within the context of any given request. Therefore,
+   applications SHOULD supply as much control over this information as
+   possible to the provider of that information. Four header fields are
+   worth special mention in this context: Server, Via, Referer and From.
+
+   Revealing the specific software version of the server might allow the
+   server machine to become more vulnerable to attacks against software
+   that is known to contain security holes. Implementors SHOULD make the
+   Server header field a configurable option.
+
+   Proxies which serve as a portal through a network firewall SHOULD
+   take special precautions regarding the transfer of header information
+   that identifies the hosts behind the firewall. In particular, they
+   SHOULD remove, or replace with sanitized versions, any Via fields
+   generated behind the firewall.
+
+   The Referer header allows reading patterns to be studied and reverse
+   links drawn. Although it can be very useful, its power can be abused
+   if user details are not separated from the information contained in
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 151]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   the Referer. Even when the personal information has been removed, the
+   Referer header might indicate a private document's URI whose
+   publication would be inappropriate.
+
+   The information sent in the From field might conflict with the user's
+   privacy interests or their site's security policy, and hence it
+   SHOULD NOT be transmitted without the user being able to disable,
+   enable, and modify the contents of the field. The user MUST be able
+   to set the contents of this field within a user preference or
+   application defaults configuration.
+
+   We suggest, though do not require, that a convenient toggle interface
+   be provided for the user to enable or disable the sending of From and
+   Referer information.
+
+   The User-Agent (section 14.43) or Server (section 14.38) header
+   fields can sometimes be used to determine that a specific client or
+   server have a particular security hole which might be exploited.
+   Unfortunately, this same information is often used for other valuable
+   purposes for which HTTP currently has no better mechanism.
+
+15.1.3 Encoding Sensitive Information in URI's
+
+   Because the source of a link might be private information or might
+   reveal an otherwise private information source, it is strongly
+   recommended that the user be able to select whether or not the
+   Referer field is sent. For example, a browser client could have a
+   toggle switch for browsing openly/anonymously, which would
+   respectively enable/disable the sending of Referer and From
+   information.
+
+   Clients SHOULD NOT include a Referer header field in a (non-secure)
+   HTTP request if the referring page was transferred with a secure
+   protocol.
+
+   Authors of services which use the HTTP protocol SHOULD NOT use GET
+   based forms for the submission of sensitive data, because this will
+   cause this data to be encoded in the Request-URI. Many existing
+   servers, proxies, and user agents will log the request URI in some
+   place where it might be visible to third parties. Servers can use
+   POST-based form submission instead
+
+15.1.4 Privacy Issues Connected to Accept Headers
+
+   Accept request-headers can reveal information about the user to all
+   servers which are accessed. The Accept-Language header in particular
+   can reveal information the user would consider to be of a private
+   nature, because the understanding of particular languages is often
+
+
+
+Fielding, et al.            Standards Track                   [Page 152]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   strongly correlated to the membership of a particular ethnic group.
+   User agents which offer the option to configure the contents of an
+   Accept-Language header to be sent in every request are strongly
+   encouraged to let the configuration process include a message which
+   makes the user aware of the loss of privacy involved.
+
+   An approach that limits the loss of privacy would be for a user agent
+   to omit the sending of Accept-Language headers by default, and to ask
+   the user whether or not to start sending Accept-Language headers to a
+   server if it detects, by looking for any Vary response-header fields
+   generated by the server, that such sending could improve the quality
+   of service.
+
+   Elaborate user-customized accept header fields sent in every request,
+   in particular if these include quality values, can be used by servers
+   as relatively reliable and long-lived user identifiers. Such user
+   identifiers would allow content providers to do click-trail tracking,
+   and would allow collaborating content providers to match cross-server
+   click-trails or form submissions of individual users. Note that for
+   many users not behind a proxy, the network address of the host
+   running the user agent will also serve as a long-lived user
+   identifier. In environments where proxies are used to enhance
+   privacy, user agents ought to be conservative in offering accept
+   header configuration options to end users. As an extreme privacy
+   measure, proxies could filter the accept headers in relayed requests.
+   General purpose user agents which provide a high degree of header
+   configurability SHOULD warn users about the loss of privacy which can
+   be involved.
+
+15.2 Attacks Based On File and Path Names
+
+   Implementations of HTTP origin servers SHOULD be careful to restrict
+   the documents returned by HTTP requests to be only those that were
+   intended by the server administrators. If an HTTP server translates
+   HTTP URIs directly into file system calls, the server MUST take
+   special care not to serve files that were not intended to be
+   delivered to HTTP clients. For example, UNIX, Microsoft Windows, and
+   other operating systems use ".." as a path component to indicate a
+   directory level above the current one. On such a system, an HTTP
+   server MUST disallow any such construct in the Request-URI if it
+   would otherwise allow access to a resource outside those intended to
+   be accessible via the HTTP server. Similarly, files intended for
+   reference only internally to the server (such as access control
+   files, configuration files, and script code) MUST be protected from
+   inappropriate retrieval, since they might contain sensitive
+   information. Experience has shown that minor bugs in such HTTP server
+   implementations have turned into security risks.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 153]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.3 DNS Spoofing
+
+   Clients using HTTP rely heavily on the Domain Name Service, and are
+   thus generally prone to security attacks based on the deliberate
+   mis-association of IP addresses and DNS names. Clients need to be
+   cautious in assuming the continuing validity of an IP number/DNS name
+   association.
+
+   In particular, HTTP clients SHOULD rely on their name resolver for
+   confirmation of an IP number/DNS name association, rather than
+   caching the result of previous host name lookups. Many platforms
+   already can cache host name lookups locally when appropriate, and
+   they SHOULD be configured to do so. It is proper for these lookups to
+   be cached, however, only when the TTL (Time To Live) information
+   reported by the name server makes it likely that the cached
+   information will remain useful.
+
+   If HTTP clients cache the results of host name lookups in order to
+   achieve a performance improvement, they MUST observe the TTL
+   information reported by DNS.
+
+   If HTTP clients do not observe this rule, they could be spoofed when
+   a previously-accessed server's IP address changes. As network
+   renumbering is expected to become increasingly common [24], the
+   possibility of this form of attack will grow. Observing this
+   requirement thus reduces this potential security vulnerability.
+
+   This requirement also improves the load-balancing behavior of clients
+   for replicated servers using the same DNS name and reduces the
+   likelihood of a user's experiencing failure in accessing sites which
+   use that strategy.
+
+15.4 Location Headers and Spoofing
+
+   If a single server supports multiple organizations that do not trust
+   one another, then it MUST check the values of Location and Content-
+   Location headers in responses that are generated under control of
+   said organizations to make sure that they do not attempt to
+   invalidate resources over which they have no authority.
+
+15.5 Content-Disposition Issues
+
+   RFC 1806 [35], from which the often implemented Content-Disposition
+   (see section 19.5.1) header in HTTP is derived, has a number of very
+   serious security considerations. Content-Disposition is not part of
+   the HTTP standard, but since it is widely implemented, we are
+   documenting its use and risks for implementors. See RFC 2183 [49]
+   (which updates RFC 1806) for details.
+
+
+
+Fielding, et al.            Standards Track                   [Page 154]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+15.6 Authentication Credentials and Idle Clients
+
+   Existing HTTP clients and user agents typically retain authentication
+   information indefinitely. HTTP/1.1. does not provide a method for a
+   server to direct clients to discard these cached credentials. This is
+   a significant defect that requires further extensions to HTTP.
+   Circumstances under which credential caching can interfere with the
+   application's security model include but are not limited to:
+
+      - Clients which have been idle for an extended period following
+        which the server might wish to cause the client to reprompt the
+        user for credentials.
+
+      - Applications which include a session termination indication
+        (such as a `logout' or `commit' button on a page) after which
+        the server side of the application `knows' that there is no
+        further reason for the client to retain the credentials.
+
+   This is currently under separate study. There are a number of work-
+   arounds to parts of this problem, and we encourage the use of
+   password protection in screen savers, idle time-outs, and other
+   methods which mitigate the security problems inherent in this
+   problem. In particular, user agents which cache credentials are
+   encouraged to provide a readily accessible mechanism for discarding
+   cached credentials under user control.
+
+15.7 Proxies and Caching
+
+   By their very nature, HTTP proxies are men-in-the-middle, and
+   represent an opportunity for man-in-the-middle attacks. Compromise of
+   the systems on which the proxies run can result in serious security
+   and privacy problems. Proxies have access to security-related
+   information, personal information about individual users and
+   organizations, and proprietary information belonging to users and
+   content providers. A compromised proxy, or a proxy implemented or
+   configured without regard to security and privacy considerations,
+   might be used in the commission of a wide range of potential attacks.
+
+   Proxy operators should protect the systems on which proxies run as
+   they would protect any system that contains or transports sensitive
+   information. In particular, log information gathered at proxies often
+   contains highly sensitive personal information, and/or information
+   about organizations. Log information should be carefully guarded, and
+   appropriate guidelines for use developed and followed. (Section
+   15.1.1).
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 155]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Caching proxies provide additional potential vulnerabilities, since
+   the contents of the cache represent an attractive target for
+   malicious exploitation. Because cache contents persist after an HTTP
+   request is complete, an attack on the cache can reveal information
+   long after a user believes that the information has been removed from
+   the network. Therefore, cache contents should be protected as
+   sensitive information.
+
+   Proxy implementors should consider the privacy and security
+   implications of their design and coding decisions, and of the
+   configuration options they provide to proxy operators (especially the
+   default configuration).
+
+   Users of a proxy need to be aware that they are no trustworthier than
+   the people who run the proxy; HTTP itself cannot solve this problem.
+
+   The judicious use of cryptography, when appropriate, may suffice to
+   protect against a broad range of security and privacy attacks. Such
+   cryptography is beyond the scope of the HTTP/1.1 specification.
+
+15.7.1 Denial of Service Attacks on Proxies
+
+   They exist. They are hard to defend against. Research continues.
+   Beware.
+
+16 Acknowledgments
+
+   This specification makes heavy use of the augmented BNF and generic
+   constructs defined by David H. Crocker for RFC 822 [9]. Similarly, it
+   reuses many of the definitions provided by Nathaniel Borenstein and
+   Ned Freed for MIME [7]. We hope that their inclusion in this
+   specification will help reduce past confusion over the relationship
+   between HTTP and Internet mail message formats.
+
+   The HTTP protocol has evolved considerably over the years. It has
+   benefited from a large and active developer community--the many
+   people who have participated on the www-talk mailing list--and it is
+   that community which has been most responsible for the success of
+   HTTP and of the World-Wide Web in general. Marc Andreessen, Robert
+   Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jean-Francois
+   Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob
+   McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc
+   VanHeyningen deserve special recognition for their efforts in
+   defining early aspects of the protocol.
+
+   This document has benefited greatly from the comments of all those
+   participating in the HTTP-WG. In addition to those already mentioned,
+   the following individuals have contributed to this specification:
+
+
+
+Fielding, et al.            Standards Track                   [Page 156]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+       Gary Adams                  Ross Patterson
+       Harald Tveit Alvestrand     Albert Lunde
+       Keith Ball                  John C. Mallery
+       Brian Behlendorf            Jean-Philippe Martin-Flatin
+       Paul Burchard               Mitra
+       Maurizio Codogno            David Morris
+       Mike Cowlishaw              Gavin Nicol
+       Roman Czyborra              Bill Perry
+       Michael A. Dolan            Jeffrey Perry
+       David J. Fiander            Scott Powers
+       Alan Freier                 Owen Rees
+       Marc Hedlund                Luigi Rizzo
+       Greg Herlihy                David Robinson
+       Koen Holtman                Marc Salomon
+       Alex Hopmann                Rich Salz
+       Bob Jernigan                Allan M. Schiffman
+       Shel Kaphan                 Jim Seidman
+       Rohit Khare                 Chuck Shotton
+       John Klensin                Eric W. Sink
+       Martijn Koster              Simon E. Spero
+       Alexei Kosut                Richard N. Taylor
+       David M. Kristol            Robert S. Thau
+       Daniel LaLiberte            Bill (BearHeart) Weinman
+       Ben Laurie                  Francois Yergeau
+       Paul J. Leach               Mary Ellen Zurko
+       Daniel DuBois               Josh Cohen
+
+
+   Much of the content and presentation of the caching design is due to
+   suggestions and comments from individuals including: Shel Kaphan,
+   Paul Leach, Koen Holtman, David Morris, and Larry Masinter.
+
+   Most of the specification of ranges is based on work originally done
+   by Ari Luotonen and John Franks, with additional input from Steve
+   Zilles.
+
+   Thanks to the "cave men" of Palo Alto. You know who you are.
+
+   Jim Gettys (the current editor of this document) wishes particularly
+   to thank Roy Fielding, the previous editor of this document, along
+   with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen
+   Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott Lawrence, and
+   Larry Masinter for their help. And thanks go particularly to Jeff
+   Mogul and Scott Lawrence for performing the "MUST/MAY/SHOULD" audit.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 157]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   The Apache Group, Anselm Baird-Smith, author of Jigsaw, and Henrik
+   Frystyk implemented RFC 2068 early, and we wish to thank them for the
+   discovery of many of the problems that this document attempts to
+   rectify.
+
+17 References
+
+   [1] Alvestrand, H., "Tags for the Identification of Languages", RFC
+       1766, March 1995.
+
+   [2] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D., Torrey,
+       D. and B. Alberti, "The Internet Gopher Protocol (a distributed
+       document search and retrieval protocol)", RFC 1436, March 1993.
+
+   [3] Berners-Lee, T., "Universal Resource Identifiers in WWW", RFC
+       1630, June 1994.
+
+   [4] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource
+       Locators (URL)", RFC 1738, December 1994.
+
+   [5] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language -
+       2.0", RFC 1866, November 1995.
+
+   [6] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext Transfer
+       Protocol -- HTTP/1.0", RFC 1945, May 1996.
+
+   [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+       Extensions (MIME) Part One: Format of Internet Message Bodies",
+       RFC 2045, November 1996.
+
+   [8] Braden, R., "Requirements for Internet Hosts -- Communication
+       Layers", STD 3, RFC 1123, October 1989.
+
+   [9] Crocker, D., "Standard for The Format of ARPA Internet Text
+       Messages", STD 11, RFC 822, August 1982.
+
+   [10] Davis, F., Kahle, B., Morris, H., Salem, J., Shen, T., Wang, R.,
+        Sui, J., and M. Grinbaum, "WAIS Interface Protocol Prototype
+        Functional Specification," (v1.5), Thinking Machines
+        Corporation, April 1990.
+
+   [11] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
+        June 1995.
+
+   [12] Horton, M. and R. Adams, "Standard for Interchange of USENET
+        Messages", RFC 1036, December 1987.
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 158]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [13] Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC
+        977, February 1986.
+
+   [14] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
+        Three: Message Header Extensions for Non-ASCII Text", RFC 2047,
+        November 1996.
+
+   [15] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC
+        1867, November 1995.
+
+   [16] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+        August 1982.
+
+   [17] Postel, J., "Media Type Registration Procedure", RFC 1590,
+        November 1996.
+
+   [18] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC
+        959, October 1985.
+
+   [19] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
+        October 1994.
+
+   [20] Sollins, K. and L. Masinter, "Functional Requirements for
+        Uniform Resource Names", RFC 1737, December 1994.
+
+   [21] US-ASCII. Coded Character Set - 7-Bit American Standard Code for
+        Information Interchange. Standard ANSI X3.4-1986, ANSI, 1986.
+
+   [22] ISO-8859. International Standard -- Information Processing --
+        8-bit Single-Byte Coded Graphic Character Sets --
+        Part 1: Latin alphabet No. 1, ISO-8859-1:1987.
+        Part 2: Latin alphabet No. 2, ISO-8859-2, 1987.
+        Part 3: Latin alphabet No. 3, ISO-8859-3, 1988.
+        Part 4: Latin alphabet No. 4, ISO-8859-4, 1988.
+        Part 5: Latin/Cyrillic alphabet, ISO-8859-5, 1988.
+        Part 6: Latin/Arabic alphabet, ISO-8859-6, 1987.
+        Part 7: Latin/Greek alphabet, ISO-8859-7, 1987.
+        Part 8: Latin/Hebrew alphabet, ISO-8859-8, 1988.
+        Part 9: Latin alphabet No. 5, ISO-8859-9, 1990.
+
+   [23] Meyers, J. and M. Rose, "The Content-MD5 Header Field", RFC
+        1864, October 1995.
+
+   [24] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC
+        1900, February 1996.
+
+   [25] Deutsch, P., "GZIP file format specification version 4.3", RFC
+        1952, May 1996.
+
+
+
+Fielding, et al.            Standards Track                   [Page 159]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [26] Venkata N. Padmanabhan, and Jeffrey C. Mogul. "Improving HTTP
+        Latency", Computer Networks and ISDN Systems, v. 28, pp. 25-35,
+        Dec. 1995. Slightly revised version of paper in Proc. 2nd
+        International WWW Conference '94: Mosaic and the Web, Oct. 1994,
+        which is available at
+        http://www.ncsa.uiuc.edu/SDG/IT94/Proceedings/DDay/mogul/HTTPLat
+        ency.html.
+
+   [27] Joe Touch, John Heidemann, and Katia Obraczka. "Analysis of HTTP
+        Performance", <URL: http://www.isi.edu/touch/pubs/http-perf96/>,
+        ISI Research Report ISI/RR-98-463, (original report dated Aug.
+        1996), USC/Information Sciences Institute, August 1998.
+
+   [28] Mills, D., "Network Time Protocol (Version 3) Specification,
+        Implementation and Analysis", RFC 1305, March 1992.
+
+   [29] Deutsch, P., "DEFLATE Compressed Data Format Specification
+        version 1.3", RFC 1951, May 1996.
+
+   [30] S. Spero, "Analysis of HTTP Performance Problems,"
+        http://sunsite.unc.edu/mdma-release/http-prob.html.
+
+   [31] Deutsch, P. and J. Gailly, "ZLIB Compressed Data Format
+        Specification version 3.3", RFC 1950, May 1996.
+
+   [32] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
+        Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
+        Digest Access Authentication", RFC 2069, January 1997.
+
+   [33] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
+        Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
+        2068, January 1997.
+
+   [34] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [35] Troost, R. and Dorner, S., "Communicating Presentation
+        Information in Internet Messages: The Content-Disposition
+        Header", RFC 1806, June 1995.
+
+   [36] Mogul, J., Fielding, R., Gettys, J. and H. Frystyk, "Use and
+        Interpretation of HTTP Version Numbers", RFC 2145, May 1997.
+        [jg639]
+
+   [37] Palme, J., "Common Internet Message Headers", RFC 2076, February
+        1997. [jg640]
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 160]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   [38] Yergeau, F., "UTF-8, a transformation format of Unicode and
+        ISO-10646", RFC 2279, January 1998. [jg641]
+
+   [39] Nielsen, H.F., Gettys, J., Baird-Smith, A., Prud'hommeaux, E.,
+        Lie, H., and C. Lilley. "Network Performance Effects of
+        HTTP/1.1, CSS1, and PNG," Proceedings of ACM SIGCOMM '97, Cannes
+        France, September 1997.[jg642]
+
+   [40] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Two: Media Types", RFC 2046, November
+        1996. [jg643]
+
+   [41] Alvestrand, H., "IETF Policy on Character Sets and Languages",
+        BCP 18, RFC 2277, January 1998. [jg644]
+
+   [42] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
+        Identifiers (URI): Generic Syntax and Semantics", RFC 2396,
+        August 1998. [jg645]
+
+   [43] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
+        Leach, P., Luotonen, A., Sink, E. and L. Stewart, "HTTP
+        Authentication: Basic and Digest Access Authentication", RFC
+        2617, June 1999. [jg646]
+
+   [44] Luotonen, A., "Tunneling TCP based protocols through Web proxy
+        servers," Work in Progress. [jg647]
+
+   [45] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of
+        Aggregate Documents, such as HTML (MHTML)", RFC 2110, March
+        1997.
+
+   [46] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+        9, RFC 2026, October 1996.
+
+   [47] Masinter, L., "Hyper Text Coffee Pot Control Protocol
+        (HTCPCP/1.0)", RFC 2324, 1 April 1998.
+
+   [48] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+        Extensions (MIME) Part Five: Conformance Criteria and Examples",
+        RFC 2049, November 1996.
+
+   [49] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
+        Information in Internet Messages: The Content-Disposition Header
+        Field", RFC 2183, August 1997.
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 161]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+18 Authors' Addresses
+
+   Roy T. Fielding
+   Information and Computer Science
+   University of California, Irvine
+   Irvine, CA 92697-3425, USA
+
+   Fax: +1 (949) 824-1715
+   EMail: fielding@ics.uci.edu
+
+
+   James Gettys
+   World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: jg@w3.org
+
+
+   Jeffrey C. Mogul
+   Western Research Laboratory
+   Compaq Computer Corporation
+   250 University Avenue
+   Palo Alto, California, 94305, USA
+
+   EMail: mogul@wrl.dec.com
+
+
+   Henrik Frystyk Nielsen
+   World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: frystyk@w3.org
+
+
+   Larry Masinter
+   Xerox Corporation
+   3333 Coyote Hill Road
+   Palo Alto, CA 94034, USA
+
+   EMail: masinter@parc.xerox.com
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 162]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Paul J. Leach
+   Microsoft Corporation
+   1 Microsoft Way
+   Redmond, WA 98052, USA
+
+   EMail: paulle@microsoft.com
+
+
+   Tim Berners-Lee
+   Director, World Wide Web Consortium
+   MIT Laboratory for Computer Science
+   545 Technology Square
+   Cambridge, MA 02139, USA
+
+   Fax: +1 (617) 258 8682
+   EMail: timbl@w3.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 163]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+19 Appendices
+
+19.1 Internet Media Type message/http and application/http
+
+   In addition to defining the HTTP/1.1 protocol, this document serves
+   as the specification for the Internet media type "message/http" and
+   "application/http". The message/http type can be used to enclose a
+   single HTTP request or response message, provided that it obeys the
+   MIME restrictions for all "message" types regarding line length and
+   encodings. The application/http type can be used to enclose a
+   pipeline of one or more HTTP request or response messages (not
+   intermixed). The following is to be registered with IANA [17].
+
+       Media Type name:         message
+       Media subtype name:      http
+       Required parameters:     none
+       Optional parameters:     version, msgtype
+        version: The HTTP-Version number of the enclosed message
+                 (e.g., "1.1"). If not present, the version can be
+                 determined from the first line of the body.
+        msgtype: The message type -- "request" or "response". If not
+                 present, the type can be determined from the first
+                 line of the body.
+       Encoding considerations: only "7bit", "8bit", or "binary" are
+                                permitted
+       Security considerations: none
+
+       Media Type name:         application
+       Media subtype name:      http
+       Required parameters:     none
+       Optional parameters:     version, msgtype
+        version: The HTTP-Version number of the enclosed messages
+                 (e.g., "1.1"). If not present, the version can be
+                 determined from the first line of the body.
+        msgtype: The message type -- "request" or "response". If not
+                 present, the type can be determined from the first
+                 line of the body.
+       Encoding considerations: HTTP messages enclosed by this type
+                 are in "binary" format; use of an appropriate
+                 Content-Transfer-Encoding is required when
+                 transmitted via E-mail.
+       Security considerations: none
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 164]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+19.2 Internet Media Type multipart/byteranges
+
+   When an HTTP 206 (Partial Content) response message includes the
+   content of multiple ranges (a response to a request for multiple
+   non-overlapping ranges), these are transmitted as a multipart
+   message-body. The media type for this purpose is called
+   "multipart/byteranges".
+
+   The multipart/byteranges media type includes two or more parts, each
+   with its own Content-Type and Content-Range fields. The required
+   boundary parameter specifies the boundary string used to separate
+   each body-part.
+
+       Media Type name:         multipart
+       Media subtype name:      byteranges
+       Required parameters:     boundary
+       Optional parameters:     none
+       Encoding considerations: only "7bit", "8bit", or "binary" are
+                                permitted
+       Security considerations: none
+
+
+   For example:
+
+   HTTP/1.1 206 Partial Content
+   Date: Wed, 15 Nov 1995 06:25:24 GMT
+   Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
+   Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
+
+   --THIS_STRING_SEPARATES
+   Content-type: application/pdf
+   Content-range: bytes 500-999/8000
+
+   ...the first range...
+   --THIS_STRING_SEPARATES
+   Content-type: application/pdf
+   Content-range: bytes 7000-7999/8000
+
+   ...the second range
+   --THIS_STRING_SEPARATES--
+
+      Notes:
+
+      1) Additional CRLFs may precede the first boundary string in the
+         entity.
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 165]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      2) Although RFC 2046 [40] permits the boundary string to be
+         quoted, some existing implementations handle a quoted boundary
+         string incorrectly.
+
+      3) A number of browsers and servers were coded to an early draft
+         of the byteranges specification to use a media type of
+         multipart/x-byteranges, which is almost, but not quite
+         compatible with the version documented in HTTP/1.1.
+
+19.3 Tolerant Applications
+
+   Although this document specifies the requirements for the generation
+   of HTTP/1.1 messages, not all applications will be correct in their
+   implementation. We therefore recommend that operational applications
+   be tolerant of deviations whenever those deviations can be
+   interpreted unambiguously.
+
+   Clients SHOULD be tolerant in parsing the Status-Line and servers
+   tolerant when parsing the Request-Line. In particular, they SHOULD
+   accept any amount of SP or HT characters between fields, even though
+   only a single SP is required.
+
+   The line terminator for message-header fields is the sequence CRLF.
+   However, we recommend that applications, when parsing such headers,
+   recognize a single LF as a line terminator and ignore the leading CR.
+
+   The character set of an entity-body SHOULD be labeled as the lowest
+   common denominator of the character codes used within that body, with
+   the exception that not labeling the entity is preferred over labeling
+   the entity with the labels US-ASCII or ISO-8859-1. See section 3.7.1
+   and 3.4.1.
+
+   Additional rules for requirements on parsing and encoding of dates
+   and other potential problems with date encodings include:
+
+      - HTTP/1.1 clients and caches SHOULD assume that an RFC-850 date
+        which appears to be more than 50 years in the future is in fact
+        in the past (this helps solve the "year 2000" problem).
+
+      - An HTTP/1.1 implementation MAY internally represent a parsed
+        Expires date as earlier than the proper value, but MUST NOT
+        internally represent a parsed Expires date as later than the
+        proper value.
+
+      - All expiration-related calculations MUST be done in GMT. The
+        local time zone MUST NOT influence the calculation or comparison
+        of an age or expiration time.
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 166]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - If an HTTP header incorrectly carries a date value with a time
+        zone other than GMT, it MUST be converted into GMT using the
+        most conservative possible conversion.
+
+19.4 Differences Between HTTP Entities and RFC 2045 Entities
+
+   HTTP/1.1 uses many of the constructs defined for Internet Mail (RFC
+   822 [9]) and the Multipurpose Internet Mail Extensions (MIME [7]) to
+   allow entities to be transmitted in an open variety of
+   representations and with extensible mechanisms. However, RFC 2045
+   discusses mail, and HTTP has a few features that are different from
+   those described in RFC 2045. These differences were carefully chosen
+   to optimize performance over binary connections, to allow greater
+   freedom in the use of new media types, to make date comparisons
+   easier, and to acknowledge the practice of some early HTTP servers
+   and clients.
+
+   This appendix describes specific areas where HTTP differs from RFC
+   2045. Proxies and gateways to strict MIME environments SHOULD be
+   aware of these differences and provide the appropriate conversions
+   where necessary. Proxies and gateways from MIME environments to HTTP
+   also need to be aware of the differences because some conversions
+   might be required.
+
+19.4.1 MIME-Version
+
+   HTTP is not a MIME-compliant protocol. However, HTTP/1.1 messages MAY
+   include a single MIME-Version general-header field to indicate what
+   version of the MIME protocol was used to construct the message. Use
+   of the MIME-Version header field indicates that the message is in
+   full compliance with the MIME protocol (as defined in RFC 2045[7]).
+   Proxies/gateways are responsible for ensuring full compliance (where
+   possible) when exporting HTTP messages to strict MIME environments.
+
+       MIME-Version   = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
+
+   MIME version "1.0" is the default for use in HTTP/1.1. However,
+   HTTP/1.1 message parsing and semantics are defined by this document
+   and not the MIME specification.
+
+19.4.2 Conversion to Canonical Form
+
+   RFC 2045 [7] requires that an Internet mail entity be converted to
+   canonical form prior to being transferred, as described in section 4
+   of RFC 2049 [48]. Section 3.7.1 of this document describes the forms
+   allowed for subtypes of the "text" media type when transmitted over
+   HTTP. RFC 2046 requires that content with a type of "text" represent
+   line breaks as CRLF and forbids the use of CR or LF outside of line
+
+
+
+Fielding, et al.            Standards Track                   [Page 167]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a
+   line break within text content when a message is transmitted over
+   HTTP.
+
+   Where it is possible, a proxy or gateway from HTTP to a strict MIME
+   environment SHOULD translate all line breaks within the text media
+   types described in section 3.7.1 of this document to the RFC 2049
+   canonical form of CRLF. Note, however, that this might be complicated
+   by the presence of a Content-Encoding and by the fact that HTTP
+   allows the use of some character sets which do not use octets 13 and
+   10 to represent CR and LF, as is the case for some multi-byte
+   character sets.
+
+   Implementors should note that conversion will break any cryptographic
+   checksums applied to the original content unless the original content
+   is already in canonical form. Therefore, the canonical form is
+   recommended for any content that uses such checksums in HTTP.
+
+19.4.3 Conversion of Date Formats
+
+   HTTP/1.1 uses a restricted set of date formats (section 3.3.1) to
+   simplify the process of date comparison. Proxies and gateways from
+   other protocols SHOULD ensure that any Date header field present in a
+   message conforms to one of the HTTP/1.1 formats and rewrite the date
+   if necessary.
+
+19.4.4 Introduction of Content-Encoding
+
+   RFC 2045 does not include any concept equivalent to HTTP/1.1's
+   Content-Encoding header field. Since this acts as a modifier on the
+   media type, proxies and gateways from HTTP to MIME-compliant
+   protocols MUST either change the value of the Content-Type header
+   field or decode the entity-body before forwarding the message. (Some
+   experimental applications of Content-Type for Internet mail have used
+   a media-type parameter of ";conversions=<content-coding>" to perform
+   a function equivalent to Content-Encoding. However, this parameter is
+   not part of RFC 2045.)
+
+19.4.5 No Content-Transfer-Encoding
+
+   HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
+   2045. Proxies and gateways from MIME-compliant protocols to HTTP MUST
+   remove any non-identity CTE ("quoted-printable" or "base64") encoding
+   prior to delivering the response message to an HTTP client.
+
+   Proxies and gateways from HTTP to MIME-compliant protocols are
+   responsible for ensuring that the message is in the correct format
+   and encoding for safe transport on that protocol, where "safe
+
+
+
+Fielding, et al.            Standards Track                   [Page 168]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   transport" is defined by the limitations of the protocol being used.
+   Such a proxy or gateway SHOULD label the data with an appropriate
+   Content-Transfer-Encoding if doing so will improve the likelihood of
+   safe transport over the destination protocol.
+
+19.4.6 Introduction of Transfer-Encoding
+
+   HTTP/1.1 introduces the Transfer-Encoding header field (section
+   14.41). Proxies/gateways MUST remove any transfer-coding prior to
+   forwarding a message via a MIME-compliant protocol.
+
+   A process for decoding the "chunked" transfer-coding (section 3.6)
+   can be represented in pseudo-code as:
+
+       length := 0
+       read chunk-size, chunk-extension (if any) and CRLF
+       while (chunk-size > 0) {
+          read chunk-data and CRLF
+          append chunk-data to entity-body
+          length := length + chunk-size
+          read chunk-size and CRLF
+       }
+       read entity-header
+       while (entity-header not empty) {
+          append entity-header to existing header fields
+          read entity-header
+       }
+       Content-Length := length
+       Remove "chunked" from Transfer-Encoding
+
+19.4.7 MHTML and Line Length Limitations
+
+   HTTP implementations which share code with MHTML [45] implementations
+   need to be aware of MIME line length limitations. Since HTTP does not
+   have this limitation, HTTP does not fold long lines. MHTML messages
+   being transported by HTTP follow all conventions of MHTML, including
+   line length limitations and folding, canonicalization, etc., since
+   HTTP transports all message-bodies as payload (see section 3.7.2) and
+   does not interpret the content or any MIME header lines that might be
+   contained therein.
+
+19.5 Additional Features
+
+   RFC 1945 and RFC 2068 document protocol elements used by some
+   existing HTTP implementations, but not consistently and correctly
+   across most HTTP/1.1 applications. Implementors are advised to be
+   aware of these features, but cannot rely upon their presence in, or
+   interoperability with, other HTTP/1.1 applications. Some of these
+
+
+
+Fielding, et al.            Standards Track                   [Page 169]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   describe proposed experimental features, and some describe features
+   that experimental deployment found lacking that are now addressed in
+   the base HTTP/1.1 specification.
+
+   A number of other headers, such as Content-Disposition and Title,
+   from SMTP and MIME are also often implemented (see RFC 2076 [37]).
+
+19.5.1 Content-Disposition
+
+   The Content-Disposition response-header field has been proposed as a
+   means for the origin server to suggest a default filename if the user
+   requests that the content is saved to a file. This usage is derived
+   from the definition of Content-Disposition in RFC 1806 [35].
+
+        content-disposition = "Content-Disposition" ":"
+                              disposition-type *( ";" disposition-parm )
+        disposition-type = "attachment" | disp-extension-token
+        disposition-parm = filename-parm | disp-extension-parm
+        filename-parm = "filename" "=" quoted-string
+        disp-extension-token = token
+        disp-extension-parm = token "=" ( token | quoted-string )
+
+   An example is
+
+        Content-Disposition: attachment; filename="fname.ext"
+
+   The receiving user agent SHOULD NOT respect any directory path
+   information present in the filename-parm parameter, which is the only
+   parameter believed to apply to HTTP implementations at this time. The
+   filename SHOULD be treated as a terminal component only.
+
+   If this header is used in a response with the application/octet-
+   stream content-type, the implied suggestion is that the user agent
+   should not display the response, but directly enter a `save response
+   as...' dialog.
+
+   See section 15.5 for Content-Disposition security issues.
+
+19.6 Compatibility with Previous Versions
+
+   It is beyond the scope of a protocol specification to mandate
+   compliance with previous versions. HTTP/1.1 was deliberately
+   designed, however, to make supporting previous versions easy. It is
+   worth noting that, at the time of composing this specification
+   (1996), we would expect commercial HTTP/1.1 servers to:
+
+      - recognize the format of the Request-Line for HTTP/0.9, 1.0, and
+        1.1 requests;
+
+
+
+Fielding, et al.            Standards Track                   [Page 170]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+      - understand any valid request in the format of HTTP/0.9, 1.0, or
+        1.1;
+
+      - respond appropriately with a message in the same major version
+        used by the client.
+
+   And we would expect HTTP/1.1 clients to:
+
+      - recognize the format of the Status-Line for HTTP/1.0 and 1.1
+        responses;
+
+      - understand any valid response in the format of HTTP/0.9, 1.0, or
+        1.1.
+
+   For most implementations of HTTP/1.0, each connection is established
+   by the client prior to the request and closed by the server after
+   sending the response. Some implementations implement the Keep-Alive
+   version of persistent connections described in section 19.7.1 of RFC
+   2068 [33].
+
+19.6.1 Changes from HTTP/1.0
+
+   This section summarizes major differences between versions HTTP/1.0
+   and HTTP/1.1.
+
+19.6.1.1 Changes to Simplify Multi-homed Web Servers and Conserve IP
+         Addresses
+
+   The requirements that clients and servers support the Host request-
+   header, report an error if the Host request-header (section 14.23) is
+   missing from an HTTP/1.1 request, and accept absolute URIs (section
+   5.1.2) are among the most important changes defined by this
+   specification.
+
+   Older HTTP/1.0 clients assumed a one-to-one relationship of IP
+   addresses and servers; there was no other established mechanism for
+   distinguishing the intended server of a request than the IP address
+   to which that request was directed. The changes outlined above will
+   allow the Internet, once older HTTP clients are no longer common, to
+   support multiple Web sites from a single IP address, greatly
+   simplifying large operational Web servers, where allocation of many
+   IP addresses to a single host has created serious problems. The
+   Internet will also be able to recover the IP addresses that have been
+   allocated for the sole purpose of allowing special-purpose domain
+   names to be used in root-level HTTP URLs. Given the rate of growth of
+   the Web, and the number of servers already deployed, it is extremely
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 171]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   important that all implementations of HTTP (including updates to
+   existing HTTP/1.0 applications) correctly implement these
+   requirements:
+
+      - Both clients and servers MUST support the Host request-header.
+
+      - A client that sends an HTTP/1.1 request MUST send a Host header.
+
+      - Servers MUST report a 400 (Bad Request) error if an HTTP/1.1
+        request does not include a Host request-header.
+
+      - Servers MUST accept absolute URIs.
+
+19.6.2 Compatibility with HTTP/1.0 Persistent Connections
+
+   Some clients and servers might wish to be compatible with some
+   previous implementations of persistent connections in HTTP/1.0
+   clients and servers. Persistent connections in HTTP/1.0 are
+   explicitly negotiated as they are not the default behavior. HTTP/1.0
+   experimental implementations of persistent connections are faulty,
+   and the new facilities in HTTP/1.1 are designed to rectify these
+   problems. The problem was that some existing 1.0 clients may be
+   sending Keep-Alive to a proxy server that doesn't understand
+   Connection, which would then erroneously forward it to the next
+   inbound server, which would establish the Keep-Alive connection and
+   result in a hung HTTP/1.0 proxy waiting for the close on the
+   response. The result is that HTTP/1.0 clients must be prevented from
+   using Keep-Alive when talking to proxies.
+
+   However, talking to proxies is the most important use of persistent
+   connections, so that prohibition is clearly unacceptable. Therefore,
+   we need some other mechanism for indicating a persistent connection
+   is desired, which is safe to use even when talking to an old proxy
+   that ignores Connection. Persistent connections are the default for
+   HTTP/1.1 messages; we introduce a new keyword (Connection: close) for
+   declaring non-persistence. See section 14.10.
+
+   The original HTTP/1.0 form of persistent connections (the Connection:
+   Keep-Alive and Keep-Alive header) is documented in RFC 2068. [33]
+
+19.6.3 Changes from RFC 2068
+
+   This specification has been carefully audited to correct and
+   disambiguate key word usage; RFC 2068 had many problems in respect to
+   the conventions laid out in RFC 2119 [34].
+
+   Clarified which error code should be used for inbound server failures
+   (e.g. DNS failures). (Section 10.5.5).
+
+
+
+Fielding, et al.            Standards Track                   [Page 172]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   CREATE had a race that required an Etag be sent when a resource is
+   first created. (Section 10.2.2).
+
+   Content-Base was deleted from the specification: it was not
+   implemented widely, and there is no simple, safe way to introduce it
+   without a robust extension mechanism. In addition, it is used in a
+   similar, but not identical fashion in MHTML [45].
+
+   Transfer-coding and message lengths all interact in ways that
+   required fixing exactly when chunked encoding is used (to allow for
+   transfer encoding that may not be self delimiting); it was important
+   to straighten out exactly how message lengths are computed. (Sections
+   3.6, 4.4, 7.2.2, 13.5.2, 14.13, 14.16)
+
+   A content-coding of "identity" was introduced, to solve problems
+   discovered in caching. (section 3.5)
+
+   Quality Values of zero should indicate that "I don't want something"
+   to allow clients to refuse a representation. (Section 3.9)
+
+   The use and interpretation of HTTP version numbers has been clarified
+   by RFC 2145. Require proxies to upgrade requests to highest protocol
+   version they support to deal with problems discovered in HTTP/1.0
+   implementations (Section 3.1)
+
+   Charset wildcarding is introduced to avoid explosion of character set
+   names in accept headers. (Section 14.2)
+
+   A case was missed in the Cache-Control model of HTTP/1.1; s-maxage
+   was introduced to add this missing case. (Sections 13.4, 14.8, 14.9,
+   14.9.3)
+
+   The Cache-Control: max-age directive was not properly defined for
+   responses. (Section 14.9.3)
+
+   There are situations where a server (especially a proxy) does not
+   know the full length of a response but is capable of serving a
+   byterange request. We therefore need a mechanism to allow byteranges
+   with a content-range not indicating the full length of the message.
+   (Section 14.16)
+
+   Range request responses would become very verbose if all meta-data
+   were always returned; by allowing the server to only send needed
+   headers in a 206 response, this problem can be avoided. (Section
+   10.2.7, 13.5.3, and 14.27)
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 173]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Fix problem with unsatisfiable range requests; there are two cases:
+   syntactic problems, and range doesn't exist in the document. The 416
+   status code was needed to resolve this ambiguity needed to indicate
+   an error for a byte range request that falls outside of the actual
+   contents of a document. (Section 10.4.17, 14.16)
+
+   Rewrite of message transmission requirements to make it much harder
+   for implementors to get it wrong, as the consequences of errors here
+   can have significant impact on the Internet, and to deal with the
+   following problems:
+
+      1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
+         this was incorrectly placing a requirement on the behavior of
+         an implementation of a future version of HTTP/1.x
+
+      2. Made it clear that user-agents should retry requests, not
+         "clients" in general.
+
+      3. Converted requirements for clients to ignore unexpected 100
+         (Continue) responses, and for proxies to forward 100 responses,
+         into a general requirement for 1xx responses.
+
+      4. Modified some TCP-specific language, to make it clearer that
+         non-TCP transports are possible for HTTP.
+
+      5. Require that the origin server MUST NOT wait for the request
+         body before it sends a required 100 (Continue) response.
+
+      6. Allow, rather than require, a server to omit 100 (Continue) if
+         it has already seen some of the request body.
+
+      7. Allow servers to defend against denial-of-service attacks and
+         broken clients.
+
+   This change adds the Expect header and 417 status code. The message
+   transmission requirements fixes are in sections 8.2, 10.4.18,
+   8.1.2.2, 13.11, and 14.20.
+
+   Proxies should be able to add Content-Length when appropriate.
+   (Section 13.5.2)
+
+   Clean up confusion between 403 and 404 responses. (Section 10.4.4,
+   10.4.5, and 10.4.11)
+
+   Warnings could be cached incorrectly, or not updated appropriately.
+   (Section 13.1.2, 13.2.4, 13.5.2, 13.5.3, 14.9.3, and 14.46) Warning
+   also needed to be a general header, as PUT or other methods may have
+   need for it in requests.
+
+
+
+Fielding, et al.            Standards Track                   [Page 174]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+   Transfer-coding had significant problems, particularly with
+   interactions with chunked encoding. The solution is that transfer-
+   codings become as full fledged as content-codings. This involves
+   adding an IANA registry for transfer-codings (separate from content
+   codings), a new header field (TE) and enabling trailer headers in the
+   future. Transfer encoding is a major performance benefit, so it was
+   worth fixing [39]. TE also solves another, obscure, downward
+   interoperability problem that could have occurred due to interactions
+   between authentication trailers, chunked encoding and HTTP/1.0
+   clients.(Section 3.6, 3.6.1, and 14.39)
+
+   The PATCH, LINK, UNLINK methods were defined but not commonly
+   implemented in previous versions of this specification. See RFC 2068
+   [33].
+
+   The Alternates, Content-Version, Derived-From, Link, URI, Public and
+   Content-Base header fields were defined in previous versions of this
+   specification, but not commonly implemented. See RFC 2068 [33].
+
+20 Index
+
+   Please see the PostScript version of this RFC for the INDEX.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 175]
+
+RFC 2616                        HTTP/1.1                       June 1999
+
+
+21.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Fielding, et al.            Standards Track                   [Page 176]
+
+
+

+

+
\ No newline at end of file diff --git a/htdocs/index.php b/htdocs/index.php new file mode 100644 index 00000000..1c77f8cb --- /dev/null +++ b/htdocs/index.php @@ -0,0 +1,47 @@ + $value) { + error_log( "caldav: DBG: $name: >>$key<< = >>$value<<"); + if ( $recursive && (gettype($value) == 'array' || gettype($value) == 'object') ) { + dbg_log_array( "$name"."[$key]", $value, $recursive ); + } + } +} + +$raw_headers = apache_request_headers(); +$raw_post = file_get_contents ( 'php://input'); + +if ( $debugging && isset($_GET['method']) ) { + $_SERVER['REQUEST_METHOD'] = $_GET['method']; +} + +switch ( $_SERVER['REQUEST_METHOD'] ) { + case 'OPTIONS': + include_once("caldav-OPTIONS.php"); + break; + + case 'REPORT': + include_once("caldav-REPORT.php"); + break; + + case 'PUT': + include_once("caldav-PUT.php"); + break; + + default: + error_log("Unhandled request method >>".$_SERVER['REQUEST_METHOD']."<<"); + dbg_log_array( 'HEADERS', $raw_headers ); + dbg_log_array( '_SERVER', $_SERVER, true ); + error_log( "caldav: DBG: RAW: ".str_replace("\n", "", str_replace("\r", "", $raw_post))); +} + + +?> \ No newline at end of file diff --git a/inc/always.php b/inc/always.php new file mode 100644 index 00000000..9efb0f21 --- /dev/null +++ b/inc/always.php @@ -0,0 +1,21 @@ +sysabbr = 'caldav'; +$c->admin_email = 'andrew@catalyst.net.nz'; +$c->system_name = "Andrew's CalDAV Server"; + +error_log( $c->sysabbr.": DBG: ======================================= Start $PHP_SELF for $HTTP_HOST on $_SERVER[SERVER_NAME]" ); +if ( file_exists("/etc/caldav/".$_SERVER['SERVER_NAME']."-conf.php") ) { + include_once("/etc/caldav/".$_SERVER['SERVER_NAME']."-conf.php"); +} +else if ( file_exists("../config/config.php") ) { + include_once("../config/config.php"); +} +else { + include_once("caldav_configuration_missing.php"); + exit; +} + +include_once("iCalendar.php"); + +?> \ No newline at end of file diff --git a/inc/caldav-OPTIONS.php b/inc/caldav-OPTIONS.php new file mode 100644 index 00000000..e6933b4f --- /dev/null +++ b/inc/caldav-OPTIONS.php @@ -0,0 +1,6 @@ + \ No newline at end of file diff --git a/inc/caldav-PUT.php b/inc/caldav-PUT.php new file mode 100644 index 00000000..e38e42dc --- /dev/null +++ b/inc/caldav-PUT.php @@ -0,0 +1,105 @@ + $v ) { + + switch ( $v['tag'] ) { + + case 'URN:IETF:PARAMS:XML:NS:CALDAV:CALENDAR-QUERY': + if ( $v['type'] == "open" ) { + $putnum++; + $put_type = substr($v['tag'],30); + $put[$putnum]['type'] = $put_type; + } + else { + unset($put_type); + } + break; + + case 'DAV::PROP': + if ( isset($put_type) ) { + if ( $v['type'] == "open" ) { + $put_properties = array(); + } + else if ( $v['type'] == "close" ) { + $put[$putnum]['properties'] = $put_properties; + unset($put_properties); + } + else { + error_log( "DBG: Unexpected DAV::PROP type of ".$v['type'] ); + } + } + else { + error_log( "DBG: Unexpected DAV::PROP type of ".$v['type']." when no active put type."); + } + break; + + case 'DAV::GETETAG': + if ( isset($put_properties) ) { + if ( $v['type'] == "complete" ) { + $put_properties['GETETAG'] = 1; + } + } + break; + + default: + error_log("caldav: DBG: Unhandled tag >>".$v['tag']."<<"); + } +} + +dbg_log_array( 'RPT', $put_request, true ); + +dbg_log_array( 'REPORT', $put, true ); + +header("Content-type: text/xml"); + +echo << + + + http://mycaldav/?andrewmcmillan.ics + + + "fffff-abcd1" + BEGIN:VCALENDAR +VERSION:2.0 +PRODID:-//Andrew's CalDAV Server//PHP//0.0.1 +EOXML; + +echo iCalendar::vTimeZone("Pacific/Auckland"); +$event = new vEvent( '20060517T150000Z', 'PT2H', 'andrew@catalyst.net.nz', '', 'A Test Event for Andrew' ); +echo $event->ToString(); + +echo << + + HTTP/1.1 200 OK + + + +EOXML; + +?> \ No newline at end of file diff --git a/inc/caldav-REPORT.php b/inc/caldav-REPORT.php new file mode 100644 index 00000000..630a644c --- /dev/null +++ b/inc/caldav-REPORT.php @@ -0,0 +1,108 @@ + $v ) { + + switch ( $v['tag'] ) { + + case 'URN:IETF:PARAMS:XML:NS:CALDAV:CALENDAR-QUERY': + if ( $v['type'] == "open" ) { + $reportnum++; + $report_type = substr($v['tag'],30); + $report[$reportnum]['type'] = $report_type; + } + else { + unset($report_type); + } + break; + + case 'DAV::PROP': + if ( isset($report_type) ) { + if ( $v['type'] == "open" ) { + $report_properties = array(); + } + else if ( $v['type'] == "close" ) { + $report[$reportnum]['properties'] = $report_properties; + unset($report_properties); + } + else { + error_log( "DBG: Unexpected DAV::PROP type of ".$v['type'] ); + } + } + else { + error_log( "DBG: Unexpected DAV::PROP type of ".$v['type']." when no active report type."); + } + break; + + case 'DAV::GETETAG': + if ( isset($report_properties) ) { + if ( $v['type'] == "complete" ) { + $report_properties['GETETAG'] = 1; + } + } + break; + + default: + error_log("caldav: DBG: Unhandled tag >>".$v['tag']."<<"); + } +} + +dbg_log_array( 'RPT', $rpt_request, true ); + +dbg_log_array( 'REPORT', $report, true ); + +header("Content-type: text/xml"); + +echo << + + + http://mycaldav/?andrewmcmillan.ics + + + "fffff-abcd1" + BEGIN:VCALENDAR +VERSION:2.0 +PRODID:-//Andrew's CalDAV Server//PHP//0.0.1 +EOXML; + +echo iCalendar::vTimeZone("Pacific/Auckland"); +$event = new vEvent( '20060517T150000Z', 'PT2H', 'andrew@catalyst.net.nz', '', 'A Test Event for Andrew' ); +echo $event->ToString(); + +echo << + + HTTP/1.1 200 OK + + + +EOXML; + +?> \ No newline at end of file diff --git a/inc/iCalendar.php b/inc/iCalendar.php new file mode 100644 index 00000000..d67c2761 --- /dev/null +++ b/inc/iCalendar.php @@ -0,0 +1,231 @@ + +* @copyright Catalyst IT Ltd +* @license http://gnu.org/copyleft/gpl.html GNU GPL v2 +*/ + +/** +* A Class for handling participants to events +* +* @package caldav +*/ +class Participant { + /**#@+ + * @access private + */ + + /** + * Participant e-mail + * @var email string + */ + var $email; + + /** + * Status of participant in relation to the event + * @var status string + */ + var $status; + + /** + * Role of participant in relation to event + * @var email string + */ + var $role; + /**#@-*/ + + function Participant( $email, $status="NEEDS-ACTION", $role="ATTENDEE" ) { + $this->email = $email; + $this->status = $status; + $this->role = $role; + } + + function ToString() { + $rv = sprintf( "ATTENDEE;PARTSTAT=%s%s:%s\n", $this->status, ($this-role == "ATTENDEE" ? "" : "ROLE=$this->role"), $this->email ); + return $rv; + } +} + +/** +* A Class for handling Evends on a calendar +* +* @package caldav +*/ +class vEvent { + /**#@+ + * @access private + */ + + /** + * List of participants in this event + * @var participants array + */ + var $participants = array(); + + /** + * The start time for the event + * @var start datetime + */ + var $start; + + /** + * The duration of the event + * @var duration interval + */ + var $duration; + + /** + * The organizer of othe event + * @var organizer string + */ + var $organizer; + + /** + * The status of the event + * @var status string + */ + var $status; + + /** + * A summary description of the event + * @var summary string + */ + var $summary; + + /** + * A last modified timestamp + * @var modified int + */ + var $modified; + + /** + * A sequence for different revisions of the event + * @var sequence integer + */ + var $sequence; + + /** + * A unique ID for the event + * @var uid string + */ + var $uid; + + /** + * A GUID for the event + * @var guid string + */ + var $guid; + /**#@-*/ + + function vEvent( $start, $duration="PT1H", $organizer="", $status="TENTATIVE", $summary="" ) { + global $c; + + $this->participants = array(); + $this->start = $start; + $this->duration = $duration; + $this->organizer = $organizer; + $this->status = $status; + $this->summary = $summary; + $this->modified = iCalendar::EpochTS(time()); + $this->sequence = 1; + $this->uid = sprintf( "%s@%s", time() * 1000 + rand(0,1000), $c->domainname); + $this->guid = sprintf( "%s@%s", time() * 1000 + rand(0,1000), $c->domainname); + } + + function AddParticipant( $email, $status, $role ) { + $this->participants[] = new Participant($email,$status,$role); + } + +/* +BEGIN:VEVENT +ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR:mailto:cyrus@example.com +ATTENDEE;PARTSTAT=NEEDS-ACTION:mailto:lisa@example.com +DTSTAMP:20060206T001220Z +DTSTART;TZID=US/Eastern:20060104T100000 +DURATION:PT1H +LAST-MODIFIED:20060206T001330Z +ORGANIZER:mailto:cyrus@example.com +SEQUENCE:1 +STATUS:TENTATIVE +SUMMARY:Event #3 +UID:DC6C50A017428C5216A2F1CD@example.com +X-ABC-GUID:E1CX5Dr-0007ym-Hz@example.com +END:VEVENT +*/ + function ToString() { + $participants = ""; + foreach( $this->participants AS $k => $p ) { + $participants .= $p->ToString(); + } + $fmt = <<start, $this->duration, $this->modified, + $this->organizer, $this->sequence, $this->status, $this->summary, $this->uid, $this->guid ); + return $string; + } +} + + +/** +* A Class for handling iCalendar data +* +* @package caldav +*/ +class iCalendar { + + function iCalendar() { + } + + function EpochTS($epoch) { + $ts = date('Ymd\THis\Z', $epoch ); + return $ts; + } + + function vTimeZone( $tzname ) { + switch ( $tzname ) { + case 'Pacific/Auckland': + default: + $tzstring = << \ No newline at end of file diff --git a/testing/delete-meeting.txt b/testing/delete-meeting.txt new file mode 100644 index 00000000..f4fa4417 --- /dev/null +++ b/testing/delete-meeting.txt @@ -0,0 +1,4 @@ +DELETE /?andrewmcmillan.ics/20060509T195919Z.ics HTTP/1.1 +Host: mycaldav +User-Agent: Evolution/1.6.1 + diff --git a/testing/full-options-response.txt b/testing/full-options-response.txt new file mode 100644 index 00000000..88da2918 --- /dev/null +++ b/testing/full-options-response.txt @@ -0,0 +1,7 @@ +HTTP/1.1 200 OK +Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE +Allow: PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL +DAV: 1, 2, 3, access-control, calendar-access +Date: Fri, 11 May 2006 09:32:12 GMT +Content-Length: 0 + diff --git a/testing/sample-tcp-stream.txt b/testing/sample-tcp-stream.txt new file mode 100644 index 00000000..775e0b7c --- /dev/null +++ b/testing/sample-tcp-stream.txt @@ -0,0 +1,87 @@ +OPTIONS /?andrewmcmillan.ics HTTP/1.1 + +Host: mycaldav + +User-Agent: Evolution/1.6.1 + + + +HTTP/1.1 200 OK + +Date: Tue, 09 May 2006 00:40:08 GMT + +Server: Apache/2.0.55 (Debian) DAV/2 PHP/4.4.2-1+b1 + +X-Powered-By: PHP/4.4.2-1+b1 + +Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL + +DAV: 1, 2, 3, access-control, calendar-access + +Transfer-Encoding: chunked + +Content-Type: text/html; charset=UTF-8 + + + +0 + + + +OPTIONS /?andrewmcmillan.ics HTTP/1.1 + +Host: mycaldav + +User-Agent: Evolution/1.6.1 + + + +HTTP/1.1 200 OK + +Date: Tue, 09 May 2006 00:40:08 GMT + +Server: Apache/2.0.55 (Debian) DAV/2 PHP/4.4.2-1+b1 + +X-Powered-By: PHP/4.4.2-1+b1 + +Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL + +DAV: 1, 2, 3, access-control, calendar-access + +Transfer-Encoding: chunked + +Content-Type: text/html; charset=UTF-8 + + + +0 + + + +REPORT /?andrewmcmillan.ics HTTP/1.1 + +Host: mycaldav + +Content-Length: 301 + +Depth: 1 + +User-Agent: Evolution/1.6.1 + +Content-Type: text/xml + + + + + + + + + + + + + + + + diff --git a/testing/schedule-meeting.txt b/testing/schedule-meeting.txt new file mode 100644 index 00000000..e928664f --- /dev/null +++ b/testing/schedule-meeting.txt @@ -0,0 +1,77 @@ +PUT /?andrewmcmillan.ics/20060509T200223Z.ics HTTP/1.1 +Host: mycaldav +Content-Length: 1049 +If-None-Match: * +User-Agent: Evolution/1.6.1 +Content-Type: text/calendar + +BEGIN:VCALENDAR +CALSCALE:GREGORIAN +PRODID:-//Ximian//NONSGML Evolution Calendar//EN +VERSION:2.0 +BEGIN:VEVENT +UID:20060509T200218Z-7351-1000-1-9@ubu +DTSTAMP:20060509T200218Z +DTSTART;TZID=/softwarestudio.org/Olson_20011030_5/Pacific/Auckland: + 20060510T100000 +DTEND;TZID=/softwarestudio.org/Olson_20011030_5/Pacific/Auckland: + 20060510T110000 +SUMMARY:Alistair +X-EVOLUTION-CALDAV-HREF:http: + //mycaldav/?andrewmcmillan.ics/20060509T200223Z.ics +BEGIN:VALARM +X-EVOLUTION-ALARM-UID:20060509T200218Z-10149-1000-1-48@ubu +ACTION:DISPLAY +TRIGGER;VALUE=DURATION;RELATED=START:-PT15M +DESCRIPTION:Alistair +END:VALARM +END:VEVENT +BEGIN:VTIMEZONE +TZID:/softwarestudio.org/Olson_20011030_5/Pacific/Auckland +X-LIC-LOCATION:Pacific/Auckland +BEGIN:STANDARD +TZOFFSETFROM:+1300 +TZOFFSETTO:+1200 +TZNAME:NZST +DTSTART:19700315T030000 +RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=3SU;BYMONTH=3 +END:STANDARD +BEGIN:DAYLIGHT +TZOFFSETFROM:+1200 +TZOFFSETTO:+1300 +TZNAME:NZDT +DTSTART:19701004T020000 +RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=10 +END:DAYLIGHT +END:VTIMEZONE +END:VCALENDAR +HTTP/1.1 200 OK + +Date: Tue, 09 May 2006 20:02:23 GMT +Server: Apache/2.0.55 (Debian) DAV/2 PHP/4.4.2-1+b1 +X-Powered-By: PHP/4.4.2-1+b1 +Transfer-Encoding: chunked +Content-Type: text/html; charset=UTF-8 + +0 + +REPORT /?andrewmcmillan.ics HTTP/1.1 +Host: mycaldav +Content-Length: 301 +Depth: 1 +User-Agent: Evolution/1.6.1 +Content-Type: text/xml + + + + + + + + + + + + + +

NIvui@1J~l+>Y9-}1Sx&QXQvXC{o6Oa*;iJm=ZdVKVT_Dw5k4+A<20Q2 z7eEAZ)AJ@eAs5O=4*)$RUhG6}p%aj$_wiDHd-Ys|?J=Q`BnYrW3|1l!W=~-E7}E2- zy+@^MMRlqL^|s*cxPt*F^>~hnwQ$HQJ1hg8L47hcUoz%WJzUEtXc_>NXeTk+-*J*FePBFJy+-?*4Jp zhfH z+8>AAs{{bq?8&y(RnfHyB~>Wy`GeeEeQwR44HZy*Qt9<3?_%XF-u1e>@>9-6+nIoZ znE($a5mQn*f~H3kanUfD1;+bgd*FO}(dxA8-T|&gf-RAB z2Q=*`<*MOl{E~S)5OcG|E+Jmhfe?xs@d6 z!%Y*rwjz7HVtC{$(}crtOsQAH)S(7EL|lHq*Zr|vOV*7wR{`0o$PXjGm7(bCkjMQ{ zN@3{_p!YkaWyHfBpAQBqBci&@$jd(grm{63CdwcZ4siHNKz;0iTa9Z4?7oe)yU zCA}pZ7$U8GNh=DCTj2aVXT+;h`?rWEoq~gEnJ~&P5&r%fKcb|+-#+>??0Gmw!VK`@ zwOT^d_;!_>C>Q2OPET#G%P$CgSQsHWx7<5BJG8RQh#W9_7k~zWrPZEzMUmN*b;o{9iu9CHa&HzW{iRKkQo8a; zTfbk$Y=`XkHBQ+k8EqR$Q;V?jq2>vnkT-G>&+#IQNHcU+{2BWckP^KL(pzZ_`dg_X z0t#Kon9c)eRALlHm$Y(d;%n>5YWK?&-&YnHxybkdA8&}=D!Zpq^^vCCx!=8yf&V#x zpO8t%tjeffH$8&Api_?(&!A@BGbqG8+dEWdxgcK`%Gg*9$|_G>ERQ%d37l_~kH9{z z{FWqMXG(}ZSeaTOn18dzJt=o9QA7a7*IS(JO0h>R^X=v}i$NL;f4Fe<1_@SEkpa;@ zTb~~J!b4WWP*F^L+r&M5^jw^ui?`-duplY46%e%jYoywJ`6Jt-yBe9`v4~5Qgp)FL z@3$pQ;pZPduW&y}j*r4%sdWAN3aVh!<_pUfLx-~yHs{i2(LAy{+N(0hm;9M(wbfa@ z!Q%&5ZH!X#@S~RfvRjo$j@1V&;{;zN7DqPv5Iy=w;D%N3m1|&qv!kWaphp->C_|(? z$$=9Y?qL>Ld-q;DY}<=%htNV3=s1=kSYR&nOkm?1flf^-|%bLdC^~w9Dw~%FN8kmev$} z&e>)D16=%x3RGF%@RK<__AOvT@F@>!)ThAxyx=&$Piqi}EPrp5MHH%mWBp=hZDZBg zO%u^D;POwyh#WC#wL)Y}w!%e)!zrS#wWNNr9kAA2(kK{A>oJ&9`6^#C;BcJqO z-}c(=HX|PL3BRBM%`E_Vin?M!#?3o@SkkT)8lZyD^x>8;q9Vc_&@ghlmMWTy>?(HO=JXrq^wpML-b-&EmyAO`W5fz@wR~rqg5AUkxdY4?S(fXRBt=A>RW! z)0H=AsBt0vmHx`q85cf%+~>hyzSu}@m+YJkX7(}PJ%vVi!r0ExEEa%B_}e3IFz_54 zZ)`MyD;Wo)S+vostLlU%o_Nv#PB>%sLFwMjs_cn}FOI}HJ4;lfP)$8h61LZ8yL8=N z{OiqB9ZlQxTn6i=T_(>e|BB0q*pGroTXk|u5QrY@k1p?t)zXp49rG6?Mv*+ z3-&GcIvaQ&?dzt{w`GvIbIdgMxG$RcL%=EZx{QEI*|eh-E~O5vLNt=37B;PLu0+kk z}G0yg;KQ9-+rPP8zGJ^*?K~-;rM; z-`O`rCXjviTM!(`3mgV)9gv@Ym_B+&c^?L5n>$NxyWu+EJutZ>uvR*&?5fc_57W;z zrYvUUGrhO1#)IQqfvt;dt1N1!#Um9WNV^Q5CRMT#eFPbqoaA#mavraEJY^o$`en8u z^8sjBMk9lp8HHx5JMxVicpcmKl1MxxD=E0L6a5qtR8`wZz#m2n)5>`U0^WMcN$LHo zrjyCvmdUs0#zU4DzVnPK=y5v9EQPbjlu=8Uh6LX^ykBS=G)rMy*GNP%&sxsV^jiWI zMyO>3acw7=ZW-Nn3drc*z0&Ihvprmc{5P_H-vjCf^jZ%8qxnr2PrhPvssV+v0Q(JQg{Y0>R zAV*C~3u^Lme#hANRJzp#puKo_2pbK>j^Vp^RRp_+JuJwkCSO8A`(FC=wV7o}6z`!i zIDn=5KnI+bNVR?qCw(>g_o^3eA~Mht&yiBwgmRe5*i;`Y;NRtr^(%C0`0;y=R4X-H z$4mg}FbvQbLb4k=|i zc1|XJnbVnqTPqzN#nb$0M94NMjs;la8?p=sb{HI<-`aDCK0ask=<&eeLTiwG4RqPkrNgIHo+f(lMt^?T-L}R*9kj&uq}fCW}l< zPi2&81|M1=^Ps-m5w(;G9T{qTxP__Y}j@ z)G574d0>~KuCA>JGXCu!EYyN27*sFT%Fwp#{gr;=f}j@V*p#{Uk&j1j2@vb2srsc+ zF->$I9U1mFw&BnZY*|dEPBNE$-6zb8QYfVA=FP`E|9Q@_Zp$>N$@GQDODU0^phl6Z z)UwC&egzE3l!^niC?u~7-e`U$XyG4vlvk%RgZ$RgkMxq&)TD?={n-9YSwAkEM4#^7 z(~qGk{rE_SDG2E}E>8@)4b#q|rnXL{Ph3rGPVmY1_Ie&D{cS^*Hkn)Y`FhIA3H$*d z$R2Y|r_EPao6YG~WSWYkZvVrnb@%WWI8!YudZuo{6w%l!&B#ch;*R<0bk7->Sl;tY z)?4!2{*jU;XY}j8!8`YgwRy*dYt~Y!KZr4F zM~5->;|;(B2}>dch4`$N`~5vS{UnyT&jPJ%BG}r9Oc^o6XU#})lnbEi{~=d(ljVc`11%@$tMU_z1G6ozG^E6F zc>Q53>h1qS=hs!ZE4=o?%~tp;Go~XR=1}(AGuH0*oPlI_+<{br(~izTq6;h9^`KpX zxB+brQh`+u0t3UopNBkg{2u_$Krz3)TmCHa+#H@fbA(Us>mDlf@b9Sa{EO`W00881 zVdQbZ;)&s|8SuoCI7LeO-lZ-xL#$|y{DNnXir8)UmTvW~bE9)VO!7A$bn1V43d+Q( z#qD??4aK0J7$s=b8?$J59>E^iod}=yE8P>QXWi7Rqc1AUsr2o6W8UK5ZBBga+-;D2 zS6PkJXQyQuury+N+onk#y+4{=0RI3kc=s%Rh}wrt#;&JYD>meBY>kg`*|pY&v~Jl0 zXz^Q^*p3)^S8smzV+L#=&i?>ESG<`20He=tS4)Ek9^`mH5)y|95!3_2sQNlk#}PUD zBN#}5!x5*Z#gW{kW?n-xaku2$?bg@o18d1F4lexXcIp*Td+5^ST zE;E@=GIV!s!0@@wiHIz=K$2~OcJ6D4Yfhuf^G3R^uNw-+;ALfcmYZLV=?cS7t|Km= z(mPKP^kaqHJ1WpX`z@~b5FpjyOzU7&x{cWm#J_znt)mvvCCoD71dvp9w8ko%-g|za_X$BBPxg4aBGDYZ6U9c$pdiT1~h@e?znuurr%b^y2m&< z?viR`v=5{C=3NKB(c!DE`u&VXUQ`fl44@XavUD$>YvN#c;cyx3aLKvElMmYt1Q_k| z@Kn!P4I5dHght(!84RTioG_4-=0J?3BVsb0Ub<-U zIDRYf4tisjl^A8HPhN!4JM`bpi?eTeBAi}bWnY+v4O8Tx9GqFo@Nl#s{V1j zaz2+IHQW7K>c4BlWsPucw9?kVU<5o7TZ>E>+%51OSC@{fH|~*TJqKyQpJDV_*75 zSTQSelkh1dB20YKt#?*X-)C0Fd&w;&tgHW$DjB8AgS|F3C5HtksB7CR# zD@CknE@=RViFbrFYq>$}X3!fhW4*PfLUl7}nVv0pbBwPFzzAL9vT6kOiwy%TfDZelsV2ny|v(Jq5314j}=d?;4?22xvgvOrLJ{g=_B)- zJ*Eb}FsWemBV!uZ*^f2Y#@b7ZcStS|6Z_wlXYzQ5Cz@QS6^?h42lscB2lsF6ZG00y zpz`w4c=jLE>Go~*IlobJk3jm*XGh2}iPT6GxSlKoilms0(pYrn7qBtK-^zyprk%UW z@*k`n8Q0gkt#a|b)Wd+2&5U$@bA)XpO(AxlQ~tCLwbN?4*V5bReQe7PJ4>8FEwFYQ z$m92c3qvB8xy>QgM%#{?WD-FKQQNY{$--%5JJk_GL=xQr2X}2lyZ9|8I;)FKj-kzG zsNJnH4(IF1(?P;tW@E%XtZ^+3GETACYsAyJZ%2JEbDIya4Yr*&$Sxp*sO{NfW%Tws zy|49Qxb0{K%zy|xyJ{Wz$G4KyVXERB_fYn;)oE*W2YdD8>7djnIMuzRSk^eXp{|m3 zjt7r*&fU^!vch&f$3PDDOabAi9xF39q1Nno)cQ}^-&k#p+#pF2?gzvIJlARV8UwzC zd;B*$zxwzr?97gmDsc6&pS7-r3n$zJMw8!9_NHfsJlN%mU`jKI5{$MZt&YnxV~%Wc z$1%kjjuH=x%VhK{Yi)7#?0L`!dX>)5Cy5_KcUv?}vx`^n# zMf20{JMi*I05fy74w>4=AErMw+VFMhKDT{l!mFmR*b9%^92t%y)Un_gV+OJGwK1p6 zPc`+UD*^o-?8;?MbB^40wa)duQNydy&pzOLE>ovk>^`MX>N3k%8r*wqB(}KhJUNN% zyze)}IlqK+C*hcKgUgxY_Oj&l{nSognB?ecy%u)R==op9pne_APYfmLv8=V=68U(K z<=ybSiZXh3OR9Kt9tX6LTP;2y{v*Xs&a0DgVX^MrS$S)L5;qTM`7JN4Pi5IJ$gk22 zbAw4^i>2e8q@912r-bUT7o~kz`oEKXm3?FD&3*Z8q#O)pmYVS@1crbf={5+Rc<=7x ztG4H~InS!*f?C$?vAk#?`^Kb*`Sam{(z0oHPsa?dyDap?>NGL!bBGhT{%_waN!C&> z742i%9@hd$1d>B{=sONbJTBMZyq_=2a&VLloSEOdYysoBk7a$CuxHm!m;rWh4Os%8Di!!$0SehbTz&1502}(o=YBJVK{LKeZNOH zsC0H^xCibJY5HZu-LA2~*W>eC&Q1nKIXl2`1c2t52X8Us3%z?Q4FHd8nglp^J%eEC z96NaY6>Di_%y+07@%hfOG~MnX5*#&jM1OMgf7-uVzOB61)oDFL37+4yvEJYS5jRHR zz|z63u?~TUGv(+h?ii+5;aWaSa5WhgWDrzCm=EW|G%D$7cIosndyxK4-sR zxlXn9Z=~itxwxKJ(`CxHa6b0@=oE%4)9moz!PTo8Spa_%4z^5+`) zaRW^V@_hF$f1}Uck4$-WmtU4q*7VZe3P}Dc)j9XDx=!NeIl9Dqgh>ZOpoOv2Iul;w zWdm!0_cvCwx9FFB6CUnXHckcD&OWP|8pE1o64R&}F0gd~0r$8PCvk_zhSR%Iu9|#M z?&^TJ?YMy0b3tG_Mv`Yz@0N>&A6GiBPaov|qiqd#?@f+&(CF+796{&zQ0&h7(~3yC z=H0dfiLicfk_h&E(3kvbpDqM>-cL3&7>o9@W6uu~Of}oVl0OtUxQ{V{SoYQ@jCgGz z>|yob+M3f@n#a)wK@bP$xSnAD01*n^omsE0T*rXtZPR9s1c;r$4*UIneaWW&j zr2Z=q{{Y5px#!Ge<*`fkgAg}XI6>T0dY+qpEiv)BmTcU%GbwrmWMl{w4&aaFMZMIr zn{x);;jVVz99l?R$eQxr~;LfQTcPInC9j+UT>ATQ+qoUmGl{baj8D zsg4aL!QRpgL$&;fR@h#~`sSAz-?ffyWxKu4E^Ps=E_^q{=(4d+Eq67oCHB5SB>Q~A zo?EhRc-w1*U~1CiGBoWSlt<#3a^g8N%30-NBMfqJV!i!QHytnOqc%T{WXa3RJn{Rv zN%sA`a{?MfdZiv3^YL!Cto0@ct0vaZecI{4Y2+U;tJwFsjrB~1wkiTN*SH=?Nh>zl zjc~DntZ8du&0%xTzfX4OyvYZ~6)Cr|k7T)%%DVfMP(` z;Dpb#TVqME(8iX#aMB^bhewfv?o_h#5R~y8ytE9)(1lfWxqPEQKE|&#&qpk=%bVpR zEY(=y5F-e~j_cGYb^7_P=QmK$K$(JP;F%RJjO9RpyP>iXEiErK364{u<6(J-y2X8Py%Tn>(D?$hA4&O2P!0@*rt zB50P!i>){!L1G9ozhL?kdk9?%4s6XK%9%aT3WkJWBONWTuN zIbKj7*X68yxHl@6rn_#Wl1V$-(Bd1k!7xOT1HQeG8e&I}Dn`eV0mL_7xTuDga5U~y zbLAN(J-E>91#T-rs?Kkij$E-gVZjh8G4EFbjxlK=X0q z;;Lg&>sT5-fQ`idPnlgV1AfC@Iaa*X9c_(Z6o-;pzzCZo+wX!qa<%>g@SL3AF%!eZ z0p+b9SpxN^bN(&-7dJi3$0^n@l@AgHp8i_?#UzqGJ}d4HjiMt{J@wKw_^O!}Rq58& zLyy_@be$&GJ~;z|B|S|qy|jjb>prjm;FF|JVeUp{7T;8ZW7=!j*9>A>OHAzE(6+F8 zd9K&qEqJ_JM2BJk;O(X1tS^urd&eEut8#cpD~My#CNbfThC2FU56j^DJ|P@9p^7!= zh={X)C<9#^7_}C$q{uCEi3g4gRjC!%xbB9ud`_R03cBg3z!x!_OOCER^aoz$Xyf44 z;N8w)1&s}81d`V_KyKlzh}ZK`dR@(_mE*J6X}=%_gS%cwxy~dwMxPB<=00oBPRS<6 zZ*DH&@&_MisA=x!%a1rf>G;*Pp`_H~>e({Zv_r|>8u*gm7k+VD6yoAHr`}r1!{1+~ z>v;yTeQnvdfY=LT5SFsxsND7ACPZ-)`?vVmRmSKK_xiW`NUt9FVB2@AVKD{L){Ucd z&$n#1&y~^R^&1`1vPr%Et8qO+VQ3?1%Bz99L)&a^^My;L;8y!ft#wb?YueUsA+SL& zlcs`ocP`;{RP^iy^sBbAv1N_e`?VmjWY_vVvjLhy?2OA}$6vUreL=H@b9L7m(fAJP z>6srDS1cD|TFt!CV2SeKJRm)}nI9c~8oGyw znC-&jezM}Y*_o}UaIL<_3dt^OfFS;Br+~Sv+)Hg4EpswnPuaE_^6IborfvNgc=k9E z?+57}Lhm}Z8?Un?^iP87L6-nH{O^AQ#B1QWjP8=+U0J7o>)HvhlIdf;x`U(t0CmHW zqoq~nIWe11IEere>ZuMbj}Jvo0$^U_ZAkoxc#p04Zgsh@2JL>%A%r(^JEO7Md>5YP z^tzjUwl$Wr!1r=NCFjY_0^^jfz zst@1pZliOYbw9n?ylS&B{1+A}apS-tD%Mq!_U)(F$%Z_R7|V!4w*4ve{{RW|=VM`m z8*T@PkbT3R8jVL!W$$UJkBtf601^xs(Z6@zx2@?l?k+g=Lx~`V-aC%M%@v$JmJO{8 zrk0l%iLKV|ow|>E$N-K{gvP3tP93eI9{Lz-yQkG&rR;v5-P*V5mb`-K(g|LJ^?NC| z;6B=h+VU~mv=}52yg7&YKio{ezYi(J56waf*ev}-#L-cKt>>gztik&)AF zmsIvP%wwq}!;52$T+m1LfeKt$CCGEp%l=265yz841arb5K7Ry}0 z!Q_VN&x9a1qc!;ZT~h-eO^tIy>;Sa6zejO#73=NqyPXy{)u-9fy52`a%P=f-(DKkX zJC=|P$EeSb?)P2WTnnB*beo+g zRf}I^vLU7AzedXrx;)46Q6J~Nk^ca?Sui+A{W9=Z{y=jh72sxsgjOneti`x@34kYEYXq@TEIxz4WR((;E;s<(PJTGm?Kl1X>D%@d~Aat~*G zRg8N+-G0)g%`v5(aht>B_0ge4+d;H@j_kvrTQnU zzwqvN7dMNJ2B!@&K<^oNy`B$P>9^ry--KV0RkgfQ??gCRxW=Sy0vsT=M!I|!S6OrL zpJprE+ZkI3FQ{#k4lkE}Xl|>=@VbXk=-CbFw&XpyZgagG8uvAfFFRcCY2#0D>~$V} z4PAZLVp&PH*ShAjTU-NLN72)Jw>EqK0N+;5SJq6rt}Xj)8vVeUStCtPwTH6i^LpE8 z4|TQzDyl(>Nx_64cS4~-(&VwTO8wMg~kH__LnL+?G7xdfbFG@iH7*Yq>`)i-0o>)`==+TGe_LXM8gI-NL1w!^GMO)hh6lIv2(oU zNo4z8zE4G&^{XzNhgbVV2UYiUP3FfngK^(r)DTbS7SGc>apb9C z;ADNIX7vgj`>t!OuA#VkEd&tq-LLV|c;{Cpz`(TG_Wq*5_J|E*8>?une&(+Cd8OB} zabMGm9?|L7V@oZFc;0rpG!d_8?5|goO+mF9ua|+ng_}tPkTfoxVN>f@*KReq^$VU_ z`kdN@WV8nj?;E!`>E1_|B2qsKpu;7RC;Gw&-%Rj@$;u6r#Jy!jMdE#Ztb8u$m-MmlD!89>n1jJbvc*Sb6#7r z#)AZi`dSUHZ|-QgZ%-`IUOmjR+AgZF*7`1S+3B&wxG}S+T>k*TF~WG{dEP+AGWN~OHW6BIlR|LpFNk=&U&THF z&U_|b=PD)5@>XT-jdJ20cz=2|^?3Mu0C?c=;rNBG()!t;3h$EHz>wC6bjSs*;oqGfH8KAHj{JsUA&g5QBjxG0Q7Zmc=3@BwEJZ}z;xrU* z?5DJ+sL^9t6&$Xs zQS~g?(?&b}MizRGdq&{E?|X;C!E?ggyu&uw7zhA|7%()51F+&qTb(|djV`FMul6uK z?hp6Fn;`2D0qi5W(NmAc{w47#P8h)D@zIcx;*O`&5yQlM3tAr)&CL7J$B1HtV=f6~ zu`NiUp%=I2^f{kdDfF7mSC%?kxVo@(b4e#_iINO=`7BJnqmhtA*)3>uK-kvk?GA!@ ziSq2KCtw8Y#2zD%H05JWxo&Txj?Juqc8C!>zLUvE$?5pwkZqO*>m|()4~~W<4Cb3m zVpd7e?r`JfIuDAt=G$&FTWKEP1DMm@x)Y%J%EZBk4pEpH9&U7MTs4b`c<$wXG!SI)F@r zC-^GajmI99HEk{yu$HvCU~?vWD;Lq0``jBf)6B!Up7XEdP-4N75Y7l0qa%(d9vvbM zr(V@sl2~y=+rgAdKKPdmcrgRR9S(<4r<#&UC1$Kldhx@n9`fMVoe2lu?I*GND>}oK zbBj;t+c5%tz-iBZJc7{0WlSX?AGS={i+ALn;hsKFSOxVpDV0PcG%1HwI} zfB>!Z+>C0nqSm+R(-7AeNV>NH@3%=m-vwF0@L6W|M>Iw-H^wKg2 zPy6^eRWR3ESOhQu$o?pfW6MR2WVOfIL~9xt)gtMuLAZeg37G@HEGxdSQAL|v8*B9& zYbF~%y#3IAUwWmVn!(F(V#zZIA4skm(@pqxW%z{gd?%RY`8<=zBQX&k9xaBHV=vKj z(o(XwGi-u4G&oP1h$ILHPJZR3cT)QWR&IE%x9txkxEXBi17m?dNa?{`wtrf)C9b86 z4ab=P%$`1$(g$Q7rJn4|_qpZZ6SGZ?Xg`?NOSB#;qgvwa0Vm0G9}xJKT)7TBQ$Ea0 zfURsxQ+*yso%oM4JiHjQnPZ6pKHcyO8t>Z5gNT^!Af%E>Ly6a(QrhV9DGkm((f1@~ zPi2}T5()JYd-rpIi3VP&3nPnb`u=K3B$U8wT26;e0X^nBA(JLg+?0}a)-(yg8u)}~ zkjzFSNXKF2-I94{pN0d|243DkPlsieSn}}oX39iK8i)dP>A5b?!+r_O zWac5upXYK2%OM}+aT8X5tuN6ZRV0#~Omp201fFy;pasXDg1^$bHI>pbFQL{ku3-&r zwN_kQMyGz`w{IE`iob78&CAWQ`)GZG*0IJiD$qT}(9P~V9>eB=WAR0nG*ek%R?Lh5|m;Iqo$gT)lF@k7eqyl8f5vRp!V`JU0 zZLY?_646=EkER5TN_;vR%1dl%4k8E|_wf!LycVSwF`uPvGAe%Q0Ej=<+fdNAE-VGxZvoq-#2Dva6`^zPWjN6HGi^XRT;M&eWEPLz zR~l?}^)qV#b=5ao+6J#^mo!I;Gb?o2PSL;lu+qq`e%8k5*xE;Ul}d+R+}w89=Saw= zL!G-rVuz=RvCL-IUqe0BfFRh$$!H_R5uk$VwvFa$4K>AEzSh?0*n&I8<(|jn)tipX>~SL| zi4SphhSo&R?-BWY5TEs<8}`L`rmF=4*lUf%f=#D`0zKfE+=1G%YlzxMrtm|) zUxG3NuJsriE3k`NV1P6d2D^`(riN$GP;Z^CBWWI+q&wyKBOp5M?Eo^!v8D(EO+eRo z##KDZ@!xHM#-RTIQkb1jmYw{9$ja&T?h-NK_SqT}B4mk;XY-Hd_FK76v9<1VZT@z> zfvjVXEgmP6$?UQEt^Gop>GU0SMfOoZEk$uV7;s=Y1xQttRqwYU#kJI2979YPBz+d~qFDV?E%6uF>3f|g(mjCe19S;IvAVEp+sad98gZFZn(Aclmk`i3jb=a^cH_gv zHbt1v!VhLc8$>mAT~4QgV-3`_7TU&rCpH{LwK_=ot&X+6%z9kX zTpn(RA8B@t4l?b$lnl+m@5MG-SK7Tjt=eVml4}ESkEJm&+!c1tymNM!S51u;6D?pe z;@!WT=X*$ef&3AJ>3t0?uNkH6dmQ0Ycy`@et92cWu6?<7VPtM=-S$gK4{n>aU^BL7 z%zr1~wFYe)+v`~NF~QCbV?&*^fOXt_4x~zpl*~9Mk1S8Si16eez1l!_E=D6bYG^7z}=DVcHO?>TkW3Gw+GqZOI+HqS-p>A+}fB%*MU2A zZoF$hCFhN@&#QfR?KGFOq~*J7{tjq&xq?X9yK`hoZ_RdNtK&s(z3&y;*StQKwZ~x% z_YKETT4q~1c2VoOE&B#tEvAa*o%`8aTJ3$>5grQX)pJ+;*}}2Lro6t^{*yvLeZ9bQ zqIJ|N9eeE7^!(hKpLXv{X4`9M9@uX!KX?0*=ouMI`oDtAdmha!cG}~;mrJ#2?dQUH z{{VDsMuUIw^=6cABolUVZ?E~rx7Q2W&XTN=n^)i;*w-$h^Qc1B?7HdT#f zjoX!B4Pb9}G?OlA{ofc?vkA>@FLUaoHnxp{raVrP>2|Q1tX46*-H}VGt;D#7l0EHi zn&|`$Rg3a7uEz{1R?iJsg`~MJ^Qqwat<@5o4lz>m8I&PM|Q`c1Anu zt;Bkf?FHZf)|2A2ZaLQDHKf=>=_e#@Xa&Unc@5ni&ef6DdWJR*C4%p?Sl3xw;5DF_ z5!>LYbqriw{8NW$W1C?O@Bwb&HZY@$MlVrL9a&w2r;x4?i$GWMxc1ER=nG)Xsx7eY=GbZaT7mE zC&%(|w>r08#=WM1FK*X4q&PQL$@ZBh4EK*d(0R0K>%QXrtfsNqC7`xm#l_vRmr!hen>GpUF_-}358}8cIHUl>n zv8)5LL!f`JiCY-;Vq-DZw)|o0M76h9xr7$j57OLp(~f7J{K$L2fJ{g+<}^!tpb5}V z;<~Eyu&Kqhw=u1(Q)Qcmel@o5+YPCKtS*Z1R zwg)ziu{?r)<&4}*TLtWEnh0~Y-B|YcXkDre7}w?6SxbE}5@eI4hW=8S%zwsjiDWn< zhnGLDBZnR+%3OY{0P%t<$ky5U{{Z;Un;h_r7;O4u<0K(DMsOde9ghU`H+@oDXnV_mGU4tn zJBcTgFcbg>lL(cP8g+04YqSIH?>}-i`PRI^bHx23<0tWyEAa(ojUK4A@OHhSze;2C zrc5c(c5WM-D6?b}EhUGKSrh zF{x}dvIzv}AybdRc`Wfc`4f<7VpEi{pYKArudAIO_@nTib`j>eGmu9#IL1rrc9eZ! z4{_OsyV?gI;6YE^D?2($loZ^Ogoj&y7}hCHIK@ zN-@Kh8S?ERJFPc~ltzc>@)*7uG4VW@xg6hloCy*$jYLFBs&mF?8*8MIGG#kkxcrIx zgs#6AA)b(Twaw>Eut^^8B(rUGjcs+jG&f5&yf_d<>9@neembrRmswB_W6Mv7mi|aq zsOvd{PgU?dUVrb~mC5{E$|IDPE(0w;RhNs4^3lD_!!B9J;qv9N$1Y=W7&1fLm0XUd zP&K~cWRftD1n4zgCPj5Mloqqy>a-UVCt2;oLcM>g@imzDK_t(d>%!&R*IeS?R64-d zgY?=p8qSriHhpiY&)Z%YbDgX{^AoB607TVem%#}PkTd(ZJOhVmf6WE8%YVgAYIySC zoF~fwAtS}@=qg^LSu|2gPOZ%VyFgQ#zyy%*DIe`yb#%tnj@*}f-z_A#=r{V!)Bf7$ z@*_4~4P#7_2ewJqf$>>+Us-Y;(HWCnb=2YZa$4Z)1Uk(2{&#@Zf4N}g_0G6!aknki zFgbv;9qg>bnp^}`snGc8-CfV@awagweLmE3TzIZTivZSzyAOk7_sPd1H9k3Dy^z z*_8Y3YoylJOM$V@c{As)JZPnUdtYCq%Iex4A0e)n5F>Mo$(c}czww`x!H#qG$&^Q; z6ZvN^-n$Z`TMcz4})2DQQ4f!ar7uYV<} zh%vw!HyWHA*Y0lSG3^pH_qop9w0mK{1(F=*nQ0*TXr0zr@1){+=g*a+)c&%+Bv{JD zjAOU8jo!_qKX5ztQpdRKB3!V54($`li3FMPQekL5;VX{kIsE+gZ*w`~=nT4jfILq- z@m${!=6%fYfQj_RA|e1;v9R%8%Y8#TTHOHlh~vJRC?t|%(Ak-v&G;p_@!d$xkM<3F zYuFDGiCtB;w>|Fx+eu?!l1|{*77j0kU2kTV%)Pf$i{v-&EAm zV_GlT9kA{-k;_MTIuYco4qV`vKQ>CTDp!ui=WTavPm`A|nkFNTU~zEkFKk_0z|?su zB$8KpPf5tn$*Njk>o{sX+d(jFvN!{ubWc1jOK%2>X~h;YkxPZne%6~e*laVfyV^aX zH+Ix1W1MfYil}bti}#B+x@`9C1;BP52xhi4#?4@lrQi38^pE(j@G*`N=41r&WvLlx zbUU7#^!y)F{{V_#1jmB}dCb49&6cupNC|7Ns2e(wN&-xHtsFWVS(irnE#tg@a-~nw z)a?hn12L>>wW>RSEpZ@{M-dUi5!~TAmk>N{ycuFa{f4{dL;`>(Iu&=|t&K7rbF z^VWP7N~_-Hw!Ti$WVk>Ma1*R|K5M0~4vcr2Xva0Oi|j2fxWDs#KT+~VrLFd}$B?@T zal{;Oh~kthPyy0AoqPBfs>?c{I^MmRhK9BPf#4BaxZ1`rZZ5H{_L+^wB<-CP2zJtI z65u!_e;DqyuzG2wq1%hz9@l!i*#HmDb3oQd4CHdBhFL{b*IRv7F@zUbG(O@?ux=4N zYOPaam|pF(yb01Z)X%hb?xTvzrM0}hpa&NgL!1WZ9o`N){{XBjE_N+#J1n+N(JyY% zpdfu2(8j9lAs9!1M1dWN{MaWTEVnvq%@sAJt-YW=3!4D5c_FW7ymRKS;@E3_j`ZZ% z2I&w-E-sd~eZAChtEI-etaXfQTJvdSIqh!u9l(7TJKR1;jTOhgr%_woRkxYiBF60o z0SyCdOoId-J0$#qZVYP#@7*J`9(dsVe)Z4U)PB|Vnw(m7$H3fj4uQU-&!X1E>kqN4 z_@5jzk`rs5Ap&VF_7B9@WvY18zDqq~1Jc)}JR)z{bcS3eG^`+fB?``k#4%(k-1 z!>8pl%$3e_{O(S3;{yu9zk@p9a~j9i?t z^IY8H&_MA+ADoD@;De}jhGG!oTYa{I2otDx^-hP8s^Ly;_H{vRZq}EZt$32n=RnsH zpkQ-_Vtu;!7*@Wqb)Q+pQDwV#yV5Q#0FZUE0Qm^gc=|fe1Ee4Mxzvjqe$Xnd))LYV z?_Q>gK{9*r0GEGNdR-k(+g=7G6~2#I)YosWeZ&V6=xuHUXnU1G<7Ox!g3H^A^6M+P z+uG)PpJS!MA;&@EDo*sVulMW@`$JvpoM*fSvXQhj>%nY5Gw@XD%D|$w(`~}7__okV zX(ShVRr}z3PUe}O46XCS5KN6%S!nh&`#l{}>z+QvMKwcD6ycLWsnH|+Mm8P&D5vdUd1*TV=T z?q-qhnC-$IJ_V{|s#`tswodZdc8XkKnbr<4UoczDEHYT?KYOqLXhY(JK z=gI}y&uwjWE@SI9pH6DjPjT)9#=XA)ol&7g4Ro#^{y)p=noDRn`47i^O=V27hZ5`T zA%;ob!bE$gZ*D#aINdWO^>dSu@Z4JMv^mbnJGSg`4Qn|NOHVzJx}}&_^%v%xrUCjV z2D+PswScw6IFK4VCqjXf)a+$UelwY6M)T` z*B3lA7QL-z@+0@2*KHi1l!3TeH0K8Tjc9Aw%WG|}+q@YC&)6BEaB(Ea@R*t6gs}B1+-oWQSmpV_l$G43ml|sDgTpG>R7Q1NNUenHz1Gc_8D@41}V+M`}H2Ow+ zAHhJjr;y{7Sa=UDn<@p~h%dGs>i%dNo<9`J5dL#4c%>git|0un$|AptB`CyPh=}nk z=5^39n_bkl;f-V39$!0)%^DW1_V8xMSAI z+U6J}eJw#Se&DIun}fNovn}H2E^M?*gC)-Q2TOR`3FPV6s`;4t&);M2b18P#+6?YH zNF?af?%X#AABPIQ9!=Qxo|~HB=Qm1>mo|7YJpTYE?o+cr9*xGEF)X!>0*%>Jux@_c z=lRj2T1Q~!{4{*ZgW`T7}t|9V6?7t;{4|?%TMo|yo9rI z^41@#;mI5ILdUB0(4N0n6XO#x1DNIgS#gS$P9igg+$YtzJ22|~HzzKOthL3JyKdob z_a9NM4d0_k5@do%?iM#mzRV2UdUjy<*S(dAmhPXTCqfL8-9RMytrzu*C~*5TseOPS zN$=j!9OjQuLtel(>$Z94RnK)S(UkJi+To6IuGY28CA*HBONeMZ$7R`Oy6d`5TWZ9+ zbE|OCt|YiY&~5I4)9tpdiH}q8^9_`kis^a!R^AEHBX2I#!^Lr!olTduxVKP6;ijWw zZL~b^bne@^%_I}VD@?)a4{dL&9_O|7*5LLux@C>st7LYCTmDqTHaO0#WS>pMgDBRrBVAsw-&a+VI`K<^6#P# z&;*}{#ZbcP_jLRdQz;o9t-h^$EiAL##}A?!bbuU8_iv1@QI?j1Hnhw{j{-a+!8`2t zyJ#CpBx&NhT#u~y)MV@3SX=rsL3uviHx9*MXZ>Z#t{qlZK@4kH-Q|JS zICpzk9Nr8nIW2B83$kmzrn(zbb~G0{HEcPwWo!gfi+L+RICsly%Szzy^R0iwh$^BIgg%Td}dRud&Z9(^xulC$azygD13r z2YKN#BQDCx$QhZp`k72<*ylT1z%m*Rx{ngC9BgW<^$qm^(j*q!srpbRunHarSj{%E zl-q51?GfrZs@$)`{r*l_`Dw?S z$;VO|W^oxxu2c0B$J1e}nS&ALc|$*kLR`*XGZ{)}+Zzj(pqYI>n`*TsA|WL&P4PQS zc)?XIs~07M5G7FSC(gQ0Ne z=6fo=OJLn=m|86)fB`MnUB2>U0o;{e;$H>F4pd~#IK!BQ`-TFczQ?%pVECW>U&#(q zT-Q67798+0_XabLF*a;RhBDjvc||2K)(@uWAi)to#3&ynfk>&01i8XwkN_|SozE)H zE`2!GSn}t%mKL%=SMIDa?$?)ktdX}TS>~>l?;IceEluLKh&zc zpTzmj92hYie6Ol8$1ITjQP-r6eT8?!{{Z7BGagS5CCiL_q`09RbITAg=`G?+LG8Sk zX=py-Bf?=wy?}#Tc93LApWvX9oxM*pFCo`H$1$bPERMnYI73J7=&H81J>;}~B1}er zc_U<+S#_nZ(|foAG;xU409kF0(~k4p1pJ=HDB{J-g)7(&5N(AMH%zQ(()7#1HRI<_9?pgC4LQ*_h-`8E&lHLq_6HkgDt-EE<+I%5E=tvrm z6wY+Jah?6$r-IPvS)#ngW9{5-wvyLOZS?HlA2mVDYug~0@qje@*6-CWp8K;LD{kl0 zZZq5npJ%K$JDvdLE=QN=XYmXtm#kRjAvt6^#-;OVeS5L}$Ko>Qp_7oshX*4mM=ZIX z9A2o(RzyTPn-)RpvFAkXcGEsYec}=TxWMG2;!)~c)|2fa+l<5jJ;cv|T<*=#N;O67 zg2Gxy5L2?ZLs}Z?aF&SXK4^ea*cWdS$2f+7c%8Ai!%a0%$CAy5A(SFL!gY}#8$K@he=M#gP@l{CO-*Fb+)%#V_^*d z&*vEY)}B1phownv9X^{YyCu)H-)QvRv^0Rw(CZr4pXS_tk9{>%x{hu|yD5LDD`01# zQ>Gv^Fc{DY0(2eJ@ou`Bp4(p6u-4~>i%Vd*hQu?I-ai#C4r~r%E9Jj@wej}Hc!X-SUL{Bs$i`$0|IcP`9Xx4*z=vXPZ21{f==$*|Z4Mgxj zDg^Q5kTI`5O0}6e)?x}}-(;=(S{yyCcCLoc9Gwyw4cW2JumUCE2ElL;-8{5V%CuQ) ztPB;0aa&0sX&;>@vI{G+$sweHsev#6llTRXo0!XsJfR88K4~5Tb*hZ00Unz?uRqW8 ze78BD7rpna`L7;dM0f~2vDHV%$3plbI60j(1zU8af_)b_dC+qAF^!1e?H4!;$6{68nN$1Nr-$}!aN zL~3~TuP&~+_#DqI4CKZ>o5{oKJRC|}-A>R4X(d*9mk>NvmgKssA4?}~fPzkkQq$P~03k((Ae5vgOnH1hz5sNT zqp+dgs`aaBa-7aFIYPgq;q_NZkOy$C5ESzImPv*&E%jl@mQCmayweteTxVAr&Aj*>{56Bd5 z01ydrY(Wj&N4gJ}n$W6>!x|X`G!~Z@`;Mph{8bAZW(}tLzoR+ZuBDJRyZt3&kCL|i zmQXLP!(q+G)=~W(#+O+n z5J-rQM}oP9lv`(~VV&nfN#y|ETN4@q<>m9?Rbe%}JB^M6h}04HEx)U{*X3E3 z!%(%%6*vdi>V^RG?rmkKSmRHL)ox!!wK>7UB$vCBE1bnvt_1FLGjA0)S#bnw1nIkw zUmio3^|$EEBa%II;fNq>-@)F%Z8v2;yKG}w=(w=jUAKR!Skq`S?qPJ#s8_v|?b%uP z20MH^k9)hnO@FwB!DHMS&84kz3?Mb~T14+ZM33EFXHBxQY`b7&TfVaZZanRo8Ug#N z#VxS7yLlDCEfQcE4JSsOvE`}oO_7m@hlyrpTx_Y0d3Ocwfumd9#JoV^3{7)&z_PY5 zz0Yvk(axlwAXhwWzw1X(V05#i;T<wvu#YXue!HFK z$&L(SsBLqdZ3qE!aDF-QT#%GGPE>oG-!bUL0kA!1KkCPF>Qc+x;PGMfJ;XG*;5G)r z?_(SUJ53Ck;bL|Et&ZCM&d782vH2D;+gwiF!(S3zz#4P$pHb>=!r1l_E%%RbEdYR8 zWyUz3!@PG~+Zkt3xveg7s-PO#jm~lG2LQY99x<(-tNlMCtMw1txvc~}`!J{`bth|J zyR%EQJ~HnG-%-)8XHCgz#{%mdDGxVDAY8$)Gj7qx(&c5~8(FllvZmLu)i-4A^xQVU z+#`+_;rCsN5k)ho%<&8$CDKt3#X`*7p$b;? zfst4ZV|KS;Cz4K}lm=tjLG-abS6VE11-o}`mpiZx`1UFtL#yN(KbWf5ZEJ&Sc`kXZ zx){yQ8j{^)u6wHW!Bd@0nAWwmI-vgmM%DmdYg+#RNN#u04g@%=+4=l9M2+#7fu|AS z)b%>COPR$Q25~po+IRF?axHkt88rs6jM&dilk}WVxvo9?Xsa_8>{2Me^`Cn!v9jH} zi%XvUU3!KqYpXucLoEY=%XS!!j>yql9T2bdra!E+r;>m9d4ak4Y2BFk-ipL{=i_JGFvf8f|#?f8|Get%KPZ>M%%MfH#a znPsoA7&0`U9v3~&f5x~&iVz2iy&!5hh`nwxv8eo7a`=R(5fK~yy^HL9J>Ju)bpci^ z-Rs$J*-NSV4rmQwHUiVz>2~~qa~YpnsHBrqFRRpGH5b=WJInT&ba!Ae5*Hzrm~3EZ zbKGAqwboeYlIKLupnhoVtG??j-MPf>GU;(LPmG@>(seJaxTUT*IgRz-YaSl_bH27U zhtv<=)4A_?-8%f1Bl`aUQ7mg)Wh91J!x*%*v|G46tve^)9jthvQ-hCTHss%9Ds64E zBIZ#03mo@sYdy|nljA7t9Ww^~j>$GUw};%zFj`Lf3WBpPOD0&7O=Ukd37{<+zi>+lQ}%t(EnIG1F~VlVz`S<<-}@x|sKtle^7R zx2xw^&8~QY01(Q=2{Ia5!L%On&vjagS!3eMJvIPIa2t-E0!QUme#uY`0o%#?ZUaC^ z1+sn9=L(B!er2O`sbO<>^vluWxW}@K(jjujfpivEm5@hZJ`9-)>u7d`KDMVmthuxafc*67ivWZ3*G;rO#h z7sNTilRiWI*q)^S0CG`2C+u2h$-^<_InHk!a^^DO#4-|3=^Y3f=+txVdEKtCG!P~u zw{%8f+V-{H*mS_$&_`i1bk!RpF28#{Dv2a&#x=Zof%y~}nD-O7Gypq8cp3z2YO8x+ zhUPaVwm8%2JHo`VNvS;PwRg5fdpOKKt>t@{BZGeYp9t3OSUnj?glkH9{&IpSK}Oy-D56i;O0kK&lr!= z-Z>&FH6hq&bn4>&0LCwd=EH|Be}&5~g87VaChqTu0oz?XKF~h5GzUR%V?582gpf&z?h`IsHX&r3He$a1ped3eHKua~9*Rl}qV zc#l(ML5!`#e&AX^7K^-8!n3jJR{|s=-(q?SNcK+6U<+L#SliLrZBcVGk{H_cZW0 z_74>(#moF7m(8D>ocY|d;W7sG{_p6;hFqsB@IFtO=DGax_^w%37BeqF*Q9nEpi&Ib z7Z?YHY|)Kg(#NsxCOyvp0|d{s`6`w>d$(vOu%F_tzMOr8ydC|tnH))vHHnp5a;)^J zVY%Ejz(F2hf7I{sCo(rct;J;i`cPjM5;-CnCZn8^=}ecKio z$CbmLQH<_4FHx;DujOu6JBR%{%JTVnIAi3wc^(|G`G~nt)IL7z5`G1T(!M7D!JO-@${NGA1?m@BoSjIVrrn$P*`0_vA5G-bGO(pyG{_rG^ zydrtIOu+NlB{^c&Bt)2bkUTrLztfTCjv0J&4orsuGRGk=)oawmMtb(J&DU7w?I%SL z*E@kd(t`Qf@zK|R)c8Awt0{n+o4DXh? z@Bq_?YD&_#uX9&h9PTBT=;o^Pm z@L6hptAkqBfWiT3b7T@7&hN;wn_z1ibe4m(k=|u0oFBCMQpV`_NfSIBJOW`4XStd< zZ!xqO8fhrsYV?DJ54yP8EBz!01KsohJyP+2kT2lCe%v$&-d;kWUAsb)z56XB{I@NFDUiG`YkLNj;M#@>e>Im^C$x z$9o-ldxh>5Iv6Vrt&C~3ZsZbU#4MNG;u_d&wYxwK1Gzfw=4FTB$JrUZxS2!d zJR^fm1#Zc}0N!;IuY{Wv z!l{*IZHnt)Yk&dn1etK;jbl|eWM$aa?cC7a+cp5e1I)TMfy|({9_wuG_mjYvIG>cI z&GQ)Jj9|hzvPz8dk!MjxAnrQ#>)m(7{wIeVW6ScA-DyT8_V0KbrWQzUhzQ{Iq9^6CG-*f(pSRG*0{zL&t+32vt zo&adtU~X_`vU~!#$Kuy@HMREG+A@QPBYW+aux%cY4Q`c0e=ANGW$^x7@|?6!2$pGx z@EtZ9OKPu4z5f7%>Awo(qwwE`#xeu%IRvqgY#K3#5!7kJuTL)Qt8V)PV32tY5@X36 zdNoov%im>ZN%nwA+u_54Y(|FI%UnQcE*g*|hNWe!xy%8(E2x>{=+9y8*UD8qm(h=n zPS#UyL)(zY+|o>a7B)6*X>>ir7~qAT(9kp-jz**-*^>Jl{l)MFfvsR@Xaw$X_JO4L z_#y7H$q{4atPno!eoLnKdBuwyaRc&v(l>Id7cDh3_I#!fV-SRo6!qefk&)EsEcv$a zC=aMU*IDZ}!?~pUUIS~Y{Gf7XgIr?UPm;`v^suj>^|3xF1K@G);{gcJA=0! z-l24X9mfG?(Td7zv|8quK8mb!Y^-b**c*4f?1%N%Rbw8oyp!42);u*dh&7M<` z2bjg2@bcIP%>zP2NBv#@0Ey*QlOz)p0%QZkh+1^@gO6XP!0q16L-dd}aMMF2QL)V= zzi1)B&?k-r$8RJm>wScV#Qt9ZJW23Z^7FF(v1ObbB3aX!t=5LMo5N#M0C(Vg%INU0 zjdWL!h|nmZq6rP|1etSn-041QJu{}_V=!W4*4DI6`yB^yG0UCex*SYQe@X6Otjvr4_yBMMiAU$#17Dp+D@hDz6bDA%JFl2*%`U) z;Bn9NVIG+Aj*%aZ<+Wwk=iM$P#pHUA4U;E^wmWzU^Z0cg3!>yPf$VE#tP&h6J7?X^ zjWS8^<=_Ml>fc3Zbll3zhqa`@9_=;bw0QTJI9Q^my^W>TiuW4W2dL7}L6$Ug zyN?b67CtV2s=#Zsw|hgNGlK0#fEn@o*2Q>s3`<7K3*0vPa^IorGrz-Gl!Gv<71>*8 zweGRI8ZC36M&jch9wk_>BlLDV(yT=w><%z}?Hc)fmeuQhG|}B9t&4}%Mb)*{UFrIb zYs*DPLf}X{S`7I8>vp^g1{H(TwAk-wqDypVuHFdp)@Ov`yb8ruQp|gv>l#=E&U64b zx#lKz_?2auC)2Usl|m^8U~z-*179za<+_*GA5Pc18!sH{EX8f0*3!oaZH_x9R-HA~ zVCVg6vH8H#aO|qP-pVXDOAok%+PE>ADTd7RS8iv%Z@kE?@FHLbY(I`?X1j$;WK zNDCYzhB*bF?)K>Loonm+-)*0>I*Ti7ZT$x9YXJ?~M(=eeUySqHw<*=WvghZAHtQ>~ zpQJ4fuEv1UL5O!}aj86Z?~*rLYnzapb5|(fWo>JF&4G`rbD+?Qj|cw8rOgyG6TJ z1{OOVy!87Wyq7h@CB?0eV=62R)@FYyt##nj=>3ZfwZK;AQ(N~CUB6=-UQ7ZtJo&lBLVq{&alRw&aRbC9#q#kD5oKNKzCabSu-4aDX@Df3 z&XdcJDeA__xV6l!@6?ZNM2$53(d4aT^!ouV$z^Z#4%a!>IJtqn{e~U5@ya!i!lm$A zPjmb{YV%e5z8HCBt6c0gdO)h{L_nRAcP5;fJz z)wTNdG(RGu-=rH5LF3)Fzv87(WmyjN>a5jSacz#S*9d4Z?S%gT)enk~nEwDz^SS>3 zqo25PFcFuiNMxKq^#d;-4Oa6wzvBlv&PG^r$CBiQ9tcGHve0oxW_&$P@pLk}rSA3% zUtpc*bIXR~-=0+yb)?C0Qy90n1Ghu3Bm2>tgwO$Y=N?N(e;)->%uDVbu&x+Aq=TU& z`p!C{418Mh8AX-2l33Smy0)~q!5}|lzye}P)4DZm#-f*oxu+`1L#u1)1+4|!jJm>o z#e+f`c~y^6$f?XB)$ggr%-LOH3`b@x{%e)^Kf|)*=DDBgIi(}TDc{efi?D2VMs7>s ze+tW&;vC6@GUS}UTasBLE-t#5fG1kl{5zXxdFxi z8jac=)8MJT_d7RNE)Q+SzaY z`8S)%@lJX$$I9Xn<>q6M<)0Cc46cMCeME2m`p$cs_`f;K;KT69Kyuk}W6eHeHxP|V zWZYq)I#p{;zg$!{iyi5EWr9YB+IfjEsaa#5bus}lq$yWjm%XfRrNyit5_W|);yAd6 z7-&B-k!f+Ti2h3DkY-noC(&*sUGCB`{?NAAn|+kPv4A@Cghi9ZndVFNeK%yP$z z+RddCf1^76E~j)bVq-+W!n`VPr?w8FBfpBPb$*+maoDXh>RR|N+gTtx-3MJGf>9Xi z*jo40!si!BE_^pg9G>eWWZPH`f4#q&@T_84YupQ*3mvA@#46bT0OKbV-`1wJ~WD-7^!Vxi)4Qs{q?ckP&W3{`F^PP-O;pC?4jexSd3D1%! zciqac9Kg-*WeskGn0Ax#a91*786ahsEC`S$TwXprJ3U{-v2ur&oO!s9V1dQQI*yv_ z>K&WLrZk4kz0Zacnz-f%;Fann3Y#&2epdIh4+^Eq5OfRsMlvUze5bV}Dh4 zj0As%$L3Y18Y#1pHWJU>R| zAG7NWCC-vIkXzb$DD;n1OI>Vt_l*j-i(bsC0WNg7{Ubk`<(}LNX~;FZQA?b_c#^_f z@>d(9eZmJM$AT_xey3N>V>Y<`rs6?k-Lwb1l1qP*)cBa<`|F~oG+TXc+SfO0TIrX) z#m;g5ZLTuVe6`~qKMIE?B?>;N9vJa@<$3@FhNrN;uRY3q2a@<+1Hn0;dLlvwB;2G8 zL|^Z09CV=gc`FR9-jH_35w+Tffh`hFo(Y*>tz&VkAEmL)ZD(*Gl0XeE(0tTcjO%5! zv^=zKcHLpJ1fJdCtC+nas%&Ms!Svo?`8hP)+ZYQ=g&~t;%up(6xVSPm zZsSs}a=!`3mo#z8B6&!^YosH;>!@)?L%{sPw%xJ#XD^p5Bg_DDCdLMeoE;F~aXJo6k<6^Dj+kx_w>p-zZF8)-?%Z1k*}dn~aNK>p{{X)$ zBcfAX&S-SQi$hvTAP)Qxx(l6;MLvaXZ7;tTqv-veqiKDC&U2q*i?=zg#_@U0cgc$Ry8`bk=(;?3atJHC6*h za5xY(?tXr2o96x(iwp#eXwTCKU$2Y$!*2ULhsC}f_e@X~D4eJDaP8 zAKfwX!yzyRb)dV@?$MS5$wpJN9NaN6qC}!3HQTb1NhMjmKN{`MYZ?xaAf8|kq~fgA z)2gfuJ;&*70l#!MQ83zCJyS4FpWpLS%XqD#uv%<((=8;xiTG1Vc@ehuzV zl>4_Slj0fRK$(w{G=9Y-kP<-g`6NUV4{a80`(8u{9fy8N?yq9gO*sCmwY8EW zw(Sl(i(B-4#zRLxB=|1A-PTy=J=PLIao5DdkBW0eR#f)B33F>L4JJf_Wcli+HL{}0 z%TLl^Y&e+!Xf~}+g>o6Pa}b%4;2x;~FPdCuapd(s@oV7x&VG9zGj)O<>_r3fPBQtb zzKTx4?j8V%BuD~#rdF|W-X0$2k+iYkf*=DXPuz)3jbkl!l{C7qL9J_?ND=DUCt+{y zkCHBZ&7!+&Eqfhp)mdlh0CRw?&iV{&wX)f&2!S`C1)NFPB3_?IU)pRWBu=|E26r0wcFh1yOx&yArBCK5Q~LV+Q&C$ z-QlkmJ-UOe2Fz$dpScC%%d;O;Zfv-Q2LLn#&xEZC#e$}bG;jiA%eUOBmb|n8VWMZ< z6Y`Z1=CY?b%nu>$02%Hab%GHb&B6e!gI!07)j4Yz#{w%YE(RSxnhfojJ>h8Pz;R)b z;t`c-P0-YBqqCkuFeH-@3~sw|3)yq9ILP`?IG@O&Zu4Up*A@cT5yBf z8pf*@9}~(XIbKH>-Z`xVh$LggBuL`RIQ*k+H!mUaZ}`EJK2ym2GAB1N#ss7#D8mpY zQR2xVu+(X}`x4|@S{++-U}H|`lk}oB@>T4}+~+tvf$DL#bcoz1zKXl-d(60#+g}Ad zTxaCm+L-~*&`g0aPaq!!rC;q2tXBGa?4zX8cJFbQJP3ei+FoN`z^(i~n%sITWfZ!) z2j>=$3%``|Is8hqkB5Jx#t0Qwz*^S8Xlp>+S{x&4Hbz6LA%*X6v>l{0fJt!NL!31L zXbkx1x^IJg5fWdo)1Fn;<@z?lHnYp%L5dbbbr)41AC4^GokM?m<({E`y{X zKSm*)824oCYa5_DK^(Zun3Jpn@C&2qpI0xeGb19K8(8`~n&DU{#l@gW0C}GUd!v0{ zwwjw~e@qt=L~U$2f&=6yt6`E^faM(|@ z8#I}nU1xwl>J_|O8%teeozJKZrKQ7$yGR}YM!$D#%xBq<`srhxW1d`E!?Z~S+rK&i zhOI1WpKWbutiHz79Q{B5HLYxuxCOg=yQQ^7H8ZBvN!kscoinTMpP~$&C*V95juo}z zR_k{X_s{`m*EzAZt`W7mXasAomuy^HGBYfr9=AT{*}2u%>~7-H?Z!844%)-7K6XMh>AQJv?>F~`pGkRzEjaZ0b>_Yr*MQSbJa2K_+g&yj?VSYn z3qPoJr_dTQ^Pc9DEN<2p63`+3-NR1P!n2m@tER#&$GPRLHP%~UJ4x2UJvO(F0Y52N zU3aBA{DAts3Rxsl81@F5$=t^{7rEkEXWy#j{x{6zRP&$*?8aV_-gBsw;>_^LU* zQ_;Q5qiu(WJhh<6fvj`KiqNwrs4Z)n=NN&p(J)D!%o@Vy@+!)8h0kM&Ji|;6Ag(l1 zb!Pqky+wuKHNmfY$@a26&i8lrtXo~xvWwmt{CZC&9rQ;4x;6ZY?gbR#Y}3`Yvf?b< zLjfSSa1CsjpWX@F=-R_zJ4g)#_a{l8im#jDUlaJ(FM?kX%PvMDBi-e&4@CN&FI9@$ zcAjs7^S>Fv%FE(8@^WB}9-&Cx?Ic6Cn1DzJ zZ!ltERLIJ_xU`-KGqf<6@&FEeljXPUnT*{<){0!naCr9y0U?jAj&6hy2$)&dW!S>- z`|NSBlJ;(Ko!Xt+>+?p&$jZF8+p>z78p7kK4dYit@|@L1_dK#*A{{aePQOKGWac^l z0E}|6pCK7TQ3EW{F%cE70I_$|VAeko_=m;*9~{33kKN@d@JlZ<0}n_V%M?l0>~OY* zML(Oi2Z@Q-!UCmsM)ylV(}xkS3!!uD8V=lQN*i}l$e2dYNN;Tm)eX0_Hn2Ci~DaBQD(0C{Sy)k7)} z(a$9Eq~ZtMc>IXn5INmv47*6M008X{_$KS)ZhJ`9F>uHJ%G2>g==U^rd?+j@)FhEJ z!H$1|uh#Nvvn{XsMC0O!^KLy&Kaoq$d`FY`ehKBtTmV8EfIVDNJ6YT^^Zx)62zOFVpE|dANWACnA|XKK7-23k-NS%kx5fdp2fcypS5(s&PC44+d6# zPF0Sv%?2QlNb=BrMMcgIowC+6l1V-~4$2|Vd^V_XWyxdHIiu%M`HY_BnDrL*>cjFJ~j2#qkf14q9BUS@J&)m=nrn9vt%DKn~h} zDob^qlVrhh(0>(8&Mqa+GD>!});cvlCzWQbW`i!&&wdj2fW+Z9>?w-P00|&d$vXA1tk0HzQ{`j3{jd05m{bv!{sP)^kU;Z=v8{u51B6+cn zSoxf0F~ye+`-WuD&~JNE2GL`LfuZ3+%`GrQ6@0y+vPPVJ%8jqy^5MbZUaP1F4ZlSG z?veMVV7DT`ZqQHB8Y(SoPxFqFc|FJXqcZC$g3>Ku*UWwT{{RJ!dAzwsBhQIT3{Cn7 zH{0ES*X+^cvPa@P#BgT##ti=ebcV8)Jbs%009^>|2iehzNyA)t1oqJ}1acu?xcivE zA*~P=*VXJR*=@Gi-%6`-Pw5G1AUfK1xvbnBtPW#N>kktv5Bb{#PjgyBX|y^^qucZ# z5I?N9x&yk~6I@Qytof1Gd^6)*u1x&495Fd=P#>%H za7OCQZMb~{mj3{ZJcfT`mgLEp{aEw}$VM?W(pr683>Jn|N#)v~C2t7VZ&0eI*{}lQ z=QILZHjz5Hz5K$+W<|CA7k8aNKYXiwCiXX}Qv999qURR|5YkT4H1@c6@K!Uc%6?8= zIJ9KcADdx$_c@L>J83T3)-|nbT28%@Ym~dqG431orJO?aw;sogoQIDcVv?OW>^DZaEeksdxf-=ZunsO0@Okxbo zr5{XT07dJijhfGJuxwy8*2y8Rbj)$sdzGtQMj?JBMx2u8G_xuow^ozEKf9zJ37vk8 zR%AZ0`V$1P%zU+{M~HMt@Iju+&O`Gmbvpyym6pky8fB%%XLXJ;^W2f3D&I}1-7qkK z=U-!OcIIB%_7K9^1Kf8()49{Sf3;UlL4o+z*vHgZ*EYwwpa(p;=V%Thbor{a8kj|- z)vMlpGq}0W)VD?s?;<6`?m%L}%X1%j8NJh0kBEr-LO@1+Wvr}&dh}~!_-rxrc|I-9 zXOu=b-aa^hBN=1RL)EOMeM0X(;xy#(!cFhT!2DFChBjsn=#V2&29lh%=cgbABt#=J=NnH;*XA$zhbJK#z7@GW7M{&bD;u$@Vm`jjRW7J6aC_ zLDdB!ONl3w%35h3HDb*6R#+Zf9bj`@_K9=**+S9 z{>7P%j`4YQq*mr1Y@H>)3Hf=g42#CYO<|5<3?{(SCCzEw1^V|O_VCd+4tdLqKQaub zW*D*Q?q3gT?gqR+!K=x05|_KqbGYLv0mI5+lzu_PNzj`D?^-*kp3ny$fwcKH_ruilM=jMmvUJ*+Pt*FR5a1@HxGvLnEwD(%Fl}?S_JXLUP*QS#o_>VhG$Ocleo)?@jemw zBpOI23=T@uV_QZw?sSIwO)LS;XnyN!ZqPRq0txvneC(fE`z(kKcHq)?5%D@nR{Dlb zY^JJe4gO_<_W)3Y zYntbh*&ypKnN@6q3i)&xa4UIlg9$Wwxt#w@ITWbx1ze6G%-K>~<8sS)B-5MRnI0wyDYZ}J3 zs)K755Ypmdpt@wwZ!~(Hg!?*uHno?w+Uzc}xejZcZbs0@z$0#*xt>=|$zX@Wz8FO0 zC7YR-1&;X%k01CZx;?+bJ|7Q*{35f+8^n)<&AqA z5?v2q)_kY&Rqd|9O!+()W&nTWm^jdeYp44)q4eih5d37@;n zPhJS?In3xPF}?KLPZXGV&1H4u7i!?+v<}kd#LtxQiGE{1A*5^Ge*JXpsJ|uUp^VX> zokoPo-P_Fsl1!dft@%_^(_@GbOu5`o@hclIt6O{A++h+-+D5GByov+Kb4p0`hN2$?Wo%r{90p__|L}3mo#PY z-bDU}pLv{r^&jF>-IryW4{LZ4;V2rPl6EoAFwrGjrxBxDH9d!AYYzp#X1g)g4^oGH z5RUD89ruMn5ad0GV-Cxkr)5zi%MacXcmE>^84md( z?y^RL1d{DEp5AL$2hzuOjNC|YKHv!i9yI1VptY?K zI|%!cSi;u&gXoY%>E2t%E55^j=$m6hi*BN)k5uj?y|ue`=mEq@*SdN(va%!8<5z%m zkL7RYlA(iZtj5Qzne?%7-qE8^x~gV=PW+1FX{Le>_chEdcn$&J!Gc{31bhH1Qv_l$ z!_%mYM%|;;w-f1)h!0KDEd2qn*R)ws0k0dU+{W(`0CxxD-5(gXy2ycSkat)CfJVPd z)aR4JsnBh8xNWLhTSH6O&|piR#=1+R_r6PEnAo_^+-!YsthUAnhS<}zkX-$>wapr6 z06P8!#fI&$2761IYlv|kJO~>90Isp2j{4bAC9Do@a$Uom2;M>G=l-E*)bL&&@_iCZ zJxJDma(Vv%UkwVw>%}<~Io|wpE{2h`w|4{|-5vaXQu=kT;DVnE*coox!DF1mPTjAM zAEMG5sQ&<2jci+KWiEco+U8ZbzIM65k5Gqc_xbp6vM6&+g3Af}Gl{HSwC*nBO~AOB z^6~j<(%035a`Bww>SDO>0j0Z3H;oHPA4GC|egkfewF?Uz&Bn%^coGJj_;9QXo%SPd zvv;evzTfAAXPN&1Y7bF!+m7c=qHU;F8(UmUi3I-uJG4L_51$B4d%t2iz}dgll6^Y& zdY-ua&EB6s%2AW~t$G?Z)GXNMNwK63zz`sF;lePz-()s>C)U~DZ}Y*E{=Lw8lk9Fg zoZnP_mY~M6wzFV znMq}SiyXqofJ>Mh=T_aCy0U(eKQvd`Yo(a@X7)Bqp5jL5k{ZU3(T>5Yt+>v&TZ`r( z7YT?S(W=houxI9BC}fzA7?%tq!X*njdWP#|hFNjSISp~~X;GD5YYcK9=r~qHSVZlA zvLu%G@27&Ln(Tv4{{V1fq(FIyX>)#$9JW=e@Y>l9XndU-8UP)=qutMRXIDQ;M`0mz zxZi9!z&m#0@6t~ZD^ki!-|9Fv(9`sbTuksaR;+8m^!2gsZl6V@%=b`zEy$^)6SdI})RI>x@gMlbJkp*%SPA9; zn)KejQN3JVcjFP4-Z^eUQ09Iiiystl#&PSWvLc4Hx~#F>H$ogX%eMBO-;r0k_b>ot zon!QlJfYi>T*Y;;iR82(`>ZAa(o6vwBJ|AHyQ$(bvS3&>01Zk0NC|Z+THK>;yN#Zf zJIV3&DP!lhx})@LH#e$cH(_f{gPwE*kI1ZboNIk|ys_IGkAe$^kbccjf=?aQen*hc z%zQsI`QO%M8HPxS50;>QTkYM-k(S zi@5HFxzRcepvU5oGSW#P4o=pA_o>}rtbHfz1_{?sf`x8%jh8kDf#GLl=lCTqTMk3+ z0Cd!WUFzH1$Huuld1vtMObK&w$0GrX5io@f49L)VbwJAfHp~W?)Q6Eja%-Mz!Vqxa6i2dQiLtB?g5jwW53*t5Axp;F{ZzYe?&L)M0OgYGN(DgmBDe~arl@D z9$aU~XEsS?oR4{Mj@%-g--hxTxp?Kx@l3-$T*r!BV;rFx7GsVwy83VVB1tlJB{+?z zO?w$l-6SRpojV@)Iy-rHF)3NOmh5w%EiiXz;Tmve3c4}vcG@wheb(eK2D*~x?vH!G zYX-VRw9GBs4vU9}Q@+)HMg^{ACj6TXRnxiQm-=jL;qP@{p3r2$9Ky4T9M3n9;Kj5@ z6tc=hMift^MqC_SHM&NAK6-M&%fv?n53e+_W73c4fFs4{6I!z`Y0x$RJ|#g)y6m;$ zx|&}17;9Q2ljH)>qo%g29NedhPp7(UZh_v@v`;Q<`-Dz}a>qQ_aepkoKV|WY37oGRqz+;fzmv)SKDK__zFD!O7y3`B>z|%;S#{_A+thm@@fH zBe^Pn8Sc85@OBls(suk~T#rc~P6*83R%l3ed`9}^xx z4$7J01RYNSP;XHOb8TP`Bo{c1#F6xii;U`ZD7d$>py5NDH-Wkc)(pmnh*`~JyX)gR zq8xv2{{W&(cQzahjoWk_tVn0(<3>=7<%~$}!#H00yxueM7{VFzVaJ==9-b)2iaKjr zQNF#_NhFrTvdhb@$a~!{X(Wxrk`AYFiQD&}<>Xy^K;P;BNN6PcTJ2151ov4^y4m`B zi4m_c^F(Gt+4R~^@{_ZCPFaD+la3=^BP%~sxW3wH=EcnXYJBhNd4nu?Vk^_o_}B6Z zNhFq)ENx6AxQG)XbvzCt0&|ybxf>XFS2{F-q(GgmfiNS@Q2S#Yp(F_IJHnkWt-nRh zGIf$A6U@e;j}(Bzk6G}@+^fT}zRWp!h~$nF0n?rW}B01!p0QfA@!BZO3Gr7MG6W+r2$Rb9X=n%y$ zyss}V0mYQ?-SqIU;Mw?b=DriiWae>Wgt@G|9@(D>lwl~Hf$j>E%mUHDgZB^irb!aZ z4Yx71m~s5}^95^ALs~5jd$u<3XlNi2Q?@vh;7px33o{ac9@7QRBs9jll0Jx5ve@B8 zRX1$5%S)IaytMl#cBVd$K1$CgESNB7=4Bh4_(+UN8%jG+=-K3P^L&>j%zQ&A;pREc zDC3CX`AtS&T9xRfHasz|8+R9ond9W31ei`-NC5CS079jclV$Gr*lciy$t0bv(XII{ z9)c}yMK9R*wBJ$m*d@t*mSu-__?hXQHU@ngZdnX`QgZ6Eb=G-^5 z$#L6RY>__Sq^j})c;_yAHy7%Sjw>8Q@9L>Ip9{m188ZAwIj_5rVZ}#}Cmcq`?t#4) zPQuXOTsHyRgu_$Jd8a4Z8{sF7b@TZl`p>$`>vQBx4aAm!TuC}>9m=a^7Z+}58($M;=VGl)i2* z5h0-Y<@^h0k@z<;@jzuBUp9Ghju}LVMCsQg{{XtQlM~y7k^s1XIVLqQKJtjlT>k*R z4~p7vRihrt-DQC6Ai1p@_!1?*MEnZRv#aM=>g}u$T1#rW%}jwMt)Fk_PkvNznNumR zFwyEpN2FTfHjrzW_Xyprg&fMCS4_sK>^0cTjF#Bf0^0;P97CFTf(ZD^+8n3EInHYz zD>;l&fHETu@eKr{>z}8K#0RU7!G0~yb67b(Z#+3{IO1a{^74%G3XR6)FVgW5{fNPY zwJ5ez>44+(TnGoTBe&uaaj6?ij30DzBoXDv2-y<0O()n)kG{hY|26#Y0`*2$eQo!Th1D zd9I={!~q-;&=XV+o!xGWHLYldi1;ao84yZt>Dn~|#uGBfGu>H|CIJ#S(7~0VL#xfj zuO438six<<+6!J-=UO#s-8)GW9lSWpr)ZMtjy<{^K^@VksrFbZrnlPQ$NNCsPqoC5 z8`vt*mP5gpPM)$NHk7XXypbRn@(3~qks$sEln1<;$t0cb6C^`gU)oRRp#V!X(D{i| zt)#zeM&f1w8l5G2KTDzPs=rfEaVTRe)o;1@N^S1 z;HY6@G|^wG9?Kt%kGZ>M9bGjDZl2?(xc+XdVQI>?W2Ft2jN`*uy} z4cOa+Y{d;>3hD#aeO)V$;i-}i=KUeBb$=Tvf~~Br&0{NQ19&<)x&tGKRPeXt z-W=_%w#PV`VGV3cfg(HxfcUKwjN0pP53Cd!F247>JzH1?jBXinZB4=pOAKsO$>{ioL!)>fP(Xh47VV`S#+cwE0yH_5@5nKZ; z9@0fl8$+LA0JLq;Iqm~P;H}p2`!35v5A*w7ujhTCf_y%3k55dk@3LyeacE;f^h={j z+b%q7*%g>a?61f4=-cYZXQJT9^&0*O*W{XHGyr+6B`d>g$PU=&dM@^dS!;kTmYt#Y zIipV{ZI-w8Q|=Xze$%zWN7MUDTRtB&db(9FeTCFwIn4}cK8Y{@os#3my^&di`lIo^ zDmMDEEA&XNJx1B|N!Q{#uQRdieGuxI_JYAtxvqFS0fFq@>F(M9nEX{oW5^KE#)J?* zkCMDvyEJV5>`>7pgXhYllNNb^H*2S$i3=TY$TRGnKvkw3}ggeNrcIQRj; zS50ybfS$zi5S?6hm`*VfH6zz!E6^PPyFf(0KE$;g&35>Ev3hUUhE zDle=KWJoA4fIl>cH-ZewJ}TYYTduGtQmEuy+S$6-irUc{iSt?f_cwCY`AiDG1w|ub!6BYYmnW#wpt9HXH{z(A-N3P z1Q~)6cEFCyA-F9MHr(-RiO@(tda~BA>iWSxJCE=x&dBUE1aLG_BmH21a;36#^KiZJFRPJd3hSe%=I+pG;*oW&!3h_a-5zh zj$Y#|*^GTPXV4?1lH`12C&g#+Ts*HMkAn$@8RzCQY6N}VV;yeV?Rdqyo8I?1wOd=r zF~eRR*bfCp{I}Th=I8^7Ys15qi%ngkYuBUvu~3d<*JYZ{%>eXVhlAV7g7S;grWTaRW=O?Fj;+T7;c z83FbO3dL-(;wDdN;HsnH7;r{;fR3V5ncy9+M^|4D!#*F#`?=waVwB0rmmnvKQr6^a zc^y%+7T1Z01V|-VZXj<3(g-3W?^YdCM7u~0fvFMQJ%CkFz3p*e_Oycm&eKUcX*0s7 zkB?oaf3>xT*4qFsafeLt-~m=J@r{;KRU*4L*eiQo4c)x$XcHz6VjHBQS zt6=4iIg(z~Mm!k7Gs-F?f$ACqpgc9Kdh~L6iDl=dryMzWdasD_A5NS;f2H7Qr*UIXVK6ugN{lvRQiANHwtVaB=Z$vF^vLvYWouk}b05Q|h?m*4EcU%UvPDOnku#j(gwL zZnBIfs8}syB5~6*6yW+_14PTUsHkI?QD@V`E(#f+_||fUmP)+ecP1Ccwlsa z<|sr79uY$0!hTV=kXy|BN09hjVF~3NzBx~a94d^YI5h)?v>pEd-)wAax@+Hc;kpA^ zeNJV>dW>@+qPrl>!9BcpC^TJ_>Q`3h(@Slz8x3`k(&n>vt{VLj5`2)|Yb|!l{h053 zHkY`%A-hAITE>GCV1X*Nc@M95r|l1EY1HsYKfw>H^%^kTaJowyUN-kVp~TqW=DGDU zz-*Gj>cdGMKP60c9Jg2LIJMxGIqx-s=bH6kc_5btr?rlF7v%buU2Se5?jm8XECiFd zpQ1-%hAA#-EtwHI6B_Ljcv#%W-lxrEoM$X}WyS4bgoutj64tnMxeFZ}oP3u#lb*}X z^E}!1ILt9e9!YRUCS;B)8pzkpTPo{GdxHrKbV!q|2-k!uJ}JltP(b5Pia3%K2GIj-=?E5CEo+<`A3y;B>8y}7@5;AUAhw%sw$W8pJ&Yi=&MtGq z+yD*otjebFU1RQhTG=Fqv_KyKv$BlbQ5Z4$B|l8a2FN3b zuhfS!v#8t}()g_7ByMSt?Wglf%DIBFTN37&J6s$z^JpXSN|!fx=MRAkTDoh>$i}UW zvbz0OHQ=zk4bI&V!K@FYA!R-7cHemrHvJGIS<*f!(D)3c%o$^s>M_cP7YHV(>!_{! zGIC$>B6B`65>jgok82n;aSa2^=#I>C-AHSU=t)1^j@*zN z`NRYJ%`xVqZa{I6*En_rkM-3b7TT++l|J`X>Ew$@43@c|03D$Rb6~(eJgV2&ZobD? zFy}qtyFh?U_LXLT4TmstVuZMOIBKg?TK@nldLD27EplHGmVQeY76@|37wd*uO2LVh zaLb5jYV8A=v<_tUB0q|W1ZYt%dt5;t8uE2TYb)3s;3G{zpT1Ux24>L9Uc<7RD;8Kz z;v|wF2KEg?e^GJuATUWgUG5}^K4V2Z!B!m>V^m*b=7&DwKxiVe;?U72m-D-~3pVRr zA>23__?;DQdn`G4!ygwH-E<(s=9Hvjb+NY#&wO*3<+)xAFp-ow7{)OYCPq>qLRWk? zM+Nzy18fpYLGC;}lu<79+hf|#bUR0IJp6u0Yi+k&&Yex?WkS|uhg#^@Pf4P-NZlK` z6VH+l)+?R+OD7q!DQ$tx4?CSZ8VtXZ4=|&Jn15$vHSTzIRFK$k0xZ6#Ijm_O+3yOD zU83xZZw2Snadg`4?=!5uzzIJjekILfhr{`N7>N?e9C;=PsY)Uy2Z)XSP`~0l&KP_v zl);1;8A3U-K>AG^kE(}w_xdEPZQEyqpm$NXZ>a5~Yj+)>@&u#^^xO<`BgHd_E+w)7 zIs#{{UIe zb9}{;GK><8Y>@&4qH4h19#D#_8qViQba*qtUdy4BX5>`aJ1wz+&iY$Jh!Ywt+dvlB z(*(4-NzzC>$M9OYr*>{bq9)gvCSqK9J=H+jannx~GY43K*aM`GgR)H^kGVf@7)wOyft@)=p|*=^b#cAUZrxgY{{SfX_^8kt$F<}&$K4HccMqcj z>1o|-)JeF23P0Yx~wT*L<{+J1SfmMkpN&Nr9_65`37l%!m^zAj%Xx!|T^%EH_l)4W5f9Fo8` zmYoC!iH!jK6z;;iCC@dvtO0_yxz8dTNzwyMXkhp)JYd5VM&to?eIwKCNE86QfDc>s zUEM*L&ED`B%BW@yOz1a`-zd~5T8MZsawG;H6*sLCvN25y` z$A(sD5DT2p2rPE*cAK9EPrebddUi%@o@sk)Xsxuh@3GA-aW2zqTId@{2f=I7(9M<9 zU#pDn+6)t@)(0xhChF*}=C;S#W+@J_g^k;|w999}Gw>cNk4nQhfwbh^OjT>$V@2}d z-LgHqL5Ys&S?04?V;IVd@%FF>yH9hSth5sZ$n!?bqqepDwXfKUck$RN*C4DD~TqRpGY2%P~lGwU#$#^3yEc;2Y<_@mc*71^5kaHeLAfP1ZiZG9|&K zvIgCN#F5ED>V~sGs=Di>-HWoY9_=O0aNR8h&|M?X#cZ708)u?MNMqj89A8%81j}_h zppX&Sf9Pzt^_bi%f<*2X3gxC_zca$;FdA{il$#g}?XAuIArJ=QV?g5HY&ecQ*2Q;^ zvf2oz&<^#R7TM3N*KIB%_q;yj00*a9{AmOSaoKk^;YnsoYq9Jh#q`L4Ww2ek2?9~u zk@^?g84owa;i+_8-`9k5}S8@*T2t#vt2eP+j&0r8@cJlbD?<12a8R$pi zK_6wd1LpQnc`ZAf_O-1o z-1is*afEvC=&?RC@n~{ftn%Z$xdjNuJW@PF z&=lwVU*d82e;#XZ2qRzhl}{%koN@X>8ze___XK>d zp@~$r&x6c&`Vlf zGMs8$LkX3}zeG-lsl~(ajGr6jxqSZs7=-Zf%Zzf6oVX-EMCAmKNzl;IK37t8)x!v3 zaMi78?l|1%xl^v2ZFbt)Tzp3g&riXAMS<=FR1T-d$Su~=#(*JEuAPkmjoQWtYetZh zo3~S-SD)#(LI=TA$q`%ZZDr4Bn(G=8erux2F>*Y)0E)#OA~&Eq0Q8fdE?1W_t{hk) zq+l=80kmQ_@C__HQ;$~CWyHxS(Cs2;Zw#Emv=yeB$ zhgDCt;fxYW+@h0RO<~l5sq;kXENSYPv#Ad{&+=TX^_ttiB!9u+=s)5c5TVi-e`;fY zTA+x}ZLe$Nd794r9W%S2}B+;upc6BGP zExuwx8O+YY82Y?Q==4&CLMLpn?w^d91u1kw>dl*;dqQWzJ>Qw(;saYe%xSvsV)5MxP}N zjBBho^gA9hTF2K#HMkHNQQaQrJ>N;snRGz-m3u12*8c!f$I|DU!KJ$k153v9zh|b+ zeUl}?eeyhdx^LLBTWPH4v|ajY>$1jH*A`R=)r{A3`Dx@GI9%pf%bm&k%EOBp5&)l* zhf_I&#Zu6ibgfHIAj!>09I!svKAe87_4UrX9jNToy5QEAIt^qwt(o^ZqIB_Tk;12W zeod~m%oPw?(_2G`XaYYtx!sf4+uQ)U9z8wvfJ1h)#=A$7xEoD)&MvL*z1B#v&Ll)M zFhfq?r96)hfi4Yo^t>^Y%bGJuqP&({aAPWMu65AUPra_&NYi$pnHoZ`g;l*m>~b+p zG~wijhqlja8*_u-W9_}pd!H<6_MaU!Oy*sd%Q5J>nlP~%*ECsIq686BT>k(`uX%ji z+#X81jP8+ZaSL0%aldEL zi(`umEULQB=9fF(#_In7bD(>sJ9dG{e9HFpw^l8(w_{db>awo|rO&SqrIVV zx!4%>=h`WIUs$=!VHi8^RkL6y}F)mug-fMHinX6p_+Tk6^$tKJ}yG9VXrRIT;; zo^6fCeJ-Wem$bUEStaB)To}U>@qn5C02q00TbqU~Q^s=S#Um_njhec@PZr*mx5a)B z$@AkJdAuI)uuR}j5aHq?!6T{ceyv;azR!VWc9#c>OLo1xWv&2+HK6$M%Ec8piG#sB zcr9G)i>w9Q2j)&SOfn%|}E1OqauxwZ!T{XqC}8%sce%m8>)@vttryBSD^kz87~!JVKuBdTjaX7 zvCbA32TRB<+8Ef=%qqFpV&m6cSWc@V!&94nOGC&d&vSrhsu{yJiQ2IbB@Svb!-g`B zEKvg{V^(Bh0E9>z7)!%$%pBJzKZwUCDTY(Sk5QU(GZuJ{q{c+)t@Jj5tZCi3@c?i+ z`{72z?mq3n>I_8Bk|};e+$nGPU9E`+anKKU#aR0dVzvWec_VYSle81@16WxVUy*CJ zJ??uz0tqkx8%NwUQZ%~4;?O{AcM@C(5vM;jAm{5Ly7MEIqliX6EAEE9_R#IE^h27$ z>sw#F&eQ0EM~0o! zk&J9W4SO^KydjJeuCb$Il!hg3JA}_|RBm$_>I1pX+5-&e*T~jCt2(IUHHXx}$ER~# zD7DWHaU_bvW?v15I^W&!MW&qIua!>wTxe~KQ80+uKxgQ&3rrJ8GbAAT=+x)!$w(idWjK$GRFhGR?=(PYmVk>8Mu%SZhyTq zSYBEBUVZ5@Y?-ctCt#677>cx)VU`@SuS2OkwnuSwSZ{XJ3t z02sbFc}dLSiQ^NV3=q_C&JqOW*6hkBhxTle!CiHhI5@mPt(G;gSTq|2bm24--tq5xfwQM;I|rvzJ`6K=aBmYZE!U*y|xBMfKP2?f!$;@ z1J967M3#Zc(_b}u>%&?q^y=Di+4+o+b~XEhhP$V{typtW!|?oauWAH)QQ_EeT)Zl^ zdj40O!^wOrmdiMMFq{OAoFW`r*}j7Q#?Cj;&_`YM z^7jqKB#50BdyeZq3jQWI$QPZ!`dIcpCO(M^K4s!QYh$PVo~kmecIUp#D?qJ)fY%!u zz~?;AVLyV!_%>k~bGao_1~WWe{U)ouJa7C~=LnC+d6G=QCR|l1UkoKEL>s?MV^)n2 z9ks+6kU@?R(IAT63rW$YXM%W@TdLe{&$`0)SV(B!Q6-0KTHOn^(iIxnz2Kcj;5Fl4 z6iaL_mphZnSnYF({mIlGBsIoiW5~yv=He>GY?GaB^OG+fo>!WTdEbd*$1j&IN#u|k znw8G#`gPTV++O!QnJy%g<0+C!Xyw!~v8rej_PkbEHU|Uz>&NJ|f<2wqbA)?%j#h_M zwYFE&ni%E^u-L*~KI6XEZUFE-(6gV*h~u=Wek)VvWe9)Bn@*_n`c7d@A`fzCU333k3*CctnH zHrU@)wQVH1#0G-)f^_HLtJ5WfxPl9(-780@V>R77sNJ$%ODQaL&eH4H&!TzdcYpDC zi2OGkw^I?O?h(Rp;v~uA#Tpse@*rzIBVV}z5EsGJYaSj8 zq7l}>uMK<~>w>2P_mmUrv~a7!aciu~^vt*)cx(s&5xKqO%G$RF6f&CIbP_8S2He6Q zyLQ43*mmu8{N5KYOI%*TB4qdSTli;t`ekrrdJR7jYnwCkP)-sPCy1X(mb_FrW#+5v zqhglQV|9_KonuH5*<5urI5CWImqS=L2tMaDLEG-!LDgoo86WG}XyPAJBL$E_2DYD% zsCfI;ZnW%nyB)30c4;-(+rLlhkO|OlXd_-@`_VqES7m)ln`mh+HC^eQPUpdHfrY2# zD<>KF492;+0Gxmw=(}r(ouo8rV@8hGR+V?4b%)_(w7Sz!ZC5tCTT@=@-sYDz?cm5h zYOw@h959ioLRV6w#CZK6Z$$q9BF8xKLx)0cCrv(C1LD)Z>MYvo?R}Ed>KDw(^DPR; zMmE>gF&{%q?ENTU8;Ns`HjM>kuK7x%Q|k1b=K@~fJwE|I+Vk^PFf%R1%Bt$#<{I~r zV>EjSYk+$kAjmrNuN~KQW@Brmu5;^a(g{r&Ud^+FDM>F~G^x2v;!i zkq$4Ez<&2{61zeH9bUf9q}F3sW8YY@`-6kS$lNv%H#Pj7(thOEvQxtckTeVY;C0M)!O|nOqJBOmt*7H@Y2T;+beJ+ zokMoWcjOv)Eei4+{Fc=qhd6-X*FXR?hi;HHk|VTz=8GGS%zznV?5orb^h@@F;UA+BVRLqlw((t(Or+SpH@8*{h+uO#g2EjM497B zj>{(s%!cGueVd zV5((Vb8}x)U{Y*pacy7-A)B2IFgTtiT%^`|b?i1Bg2`;KfwR}I-XFpELJm$QOR|lE zxB70fwr^=}goZGWd%2x8S~c{`8--&wT5Nm&0GTgtjP;uBHHq3M=}Kv>2EWMosGS-a zwq)1TY@x6*oogK8+JGBKX6Hj)1L)5aqQ6(9dR^60OGmYv%eN2@x=aB*gJk|G z`a`;n82j^KDW4Fq=lS0SJNGh^m?jGT`uB`JX*az-~8OQ#XOy#tIt;}#xk zoXPOsPB|ycMl+1Eh~7L>8*!WS(|sNTA=Oo_j%fIhKZ@tN*HvR_jAyjH+&QEjI3;Cu zPP3Pjd)n8QRM$WNZ6-W>{E)h41GDbh;_a>aP9NS@C3kgRv3p-jor{RaOI$f|ZoX3= z=7rKSjow4cy0Y9>v;ncL000042pkBMO_A6HehcuAy7A@aa!;Dgl!G}-Z9jH5Q4GHW z_$0XjmoG8QPn_ntf(~4nK3zIO8$@c;_t^gKdymADx(=Jss}zS`z+QDA>mEx(6QI$G z?ci>A@`HbX5U=`sbbvlz?NwV#Tc8p0QG1%!>O`sJSXc}|085Wx2hCvq-F`-Uaj7WgtiTrPq_;JM!Vp2Idi3noFjy!oJ zPMSn&(rp2v0DwG{UiP(`kv=6us%N(jqF@&t8qwUYV(jdzi8feBJ%)quQR@9r<6HJh z8f?pO5CE8-K0g8e#Xg%(Ycc--TC>!(6qy$#b z8?Ul^$^QUq$>sSR*?IYMyw@;gkJK>X2Zj-W{o#J1(&c^;%}e5WJ|oWaGRYCe9$S`= zryL34F{*)Of-|i!68*vCnaEYg*k&ap9x9m2J%A{)_?V7+uk&VHmjn3dmlkiUa*aoHl0QTGe0P+f+R(PO(g4SPai4S9e{S-&? zSktM4tB~+8X~w@D*NaAJbH7H{*Rr$jYc~e9<z2V|p?qlJ^cbJnSligA1*yg^m zg}gbBW>qllc9H5dOt(?-T@O>Hx~LY>YlH8(o5%zay1R~>m^m%inN(WqvF~+nW<&4D za~)O1jcIHLJ8KQK**cie52M?KAk&w&E4h_79l`c)ZJ;%~?{lB&GPajLX#gF%kt*N6 zeKgo9b=2NiUejUp_Xbinn_L5*?R3B`&>s5Nw)|X51!T61!MHVtBEkzSYibq|MNi&z zFdYy_nyO*$ex?~XIcOi(WFT;nEqG%yzfeyQroLFlV}uSEM@i(NL|0CfdiMPJ{41M7 zA7iPm-(YEB4K@v$5TYZ}l@4m6i5nfVTTE61wg zmvc+mYlw7K*M_zLb66%plc?ifQwy>1uw9N{V|HBkif6eD+FV-F(nie&o;uEf%zi)E zjVyD8R%6iO>uaXHrPdogOCPbrGoHbB*eG9Y-b3lU5B(cIv~L&BV5N_JUkn z`=wgQvkN))Vp8h;4^gdjdWOOP+Fs+SJd>k-U6W$;_Saov0BZpP1RYG0Pm0I*pEo?Y zxqMunQ65K^JYIq$IpmE*iE4Be<9%EnZamjN&T_Hjd4Ugy;XGzoa-Lme$09-^t_+xKzJEvb1Y^;-!WXakI*)cG9eSl5NXqM_paSsb`v&g-Io3NXOale2b@km{v{_gTZH%m)trA_dIqd|;!{VK^ zRvhQOtaW9P4leG0lN!fqRJy&7s9kli(`XN4D=^X??Zet9+XKG}9&4VKEK-*j>m)d( zFd}#$Ec&Bgyenq+$9^a|PF{HNnvmk0~NZ0di)br|ZE^CXP8c(`nJ9#F! z`a!k=-&B`DY4I4lVx(PB#@z+fepVS5|CX6?^_cH4R zxgN$p(sMS3Gj{i~PU9esd{$AV$LQAJI|&E)1Ux!yvd3R;uChsy0t!E-2Wroj5{VIjgMXGqko0PI;CKJ{SQ zC}0(aIJu5%oya?ZX#zWmlqwqF@Zrz8J|HODVX(B4Og1$DdG=K;%XN5PW-J?=(mhyi z=-kH$J9og^M?KbfV_bKGxNVcKe(G74*<-`qI_M95G*3%3Ye)n=z(LS+;<7PLJl8*u z5gd5%h~tcj=^vE#*M7clFYvfx_`k>DgC-%DmE|L(wfS-D6E9a^HZ$$p1DT%bHKooC z9Fqx=alw~9NZ8V3DYCb1Yr`B}X5hj$z>f(Nq8<0%>e|=5pJ-s1Cu?|Y_zud;%L5tu zHl405X<;A<*WEgmO4kpfJ7~22JIv!8r?e+P$I)GO?N@reNBno^F-PFi#$^nC^tdp9 zBP$T%u^msBMBc^^PFe$Fbn<*vdx$o;h>s*$lIQOuM!3it$ASZ#T;k)&Ql^JJ?Q0rb z=N+I9N%B|o2&)$fo6UyYQb=iyq~C6i0(WTH`;|H?E_HRp?r;&r{7Rlpfy|@_HNv{~ z!$A@5bD+o)eakj^AY)wEAruGMvET0H*6C@go|?_>Fr7mg6OB z^zE(6bDgOBK1)M^l26&5G~J|0P<#s%C(LBYD;~@^qb}0gKWml$02Hv|&G8;wgMT2`0a!hZ>PMq*8M0n+w?&1TgI}e*zo3p1Vcd7 z&mY6dMU88jX5s`i5D4eo(E%y;9eF~qlLO$X&pG!-WBS7=>m7y8#c5spF>~C|j#11` z9`_IiP&7EDDI1CHzh z$M55oC;%&73D6N9U7u0rqZ~g4h72$m{mdgCH~~U80zd=k+QnmaIvJ0Oo>7`zE&zu# zhR&oAe>araf!ieTPKr6reRi78;kmWAi3A$==x%EJvlftNm~0@G|AAUUT~x4&*zG+i+vqGopf9m>+^6*kP~ zILub+NpKSzudT9wySh0@o-;5^G!gasuI1q+hp7CLvA{STvIOZP!{D^KcE{vn`*xN( zvpbq(ZvgS`2gAQ*k_nSP>!Q2UD-X-AW*X)aK$x2t-rp5InLxJ^`oOG**jn@Y0`S7a zw2xiDz;}WCRXpr*i<0KK!oV2F4fNTonYa8Ko;|0Z9_e)Mmu7ZFOxZO$*4FnM8DG*e zN58~yx*z$ei)Ijgc$PCD`-48z!&p0uOFd1SXKX$udn%Z67)WtzVi&^*nH%fH$A6O_ z6rz1n95uC39wgqsVhk2k>S6Awt{?*I9Y`P+^3PbezwVUQwXCqinP32F!ooEkEG`-$ z<4|o3X49Z(CrJa#O;3EXcctkCv6I1tHe2H7CGV`wZ9p&nh;JZx7BmeIJmbO0}FKEcmf(F!gbWa zMi$UWbW&?1X(L$DK9obGXj?x%9;#X?y7;CYrhs$nGo3h|(x51FL!Re7p_a4Tw|ks- z4+-xbzu9@Oyx_d;yVVcd2DbwqvvmV+hja~X;)cMx8O{zLXEhQ8ZW{6<=|nn4g{1uA z6;v=&ZbsTeTz1F;N%h(ExYB!WQ5f!EeU5#MYc6NBx72fv=AX?D?-~aG0J8ILyx~3D zZS_T)b*aGZ^_nC%Zobpc&3W^>W)jYRURRgmmMnPjnfj+FMlmuyOo-j_OdqPw z%B_~Txvg*xAP{sTju%OT(rCk|F^zyfD%7J4(MxL$APpi4r`0oSz@gSz?F|}}C~q4? zo&wIy&8CXoZLjp|V3#=fN_KTjY^z_7UPX3UU(;hwqqogvbzX&kP|s`b$o)l)1+)zv zyNJ`rndh>l@gIz2`@Q@+Bbb?&29?7T)XTtDwX2=+KZU#~ouy zI`>7U+%C6)U|@No!dYa390=5LK28XjJtrRypYiwK0vK!wm1XvKn)EM ztO7d)0LQ)1B$5x&5@WuB9I&|iMx?+VXMnF`;r*Shve4#aHO~!bcaFF; zT}^ZVk;Sggj(pL@5_gdrN5!Y<1^@ss)EgTO*IhsYdy@ct>f@W`sX76w%FW5#_R);i z-Y;pc+iN@hJ>|^TW1?em)ylR$D{HJjQu}LY409SFxxvs&r&2gDp^jP3;(gFe{8gM>O6sMSz0PH9-X7ap8@qHy?M|8q26aZp>DF}{ z?5g?2rmEd#Hf)gjccu$V?5)0H5AjucWi>wfuHMHnnFWQcX)Z1SrOae#GM@&~AePVHr)7I4=UqG56uzgh7F^dClkN2D^!1W-E@&~r ztCVfT$FlO<*!I@iYt*z?Cu2iwce~XMt8vrwmEIA{<2<%Gab%F<&5#`;2dCT=Y!RoY zipq{p))*^t~~$r}FH}q+wZpeHk*{l-)z!TdZ?j;MWJZ{*8_UK@xc7XnkVO z>F&n#u<&liG~_UsI>O*~veC12?)FLhq7{y>)G?ihZFSR#U0`dfqLH!IKh}aH7IfM#^$JW<-tlmg%LD2*0G|sA#br{w?*?Vuwb`&EpFmo(=8{z&z0+M&t)~Stgz%f5czJ>&|K|c!Pi}TD}8gV40dny%WvH0 zOP*ZkSmuV4xIyz!=*_z-ko=~PQNviCG>Q25E`Q>`5ash3{405Am4i1LP<5* z=RPa(99-5+p9JNnJbAK4vgF6ZLvg`+)syDbs}CO&9nZ;QZGH4L;jMGMx_X4WMs{;_ zX+PbW)GapUJ=?c}K?Y<=0#Q1KYw|3B;N}4m1GSi$-dtzeJE~(-3cp9`kDx&WI1pZZ zTr~TF*<}*#L2CeUE)CrQqj5)VO<>yA_lQk%TE;bwlE*#4&}6oL5I?irdr;PVJTS#>o49j&Wwt z4$ylMz~jr6YpYRaQ(Hzm;53l(N74k(Z^%`SpVNg55+Ds4vkB&N^CATPtW>6Vxe@Zj z+0r`wuQSTx_=i35VG=8skE<-SF_AQQVs)Vt&@p>~A~=E1Gu-LUrA04-KuU{o*;^b~ zH2}fn&yt6r`+cCuF#~8i&%tOux!1T+bx&<>aWG!ilEV`kk)T?m^>8Eu!x+f$#GZhV zH1AJ!%*!7o$`c5Iz&#^Qn(jgTnYEBc?hH@C5I8V`T1k=&IEmB6L`!syJLsclc7P$I z!5!!Q%P*+rST{Dqqa5dk!~jnxXoxxmPZr~N^&HW=-7g|Zk>}z0RJx^C-a}cb1P24p z5RFDLu9634kki}Zv9O%^dC5%iOBnqrU#x?s`|#B~2f}dk9RC2v2N*Ktd3|Ro4J1wQ z?|&^*3GLZCM7R!Q@R?4KJw}tniSOUR69_i9dhfCI?R8LC-*Fp@owT@tAPqdwGHex+ z?cdHG`shjbJH+a*`c1C0SO@$Yw>XkU(FO*C-81B|dYzJV_Q8NT?XM~S029wFLNOY9 zB3wGidaUvG=s$(Gf8%Gw%st7({GOa{yR z&Yiw%DyHsnk*x5ncq_+b5a-MFKY2T|*hHgC-zxs{f?P2dn9aC^_m4HqY9e%62>YXUVWY-xMLMFCp1JI}uZ9?*2u3472M8l=_hj(awWF6EWPU{iOZje)K#7PN6g1fMiyLc*`V9^q zUiP>6tvcK3;MJ1SODwZ4nP!e~Z8SGo?eF}nI}Gb@5Ly8z`s`X(fI1E!hyyP$7M*qU z@c#ffEgyr7czzSja|Bel@s2HQjyR3OFZ@%EJRbn&`Mw`qvm88TwTTfOk5m5gm5XaM z(#rvdJUN;eB0iM)5a?CFB!D?8)?At?add)R05&@}UEjmE&1V*X=<<|YTIjN@w^#vn zRW;RX!S$+X`1?siBj5d#`3jCOVf#az1hIg$_#NyYl2&gg!|w9H#7s*$i3d?aG5oF0 z6C7%FTaRFVR!or6-j`FGxJe{q(W7U&^be1JxVaod)9&*ShYj>G$@rTlhW z5#%5!3GiMSd~sgraW|%ZlLMOWQ_$>0s-);fdF@1KPjdhQ3vJ6j92(Bw=63L zA=?~3B+qu{)Od=kA9DarC^V93Y-yw-g(1)IPoyZ0e)TPXBEO1Kx->Te$ne)@LcArS zV5FXP=SeF=rCpIzt$kaIn#MVWqIT`Ihluf6;$(dJQ)J8IL$|lYDe`0EhYX1MqE45z ztOcLT@K8s^eU+Cvk{ttS9ii`8s_YOcz)0z zehYUC>nBXEy8U)$+|XQJ4Qy$61cFJe@CXDpd4btr{f3;XXnsYGpc@{;d!0~gr(>Kz zw#wZtC)`B+>p!YuV`1f-d~A`CSZhgiwC!_*y0hs$?Qw4s(+fL>BR8f)9JK~O$6r*c z_vm*10bv4C;RJ$4;=f1E`=)FC3uuOi0Oq~b_IB6(5*<38I9gc0SRIRK4#m4O9nUU% zU1+Gk+q92pbQq0BvEZ}aTP$YlZ8d=-bO&>*j2E@WJdiG9Yq8a`!E0K5uMj3jgIw|D zql)Zt?#Jpk+xstmHTAe#lyWO$9QKkla2vM~5_A(ke^UEtt9CtfxEo71*y{_)+GaqH z&hTD$&~A8UTdbUo%*EW+yzlx!yS+xq8wYQ{h3Gvpir#H5Ye){R0c?T};~lg5bTVY=wO8=>RZV{UWn zXlXS=T*(El+)Fi$50@%Tb9XSe+VJ71I`Xe!*L~Q(qaay!8~r`b0J*@{IXZUyRK*p@ zCAGG_$7n1YM(^e&b)J`b%2S!=O6P(r}N0(2=oQCfQW>Zmh5tSRM?A zYBeEgVKXB95NaS>k%IpKNIBpaxOzj92od~ITa8h0C6zLu;#wV8*xwG|Pb3dHR#}G1 z*!|9^RQgLA*497(>pw}&i0l(k$FcTgWqWbO)dqo)qYm$LoLTMs=JHjB?PSyde3ZZ$AgX?3gwdPIZ7>$}hWbw{sxuG&i*>9pzXaQ6DGJLHc{ zh%=%80Aom_ekd#{ZH=sTYwFhn+e+oQjSZ;CZ#<(AM`JvO^fV}RT0wC<8UG9b=} z@#6%vtp1}>a5KZ2Teyjd@LI=e1-_ge+hiS#rh_$2iQ?3`mi> z)2^>L;QsOV5AIyo*93Dk@8qS1LV0bR~+NXXNNHfPRWKr zlBHW*ONIXc7QP$so=2C<4~6qF=CRKqo=HbEb5yJ4xM(zdj;tK3E)_PX7f6vDd}oE| z9XAD(;<2v;xu5`C(K>vUz&c*_^=VWO;z9rKegP*Wf<7vk?{Wjd8Y8t00930nt^7)JAr}R z0Is|@xgJYDJBo^!@V@6Yk@;j4Gta%n~S_U=48Z z21(C-9tOm4sIzQX{Fnq*Rom~(Zs$Qea>vh-mB5mF>%AU)Iej~ zXmELW_O$ZR=5$u-W-xt@%C@IkSOx64zVPkflJjSN$MIHP+WmUV-3$&J!32Y^x_>v1 z-cN~)#vfYkjH(Q{lP*6-0BpV|PiXuV(Ua3GrH*smXQigbHQv{Nc7~XfBTskx6N8S- zJ(db>b7Z!{7|=m?4G(mE{{SUQ#@hSrmx`O}O+~;se6gLi8H$u!$2hGDUg(x^$}~wA+LBk4^Wo$Ke+c{e_LQds`zy3#V}&P_?pi zx*k3TEF4~ zd6iSEbv~LpJ1}Xvwd2zEyfMM;4Qrg{%(;QYk{!wU4JOF4I(Ac8Q9GYz=Sw}l*6xjt z+Iw(6g5Z9#{kGheGcR==Ij$e2(amv#^hI(!V@_pJ_?I`EljS8IOAPtUnLRm7VJVo; zU2@0`G~V2=jC0)ADTGUu<+Ag9%;&=hVuYm;D>P+7Uv8Q;u`sW7)%6acUh6t-weEE$ zuq$AAaE4aawa0mO-FfFuW7ht#^yc(>I!+MC0*sel<8PZ?f&)_*wQ0{?Z-!WE)C?DxVS+i$nZZkb0ed-sOSBwSYbPB{K%PZhmRA? zt!gQ+6`NW?o@5e9?wh5GMh#zOGQt5HW&?W-bw*=Bd|2&+W1x{E;qYAdD~pyBoVc<5 z;%AE>;sl9yAo(z?y=73GUDqzyG!4PswQ);ucXti$?jGFT37+5@B*ER?B?Na365JD9 zrpfbsZ@s6^shXLZ`9ZPotxK-8HuQD(-jA3mw-)?K6a3Bb{nVayTQ{csH6x2dzqan* zmBmMC*0lOev<^0NlcE8x=D6hWp1*PNw0&8e;eVE>@-nq?Hev!pzP*BRy8Nx5dGVy$ zy`?fLZ6~0*()I|&vID=LPX^)~Y?aYM=ph-a{}VcywnMq+x+aZ?D;S=ZTmYSkBA|j(f@ar zVddmOF5R6??#R!f7$jr-UROb5GK%XC+((059)I1$ffyVs7g!b|)zJQX|MN9>fF4v5 zY6Shv*FsdQT5`7)wo3%9*g;1o)8muh-SJo0Npy+LwG@r}x!iDe6%+o`I!h>&W6ePS zKXRqZ%jVx*BS}uV39dF9te?#slZ=>b|W>r+lxxIJh#3$MQ#pEmE(2Q2?DG89P0O~EQG2OOn;EXdx)Qg zR)MqS8uWrELu){ISjzGaUbX1ij;NXN4r zA|r>7HSck&j7H}@ui$5GWF5T;gquCy9>wk`e+e)E`Rr-(YyFeV#Uqs;?%dKb+0BwVSCnnqr>EC=DQ2r zB+2oPnY_O&O{{n0hGxv|F9QePRWiIZQ5XIXDK_X_NAo&f1=RAlg-LQ689IKQQzxI# zSZI_sOA>?`Z8_1zJa~PsmUQ!D-x22gTBuI|IIb~Xs*F|H#uwS<3|m|L3N*W%YU)1M zR2Un=a`IM4M4kG1?0&Jaf8RvU<7qt5?fE61w9u3_1=%TH270c_)^5AW-efQ$6%%Ed zvY&(sqg1hb&v6w(F;DxG!N=KZA3NLtLG|qcA3XTI4Mx`}iO=-`ch_3lT|c1ud~T#F zv%fDR>hfmy1Ix@Dc%Wy|pyqwbPH>K|(=8H*Anze+ks@E0Ojzc~#kE3<8XE6k{W-qMSD%yA}RcvpWvw;Ckp$zufI> zd`n+tyXOr>Rp$Iw9PJBWfYETVk|-he@|=W>sNJ&%wlOt4s)j({$H-$&j;w!s63#s{ zHVHgz2_>WyUk|@6b1SXBwxYOJa$A0J;=WxRsx%z>2lgHx-@ND&M|cW7j+}= za-}@@{L$l&)RQhYQz+h0)^5!(yr}p@yaE-iR5aJB8(~ZCMF5x-XSW7VQiT;CR>pNy zk=YdUVV$r%CKjq$7K4%9d;DVIl45K2i0j0j@tt{*mlr4ntwLgJ(L`GR2Op#) zQ7%sU8*jtuN?V_wdHvuW^6y%TI6vGA;zueQQ#AWSWdLbSX5KlrsclL0i9b(#MEb23 zTViZWJ8r)N#a;IeDM|d1KY`uC#+}W=%(JS+9OR7NY1g2|OW%i*amqhrtM?o>u3O=r zRGuX1^Bkn9idY{ICzMm`Io6ZeVZ{-|{eBvoH9AZaaW*Nt-jgAa2nN6i#i#a#b}gvS zY{m+d8%aMVmOh_J`62+2UCmXcEAm2y-hASwqmk$Go$VG%?qUAuDpB6lCNkHa_^4j) z&RBk+vwp9sG(csq+9NGlD$36n4}-QKFZ|F;We*mFZS$3ilq&k|{d~BBVT7sYWaLw? zQDZ2%FyMyS(B?tlwaT+<`Q)Y%^$8#uIMk)><*HpUX)cr3b4yoW7cfQoJ0O}$BH;{j zm@yx})EVT!uD;Ry`soRk=09f33lTW&#QEDU(l@Af@fmx8J2|lJH^*(FPMntB_JbhP zb;7#ob?pQ0Q$m!3wR{p1xddY?-f$BC6!B8!A#&SDxHx>oVK?gcTe!U(XVMt6(R}*9 z=d=|nzB865;Vqz7p;@XB&uPtT6ni-?eGq`scq(MqtaBf^;ajx4?|ybn8b=rCbZYcQ ze&X%YCHWqtdWQF${;s;dqcW9KS9jZx_R1i4<}&?LOY;Nd9CJ6jmddxxzfR4Qyk;Dm z9LGHumsv$%Yd6#|CIQwr&iUj*FdJKK?-p=7(&bz3G*aj6Fh+0K18217vcg{gQ(|~o ztfrfSyZsmUjYPnPpPfOmfz(!y(|_y>o2494jxQXFGxbe-kU5TXfh0o{eq=GT_o%9t zszwjQ?v3p#!c75%lKU=pM5zyAuxsr%Q(h85)hEIP=Rz&69q;ZU=mP7&e6!`Jn2+Bd z0NBlKGxxeaE{$&b4T^3)M4M0fKjx~D`obeN1Lm>hPVDVbeCjPdd7<8f$LB_Wn<@9Y zZq1{0Ys9$WJ~ciiTRrDKR?j3hE>D`AhI~DIn3|iwsa|CEnbwcDiMJ!p$@fj$em7s- zDJl`^pD2j{235 zVx{gPOl4l@C_qMI4Ca$e#TjMriGPThWc&5q7v{F<>d(1*W}FTyj}HQ^AM1VzQRX>J zE;W{gNDtY^`RGkbFB=!FZ=Z#qF45?t>#7bC=C*;GpJR+21ke41mq^xfeEaDewOz_% ztd@)#6WKdB@^IN89=;MWpAKNy)w&CAIg%p~FIDy8ab>}n3FQ56AO7~8r0Eh>PS8JSrj zl}gJ0sdRMuPffNV^K#>ur8#68O*`W0p{Xi1?xk4ihXc&`aie4cl>J;h>HIu=Ie_8F`x1W zM^jaESIDeP%Hon>CN*-?8DUMG-JWd*Zv{G&PK0Wt;0KT5y${V%!x%dJfE<_?ywR$wk>E^def)^@Ju zA0WT&APyEcH+3{K2fvQ{7Z(W9QLd@uNkmQPp=S?ReyeVvh>t)77$S3+cdCtM={gZ8 z2*g;Ah}t;jPu#cS{z@K}oZc)PyGBmU-?JZKk$134r!SvR?<@`XcAp$Qj!g7F=f(xR zxZRwdrnc2TRuctt>gSvYJ>FmY9&wGmdG^(=us@?sW!&{$cwP|_To-sz)tSD$J^k_7 z?ZH%TB(=S`ai^94l(gwZW-R_e)XZ?W?oVyyk%iYsQgfe`p*F{}On&|{TOFp8=NKge zzx%!2t}zoT8*M{hjCSp?K8Nl}yH}faimam%FEvs-b{@=Raf(F>74` z&wUXJPv_S+dzocb%Z(eIz86~qeQere5I%y`u>JmWfa2xmV59T)kTjmD>+$$!+t5Ul zl(laPrCx&_YMs{9*s}OJduqdP_qPJ+bPLaa&Nc!(ubvtM{ihzdy57a3b~xrDtx^f4}vOpQ6L(TO=(+&Wj!P|TCqAUKpa4G!8%c466 zl)p1A_opZ(yGoqK4@Nc`Bd=|{6GTOWxsIG^!G-UF;)Lm_H#u(76IB1aPQ<5m>0Ay@ zDaa9qTu3Mzsalhsr@0piEH7rC~u3i^Xay+^94^&<_ zgiqmzDxvYTXT^M5Mxz`JKP=j3OP)8k1(jj~XslLxK0WG9FcBi@N`<0bF(+G);Vr@o zoH#xCiVlwS4ix88p2$e~K>!`lcnTR19H<;m03BR84v{BR0RF8Lv~rynpa@SHFf5e_ z?6HBUm}6vVtT19Bdc^f0O-FsqAoFODn9w-W@?)BAAQU#3Bn%_8aOqVYcD~qturww_ zVT|fTFEt&2tSpJ}2y{YEFu!>wymuWUfj#g^T2)4>D7XDvi+{yMP#8woBBfX5s)4+}b>SjR$?ZVNs|6nI_J zxIG9h{LTwN^+p(gWz3uo_3K1LJrAF!`ioa+lgy2SY(D8m80S(Or(+4$^2K>Y)^oc) zyTgST!c(NO?T|fkV6*#43V$F7ln1#Wwo;!D;wR8=Z@pVE)aULJ`pEluLO@GyrRJpDQF3@Yt9Hg?AW`SxO z&T&R7OnY_J!xbVQqY6f?x>DW_ywgwJw{{+|BATx_GB)gTf=!a`eWsRz*zX)o+cI$O z_|>Dm-RRP>q4WP3Acz7DKALF(+gLg$P$%%SHa8Gi^gXKd6z6n2_s3u8?iWwX2_}H) zLUU@YjVfdaPQmrWPc(2D5S(0s%2yM@=-Kk;GxZ@Wpbd?l#`_-)JkSmJtKnom>et?= zMn6Sj?2!WKE6W(VA=4!FU(nECyq9}LHg_W!o+tpeXJJq*>IqJiP=WuE$^+sDOterz z=z7jqk2u8=8|7NeOb75X5!ktBF*nZ=R(=7JCS?_#xCXUDe?OC`vN| z@5?h=zk+1*ZM-l6yn-W1@O$w^&0L;mq=1{X-h_72j%nFo0rX|}x;A!*0l*673?Bh> z1Fw-D`b`hL)*J#)Otj+O=~L;Xg&z(qsS?VZ?Tvd%va+wD~@U zUOD6A9(G~~C(`J9B)5Fi&by@Vccehve^SH)=;t2jyaIp#^vy*!I1@-rngCh5mrCH^ z&ENgSFtk0a)ejO#1n1>!e%6(v&eynjRm@L3+G!{Ybo4j=`@fc?Z?1Gel#~Y2Z|hvs z?mzdrr6|%-Zc?gzRur!N1@V7(=WQ?iS6X;4j#tRwgP?jWM4i``A))uw-~>zm3FP+o z0T}!v^zgnxH5wipbXu4=sW;>f!PG`jFTNF8EA{J87)Y!Npid8Q{CG9$ArD`QWLx># z16>#(3;HY^YWU9L6>Zb5z7>4%MH#Pnfq}B6WyP%5e6?6YSnzToDDCST()GJ{ebmRTenM~9>vHS8b4rIe9TucES7z*uh~vBQ}wK#Wg$OqiDyRF9FzHIWC& z<2joPONI@v=t&USNTt-y<;tMjUS1|i_d zjsRx4D`SU)K?S;c3Q6gGJwK=mHTCr1BuPIa>(dfgh%z=H7*4hilPzwWkvXQIHK) zzU$xRthdnE;nbsPlo8-TP81&jR|{ha5X3!>l3AhYKoa>5yp?Zeppg=2#la1?gbaeY z8HSr0^i9Grv8WT6Yu1MW+(C#OFhLF9k`w&$B6i^SbrZkPvtp`!f89@DfwE&YF>_6J zV$o1O2wGYwU3cO3()qd9talG5bidE>_N9`z0r;aXD~ztG17u!60z-D2PtcQK%8km` z*hL@;l$UPS?s<9f?H9ImNjyDCF%gCdv`mmuw*Tw5nu3|~eRV}qdq~PL0e@zm)Hak-wZ5+`#@gz^j!sjINRd6b{H>`7CsBx-K8z@s28hIHCmJy|a)SWn^y7m#XzY%ekQksg7g z7}TL6I~a>Q7$3+JQf^_);8n0%L7aE+lvMsu=5&}Q9=dhZLP0zIOkg=DE)Ua-hh&`F zr)2Zv+!lsRjyw2582=Y7(NjkI`5g=_^sfx(4?`F!Z4KJVsew>t9(Ln&wCq|j)~t7H zBSMj>q0G_xz|6u}ZK?aHz#938M#;DdXo0OsEusXn3%Lpg z0l&ZZhWT7mhjvDw@>%W>F|}XGx18Et-tX-w{T!>IEBQbQvPD*)#tj_#lAm@_Hv}|G zX#sHFK@~#z-|UcKidw2?%KHPe$qazxma34VusEQ!kl#df%g!cwgep`Vj6JZFl)ziI zY<7t$Eg7YU!TQe#YqI>flp%TLX&BmEl%?GIgs)3Nh4i{m#VT>)R+(x`oE+- zZo`1%O>w)ag}`J02^AUYuWw)N4o`=!49nBymxk6S?r~|Q;4i8OiZdAom8(WTxD z%cjhNd3mgWwYWp0Oho%RJfRzM)C6RDU^v?zZh~wYc+G7*Ll1aT{`-354g$CQwo2{f zTw$9nNMkx$%R|O1sHpv+wM8#s6MPqP1^FPuMi+%XeuBUQ(r*(tfyzw#^cAsICq?*~ zSBS$HY6&fWC82RZn$1%6-m3)6@4QLKy7ZJuu-=07q)Ev7j*o>Yirog{Ow z$q5rlG6pIb0Axgd@=&(XRAQ8m?8W`mtYhk=AvWZE=l25j^6Wz;@vah>*t3MG+VS(^e`>Am(%2#(*B zp!JkMbgh-EE_MfPrcTo~IJyxdHr-7ImWh14C=|(2aR~23tIt_0Vlfn0<^u(6?@c|7T!l|H$nV2@VSo1qm?Z?k;H+v0i7;L6p+rcGz^7VyWM76j6>AT)?Du2^XL~PhTITd5E@9Uuu zoO0$(-)U#wIl-wj`(<)K+4OkRJ@u;PXo!bJLi;f2(u4^K&z#ZPB>gD=Ds>C{Z2G9C>Q7w`lPb1p4bAtqo5Vzy{?d;YJT&+t>5J(+hZ~!e z`dw=hJ-^%t?UdUza+Qag0|Ld*IGe7MrGs_9=G#Fx9mGTsY?}z)KYR*(>h)!>WPrR3 zDJrz|R&2*LWK)C)vDtV=WXD_IUFn?!pe%2$^>S8Oa4sRXIh=$~x{hhvB+-zex}#Ye zjw6uFm;r-RrtrxXN+_L2-8~>Yqr(Z$89j0S zXB=8jG3!n6c1|-a7#;?$^CkF=?_t}RSCm}w?Ff5gaM@RNHCj|mvELG2`QEUhN{N9l z+OmqjX7ni*zh3w%#%@ZNU5Ate;R|aIo*Bn}BsCze38o^0qx4XCtI#Xsnx+m#cxxc> zdoP*(b40?9D>n{>p#lGXEw^>(u~{gTf@ZpABL$6KAR+IuA<9`7%9eX4oB8vVZ<&u8 z$D@CjzU0kEUam56VM2lVNq3n?JSW+gjj=u)_w)75X(PytYR%fS7%15Y954(avp9B$xQ`rs@w{jBoatC-y{L_ z3;WqEDk(d87QjSrN`5|tf4MEx#gvrSwoh)L7w0*$;y$W<9vpD#>aY+g7via>AVV@4 z83;<1JO4nThazYZ`a@unSqtT`HT&qSg^|B0db&R)GaT$<=l|?XSTu>~D5&5OjHge~ z{$4@7&gOKg+&Q`DTaABc&U^lYHPlH}dd3Ec5bRtHv2|(xZ!o919)E^VbNxdg7r|Zi zTN)S^_@XHB?&h#fAOA>wUKR29k{~p{OTU*z$t4=&I@ROZ-RHe?(#EN$x03RrTSkq^ z=+eOVC7Te*t9!Fuj7gSR_Is;4g_VRfSH|F#*cYX=GKrP)y?ri= z(bKG`Z3E720}+>Bz794kKaIn_u}>;0FE0icf3^#6aZDd+hEn{~h(^c$@h8C#O-@`L z`aue6>rjoB()1=w93z5zx~e1&&?CvbMxAXBUho`3*>?ujvkB-cvm}geY+FcE5*wSm;qPoauD;?ss==3G%5E9zdQyKy zK8CIy|G5P+*ELjZL|k#p?>#9UtZB=#z2Kjh|0wLJuPCCKJoX$Muux8To^=XlDO&n|pO|=Im+t*bo?UH<6_Sh@+j|gh^B4Rma%JvMyGcwKbP+Zig^>Q9j_(iJCn5KoW z(11)0*Vvlk^fREdD@=rdX5o}Mu5dY`xmku}FrO{9?+G9HiJ`^Y&dnm< z?QenyE`fd4056>18QuDROP#4QaC^AoR<@u)L@wRcDTXKHh&iXX!Y3vO`AugaP|sL-z@8`|1NJymt>*o1`!$(B7Ur}Na0>& zslB>cS{-EO^4k;B6+!RC{c2?xu;=gI^$nF&aLw^TvW$G>@{X?fJC1dn2?;;9jH5pkz}U+^||L-xFSQis}&atog{h-i1jIEkn0Cf8ud5 zd8VeimMm!h7#vrO$l}g$|Ar9XGlN3|rggYN7rdHPdUwY*F5Bt)7p?|)#0A0eO@Ra+ zpG#`@Qq~~yI0+m@D(l_CW32|_^Osmn1(y|0w2nQ^&EX%?NL`e&QYFrruEh$x7nBjV zqACgfEE1(4Yh59>2!jXRdv_?bJo7dI2~4?elbe%=Nd+~fdulidoq{W;#NevWk~qd6 zr`4c`-D2Lx8|ku%o%eFeF2T)-(#&=T^Rb;ei+g72P&wHYN{a=GrnSGb?zsTjH-sk= zcY~%FYl`HqXgh0^unP9ZV`{8!_YT@#T|)fL=@(rCVED)uj3O4P*783)7uM z-DeudVxQJ=s(L4|=H&7)-yc-oTGz|P>*R5Q+yEtkJ(xME zRH8PN081f8|DfGo%g3@t4feLxCbO%<#36+5E4;q~w#=P7+t<2V+wPk8_#P7_R5A{; z^QK(Z<1q-%lei#KnyzN34HK9g)~`oe1$SSPo=#618QeP%P@igk(O@8=eej7QD&nTH z5)i%sSG810rOQ>Mle~2y^e$F1Cq-FP3sEDJexm4wNypDn#e&Ct^ECLe79BsWr$+@Q zi&@wu>8eNa8nwPav(H~RYX9cm1ad17^Y6|8RDVK%FQwwz*R&78iLFt|eM5>J)Q=*mY&pO?X$xK z7P#Z&iW~L%5lPr3Sp2tQaJ-$+&F!C&b7KGBl@4QkRF$MYOJAcge*B?;Dd49?m8eVQwe^;=uq|ox zUu;KS*EjST$B;@}frkB|;{N1;QKQ8!BAzg-@??Q43yrzc=}z%&>qdlb$?gbA5j};w`=Jb=P2 zjc`E1au15~vv~Hd$lb?bK&_(t{t!m`D>s%8%RHm43hOG~112}`@ER(x-mf>rqDto{ zx10;b+hv+qSSUgY63Q%``}`;%sq0yLQ{j*5qUCCZ2e=+KP!v9A`{(A+3U>-^O&Vrb zoS>_Bai;q3+xx9tSur&?8R-1OiI8S568+(iQ$UPQhIm!;3`*zxaz7tHghq2t1#tNW z!`yQ3RIlN$kT(QLq|@OiPzRbyg`7kJiQakN$Q$Ru_C=bZDfYo`xr1x!N)ipxbgm@0 z*olO@tcw!z#wZu%jd{r#?*E_&1I@doSLJV9rW-D$~{DHCuyxzBa75T1=cH^2ceY?m%ijlcI`@@od3 z3|LqfvvKKn>3E0Fp09I$8vJu#d`O1}+P22yOrkBtm%|n> zI9CzUrc{)tB4!{#n#M1W(C6_Gxx(Tj^JZ!kh3T|}jP|(Mx3azbKQzhnsdx?M3-E<0 zqOlRq%{Isyis(__6_1MxN`=*wsKog+pmXWU;?LjHYq2#0nr~6LxN>1k<9oBP*i$1a zGpIxD${BvdHgUVf`hO5^g2G3f6+bPc%eyZDn%;;~cS41yWm##vwAAj*&NsZ}kRnkT zKyr9AdrvCpk#ybb7j^1w;+y@ZKFK4+ujbu75GIRT?wW{2)Z|)0f?nMUG<<9KXYtoT%r*@%(mmnPf%Uq z#!P!N-?xwB6jh*7TK9hxyN(8GAimWkR3}sId0;~y-<{SbsdImu-lcJag*0MoTb?9B zYh&{RKYGVw>r%!*HL1upnuJ7(HQN+E7mQZiqB4)pbt*ai#VIf|cN{lS#tKH;fXJ=% z`r)dW_KXpv4jA|IDL|1YiVP98j$3u_-+~9wy;@1UVfBq%#Uv2QOJ^zR2h0w#yoc~XWUScWq zu$vn?ZyvG!`okAXx_%?G1m?>?TofiaGCHKj*f4kj^fQ@-kmI5o3_gGU8SuUi4Nqd=~w)gaVq|yB>WnR&G|XK8&sO-R{n`U47ZGBR#lTn{)Ri zKM^RrQr!*+cyRT)_UXDiIe02^IK5SEO1a+mT`^h88C>`%zm$5sTMxMTy?X)vNYekNb+5W;{aP!Iubl3T@uyc@Zby8khwBE@^K;)> z&c;w@YFk&()h)YV3RhEvsob^yBXN9yU5v*Yx`(y9+JXIRci+SO*bd)-JH%9qd8cDT zZlV2<4L`W6kd4P*i+^&NP%mgDdhAIIlQB=8bk`l4o-S@r#dI+i=1 ze%QY>^WQqzX<6&;zgcZjIU;;V%B74F;VWSEKs(n=t$a~K5TYZy+{(VWOl`p^)TsZC z=EUOe%+Gr(Dut2AWL+_H3Y$n1EW{+xK zl1e)iCrbQnORQao*7uRoJL;=_1&u9iuc`C*I&MsrX&u%1x1h=zIdKCyUMj>udwFLK z51@%Y!)S)MQF=tx`%jT*3rV#WWYv%}Q(4j1E2zxJMY}b5Hpt_wQd_}Vb!bi!r!!`l zQ)=Rn1+?@E#Idkd=PAjvr)bqNYGHQ_b>sERXMVZ(@vd_+1hU5j>VB0W4<4np#R2ju zugH&zdwx=xrvyqMH8+CMe;frTS&(f;g&)~@8avu6ys^cBdRTtpy+l^6Tz_%&?UqCQ%eM z`^Z4v*icZ84|i<7^NSCjtg0f8Lne?A(+;}~BDNBwlijDs;|*b=A^yKZ>^{|s*Vk*L za3DgdQZA2=Mjp<)4`qY}(tSvYEPoF%=aKow~EEihI+ zN!)YSVIB#@Syz9@nguEm9nAoD!{HZy{TaUbus$D~lOYmFbI5O{C_JtYCCvtqmcl%e zi?k829`v>ol>;Wsd*)<71?K8xo?XdA+VU$YV8B7K{RX4=;J%`x8@b~KV;Oiw3%8^lGK{m(;;>`&A4p-IGdz9Tx-p@Ok9tq`k=4b8l+6WCI z$P_geSN&-=F1$%+@;S8h)f<6yRyGKq&|507U$KP6&ZUoTo!zdeKt74@)Q$4`s6zE> zM8gXa7mRtj&s4So@}H7H&4q}v8DYXaA2K7r` znE1+SqS|!;D-Lx)t!~*!225ayl@%|%%0Mzl3_xz`JC*=NN>vFZ6#ITRGCPYtlp>@7 z5lW0*@HcegO^&8qjRl!eBqO|n04xN1bH~FPv9YxDIps1Sn?<8<22|u_p0yTWShDG( zTUlv;Kff9abRZh7gM2KUH&e*EEKnTK3i8B;K%<}8tS|?gjUvlCs*W0+z1;$Q_>TOf zqLPUT()QK1FrN-bQtcHr;xOcL;wtD6OXL;KWPC#ZR!(KEKrsj{o{>=*D53{dC<9Pb zjYCr>Z~q%KjRlf3X`8RX26wKG5!rlG{TFYBR5lvf=nWN5aU4P2@T4VuX(5zY*edf# zz_&qlwQ@+q^!erZfzA&qmGN#B)V71(c+rDJn9L|JkeEac#JAFt&4DrqOXh$-2X`Z} zzhfak)`vVHLUBztrvNE*^yEe$h$YOREdNP8pz{$nWFc2BG1c;u+&pD4Cx%6D*&b}7 z8Y?8`oK$ZxSPaA%g4q$Fgz^mIuBOFr%RPeGp@TjYsH~x7$x_?m81su1}DD41{QRs1r}89q6pU&RWzPxV69ti5qEQvnXl$Y)Fg(LG~8r;%awh7vvbBaYb5PZ(KJ8f@I zX~-&<5r+kOBm|3_x#5{Wpob3cN6$u9>RW4pKFDDX1^2obfIIqEQ8F_|6NYph95dEO zx%B&nBOgb(MhHF;(43$@%4vp*+;RY}6T^#$JpJ_hylilw!oMaZ*s8t;vW|RMiHli3 z^Kdj+ft((#TCD;DeZej#BdlA)=(-IuFcT6NMp2T*vaxt?cCkeuW~E`S&5CSn>a1^7 ztwXb7WoO;}9@$F$dzKO?wF1(e8g`XP;m9ws01r}|5u|@G7Cp38fOwxI@-6yyY!kV3 z9U3~^YqF^h|2_M*zgnU={~+3l-UI^KA4B*)B4U^nhwC%1S-#&1Cp+H7RP;&(9ikd` zC?&eYE+ovRIBiCtr|=Wi6}2(p+C?w0SfqtN*h*-#0nS0hGl*%!`%$Z}N7JZ_^mWO0jB9*Da(c=ZL zGy3#$Z8*;Y_o%OK?_PHd;_%|)Bz%?W6f#G;jXJ>Pz$-FGZB6hb6v4u&mZ5alSNlM#Lc$POMX zX2>f|faJSD#_9XPqdHky+j(z*UQ#61f;YseK(yHkUJ6k|LK0hGqA=dVVF;z?C*^r0 zQCO&sLtliF%aIHyJh`J6_^L*#rjHc&orWy&Mm93W05se#y7wvEsB|Ubx}Rz(D>5$)w-v%!P;LW349+Zt`*&vrq?p&A8S0{vX%Q_ltAvAuV|6lAyIhR zX4bl|vmOsndQRz-CkV7!3Ylkr6A2H1Pq;K4h6){{t}o^YOaX8Q1wnORGy;rf2mq{s zkjsG{Vk-9K8J<&u5}v#g2HWhGLg(3UXgXxsxQit5pr*|+bs#-eXp`6ixsg8u>|S+K zrh9tJ3V5J3fM|yt_(3>|2&%vw_qCq|>+T!nMlL{4En)>kar#drf^V_uIsbgi{bxL`hh)Lnn+WLi7WeBu0VR0MCMY z5XoSL``%KcnDz7vEt`K}`Ce{4kV~6jj5X~^Gsan8ys!?TDz^xj*c=tU90~p0TM5A` z@;sLS2Azov*H15xOt1doN&f@n(B=X@E-rok=vo}v_Wf(d%Dx(U7iZO*agyOP0f%S5TfVI7 zu+-1ozB`zr9-^RlO5OsYGJ~DcX}A1k#hr0w?5(d78#Z%CqH4QWlEIvp^~!(r*`KtV zwh(g?y}Y6SoX5FN|5U1C3`*^%&{^XU%Y+urIjUrccM3{&L*cs7p_yjL35p5?Y=(%YEX7jRtRtVb}6w(g5XPlF{p8&d%FyUu&6 zz-sQ~>!qdOTgPSF8PN=u^X%KsrgZV)Nbm(F|0V5k<#PqDj+;kp`AjLy2k`fAbN6e` z!aiO>$!hDI#E%&uZaTR%8IJ(cpb>A&|Ze(2Fsc~>k?ON(1VJ~{rm5;KNSx`QWQ9_-r z3biUmXh+V7t&Tp+voCXYN1x!5cpTx|sxKWhO`|&*{)C&|BCJl1MCfqhvn3DknDhEp zdZ~#Q633B{=|xz$3LAu^u&sKyN~A6Ub=tkuBp1_VdWK$5WNJ*lunj-0M9wGKg={WI zh11Z)45Z zIn{)J)e$xjORb@Ho%1C51KZC64pxia*r5Zp$iegsmI))wbyxMDlA*NpZv8*u^*O$w zu<0%i@MH$foFmOC9tOX2qs#pvfMR?x_n;<-%)Ga|fb7cjnf@xepg(Z$AXHtq3dIhe zlDa6N*g4L)PM`U$ovDJ$ydIIN{f7%!b?a;JmdXuRg{`x?z2UE2Y|%jVVAXwAHNO!G zUwP-7L7O=8)~-DV!cBW27a5iSfsg%+3miLjK`Jx(GI|-ES*IPEgv&lZr?+;5BT$Q( zEtsPwDrdKtx_)zO74zBHjekb~w}&3(e0NupU886j>GF0O?YC2^rT(+RVjP}uyY{F2a! zhbh+>faK=^ORuUH0LJP|2qRYp*Lj0kSHl{p;!3|z2ACDJmT!tw>SpsFPUK+)CYcLl z?}azH9$-caZi?Ly8<6yy0+!*;FpCBrm@FyTdU|txOTOtH6r{O-v1Cvh5-C#8w!P*` z9XB!?g%`)V9A1nf<@+eBHb+i_KDtU>YWHzLZDORRLQIVCID{e4XhO07L^J+(Fl#Hk z<_v{=l5@v9>$Hr*dV&HPH>%ds1CgOD5nuk=w|3&H&@;+Y(?-8^WjFMaWixt0f*GPG zgv2rf-(XliU)pVFnOhfzrt~nP^w9Hw|X)W_MPvx7UJb{dZvPG$0967TYf-Le?!v4jqyLE>~SInA#2 ztCZ9}%{!%+I+_w%} zHp&jc;8aPWR+jagB|wq+g_c}BS3k1>2Fq_U|H!&gdlJUte|dONk4I4NS!b%ZUKN+T zXy0Lg?o#LAmlY1(MZ`HZ5c);kcaI!QQLBK(ZpgdmQF4|4?&0CMbA&M@7VivPjXJTU zW^>pX*5d8pK!o+sTZ~lH~%i0kWPq9Jni4fJ1#lboUwK|ARvfawVg_1 zODQ*Ga!JWmI#q0|H!%E$zEGcOxUk0fW6Es}o2- z*s>I^`B=kkokpg{ZROz60Xry%_4@7W`e^-t@-FA})ZrOp<+EI`@A|dN-SV}abAdp@62y{n5rCii}lFH)^Pf4kV zhsA&%TAEBX94PuYBd2xzo2t5>&}kv`-f6g@t;?y+Rbu)a$9Z2oDSmO*lREt6_S2ey zQBitHQniU7mfzPk+O)R*2LJ4ei{oJV!xY;DVv4~1`+Y#$akHi-snKnkgpKTW5sM95 z&-TOP!KzK3d{#ehpFDx^Q>dLi&5f^b>_E2?#{I?eFaKF!j^i<#P@A5%Vuw%H78e~y zb5chPo`_4o)+DRo@58yn1FEd?Z9dQgO3z2lT85e>?sC+;#=KI} z{<4-`#4Af)o0uz8l`Y~2jYCC1E4)R=-Lk64~z zg3rxYfxSF+>L?W+4<55iw9&b?=79|Fo~nMxHDz>#t0o525eBqwObmmO+0NNorfwf@ za5r*1*0XscP+5tltSz}~TUt9FJP}JtVM`_G9xL-HZ&$v2=D+Iw^XKF<+vN2g z>d}S$dYT3SkvGdHtv4%DHhdqc4U%UQDRo_*FRyhB@A+430+b7;z#g-mFPv4dS^(?8 zM#x=k4jV=WhT_$L+hj+^B%coTye2%oqF`Wo(>Kf`TBl<#gd1ER+86YIC#Zl9XuZsb z<656n|Jynbrf-a@`c95((Q?Lbr=mi??HxO)B>{L6`DL)0w2S6dsuk-S=|M}|h(QL0 z^K=c>30UU}Q>g?wJaleJ4nWr)avz!AF`{so=2(o?8k(ay9R8H*VUp)MGc50_1r~*= z@o8w{hylj&$Nn_VcF_p8bXbxTb?+TR(48nKtgDkp|t#(Q6+r?GNpOSzp@YE$rIv z56Di&m0(5sGw?ppHE`LZLK8ErrS@(ai-GhdNc6D`W|O*BT{#~U*kE9fW>nc}bf00J?vE36Nx zkRGqC2xOS$DXvqp-br+zmc5JaY`8N0X4wObw=l(#l3PxYj#!F>?fG0FGGvAn{Uj-G zJWkznj33g8)lTjB&0@qn-qe^R#3--qes~)}L5<3T{w>D|n7B+9Hg!|cQG&29FS97a z94+1~SfWoy;E~CYlaQ1Bz2`}rqSNdaFe9J=r$ju^^_R)JN}<`UxS`-6Hzr+i+vB~vaEo5h#1oM$nEUf0Q51?We=FG*ji2JMS^TlJF2YJ!nGIdL(M#arQ`xXw9I zu()*^$il406<fs!UM*K5nTL+eH zWHPb35Ubu0Dn3*>Rfj<<(niW~-kPVhNlq;D4Uz!b8O>~)44##Y1{KCtB6a0y z0&PuTaz7k-n;PqJsla@*hR@!3^U>5}pFfS`+Jtjl%AGIPkW8R-Iv6E=u|beI0wzW4 zrU267_K@5^qXfUnzB=X!+scaWCGtkh#H0*s53gf#rwG2oz%^hY429nSFxoP|Y&VPO z-IRW~Qv03dL(Iv1{whzMO`0m)IF_JQ^?*1`o#37_V+7Ld(yXUg=L1?HQAm zDikj1S!MXOqoqZeBW-`lHZj^!`B7R-sr@Ec{FtiJpP%~wV(u+~;@Z-+Vcdc{1PJbs z;O_1k2ofBEyF&=>uEE{i-GjTkyIXMk8_t=znKS46@0mMys%{lf^zPlg_IlUrd#~qV z#$g{r`XU%F%!MulJW259PxR<8(TB@Xf12y7qv`<(`3u7)y|Wbd!xoec zY|jfgZ#(ABZFZ;2h?moZQ#8D5r$*J|wXhB9{Gt#Z{fU>H3H}WYOAOGGFb#~v!d$2q zCb)fMgjw;S%_N8Z%7ZSpeF7Ri(WXk%loK>4MOy-$hYS&hP_T1X8qw15wo$yN6^k#D z4;3!%VsYP~f~+xbAmhhRJlO~+ViN&bmcC?-{yzKFkTji`?~Vj@7gQgW#~iXK@d%LU z8j&hvmt~#1!ciav^jwx3V8vyDAh3L;g198OMUZ_?Q6COJWQVaj|cDV}Ok$~Y2Zq0Fz|qbZ?tCYn>DvCH(M=S3V} z^%^f)7GU6pT7KA%aO+6a!lp;=V$qWF@FGhnFq9$&iI7A46c)g1`i?X~hemRpA36pI#5&eJ73@2Rh?m+b(#ESdOU_vnSc_D0H)q*R~i5+wL?e+?^B?? z^wKg69cL8MmemN6Ymxiy0Vu3h6Y&UK5>{l~^0jO>aj^;Acy7#I+d^1Ri z9%Aj$(X-W&Hgw^R8&lkfNV?dP;gH7iETpHM2jK;DHuNaS>#ODz+oG${SuAPhMDOm4!j#Z za+;#h!TNDyK!!DEzlHk@evMZgA7$t;m08z3tQ;=bBq9bBVTx}w`zfQaOfo5+7#KY| z9GO{jckaVCo?=9(z~+X?ARSH^U;3&rd?1$d>pkbo94O8X!!c{;YHsJ8?JPmRe zIQP;Kh6GjRTjmWl_md9Z9tXmNJ4+dj`IzXg-Uu;%E=tiTNpPM`$_~0QioX#%J~y~3 zPjR)0SUNb`KRhVBpRqVD;YrqPQR8Y^%Qg`v`3z#RZ?hYt9XMGx`-JN z(EP(oVbt^*rm3v(kY+aGx{uuKS-mIU(($VUH|DH_FXYB!v)2Hk?6+rjS6LH7>ePtL zonyu*D`3nx?+%1R1SvIY5Q$l4*J?t(a#Q>Od~h2Y#~A$B(ELDTdK3Wpy!d!6aUvKE zYfZg3=gQp!&7g+&xg9HyQ{J$1WPAJ*C7jB&MQ#AQXK-#vbsFNYHh^}tLLgxI7eAI62- zA`l^^pz8nToM_RPUvPY%01X26of@_sk@LE&p`f7wFZbph%Q$byWUgY2fL|`zMU$24 zGN;j&Hz;vC?@)e~?p(R!pca$7^Z3pjatW{6L6iEPJXWWP3o}Aki8~^1h*5 za!MfwLcbuF{Ykx_CCS*DYbbcDErAfSD}9ucEbkaaaRw1zQf?YjGa^4_|Hg)5Ww2n0 z@P5b67L!1fX@yZtpTwJxTg4>oAfoVrWPX%`*^khXTkRr|t>nO8j;}Lwm4Yo8N;3m~ zCC42=!hHFd{Y`$LH(NB%tVEPDG=emuDBe{BWs_qr5G)xpV6h(hEPp$mk%~X5H;dYS zmAj-*L4u#pKaLIkfC8Ts$`e{S0v{z(R3Qq9TlkH|MAD8ZB9{=0T2*H#QYRIX0V8tZ zq@QS!UjZq?+#Os02=HAQIr!-L$B+ai!$Lh<@*=rWNHt6(ypd$DnlI$ z#z!>+M;eN+mZ5WCQq|)j(2(9~&KT%=NK7z=uKFh4_Rqt9__F!t&|6La5O24&|+~ieqH`$lmY`& zZII?_WEY9RXJ8byPQKVTpEOAXwH!3MeJtwNohq}HsGQh7+O#@e`mpOHM;?UK)bCXI z4Un6rvOCo{etb4)kx_ts!^^vL1ixSSZYpRf`Qr}9QuJbG?m34KCSg3&IP$VUkFM(b${U)8(2K(sORR@v$jXQkq;u=Y2 z5g+V5C5JgF&Ns7jhDXz>{nX#t==Og)85}jEF?#=AU&p0U%Q-97Pb_LCDaBcJJ3wt{ z(Ib{sq0lQYr}zmAwdSo`2v~epyr8msB&P+1VvE_xuK1z zAwGKys7 zfkP;LX7$oa2neGh^uH6DL?r}^<%kr(W(j0D9V7-{aLMbRDnsE9bbrJOxm`i*<<0Eo zBu0R9p3~+<%vz^7!D0E>Lmzwjvlm}rVxmuqW~Eug8LO0wlYtOrF4Y&7o>c37AYl}n zFC3O0^}N>)MRSss&J)^Vsqak!0?zSp+ik2q^`Ub2yF%C=!XP{;lcjMh<_P!qXj|uG z)eFlGJ&8vF6Aa~+@>--&MDg$+%z_m=uEQ&$#~T~D<8#@zVG~$j{CC(zzKe(6WLgcz z^y)gtOPY3nuf8}}>PUp5NRxnv#tW$D#qF9RD3@B33D3hdxr~p=As>;!2~;Gc;};-g z)nLS1KoRO*FQ+~bWzMTd;ZTfaP|ZV_*M(u^va(~u8t_k7&>PEyUS}+4{X#As-)bay z#0pZ63h$vC*u`E}(@jqEFzm_n4*;zAxF<$$3E2jbF3{WOj=M&a9r9636xrqxH=SJO89sI^kH@tM%s z6geQkL_iWiVyx!^d(qoXDHP4EW6U~PJ#&hKQD%6=zJ`L}gZGYRxyI5k5k{1?hbZO- zcvd5d08FYQAp)Hd-9$t<$6S&Yk?}obHSQQi*gTtQYvRpeMrSSln}7lI{qg5 z#il3c@&}{(<~$y=r}GJ8yGL_IO|Btj45RTox~STOKJy>57aH@lzDV5?0!?<3o`eV$ z^mpB2KS2Zw3GjjO;RzM{|BAruoaH>m_)|mrgl{b; zE0@`H^18F``BB4>fs+y{G2PsgO*@-I^$=!qIZDJN#BLrvL6D-T8s$f3kKS3iW#ER! ze5GhOCGQg!gHRi8z0Xg-Q3w*uW*tVE&f)@=&`=G3X=TW*XeuMmH1XsrM?zkmpa}m_ zC}`h-07@rsFuu|A3`hS$wVxP~Vq?n0T7uy;I^f>;b=*?n9mKkuBh-06V(+u=a892^ z+E^6F@n~R&nrfKLgog$*&_O^FKDhW4&%>g_55Sdwk|rwV^cUgfyt6PZjU`)kcX#me zyTWGVLVulfa+(+q@`oy#5Y(!Zc0nO$GC@87gBW_FT*jk@1?x{*H7#NyhBo)AwYTV~ zLZla~roPr)=!a}6oM82~!FoT(zW?az0CKG)_S7e!a~~3Dq;rqtb%qxi4I+VWp7xf6 z*X>l)nI%uOvG%XugQC!SD{3EJD*ts14Va^37&-TlC&-mwp`g~rGT99wT@mbKpJ-?V z64+!HG{}?o#B78LaSz;qO?2w}{=}~Lv!Eyj4sHF8Lf?`a0&&nwC*_`mR|dj?7Ajlf z)-{d5(t5B6O#(PRE3MGzWivKJVhxO7A_+>^`EHSs!=Qj~^vl|cuH+myVtbijUgG+SW3O#p@Cn@i@OKC(2_#^G@%Ls^Wc1Yw)V5K;j?zf z)>fz3XKrqH!PXU}palsQItPP~Jtd8D7*NvcN0YH|>feB?{Yo0!u9rhvQ}#$5mc)>( zo~_ZoR}=!C-6GogIAPm*5*o)Nne;pp@QrHV0=&db#%rvyVbSh>LaREz5P9cGrwTl8 z0sHW{D-mHwX1{`mx3e=MIxq2v%&z6YO%09RG4uGErF~!~OC-nsqz%)Yap?`R3`9D8l92Iq93jAJ3XXnCTvEiI8JY zVau6URfmK2wFk?Ztc=Y9KMmh4udFhGe?uj69&9YQ-U!5PTs#`Fi&L$%pAWkO;rm!` z_0dB~rl8*wAKWZk%MH`QX0qJ#ny((ysCZyP$7rkH;@RS=P){Uu!+-gnYJWQ(bfEsd zh@!Hwy`t>AH3tLo~R6+axOb z9AkIc_H|;g#1&4zUy36mc8F8q7odjxEE*jKk|S)OR4gYERjM+75C;iN>q9_S{Uk=X zrD079lTa$Al`Zc3!^T!?gc1W9-4%&dC^4=;H$+qHLvf*;)J{>3_s5ijhv&Qtxna66 zXh?sBp6}~)-BFkf2jDkUl#oR_`Nri%s`IYbc=+4LTVFRHdu-4gV7*a+_o!uOVkzxe z_yj;O->Nd^z1iq&BqjHb!k8QxX9ibcWE+O|!USal^=oOP9pjFP2&q8ywnpQt&z&oW zKtwd~7ntD0p&r!|j!4*4R5VohFdHHTnO7l}rVB+kRsh7rpH`sj8mEX0q=_QSGNF^r zN&L}I$H@y_ObW7|8G3J1B~uJ`q?wmpYMqdU&X&4HHIF^wk+E;o%8|TgS<#AHir&_B zU8SGhSHma{HrZV%1Y_wwGy*7<6l=q-1B zbH*tHrop>WZo+W=nj1lm1f)R2vHZAoY$40?WPW>8#N@$)CWl3WJ)s@Gi!%*pFdZ_N zV5J$yWQtB=DcD|ND6Et|er2GC#yL9{oTaOXIMmCoC6kGz(i5OTj208QE2I>l^po(w z@xAldn%V4~oA`Tsv1jAZ1_su#pwINSc^t(^&9fu|ehmsnuLnkxY4v`8M=hovqfu{H z)}esBRWM5ZMA+|EjB#I;fpVV;yNU&SoQ;~>?D{T(&)le=dkigy$T>>O+I!ZL2hAU3TgdlWV(W8^`v1YpzB@?$_dlwcq?)Dw$!gtvwW4jC8C# z%26{5TFV?=kmgfElCIujh)TWeSr|iw(*_PN-f_re%50-;_k)Z~XQ(4f)eUvsj*%UC zBf=o=(3k&%MPrt=W#x2kn1u2c6WIVoew6@=*5iDFQRm!>Ex78FC3|pFVSAn78Oty$ zEk+D$@&2uPw%SK$)Dc3UEkvXNUJCmTd#KgmPuA#;_Dg9l1w9g_NFzx8x%uNjtf?w9 z&Gth?Qn=B?(*Y%Bx6$@jbhdqBqNhs90%(JW9w_ACKzvCNUn(9Y_4APhhXY$-N5d+P z6S7p%*rS4x+@Se`$}T^htI}HYoOv&{18Giu{kHYhJ*Nf;Y<{qvs^xK}`@V zA5Rm@IO2^kaWtAa=|KFX*N#B!P~QCja-U!dS9k|i=X4puh4J&D=7AB3YI|KxJAxY) z`h%Wm{`Lehc6j)3Yz8QWaN%ue-?p0utI}q<95G45u>I^R1RYfBx};p3K%7=l#8=*k z2PG+4ClkG?X_otq{Y(j}pAScq8JwiV>#!9*0{R{@yL4EB=N?f+debS9aWZ>vDWiEK zFxk+P`V0o&9%^ttc6=s8-+-^3r{mIq5HnIrix8Md;_EjP+AEJG);8FbTm{p-E9j9D zD)i7YrG(-H=^XAe0qLHfUYR(A9*5+GXvkm*jZfa&jyS7NMiU3x;f}1YtdCN4i>+nO zurV6$9iX6G2h)q`1#S5bVX#){x~QB%(B|SzY>Vqk{jSY~YzHI}*nNz)pA?$!_Sp5!lCGZUu2lgOxW#54L{jOHT9RvWyx zvT!NBZy3eCIKX?&-4sR+U#t6n|LS}L9{jP&$Ys%antPV@PfvS0u?-IRZ;l+i-zDv>yGx-j@FGqAGwUsX){bOJlba%{IU_wp_V2r zj^GrIHTeyU%i6hb&QBEyLc`2Hk_K*vhD^$4-}AHYX4nRa!evr>wrWx4>z`wr7@;&8 z;IX0#VVUR!;5^ey1k8$m*Tjqk-zZmlRZ6P{b?K_)P^9CEygFmuH!@|J1ers<)iG( zqB@@Qg-4Z%GNuilihe0}k+ha0VJe+SU#J>P9I>xNuUh_Ep9jGgjpl}1v{P@YrmxF8 znawD%ULYKbiFOm`{ooW6ZoxR4FqCmVrHh zb>v7pImFL}*W&V3)G@?ZJgV=zMc`ntM|`RV4-V>c4&91d{ry>IqQk`5<4NjqNaDrP z`S#PhQcYY9%wUCqEGmzqmZvw2nr=6MqUGU&$6}?`CCROBChO_x+TmFTT5XRrv18VE zO6FwQt)&NH?|3Npxm=T`*$I{J^jNc8M6ILH>F4lFDR>~J!5AY3E#hQb*>1l^%q!;ty2+d#W8hUPFt}2*byT{ z0QA(mf^}F^(#Vc(us9N2E98ye5nJ0xKHFvxbx~sgqhn%-RMoX4(hbUl$DhP^O5Rxf zqx#zXl%-gtH!{&zB5Q__hi2PXIJO@NL&>z59H!IU#ISsGF^GgmH;E5%c5S!J0KHq# z6p4$i)FOR}#o=xB^IeJk!=2ca7puI!neB04-Bwz!d1Bybq=a=t*7nDrYID(nQAh}$ zhj=;o@>XTL<_cNS0f4L1V7kj8Q2q=AizqBq=+d;TiY>9xymqO zTd@sIr8-O@q1!7IT*c+`TAx#PQ_dj~)`!a=_g{?BCL^(%| z1yc>}9;6G`98}?2C-$LPt5e#t?AIL(;940>Zc62nzT34YtDr2#Gqsad7SvYmJ98A$ z)=e0Dauk!^FoAX4ZIBYgPwVp)3ik0scHrjuN0$XjZQUw=ebWLly0ugGU`+(94+ZSw z=w)phyXPtXU}#2#({0TOIUSu2-u+zgHbQ4$fsqr}*Y{b|g^f`-0;c%fib(~DNl>qI z$!7z^4t(Kk*sY9RbIQxFxE2y$Bj_HH7CqkQuUpXinfRrl#RjMX2LE!7(eZ$I*s zv2CnTWTLIQje?cwt#@a&$3V)5JU{ysg&hCdu$6DuUI?HWGE6N~mc~DO@VKmubvTad zQal87jGff!E3e~5dS(wv^(9ao^Cn3Vu;kS42 z+G%{X*)4;2sH2V44MO?OZu;-kCz=mE*I7x1yU-?t#=toGu@ETWmGtYSg9kwT1&!aK z2TM6E_E#}gr&U?zjXlG@+1Yol`T+4R=)S}l-1$0KnybWJL?ro5I%`L{L`@VhMv@N- zf!cd?ahezecY|<~n5b;nH}+yBv4-PheBfad^5_0j6?xgEmp5=|^!L-D+k?C1pWF!U zqoTg@6~apRY`~#irF=^xg&#PXC%ClW1bM5Zwb~s_r@Z%VZr~P#`bMQ1s%9&jD?+Di zJzP;Ll$gRetYaduwrm5}C3SSBHVto1^BEVY@!f^HlAfFYCoL|nR|G@O}Q6ckJ zkmi@q(tlulIr2Mf^Phg(?_kdifc?pUZO{KL*fY+Uf(y zLX8>VM=gKo-4w%8{6!T5N8`$ql<>nEOY2QvSe5^Y>jstP%^(@~xyN)bIOyRQ0A5C?xqW%1;}7_n%8+7HZHC0zUWn<+(CQ*>rovAu)H>h;D&6w2 zW#5IU^?)zpd(^i-B&rNjW7B!bx@ zrX!y}ogmUMG?h)g+XPAJ z;wdEcu_w^jyy6FSm~FlfaBf$+`%vr9Nqp+3k9FyQQK|@>D$=Go=+)(VJKIajT#Z#};hjo^iGlGZoz}AP2Rv=Iya!;kvf7ToTdcogS2e3-Nx*Z0u33zc;v<$5D0K9*|!CwFeUa<}S?udU! zK6v$dFU$Y}7N!=~3YOZs02%>7eS0HaeE}&I3BVhFyHNbs>wkgd7qGCf{%xG!9pdX1 zIRbF|^#Fsvy6e|Je;EE3!2Q2}>Hn(JWn%uL(`9;f!+*u;0tg2FlI3)QqM`wKwcAo( z+-zcDtl7d1X$vtSDll!V?Nq;&axlIAc93H_5fbj5p;77z>xeS-!7c(Xxsc$$lI=;e7`)aK9ef>)11ye=G@21Ogsvjoir^`z&i!4Cj z&i8gRm*)?en!iz-@1L$IFFrE0faI9(8@4YmTskyIaG4)izA7($JUjt{WbbWSQYEBgyJ z#Z31XO$rju{R4oi{^^-#_Iv1DTPxUnmL}{8M(4)S*52Cj_Wt_e=B}2-7ZY7GeIspi z1LN~IAAlGRFf;!|0e%Hl`J3bV-}EtbuU_>Z+%EuX=da0wfu8v<2?Vv%&%PZ9h6}Y#2%{xe6_-)wZoww{=w4UFFwJ)i-SwH}w=(9Y3ua zhVPW6epwi?8XYL#Gf;7;C}PLDa-gSPFuGDTLLWl4*(i$8t4+~UmH0pxT4*KgoTN?C z-8TDPWG^PeHVBEm+nzv@>RnF!o3RhmmDtt6!c4e=EK2gg{e3{$-l-Yoh}RKex4lBm zdLi-t;_O9{FixVzc*qHfj-yi4X^59pf)BJE+!zFV8RNA93M+Z$VXQ+-aqrSFWJz#w`=ht z!eW90N6GOrV$lT&Q)fW;nRXZ>m5UKp=yjVjZIr3V>b;Rx>Clgp#Z_7iL<`gDJg8c; z>AU%eB~^`Lxd82qJ~Dc(=Wr$^r>S3hPalk$BJlZGcl3ge<*&L>KW2VlARt*6;Yi&6 z-hOy}13i~3aebHPXXs>X%!2v5av14pyHZ2^B?dWApovO^Np)nlhj9e z*4=PuKU}NHEQ%f+hYqm`X||)_%HepcWpIqo)^ljepKX@lY_^wd2h1E6?M6KB@f>#} zgu=MaCK*PWPsgc1OPkN8IZnQwj*+E)J)4TOh%NqfxrD&;c)sxN+atpRK>YZu7T14b zmcNu!|8m6s4PuM#H!v}}-w?j&e#?|!gXgbd{2wd#UqU*77>k*O5s*aF0_dGs0TG#& zjs69o>>tDIEB@ENlRN*Gy8j{6zohQ}9OnNdccyB+ITw?^B z`4@BNND^Q~-u9WN5VoQD*G7en=|W98;J>_J(QmB=U^h&0G*CZH#KLF9Ye;8J1pH@| zYKSIHWWLYv*%L1w2zt+`*aMJx#G@Ca?8)Yj_<|P{t_Y`(q>>gyu1J=TL_8NX;qk|C zMI#wR;YsJP_yZXf;fbcOq!SqULy4ELgnSuPLkT9ZBx1RwL&+9Wctg45qzPwIBvZJA zq)Ap%ggv-E52uZ$h(%b$CP|fBz>~B99wf@AZkkN0$RI+QiB3sfou_OVZ}f ztMY|Z%a>$Kt4bwT3zuXstBQD4YnZ2v&5K6Wiva(D3>|j3AA!A?B;XwH|f?cc`LFhXO7uZXM__+R;Qn|S>q<2vK@Ln@|lYl z!deDly#!+O!l)s$&P4Z>k&O0uD{f@bln4@|7^eXzZ7-hJUqy{a2H1x!vy}Sewt! zNJ5E>zMDY=PG6gvIk^^>)ITRBHI;(~TBvhY< z>0>LryQp;t-h3b7+@|-N8_WoZAJk%>_}-67$`BABsl~a0Ie;n55Eudb1yca4Lkof~ z9QbGMyRUl!7S3Z)c(%E3KkxB>VIPZtugb+WGrFK?1JWumJ^mAG|4)}!|5o1|0JHhm z!jPX591tK`A|?#zjV-F^ckHEhY3)tvbN1IOJ;b7*;_xmCj%==A*w0*a8HNJ~z2tA_ z{rVQuK%mo1PnXD4M}f%9AbKdI#)l@PJf=9LI>gNEiwno>n6y3fFm3n3l(~JaAD7gJ zF^#L5u&+m7BKxi!+(B{m+FrUW6!126L^yloB8kQcx;O`{Jsj-;($*CUN&Aes9Gz)< z!?v+l!}g&z$vdtXb)!PG_5l)~4RQvCtbM3HZyC>ES{EOvThzQ=Gz?7~w5wEG+-I(B z>`Xqku60>7N%>p9S3(wB(mk z>tBuuzhSPvx)ynSfIEC40ewx8evJ@+OXmI|Qv6pU_ooTmFL^%THqCFaum3{xlm55# z@_(Gb{gUVYMcB5w?h&ta`Qc^-oNJtTJ z_T0MByz+jVTeIowx6>Rakwj&b;#8@+5>0}8N5Yx{B!y{Un{Qx+8RyEiKZ5E zEvR_OOHEyD4j8$M$+^lOcr<|QdT}WGlIEUFN9@U5uydzTbEk>f6QWMFLgjRVy?)?7 zHcNLTbD!&&ZR(gom9g6r+G+XqxABXw2wJZ|ZKfPcaKVXxMhpDhg#tZ?1_cd;i*$^PhE<;g_ELe`H<$o$`-??yn}+KCzy%s6cH;#~Qq<>th5^ zqELb4bxTWt^3P=_sU6G|0;OC<{m1qyC&Ahq%W{$p3CsBC05oKzLR7-(Rrca4=2go z)P;4_xeYi73#xu7X?YHgV%Lsyr;d6zO*(gGXvRvl#R8qjFgdtTu_#bAC@>{&195ll z2*>P)VD;C~MG1vii*@?O(7Z^w`;H8lRtBrLXgH#l$j@v1g zP-v%`C#7Vl;5hxxaOafp-G1C@0p|XUQ2q+6_y+nioJcp9D>>B#5_bsYg%cyQWP_})fD5J;HL z7x__-lPZy14TgZ@Au0xmLakz8*!8Nvz&lXh;HqxHJ%nab~Ri1s4R za52&%USG1@BJNPL-f`Gk`zO56jWI_&nKV~I8PYRb`jMPdP9F?~{O`j0lpl?nlB6$T zHHJ1Xsh0w7XEmi#(N~&u%skf74vG=ng+&?|8X)aP6nsxJQo42GSn%3+}ou;TXt|GfMetPb3 z?WhD%{|p9Cxr)9``RU!mwJjIsI4gkn)BS$wONz_VhPgxi1g^P5qT15Bfz6U$=-VZ& znuE_fssbfe)rIPNFqP`&IRonZ$QX^iKD3rC7fA;=UlP}-za*HCVo5tBC?v1zk+F?I zhdLzb;_4>khuTLI;jUTw#jnfyvCg`C;p_t4Cz?h+9-6#!Sr`yRIW$6OTo@|pUg%=w zSm+D2FKa$BHF>LRW=5rJYV;=4%shH1xGG;NxU4(`wl-axxvb^#C8HJV`m>Cd;orz; zf9E>*|4U{6!8|_DGSSfiCAf;b z2szq{DA;P->c4VJh$sN~BmgP-%i91F3I@Q7-|jd6ffV9ZK!5W`zdsPh%)-L-S4kmo zYLUE8?oq!k+JX6nfWUy`=!4TJ)ab>l`oY8CqCUJ)LDzp|y%BViarnaQOvkjPWmz|v z`~U&BiCQpz{&al%MRRBC(Zb*M3N#;S)h98c!YDMvgHcUP_lECY~F zt}4Z5C**OoTdp%t3q0J*T+a%s8|yDaoHTAZjkIV#OmY0N)jq&D6C92xi)C)475d0rY+RLIRKL89E)``8oq z?ww*S%V&+}hl$qbi~9x5u;-_T0|8@<#&6FLeh7(oYey#|EXtbIX02au*SmuJzEs5C z$7yo6I9_fAi9DT5v;uBM@Zf2>-OhD7gr!=9jo*-q)fvy>8I)(lRR^pZ(VFZXeR8H( zD0w_sX?;H3zBdDY%(%92Q^R}byuyvf-~0@4l5MSyi;oRO7;{(q75YUWf>XG6iNFgvz9Os)oO-xG~-U-;|*pp zy&=mhss@4!ploh4Ic6ZpedYYNFWcPs#78c~r8gCmYipu8L>@ zXmk991-cCx@aUP&E4gvX^8DE&P#DX zYa9-Y3x)(r3_wyH2yJMO8Ne4#`oh1hMRbu@1r#04=^hD*?*;DE&y4cZ0E2NJ>@FfF zGE^MyTk-4QS^2w?Wy_o|9N3sJwPT{Y@~?c@n2bC~V9LWU9QUIm9Q64^-jlBj=&!&< zOATb*j|U)C$Cs)e^p^jDLhb{0sB6{}0_m=L4kQlm4n*FeMGrc-;8noOV67!`0c8<& zycEsP)AGiw!oh4=nxblBO^xl*snKw8-4FE+DSbM00UPLrq}&Mz8j3eAKKyedfH)l( zdiS#Kl#jgRGe>rKnVNo$@=Rf}yy=Rj4_A~PGBw!?Gq!0Y7+50okpYHURe<%CVaF8g zH;dP41!o+pfeY1}vV=&C1E{#|Be*v3Md@C+x36|E?A0@f^$K6et5-W}Kg}M)dX~KC zQAdm08Z0q@Dpe{JAiq_DieaF_xmV7552A2P=;ELk3HyVJ;3K1Imb~z*16KplR9b>z zduQQ=XP9NZv%(%CI$Xa8uz~|+i491Sw`jfv=qaBe$DIr!BY?qu6Z%sr6GRE_ekE%363`s$AEPp#fSO|VQBWUBCD7jEz-BM-Sa~)3JPCJAhu+{f6+W2 z&ffvw+hhZocCTb6O2^CFmTwUKWnp@&gEb4l$G*$J=UU2~^}P&|u2NW^gdlDcpm81y zd7fGf?JIPE!LC7vlD=7IYr0$m)Uus-G+t}`MPb@h@H`li6P7u_vi-|SxosY>o{k%R z2%LDFvtz(q2&;|^9E`95dX?}=85>wW5E5YNPzv>gdIJFUB*mBX$5Ht6YB`}dcVVQ8;)0ZcLiOtHKAP;T_m?|?j6UbIatgF4w=ZwRpd?qAP*P-Nwh z&y8PHh8_yUbI5zWp&DR%_ag%uP?yClA)(AO>$9DD4`a`h|=pr0Zi!~EucOO zqxiN`FCT@0f&<7UE6612MW|CY_T(Yhss5&5vGri~w z49K*s9;spJtHj=bSBpV^kbB{uznaO2YBf4@6EA-!w+>_rj?oKai89 z@$L4#D0kY?$3qY@d}J8&LV#uIbl{QIG|xkcmRN9PV`>3K16;xiz$F0o_|H#@k(XF; zkchM~1&H+0-&d0YjOH!^+lfwxQJ2ml&) z8zV4^Uj=aFeJGH1WPuQa#Ip2;48-7%pG>{Kd?k61$d{AQLYz?_F;!Mko% zW30ISB5xTFl_qzoJ#!G0p=hIp)36;u3nYZYRgj1*$%PG}JhFbg4HqDX!2-Mt;gw&9 z%PYa;>zYV-lZ_-Q-2}|$?Py&aVasjgah=+*{lJblrw%wxb@j1_fbnc}o1e~;6wDfY z`5TUBXf88`I3d1AQs}h02Y;mr-K{Kp@;L(%1*7_VhG(DE;&=3K6*zSyNE;2+|e8QOt2-!$^5CFLGv8-(Y zBX>`rT@og6qUe`bbe_au@(~3B-jvu=u7H`)Q(hpZhYB;j6DJBs7q`w5rt=)u1xg+# z*oi_HZ{C)0)>j4sNUd!#AvZcl4@|v)5DdNx>U$SP`#~6Jcta@Q>LKu%&h91@gVXfT zUS(*!e%V71t^b=qbymUi^0Cs56#=tm1PSoK!1o*7d=UYr2Oe{CZUW$ST1+q!YqT&v z+ZjQxDonyc36MHD9Ix{@rC_+#(}Jdq>iD5#LS>Ml#zi_N@LtrNI@RHB33PZ;?DG6b$}D{Tix{g|YgrNNku0tudrkyL_>yJJHRkroi6 zUY`!RhGdx@jQDcBB>9|zZT3h6uX>YqKUk&Xo#WO8;x`WU1Jue0N!;)-0_QV%h`TLw z6YyRn(z&C$4Pe#=O7mZ_m)&tZgL{}T076f21RX~sLOpBR<~IV9M>*kzPj>~EZHbpz zSvrNtG8rz7evz>-KGP}0CgOfW01_)I(deuMSIrt+FTrk6=&R_s%IU({l&f|$fa?Hy zusNBBNKo33=^UL~bsxxO;BmiRy{w z`Sxgg3E??%-Kd2^pHFYY+uw_@I7Q1O9EvTB<=gyH(|rqi{Vdn=W)dvVdDD;U?{9GW z?a6`?L1}U5{aogc))X{61CCQHxXruw@^Ks9AB~52VUp3MF7PGIuWi+U)tl9mT`RZrlmf??< zBjCJbbBEUD!zW7{1bzKew>0X9PmDDsSFXp6T$$8FI-#vg+e0qG!M=Q4z~d(&(p=;R%Df6 z-n3hOhV*`iBvCa0qW%^X=_$eZVlI-^f+h%j0*D1hq3S*702enDdf1~I=XboqyUJ$X zn_$S15}84tuZs_lYs!_HyzeV-4$Q9+&MM=325jGem@~UDEWEFE0Ltx9FO@bOwIvl# zCP$0>QU0j+qxIVpw3Z)e_XyF0_ZuexBq62tE8s8r*^RRC;GT~318-HyVXA37=3wTw z202%=((ag}ZXb2F^_QLH1=AL=Xsr>=c)~#P7=qdhK<9RPi>A;qF+jLwmiRl^39LqX z%30da_^_#AY1z4p$5+K!u{H>Gf|M#$!UjGzS*^=^)=GSL^fXml>z+==pB<}0F7jU) zx;-bY7PlxA*C6p|W+ydfM){E9#ugfvOEfw*1oFfYf+7p0K760gQOST4p$)|~FH%Rt zFw0zuI(L&Bxix6bV*C9oS;N)=Y;;18L>MJ|!V~PL`(rKld;9iTy^7}u!EL&Pi+Y&t0W;KKn|>JGlMH& zvd1PK1VIju(N#J&csnGl`@o}ji7n!`5~ZIUx2+O+8+Sgx7=TGvrVd~HB5wN;WE z11vx3Z7gF8Ipj2MRg`4EzGJU5s1O>v?XfkCQ{oJr$j^Syw))0hv!OARSFU#2bnLQx z^29s{26ks*fzxleCjWb!~A@EENv#wsh1tn+coeI!(`t5eS z!(~TB5JBH4;aWM+M`T}kk zV#zSGx~}g$W2%1ho>%~GS((fUj1QhDU89GrTUL3&i5=@o(jfAwLp>M?hygENZbzwR>M;p7uVqrriUIRis z@OsA?^&au10J8$Zp&xB70(f~jXRoiX?%L>B=}T`8{wjp{V4Nv7f9^%&vfgo1#~Oz~ z8})@(stX8V3<0#B=Qvzy)b>v{KGYISLEQPRO^WFkm`46sgm9>HTzhW6O|r@Y`@N}{ zNDddd;b0s(*suQ8dQosAdv8{h$XAP6-eHG!=T%4PS|A8OE zRD+jei;3ai4`u!?FxcM;1724c?&=1mSkQ_!sSwHx&z? zh8kjy=xi1dq=jWgvcNWH7-%^i<#W|jdlH1nLUpsI+0A3)km_lU+zp^UNt9XHDZi|h z6T{xZx~J;;PbU_$Oq=@-kHs*cW$eYR0sAM-oXqu@9IjV2{Ge#ktl?vJnkeqiT|Lb2 zR{SF1u&U)$^r*{?n7T|bY-`u@L;Hm?49j;G9#~0(9n{?8SZbWP)Ap-Zba|+;xlFIj zj`aQOqF=QorpLI@beb8h8b-Ou9-1#!D7%@i{Z@y6klnXn){;TUH}qRf_xxWaFJLnL;V|tbo8OzK_1XI>n{U~j;90aOFTQgiZIfnt zGN>$txiD<^=sRIfevcq|ue<^Z-N{$a9H@@DqU~tXLN0G+Nm}u#V{0fO%z*u6?4R>C zGN?mg(H~zPsGN!Mif0>n%Y2U)2eUx8=W{xE%tY_%s24+NVl$T=gU3=5dUYv;e)T^5 z;EOaqo{FspV|pp<#;T{0rb|h6cel;`5$A^d0t-LAQ-mVVyH>d)uJlx>2i)P+D4udD zp+*tTuG*US>U*WKl+lDFvh{@a0?8~&Kn+F2`4ctpWO_NpPn!Jh7O3X51V}ipa*`+L&8SFF zZngK(WM@|Xj#D> zD^7SCLJ;%&6b$rI)R&HKR?g8g(Z(Y0@Mv8^MYxlH9MTT3XAAGvcU@d>auYi z`h;a^b_3?minYkZ3vLRUdBq9O%Xasa3ObqY?h8>e)YWB7G-%s{bRIHLj51{oZJA~i zTZYC_%Iw&-g*+4IwFHG8Bw~@=DTS(6OlmGd*tS`!Gp#M#Uz)M35Wnld3bs=*UmiW0 zAV6r+ya87XoPE*T`lSTl+$f9T-T&ftV7-zSsAiEj*^W$)GE?iAba})lSud29EZTg) z^7Vj*Qb+h%LdG%%Ps(;y*6fh0cazC;A7lkJpoS~;ORWGuC?aWzGlwfuNvDSH#Hzkk|-Z5t{wDa+Pfh*S=7&in}8` zTs?67%q%XvAEGu_`t{4aQ=oujK(FoehP#(2e+FlkF>$B;h+?)2FG{zmBC_dIG_e%vn~`}2~H&dQ~mADhXFpY_hA2>t>wh`7aaMIx6sQQ zj+Q);WK%c1`oq;7bA}8!2!zhH@%LXRY_dm&bq&8$Yvtz5qmlYP;!U*lmSPm;^$c{f zMv9N!p`B1c11;K@5RjCiT#&sivxhR#VPE`>87Dcr}UaddRX^Qb_O3fsMD7zj24 zwC8s|g4!e@dM-XX*NUwf^hidv?0?)wK&v`QLmD1vr?Mpa-<y&9BB6SOij7@G-Oe zKrwS&5wpI6F+WFmbzY{H=;pqEZ12tT5zZrPW`X$@@78X;k;2Bu`VIt~;J1b_)kYO{t+3^#`!6D{tIpq&OavO|0Kr$*TncwmzO_@@qZHI|0Kr$NsRxK82=|R z{!e23pTzh-iShq865~0mlRp#VsoS!vf03plQ?g`5xfc#7?j~Y{ON&Kvz#yJt^#KDx z147eY<@hLIZ0=}VV{CcSWLn1#lv&!+JndiBo%D7l_?M}Eh#6hGo9*M#uh$Q#1T=a8 zP=OFbB{hR?ic4a#OD=S%?PMgDq_MKxcsoq^KGY6;8=!SG_*-;yZ*P?M^-~ zA(4pW6-q~hK-pa^Y^1_s3B_d{*aY{V*!0NyHNDOY3We#`RX+a&B_jZo66Ky37=pxd zsc@!w0SZD$^Z+EXGSQ!}w3&AFmka=eWksTkNI%o!ksnpD-};r?-mR~n5)vO36-$9) zWqJQ<2^D@p0+Q3z`Zc%qaa{t~i@0>6g}RtfECIn!xCdhvGFIZ?GqW5@08Pdu@yeS8 zm_(NIueX(k>E(R)J)Pe*|LidA+8qc{;uyGQ6hh$3SS$GfI6zJe!cRsDU`$^Speon` zu>U=x?sZPos>E%0VV&N7zPNugynmHuuu-qvdTxE)I=qiR^)^T0{I;@xBR7)$YrGIB zYy-QYh*UrlKmiyWo`yth6)~6L1Bd{m_00h_otyycYoHw97I4vzp45o^(LFg>;nS%o zmW@MOB+a?m?0c1y-Uw&|VEND6&!v!{j)Mu531Rqsc7Y63$TVUE5<5@|)AP9!2LWMO zK&@8r;y#D~85)6rhao_y8M^Xw$y!u+d=XRGNCKj*e``4!7L(1x3J^qW{cG^p?~jj+ z0I1guiF{TMz^}CkxojS0K&n>cXGes1mpjbBBpxS!D;+mol;WV-6y)|;&u0-xh;6~f z+{J8(G!v$>l?!&k{G6$0{(5|0Py}rO0VIw<%ME}W)8u&YYx_e2JEvn7W~=MR1W?EC zLf97*v|p{-?nGB_Qmsyy>|_#t^KW;{At);E5+P!NX7%9L_Y!c~&=iLvTEDDZ`QyD~%-*I6ObiWL_K(J;T}mKnSOjXxuzxNOFd!&0GXa?hlG^DV+2 zKqTnt2kw!;07}u)Wr?G}8-cDp)&>jnsu``zmM!hEGZQcdDJB#bQgdpOSVkADD;Gu_#!|}bt*CJ$>*$+=xPn)RiIasIy zJBWf+F}Pc-dQ(#vRQfSEb|mB1Dv>6ub_9^#b3tfUhTj!D6j!Fzn}&9beye3aDlgsm zaE~G}=%X{cep%TtMuC^;Pt|F+pKTRg$*-k5?#E{SU<|A_WP;w9*iwM&)+JH!ZSY(~ z-@y_6nG`$O@PWCBfI%9VN7}d66A1VUJ9@l2(6P2#znNphX}^_U)K?r0H_ftNV4Q9i zgNHNj`WA5O>6@>F-Z(aBeYGJI!>^ZBzbn11po5JZwQ~9OWYI17^MPCxYg-?dIK6@A zdfe&$7%YU)@w+@xTH7O7+AYi$UY{b)VuWO$P*=Y_MC%Muh7YjFvP_1k0aK-7tN9IN zM9yQU6ZZ~?R3?HKFo==h!069u2RFX1s{DN)u@5&~*8IT`NsZ|dIPXXY?R*S|c>l&F z*}QTxsVQmRQ|?<8h<0M;MI+U2*~PYylWQ!UbCVa`#dVTq!eK?Q9YJY_0|FF5w~hA! zvL{%7pdDDzU70E7&WLL7aSHgw9~Ql99Rf}L(-@B+PgQG9Aivf>B-VkNNRIw9{D%0w zZS75`Lo0MXBoe5N*=-*mX5{3=)=3wd(ioXfKY&~Yn@e`^305bT;xPV1PsTf-Z6dKM z)+G8aB7Pm?(ifGo#kWoQKulbGYjFzuxI{n$4|U-ZM;m*PNFU0tQ^2tjd0raoc8PyB zogAC8qEsb_DDd5_Qy~?&8L#btI)&n_v2<-$AhoZ#yARxW1%Q4Mv9>BxJGESJq{krc zHUHat}COe~Z-*=-626JMzU+(^pkU95x} zVOi;>skV04<%mP#m~{4ea8xZ1nl$nZs7_xNO3p?BXb+X<4B!z7m)UAW2pr}L8uiNt zNm@&TUIC`wgK!I=M7ghPnU=B0R15)MDdLqxIqAET6v7Ab&92s6kVGvDCI&!A*_Gqs znOk=HOen{f^ThE@rk%DvMs5&11fKXX?gpLn93YrSyXxDc&#Y;R;oP%h_xhvw=6StG z+%?eyHK_Z!9Tvx&E4_Cwm)0^J>sbRs^N2X4`zYC8)S3BXUNx51&_4z7%( z7kQe>)qLY<`qas%_TC+bb|UvWJ$i?EbWbc88Bv^*{hYN^16a%ic-+HaG&ytTAaj1B zRppLwzIRs1qHP-8iZE=ppEwflgV(8NM0%^J*-IGMEQog2ykG6YZJn+iN_BsC8IUGR z4Vn`ge=!r|C)R|5F|V~FdTt8DK3|<%R=Buz;hv{JpCO2Z-)Gs{tI6%BA49_vBxnh_ z+ib4rtKx4!1Rjyv$`>XJF-{;?#-7+4mQq6A+v@cOX!;yf2qJg;37*occ=vQnTn)oF zgx(}31SCWSOxo1kctd|o_*?|EB^$s}5G+zbAPUPF3QakVgH~3rT&U}Xe_^$`@;88K zZN^0-$ul9FmmzyR>EoNvQZN`9%PT0h8g~Y7QIBY|D?URri?qXGJq>TB5sa0-G3oKN zWPTC&qET#iT3CatmzH<2R!3z|H9asR;(B)VqCukV40Z~7-Ho1kLhYJ<2YFK3=0ls|LRol8mve& z=CWl|5a#u|Q{E{ZB87t)epd?%LyvKSBVST|ozG&~HDvdXKcZu$pSI9|{?cWzjn}z2 z_hdP=`Od@;8gNy`F?dzR`4b_PaYgYOey)#8<_tt@>TY?lo)i*+CoBfQ&N~r|6~9~W z60A3WMx51wcd63D9m(q_{UcYSHOC^aL=+TjCE98Jt`*}@W6222kb(D1y$7ptsYlF%z#a$H24G!z* zL6%eN*7?w=^%6VqkdrkZy-^NbjJ_du_J}jMXZx3gVszCX66ac1hd8{`88SiNj;!PF zi!uz;G+}-fx%XD@QskGKe|_TLTc}ItKo)s;L!$`?Z6G*MyU?smHk~7GOdO;!RoV`4 z2WB(+irHn|biSuEx-y|^AS_paPy3%usHzxWu?{<{T@fuCoG=|-?5R5FF-n4uB z5ReTvcMsGdzhLPxfQG5;`}5;b&;smYu35vwjGG^@IzRq^W>&EvIy+Byf~OwuDS+x< ztE`2qt(hU%+(`?cfl_}puwizU6Q!>;MX#N9pCrE2l}ksEe&{hJGheUaW@*ys$?0!I zS4Vq1rdKi&$2JIGk=(&43B{jytv;fgqWSomTSt$%fTS$W+pMcw!h9CAkcTE zr+wK~j$*&^1+C9Fqt*KBdCDXnlVVD*q+HHalX>iP#t;0n>Rb+)tfwCF&_(g~=tuI^ zAqsK)H}C=m>P?v+r+Jku#ptBNMdkV}(p?_Q^O)Xp(873eT#+=wk26I>Sh%iPX778= ztSh%bYB6(~@!HjP=3#!BxchyZwMDwOlA}``JT_^2jdBFI+>MuyeYF+~*ShcqZA@WN zGJ7R7oYYfX-@-A0LSQ z;0kGs=x50c?*XEiMUr8Uht`nEp${OCa#GJo(e<33*!)UMY7m94G{6%s#dn*HhQHlQ=CaL{M8FKq>kCCTkMe?y4kf>L`t`2vcSsGSk`H zJ1AR8&;)9Tm!j<#80j&$5@=8DZ|Mu^#NnT(N}SepFjPqV7q%+qs(xckTs3wi8byr( z0VTuo;(FVD6F<_~DwrpG;jexLL+3 zw&fmRCJf@@D=0uZ**$mH#b`eKlm=mTN<+7j`ma5Bnz7%~v3wT^NMHWdBUVF!MWJ2{hQxu&cHonAH zoMSGH)v`&u{x|1}5BRI^=U&>ITAIr+`D4RHgQzCnr1sWR-Yi;8C-bV%895lw>cDP+ z5(T_mPJusdLAIt<;T$*YCPh-S61G98(HNl#SCJqYFz*nGl-q=#g}*oH!iS!5NG+o> zb{%q`32|E@%CZ-5ScMbKKy*=<`v6OSsev(Ne1FhrbVirxZ&EqAd0x*wKM{}`vKndI zJPjp%;8ZkkW_);1hQN#RR6@;kl#k#qf3D;jE$mis>jMW$S6ru$ZD14vpU8(j3|u-L zlUqNrz(P{5z8$h-GlH$fhGkvvBWnmGGsfT7GlygB7u|)h!>3*QYL1Ncat7@=hj);s zo9Ys)w7_kTpt07lfUOC*-;})0xZ}o(X$xvC<0@Yz_6xN@#DSU0(eH7QYy$K%7zQAk z>X~t?7_H*mpjBPI+!SYLzvBR=e1SRt4+`f0f+YXT3g+LvO8x?o{{cJx!!qO_3g$oV z|BVXfKN<4;|Dj-hT0VbTivM?+#($z`|5LX7G%WcSWy}AEm`3kEOyeJ>@ekAZhiUx7 zH2z^4|1gbzn8rU$Dhc?ACt2C*Oh)Qo;_UJ0|hkw)3++Z!iKU)!zh|dgsr{XNxF!Yq~OHJ4fsP z3gr&K7=$tg(G&0(18tNO0*(|C5(Jeb?egOxl28`cSI7`39l(&!ViXKrOZ#k@DC-5} zA=J{!Euo$5=zo#TWA?_Qz0yG;o1?w`GK>;oZ*h|ss~;wy<9|UQ$FQ?_D53z&6}wQ& zY8IRO@?xAO;@~p7^_x|Yl#8T>LRMaQyUREw)>z_mAc1Mno-L=+MSzVmq`m@bEV5r) zyr)o+amiF(37_SmWnosglfmhw!9hmion-rnOv%r@5+A|m{Vw2iM>4mUH*fgKJVd|V z{M?kAl|3M)(XW8WUBDPnmnZZfC|ZSOJ%ubG&MkH|tL!rP>JP{8z4TvM^8MuzUqr_0G|3zI^$L;r7iIVi2 zWW@sMo_s388VZsebclc{0t9(71fb9EDbgQbDVfO3lY&9fKWirA_3kc|Rz&14;s8tv zLLeaWGpJ(vf8J%ukC1#8gGAmyiTA(@;1MuG^;d0joOi|Ktt8Ct+CkhEa0Q->Z_{#w z-eUOWT8&$nu@+?mylv2fL7lVnR_X37Wu|+(*dlj9ML;cO;A6pm|FuSjfDRLmH|?Ta zzR2C@wA(vqd2>8qbySD~P(pg_QP2eP&lwOA5d#+q_BJD+ut?t$M(d)IqYCTOQ<3Rs zg8w!16c}wd{8-~$ALMd#MREd?imaM8I_b|Rf+&DP?Q#$RZAi8)h=r(*N-j@k(Mq=6 z0txw7)zB!iJo8iK_b)nn@;Llo1-hJrP{BQ8|LQ)68>Y)odJGh+%1Rd%+1#vft#}(| z1Vy=}%HwmZtqfqqj;6#0z5H#f$#{Wy2tC8c`jp6R(LDk)asD=24FddCP`JM~VHU<; z3-DjmO{)dd6UfrP_xRg(eHw`JPjeD=JICw!+yIirLe)@AQeS~Tiz7*H7HAN_^w-WK zly@7a!1%5S(jX}Wh|B{>f(5#YtIG9DU*@H7wQbR~xyymK(R|u?;`w-c$L66Uc*X^u zQPOZ}y&BZW&hmMo<9$e*DQN!6?A@4qqyH2$?+$k6^gc=lem};R1!Y9xe4&eQ{wAaa zA~Ma%_j>TOGdI;5yZiJ=sDbq!%QW~c@e2q&PjfW2KTJ#_V)0Q#7EJhym-pjCQR71C z=}9fxTxo`|T9Yg4Q7-?QLD|l59rt7RCjQ6GD?7l}zyo87p9ma>3DA6N6g@DhwW2Lh zU8yIRfLUoH!YT7rL*_2s8=3xx#C!tBt?Q{z`amN=7Z2aZ^W|%?=S_pdp^nX5*zZx- zUH$Q*bKSwlELp=cE$WauPZxCfrZ!lux)=pd^XN^6UykO>`t4)UasuV$2^0|2TrdH( zxVCvGYfegP2g(l{6wkyQ{ao#kwb|KF`Khq=c1`KRYXsIHMQ@ucfhF7uAL?vP+==~0 z@n;c}vai$9uD>L`yqr9xa|77rw*49l!!@+ULlzPJd~kpN7>X!`(9>xzqDROBWu9Vh zuszjUb5mV5ZRn123!y?t@I2}pOBIezn@&QUFye36gu==JS@s%@)dxwB0;@A}&fo)PIV~m}8wXS_bgRIj8%9!b;CjGKpZj%W^ z_2o_xVSDPOc}}d;MmUIWJ1~Ghz-6C+;S#di8_yc5Yq;TDnA4|sosx(slpXbc6UyO; zGNCry9BuU`WGVwVMnQmR%s6TNxRog^d8z@F4L#3W^de?q6rT=mZBCQBS5EHswTXaS zda&sNvQ>wf5!X}#4U;pdaEGg4Z+24}85`Ig;Z>mDQg8VIa7)w-D zq>mW70NSq^gu=HAtP7p^@d~Zj!s)RgUB6G+_0?a%#>&gn#{FMmbaNINdbSq9&&|Y6 zybp1Rc%xpR_N&b4CzT1t)?UpmW7UadJn-{FutIEF#40O+V+;@G=kLY}x0d^7-{U9P zsUmg~V6aKfD$~d8Zr`>D$4oYEtN0jl)`Dx6Oh>o9(Bx;jUoFcmyt2#8yVDwt`y}NT z_#HZY+!K*Qb`SMpF8M}+yF3E<1Z}nt$aJ3#epR31QbWEUn`H=bB*I4F6DRuj%k>`@ zC}B(75{aDYU*LP4heBmvb@~_8-ZiZ!L%X&}-k&G^6oK%p(4l@Gp5l)H<&zTaohHYB zhhj&S-2(P|qATnQGIDGx68M^Y(Vqt&nM!lsWp{YtG{Ru^Yc0_Qa#^ya@7^7%3YWK8 zfU-67d9wp=s;Ml-Wf18grB=&TyuF^ES)V^hjof0w2W2_itR0kIG?T*aBmR98aqK54 zycSfsVcG0UbW?+UryD6`d9Rjt4<#&^SAXKbd{r*PZ}>H88D(2R;>V)e-&FIKsa~U8 zcN@|KQw&kGOB;>dED%?Q4p^KE^o{8yzt4GNK=><8o9oX+A7iZ5<^-U^U{;Bq;SW*G z*4v#IOv#*0WnSmBZlFHJl62B05)%aC%1*hM>LCka?eYl45 zmqis^wuZkHx_v!AthhOW{5>KZ%+;4HmU=&sG~urov9@^zs9G+Vw}j_9C97FxWiUcu zpShbJwxwX<8-777(OaaQu~n32xyoOmO#$+A6G}Q zwSN<8PcKQsK4P7CixVASLf~JPxSeeoE(J9sME%aQ3$GC7xOBd(X2Wlv6!_G{E!?D5 z8Xxe3RH#Fp0TANp{mXn>hW8B%w(py!IG-)rftOZH{tdZJ4fj=Q@rBqKTkvY|CLwa^ zp=-O^hgrLd2s{L;wYltzEv;F) z9eVBNN6gj-7uG+GnlXg<#q6%*0W$T@%|X@d3X@hZNY948Z#gst7dOMX4@8E)+&P`5 zdU{pZs)E1MF|TfHq@_+WN_*M%2OKYsLt(hAhL;HLbx=5DDZ3TV&$U&^k?0JGw4-3#`Y|$Iq^$GdIfQ8sYAC554+(;BY#Uf=w3XGusxuO5B>66N8gee}T_T}%B#j$<3N%yG)wn;`n{AtU%Rsbv6Q`fXYX#R?g8 zlUx{>?WT`gyaLkkgGonDf(*pEFfAuDN6PLy&0p%W+OZAe3*UIVCCtj}CsRx{xWtiX z`i1SnPID>|)bcd(ss!v$yA4;{Mw@r0^);-cx%RE_g?voop86Y&moiqdmFaHHK9KcY zjt@L7O8GBV(*l4_dgUFBZkv#Ww1{Qn#kv`Cooff43nD4Ti#qE^O+O-6o+*oY*@yT- zN#-~S2443=a;f6w#BtIw+XY!Vg&LJ<=|{q+Fll?=g50Oj+`ou;^|grxE&K{fiN#q9 zsy`>X#WN%!BUt2CaV9OD%T(OQgFS+~Ks_Jae2@Ps=-!fO&A2`o@euMWkmhM)&FyQo z0eNcSrtySa^?Ez?u>l*pK-qV)z1}5V+v$13i*=@YSL+&Bov-WpU0){9Rx7xTdK3^) zuJ5*qu#`7p10x^yQrG=*+H7x$-<8zh?JZ%Q4Ibf;@F`Aqpj$_?amdS;SDlD3m}-|9 zCgz4H2=^q6mOV(r;_h(FeYb1S4RP3`6#02w56zvhq5_iqql*+R=ul-K846$pFU4Oi z!lTTET{u84yk=?niOWVE%Dt<`)89uUYZg$v(!+)+oSLE}4qeEp?uyIZ!$Fiw-5L|Z zlW7sZ5_LRl{5ZILBVNnkUucUZ2^D!%tF{0cqGHfmu{4cL4XRi}rdqIZ+l{>j2_k_& z&-y(i+U>22M_LLSohBGYOMus7#$-i7a@uw6HKAi6n3Y1hz6+kSox8W4BUZmmJ~uHG z0o{8wZJu8xm7#V&e(u$E`~xDl@p`U-9#yreMJ2m&Co3)AVqp{Tn3+3e+=E?-s2+3c zsnsu>9$Nlm=k<{9`(W*_S~-0!mC_K8mJ+m3t)EcbD)`#LmdZH&i)4v1X%{ zrxL?pHK3mRS`k91GrFQNIyj4smtIULe4|oI56wp+{z>cs>aYOL3X5Fc2_{s;fUHc1 zk6!sWhU>9u%VqYLT(@Eq@rV^e@nu~)+~Gxp1JuoBtu zmrWQ%c>qa>+4E%0eZO$nYLbGFRqL6mfLY`+dztCIY&qBP1maj zDgN!~M$x`XI^UTC*!_d@d%4*VR`!#_3@QQX{qQV|mh1Ku7Bt@>^&hkD@PVqUPYCmu ziNLDQash1aeT1V)dOfBmp{#JKX5oYfn9_k&4^P|c7D5#zlJvfaWEHWub!KyMdSJgapj8*FFpQtRUYkdD z;x~1i1V5LftzOjRdF~lrV~K#J%S`)eyPE7^CDVSek6!YrTdDRRWg3ptJfT?z%}Ewi z>;kr@8?Qj!o!Y4AhjEHtEZJiB0)oj|X{_i78^f!8Z^glVxPrp_ULe{?vvhq%mJyu^8Ev=f&ZLjnLr#BSY`zDvep1Cy4CZneq^Mm^yQ|~G|0Qu8M zo2*M@d6Qyp^$;@gt8H5CsU)$GGqJRlmXJQ(NL?Z*`j_wP!kTNypxIy2h(X!g8k$Ih zVv*F9CCrIBaC9`+aKGq77Ac{|AX>D^9*x!{le!(w4rRBJZ$@>eBm+|5aH?b_i~&v2 zR1kB>fO><3p8&RKvcIldhnV_Fa6k~bB501VSWYVtHhYfr^M zdWPcm^fiI?(MREs_Xs#Oaiyi+rSn+QfP%U%fWtmJlt`46k%R+OM#KB190E`~{lGHa zdtrMP;%aGHAx?iDh zOCRjqF01niX|87Zj8_CNy-pgknp%HJ%E0c$5i;Ca|4^lre%0(c1yV2yVWc8{Ri`s$Hvi z=Uxu|5c4QtS*w|_$p{r<+7n+bRt{dx!e$%VH@!7YO!DjB%D>IFDHcEHJ(QKJs4i?M zu%F2P@Z4ArU32O9CV$js6IpzH_rBFm0C)>KlRVpmX2~oOAPAwmT50Yc&6GY1tf=;=2f4&y)3R>RY7&*L>CcbU~# zWB21R#i*2B!S8N3k2qQ3{E~@S9>SR$3O?*^<1_!#HE>gAckFhx^TwapWlw=!c|W*g zwfSR1(|cJ0akJrj#|z5WB4XpQ*z)J;UQTN6_3!5zi%&2==bKiTqdjQb@=wY|kM5jQ zUdtXH+CLD{iF1xu_N_TN%PW4@y}I`$twCsildH8<(S10;|6!wxxT&c2QlTK?LWy6j zpT%E9Y+4hoG+kDqg4)i?JBdW_l|^{{M#gUwO-1#~PWmJl7*Nl5rF+K3t?HPPP%M2+hP!FRQN4^Rm^L z2;X65LLsY5uItR;_lGN}R+V6Y+2tjxB4KjnVQntMNr=<?*{ zm6TB)eu)5==E!`J&En%JNuB~SVQqV!r8Fk@#j@iZzfh%nvIzD>szo7TA9wOD!sS79 zntD^xXb?jmBthn&+%#a_UT3~l%BSAYZUE9Pe>nYW7;Gyi?y8HT2ODMotaRmdI*+DD zoQ&cfg+{m$_67C;JXI~i?YkaUnfaHo*JvEi zVTyR|0DaGl{&1P0l^3D!oTj9Xiq797wOv>C6v_HVGNPU3yULtW4`Nlb2{3kTXW}x3 zE%2_v@4qceV@AhA*se;gYIjh!8*T6t$cRcK!WrqhJaDJp%?uUlFi70`qzwcmh%Z?; zsxBG%*E{VH>rzQRDav+E4&kcI^0R$$p%{zTHGrB#veuO_5ABHPhWPgVifSJf`^a8qt+4b4*1 zL(W$`9~Zk}j}*3#^mJhMV>?09q!;L!Q=yCunTBkw|hu!kr)-xV;R7+Nk+~~B;Ou=#u`E>(ew&dZ$rp0JgNebEg ziEn1%bisE}p@|&$&|0%d3Gh0%2roAYKbhM|nvqcvj8kS2EWT8j%(y7unSKpl>opl* zZhjY6c&3Qb;+FyL2|tvhdiKzmcJCeRE|glDpNXw*v(xuzu{r3!ayX={w>}O!D1evo zW@5CR0dPS(Ay7u6#hP(RQCise9S^D9Os+i_R2z#%WJ%gc0R#Kra|6K)0b|;$Xq;JX zD9XG@UZ|=?X*-rGG)d}0+W{_2?`RpT(4AkF%#G33;-R&w-N z98DrY#9ZLB=M3=kNTAWrip)j%egV{n2r-;wS_y+q9%Il>RCBq+Me9jSI@VWvCioN) z{m}1?VQ32;Bs*!WFKal8mTA~G=exJ&&XYC0G`%)4_)-}yrq!mdOr5D0z|U_ZG@0K) zj{OcGijfRz>E(V~wQPbO1sWn2GhHm) zQXr*O!w(LE1X0V;p4Rw<;6ueUp4z0mtz1!go6c<<)>Qfk2a4hhnbdXh z$}9`20WxqF+e$e^tYx`D3#xp5YY2Z_#I;E%MTe$|4}(!Jc{xafnN<8q>X{4Wk=&-t zI_QJkynDsjxBIq!lAx1IcpX9CpCzY0R-T=y;78O6;@5L0-48LNuI=|~7YOmn%J8YH zh1>FX9iuCTmAK6j46KEYef>+u`AJ)f}V~@PwXzAf%ra( zJ2aEm*aEgQ_56v|(E@sQYyIq+XgD1;!i^|@5{>zPA%a4OtbvsO{?3%7T=kTEJHc0z zQ^MhzBt_D)ypei*eEzg+@U|H#bkX;6*F3Fth5y)=RUkm%T}J*RfnCkKQn^u;B;fm0 zBytBXm|uJEDhaOBS~-; zQ4Z6^MI2u1Eo)BeF0xYymMyucKS_l+CJ52M$J(4iQLtsZbgJX5egvmkO6gfXPsVp& z&iKyzLoU~=R?hI;5jwW1G8w^j?7D%dFnyP|!==W=XL}2 z5@5jeG5&Ve&D3G;8@oJMOImXERS6Q4$lF_`lt`%&t2KhZAzawVccwKF)a9}{v4Zy~ zMR&O^=qi8yQyCTMpwBNF)r^5XjvE_G`*B?Nodxkc^0AV!ltsdlzN5@LBmN|=-4n{Y z9J%7z44u@R3bwNqC3?U3`2#q*@m$)%} z3i$}^F1^8ncpWl9&5o2dMD+DyZbjlKYC96H!Gw{8HQ1U*6|WJ>3q~{^T43%if4LXu zj-M4_C>Mzd8O1sgn)o1@zN#or+=4(lGTpzz^k}kdT_0*Es7`KFUy=aAT1P1HSLGU< z=`@ahv+p%u^mc@>s@f4jb#ah*>fZFus&+Z9W*}%-@Af`dcDThDjI>dTo0%Ot-gjg@ zan|h{qbqAyY5QH_l>50KZPPy__gE0u$=G-k@Rc*NaZz(zTA|N-7D$|`jw`}^4X7bFE=}f!A zO!l;k>O@Nkh8o4E&wcsr5RE2sd{_dhSL!bzNtR%2EnC1yzC{+GfGC-;g)%QjOasAt zx>(i3C&d(TE<yTerS4YSw49m;)bqE^cL^iTcFr=; zFYIhSAlC$kMPJ2KH!VG3803|LeYW7PX(7hl<{g8QWg4H3>h8xC3U5Up-rC;vM3h$D z)f*60nlCrgeD;Hm#5v%AB-@Y7!twd~b8;$$HW!yQCF0?eyjV0d0~Upv*# zSg8Y29NpciIoBnX*4pbRQ$>2r)-A~~5n}gtR*1i0{{SF9nt!?yZ(#K--#wu7fZMr3 z^VW!961!kkOR%HavC0=X-t%%Ho~25C{&;7QR*zj!qh?p)x~kRmpTvM)H!KCwNb*yM zGd37>)Ux5g3a;H-B{~ojlEJfWhvpU?3g!~T0wO6njuNbB>^_tj@YGs-+pSj} z5o-TD(G@RS`yB&4I4~i={#ut5sNx{W@C=|ThaWfG9a8)urTp)acqP|o`2tIpb*|pXSKn(JAB4fft zNm7N zG)ZQY=t_e6FDv{L3Be!aVb_Dnklxdh=yPpTB*(!B5D|XA<1zbELB3ErN2ju(hHLvR zmpT0W01km)mLaUvs9K3)+m(7bDlRT&@MBI=?=(jxIMiuWP8SxRG+jag*+G*MK)#z2 zTbEdb%Sd~=z>r}u(-IO-qw<*U_V-illz&c-vgF(tupFP!K{hxnqj~vCbuz}FGP*Yp zCcC?b?~;!B@}Qn{!sQv8JZ?wUUNpDTgnvKubiAswT5xOHe{|K7rb} z2Wrd(RIC<6XLlhJ4@z}r!a}rTrzp;o6;1+=oce9eF}}bccDzq2w)$@0@p^853kX0% zH2M2~7tKF`)PGW<|5efaKVm%pSv3ELmGOUIzn{6Ff6qMq_lf3z8}#2Hn*Xy<{-5Ib zzh4{wC!^(m5Wwt=O#iZR@&7{vu;(8F_zwa6hXDRV0RJI?{}8}`2;e^i@E-#BUnPJQ zbji3KiNye&4{G~yCdw*KdWTH0n#n}{e%2-Wcq9bN#;Pis>jQ;aXCGJOlPX)g>M1m; zs`twweyOS@dyMyC4M-)KM-)L7*}-w8Q(wyY@Y)$^+frj^5Y#|v>rh6(eSk=jP`ua~ zplFz&D3MAMAHfQs1h>;c(O009C0~Ih4atHI8;e9-fs;_W{aAWC*3H6ovMv3$_$B(D z!#(OO;xYvqdoBoM#3%D*BBg~yLDQgL-)Dj*I#wG-BzpjLT+xS^RP&v5MIy#(Q@4Bc%eQ@o5KxvU#z$!NQ^R zwK)EF(ugG2p&W3nRKl5n~8Y&>UGw5HjJR!lp3k06EaIJO&LE!#!m! z;m=hn>{mjCJCxCW;r6#A$_q~nksjeeiCsB~y(>k}JI%XL`k@2VFd{3k5mcSXVhGGv z1`8Z14Q%P~V~wnCOfJuQbt8t7N5S;hvP&=@ffC82 z!{(+*YDQ#p47VX-$qID!KieUf)Rtx=`v5G2(4Wct|5k8r!F zSLw&|QE4($mNb?X#8Btw^npXBiZ^9-d}Sb`JZ+Fxp!kr?Stk8PIF``k@cgj;2Yc@r zWJ}XV3$|^Wr)}GP+O}=mJZ<-B+qP}nwr#to-}~KfV&=v~%uK|@{Ca;>MeUsxPdTkF}fUT zgFmKOmKsJ#Cnkl>vSV}v(l?Wi(m$CyB*D1RF z>H;74>6rlkK@#hqM^!v74FoL}gwxY}xab3DE^tCx>YuF3$nap8GYmbBb$$j5F2_Nl zpQSf~IR2l^#>|@t4gX{Z{a_5{U!*D382f6;e*#YG_ge)ZQ83uWtpYDKG3Pg{GmNjx z?BH`j?s#6~)%MQxGnXv6{c$*mRm{%J>Mnd|2Fc^5>Fmw)19kYEUH0xJ$2ZzH)%UB5 z>vyqi7dx!$UwpZmTfqULzgb!IOZ4 zJbE_$lX)wegar7&YW(1)U3D{jZCz5K;T4bX!MI(g>JWY9g=p{cVmH}Cad@A- zCn*-D#mh|^w%^WqAABI3iScUk*lW)tA7{XWslGp)AKgq_8vd;T!L2SIT>9n28xXK# zwLA)TVNJNym_V$-Hmr3pjJS9EjZu7GBvQ_R_dsbT7XpfISW}+~UIt)CfsSkh6zQgL zmx`2s$x*Iv^^R^ISkY+^*IhvRFsg0pVgb!SS5_+gT~sw8D#j^%r>=tfh0iztbk-nL z5AW+X*i9F0aVN2ESPJ*1d})YP354g~eVzYQ$rJ8^B}=p7zQ0TIN9pjUf*;(}GPp4$ zBcy|3X1r(t4ZhxWAqtvohhM)pA}h9K%oUXY z3*xp6Vkgx}eD3ZNp$Z3T7EtgeR`t4tZrh4`+VQK)9#{TJE{G_5$Z@@%E=e~aC!AAt zK?4;ej_6o}imqorgm?Auvjl4K5Ec&0ti<5VGlhCFf_zaV8!#{^UIqae$>xY-wrcQ|7rXN z?4r~hGt$5>Em&N&%vU~97s@^n1&Va0tqXTOuhLBG1XDbd0frwuUGgFYE!{*;)}cGE z*T34lSButnFfAejhsFQODnm*BdAIR^=wI(J{*fFpOGOPfyw{C%Uh z4lD2@*KSX+C2Rc)dzyq9hYygc?azmt-U+g*kVS70ped*bblIZkZPA~mR2kEh;cowF znuG_#Aai5vkSBItp~H34tmKyqjt>zT?7Rd%{mmXTza3x^vVhJcgt4{&6pf6+wxbHM z4V`|Z&ip`+;3t7}a*&i|u#b#Y%lVG+l^Z776lJ}po&cC04=W#Rj&9h!)x$zC7q))r zxzv}9;hW!O<)|)nynYOfbhCROa|D+Cb>ln;lZ59zejV(#t-?lO>>S5Q{GuuEiEqK8 z{6{0WPDCF`G!FjRU>?s2XX1&9I{K*mrZ5Ui0Y$&$MCeiqIhTF2!HIF8zm0wTYm4#L zf$qfQFZ8}67ZBL6Sv53>M~;@j$8UfMLyE@G~wYnQly6)@7D|^#yuK8{!F#0dXBZboslF< zX9Z35OTzE^Ci692s-T#X_UC3_izU?`(oT_tl2KC3M9AcW*#4#I#D}5 zg(p18nd`D?>chidT3Ks$G{G`{p(WEb9CC3yAP=Y?&Bs)_@iwCr2}~5<4D-@anzPYL z(B<=LJ|W7^yh`av$z*yJf!QST!Np@8@~rr3yM663WTEw-WCf$;2|1a==F0i>&_jD^Z( zgt#=~n-E|L@f=GAtt`(%gWH@B)yXzy*O}U1`E>A&@x@iaUfvH+U*9FYdk*!_{OwW3 z(ex}4J&Y^$!04Mc|2P&2-MKm+V+X64pij>|i-ql|1se;v5=ozQ(*P>E%Lz38?&S(9 zm2628dh9P;-f%_9=}s#tM!Q@#g-QS3lo4LeZ~;0#PHk7eIO)p8AEWr&9W(*&PxT_A zXfOPe50Vj4(?ZGhkfSEgiDxqKNYgoMF%QJ@Nb%vUh4&?ZYimM>`zsGWfksPZ@tcJh zf8EZCg%N`T-EIL`?+O*U;v^dtRp{|4>w6b3qj_of9Txw5Na^`ZH1ygA^*7=Fq>wjt zYeh@L18;l=n#Ej*lm}g?l@IlF3CzTaNCD9RB$B@8MmM+PvQo8a`4y&mjjy1%xVU1j z@Uo+_TQj!v)p8GV%+*74mhGm6MSCsh&<_K@SHmYE0Gc$DqQoa6xjPbE=OZBhxTjdi zLLhF(ZeoswgTU~;j&SAZuuRU0wQ|zzVV9jhV`e~!n{le7zWBDc4|h?D!%WGR3rJ?b zj)J)D=!{!w-a{zkiGwl5aWFCvm){VT(wHU847;hcA9guU?E@sR!vfg!Ke$ z#g<%&1x4dJT1+)ty~l-fIaLP!Ubt1X6kK&A$-;5UI6G^YjLP{QTo(>rp?~Ph*%4r! z=%9{JLK)Qg;}GqrYqAQV3kKDyq8mzH5%(f_VPrsdvkLYV5jQe!m_aAVOZU!BWo`$u zi@iYvEAFSn#x+S<+TYRN+2*junl4hfeOC6xFzUQhhn#XDHa>f?3RK(r4xa+t4=<=W zO*4Xq0ZT@IF1Iv;c|=3g3d;JJ@HFfq%|xRPv?N6e=+g(Uv?3lWEogWzV7q+D#POTv z3#dWmP(>m~Bw>iOw#=p!gaK0^HS@FVBY=;wX_In9Qby)IE4yVVA(+GO7jJ61;ulUWx(y}ZH7 zctXca+-XuJl#Me6z z3puLJtuk02dx$4@rpRJl3>sqKo-}qJ-3*kTy0bN(v27l!xIY+wiT*7wN7I~Vh6 z5hdou<&ugQx?r2zkS{xg@riY-=xr({njMa~EdDX(apoDJB6JmlwsKh0++jI=)E{NYAB;}R5Hp@g zfPW$u+0cb=?y&gAa{<%mKvvven97)kE2MpbuAy!LiOEK1KC+Z<*OkXTl~kp4nNX4f{`ok zo$OG}X`PEOPE%|Ss{@_5w-pv{9(lN~OvQkE0)cJM<9l|h*g@YC7l=x%jVjt*CJnUR zPV?FE>xUWQ6Q%Pr*S=7y&JyfiU;+UoCZb>b5G9V|%6`JU2Fb0@oGz;hSd zii`MR!a_WVAI=`qDSVE!eUFn>wd}l#`V}@V04q7cBwmr&B@Yzw1Kev7@;Q1Pj(>g>^Ys(52e%iX6xRUSEHcZgm*rnm8>T z*RSaiyls{C_eI1LA$6}<5lFEp;&1B^J=rrNn@)rnnnpuj&9AmU%|A!DST|isOO!Du#3yUFF}qpA9C24GjOS*97Sdo;tsB4go}^)Vst5 z>*gm2Sm0rNDg=3!mv_}(eOPb8K3awq#%G0OX6IovHP%5i+GR%Xx~EMni8@>a7rH?C zY(Iz3o?d*Gw=H2~?$7D)-F%!rtJ*qQJ>{5xhOOI1)Ic}A{3v7Ta0fOcGx45>(e{QQ z6WB2ht897IS53FNtk1{;Byn8TKdRA3GNR5R2Q=?PhLj=cbz4p6VzPfpVUHt!*vpgC z2YK(gnHVQV@feDb>DK6Yb7aoe`f$N6GoCJXAcx^Z6_7JMAua%sha~1WwCPC|n-Vtb zz%VtS1J4Z63B;1*?vRTHDN}i&d=6(HP)%t=$bh{zGVkF+oSNqxHBd+Ihy-dcyWxQP zHNKI3o5%l!cW2%XR}wt|*dC8!fZtD1ZP*b-H&XxEW)L$+pW*e__z0xR#TMcwb3?x7 zlAfC0U)W-j3ndaEJNPb~dDJbl2(dcM`65k-vB2 zH2u*TyW1HP(8=kW8Wa4KGuC%7ws9i(hbR0GfvRBaXzT1?XzWP9@?SI9|Gn5U%YVx+ z|Ce?BFAMwsA?x~ostf)9(k_;ffPv{BXIzCJJ@Ee>(@H18z(~OQpSypA$_z{dtp8Oo zGcXgd{>K>i=X(|c*8kw}bInS?`X2;-uGt7!|D$aFe5;wrS_kdQT0g=A#~%z^M@SMvWYhUZ)q z6@^$6>||c_p~6WxA{u3Gs0dL2>O);RBPcvaQxGLBFhhHQLFl!R%*q;sfC$8r7)~Ad zT|#GV1%rqLGAdp~7D|0zXU|||M48!u0-o=5$TxO8gYsiNOX{jH_hUD!3YSX(pdgeH z1z=E27V^_lRK(q1vhrg+D+-s(06=Pw_)^Jy5F);F2=3xv)`yW)g)VF?+|;00_dV&^9`c12Oo(2>sic zjB7I>0N$Fn^JJ2+{AW*ju+o6Ba4)+|00ZiKKX=0LGtp`nhG+8t`%wWSr%I4v)}oTf zL?Q~{zaGZ=GZ>VNTq7`k_@X~~i2xXxK$;UkPu~?LgGQ&W&It306ZC6? zka9V%&jjO{5?`*WTkJ8~3KcJO_h$P}0m+A_(kZOC!8lGp`8KQxKh?wM9c@26g`r;H zn~1iDerFObGB8OXtoa-l3JV2uuqe{pMLRD-{=v120RVg5bKAIGfOF}{}6ED&D z=T|?2(E_xfW=uZoTMO{r!fEqO@JOYZI-#mX(X`{??DeENIK3xx6a7gmXy?p=sp${+a2@raJONA0a} z%gsu(^J#j;e&eDZ64e_moTPpdizW!(=rHZB#d1~m;_HF+wqNs~*T5QA9XqH10cM-Uo#b4`;%iA?f5jy2(!>Fgm~deQ_1mb1zlX zfuI?H~Q7WD>j{Z8{LL0k>hCp8wFeiDoH=~K=8u5zif?*#YM{C3#MZU&_mdy^5lVG&+svpED$hjK+{q$1hc{K22ZZWnd{xWW z)c(?&Vbb&A<8|ljcTXz;FuHi}+Ve?|NoM}z+;DmJ`l#rveF7m(FSfUUF&R^jmm~^t zQ@XT&0B|h6e6)b<2AE;2%mr$C#cCPyK`bb$9%zW&feKP!8;am6r3!m9OERbN`3HxJ zgwI~Fgi{H5aXa?=fahDR(+b@N4Gi&TwLPiZWsZldFL1ki+K55Rd?>yQc>r4ns(IFb z`I{r%8R@2s;A&>bK#Y+;ue7uX%ZWmyI~|9b8{Nr+WK(la(z? z>nH{z+-!U;!areKi}wF2`Xn0Dz*#d{KdbVryY_ZF!*t?f%q$NTSL5>C4~vkvewH;; zaVM0i7CIjXl)x%P0LG-JuT-b(fB%iOn}+7Dc`Kq{k>tZV$SYu#1t1yu6uv1m@Dr2 z-ad;4==8VI_>S!8v*j-#Ln{1Z;FW(YO{oNR(aM= zTVfDs#Cb0tpRl^t6w$bl$P&t}Dse1(b2ca^+@Z{!16gcF;8m@3<2ljT=uuKOxVf_{ z8UKBjleJ&O0mSpA9qgBB)^OsA+J?|C;GaOq%0iTiMFxw+247}p{;8tDC3<~drxCtq z6layEsof8u1n6O7OXzDvF9BPXBejnw1%7Ak0+`>UU8vc`51`y52TF|Zm&8K7a_B|91^qzb{sC z{&c;G15bD>3|w3J#aEcF`o7;i#9ObkTYoPHXD_zdTfJiFM5wj!z#%!LV_EI*W$lIl=;MLhoc-%7FL3;0QlF8)2oRb$6HXyI*_LyIMoAZhdJXRi8{b0UHnA9 z`IbnQ#Wy|VEQwz3pH=BSnr<@Gkbr@YSl0)|R&;z9<7!vVZbxo_;F_BWU<)~6RmT3D zPuN(PHgL+n;gV5}#GYoXLm-S8G-R}VT^clm@4#9`G*bA5Rk^QG_>rkWg!zGJW#c$_ zayPGDZFW9Z6|Z?bU*pJp2IIiBcFHmBMt3%Tw6$YH+XdE}TSAPXMHgI}Q?n#^_vfZl zmtt*xg+1cA@C#QxQ!H4-Q}Gm5z*tu8`>`DTBWd0?UTqG$09JZw01`M!PQxdQw=x0H zN~kcQG!Vylq50+qkm90N-s{#N%l zhK?d#U=GvmgIuG~aEd2!I>RCs&XH~`XIJ$V21cfpQ* zP4jBvDR=$r?d2FB|NG_TTJ-DV`FOkWjj!?TK4$tGpw$;qD{7~&4jt7{`l(D>q7f*e zvuEB8W-pJFCDoEO1;I|PW?e*!-CNzgtH<2^6&=@GOT)eKkSifqYDaxVLsSX}&^vS8 zp&exv)zK!T2NkBezu&;wdlq^6rqf)OTgO6zTqg!qTb@6CzmXsNZ=1DEv0AJs$f14` z`lI>0rx-&)G%_XVIXCM)EnWKMYu{11aSR1#?N?ol?JiQ_4YT!*Io2euQ=L^ejG0#-l*^!Q6+p(#%zl<6 z7naMO|MYsb>LrWlFysyiyGO*Bcm;CB3uA;h4Ebm*bNGSwt?ddcsl3e^;9 zYFhWGfMme5 z$JchMF0rkI(~b(zn&=9)&8J9JG6Oe{dD2q(2|)i^bEFuQnZA@5@J+uwT5G*nx0onN zHNlCen?5py^Zf-NgS(7cYcy=6dR^TM0(tDl`)cMc-mjn*a@jB?etgi6R_+!flt0Iu zO~^a)&a_vTD-*B|6${7EGb={(O<08c}A!knj9g2tj1SmFc=Ir{1wbFPqi8HS} zM8d{BZ`s|BGl`RdcvCD>~hGkn0eh#L&^vh5X z?rD}B3rPOVv$4ONh2?oD9$TjY6jf`_Jb6xzE?ZSrI{ ztW^vH9Sw9gywHTVJjIC3h3n1{R5Fe@T*HXkbg3TWYP%4+wB(pH$IlG5W0A@Z(fFPZ zZ18L)aCZgGG2$~e5J_!WlqQA#B}%wlsZF-}i&3nUq^+@GRjZ~i=7*~rXKD>3Xu3=< zT|AOxS&-P~Stinjq)Ej-&OMux!E#g;31Lw+!bDbFVT@;()hkd*A!&-!j7cm;@N`25 zv21_oXBF_U2jfy=R(rl&w1`O1-Q=V2f@C#TK{jcdX=cdl+;YKkS$AA+5`lqh8H<6Y ziBk7@846$4)RViw)KRvGvNZ84<}K}aBiN4VEo1{f!WLou3wx;~4NJZ55KQ`P3EV8v zPK#c}YzJfnJA4!6@Hkfy-OZ9Oub4_TEW)^!tth|_2;rP0$RU4vNk_|)vT?D&Sl-Ja zjMpgrUy5o}cUY7zFe`EXfcwdX)eBtmzM&5Jwp8y3(!yGv?YkS+-(V*iYpk6escC^O zE;dxVnMkhJy<9wT>Rn$C#JhiILLJmjfMouj@$~9ezWSe{9-@SUo+MmGJ zRtzh#N9|BNbEcTr+PbQZ+R9bIgvTtF!Hs6UtmU*Cw8#=v71*3V$DS+tn40gs&QaYw zoCF`BWG)!A7N}}e?FBJ1$|3$@$z&)Fe%u_O=J)c|pa{!i^j8T6lnQwX5L@3eIxeDj zwsDHBXUPN>YE)nh(3CQc6~NMKlnG8y;g>x&6g3JBZ{J1kIaw`2vsrjTWClg$;v~dq zua`|r>7_M+iv+qALDtrj1y?y2F@@yeURBEb-f~hly&caB@}B5LqdcaxQ(fPFO#Y41 zO@H-bk^7uJ1U!3@$>Z6h5=ZW1#KhJYqsWQ(7^wVr3997ip zRM~m(F~nNt9UJ^6fLo^X1SXi;is4T#_NwGpZSaAmaIEyzi=wIQ>`l{J=t$>kY8X_$%At(8=&3}R&kDiQaTI~^ z!i3;d(k|$))Zla;Ul`x>PclDu=SJ`f-RfO_;p~ksFZRpY!T~$nnlx74_3G=N&3j)s z85W_DoDIL+MUFR3F+%6cu%1xGwFQ^zC`iZr@r~{YAm>0}anVcfXY^?VNVwtWirZj) zEbD@Qr3Bi0YUJuSvQPlgJF0J%ugAm2JbAai2i#$i*sS(nJo4{9s_o`wEy||Ln@MJOzyj} zM}E-8&WkU_LU}c$6@ue3;?hK#|y3^iARk8176OO|uXdT3|EPKTUMN*XQFH2dp z%R}Z^ZGhScAR1;~Q#7wbMrDUsKxiF0;5qwK;jQ42t^j5L;jT-*1d?Yg)IR5s8S(b( zFcfm+G5*raTz5)o;K<$%ASUk_H@*kxeD%2xZy73i$g+QObobhsrA4z9%Ce2+axn*{ z|5bJ5gFRQDEiIx`XdT187;b5GAF7wz0 zX}DI@eJ)V%LWnWoB?Y^czubQ)3K)imKC-P1kN%kMDb^PY5IXtn&pQE z0lhMGFiC|8Av7k#&oU4)I-5{Li}1fR?8((7+ZqBIQxZEmii4@Y+Z z_apK3J4cy8E4azCYL@brO4h1nES^pfw)$`L=g*wH!Q-Ca4=eQ`$>&@8wzK)Oei#nk zB7@0!R-ZdyOPtdj8%#u91giFqOZX$oO?_cSf9q||lRNxPCvHb*Rw5YWjghWk_Xdh@ z)OgTdz}b^NfZLtHrH(&Bv^6WtI8=-%j7kI~AV6Ax=&kRd?3659E(K)s*z;&^tkSjaRyG1Yb)%0pmlcQF zmS9ZX);cNP_o@M1%E-3k=*R`3w*kL`jL_ zc1X^bi_ZeJQf{|G=6Qj7mK)UK667PF9Im3Jp9Y#z4)Gsuxy%GrDZq2*peFze);+5N zT|gweEluPAUo35o+tM(09VT$@QzRF1!)8^I# zvlKPKrP{O-O-vkdJRa@M(ASq)KAoGo{E8#e4b&Hd=Ka*)BoTzE zX#gJlSunh<@N#b*-(59}Z-6|KG3b_aYbv*%zUsFuJ(y}yTl=PaGnU*_dQ2(4CRY$i zP(tV+S+2^0wou%TR(~9<0Inw9Cr1HLl7^8hr{*6rw`S^d$PPXYr%uf)Xkuy(H8~zz zp=Ccc?$9Ua06fm{ni{_p>bsj}P|m_} zR+l%;#lFg^)K&lwEpCAK%pUd`Pz8>;O@^zl?7cqNo0ke#?EGXplQ^Z{crc29t)Z;# z2vR1WeG0uG{O*VAQL=V*%<}9#y`%0_Y?y?rY4n@OEthIx{D5hlPQrywzUJqK>99YW|C5>K4Sr03I#_>{cH?0BtnIb zz2mw$?7Xa8xA(QY<>TY+`8AmaI`&Z)v5&NJs-@=Gs+I()fkxs>&Hd03Qex zQy|Gi`h$UX89sH_jicv0R-Gi2;xiVNYk%!a7cQ!?%bhzC8uM?r8Tt6~1>mq1jP~Jz zn`rZ%_c7}9TuI4(mKnzOXfxjaz6nmfH9wXj*;@6_@?4JVUXh;He7-0|jgEdn9s_O^ zOGOQTvPk1YB9&b>)7qlv zN{PzC!%LVXk1L!uXAQaUty!oSGNh2=B~RC5xoOPzj&0rJwl8GDo35MlR;CT;NYpFT zV#LX5W%(1G$QKGLkp2<)xBK(KRp-I=!1gn9$D{1;2<<3SMvr!Dri|>}EhIu4tWz58k(e zZw?@3_mO(L^cyKGex*=p34M(x z`RQ?H+2;E1QP0>7qrp0jyJZ}k*|X)ApVAcog3k%d-t`6z;GGUt`2Ee?G=0Q9go z&-S7=cseO9Kx&GwWYg=5TtJ_pjW8@>P0f;?FS=}TA3N~7%C0POpD+xXJdkm}w%X2T zuR<#q(_$#2dr~9(qoT6T^cyjygJbB))kn@VeCAZrD_e)b6-sa?8JMXngc+NDa2W{wE|LIP?^iK-Q@E%looG>Dq0V7n%*hMr{zKwaH-iB;zaS6=PM8@Z;^?;`k0d9 zOv_0nNO6$d!^zU&qHhjQDh=eg5=UCf33-S?gKTgB*=RKcd1`6Pq8rND$2-rT*6wd= zy@9gdpgbv&g`TNITv@XX^v%uL&$zMz#a-6o3V=&m6!C-8=*U-^5m=7o$gpfbM{(pn zmTCsomgJ8jhN$*ii_wq}+!d{^z(1-Yp--kBBe$r|P>n%Ss^^%3y!$*+7a4cVA;jWg zAFhAHn&ME4PQp0G=}-sUI%{P*jVp{|?h#LJh^JLg zaIys=)1H%QW9wUeV#QpGzEv}|zZFZy$t{qKR+yV@d=KDMGXhB>cpdUyk!U_FkYqb6 zk#zML-bkt85aK$^I?Sb2M{%~55yf?iPm>>Z+oF*J=b46!WhnCk6UFUpMTW^euJY$J zG5#CLd2|UmM_8FI77OR`lq3!wp;bqNU7L_7!)fs}A;77TVI{$N@|VAP1*ifB;YvZp zFPfpB)BA5fRklAtyTN@RF?d^KCNp=lkY*-o7$ToQNC*wpVvOTR*yAcGjk6Ef0u%D_ z&36L)ajg3@sA*1ro^vI@=6Ybj)hT!z-6D*WnV!XTPJ1vkX9t6ftg+n3<{dw{q-C4{ zxa6Y(hc%Svh*ofDqgWWB!Af_Drj_g;>xJaNXwC}926yX42C{=bkAVNEdwuIe}wvEY;0pU@ibk@7sJ+ zbCzlU5?iibIMdI%s}G$o9mb_zo-eo6D;k=a-nM`(chjX!_7BKj~Z)Y zz!}csT<3AW)t^c2mPjruJc%=`ZR3-jpD}tl;UjajTl&n~yhdbe)&+vx2h0^u$NHka zV_|fx$Z~&Nr1}+^E>qg5crI8mxGi_!+LjaTMaN~}+qHp12XG%PFkKrGuv*rs`-t7Z zwJpa9^Z`?8+`z4QW)5*_y#t#hS#`C#2rb@KpC3T#v9V4mUXWwm3_EnXmF*qx+*fAv z$l8hR1g~jP+&+98V7UL7WWwM05sA~aH%CBslmolrw^7^_n6Wx_{OBDq5o{UVmg@c5 zSJJ!*D~e~33xnRAVAa*ISi}5!`vP=#*#00TmP>mTVxbNrInH5f(p0W_Ss^O#vzOT$ zFErBN*J8UiG^{nXHXI(qp~XX)p6pC6UcjY+iFwUB(@x2K%vxe4pHI(Q0@5JxXY9(| z&yMgT1>z}`*5~qIu_M0=eV)9v?0NUt2ZTTP zN?Q#^YqqV){LUUiSHsjsegyb*2P@)ou0Ml|uxduR2SyHSt7C@7%eUm4L^LBbCsZF> zpgUTUcG2!5QOJ?`_Q7E>+eGl(EUS9*Hdl7WA8u~&Si}@9w@0O(wj-mvzxaB~^Z z&oz}%NEbX66WkXj`b@O&W&TX*A6J?6xyMAaF|u4v%lD)CGG`G5m3)?wuVqLa zDs)44VQEr?>9)~-z+Te0uAOclSSL%rBxcDRV53;~zULUs*8M)K`Wkjg)KWz&81q(_ zM_U+muMthx5d-tO_5~3zxm)Or+tH50{G-xb8>;66RE!N)E0De&#woNJ0AvynqU&A2^$?U z8Gh~&E*YKVs?qHDu9K$8hFURrDk8ChBcx6z&v?%fgYAVEW3gi~3$HC|ys{*|3W@p3 z1FfwMyE{vWzS$T`nf(Hh-U*~8M($y%T5)+NvlkmOUsvx=9~%s2tH@ zI9&wQ%V&VKf=77Rfc2$NP1qsSUwj8-duRLR3k;VoJwn=KMmq$d+vxRp7rX~x5VP8cBDzEy|RJA~t~wS)k~ZoE!9H=yuQs^|5)Vs3VsUmh%W z-8UB-=yTc}qM~g)M3B`0Sn6L}NcME(JH`jmKHsfDE<*N^?75r`e_kJT2PH?en2J1+ z<1{nxzwNoDdzQiKQ$&Co8d!cT(DOMse$KYA+ltg$V>~Fx?e4xx*zHPOc>uKv=C_6Y zcOV@1xm^=OIQSse^j~vg{8+VLOhf8BJwp>DDBC?^7c4XMZC=dUTfx|qG*k97VCap# z;!hOZ>efwL@BqFKo=uhDbz`#W&K)qoPzG@Xj%KZs`1@OkDno$XHqM8!fieo%dUp%mg%>36VSDOA z<;>3*`=cS&=el)If8R3Ihx~(o-v0l26e18+JoU07QUS zOa>Ic3LGtvO2!p`!R^{ZBDMVHHVs*t^TqL_oeF#xTuNwVUaOdbhnx!Ro*t1LgNzQn zvMHry*W!V5X#Ca5O29VpR+u~L zx$Bs@8eYyWq|mAR2@>5c)HbP#%<_$0DXJt7E%FUs0WfSb;E!6M*#nR;g7045K+_$n zEJAOTYgaX$5>!_O=k0$tLO2h~(r&Q;C=;y`D|49lOuj2HoNhje;cQm951J`5@$tv` z6#JpSH+)C#0}e-5%D;(3v1sU6Q;L4#=tEPg@I91+5q8(ymH~CbU8rDV-66{~kRi<( z&V=3;jCw`-M2TLzZpq%U5XWy%jg)_R54|TzxODAATMj&C zybZGZ!uXRu#EAOqjIfcD0m$*MgLkLfhvk8%bnt=kI9Y(a zZ*;I_GT^*zQ^r@DK)Uh4Z;BI)8G}sxt}57H>~q5$2#B9$e#Cs+P&mq` zEo@UHk-GzHzBM2$=4h;FV1GnXim-o}5@2o++Q^K7{~W6JgEbm(TM?l^(-#!bBim`p z@R<6YBw@rU_`&*~ZUNXSN|msY3=ksuT3v020-(5UjQioYwSKswL9!ZxTirWC;r@0} z1Bq@w-h?{phV`jXre;a-CJvPJ=-9HEg=ZvRw?Avh45mzn-d;^#lq1;Qu~;JmG{z(i zs3lCyHwIbQ>C`V0{h9D%X!1Yr4 zZ2JMfqrOQpLI|*i>Z#P`Nn`n`-jxR942ct;@H9=jCp(`hIfe@^T-MiW?#M4&c9z#L{aw=2s3g0>~UL?4btcQ$3A-$QwUmQ z+6lz#s5!@Yl&=h022v#U2+C3<&~0yB{Gr%6e573TPWi{t|(W8 zuoO}JuIbfRfsSiUsK^{lz9S7w87jUtULR4VLz@yqPiIF}D4pJ2nb+EWBt)5wk=r5zHA-iKzH_cyUKTA600bQ%g%tP&%te+!ji;m}8?b5KbMJEhP zh24Mf?0Ky*Qz-T(Qhn{4&~Z4bZ$pK+&9w2Rocq_54qT4Zk2)kfs)h4o?hx%nPA$?E z>XOo-L6*B)3KVCxEU;Gje8)r#Bge@jR6!zlyhG)5u##;pCk_vd0Nftd+z9}mk=<}$ zWte;x%U8O|QHK?};I-b$T5#C*x^_gqp8AT87t8yKOjC(3>E#|%AR5|pEspa8Os9HJ z$E3aRc0l`YbSm>sF}X*sfv-HI;)#7vcTyZTg75v(U)I6L)xbi5*sU6|4g>)m=k=@b zrd)UQL>!&*+YqfjKKYnuj?L7tDPJgigfJMne(YGwu97@+qT zYcbTjROyjcPOecAQrOL#!QV4KzIm)dSEf{iKQ{bemP+FuBK74K0obX z`rqK2g^SHlq!)eiu(m0NEKD2wsJ21QDD#Ug7Hyu&CR~%Zzmu69 z`ikNlY>mFk*nkz0qRZFIb6|gam>36F(-5@5XAi&oV<+u-IC1% z8)@AD)led0k<43=n-UeNMcImJRnB{`60Y_jNwEn69jYz3S=`t{U|LP{p6L~F;*EH# z^yGq;zV0l#ni8-(J2UZ(j+K3Oe>u>8>3b^qZMmkVM#%V&_GLAGF`uv)AoKn0)$|UOz!;EtYAaXNz zqvs0jii|qUio(}rq7qlwFSZa|@0QmM(Z!tK*J$$&cn`GA20yLZe-?)GD*jZ??-^&; z6t#yqwFNud$`@;Pd-Mx4!&t^f0qM@FQfDx-AZ(##hc{ZAEA(Nhsnx1g&3KJPrh%4J zyU675pP|yLEw4#jV zKHipz3NhVm?Q7QI*>Atlz*KXohM}2G`sgrD9G%|yRfQ>fm{cU598Z2eN1rr%(d&9a zp`tC4pixHkG|Eo^ps^AH@}gCnH4)(@?&ccjO6q0a5)x&&IVvU-t?Jv@6Tm$|rcpRz z*wi*^m98;FvPr5tZ;e&NWtOjr)nuynJNU&F;nl%g-hO)hSChp)=?Q7}olKJ@?WhhG ze3Wi0QS%nJVSA*;tgcA)#)Ve@Ap00@{PF}vRkNi@0S7iwi?DYP6YPj^(49<1fu;n z9hOaG1l+I-m!!6`Vtq3!Y=fua_^nh;R9`3ByIma~g4mvMAg z28jouU6xJ#TC|?+{n=P>}DsHsbM|``pj{-rsrtc>j3eH+$xqnH4j$X4aZDd(ZVP zw8bJ|2Ou+eMl8O0M=DM=oXg^Aya{Z!DS|s??6Z)k9c10G$5owt9NAm#xbPj5nWyAw zqm9=y>JVRq+00!6&dBt2Gn}bC`{HN;RHu+!O~fR3LE#yTjQVl+Fo|tuwGf&f6h>;? z!wh(jkPr3PK0>7!<&;6* zq9LG((UH`|A-u)gOcCvivW(QHdWG3t<2-xAE@fC=%{|&{^G>r0ci5biqjXrdOc{BY z@kBz1Grk+F#!L!tisGPHz{vnoXG6rwND+bNTErxKn~p4IygGF3)dotGd^cZTKQ#@q zFqJDJKZ=dyE4;^6$}#>HS~+I-ll`^i@LFplO9>o|Z>tv(q%HH#N4~4W6pSH^lp3O? zDy5Nat+J(1fRJOyV}0UZsD8&<`)%XuDOK#$u8s0{>IWfcE6hB>sY08Yd_e~ejwoNLD(Q>4>!b1- zKChdie2p{VPb;dkhE8rh8fW3=Q{QKM_svSo{opaqp+{^YYmV8L@!(?zG6+ppRFVN+ znc2e@3K7wd?4N1M)x14)O7XGpnj%GG6-HaImCfN;_2HbGhxAuaKbxh-vt@DrAj>B? zMy_f=uON5#lS~%@-wMfVLhcyHehnLb?9 zVimdj((q%nRZX<%;8Dz7h-uX>r72S1LgncwJzv<@SU!Osh^>jgp5y@Retu(fy}gF9 zpT*sxu7}6=3~wZfimvABzOB1XYxGfoY?{|I2C;V#cU@L%A~NL3bhA16E25YWN}?** zy8QTq+smaj23}*a9W4eON;n8ubU&hfR-JSqJv=n2D;x|-BIdYAM2HL8n)UKpl6;}{ zUCto_Jd*lIBwurf9HklA%F`y49^S=>QkXY%N}|EMFDLyevf0kj0@qSkN#QKTe@jq${X%PG>Ro!i;Q7w9g^F%uY!w& z{EgbLvqEK~?_^I)$q0#>Blup?OIekV+gPjurPY&;REDny5?&s-ZW{RJP^~aHBhe4PA-P_3(vsImyrv0>TmJAl z0FzPeb$_F)h!ww-jYz}uY>o<(Xpf4~sa1L1l6QQgwk`cs4zUWIoR%M8Pj?+nh?^c4 z)L80r5WN;qi7z_I7S&Z{p^1kfGP+;wB5ArZTUfTDNZsmkYYbAN!0eUh{zJM#<#AN# zN797XodE3?ojj^|!74`gEO-;kEYyzBB~*DtdjOV@4?u1k<{zz}}pSg!sk4_h88 zfYvjNLi;o(^@t}>LT@JxFTUfGwWz>#$YwT!LV>D6Zt;4PGw(t=_ z8!YIru4!ViLvK1s-lh*Df1)61@v2W4rS@w_l$@`nL zmLmfOvY$~t77jELgqJQyEC^k#ip^Qq(jYhdu5+MfU=eL9u2mhf>+`wsMe!i632`pf z2fu(*UtKSPh>WTJ2o-apdxcEyHQtDOt}k<9%luapT4(%-S{@U0$}X;l*q~b$Z*r_0 z8KJrf*|J?FVqn{Y$ZCmZ8T~pRDSu6TY|RV(=9mP0QFck@BPF&7^H! z5qNVVLVV9J$D7;Hx}I=AblH6Pi_n)fP9xE;Uw;J6X1+S?JSrARk_+^DN$7VybGY;g zw8-~{WkL6r)@oXG)xPwdrq{h~^0L+86~`GmZ=Z;`KdF2Q8~XNM)g9-lt?WN+w9rg+yUNH&-83Ur{8EKmJf0!{?(ZApnE z{|{mkR&hO~qi>@RgTW+YU$u9syL4ye z?o06L;I+*O$%F=Dg>qcgL&K5lmLSH;rEn(roT1eA{!|p5ujaK&hbd_u{nGWD*A|?C z@7jvDj#+Ms`?=qiE~dXnRGUE+nZtC>c8a{u{Z&jL4i*<+Rz%Wl`abOWP-n^QLKtKD z=u^DcD-hM#2QU)taME;9oYUJ;<3l_;RF%Z<^p)iV?~VEQ|Gs(uSwsQ*<4A#>!y_=iT^h4=&mcXUa$DLqi^y%Y zs%TYGf~#=sg-Gr#i4HXnB(-ay$9227E*?hmve}GdIgK50la0}KSX|U+{1}9ok!9)k ztlo;&cZ$`t4pD}Fyy=(dhMPE-BI1L1{zagW=j~d>fef~vL?pIy(!fI{7S(0`^|&DH z>bPu~fk-62fP0gez$H8(VkE-|Py4#gXv?LAwuf6o0+*@FF@}la2-9#-AKiN&SgO~a zESuP-G!v+jlX`m%n^tvgrDv)AtH9=4VxxCdH?rE9k`Fhu6Rh3p+P|?rUhTATVIW() z#*pe`?7l&BvSG2-^3i*{cfk6Se9I=<`{dx_y#6DV<~zRo&l5Zo_!IHde5r zdHU-xmCG>L*J8+wrV8C58dch~l{UZd*cqlePXUVLCMbD^i z#qJPGu#y(vs{@%M_;6pZMsR6YwN~Kc_qB|7A13G+=jZ5rcpOEf>KunQ&X)I_hv%)8 zlkAEYb=xNi@s!Do(tDuq}JGMG#=pn>SL!+ zMF5eKu_oXJwwQla_9A6F`(%j~k*c4KHJk294K1OW-asg24$X^2tvCvX2D@aZgD6Fe zw~=H$x!R=HBHs-s;|XP23%3|hVNOqc4Gt1soN&}-$I;C_yH8l2a03zY&T!)S)9XH= z!ixCL_&=~mmFFg(Q^~ks?NrLtey!?`EUIb{pu`KWfvBg=wY0puKIYa^Rw|H6@dB$n z#d7``Q}_^;sKR{t`cUeAByzHQsO* zJXP8omb_)NhatBaCiv(TYrxQkz$>12u=H%Nq4`yjboGt9SC6WM#KW(W6=cIv}$Sr5sBxfKlNaW_)*UQ9jwtnQaR zDvFAvtV8O^^ZZ%@chHmX$G(kqGO>#m+DWOVo0VvddBW5y^%JbuOqB?jqXqc9EJ(IH zP$muRtlw~OQe7=XhswS%=DfSDtJlk;+Cz4CUoSto()ZpcCElJ{X&eJ<)G|Nv!ku)Y zefnX|plJrPDa>xUZav)I3RZ{YH%A<=KWCk`DOyC>DR%tk*8)@}y)hgLH( zV(#IF&r#;y5-mnV&*s!y9JkGCdTgD(b=)SF{`Oahv|0^u4-{gK74Tcppc1Tc)S^3t zoD;Zwgl>z5P#L+R6-G|z(GKl^*ruXTo&r?i zu=%X6=8U@OmXS<&rm}sQGW(ita-xBOlTe2IB-?AJY45lMvuanhd--5p%f4K zGJ*nRGEZbGBnq~WBf!OJ(zI;-hiIv5RQsa^&?kG*MJpKpw1Hr`15N+DYi?Zy^L^TNL5dP22T^VhGP`0Q?J>?c(sCjR6Cb@< z=$|r+=cWpdVSpl0y+{AljO~M3?dCBR+Wy`o+lKgbmtmG8WRIXXw!u8+K&YG3Z+X_B z5?#Ai^0DG^8`Jx6MK-x^!dP5xQr)c)Ji!nrvN~izCCS}KwpM7cN3%5A?4P{6m5Opf~4d$z_=w?;FgN5DDi_>o+=6L?H zNpb7Ml#6Ds@B#bXNKKY5a<^p_gv5qO3fsb~=H+w-y!Q^P1zp8*hhk;;I;l*tiB!H! zYB5W_t-yQwhA-T)4K0d=EOJ@LFa1fUyD}vF^Rv)T`Ck^R?xb*rIcx>OwGA;t*wmCtVeA~fB<6<{oRe7hFsJ!ERbE`B ztj@v~bziyfK*)NYpBkFa*Wi~jbbQd`y}Kum86kUT(60gw-F>cMU4~`C*nFk_lbDYL z3bIi%7aj{+kqD(f#|INR(dCH@6`QdIVs6Ax_KA}5l_%sawUp-NAFPfV-^kX^#*w7$ z2#vrj+7h&ui&WOFBb>Tl*WGt8bgPi*%M$zud>K~UR+2qVSGl^HIgm=X=|;a-XT)AR zcNJH%)5O|}{rb1fn3vi9>BlxF+07LA8qsIhU$4p?^)e0TXH^#7#8b)GYHSf|n)>WX zUJUEH6@dTXR!j&3J_&LGVns_#7WSM&`&c)uQN2iz91Cir05j&lmx{S@O@-J+DsZ0l zEMEkR@hmmghGv*EZ)R`Hsz|H(Q40s8!1n$O#$>!7b{bS#Z{3XN%Ww%MVc0}nLTFJZ zL)mlP?fCJ*y9f%QYwWn&D zNGuU}KTr4c=9ta5kBo0bsOLlWXI1T9`$%)|bAabA_Sd?BAeKU^kAz4g4{u7Be#kKR z@Fo3VTqR_= zwL#Cr4+F&(qg6Hx@7}UsxxTCAr=%;O(QX~=z7!MMcK_qqk?>oc*=iwsj+VQuMWuM+ ziqFu-c8YM?DAM=zrmu9oH@#)A@muE((^l+z zC8Uw>LV`xL8mFS>mj@f5=a^TDgx(td%}tl!os2(kQM|nAQqBdq;1UAW_OkGV-+T$) zf5{DG$l1AjcuL!vyHf*~Mna$}=0BgffqNbyP<=ZqPg@UaV`?5jA!;7r&PF~#VQPLM zK59PTHy?uB!qkF1!qhx`T-3aLeDH8t4%P+pz?esfo0^{&AO?Q?rvL{4fIuRbftQDu zS{NV<5#RwXj^qV`kPx*XKUj(Pf)juPL17+hUapHEz$XAFB+LiY1E>q}^1|yvzy!RI zhnrdeWFJHVyyFn8C?F_E%@16E2@>EH|ysS z0|J#Y_kh924l1vpDx;>%CU58HsBP}-!6D`1Xr<_B?r3KT4kIwUGQi7<-R)dGUEHY! zf8I$7UatvrwgP2=U+A9;1rHA>Bfo@#7q}M`41B;q^8;6R^79H(3keAW!vpjlATXEZ zykMsR;Zee+ZX|_yvCw0%AU3T)DY`ae)YO0auj*@4f^}1%UfV z;k5u(KsLZKIEy^MwWYu{qToOZ0qlVF;LiXI1fCGS;0J62yb!1$4Dc!dN(KN322cWi z1;Gnsyuh8Y5D+ULFv5HQ6?htm;Z(s<2N3cIUo;*p13N(w2w*wh2tnZ5YGqypy*9-ekKFj+@CPZ)gh{+ng{;xc7GXS?V++W|@e256=WgujUs{~M9jb~JbPgjoSH@>hccTrRbM{NE(^=RN7a%LsVW_&;1!|7wH$)XAW> z5&&ifsJr220ceQ8jSwK_1p=rt!3w_=H~wFR1*a2ACZXLD2gAsnvhQ zfTaW?1Px9wfE-*tgRwARGF_HI1cA!n0~{Dg|Nabb%kNl0OqcBfSpgdk0eSm7{x8Xb zWqTl06%^Ym(?#(TmbzJ`sW&d(+CjVAK(|X{xp4{|H%fCmyu*sfH``@ zJnbyaIiwuTEgk-K{s4v`eE$4CSwO=7bg}?9`u}Eu@Br2>4`532@&P6$VAz5|5ZGu5 z00Ybo3@R^>h6iq-3>bW{J}NkAKVUu zhylYM*nshaI~`!x1@Fkq80ZsFn*K)6eiyR;oc=Wme^eEOzm@@f27CW9z8uDjJdn@J zv4LDBey{!qx{KV)Iv4quH7}liYXlE4g#YcVkYSTIcQz#s?)Add$aZ9Y)mfWQwt!$ky$d4alcn4fuo zT>Sz3@6sRu7=AAYiGsu+0zkoK05jleun^!t2q@zNIr&)`L?8rk1Xn*G9FV@yML;D` zK*1>j0)j|{ecQ0GvH~kGT82)+<*Y!o)@%)z&;ZK z>jE*{G6Krr)((gbKG}c_kUGeX5C{ZT2A_fWlJaE?A_M<_ld6l1|Mv6ODEt8kcICzY zB^59Rxd7vfJdn@JC&*>uqUf^9pOIYF`7`2+C-{c`znu_Le@uw~$+rXFA_Jz@@2Ubc z;r`)#;0Ai*_xS)AG;lKmSa>hJ4RGHMu#R#I1B>*fss+>r=%<6%1@gcc3?R(^k#FZ0 z0D$Du;Rgb9a{&wPFS7*H6JWSBLoQ7vI4MBdz?&e1*Pd9O$ay#|E(ZO|6#BEjivH)kNUg#ftLP16u-Zk^}uQYF1zs6 z;b#ZImt!E!0|Z`h1p&j))dcjlg3A&Z!rRcK=`@`A_9QHRrQbM z7{Cl>z$^SrgU=vE_+kiB1y&N!SQP}r&(#G2PXG^a%>l$) z8OR5bgTP?fWehg!A4?w`!DY{1-~&JZSdK5LfH6oNj4$$je}Y_QUld(dxkPx8ds*iq z_p;{2({ED<6so@>xS;)C&Jy{*+An`IReo-Yf1fJ&lY@Yuyuo9j zGDsDi8X$LY0r^=5riFjzgLT2V2)A6osQ?DBv*1X87@Sjo7LNaLOd~HZ`)5`Duc85H z(0?&%|K@;3!Q9c>)5RHd+g&EXgF9+KGeWfhKMZgRb>ViAcZb28fqwe=DCG$F{{(;1 zfXcg@`vIN(vrO90-1!ecRp1SH&YtFffEvOa9bJ6>0KV9;{(`>r5?*HfF57?OGQZ^d zuML17J-Wl(ykO3je$?E+VHgA|>1^W&qXxA;RNK|XQ_joT($mhxnHs9);^hqZoPHw( zZ|Gk%&VNq|PW3;M`WwIIe@_Y!um9YrzwwU!_mqI0*#7~kf8$&D?FbPV4-ZT5t%w3b zpaWUj+*JVvZqt4~gEhfY4j$lO3~&cJn%j5)%7X{gU>Dv&DJd6U;N+Nt8`vjv@Bjy` z++4uER2Udva591ZLp5_J;2n(r14c%ZEf^Q2~mYC}Dt=1^y-71SN-0rhY-w}e4;pq5Yvs5I0ODg%{->akpKBWLFb z1Dp;2>Tic<{S-Ffyxh?f<_^4C(GhUA%fR41`pY*Ja`OOAhrb-LOH+el>*47RGk1bu zD8x7>1*>T56Z9=OH0eit!>k-3q1*|OeuhBU_x2?0UjL{LL2x0C$yAZfX81{=iLvq3 zV5CviNbyhvEN%)9G6f_8x=q&`kG|4v%RCx;<~Z=6)q>Ll?`+!YS5whSkK|$| z?n$%l`OlqC$(Z$#*gj~ZR3_Rag$#Z(<|QA-(;v%}dcY?vE~%6u_8r+ns7N%fw(uCC z&%PzuWcl;dWYd$O<-n-HE!Sz$&v&g9mC|6ql>uJLdM&eiM`h*a!deCobXHRx69?Oh z6e_)@uhBmk)HAzn<58JH?xH9h;cfTq@zfHF+su>r;5^y;7Iubua!2PTG3FDUJ={Yw zsTspOyrk>8kr{nFhU~S;<~95(b=w$^&Fh8&t)U)qsupRr##6?biq~_Cj6bI6jn32u z;cAkjY9p8`e1!~mh1=)Omx}VuX*$wedoVx{>}x^8^~f{=2_b?nWII^`@@1^__(;T# zDTm=J?V3c@l^2PK{+~tZ?WI3T4V>PItM@JqQEkL2Hb>_SC3!2o*U<3ACkTqtp;Cj- zGxrp&Br5=smhyeL-D0C_QNeCqe`mgZo)V{qUQ=NgwLtRAtlUCeUj=g-1+%-lT*8Dk z2YKls$y9j{h0?=s#1H9oW8zw}OzP+3S*0BC(_@ul!d#d$_YDNjC5l2`ezhZEDM0pi zk;AL4F?-Lmll^>;e8oSW_Jr7_nG%g_Z4YrY`r*A6vfu|>V)NeX#~gh#lys;?A^J@P z7Ef8)?WG6Gs+J^;B9lW@w4Gs}-e_VLoLYn!2JXVv8uk1N87&ZcWxEdxV~f}h zk?s*J>sY#!#7unAdf{YBf>7okOh6xIXs1_m@@@C@z24Pw>tz{o==GY1rdb~QRzBMD z55~;qt?8&Wq$%!)AD)W1FEJV#e6SY}*rSdQOH-D04nVeD6pQZBG!2T1ZLO-%s0e&y z>GzuTs!je?!|ae#C=1SPK-J4&9ml)eJuiBioa(s*_xmSYP&iLp+uNG$b8R>6=jM<1 znAYf;Lb)^#DULh!a(`6E?&|t?PipDTCAf)kAMedA&adH)-XQE-B8fk-WE>LuG);N# zhbxbI@*(S0xxh7#1yS!$pP$Tjq{ZAyvxik-dw-qMTMOdg`vFnL_+pqB)qz;LNy8Oq zfuhra@DRO7D-iv5`HZ3vJEpI+-Oc9|uj)pRpDH1uTEC&8{UENeBJ2z)0l0Pd z+c8J%57NO;RPTUGr<|xfJ)d8rqMR~#TR`bcTA*0GJH0_L&v{%?9b?`blTsGcBJo)K z>d0gi8A8d>y0QK$e=8?Rq{_!MHDbu5c1Ly=S?#mBxs0^Q))D79t{8$~KZ`+PDc8Jn zkuff$>nbM&iMYX7u%?!7ol6xVtH0xsx$eVKGQ{9uL!*^)-o=%Daz@O6>An8>}1K z{bicOli!8tdTA_h;h}sfQGOhMHLm@r)LDlMudpQVb}?|HGT961;yZKCVu#N8ubjUM zF#FeUECHJMZ+DP?tB-_14fmTq0{os3;PmoR9|4>BOML`5j{l;Ifc-ZI58x)|<^ilD zA;1dz7hUx4zB2G9O$4WLp^D(z@s}n743kSubfGqXDI#e=4LL$#m#PS^h@7ByfO@io zxUwThPptlp{~Gp6$pSSYokdrz8&R2y3Q4u07ndKI6p8 z{;oC6nskU(iq!RLQ<|jVJ1>lYD}uf=>fR-w?8=~z6v8pRAKrktq>Qto*!6&(F{y_= z(m)MQ6Dfg#0C_ANk%smqK3nu78Gg6aW11{-g(&8zt7G0{vhpv-HoxL<$h=O*ufKak zgxOW&b>4*?^w?p16OM%pNxF!dH9fK+M-lQ|MY3TLzDpI8mady)g|u% zvALi)gZMMk#)lG~anz*k-978_6M_3D4GyQ+i@LM}BGIltW^z$S`nuJt+VDou7sKfL zTV!LV9)zB{pxhenYzel{H0gZeB9UU}wXH77G*Wl7Z=Xr2M+jM&IyXH3eE}!CIeSq~ zvA)>OGWGy1Eg$aKTGlHbh9{)c86rv9U8#4TOi|-1OZw%sqEHk#GDz~4MFVVr>anOwt<__QE>SVnpt|xDgk{ZKDi6alo(nx1~ zTE^8rWH8_rO45l{MlM1vylUwQ=9jeR2EqxV2Hqfs@LPv*i-$=XV*eb1nE} z8Q0de?3RYmWA6tZaiOn#}vT^rHAR_OF`iQASc77~dCll_b zZmxQKoIo1sdv_L)rBGP+J|B;3+;+t< z2XQNzO;YbdgTsvl<^3r9Q^lhCYDaa{YdNa52VD2>chs&gF<0Cs*4B6-(qf^X5I+Av zf12J(s~W%P>`DU-LCd3_eUB-HF}cv=v4teHnZg{-htEZPhY;if1PyyD(~z>HM%|_< z14Zkx=Vje=6dZk%#dqX6R9P$V{7GXQT^2{sgtl)zGsj;RytF4|!gC)FtW zbbvEK1O)?0H5rr5G{8AdIfCMGwIz~0_KBJ2n1QLsBf?jW%U_Ba`r>e$3$B|bgp`(S zJ-1YOJ3BOOemzfRRqal)ZE@fE#D-u2;}*y12&2}>WXxCeF7CGaeNVP~r})p=F|exI zD2B==nl~SQXZb*F*XZ7^(%-XiJ7K_Y$%U7(SI)X}nb^=n5Tywx{4&8uo^$q|V0K2YN=5 ziR5tOUK6s3<4$EA_MxlG1i^4_7s~0~P@@)uY3Qz#Vu0KkQm(EvPUHRZo?&v%;!QFa zkx)zTnN0gHv$~aH2X-!sgh5fxOAihii!e!K76$c4IM1?ssnj3E%9016j)d=;O!awm z*_0RgKecOR8Ph`dMN%qn%{~yj_9oX96&ovcaT)WWzjr-VJ4^n)n0Q?vCsWmo`SN#m z`rt1NODR&(63243cUG@yUi)NeXhp5hHiQ^eF`bOzQIdK?-xRiGGg~tDuIqN6`P^P( z=osTszH4xoIaQk_45)Phah~IC<-V^qWc#W$kH>*cE zopv2Rw@Nu~qq_Z*7!3ojAEJ@ul6|@4SA}I#PqFrInLUvUYOu}Gt+G`^6t(OUm!&7V zMz!A?#JIMc9dX~InR2CXwIGoBlVK1hken<+w7q6xYw?=Vi?-5-8ZkdGj-)37Kj5zV zL_P&ooVi!<80N4teLQrxH85;Uqkl~QX;=Fg6-zUB(7n+B^%?7rlk7h_$cXQub7Tc% zJh$qB(%V*X-Gt1PR*ujtb1!M* zi44{ho5e#0?2ZlGipVkji46qCI}sEqiizxqi7U26=iL1wneId^r}`EXQO}OX)nd3N zA*VvTepMR`Zr@54l%)ioO81CRz{dHxNx3T)PW@d^w&>&ihTdQ6QuCQ=J}L{Uyq0OR z$ijP|vl~GHh3>YGYULOo&9K&X9H;2J^?HiGmi}IQ-iznDmP_4y-tHx9PNkEHcbjf% zW$oU_*3@KFFAu)+Rnb;UmWJuD4d#sCTUVTN!}r8BNZF{?;u->Jsqy%p5DR4q^p_&~ z@cNYkZ^9z*cr%5~Fu#X{#^nB*`0gzYvhXme158mokp}3VlMBo1 z@?}@%I?+mlJ)(!#ZSPl9HP33v^i`qBQV?cW!OFX; zLL{ys&@K_V)1jx?Hdf(CAj(MLQPa%TX>{1jVoW?w*ouAZkQQe+H{m3CW9t5%Xz_QR zoi?Tr;tHy7{7HVfv-{_w=N}U|=uTb)Wg0l@;LW6?a^Os?-`6``eRicR{X?KZCyNWs zsQdjT6mHv+CikVpz(IYTunDXEZ?#TT%Mqv*$zz#_;o?l{GV!kS=|uQ#tS6n=(yDZw zI%O)fF`oV3J3eBvUn$60r|jVF2qt>YW$*| z(bcmI+jL)GDUzP{Hmyohyy^Sq*@M^Lbs~W;DQp+aT)j%Xf7T~OhkkIfc<0*ko`F#^ zRmCT{rkfc&Z_=ckU%X6Uw`?WfJvN)lSfM8jHoh@L!yxhYDzSfLNoK6$#4{<`(CaIt zv2`+S6(JO5lGY!BXf_fD^XNS5VZbjW(%xQge~0>E-j$?VsCRW)k(fC~ok~43PKyug z>(dpH#e+TJiDBx+hdu*T9awQEBQHeevE@FSIHcsUl+(~Teve!wFxTZYul361*M>De zp0Sjjmc5>NN<%;zbMiHzTsoc0@v~9oyLWoe_!W~m)s$*tjBVfPEsx!AN(_1QxWx@? zMJQ_JK>W^DtL+5un2HWES>?lfpFba42Y%IY&F0qO}l(?hr)hMB;|JeLa`4(2i zX0ZwrFM(;h`pl4Cg&UXI>OG+#n#fkU`N*W*UwJb5!1D@?@M zBJ`#dk_|n1SzF zl~x(lF4iAb#N_^?#$-*CY?Lvgma-gl2FuKyXaQ4}%UCVhi&42Tjf1ESRFa}I7DDt= zPhDgab}T&98ZZ*@J}s$p-5>6sKc##zd`nBw_*oR^l9dkW+6#gTzbnYqtJb@HG&e=Y z@DlLoip2#djX&L@8Hw%DjsD`vhnt>~5gR0#%9cM(AsFIA-ioe#@+FGKyQVuk_0$2H z{2__69)kA4cDc#1dcr?u%jUu6LxF^9YgQH1!<#*o{jza_kK%T+zG0Z|@U7e>uE)Cg;y$Lc^M}QH4?`It;H@i zlfH_fw`@{q;Q_NrvgK)KUMlS=0x{zeDnoHVt-DPraB zeAPE^8at1v$8>g_dYlarf=DkmcRAQ^d21(5YH2^VuzEWtifPKimQcU}&LSUnQxkf&l40TUm3;;B zkrc{2IZ|>MIruhDOo?7%+$34a*u(j#HS}saGCG-D~l7A6NDQk zwM4$8>|(Qt;1$>utsU(o>npz6`qV-%nX7Yh;?ZUaQ5|z-X~Mp9jIyuN;BHcH6;t1r z0<{7S-I7;$h3{4~m-MHu!@8*|X6{R~U?@gvye+v&-60sv>(6#%AQ@qL+k%-N&8_ts zE@D7i)bK!F=cc;vgE={m_moY@E6`Vg3Q_k?6D8C}2MRx)1-~#CxK;}Zm&2z_kShg# zAs4qrd%)Dc{QTx}>w9NGO{)mmv>7S>w^^CCJk>X6uYWH-INR?-=S_+!P|k+NJrI!B zrU?$zuPk7zjbW8GZn;;Jtkiw~P2bo|$s?IfbGz7N+R6SnHKxTdPW7UJ(>f!+K4P2U zJ7b(ykGjl8#a_Bc^!b|5%}TyPJ9#vd{QyflW=C+~iKniBrt##No0zT#5AQdmvrl}v z3TYqwnQ~~~(94s_>SRh~swI7}sI5a5HG4RX#{D7VQvqL$3OfNm8!fWw&R8bhlGI-G zU}E)<`9^p5Fw@nD`7V?PUgE3L(LSBW7Wxmxa18MCpa4820Djj6p1N^!0pFMSSI^A9`xgE0u9-{!iym-T2vGXvnBo58hyY&j z#|eQG;2W|0lXJ!uaKm^44jEg(En@??X#AlzfcqYB`~N&Y&;lGbjxY}os660i(Sdq6 zf)1Bk5YSm;?c(JQ_-VXhP!BubOHYmh;FbXn@c@sEql+`t)5its4|8_`oI1*YbLPTL zqYd?dc?13%Pg{4`EeH&7*hpWxbo`(yfEPy*ss_~qJUHG^XFC9u5mXmy2>6P8pymLl zFel*00w8YSK+W6{stIuL=R=L3-`@ZI1nsxe#{b#PBgFk54>iJdg8?@WQH~-{5*m%f z@>jY9ObkL3*^0X;G7?7BjwksjGRcH2F&%etuBKc;ppA_!K_ejGn(C^lr0%lNExAhp zTt8J`@Qx~^(ObRz`Q9Pnc0aeH<;|Ic4pf$pH#7VW>9UK)W6&%KTCC-td1`nVwbkov$${C zun6%(OAJOs4UkgAhPXG+Gqv(qnNlrJBNWC z1RKe+#l*!nE{#U*e)M+Y7@1nx7ql{j8a`VLo-Aily9}mu0x?e&$r<*Q%IF_3Rc7&- z5nDG5?$x~a_>TOU^mF&Pf?a*ssQEqVN9;Q9)|tIjyhK0LO_k2r^-nJ}4WFR;JwL7M zlEp18(U{BFy*bV0cZ+crSzBQWQX8&uBkdV^i^pN=k)xcxl$M;Fmc6px>>aN=Kkg?w z1u*c~t}CF0U`H^cWs+hAmkPqoV$A(XP8%z}CpeP3(CFmXZzKP;&CFuCI2gk6-(;%Q9W5 zcMHlnr`cSoqV+t;*sqQClZLA2&Yf+~?@O<|-(|+WuRDnDR(b}pq*5QeLn2@hZcEso zp3H?|GsdLWp@sIu|A+t5jMy6fJ-@LdQCgN@|*$+a)}f~^7!M9ycAZ-@wr(5c#0un4(* zv-(m@xcv?PweIV(rz1U45mm2aSXs+Tm@Vj>JagQtXOLnT@ussP`YBI%3?6*!dCc{R za%l7Jf-IlPo27`sXIW71gq{v$Y-|ql)xaFF)j)|6!DPfi<*q)x(|L=#;-p{Ls&m9M zT#u7GO^&_iBqn}5Y1yvWo|XJyp}){SO_u0zUEtXXck;6@Qf|2zMPZx9W|GeiP`u41 zcPo*JF^+7>_Jpwl{Ukz>ulsf2gp*|ZO+ldD=t|jWwYE{+8A3uEoNq$qKR;LHmQDB6J%I=z4>(Dkb;mf~By!a=#wcxvItc7=15w z;3JoecIj4@vZNdD!Veu0a-T!+YJDfFl#cib@_k45;W65L6k2qj_Z$y9dUjMqI>~30 ztCOEJ1i8H*RR#B5UrOS;bbC;Ak+E7&{gh z&6`3xD-iSx^P&7Y>%EUMS$f_V6sw9lIwW|bVvcXgg?9gOid3?2zGVgHRP0xw*(js^%W?!H z>UUuHZ_Tn*^EK10SrnJHHKp*^z5TGObI<4Q=|0yWBGMGa)654e)ljS}GuMjdshrMs z9f+c&kns&0`MGsr>`oOf4$Z*Li2~_H*aB1u2U@6+(iJhHp(qgtC*dMtJ_fm3Zbs1? zty`34%*^=#+|nnu=5)mJmJBjnzKCb)wok0qf;3)c9k;4dO7@16r>4_%YME)qOJg1L zbn^{uVx9+$&XBaT63tF(P4Om|ZtYg?oZMymCiUs~Gt6{tN4T9xFCifR$%}UN6RzsX z+m##-ILDpe={u!1%g5eM*3t{}eTRjSnlGlZw#6%dL+8w$>Fn^BiP|V$xN4iBe0V|>8UX!8h*<%!PDc4rK z@2K+TQXeFXdwJxCA3=qmA~2xsgm|9s$`Z*JX_w-qo=K< zygvEE=3pb4*Ge|Ib!KPpoXxzI-YKf0h9GZXiA=XMzjQUf_V*#9#e71xJ8}#-WC_Za z=5~sC*X1Qi8+|kLxhz<`Lnoffg<+$<$Ucol-otvCPPoF1_1^5}{6lwkqh2zNdV-B* zKe{PY1eb*m+dDRrcT&11jMCdo9EFmz+f^$CThkge*F=Jm3d|6vOd1DR*G~rt+76h% zH`v>|I2i8arhG{G!0)s@^-aHb!!>V(DWM1R`%ss_>?TPqk!{_>LA$S?_q&Ckwrh5h zM0wO(8bo~wb&e14GA1}6Q_qZ$Xv-9ue}}MJDeI0E@EGCXhZp+UwS$uS4)sB%<1hlZ zH#FKXONh+!shy?~mwTLTHfEnZ%G3KM{#-%f-P1G1o>#on8-!X75F*EJcdlpUkFkq> zVWsP|p|7*WcD&zD&_emD7lGfjXQN2yTiV(}#*#c`hr{zCNEzT*;9+$qatlZwN+Acdk+Yi_e z+7H6^k5PFMmxT8mEv~R<7U3Iy%uUJHLWHk-NI|)lDn(~uesPK z=0_oRK|$%rjKiM57>lbDlO#(pEeW1uvbBveC#SQn)9#LrJvEE)Ocgc=`Ygc^(4xz~5L78% za5C{7-4)Yn?~#4;XS6q?Rd-M}8eF^*Z~GqSqYbrRy}f-EOOjm8xXcW(OrN0f@tg3@ zCu28{JhIxcuJ#P(KnDg zuOg-)-E*sStgc2vwCz)BaS%1pr;*Smy)(pO;~l7N*L{!U@osL?&J4{DO-bWQZAII&!}jIwC?% zG9K!{UPZF(X&|l??1lO0?U%GxmRh7QeWByp3b@r111xz61mv3m$OI+3j86U)rqJJ_26bjyx*g6<8XvNuUvZbTy{pleujsft={6pu81E z+90Y722sIv1SgV@*aC~<8q(1S7)c{X%#?>X>Y^kfEqk#i*tDB6{t`-EM8|JN?Vp7Q zW+hDycDmz1wtR4R3UwP-WVM06IiX~Uao)v@I%R96yeqlSJA^u0<-goRqoJjM9uk?| z`>uB5#L_mV{`=jj>XbS5Llm!dDN9qj+1#4xEPZX|H)3D>>F>y-LFZ3&3zJej^nKMg zK0WRgY{J5?ALo4+2EiI=pYwgT*qYkzZ6NwK^(0|VcOSiDGWVu=No%0=T4zvE-M3qk zh~Mivrw88I91cB%L@7_SdcF4S#7W@t?|A?NcLiV@m<}mcE$4{rsDyf(Y^R| zt}4Svx6^N@d+e@EZO^zspP3!LXUki{{%A_gdtRw1B5*+Gb3N#37&*I`&rS2UcPP>4 zcjKR!JdOG>&;M4FbYs{?2KUkGe9@3x0fYUR=G+2@_0(g<{v#&&JduF=DGi5on%mbu zowZ?o9@PA{dQ&>Br&Ov9-F$;}AL}OJx7#_DZv#zUz1iE0KvyAJH)r`s86LMUEis%d z5NK&ilEauw7cu8RY1q9FOFX-mUk#1>R5Il*(3^D4_974?dMJ2vL`>-1Jd;h*XDWWKIE# z6+kx&LyldUB3hzDGUW*#CoKtk-Rw?rR*N!k_GWr}Q+jN74r;RDpFRDSywfF4yI01r zcP*&=eeYPitw3Ly0E&_7Rpr<31-V`jY*H?iO_SF!;CFw9ZA|K|+8o+^!GpHUnoct2 z&X^8=L8Cv@3ZpwFU7^6O^PK*+ZT#V$mtaq`ggPfNg(auS+{#M4N>b{fXBO=!W9^y6 z`vulm%=Eq^9(()D_aRp&d0oe;ZsBZj&BIi5TN+WC;P>Zm-Pp$I48F5h zjy!(<*n!Gka)){5|D)_3qa%OU?C*5!q{EJFr#rSgwr$(CZQHi(q+{E*)zMS^JLk+f zGjryd`PZs9Rjbzh?ymLS*Z%B%;hGg7tNc_h7whX+n90>OoKZ9$6Dw<(8J}Rx(W$`) zIj|;x^@Qvdh6?pN17dPOAjNklRnLnM+3_^ z98M*rSl8&DXogE-rO>CKON1g%CY4D;X-rpCsTBF$kM+98&jA^w4o*?G*;yQ;3z7i|6Z> zdfULP_4fUoM;s&#{Mb{b+_$D?pWf%MdVNDsjAV(FH+;N$k5i@4;^gRI8IJ1U(Ut7W z!*-Rw4zmcEgDe-C)Zy6)CHY6`sLHz1*ZYa6Y*Fph&L9)XH+3r&A-&oRc$6Hd#mfUfXFf=@=q3ja(8-C%f+M&bz* zL;YoZ!9sWssSKCY7PmBj`O$}ch|*2kp)AdOrL>ZCH?1rl?2%Sxkj~Xci2YT&!paF< zQngu-NZzG(H&L3Qf2MH~N*o6fn>qGNG(eY4Crm z_|P^?mNr4=Lm3J++*F(Pv5*T0+#rNrB@`=TjuV)9hKR-OLqe{_tVJPqBR7Lo*hMN) z;T&ixF|GN5j=&rVjfvQcly1p@RiHG(>yAhPttV8I%<}AJ(-f}rz#RP4g@OBh>nUAj zBMlF$vTQW@{4_M*Q}^IHMscwQMxL~gm<)q78zKCteulq4uKl@-bX^bpdTeV`TjRUm zs~jPkXqG~hW~#~}eHS~G;%0|h`MbQkSRR~_L#Z6*M7Io>`gYxk+mJQP{iExHD%6^i zPbaX&9{#pJzZ>d^fc$0n;x1x|~m91~W&P#edjEauH@^pN`^Jj}VjHq%j- zXqFdN>xdV1h9U5nHHEUwUChK6h|hDP(W7fFyEX;Bl6Vm$cNb{F*9+z*xaE1c%Y4er z*Ti2nhL);p1DO?km9q($_+(4U$*Nu_o4QGuR#$}(T_qrm9j$M6o=s(e{_SgIk`~xX z8mUVK)5}}e9h`ZF*Fw@&&k&Pd8^m;IlG-xbwF-PCaBNw-50-(J=l<*Z+24clCRg;NRA<%{mK0 zFNdBLV7OWb+_TVpuXqzN*tG==Q>hUmjW8!!9$*c%BxI@HHlHfwr(;TQ>8TIR(CVJ_XU?ci$6Kfs zX@+OJ)uP!Q9M+Qz07}7rm#NQl&KQ_eQtp$Lqp$o`C{0%lW0{jSId*}g})W7_T|9t8Ho)!8R zzW_k9{s*D^|LYe3qOQ#U+pX77G*>`5!pPEfHbUP&lroN_Uf~P;c7x>an`b4H038WT zn70cSph*pyQ0^0^D})k*PZ_o-j#d$tm@y>Iq&A36r&x}bIIqsM8vo8IPOM)TGB&$JQO!)gAX12WRoqE?`*(Vs^|oJai6Dg5n&`V(O_ZCObL4Bra|D z!V)yC#Cx-v>eM0mh4O`JOi)k={Ho8#ZJ?C_*PFLvD4uGVQ7X7mXbP%PyM5|O%25Og z4HP7GnV94~$W#p#IR%wC#U$kxgZWSE{+sh%U{|SK)_Qc~ot9ol{cY0FbqMU_ zK3!gV3Q?5Os`sba?c6>Un-_-<548c)faddd_*ezeRZ6 zy*a%+xFWqbYFE0qg-;F3;}o^xFrwaPqUj*XZgbN-E9*932F`duV5h(Z!)xouSd@GC z_*{|(aGg}!u=xU(qb!l)3+4{4@_h$(FL5>xkx>?81`iN&H|N~tfYzGHpOhc~cU ziXEp7o_sIDU~rhSvAIh1Ear%ep5)<*?7RKVYH_`&v67)^WGut<-*A>IwED(ePz6rZV<8nkI)pAPeS8Y4I z5|t#}S-Ky2u?GHK>{YQ&0$8le5wtqD$+faUDwDIMS5e)o$QN|Py;LH`W8IWcon!jt z283{vuh6le!S}FJ*Um5DQ+9IkFm`dX-=j0Q+pq4jNWn5k5*Q2^QlnpvdENVXR96StRnp)g!Db%r4)%D;mQTG~E_c|l4 zP)+H^$3CPZec`=JJT@wO+52{U0w0#(1yM-#L^WIB-nvRK12c-X3r8x`Jur=ss5TC` zM?N+XO$Ib@M(j6a?me0ry}#@%QK@7uw5`~LwUJ~^%++i$U5>*8XUj`*ATkR@b!d6F zPh|J6pXdw{8M4x&!$K)iD-;=i@$w_$qUhFfl0(q2-l1E%sDXa@lz~;|0Y>JjFf|X1 z5o?&mwMNUFoav{2k!@}_ad3E#Y_Jt}Dx-Q3H9hI8!pRfMBMnWmRO#*gd6VX{=qi3c zgmEPDQ%#47CLL0~*6%d^*ylgF9Ie#ha{`>3$pL;r;!#vnM`$TYRM; zL%ORh{_`bCk47RyhIGWvY)Iua*c7n}m&;aV1)EGK;Mm)DW+kkZ+_AR)P_T69c*@9V zO71jZ?gF1|L6+ilq_p;SB$Bpy;(=X2gUP(Q(RAPkBcI&NukZGyxg!e<-npAKXulPC zpd|^xUFyID>)X>Nf))&_$U1q2Mhqc?VToO5f6C2)vKNSsk}Ga+Dy~=Cq*mo)JCY}J z4>D99pggfH3l^&QoA9ND(q!p;8HCNxND57-P;;SKGuJk;^Bhts`+6$$a`2l-AP7vB z=QV{M30l|XzFNwLM>QRhOdcb$AQv|0OFu<`?~yKbg-H+WtpK5=tcszg%1D8CH0n90 zfMmZMj#No6iG-_-E{T43tc79KiL8{l7^9SGB zJoREB_#x`Gi!~~_jR)A|rM^@l?U`UNZj)24cxIfSjOnt=SMs0|%```_bR0Lixm?)$1fJ z2;7p>+1~73+g@2^RICWSp;}*A);drkn%{&UXiQ>v3SWZ5Xvc+PQ-)KKTX5e=^HGg0 zqVWbN+>|o7&f6@3M?@cnVfi3USJPJpPgZPPxAPv?P;#A^>{fAVU}uH{X+AH3zI92v zm^%@nNVsV3StMNWB}`QtXj9cxn_vd4b9~P`{TxFjBWw!mv%uj8BZ0bDX>+N zpxFj`iMgzrj4b)^VUh4@CFK&K``k2Lz2F`S9EJ3o&N9p29}k$Z*}OT3uLu$SE% zxL}sc=7wyQ^#1e1i8N`+7zOD!7W?e2&X&D%u(KouK1@FT>I}^~^Q%T{WsO&b)Q((- zA!3*{>I~|d8VN!QBxy;qSc&ucFer<;)a8nkLmjC^q!^ES(S*msE3T90RX-?iA@9S3 zkXVVRoB>zVyShY(dug_=yrcD0F7MX$4Q3`s;lb)X)F8Y*_$j34_vCRixUjOQT`Que zvVNJ%>~`^|s3*OgFGc%QVKbJZt`(e%fncHv5?6?na@^pt*E42$6cIs$2!--l4 z>xlSG*!^8SHc-gZ-$F-IAd8H3XeIonX;WMkdV!-Bs$9wo@YR2*oV`wJyW7{C98c0T zid`(8PP{Tly=Wh6L9YQ*23i|SS*jf2qf)s#^(A*V^pfs8e}nByrayJxZNuoq$;$dJ zMmW`B0wnr#bJl*xZZENm+c}L$Uw?>`%O(gGiFV@?BjpBENE4bvhqq;Uc9&>iFJru+V||n6mg}2Xi;lwx}9eZ*#8& zc7cv^pYgf#v)~J=3>GYuSJ|eh9 z&-ihqB7$G@BFR8X>4p@38j@6evoguEInXR7GWY-9C^ovJ9#v3h*wr9KptyW)2+ ztpi*jE@O{^8+-!&-Ry=FE4ow^+ni0gW;&fTmkEbVMr@a6UuX6q>Tqv3@u0)8|LigD z_I-gib;4Ou8JiRT^t87!vCW;}*D=HbtR(4#|7lFH@sydfNW7g40d(le{nh>Z_7bX& zJWzU%7x|3wKo;!GH@GSEwn&_Nfq@a!U*Fw>L$eU<$Jafd-;&W!!>Jj?g`2JRR(3?1 zd!7k}VnoLmCI^pzvB(w$9PL+$spq}*)ECpsCp+!{klY}&-{eA5Csk+! z9$JpGx?l5^Xr_Kqn0z*l&3#5j95L|s7|;*ODUW}d<3jScRgecMBI@P9Kp$~fl*ls$ zLrpQ_e6N0aJ^j%*nC%u~=;1Y1j729(kH%l!4;?t+H-gUBgW+UuYgXG4tpD!+h9@8m zIi9ZR(DZp0pJ`0jP)3aSdW1@Adx~4sU)4iA6bGqDuye)G+RNT>GL64qB|Tn~kE(U+UwvSYg94@zXwGVR?Qp^wU^mXccbu6Gamc@Ro%h z&GY9b*CB3%#LMLb%Qnd}3kD%*O7>BiBJ8LmZ*YFuq}N)#tT5mR+vc3B9fdX(TGdw; z84{}oc5z9KqE{8X%DT)3_1G5#xj!Wuvi0Y7#gkXGwYD52gOutt_Ew}KFn)qc8SPzV z*lXWWSmXs_!q%0lHbSZ7M&{3@F-3Z=Tlg_vs)u0oeDjpfh2w_QQ<9rW{N1LvhCCy2 z#Y_*egN043qbM^1IWujL_kvevnve9sKRZkW>l&iS$ytFRnTyzOBVcKQF5D6%Gu;{l z$V96gL((uj@C=~Ht(Lf+_AZWag}`~r(7iDMq3W0Q{~MkA|B}l83#9v(6y#sZ@;`Jg zBcNaJA3FEnq#*wcn*Jp6835sZR=||zzp-{Ag8#MNo+f0XWDY~0_Ykbm^>ADqtcZ*th=?}FII!qJ}Y zuO@@P!Fs}glU)8#bbq=4^Z?qMAE3RZ01Eq0W>OA-=s5%UKUqMAQt5Aj%l{g^l%TV9 zv<9$&e{z@_aDUg@%5=8>Sy2D?RslfW)&EUUv;6?H5&kb@Gz)oC1$kr4Ny(ofKl53G zesw;!*M^xaG)YyiE@Gfp^!*&9^b5)R0$c}{7BF1{_R}t2BhJ0P7CZuR1>GNZ-jYzE zoC|huwoQj>L7xlfVp;xT`Gxk#t_azE)%&jVsDmf#2_UJh5c;5Y?GQm#TeuGWFVvf> zmT47#-ofl+l<(HnN0sO)&UT#Nqu&g|2GQ^E73OLf>6)-|Bv)#Do9BE_LCCb%(N>x3 zI|#jF)c`d;kESJ`C)e5+ODd#GuJAH`U!&4~c8r_A05fGA#f_9B8B-S1J2(Lg>jMr{ zAQ^MfBwWczCVOELr;r^z_XEOsl61^0CH1e;#fIu5GFncXz+a^dh zTYJ_kh@rk6JC}^&5%7XUtZ~grMH`4#Wf$vfVLv5^$m;{YRzKn1e4R{s!4^ZM>x#>m zh!|^QEdE5g!H~m{W486yjMhc^l@69ewvQS^Zbom743sYXx6`p%up$8MAU$AzkJ5y~ z(Oh$%7^1w&2j1ep74IOHMT_a;_*$MHzC`y(R~msLC`C;ZjwJXZn1|Oeta~{~RlH-x zV|Q0xoOxZB3{m}^x58}Ejbp~wNjn&#!Rhr>O2?ReUKPisuwH6!2=kb>7`52UveD5* zys&;9OwFG0Y_2xJGZDW`liguHxZ-JJ55PI=X_{;xO#jNZ?b}a1d0FN-kL_6guF~ zA2lGAAu=r5=*(nVYJIf5MHtVE6;-Xx0Ld{3iimw^^u3) z%DGZ|eVed#uQ!n`3sDSQ%t$dy$SYhYW;MSHV?H;*SHpg}WhM?Z-%Rn(j(AkcKyW$n zQ<*-qhISE5%gAj!%e}6dIsOojPcT8iOqb--_KNkGW_`&Sk_gtwe^PM|-*$$9l|HQJ zET5CyZz~L07b*P*biB?iIhIYRguu>V8DzHV-Bd~EDf2P*;&u@ z_O>zl%wyOkXR90qUFE_Lkl@TZ{l){+JB!zp5pixNE>yVa`Z$#y{a}|e8un;Oythf_-3ej!(&dwJRa?!; zP}?$MW}#0SjMxHssNp%O&pB>iJ1D%g0_@(10SThZ?5DDlwQI7la|^a$R9TC(&?*r% zG-?%$HC>fIsWyIs@8A}n^<%rj<*;)XXF+JK1TvLZ1YD=#mk?WTjo~u81qR9Rcz$kd zRa+W+a@6eJ39zA;q;=<*_yX9klGY*Ed&2S1SI*}}CI;+)(Kim`tjNy*ZuQrdFw0st zidViuC8uNkd0vc*9NQl?ugSF^zKn(F){5-VchinnRuNkWDru2N=8jmqV>4m2>Bv2w z&>lZFl*5}PZ!4Wv4|p#~)A^(okV&s~wR{QCkX2Q6*BtoC`V@G!d)2S2Tz)}pbpy2? zM@oWlI9*Xqih?ctj#!6I$brN%NpZP`JG_b~+c}4K;s&>%n+u3reVjQb^i@GVwa{=wHslf;N$U{N8_KNZ1vvtk-^A}9`WRuD6?q$#oq zgcW~8TUSPTl)EZq`ZR3RPEJJ#EzYoH)2a-DD+$*;`hb|tfExqz#DXk+-L;5PLw}}) z)1>~rWCEvUYFV50j*6`tKS^woiS?5sK-O!*pL+=3icLK3$i&1{bz1uCVcVD7K`ZOJ zd?!Crpflxz6myByw~)wl+^*E=#BbAOYO_#LFq0ZYiv7} z9N#60T>-KIp9TSr8-!96+XaG$&Ci1ap?uG?~>q z6NkJNWlSI}Ohk01X@Gxlx@4W8{=f9d5fz47|QMs5OE@k}Q$UU>%j{f;C$RriB5YiDwO4+{=FlXkj& za79kv+U^T@I{d-hr+$Z6emdoxjsDM&<&zLhDSNujGuXAB8QD}u5I=wFyb<1=pI?3T z3a6PgP38(Fx|l~NI$K94W((A3e-swF!&K5#`cU($hJghsR-zq7Ok&JnaC+@{WPHCX zTwvQv#T(yxC34L=@&vqjnuo6j%fu{6fxYM|N^&~HW_y&xz!GxhbO#h1EfhO2`f62h ztl#X;oAuvPIGH8iL|r;;fzRm9CoJ*vUYlN>_NHCC<{-jD;`)aj`=3v~_eSa3KuMg{8ysTG`8 zr(o$hX8O3u)I(OZnA0VloLmT0HO8?`XrHB5aBkW$cnuB~e6rF6PuaRpI*rsuR&m)f#f+levDDL6qq%#sg(| zqRaDHaK?{%YK{qfhE=8n-0$^HlOK1J+hrMAbuZ4Z!L>i>QA$X9LYFOS(dB?!#8d8D zi7>IkZ}pyrUl=|r?$Fn9$VT)lJMkiQo)+Od#=mNV_r{ZT_ght-yJZqC%ATE{l~B9k z#V4{(nbe#y5e$h0l^V4n&ZUV}vIBG9(GO}EB_x%TV0vOy76`hD?eR7cQi}kAw2MgZHXPm&G`i#6mbaP~rSv!0W42s$M#9bOJLp;@oR z3m9DfY_#fwSxn=GY(3j}Fqk!NGdWKuN8n_b^p?SRMY5Doj_D^fH-XFeg5KHeMNqpv zF-Y(0*NswX=Dz2^UVD@elP3FiEGcae1N(A+lt!o9tK3RcQAE^>oYuJyC zOYWPXk*xF*mvXDPwq8OCnOlgNrN-h$V4qkJ1aM)n0yqTk9`%R4_iCg`@q zwIW28!juGl3OW)zSPQ4fbH}KN*POcXWF*wBwmpmMn^WlW>Q@mQuloR|?&$L=a|y}* ztSvZXmP%5z?j{-d;+@&Zrd}JxW-NdXPV%oMMTETR!HwyI0MU_ni>#?mUK1{}#Dp`- ziBw#0n4d!2{3x0-cc0E2usJ^D9pf{WO|KXj(kL{<;Z}C}x(@^H*PxHcL)YP2qsJzM z`OULuN|-GuL<4mo&{;ntm0@l`fZ&0aD#Tp?$L=>dWB8LxLuE3a1Tmtf!>Fu`UzUIvlt{Jth43Dbm#5mgLLK(ov*-k8#- zdcplRpPL#lgdx=o(%l`pfVGcw2Z4vN3nI(kOpD8{6weNti=I+Tt4F&fQ9jp zn?iLCE;orHOQSN4tP4^CCO=K}3j?eaOH_pT#utu@{6%JIHp#j@dw-&j@~LDkMSF_rTXG?%976H)gCex%{) zHSV4gINw1D@52xfj|A^)QOI8jvM!UI56=*y@2UIv-JkmgQx|P%rr|C@@5kg5(}5Se>2m{QyE|kkF{HA zwYfC~b8=#)hG;-=0>uUUX^g49$?71`PecJ**j)?G4n#+M=euT}zV79l#^+{%)$;KK zE?g>w-dk{hlb2+X(RBwoHCa8n*ZTrzD8>@djtc4l{Vk%gh`mu77|riwd!-sI7e2Ze zK_2#C}{${BH7POSxi`mjfV7r)ghB*YiApLUAl(o}_V;WR)a~P+J z8|uEq!bRcg_Mn?M9Vcog)`7+dxj2ztSPt1XF9nQLz0?DqOe8u@F`O-CPb;1;T>w5l ziW$$$Y-yfar3Np;htlhODeNvVu9nSHt+n?ULj-0!)udHcYWT}s~dI=+lw1j$IfHUJ1DfXD9<2{3uOlf^d$ah z=xQ3pg%nIt3oIHb$dM^|4Q^6-`0x!Y2vP%6*GD;3x!AAeFX?B+I@+~BpObXXFU>fY z5j`ulOU^hO2v+Zg#wNP*Pv>Q0*sdCkV3s-~T+cvIWpxRxwulfJ=FcVW<}rf(T7};x z3}T)mmMYg45nIbxWj0AQ#O@HO6^)mB(w>C3&{bnsR<$ps^*YJV;5NU1 zW31)SoHW3-yU2E$l@og|c~M$EfuE_NX=WYazkv{o&n8g6wTazqtyVW{x6*dd zZ+ai$!YA>6aY3W?W@5AM7ru2?xAXoG$EJNlJ88;^qMk-67e`@Clp`t}qaHLXl`CNy zMSMI10oN`d+l7ynx|)H%I@Y|8T^R`EarVCddhqmw9hL{G^F0=Ng^|_xC9b?1pB*^! z!zvkZeU~LXm1!`XBt5X)PM$FdQ6}S&CdIS!tapduv>ZA4)Fqy>Z&TCtd8a4G$_g5xSj}}?qJ?>Jaiyy6Z3j*vy?p)XNU>k_k8II4 zTv{C^70sf`R)I9O4*pK@(|3anaag&)sPKH^=}AmfDB-fE0g4M2*%JS>)ec7>wP}Va zh0x>?OLTBY_5sMZX|+|^CxqYPd7C&TGTPhgnculu6pf_c&b$$2X%@ndn|62iXRIM6 zWp`SGVp2C*7tJ?Q#{yZQ?+;4;WFvtc%(nvg1FXdp8zFgc#^vT6`#PJ6UN<)y_3nBP?)1Hb7rQ;xTc>N>UIbP02uL^3xA`1kn>2rSAE zlmOAD(qo!Akj%Yky?F0quswmITM;sK^THYAgMXw>(mq06MXl!mizd~ER)a^H#@)c_s!4ZKEE&Goz1R%D1-$rL4gjL3Z5{xZ(bQ zYm4WWaQ|&7N&x;!$Eb|YC_b}ejvMbfuSd^1$DKt#Iaep48e{XCC&dAFc?0XzLAL6i zWD{J(BQuUNI|z9pS9L4WkbmiUPEdut)opGmiD5T>wZJ=aHXSR+Hz*oo4_N@`hZFjS z7!roSPi16Od0^FN>bzos!jsJ7_u$+jfQK9zjasGi>lnHyEzy2qBr)+A4>vr#aJPxR zvd7TyRiTmiJk_NXvc(68dN8Ps=v`k>U#Dy}q>Rdhf=FcHmaN=gBSmQ!jxtb7pbHj# z!6)$BUZJN}2bYdzYMTa^IsVvm^%$=9&o+ms8s;=@2zdq~_zO zX=QWqBobfa3gapPG|FQw_1AnD?3&3rTZhVQ8&@KD4ie~c=^L0nC>Cp< z?oG*k&o?t$_sDfcL2At=eRKB4y{9#8O<&_igDmiRAb6)uHp!xX>hS`4+>$|5D@Xg! z5gT`^lRJbAi=hj&_7xqORBD4tH)l1}++r+EE0OpKAudqwUX}KZvmOvsQhf$<%7s`* z_W?Gl+?>3aaT<*eId<9E={4JrdH??5(wW||J>}4@DmN&SxN-rHTZS0sG$5l)@a8HK zzrY;1iliU=M|%|6KdXG1w&7xc~hBRf!0Ld13%Xs3m-9P5~L2=%%pY;U&a|ZeW%8QSBr~NFn zBUl;@p~@+_+THxA>S<)$`KjmwT-%BE;qo~<3Kx%b<8l+hzhy$NJ|@h8733lrOI(;% zi`&lqnRsEwsl$6ag?5i~2K!NvTvqTM!b|qM3QN-U15?iD{bZ-$=2-RDVMWH~1ed#q z^9alN#ruds@f+v8lcQ;ccUX%S$E5LKI=$awmboa^PL%2pJZy6qWL#aBzDDaq_`MTu z@u?NESF7Yi4MxpW+prS9ohf<3P@F+$>db1>sf}O+;s+JonO+)X+yJw_ZTwk{aU>GNMyN;A>1~k-W^m5CZmnm>-dan~!uH6ccJTE(=zjvuzBySKC4C!ahfpEzzjERuc>e0rSWwgL5-5jqmFWv!p; za=OEUh*MmHq)a%SrfhNO4o;Z_p9;j zgMGW7%Hn(KM`2A|pYW<%-Iqy^4A`t#z@n#;t_1GZyhwG9YCU>|n9Y2=oUFQ;eTQk; zx_}=T;~0a6PgYR+dNjrKF6AOeu^!W|CTQkrsp&@K8xo0RVy?S)ITYu>O@U-*o3*$g z8sK2yjXHS%(~_-)1V1G`Ttp=3@{9XYszxq)#;*#GxeX(GL!$#O99=GMEq-|AkUc8V zzq|8f`fztLPKRcur`)QfCk(>HAIT;`x*GMWuc=SdFq&4o7L1Iq!r8_I+MTbP#bFu( zbKEr(M8&yy%nbOeEgwv0e?1jtPufCI8pgHA6zQzW^9QIz6Eu9bCTKpwzudfv zk6>H+Q#WN$(OCARMeuujI91`DY++zH>VrpWQ55e(qi)A~kDCpwQG`#JI$&fBc#<1q zwqv7nrbuu0(r~3tS%NaE+Qx#)pDKWFXS|Q$Tg^3&uA-7>;WvXEoM%_u{$zK}IGhFV zlH7)S)#HnC3p@9BZ`bK3=VX}pDHgLmwoTx)ykFMDQX2)@|C+rUnwm?+XPYCuPHIZ> zYnYv~w#djEu||;GBFy>VA}kI29Hq6@~07lqj3Ci zz;tP`f>@(4SelsGyikioMWUFc8q7@LO?j(Id4<$U80o8iNU4%c0kHW4)_A{|_&EIG zHrit*%vQgp^o>vYl8lU!f|7IsD)zzAcBw-`hBSBUs7tFK=7^v9atKkPV@WjOC$xwg zq6lFKQAu)+}9YU_-2_DRvmhTQVCtEV^>xP?evzxu*Z$xhlH2) z&GxN*evhPt(H|uBkwhcagQu2$GMu&y^AP7zJEe)pMap@6CG$D54!0}|EefWMt@mj8 z@h(8&sZBNdHbCLFo+QQI-faz-8C;sFny#F0X8ue%@PRcd=5ObZlJ{K|gfVW(8J1?E zM#PiR9bZtNw%ZP3AxyLOVV+6Wb{m7;YG52U5`SPp5tz@3<}60`vZN;YFd_BvTW&BN z-A>Lk`!ztPR^-WqQOsPX+>_?RyWl8Wz23m*D-b5IPzjar>`64n#gQ}QE}4XzL=wOp zyT2h8ky+Kuo}>4%T#{Ym1{bK}?@vOV*qyLYzpOJVH!7UG^*E9@S*;&T?jIptNPY3 zcPPqazv6YV&D0WluljxS1YUUn#OkaeW^EB1a(ko_(9&9USt@3_re(jf9p28^{-h4A z`t&wXbe!1ZngjestSlw&w~p_3de6`;Xx+|tUvZ(reto6cdba@mcwz^EM$A~ww@8qB z7Lz!iQ58{0D#39{BXsWN%sDFbrk{H$0>br3H$pzmQfG(!_V|F)w44s zVP>_gPtOX*BpwYtgq|4Mf7F2G*mq&nfg_0SaoY)Jg_d^~IVadYmXXmDw#D{xArhrT zSmT~0=v2HW&#z3cMgT~8VXsmlQ$n)jz%Cb-NYhdY%p_Fer{42%OTBXpq}!`V-qwt} zHD|9dq3@1MP8TgCN|979s`F_F8dt7>yK!%jm*wHbT6*`{`SA-qM8Pc1zJ^`o=MCf@ zDxvr{S6`8GN!m!&?p-j4p~SHg@K@#6ZvNj4tg?`n1^Wfp-Z;sx(&~oah6U0$fRS)BYHV}T%(T%?FA$&mnNeE2cz5KrTA(KF49Bw&~6N-IP`>bXQ zmMubFSucN0DaGV9gCMEwG4p_E1vdp^mRv~(NtD^IwfOEW!#W2Wvm+Z9l<#o-wgJ+*2}F--bXAU z98Bbm;SGvYgzkRjv6nx@ZS{Zq8MOk-D6l^#jeihbIVMw=7%0< zBRQ84d#!(|See=zOO>*-RumRJE$T)f# z$oMH9ts%oZ)_O-=AxME4XTpvmx1dvcos-p0{o6jg#hPz?J>fHWMG~S}cmqtLQR3a_ zIseQh&31=ga&tZ$#lmhsnYSf6uP(=@3jz)ibf#PKCTN<`@z^m3*-P=%0*Jh|XE5{` zA=&qnoj@DtZiLqU%dfgKhzI$+=C#2X*YvD=w&uUr(^wW1Bgw?+oE8-4b zz-W8p`>oZ8%vKzPzwAAvtYJacdM%<4c=qyXLrSXc2^Z#SR{m5e{&+@C^6UmOdM=Jh za%r%IQrBKqH-ZS#P~hR)GaGudg(#|{BQwUrBE{ZjNSc6g585I_cnmQ*^3Z5& zk(-SdvuE|eW{qB2_mI$tLA%I20?HG*za=#mEwvp_GWoECGb_LJH<hUr)z6J9z2R5eG!D)xKAJwClQr@!`S`5Y#R7$LD0W4c7T0= z|FUTS(0~6A#_q4pH-7-QKe@DjZoXmq56+GipB1nl_TO-J|I^mT{|U2W`0+n-c7Kq+ zfA-qR0N6S}4IO~0GXUhn0BZ*RYKZ$g947?e=Khr4{SCfT`a4_a2tf1xRLsc(f@nqn zuFeF2>HX=obNxrS3=l2*Q*dW!_1BJpzhY*h0C4UPdiN)aCP^p#pRu?9zFvU!|GHj) z>CZmf{|$Rn@RUI|#@!?#7L1e`P+4|qpAitYyg84^Qo`x>lM|wmyW*5aBm(6F?)8a@ zLAdQqH*~ItB7oWv=t2<&4IuwUxEQTQ)j2m;-dH%tCVf?fli4m+{kZ9JhS%(L`O)s` zyvgG=)zSUO^xnjSB_ZXdhaI!qT1!u_f3MUiR8lQ0rJdNUl1;uWlP{wZ)9M%BV`S~3 zpTQRmp-ZCP)yufs>ZI#N24)5uF9<>}?ydzA^Vw;-gO-fcQn&5skm~9%2z<+QUaIzd zedv0p=Ov_=8&k-C0UvD=}@LrrMOVm@ZjNiSp@?9 z^0_=hWp*Hj%c0eqy;LT4;HYL;S|(OnnPC3w*~+6iLT9 z`L^tn494#TY$7;U0aDB#-xQeGKc^5eAr+`HAV(3g0W)Z^XPO;yl{UbscY0Is*kAA% z5!Mvngv1&%0g{9dI>aZd-w}!mxd`kGG-!Y%^u14G#%RVt&KL>tX<~(u#n#GY^SA39 zk^&=#_ubp@s6*I~Ko1b_J<<@zIBzRBbi8y#+} zme{`V%6j}%v%u)Sb^(1mUte0j$dc~;MQ5OY!F13qV{2Wuq|<%|Z@Xe{I2t&CPoiau z3SO@hzYRmL>}GFfWMOo#cZEk6k%6j>gVkw={sl^PDd~#Vgqkg6kp-7sA#&LxDk+C< z`zcTU$V#h|rk&euf4jYVQ_Tiw4@D!XMk%>fF){^M5b@&7_|;%LtHcoqp(dqyf#(4`7kcUfq15oE`F z9q>rS(_DERyd(vkSNp?k?tB8q;f~IL`vCn(L*IAWN6{L z45CIk;qcBsW{jZA3z=yAe@-tQLEW-68~_6`Z11Zg_-R8A?Z(XKBHwye(hiIwYTb8` zqghs^_Y6tHCE^J)?{_xWV^^*=k0wyfg^o+M)P5i#dwfCS$eXIMCd>8$!Qbz-Ho6U- zem`<@za_7gKeKvp=|}N@X)|?3fCGn^)vwsvU|#T|$<$kR+C=6E%wMlB(`O9_ETwp! zj_`Xn>=D!-~9Y6FNC@VQ5&x>MKJ^xV{=uz@R178d=X2(cf>SAAS2Ey|Fa z(PFI&gjza<^eY|=UdFJCevvl^(qOh*W3FNmhq4;ABf&*D|o!QO!UL5A-rtG=(Ij>aV(5Q@3Eqm5pzoNmI#MxsQy3R-ZCn#E^FI`;1Dzfm%^RG-QB%#FWlWFNJ4OTCrEG&65QS0 zJp{L4!A|Ar?yvjpx6k zgwmca5%ye9pPv}4UXrt>H09bd$9k_Ll5-%ZeD z!x`i>c1g&ye4${Gavw5WTT1^Xn`lt?t{hld#kd$zE~jzZTQ?GNHoE@eYR4Uznpm`( zXNi>+(No@?2gR}lK77k`f}bCqtzCjyT`K*yu%jgM5Q)`lH0)H1zob9s1CU5e*WS?f zORup@p7+u7iQ%&IG?SAE&x#z@ZXN5ij?L#Ydx7$j<0TvCck6a`sSoW@lOeS)U5K;v z#d^Qbf5&Mu>_bY2!{hzD&d$@e&Qh7{#wP$VN?_G^m1NX{+*&B}_RGE<3obzvK2CWG zN4#kcwlK5;8Tkh#RaWJ^vhLro(HGRjbZ-26$@`2!%l?zYgVvoDtZ!4yE3BRKFJ#!`bea6uxA|uap9Z@ynQ= zn&D1=&?e&R33idK#^Jqb+{F=>QU}A7_V!DO9W0Rj$Yb~*^$?Gp9krt>bhYlLB@F}K zk;XE=%@*x>Vb5V9jbg8o5x@!xM6;TLu0q^-{Y+TM(2`murI#MPsO?y&glYPvHOJ8! z`6+Dw3N7ZSd6(yEe}WrdYG6yg@b01trQaEum^}zD#Q8HV+Z$A|Hy{d~_Kj?}_RhOA zw|#@z_Xg^VvV2I+VsID$q-m;)4|HT0J(QFl7W&jkzQgJkS4n2Ko6q3R*3I*~JDm{R zsC4QRF!&ujm*mR_Cd9CrGV0nqex8S8rD(B>JDk@cDQLEYKjw8nI9)_L z;j-!aF!(+urPPo-B5ZYJ75tUhfEaqxq;+9GOv8~UMKhWSY?l5peg(LClp+?t2Eq|| zSYf*7>%>;U&#Qqb8^SmJySVq9K4R|-Nb?$f64&~mbc)0N}hpQ&z$94{)4c{B*;Z4_h~o*lx* zWnsbw@xOT&D64CuIjyp$E>z80feN8z%ysQyhK;r^3qOV$p(3>|n-8|Zm#E2b$snoJ zrN|%7q4FuL7I^;F^K(Ezbb~MOcjzehotlZ{561b1NnL;EOP8}J>cTOWfO#a=3OD}~ zt?784H5NRFq-zhYhj?w1b@U3)clR2kiOD9rv`1mWzs)g)`URzu?nX0`Eh6?ItiT?F zcY2f|wk>GGt1FY>mt=*#N5|k%qc3acKq*vmF>+l&L62swHma_Ux>o%pta$MUr6^Ef zT~#R#rEhYegwbH))%4^Pa9USsM}%Big~4Nv4q(oaK&cduQ;*rm5pHMdxBBUeG+OsF zg0h`ata$@*nsl|_#|?Ci-bDE+ zWPDH*vCUOW-VOAhziGbH?RqjdX%YDvD`DYNb(0m6IDKf@bkV4i_;Yd0M(TytY#I#p z{7B|=Cx824G!DMKUp4=;NIaA5WDl1>srQH50(-{9lUxShHrI7Di{Tu<3*z4qw$9DI z#A(?Lgown}lp-F_CBG@CI~r+hoF}KxwR_|1?JJQ7N zmD;MGrP@+{#KZWN|3Z{H=PAWSsGC?}#H7WSbERMOOZa{;R-iUt@ZFs>yrl;$O4{j| zi3NUQYPJZ{A+Iy+zB*U3QajORGM&zv%?_ z%0N?b{vn+xA{5L-CpV|K@P%wRdjvNt$)*#) zii@mw@z8kRQ}^5d_!`G{SBji>gv5_{M8eSp1D6=%sW5o8Gky7@i^u9lKNGp$6U+@I`=c23z9bo(nh!Q~n)QEI=^fhCD!Ehey`oH4+t6Jh z$8wK`Jvz#U_LBTlOf)5H$j?C}LZ6V3JtSJM9$Si1E`E-BZHImyas;2M@y|LghS{ zzr`E)8j1Y9NZZ4@A}~2_Cl_HYR;C^Fp42h;P(_b|nt!qzFdL31&S~4u8`iTg$#TlL zxrf45@eEh!5A71TfAW*LcWO!RlaOOF&H>Kw@>dAO>^y;vr)ph(Pu(R%Br zHv3g$ORkJTriVEsDrJ|Gz@(B^*8}bu<2m?ddc*mqK00&LBE>%rIvS@c-IBwFshXPI zWMADa&;hYMHB__CJr<3;yo;UX;xT~HkeGgAsEnBzmL4P;1k1j3gN7k+_k?}caCnoD zNcfhGmM>+L(%hs!dnP|Kb@$6|*KT<1Cl*~tng)WFASh%-2ak7E6vQzLDN3!RhLS)X zHd4|U#V8HWz!ak=?*LWLQ^ZKl*yKB`TImYUjUNEq$hKRIMKL`qekpY>7?w0n_yqc| z6O{GQev(y{qBGX!OhxyQ_OvQlFdnJIYL=@aineP z!H)zMBEz95nA}J(ZP@Z*Ftwh)Ij-iLSXA2mULE9zieRN797JVDlU-T~DD@Y;k13Nk zw3T>rQaEaWSv<{fNvcJsK&D1DEA5y)2l)oYRWMOOPvJ|9r(eIdtELk_qsMqdP*;^0R)dv6M!KBwKuEx+>agE9=zcQqK+a+i~6$X98FCEubg5oLo4 zqGl34roV0vH*m&3Z!mVmw+|(@&SPbb8%iJui$6|l^*!?5mS%sc_Tpk?9OU|}J4?nVGzp&hQwD0^IdAHimzqtz`|jkQ8-C&=%>ZIeP47oa4#KBCtc#YllZi((bGTa5 zRc3?2ThSto19^GV;;*i|Bk5Q+--9}}%G5ZGr@1-spmFNZ2NFCJVb9&C;N^M2ef*lU zKGvP(i!&&U&Or1Mvv|0>Ee!k%XUvpTunct_aC|RYd=lw%QeJg|X@3;+tUhXk0RgIj z8)7$GL8aC*2$!R#)g~5t}efuY9LU(sYfG)MOYshZrfC z!8E?Qr6A!P{N|t<{Wy2zM*N}9x%CfWD7=2CW-^BNk;DXa^Jb-1P|24I^U(~457}R zoXk7&<;HOi(?bh@w?ngp@j&LIHxhfD_|7>0+0Nk5H-q|pgBs_ELz}<=Iz>7E0g|vZ zyVCd8Sn5CkebKE_u{wfH$-MlzBl85XD=JQ=NOLc3^LV)=Q~>2SLEW=h@W^ybkMP7~ zUpJh1!;4vIaSODrJ!l?Y#Py!OhoLiv%8zlkz$zq@Jk~^ICR;-ff!1*5g(%thh-a$f zfkbqK}dDRy*@C{mpF#o4t9OY z5bCeY1$1Y*3gM<-eo!9%gfe_cK5g1rRHGKRR!$l3V#oa>x=>3ke5^ur+dZo@FaD@P zTt1#KF#=@aA51*WeT-;-cf(4v{0sMRZ)$Ljsk zsHg5}r*F_#tGcX7?i6{jcx+;vi)2Vg!VjGrL zleyFHuzo?kr%Q3%kZdLSz$;$YA-cKZw&Hl}Dcac`Il2<$zgfkLM*73?<~iXvl*1BJ zQ$+ZTi+y%R!%f42akMjD#pP6cWZ&D@jA{9p2tI4;b7g+|yn(f^6+l5Fjf zI65W3wJofppj3!22cm_a!<*-xZ)880?-;Q>`>Xwj3d8>gS`IhsUmkEKPJbua|LyTV zyZ9j%bpNO@KrHG0t-1iok2A4Bn(HA>bu0j0_W!^#mX;7_kTJLOFn6;Cn?OGPuQi2# zTGTH`XYGX8(@i~mk4Rsx#1{^@{swf(Dk zUgj@)jS8f79`u)$ojTCW#L^N%&yj<8*EyN!qy7V6{HH_zUm(UhkcxxuU%mZOf02;g z{%&k%4=H1qLW&s{kb1^hN-zaD4FcerwOGx4K_H)YO<0yt3cuR-b)})7 zAE7tmyib(c!`A)LiJUvKd{4>gR3G;)*l1w!T7y&hruOLbQHD>(cWr|rp|XIyVlr2; z6Eb_US4>T0!B7h8KCzg%*1eC-2ERUbVEXXPvD-b=Y`*1x$0fkXZRe@&d!OW_=jDHI zO{MkDk7~?SDAQng^P+6~OBWv!ufj+#&)6LJ1vSbig1Xm8mani4i9lwyH>LBJ@CVsX zxzENaTI;b8>Sf#YV@sq(I-Y9tvwgE`aQ*K*c`)_C}ewX1|^C%tqp7>Hvt=R|NO zqn-GMGn6>rBkuLKlmHnaedy~_iNvnU%#mK6WxoH&L}-whH3^;g<*A|!SD1xpncC@l z&TkGr1@e!Bq{TN~tkqTTq^640jwgKZ&?vw;emOd6ZG~>P$h_9!d5>BM>3V7yLV2~y{F!od|T6B>YWtO2vZUMU`%lPIZIw*C{jaa*=^9u-% zvYEyhQ$_Nk%QbR~#bM-h2tE_+l`aS(UpeoOK}84(*7QTacI+ zm+tPbg`aDvfei$+PS4q2OgW$jE>xo_)*hWw5-kQq78KA-vYrUo;2a^q`#tF_F;TU6ABv(38jx2Q&Qw#a_`T&8CwS zJ+yozAt#_1wOmxTsDb)UiFdIDRgZtF+9=d?|GC&d#P{R7m9?ppX~PS3+v=+1m{2Yx z`k^s&oIPgtv`t-&c6xY}KqMp#bhr>@ks|`_FxA{)!#9c9Jh#k8;EP^u{ZFozr+qRi z(Ft0_j)4f|V3L5qTdDGjRWE?-eMUzpw>G?vh#*O`_ORz~D;|_*lniRRZ70?sI2b_= zB40mfd9gUfRCeRiJzt$QIOxbE7Hq~82PcFb`iEjer~5g@i=ZSr3(`RhnY*APA_Z<0 ztzZ|Ku{xmaaHHQ3R(!t?e4KA5WmvgBa$Lr&^DvO ztiAhupF0|>r(Q3;{TaSbS7lZaaMjfA)~ZFkgh^bJC))RZL_PmgUb@hGl>mp!nZrKN ztgk_5NEiPIx|ne0*WB(51F*|c@*#PvFUynw%Y|pV#xZDClSM`W%DUu(sY;$JLVnu} z9TaH|CA_2c=eERv@7diYFiB2QM;fRI7cB0|vS@pIBUu6$*cQABn_GrRuU$jtR`Cj=L_C^ZGAbLx&9>H=2r3M z_ivT$%ZB%!j-RwV^%iCQ-BRa3_F=FUk=?wmDj&)4IPYH`6xpI`k-nb;Do!S2mVZy< zX(lHV`MxPYrA}Cn+pJwu`CS5x)Cn=Q&Tt~Jcr*MxtHEf&z2KqEc%!|bMI8Mpu{h?e z<4&c06r&!%!1Yeal{fV45t)?RrD`@~Iv zVq6Es$L5nvz-Ill&G(F3*{C9oB4sZHV@!57tT~2t(Vx__4rD2c5KQZ`7EzEN^q>-%DPbA zzcAxd(r`&e>EZAJ&DpgHzTy!3>OFd&6Ry{MllGMJ#FkQ3vMF^uxfpELTVOV{**vL; zzx+lo>WREtF64J=;6D=G_A;2tOeAbERY|w8tn#F&aGmq}d;8U9Uq&p~yj@J`%CFXE zwubP$!An$&B(+qq#y9A*tv9ls^bF6H4Ouf_t*Xs6*WwK*zulKju9ufiH%)s5JrJJZ z>`$}VHWjTK>Wg2+iuQU0&a2^YIWbI56o*4ZBg~| z*Vgjup6LRZD2U>0GBcF5T^rS%q-pr?e6696{ri+8cCEu(OM*hMjRnnYnK4~sR-)!d zKfp$ywFbu#FGN>&HD}?Pe}}4%bM6AOkv%!~M<8~aRY_b<*mQjr?3VCkLsag3q(G-JP~ig7KTvSl zf<)k(Dh6nvTrcc0goUe%3u<+odf;YtE8l{DNxogr@ZTz@#~G?-n~`e$ncJZ$66@}{ zZ{|hv$fG_-!*0iAxS7_xT}ua}dZ#&+oI>lBcxA7YuQolnrM4em{U+p=AgE%LB{KM3 z_taCrT)7B2TLr}si+=q+_ng)OVlK}{#>h^6nf#{1yX=PTIDG5ZkH;y?tFJX1hO)6p zzm~*?6b`%aOdSX11c|CfaE1iTH^{c_6C&hn=?glb4P!2_SXIV#DOsS<{mAe>f7C_} z54sSOASEgm6+`%LQm|Qnz%xC&mCuj%J1>ErF1pUCJHkQKLfQmD!Fguy*JQA8&o2*1 z@oTbE1EjZ-=hV?u5tpwg^drtGqmWQ%r3uzvzTaic#GWUJ@C-Jnt&OQZ7;u~_eX#Oz zGqbd5qRHUc%U}M1VVufrHk_YZ8L34fd{rJRKPD_x8hVMv)hz34m6|%I!Q2U<9pB?} zN>@*Md7hBx*J(+l6gOEOYo%`zMP8cmrX+=#GCr4Q_*aDV_+|P+u0@lAptn$3K^ zgF=xnJ^T+b+y4iHe{Pn4Bb@#fG5s@U`xoamh_l+i#cU8bz~7wLSRm0G4@AoKzZGH9 z|L(l@{~EY){Skcq!&)4I2ZucRTj0j_C%F4(;Pywz1yO?i6|%`fg1CQmU~_?pz5Y0_ zc|*b~PlzZC;t&3R?93q1mL)_w28p}=ink!{W`Bc~dO#f2{$b0e2no%6{gy@;IF6t8;}487YFPAO$+9i?CbPyka+N%k&>ZL6-qjE!~6`JyAZVye&)g^U4^AF zG8%;`2T27Xu6B>7kxK7MuaU%3)|2nht%SdwN*H#i2i?@Jq|G@Di8>UD?Bk~f>)D{; zLbsXQSRsqpEX$v~ijUH-KhMU_#?HArC(j%MH`hPrOL}9x?HwHr)CU=MfZba*3LLpI zk2;#l^Iygr;n0~2YMTAx@AbP~tSk3kZEmMGlRkJ6Wa;x=tX&nR@* z*F9s~3iX=2XMd;S4n%*qcmJUq;^5fyZG6gZ{*;55RZn*e$3HW_O1orrVXp9zZ=|dq zuL52^%x+!Bpx|+m+6`4R+t6d4duSU+JiBVVpqicIm?@gCUiH(kRANVEx7`f)VOgu* zTd8NvkgC1R_hzn_uVygaE@5-tQ|jJRC>X!UVJn04Oc8zFf8r9I^5E3?hPYB5iq@r4 zf08^2rzRrzlam(C9}c&-$cfmG-BGPp`|?;)bHBcfZQke_<{?niGRNyO+%fLp zU*#3M@*$o2(d`jyKH-)sP*;x8zwJb9JE$j6;MzR8Sc<}5TAvdpDYwVCKW!)FUS$>M zm_H-Nm%mof{1LHlG@*heYn#W;&UEjJ*Q~&Dz_`|3k0n}fB-7h0CrEi+J?jl_gP!_( z_V-JBIr5KHcym>I*()YV;B*XmI7n+~^4b!NW(YANZ43P*6?cs>0B;K;<*g4f!fLxx z#eh$9euq-Kd;KLyHv9<}O@Nf4%N`#+X#hblFm_&_Z+FHpOAQkfYb zIkIH?Ts5g@xQV2l0*lMlb={9v#JY_Rkxdhd7HNLes>!RE0` z;ZyvondN(-PQK2BQ%2Wis}glUueQm#$|qtmNewC%4$`i~R}Ho|6o`n*wGLse{fZ`= zj$dyprJIP5pH!<9Uxq&iTKq~4FeMoE`e-pxcncdm!7}nO4O=PpQObW;AqIc^eFe5a zRBB!p3Bh$nn-ogX?Ls?=m6R>gtGB+oI0^1~RF{hfa^6d;2kxSd+|nD5k}VXly86l7 z+@6N0s_bP`tVd!AHuUyC_S}c7 zdT2OYjW`D~PK&mBz*y5^47}B;;;ZA6Y~R`r~b% zT-+8^p%pLU7s2`Ye9FcrB?Z!A6$Dw;^&T7@qxR`HQ(&galI?tdf_C9c=_=TM`(By? zi8}u1md{x>-{t$02Rifo1UDV0$RQqff4+Ii;A%C@_Ci&Bk1`ZY@i$T~qpC-;I`h>I zQj?G9iyh7n9Voa~ug?5Og+$LBO5c7nRmyPBCwQ2q7_}{WVrI7{2)N@23-Y=g8tl0( z;?MF}j30$<%9Wvr2;{rzKZ7PvvpDjfVf*m}@5)@Z34fI%Jbbem&#t_Leiosv9VHeV2p@0rRv+GV1!uD`%_t`3P4GPh;W)t?YC*W~1 za{`R+u!cg@JQHbk>&3R$iosEL( z?p8bdV$Ht(htQ>(F3B3~NviuopWB~HeVo7ii*KOZv>a}T(7fi7VK`<3 zDYP4Y3p*=W`z%QO)(C)xU+WDHaLro;_gJAXA3W%SSOa8?YgrzFE29F<;m0w%h~UZ$ zwZwul)YglXPXr0@33DupazSx#!HC;7#6+%1h`T6yjebKZ(Up3-*6!64-;_q{>_$@@ zmyN+`BFAVL83ejAd^f-Hg7QN#Vw5%~?22cT*=KJ%chWs9Ui}_@&+i_dHy-^vHKs`U zo?nRI7rQJ;yWB69QPFksNq}s`$)vW}aZ=3Wv9W7W_)2bt_EENu+Yskzgk}rfNn#SD~#0%RhVVF6XZIc=2 zx&7|_xfGfy|J}%ja47CeMT-;7NWk^W^#y-wNeEcIOY+9^kv$YKk8$;xT>8B7(Fw^x zRL!ssU3-`O+Zgs+_(uUDKLOr#came}Lo?R4_Hm%C7~#rXH0;zOb{duT1T#3xy9%A& z$2;)H%Hw+}00B8u?-oI>1NWyV9JwIJZPKPy>I>JQhJ)EypD%3Qct7bfTFKmuM^+Qh zt?B6Fl5+bPMq4mll9G4|-|Gg&*m0JsnvWfxQJ~I$IF;x-OGH4*W6iDmmd_XA7G%~* zvAii<^UFJR_D8xnNc-F%QsnBd>7;Cg zl34XE1`%QOR8?#z`?z-pJDVYGa&TqKw5k|g##{+L8l0e=X&4$z6LN?{cL@Lw8jV5nVmw(Am&wAIOazL#=X>wY2EEc-1pq^ZpA>MO^ofdBpVB(7{><|960TFc)4<) z?k9{O&Ri;*$)=Ilk0)qjo}0@SE1~xNWGZsMT#$JIf;f+E8nkl-obDb|=-su0I>78S z9y?pI5E*HO$xk zwna{7XB5+KSbk9S96HNa2qW!e`v*9rQ>+suA^zl(mxa`O^<*Tk;$KzsxZ~(nm&-8Y ztdgWq3w8evK0$I4F3BaX?v7OHP z*qQ0>_VpWea9F3!LNv-SEjq7lW|dqB*9?0ZrNhw+ZnUH=K{ja#wxk3Jq+;%Do?An)9kyj#KAt(`YmI1{Xsc9@mRwJDNi41U{EDv2zp zsQDM~3ukADBR*_bm5LDXv(r@{^@hm@BcM!Y=~gXxzFe)?Gr!-y=t0g7L$n+m3%`d# zycZ{~CDA*C!a+y)p73qkMxb+VkU+r^h4;c*f~W06Mv;cek8zCi9xAUbmxV4kRff{H zN8P1!z~qpn+!v2CcA}1f6_oA8so`ruYbe}OZZ{LMXV~|7rX_35P5D!xFk;}syw(<| zj#?J!`-9T6IWNzuPva%cPkvt|5~!0A4t-Ee={WL)<({2dGz&vwo6cD&^q7sRa%=v( zr>xCGYQ8lbxya5gEp6EdscMR(^qF_mJu+{W<1>6}HAL`kq#PWmh$axt9p6;o@|rNp zX#^Lm#1<10D!}ozI;AESw|^D<0(AfO-h3(GI2uXmsSuxIqnQ9JnRkY9cA4W44sJ1-b9Z3QL%{e~40N4p{JpYK%~Ka7Wb|D_3| zl2IRvx9o`}dAWDGE&GrFoO9M@|bS!`cQEYb?``5I_Zhy2p^Hj5F0N#zv?#F zoGopmwd)rp6V7K%J_OlBbr)n!>Y!&9=fhZ7vf>?J=f^3U6WXJFL~&iUronZ4--b_g zshm9y8?CGVb7rLTM%fLXAGQc_KvG{CdAuLXhQDch1S$Nu3n2wk}b*uZF#lZ@qryp z(S+!Z(~Q4?D-j1&Y9319w6!#FJoasD+bH-pP}5MTQZWP?&(dS~H#DOiQXB8EgU?iE zaIWamubm2T*mUji%5%Pl;!NRrX4^wO)#xgv;%wz9!O{@lfdHKsRxC-I?`3l)x!4;_ zj(gNwB$E5?-fQ24Lov4Bnj^)DCNXHA45+`?JZ9&3F9qSiE|af2m>_+E_dcksI2f*9 z#vQ@o^A(s?GXuRzmj0||#68D5#;p*vu92ZZq0xf@qL%h?{C{sw6EngVUMUTnrXY6+8D2iJI`$u?*y3ZhH{)qtf40`0x z);TM%l#9Pa)X8&~UuAeb#^f`gI02xdN&=(3a&!L>f06RzjN|(t^Jngo z+t+9tijK(};3sHG&!2`~QoX35{@nr^&k%e!Uf&g(VIEKr`j*gS&L zP{zDd1k*Bx8~@2E(;AiWv9gRYWUMnhKn4`fR1b&xmT#A`mfplJLSjA z`cHKLDp14Q$sF)k^X8vKo{P1Uo1+UPhbHO@Hg|9X{9jXke+UOsb|#jtfWM%Ee*_i( zqY)GWXZTy%kBx&HlJ?{LPia3%25A!)6MIJoGbS-dJ2S{8{EB zR3Ix7_%u$J4h!&YHLlS*^S8;m9JhOgZ`4`g_(ylO&eQmb2Pcy3P4ArRS5o5qJePD4 zTI`WKj<#CMNe04OT2484Ez9G9Y=g3eYODw>I!2~y#>%fRB(DY=%>`F?=&ww{mbo7c zl&Q5ozv@$HQ)8d4bT&Ds?i^P}cvOm&PFW{amdwd1h82`6);6ho%FUL}ee-mu2SrGU z-<5Lh535HQ7-XC=kAK-$+!SagQbzPZF?`Q~xPg6w+eUR?x|O#Tw^ft(UBA*eU4*O# zB^8NOvrQkfQb6S){A-I%GM=nrjilE*4=pIRVaG9p=9Z}}`+!zS|C1rAn>Q(3OXo?H za3;t{^m021A{&GUE3SJA_qQ$1(uKfa>D5@YrUZc>P4@fTSHhu3eA!+!t@9d zyNy+&(2qM9eEwK&@bUJVr$nHOGyX{~XRSwge6hzX?1z;~d zD^CgZI<0?9#5@v6Stn&4QiSK@98esTzVPBpO``^y`>t?s`8T1oa)kM<7dB*`(?KEq zv_NZ4CqOG(=&e^lKlc2fulaP4mQ|Dx!YpVc>qw*7%e7mb>LBgXDRQm|WMsyS%uZE~ zB0u}(9LVsXmMnUVieH<}DMcaSvwoP7xX~RCBo2Ivn2NE z$!JJ&1bMvA$d~JIy-2*4$huE#&Me6M+#aN$6?)s4%+5EDU zeI&@Vh>sS=gy@o{?dSK%89JnZN^L?b_T%{RnPW~>ECze$bR_Typ>(~sMWZ&O=Asms z5w|I637O|fPOU!uFy7fF2>m{=&7=0l4LP>`-Ev^?((0sq zuJ}ys!v^n?Khjyy$)KlgM<}0Fu+Osp)=PQRO*~unX{)aud}sa`DB?&J>ve^>*zeSl zZyI1vU!s7?7leb8_R-Wif6X>@Tg_*oXKR4WD2Gaf9L<+)+BohOKAwVqKZnxfJ)$vw zMUOeV%rVJ@GS{7+yQNCCtb{iaGj2;U+kSdP-!yG%wE2+mzSrd_uu-`E(0wwDyH-Q> zb{^L5M?awafoNeEdF#3Jx$rvMr584WiPEKW6=8`#%i?a?Dt zcr%u-@IErxTp1*NA=XExpFTJ{2b(g=6fslG#bQcbgF|UfqX|Y4e-{RA9rrT@y-T!I z8SJ|W;=NjU>KhZVfZ5K+z`y%ypv~pzep6TghEO0#6e3L(gwiNYJr;gQ8&r_(<;Ka7 zndLGF-c+fe7%m~ZEFmy3$RWOU86Z^(8`^RbJ{`=x9F+L&RP#!dj!HR5frqh%>fBqp z-G^>^_!amrsc)H*UySlbh+)RYx>Bl~33q*W@i?&qHhS>uwF7E?(_xmBTM}-hev~gLoYnmR z`Dl0IOo7LbpPcd>v$B50nwj#TWbP%UdU(sEQuI!F0R<>r1}hGB`@G_n{I;e^GsP-0 zk6kd7TH{@kU!|(t$dL(WB1`GhbPRP9UM->W>Z(is!wTj<;G!fQz>a3t4wjIGfP}S$ zg*ilO2{v~H=m8+|(Z5vy0UQu0_g{59z~Ae7fWNO3AaAfUakT>cg;N6j5n=-V_&z{x z{!o-4Tm0kw0D#o~JRmPXEFT~@<{st_0LTjDFYwZz&DuFS{CV2m`tNt`%w1gpKyznz z6FbNTEM3e^AVN_97i0(~ZUCSt04N3kiUWWW0H7p*8&czw1^{IMKv@99c>^d904e~0 ziU6Pz0H_QAsz5fN3IM7>3V{Hi1^@^G05t(T5Hykw0H_Oq;IM!u0H7&k5CEVV%umb??A)|%t9b~ToKxY6DvPX~+LI&dw0D1s`o&X?Z$Gjo` z1OO{!tp?fKKWnvr0U`7Lx7;R(sub|&bFOZXy|zb1mI>F07j_I`!RYr4j388ZuOSm5 z7&etDlfnNjt(dXSDjlH_Wj++=xXGVcd<2yhc(<`EFnappef}M3&lm3mn#PKM5tb;- zwg%C%%?+)NC}TqDn!dx{Q9y=`)L}RDdE*<571JI9=OEphaqZ~b7aynx9D=vmtzA25 z{yB(5RU3ieScf-o?x?7ZVh%=8ft-TDQ60iwZQh{*RrTJ-`Q6imk=@NG!4n`P3t395k+fmr~B)Ms6iI5F@4Na7*@rV*5|GML~1gjRgDyEhcTX;O^c`;mpI$8=^ zFNf|U)9kK@?)0NNIb-p>Jqv4cT5qXjRRb!NdDx{oxdRru>b9dst7vv0p6}ZyeFwXf|6LY2(Qz3SNjz3wZ-G0OE#YQ10w#_xvh*F z2*GQTYf>OH_j~HZGVBwD&pJ4`o9~_Tt^6FK7EvXPPEal1scOqj;TtEcyW=dUqqVJk zYrNOOova$S@G)9Nf=49sj!<El(yB=q$!a1qa*|6hD=RSAuu`+q3h+2HaA`Ozn6a}niRoBtDAPH)n$hxWtGJu6 z8FE{h@jHMu)hHE=nIx!nb%gC1_yoC)k;#CZ0OB*$mX$jr#hMyF+H zDF$*fC8seGRtDM{>LMHHm?#+88wf}!fYeQ>oDD^U9Su1-w9GhVtsE(o)#yw(Ea}YI zDCndpoz2MD++;yudQM|9N=gn54gnh>X&X9ZSsNQ!QD;gzGg?z7bsHlFXHFF|AQPXc zF^?IIj0htI$VJ9Nz@Aq@<-X7O@bKwjejK(6?5xa^RLXwgO4mQZe$;Dbp}G zv#KErSh!iT+vuC}Fw)ZLGpT_2gn%466e2dfBC-zjdg5Bte45PM!i+Kuj0}vz@-iTK zV@qch5l&ZTO=A{rRX0^uWG*Fgbqjk|K?-_)3wMw;hpx7~gQg}gKcl*;sE{bFfwMjx zxe1+)jfM$`&c>3*iIGV|n}-d|XeA{lAjlyp>W*v$j~Jgl3SSB z7%J)WvI)7H+3RsiYr84fN^|SWnu0krj0DW=Ag3F8Me44=7)ERdbUNRf%v&_LAQ zjMs@v2U&?u$AwZHtK`BE)19Nj@dUs)IEn5aVXJ;Ws9w!TDMi&VQ zVpQB%3|2vP{}2XIjI7my+f12a;xp}!% zoJFaaSQwn0`Q$AGoEU)45?Tf{T6C1OwtBi^JmlQ08s?Hp_OiMvZbqW&(k4vYKsz;% z6qPG0J+h0Lgaosdq#T{Tg}9xgrnnFfqq8(8lbSf4oRSPR6)z8inu#Hol^i{ntsym+ zg*t};hm{?Zma?jurM5h?IXyYDKAoe06)lCHv^gC;HKl|St1b(_t}B(aF}aH)had~1 zlD(*iE4vb(iKw-hl@XhWt&BX2xU_(g4yA>8_SPm0x=Q;(KkUWtQ8MB9j2 zNPtDw%7vMMO4gDCC?+NiqLYzVvK8W>&`}oVl?N-*Q)viTf#kSk%s9z`iYCZTDiQ`l zw(ewR`kV%A>Q3}>Y?^kqJhCjDf_CJpe7X?Xql2~xBd3vz4T#oIou8M2*^b)EfWlTt z2dE>+2$s=DrjrMOwH%#Y9Svwi9K`9tQnWJ8wi;HDUMg7~F)~A4MOH~MX$nqOCT=@! zbulg`Wht}jRpwO{FtDW3=aLmra?&&fiR)9biPAHR+A~Y(Xd`Q=i7Prv&~OSEDH&TyIV*4) zDLbsK*5*)#Df&(=j~zN!6Ko;KxMIsrSIR7urI|eC zqDT}`r`^)EOhWDF^jNgP(2jzMMSReYk(6V@dYb-ad(6y^DRcPN%l zD#gv$N|4T*8Y1?xX#5B%KGR867;(wfcQ88cF^NSsK^L=l@E9GRdrxCHqLH2lkx4(4 zBLu%uV`uT4nPo*QAEcW5DO63D+8TM@ZskqGoOVj0u{Min$P$NVP4+8!_p++j6MU&Q z)0dshXvT{p{eCX(VvT6GQm0@8a#hjNoy#O(+{E6^SgQkRc;0mhr-0lHtjfHTV=oM< zVvAWljn>K%ThgwW#a?dlonG(OyU;M=u<+(KY3ZyoUXO}HhjXil(wcaWu)64>+I$*Q zwllk0xRKXgH=DR}_I}0-N%sZe{bpO4lv2_y=fP zp)aFTvdxbg2eU*eKD{`{&t&&5rR|)4EevX*42|xQ#$cOBMp3z9@!3wqsuf59HzgUk z)<^6Vr>J9L86r7m7F}s0{ejMo@W~pHyD&;py@Ce8fho;p-ma{Y^eJv9@MwFup%FQ9 z%~*2OO+TD%ml@?|o24Cla)(ge3VF}8h4a4*4wfGDZP7)=qqVUx6sLGlEs}w zGhaEU$=)KWo|ooK8>1MkQW=ihOoq`7RhP6}+#z#HK~eJKLIv8|4ZOlBN}#6WW(w7O zr!;WJE22<8D0)9kmb>$$zTcJ2OG&P$DB@w53f#c3Pci_^itEz^<0Jy*}(v=ZZ51X zNox1mRqE-i5L;YTxTH0EJ!G26vJyOJmm#;yF7qAX*nE1H&00Gqv2-Te2c()O15Kw9 zBUwlk-Dfaz`$@4m2_Er%S}yvvgcCX3JDr?~Z#IhC*CWrAFZS5q+oF#*6#`HEVvBys zjQpoJ?pJ!?OK@UytMWsuCeoHSSgzmD#^@kkrr370ICnTCk&7OZx0E=1_;RNc$@U_LUU|Hxy($u!$3W#r zf|L01V9l&&V{FxNBQ*%lu{f_P+g!C(JO&Y!pQ`e%Y@fQM?VUBse(t8ysPa6`ngs0E z?_(n6hXT^%kVqp>U_<8yRcYg-Ydgg2aVc|(4p;jDk@ePgfSp80BH#cut8O6_bhw?P{!|940>I;mkd# zt?NOVY|_#+L))he-6MhWJjB_o&7hE5vs+{vLn$*8KUZ9sve|1tdCfc3u0HJu$_Bn2 zi@E*9u!H(7Q8_D4hR+-;$wM>J$0h=~fVfb|lI(4zs(q`>=I?CABFOY(VR~X=oTKD{ ze2^#9bf_YQ;l0%zU&ou|O&2@vrL?nD-clfIeCu99xV z^kPsHI6Zljr%E~&XD?{drL{6lcKkYikyA|Z43)I~opBOW>`@*DS&HXY4Y?_%2JWF6 zveDBXX6Bo9VXR z7Hf!>h~{FKiV`~tT+q=AI^HA7Pl;oqS}IuM@_18lThORuuMKbwY&(t(aZb$D@|)Qv z;|lScHyY0ObGwqrZTPxis1dSJ3l68We106_wY5pr8cb)~ft1!Xclo_mf8^LWkRSNl z!}uiw^qsh0I6Dc49_a zb)lv=I$9=g6v(aOAE=oPm4;_@yj1gJ=Ah(4yC1V9sp5%b_Nu*IDm^Gt z#%8pl(s#k!o~_fMm1&5F$|V9Z3-@e9qBpl@+Tp%M8LkiKx%@Py+WuvpPH^ccb;wg05TXV$GI4 z?O878W;W!(lN5Qz;`MI1Gn5k3)NzJGF;qwJb{(_s$Le(;8~G{CvfIk#mawduee!TV z8iOa(x>3-{Zm3!KaeVOU%PQBtS4m}H)gkpbtG0U!ChqU%l0806pLYl3zYEK3Tnx>r zlI-dJbg*liN1n3FeKhBDa^WaPZQg1z7&Q;D4kd84lDC{1t}2lGpz=*ZQ})wwG(2ofZ+@BDI^N1=bG?K z*O zT{a1F>doU?Z$6-E>u?{}*3>jP&zz#8epDZ%#e1ZdE%y-u!kF3+F5K&KHHB<_-WXto zrm4YYt{`*1l*IWgT0^kKfgf_KT@szd?JPmdic!i5gWGI<@u6)z&xo8AFVoaPv_{gS z8c5;PHAWs~YI=cQQ(Jz(9aEEjdvdxqYNTtGd}qK#G7Y7F!*CtqqrNa0CBxgaK8j|p zS-d$u1g_B*eN#ZGx;9J>kxfLe_u`r)sF)_0rRciT9>T5gnB9Rr6Qa+O)IJ!M7JupH zq7*FYl3pD?ANzAY+-n*CD749DH)!x#nV4l7Icd1J@KBa`#$U>1m~o(W@=?s?at)0( zCQ7j?)gpHOD3+bHe!4#r;TpV)rysdTeG;~Wb#9cHs(u)0*v;Oc^{|?ZDL|ffip_T} zj@Wy*J2Yi>Cy*>dofGP8y@CZ8rz|lkAf?qRV!GlPB|D{fabK{5m zn`xElrgL1c#6}b`lO0XH;F+iy8R^;Efx7K?Z8z@xUTZ!s`e0vY;C^b&e=mDO{M+nJ z*2aV>uqSD>uHZ7q_M1jP^9mpEkz%LovdJLj7Fj3eJg}gvvyOhGnF= zK5+A_7G}=$qB1-7xpw&)F01}kbw;JOcuD%3VA%4!2)Z#XPS*A|12X#NcL&N|hhfv9rtvyKNL0 zb10iRX;@Ms>)BBa>6A#Uy#jd*9j$dHem}y6Fi~l=;rmvPnTB9s!;%(7zd+OgzuYb5IiX|a5BB3z1@>`^^L8dX<(-e-r3e5~p5 zkkMz+^J0Ayn7C7clIAKNzp^*KU!19n(xEZaRY~3E>wP$xOkgJ3IJ8^=q0knV0NH|i zs10I%*U&lQ9vn8&z69BJrAQh?qU$t>TG1Oc)1H(bI`aruIU!hg$q!1|<~j<;yZO{p z@wPz`8y8G&AW`f7>QumCXq}!#RJ3M}#`reIX8H~Cw2?M7m`bjCQK7#X@$(d)nx`|J zCmjXZGOfQ6b_y!)9FKBP*RUXs?Ty2TRFc$Atod8b`Yy=dQ$4T0Lio@u;=h;bA^uIO zN0#@+Ac2LE$g%OP@og)~o?;S}#^ys1s#I_DEf1fDy+k5H5BiO^(y;~-3@7Qbb?8C~ z3cMxo=H#>Ovb9KQE@JB1Dcq&xogsZ)B}BNH&|(*OyS};2>pXq%)Cs?|=f{oG-<-Tb z0EJ4@hlzf)NN#q6mXW$9&d(}HX`Zwi??t%$0x59AZuHUH9Uhjn+ZAqZdCb}4?exkA z#j#U@4%;4L&@F2zdL=q>TxAuU934&=#$)kQKuSz1UoC_+Ty>drzZA14`Mg?booZ9} z<`C!o8iu-_+}c#+n!4AXyX-U1V43cwLRW{n?X8}ZGNr^Xr-%^qC&y)SOBCDQ=rp)w zoHLm_N~>HBg#sK1pFwlIyUW?uzM3OPY|C{oo5LN8P$RDVhy|(9agquq*fBU|P7@66 zgS1yhj^FTNwYPz0(|)gnCBxzAtSgB~*EzjhkXex_cFa;zSt51R_QNgq?*-aL$*Z052-2rt92N~+yB zWOr8Wh&3E8_`U9Yq$XHU@AR{793c;w7~R(4gh5>nXW33YkNe*5i%M z(;2)YPiDW;dkB++K=BKM5 zko8EHtv@=W>AlcMCG%d}jRaIR@0ab_{5tXzdzK17a$}v5y-jLVzOQdtIoU32k38Nx zt{AjUG(3}vFWbpx+1mAX&>uLUoIlQIy#`V6_;;!heTgIU!wJ)hF@{&ZcecwN* z?SbQO%S5VF=mo)<54Y=FCrnuBNy2LsiN^Vv9=oZQw<(*EA)ie&c2MxxVNZeW`pEgY zL@utH+ah{D)l;bzT^NA7xk*0Ap4UBSor){iw~+UY(g>?Vw7E-FYGW!B z?3VaQ9p1D5TI%<6#L<-|@r8!*q|Fg6x-6N8HB3o%OE zLaa}P2N`9ek4spJ@%_5PpqN?K3(6p(pEIoKvEeY~7wRD&k!Jd2X>+@=5ALRe2Foxq zrOvgUK9+c4m^53*$HYY@mv&LIk*X36by64*>LfdT9tP!j*Eq=4&}H*wZ=jZ3u!`tC zTE`lT$YCy7crhdHq$?7wMU&B^+~1!=q;PniM^rfMvvWixvt`=j``~K9$SmN&!7R-CflHFDd1Sv%j=+sn)67 zklJ0{h}=9qz30agM8!!=U@DhhbYdJZxn*BZ*WVl5kE{_v0>9;Ni~Er_qJK>hgF>MH zMNHkc%)g6Q{whBqh*yW7Q@pM0*4bwK+-?zBY^#r60pFzJ{e;)t^VWLfF-hvM;N#pD zE47zXZPe;EDt-HM)(eZga)SHF5JI@h`8=N+B1a&du44@*xlDES#77$)wR zGEF3HVz_SYZVZie1oz3xoDj0hfk;FBRok$J?OF}tYb7{M1lvX0ABNp@J`DqX+y-c^ z=07G0@X8_nypi{Ny1T^C2zG2Nu53e5fJdpF+Yw%KW3_R%G>+H@-m0%IY^^2Aa9$Ucs%c|$zCbx<|o;1 zxNxQ7810X1iK4M__G^_jb?d4&u8tK*&+0zv6d~iWMWpQ*RfTRvGRpR_aPOv?rvy?_ zn(mRysmWj*IR?t;Oi%KB-Wkh%#Ay<)?jag6fBG`Ct>+MMltMeluc6;ImD?beXKVwp z<5!p-WO-(Z@_7R(SW(lc^v3CWCq-wA6(_4p+f~0?h(W!esY$MApZU!G+(RSg@5SvS zD>DP-O3iTX|LKFeL&g7pd(YP!m2V^iuIBtMW}u$Q`CA-6f>lWZ?TlCL)(F(03c5O z{^f@^4g8bu-+s_BKM0v0l&||~s^=#tzyhK5EC2Zs1dzW30f6LH*$FJ80?NIpkcG5YozmTv51*)WelJsxq_0t1YqDa}homZevRN3Dj`_l