From 64e7b2746076e1823505a0b930daedf0ce303d4f Mon Sep 17 00:00:00 2001 From: Andrew McMillan Date: Wed, 30 May 2007 20:51:39 +1200 Subject: [PATCH] Remove all of the externally source docs from the repository. --- docs/.gitignore | 10 +- docs/IETF-CAP-RFC4324.txt | 7342 ------------- docs/draft-dawson-ical-xml-dtd-01.txt | 1368 --- docs/draft-desruisseaux-caldav-sched-02.html | 716 -- docs/draft-ietf-calsch-many-xcal-02.txt | 2971 ------ docs/dusseault-caldav-15.txt.html | 6502 ------------ docs/dusseault2005CalDAV.pdf | Bin 313171 -> 0 bytes docs/rfc2445.html | 8342 --------------- docs/rfc2518.html | 5109 --------- docs/rfc2616.html | 9901 ------------------ 10 files changed, 9 insertions(+), 42252 deletions(-) delete mode 100644 docs/IETF-CAP-RFC4324.txt delete mode 100644 docs/draft-dawson-ical-xml-dtd-01.txt delete mode 100644 docs/draft-desruisseaux-caldav-sched-02.html delete mode 100644 docs/draft-ietf-calsch-many-xcal-02.txt delete mode 100644 docs/dusseault-caldav-15.txt.html delete mode 100644 docs/dusseault2005CalDAV.pdf delete mode 100644 docs/rfc2445.html delete mode 100644 docs/rfc2518.html delete mode 100644 docs/rfc2616.html diff --git a/docs/.gitignore b/docs/.gitignore index ededfe99..1f6b788e 100644 --- a/docs/.gitignore +++ b/docs/.gitignore @@ -1,3 +1,11 @@ +IETF-CAP-RFC4324.txt +draft-dawson-ical-xml-dtd-01.txt +draft-desruisseaux-caldav-sched-02.html +draft-ietf-calsch-many-xcal-02.txt +dusseault-caldav-15.txt.html +dusseault2005CalDAV.pdf rfc2068.html +rfc2445.html +rfc2518.html +rfc2616.html rfc3744.html -rfc3744.txt diff --git a/docs/IETF-CAP-RFC4324.txt b/docs/IETF-CAP-RFC4324.txt deleted file mode 100644 index ba0a2884..00000000 --- a/docs/IETF-CAP-RFC4324.txt +++ /dev/null @@ -1,7342 +0,0 @@ -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 deleted file mode 100644 index 57ec7b84..00000000 --- a/docs/draft-dawson-ical-xml-dtd-01.txt +++ /dev/null @@ -1,1368 +0,0 @@ -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-desruisseaux-caldav-sched-02.html b/docs/draft-desruisseaux-caldav-sched-02.html deleted file mode 100644 index 8285f63d..00000000 --- a/docs/draft-desruisseaux-caldav-sched-02.html +++ /dev/null @@ -1,716 +0,0 @@ - - - - - Scheduling Extensions to CalDAV
Network Working GroupC. Daboo
Internet Draft
- <draft-desruisseaux-caldav-sched-02> - B. Desruisseaux
Intended status: InformationalOracle
Expires: December 2006L.M. Dusseault
OSAF
June 2006

Scheduling Extensions to CalDAV
draft-desruisseaux-caldav-sched-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress”.

The list of current Internet-Drafts can be accessed at <http://www.ietf.org/ietf/1id-abstracts.txt>.

The list of Internet-Draft Shadow Directories can be accessed at <http://www.ietf.org/shadow.html>.

This Internet-Draft will expire in December 2006.

Copyright Notice

Copyright © The Internet Society (2006). All Rights Reserved.

Abstract

This document specifies a set of methods, headers and resource types that define the scheduling extension to the CalDAV protocol. CalDAV itself extends WebDAV, which extends HTTP. The new protocol elements defined here allow interoperable scheduling operations on a CalDAV repository.

Table of Contents

1. Introduction

This document specifies a set of methods, headers, properties and privileges that define the CalDAV [I-D.dusseault-caldav] scheduling extensions to the WebDAV [I-D.ietf-webdav-rfc2518bis] protocol. This document also provides the transport specific information necessary to convey iCalendar [RFC2445] Transport-independent Interoperability Protocol iTIP [RFC2446] over WebDAV which enables transactions such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel iCalendar-based calendar components, as well as search for available busy time information.

Discussion of this Internet-Draft is taking place on the mailing list <http://lists.osafoundation.org/mailman/listinfo/ietf-caldav>.

1.1 XML Namespaces

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, or in other Standards Track IETF RFCs written to extend CalDAV. It MUST NOT be used for proprietary extensions.

Note that the XML declarations used in this document are incomplete, in that they do not include namespace information. Thus, the reader MUST NOT use these declarations as the only way to create valid CalDAV properties or to validate CalDAV XML element types. Some of the declarations refer to XML elements defined by WebDAV which use the "DAV:" namespace. Wherever such elements appear, they are explicitly given the "DAV:" prefix to help avoid confusion. Additionally, some of the elements used here are defined in CalDAV [I-D.dusseault-caldav].

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.

1.2 Notational Conventions

The augmented BNF used by this document to describe protocol elements is described in Section 2.1 of [RFC2616]. Because this augmented BNF uses the basic production rules provided in Section 2.2 of [RFC2616], those 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 [RFC2119].

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 types respectively.

1.3 Terminology

Scheduling message:
A message that describes a transaction such as publish, schedule, reschedule, respond to scheduling requests, negotiation of changes or cancel calendar components.
Free busy message:
A message that describes a transaction such as publish unsolicited busy time information, request busy time information, or respond to a busy time request.

2. Required Scheduling features

This section lists what functionality is required of a CalDAV scheduling server. To advertise support for this specification a server:

  • MUST support the CALDAV:schedule privilege and its sub-privileges.
  • MUST support the CALDAV:schedule-inbox and CALDAV:schedule-outbox collection resource types.
  • MUST support the POST method with the Recipient and Originator request headers targeted at a CALDAV:schedule-outbox collection resource types.
  • MUST support iTIP [RFC2446].

A CalDAV scheduling server MAY also support the CalDAV calendar-access feature [I-D.dusseault-caldav], and that adds the following requirements:

MUST support the CALDAV:calendar-query and CALDAV:multiget REPORTs on CALDAV:schedule-inbox and CALDAV:schedule-outbox collection resource types.

3. CalDAV Scheduling Support Discovery

If the server supports the calendar scheduling features described in this document it MUST include "calendar-schedule" as a field in the DAV response header from an OPTIONS request on any resource that supports any scheduling properties, privileges or methods.

3.1 Example: Using OPTIONS for the Discovery of Support for CalDAV

>> Request <<

-OPTIONS /lisa/calendar/outbox/ HTTP/1.1
-Host: cal.example.com
-

>> Response <<

-HTTP/1.1 200 OK
-Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
-Allow: MKCOL, PROPFIND, PROPPATCH, REPORT, ACL
-DAV: 1, 3, access-control, calendar-access, calendar-schedule
-Content-Length: 0
-

In this example, the OPTIONS response indicates that the server supports both the calendar-access and calendar-schedule features and that /lisa/calendar/outbox/ can be specified as a Request-URI to the POST method.

4. Scheduling Process

The process of scheduling a meeting between different parties often involves a series of steps with different "actors" playing particular roles during the whole process. Typically there is a meeting "Organizer" whose role is to setup a meeting between one or more meeting "Attendees", and this is done by sending out invitations and handling responses from each Attendee.

This process can typically be broken down into two phases.

In the first phase the "Organizer" tries to determine a time for the meeting that ought to be the most acceptable to each Attendee. This involves finding out when each Attendee is available during the period of time in which the meeting needs to occur, and determining when the most appropriate time is for which each Attendee is free. This process is called a "free-busy" lookup.

In the second phase the "Organizer" sends out invitations to each Attendee using the time determined from the free-busy lookup - or a suitable guess as to an appropriate time based on other factors if free-busy lookup is not feasible. There then follows a process of negotiation between "Organizer" and "Attendees" regarding the invitation. Some Attendees may choose to attend at the original time provided by the Organizer, others may decline to attend at that time, but suggest another time, others may decline to attend at any time. The "Organizer" needs to process each of the replies from the Attendees and take appropriate action to confirm the meeting, reschedule it or perhaps cancel it depending on those replies.

The user "expectation" as to how a calendaring and scheduling system should respond in each of these two phases is somewhat different. In the case of a free-busy lookup, users expect to get back results immediately so that they can then move on to the invitation phase as quickly as possible. In the case of invitations, its expected that each Attendee will reply in his or her own time, so delays in receiving replies are anticipated. Thus calendaring and scheduling systems should treat these two operational phases in different ways to accommodate the user expectations, and this specification does that.

4.1 Scheduling Collections

It is useful for each participant in a scheduling transaction to maintain their own "history" of invitations sent and received during the process and after to keep track of what was done, and to properly handle updates to invitations as they may change over time. This history is usually kept separate from the actual "booked" event, to-do, or daily journal entry, which would normally be placed in a user's calendar collection.

In addition, it is useful to keep outgoing invitations separate from incoming ones for organizational purposes.

Also, a calendar user may have multiple calendars representing different spheres of activity, but scheduling requests are targeted at calendar user addresses, and there is no formal way to have those indicate which sphere of activity they might apply to. By storing all incoming scheduling requests in a separate collection, clients can process the requests in that collection and choose what calendar the request belongs to and make its own arrangements to place the relevant calendar object in that calendar to "book" it.

This specification introduces two new collection resource types that are used for keeping incoming and outgoing scheduling messages separate from other calendar object resources. These can also be used to control who is able to send scheduling messages on behalf of a user, and who is allowed to send scheduling messages to other users by the use of new WebDAV ACL [RFC3744] privileges. Note that these collections only contains scheduling messages that pertains to the scheduling of events, to-dos and daily journal entries. Scheduling messages that describes requests for available busy time information, or replies to such request, are not contained in these collections.

The scheduling "Inbox" collection contains received scheduling messages. Scheduling messages are contained in calendar object resources. Each calendar object resource has a WebDAV property that indicates whether the scheduling message has already been processed or not so that multiple clients do not repeat the processing actions already done.

The scheduling "Outbox" collection contains scheduling message that have been sent, which need to be tracked both to help synchronize between multiple clients and to support delegation use cases. A single user with multiple clients can use this collection to synchronize the outbound request history. Two users coordinating scheduling with one calendar (e.g., a calendar user and her assistant) can see what scheduling messages the other user has sent. The calendar owner would then typically have permission to DELETE the scheduling messages but the assistant might not.

4.2 Scheduling Transactions

The iCalendar Transport-independent Interoperability Protocol (iTIP) [RFC2446] outlines a model for scheduling and free-busy message exchanges to perform scheduling transactions. This specification makes use of scheduling free-busy messages to handle scheduling transactions on the server by having such messages passed between different users on the server depending on their role in the scheduling process.

To that end each scheduling message is modeled as a calendar object resource which contains the iCalendar object that conforms to the iTIP requirements for the type of transaction being requested.

This specification defines the POST method, acting on an Organizer's scheduling Outbox, to trigger schedule processing by the server. This can take one of two forms: for free-busy messages the POST request returns immediately with free busy results; for scheduling messages, a copy of the scheduling message specified in the request body is deposited into each recipient's scheduling Inbox.

The server may support delivery of scheduling messages to other CalDAV servers, and the client may attempt to get the server to do this by specifying remote addresses for the recipients, but the server is not bound to support or complete remote delivery operations even if it advertises support for the "calendar-schedule" feature. Note that remote delivery mechanisms are not defined in this specification. This specification does not define a server-to-server or server-to-client protocol to deliver scheduling messages. Implementations may do this in a proprietary way, with iMIP [RFC2447], or with iTIP bindings as yet unspecified.

After the delivery is completed, CalDAV clients will see the scheduling message the next time they synchronize or query a scheduling Inbox collection. To reply to a scheduling REQUEST, the client uses the POST method to send another scheduling message (this time, a REPLY) back to the Organizer. If the user has decided to accept the REQUEST, the client can create a suitable calendar object resource in the appropriate calendar collection for the recipient. The step of putting the calendar object resource in the calendar is left up to the client, so that the client can make appropriate choices about where to put the calendar object resource, and with what alarms, etc. However, the server MAY be configured to automatically accept or reject invitations, and if the server auto-accepts invitations then the server is responsible for creating calendar object resources in a calendar collection specified by the user.

5. New Resource Types and Properties

The CalDAV scheduling extension defines the following new resource types for use with CalDAV.

5.1 Scheduling Inbox Collection

A scheduling Inbox collection contains incoming scheduling messages. These may be requests sent by an Organizer, or replies sent by an Attendee in response to a request.

A scheduling Inbox collection MUST report the DAV:collection and CALDAV:schedule-inbox XML elements in the value of the DAV:resourcetype property. The element type declaration for CALDAV:schedule-inbox is: 

-   <!ELEMENT schedule-inbox EMPTY>
-

Example: 

-   <resourcetype xmlns="DAV:">
-     <collection/>
-     <C:schedule-inbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-   </resourcetype>
-

Every non-collection resource in the scheduling Inbox collection MUST be a valid calendar object resource that defines a scheduling message (e.g., an iCalendar object that follows the iTIP semantic). Note, that unlike calendar collections defined by the calendar-access feature, there are no restrictions on the nature of the resources stored (e.g., there is no need to verify that the UIDs in each resource are unique) beyond the restrictions of iTIP itself. The removal of the UID restriction, in particular, is needed because multiple scheduling messages may be sent for one particular calendar component, and each of those will have the same UID property in the calendar object resource.

A new access control privilege can be defined on the scheduling Inbox collection and can be used to control who is allowed to send scheduling messages to the owner of the scheduling Inbox. See Section 8.1 for more details.

5.2 Scheduling Outbox Collection

A scheduling Outbox collection contains outgoing scheduling messages. These may be requests initiated by or on behalf of the owner of the scheduling Outbox, or responses to requests received by the owner of the scheduling Outbox.

A scheduling Outbox collection MUST report the DAV:collection and CALDAV:schedule-outbox XML elements in the value of the DAV:resourcetype property. The element type declaration for CALDAV:schedule-outbox is: 

-   <!ELEMENT schedule-outbox EMPTY>
-

Example: 

-   <resourcetype xmlns="DAV:">
-     <collection/>
-     <C:schedule-outbox xmlns:C="urn:ietf:params:xml:ns:caldav"/>
-   </resourcetype>
-

Every non-collection resource in the scheduling Outbox collection MUST be a valid calendar object resource that defines a scheduling message (e.g., an iCalendar object that follows the iTIP semantic). When a client targets the POST method at a scheduling Outbox, the server MUST create a copy of the scheduling message in that scheduling Outbox, unless the POST method corresponds to a free-busy message, in which case the server MUST NOT store a copy of the free-busy message. Copies that are created serve as a record of outgoing scheduling messages.

The server MAY auto-delete calendar object resources in the scheduling Outbox (e.g., after a period of time or to keep within a quota). The server SHOULD allow deletion of calendar object resources in the scheduling Outbox.

A new access control privilege can be defined on the scheduling Outbox collection and can be used to control who is allowed to send scheduling messages on behalf of the owner of the scheduling Outbox. See Section 8.1 for more details.

5.3 Scheduling Inbox Properties

This section describes new WebDAV properties on scheduling Inbox collection resources.

5.3.1 CALDAV:calendar-free-busy-set Property

Name:
calendar-free-busy-set
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the calendars that contribute to the free-busy information for the owner of the scheduling Inbox.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of [I-D.ietf-webdav-rfc2518bis]). Support for this property is REQUIRED.
Description:
This property is required to allow a POST request to automatically determine the free busy information for each specified Recipient for immediate return in the response. A server with a fixed set of calendars per user can make this property protected. A server that allows users to create their own calendars SHOULD allow users to change their own property value.
Definition:
-   <!ELEMENT calendar-free-busy-set (DAV:href*) >
-
Example:
-   <C:calendar-free-busy-set xmlns:D="DAV:"
-                         xmlns:C="urn:ietf:params:xml:ns:caldav">
-     <D:href>/calendars/bernard/work/</D:href>
-     <D:href>/calendars/bernard/home/</D:href>
-     <D:href>/public/holidays/CA/</D:href>
-   </C:calendar-free-busy-set>
-

5.4 Calendar Object Resource Properties

This section describes new WebDAV properties for calendar object resources stored in scheduling Inbox or Outbox collections.

5.4.1 CALDAV:originator Property

Name:
originator
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Indicates the Originator of the scheduling message contained in a scheduling Inbox or Outbox collection.
Conformance:
This property 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:originator property MUST be defined on calendar object resources stored in an Inbox or Outbox collection as the result of a POST request. The value of the property MUST be the value of the Originator request header in the POST request that caused the resource to be created in the collection.
Definition:
-   <!ELEMENT originator (DAV:href)>
-   DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])
-
Example:
-   <C:originator xmlns:D="DAV:"
-                 xmlns:C="urn:ietf:params:xml:ns:caldav">
-     <D:href>mailto:bernard@example.com</D:href>
-   </C:originator>
-

5.4.2 CALDAV:recipient Property

Name:
recipient
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
On a calendar object resource contained in a scheduling Outbox collection, this indicates the list of Recipients to whom the scheduling message was sent. On a calendar object resource in a scheduling Inbox collection, this indicates the recipient calendar user address that caused the scheduling message to be delivered into the scheduling Inbox.
Conformance:
This property 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:recipient property MUST be defined on calendar object resources stored in a scheduling Outbox or Inbox collection as the result of a POST request. For calendar object resources in a scheduling Outbox, the value of the property MUST be a list of calendar user addresses formed from all the addresses in any Recipient request headers in the POST request that caused the resource to be created in the collection. For calendar object resources in a scheduling Inbox, the value of the property MUST be the calendar user address from the Recipient request header in the POST request that caused the resource to be created in the collection. Typically this address will be one of those listed in the CALDAV:calendar-user-address-set (see Section 8.2.3) property for the principal that owns the scheduling Inbox. However, it could, for example, be a calendar user address of a group that includes the owner of the scheduling Inbox.
Definition:
-                  
-   <!ELEMENT recipient (DAV:href+)>
-   DAV:href value: a CAL-ADDRESS (see Section 4.3.3 in [RFC 2445])
-            
-
Example:
-   <C:recipient xmlns:D="DAV:"
-                xmlns:C="urn:ietf:params:xml:ns:caldav">
-     <D:href>mailto:cyrus@example.com</D:href>
-     <D:href>mailto:lisa@example.com</D:href>
-   </C:recipient>
-

5.4.3 CALDAV:schedule-state Property

Name:
schedule-state
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Indicates the state of a scheduling message in a scheduling Inbox.
Conformance:
This property 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]).
Description:
The CALDAV:schedule-state property MUST be defined on any calendar object resource in a scheduling Inbox collection. If present, the property indicates whether the scheduling message has been processed or not. Processing might have occurred as a result of some form of automatic processing by the server or through a client action. Clients MUST ensure that they set this property value to indicate a processed state when they have processed the scheduling message. This ensures that other clients with access to the same resource don't attempt to repeat the actions required to reply. Clients MUST NOT process a scheduling message that has this property indicates the scheduling message has been processed. When the scheduling message is delivered into the scheduling Inbox the server MUST set this property value to indicate that the scheduling message has not been processed.
Definition:
-   <!ELEMENT schedule-state (not-processed|processed)>
-
-   <!ELEMENT not-processed EMPTY>
-   <!ELEMENT processed EMPTY>
-
Example:
-   <C:schedule-state xmlns:C="urn:ietf:params:xml:ns:caldav">
-     <C:processed/>
-   </C:schedule-state>
-

6. Scheduling

6.1 POST Method

The POST method submits a scheduling or free-busy message to one or more recipients by targeting the request at the URI of a scheduling Outbox collection. The request body of a POST method MUST contain a scheduling message or free-busy message (e.g., an iCalendar object that follows the iTIP semantic). The resource identified by the Request-URI MUST be a resource collection of type CALDAV:schedule-outbox (Section 5.2).

A submitted scheduling message will be delivered to the calendar user addresses specified in the Recipient request header. A submitted free-busy message will be immediately executed and a free-busy response returned.

Preconditions:

(CALDAV:supported-collection): The Request-URI MUST identify the location of a scheduling Outbox collection;
(CALDAV:supported-calendar-data): The resource submitted in the POST request MUST be a supported media type (i.e., text/calendar) for scheduling or free-busy messages;
(CALDAV:valid-calendar-data): The resource submitted in the POST request MUST be valid data for the media type being specified (i.e., valid iCalendar object);
(CALDAV:valid-scheduling-message): The resource submitted in the POST request MUST obey all restrictions specified for the POST request (e.g., scheduling message follows the restriction of iTIP);
(CALDAV:originator-specified): The POST request MUST include a valid Originator request header specifying a calendar user address of the currently authenticated user;
(CALDAV:originator-allowed): The calendar user identified by the Originator request header in the POST request MUST be granted the CALDAV:schedule privilege or a suitable sub-privilege on the scheduling Outbox collection being targeted by the request;
(CALDAV:organizer-allowed): The calendar user identified by the ORGANIZER property in the POST request's scheduling message MUST be the owner (or one of the owners) of the scheduling Outbox being targeted by the request;
(CALDAV:recipient-specified): The POST request MUST include one or more valid Recipient request headers specifying the calendar user address of users to whom the scheduling message will be delivered.

Postconditions: None

6.1.1 Originator request header

Every POST request MUST include an Originator request header that specifies the calendar user address of the originator of a given scheduling message. The value specified in this request header MUST be a calendar user address specified in the CALDAV:calendar-user-address-set property defined on the principal resource of the currently authenticated user. Also, the currently authenticated user MUST have the CALDAV:schedule privilege or a suitable sub-privilege granted on the targeted scheduling Outbox collection.

Typically the Originator request header's value will correspond to the Organizer of the calendar component and to the owner of the Outbox being targeted by the request. However, the Organizer may choose to allow another user to act on his behalf to send scheduling messages. To allow for this a new privilege has been defined to allow the owner of a scheduling Outbox to grant to other users the right to execute POST requests on that Outbox.

The value of the Originator request header is kept in the CALDAV:originator property on any resources saved as a result of the schedule request. This includes the copy of the scheduling message saved in the scheduling Outbox, and scheduling messages delivered to any scheduling Inbox.

6.1.2 ORGANIZER Property

iTIP requires that every scheduling message contains an ORGANIZER property identifying the calendar user address of the Organizer of the calendar object. To prevent 'spoofing' (forgeries) of scheduling messages, CalDAV servers MUST verify that the calendar user address identified by the ORGANIZER property in the scheduling message data corresponds to the principal owning the scheduling Outbox targeted by the POST request. This MUST be done during the processing of the POST request.

6.1.3 Recipient request header

Every POST request MUST include one or more Recipient request headers in the headers. The value of this header is a list of one or more calendar user addresses and corresponds to the set of calendar users who will be delivered the scheduling message. The owner of the scheduling Outbox being targeted by the POST method MUST have the CALDAV:schedule privilege or a suitable sub-privilege granted on the scheduling Inbox collection of each recipient.

Typically the list of recipients would correspond to any ATTENDEE property values listed in the scheduling message data. However, there are cases when an ATTENDEE is not listed as a Recipient, or when a Recipient is not one of the ATTENDEE's.

For example, if the Organizer of an event wishes to attend the event themselves, they must list themselves as one of the ATTENDEE's, as the ORGANIZER of an event does not implicitly attend. However, the Organizer does not need to receive an invitation as they know their own participation status, so there is no need to be listed as a Recipient of the scheduling message.

Alternatively, a client may have determined participation status of some ATTENDEE's out-of-band and has no need to send another request via CalDAV.

In some cases it is handy to be able to send information about a meeting to someone who is not an ATTENDEE. In that case, there would be a Recipient in the request without a corresponding ATTENDEE property in the scheduling message data.

Note that the recipient of a CalDAV scheduling message has no knowledge of who the other recipients were - they only get to see the ATTENDEE information listed in the scheduling message data. So listing a calendar user as a Recipient and not an ATTENDEE is the equivalent of a 'Bcc' (blind-carbon-copy) operation in email.

6.1.4 Response to a POST request

A POST request may deliver a scheduling message to one or more calendar users specified in the Recipient request header. Since the behavior of each recipient may vary, it is useful to get response status information for each recipient in the overall POST response. This specification defines a new XML response to convey multiple recipient status.

A response to a POST method that indicates status for one or more recipients MUST be a CALDAV:schedule-response XML element. This MUST contain one or more CALDAV:response elements for each recipient, with each of those containing elements that indicate which recipient they correspond to, the scheduling status of the request for that recipient, any error codes and an optional description. See Section 10.1.

In the case of a free-busy request, the CALDAV:response elements can also contain CALDAV:calendar-data elements which contain free busy information (e.g., an iCalendar VFREEBUSY component) indicating the busy state of the corresponding recipient, assuming that the free-busy request for that recipient succeeded.

6.1.5 Status Codes for use with the POST method

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

200 (OK) - The command succeeded.

400 (Bad Request) - The client has provided an invalid scheduling message.

403 (Forbidden) - The client, for reasons the server chooses not to specify, cannot submit a scheduling message to the specified Request-URI.

404 (Not Found) - The URL in the Request-URI, the Originator, or the Recipient request headers were not present.

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.

502 (Bad Gateway) - The Recipient request header contained a URL which the server considers to be in another domain, which it cannot forward scheduling messages to.

507 (Insufficient Storage) - The server did not have sufficient space to record the scheduling message in a recipient's scheduling inbox.

6.1.6 Example - Simple meeting invitation

>> Request <<

-            
-POST /lisa/calendar/outbox/ HTTP/1.1
-Host: cal.example.com
-Originator: mailto:lisa@example.com
-Recipient: mailto:bernard@example.com
-Recipient: mailto:cyrus@example.com
-Content-Type: text/calendar
-Content-Length: xxxx
-
-BEGIN:VCALENDAR
-VERSION:2.0
-PRODID:-//Example Corp.//CalDAV Client//EN
-METHOD:REQUEST
-BEGIN:VEVENT
-DTSTAMP:20040901T200200Z
-ORGANIZER:mailto:lisa@example.com
-DTSTART:20040902T130000Z
-DTEND:20040902T140000Z
-SUMMARY:Design meeting
-UID:34222-232@example.com
-ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
- IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.c
- om
-ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Bernard Desr
- uisseaux:mailto:bernard@example.com
-ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
- Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
- mailto:cyrus@example.com
-END:VEVENT
-END:VCALENDAR
-
-

>> Response <<

-            
-HTTP/1.1 200 OK
-Date: Thu, 02 Sep 2004 16:53:32 GMT
-Content-Type: text/xml
-Content-Length: xxxx
-
-<?xml version="1.0" encoding="utf-8" ?>
-<C:schedule-response xmlns:D="DAV:"
-             xmlns:C="urn:ietf:params:xml:ns:caldav">
-<C:response>
-  <C:recipient>mailto:bernard@example.com</C:recipient>
-  <C:request-status>2.0;Success</C:request-status>
-  <D:responsedescription>Delivered to recipient
-  scheduling inbox</d:responsedescription>
-</C:response>
-<C:response>
-  <C:recipient>mailto:cyrus@example.com</C:recipient>
-  <C:request-status>2.0;Success</C:request-status>
-  <D:responsedescription>Delivered to recipient
-  scheduling inbox</d:responsedescription>
-</C:response>
-</C:schedule-response>
-
-

In this example, the client requests the server to deliver a meeting invitation (scheduling REQUEST) to the calendar users mailto:bernard@example.com and mailto:cyrus@example.com. The response indicates that delivery to the relevant scheduling Inboxes of each recipient was accomplished successfully.

Note that the Originator and Organizer calendar user addresses were both set to mailto:lisa@example.com. In order to indicate that she is also attending the meeting, mailto:lisa@example.com also included an ATTENDEE property in the iCalendar data corresponding to her calendar user address, however she did not include a Recipient request header for that calendar user address since she already has here own copy of the meeting stored in a calendar collection.

6.1.7 Example - Free-Busy lookup

TODO:

In this example, the client requests the server to determine the busy information of the calendar users mailto:bernard@example.com and mailto:cyrus@example.com, over the time range specified by the scheduling message sent in the request. The response includes VFREEBUSY components for each of those calendar users with their busy time indicated.

6.2 Retrieving incoming scheduling messages

Incoming scheduling messages will be stored in a scheduling Inbox collection. The same reports work on scheduling collections, so the client can use REPORT to get partial information on scheduling messages in the scheduling inbox.

6.2.1 Example - Retrieve incoming scheduling message

>> Request <<

-            
-GET /bernard/calendar/inbox/mtg456.ics HTTP/1.1
-Host: cal.example.com
-
-

>> Response <<

-            
-HTTP/1.1 200 OK
-Date: Thu, 02 Sep 2004 17:05:23 GMT
-Content-Type: text/calendar
-Content-Length: xxxx
-
-BEGIN:VCALENDAR
-VERSION:2.0
-PRODID:-//Example Corp.//CalDAV Server//EN
-METHOD:REQUEST
-BEGIN:VEVENT
-DTSTAMP:20040901T200200Z
-CATEGORIES:APPOINTMENT
-ORGANIZER:mailto:lisa@example.com
-DTSTART:20040902T130000Z
-DTEND:20040902T140000Z
-SUMMARY:CalDAV draft review
-UID:34222-232@example.com
-ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
- IVIDUAL;CN=Lisa Dusseault:mailto:lisa@example.com
-ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
- ANT;CUTYPE=INDIVIDUAL;CN=Bernard Desruisseaux:
- mailto:bernard@example.com
-ATTENDEE;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIP
- ANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:mailto:cyr
- us@example.com
-END:VEVENT
-END:VCALENDAR
-
-

6.3 Acting on incoming scheduling messages

TODO: Need to explain here how to handle incoming scheduling messages. If the client wants to accept a message, it needs to create an event and mark the calendar object resource as "processed". If the client wants to reject it, it simply changes a property. Need to define that property. Also recommend locking the Inbox resource to avoid race conditions with other clients -- or use ETags to verify.

7. HTTP Request Headers for CalDAV

7.1 Originator Request Header

-          
-   Originator = "Originator" ":" absoluteURI
-  
-

The Originator request header value is a URI which specifies the calendar user address of the originator of the scheduling message. Note that the absoluteURI production is defined in RFC2396 [RFC2396].

7.2 Recipient Request Header

-          
-   Recipient = "Recipient" ":" 1#absoluteURI
-
-

The Recipient request header value is a URI which specifies the calendar user address of the recipients to which the POST method should deliver the submitted scheduling message. Note that the absoluteURI production is defined in RFC2396 [RFC2396]

8. Scheduling Access Control

8.1 Scheduling Privileges

A CalDAV server MUST support the WebDAV ACLs standard [RFC3744]. That standard provides a framework for an extensible list of privileges on WebDAV collections and ordinary resources. A CalDAV server MUST also support the set of calendar-specific privileges defined in this section.

8.1.1 CALDAV:schedule-request Privilege

The CALDAV:schedule-request privilege controls who can initiate scheduling requests, and who will accept such requests.

The CALDAV:schedule-request privilege can be applied to either a scheduling Outbox or Inbox. Its effect depends on the type of collection it is applied to.

When used on a scheduling Outbox, the CALDAV:schedule-request privilege controls the use of the POST method to submit a scheduling message via a scheduling Outbox collection. When granted to a principal, that principal is allowed to use the POST method on the schedule Outbox with the following restrictions:

the iCalendar component in the request body MUST NOT be a VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
the METHOD property in the iCalendar component in the request body MUST be either PUBLISH or REQUEST.

When used on a scheduling Inbox, the CALDAV:schedule-request privilege controls whether a scheduling message can be deposited in the scheduling Inbox collection. When granted to a principal, that principal is allowed to use the POST method to deposit scheduling messages with the following restrictions:

the iCalendar component in the request body MUST NOT be a VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
the METHOD property in the iCalendar component in the request body MUST be either PUBLISH or REQUEST.

<!ELEMENT schedule-request EMPTY >

For example, the following ACE, on Bernard's scheduling Outbox, would only grant the privilege to Bernard to send schedule request messages on behalf of himself:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/bernard</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-request/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

Whereas, the following ACE's, on Cyrus's scheduling Outbox, would grant the privilege to Cyrus and his assistant Kim to send schedule request messages on behalf of Cyrus:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/cyrus</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-request/></D:privilege>
-  </D:grant>
-</D:ace>
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/kim</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-request/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

For example, the following ACE's, on Bernard's scheduling Inbox, would grant the privilege to Lisa to send a schedule request message to Bernard:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/lisa</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-request/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

8.1.2 CALDAV:schedule-reply Privilege

The CALDAV:schedule-reply privilege controls who can respond to scheduling requests, and who will accept such responses.

The CALDAV:schedule-reply privilege can be applied to either a scheduling Outbox or Inbox. Its effect depends on the type of collection it is applied to.

When used on a scheduling Outbox, the CALDAV:schedule-reply privilege controls the use of the POST method to submit a scheduling message via a scheduling Outbox collection. When granted to a principal, that principal is allowed to use the POST method on the schedule Outbox with the following restrictions:

the iCalendar component in the request body MUST NOT be a VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
the METHOD property in the iCalendar component in the request body MUST NOT be either PUBLISH or REQUEST.

When used on a scheduling Inbox, the CALDAV:schedule-reply privilege controls whether a scheduling message can be deposited in the scheduling Inbox collection. When granted to a principal, that principal is allowed to use the POST method to deposit scheduling messages with the following restrictions:

the iCalendar component in the request body MUST NOT be a VFREEBUSY component and the METHOD property MUST NOT be REQUEST.
the METHOD property in the iCalendar component in the request body MUST NOT be either PUBLISH or REQUEST.

<!ELEMENT schedule-reply EMPTY >

For example, the following ACE, on Bernard's scheduling Outbox, would only grant the privilege to Bernard to respond to schedule messages on behalf of himself:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/bernard</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-reply/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

Whereas, the following ACE's, on Cyrus's scheduling Outbox, would grant the privilege to Cyrus and his assistant Kim to respond to schedule messages on behalf of Cyrus:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/cyrus</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-reply/></D:privilege>
-  </D:grant>
-</D:ace>
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/kim</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-reply/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

For example, the following ACE's, on Bernard's scheduling Inbox, would grant the privilege to Lisa to send a scheduling reply message to Bernard:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/lisa</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-reply/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

8.1.3 CALDAV:schedule-free-busy Privilege

The CALDAV:schedule-free-busy privilege controls who can initiate free-busy requests, and who will accept such requests.

The CALDAV:schedule-free-busy privilege can be applied to either a scheduling Outbox or Inbox. Its effect depends on the type of collection it is applied to.

When used on a scheduling Outbox, the CALDAV:schedule-reply privilege controls the use of the POST method to submit a scheduling message via a scheduling Outbox collection. When granted to a principal, that principal is allowed to use the POST method on the schedule Outbox with the following restrictions:

the iCalendar component in the request body MUST be a VFREEBUSY component.
the METHOD property in the iCalendar component in the request body MUST be REQUEST.

When used on a scheduling Inbox, the CALDAV:schedule-free-busy privilege controls whether a scheduling message can be deposited in the scheduling Inbox collection. When granted to a principal, that principal is allowed to use the POST method to deposit scheduling messages with the following restrictions:

the iCalendar component in the request body MUST be a VFREEBUSY component.
the METHOD property in the iCalendar component in the request body MUST be REQUEST.

<!ELEMENT schedule-free-busy EMPTY >

For example, the following ACE, on Bernard's scheduling Outbox, would only grant the privilege to Bernard to request free-busy information on behalf of himself:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/bernard</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-free-busy/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

Whereas, the following ACE's, on Cyrus's scheduling Outbox, would grant the privilege to Cyrus and his assistant Kim to free-busy information on behalf of Cyrus:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/cyrus</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-free-busy/></D:privilege>
-  </D:grant>
-</D:ace>
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/kim</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-free-busy/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

For example, the following ACE's, on Bernard's scheduling Inbox, would grant the privilege to Lisa to retrieve free-busy information for Bernard:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/lisa</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule-free-busy/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

8.1.4 CALDAV:schedule Privilege

The CALDAV:schedule privilege can be applied to either a scheduling Outbox or Inbox. Its effect depends on the type of collection it is applied to. This privilege is actually an aggregate of the CALDAV:schedule-request, CALDAV:schedule-reply and CALDAV:schedule-free-busy privileges.

<!ELEMENT schedule EMPTY >

For example, the following ACE, on Bernard's scheduling Outbox, would only grant the privilege to Bernard to carry out any schedule operation on behalf of himself:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/bernard</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

Whereas, the following ACE's, on Cyrus's scheduling Outbox, would grant the privilege to Cyrus and his assistant Kim to carry out any schedule operation on behalf of Cyrus:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/cyrus</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule/></D:privilege>
-  </D:grant>
-</D:ace>
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/kim</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

For example, the following ACE's, on Bernard's scheduling Inbox, would grant the privilege to Lisa to carry out any schedule operation with Bernard:

-            
-<D:ace xmlns:D="DAV:"
-     xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:principal>
-      <D:href>http://cal.example.com/users/lisa</D:href>
-  </D:principal>
-  <D:grant>
-    <D:privilege><C:schedule/></D:privilege>
-  </D:grant>
-</D:ace>
-
-

8.1.5 Privilege aggregation and the DAV:supported-privilege-set property

The CALDAV:schedule privilege MUST be non-abstract, and MUST be aggregated under the DAV:bind privilege. The CALDAV:schedule privilege MUST appear in the DAV:supported-privilege-set property of scheduling Inbox and Outbox collections.

The CALDAV:schedule-request, CALDAV:schedule-reply and CALDAV:schedule-free-busy privileges MUST be non-abstract, and MUST be aggregated under the CALDAV:schedule privilege. These privileges MUST appear in the DAV:supported-privilege-set property of scheduling Inbox and Outbox collections.

8.2 Additional Principal Properties

This section defines new properties for WebDAV principal resources as defined in RFC3744 [RFC3744]. These properties are likely to be protected but the server MAY allow them to be written by appropriate users.

8.2.1 CALDAV:schedule-inbox-URL Property

Name:
schedule-inbox-URL
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the URL of the scheduling Inbox collection owned by the associated principal resource.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of [I-D.ietf-webdav-rfc2518bis]).
Description:
This property is needed for a client to determine where the scheduling Inbox of the current user is located so that processing of scheduling messages can occur.
Definition:
-   <!ELEMENT schedule-inbox-URL (href)>
-

8.2.2 CALDAV:schedule-outbox-URL Property

Name:
schedule-outbox-URL
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the URL of the scheduling Outbox collection owned by the associated principal resource.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of [I-D.ietf-webdav-rfc2518bis]).
Description:
This property is needed for a client to determine where the scheduling Outbox of the current user is located so that sending of scheduling messages can occur.
Definition:
-   <!ELEMENT schedule-outbox-URL href>
-

8.2.3 CALDAV:calendar-user-address-set Property

Name:
calendar-user-address-set
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Identify the calendar addresses of the associated principal resource.
Conformance:
This property MAY be protected and SHOULD NOT be returned by a PROPFIND allprop request (as defined in Section 12.14.1 of [I-D.ietf-webdav-rfc2518bis] ). Support for this property is REQUIRED. This property SHOULD be searchable using the DAV:principal-property-search REPORT. The DAV:principal-search-property-set REPORT SHOULD identify this property as such.
Description:
This property is needed to map Originator and Recipient values in a POST request to principal resources and their associated scheduling Inbox and Outbox. In the event that a user has no well defined identifier for their calendar user address, the URI of their principal resource can be used.
Definition:
-                  
-   <!ELEMENT calendar-user-address-set (DAV:href*)>
-          
-
Example:
-                  
-   <C:calendar-user-address-set xmlns:D="DAV:"
-                         xmlns:C="urn:ietf:params:xml:ns:caldav">
-     <D:href>mailto:bernard@example.com</D:href>
-     <D:href>mailto:bernard.desruisseaux@example.com</D:href>
-   </C:calendar-user-address-set>
-          
-

8.2.4 Example: Searching for calendars belonging to a user based on a calendar user address

In this example, the client requests the CALDAV:calendar-home-URL of the principal resources whose CALDAV:calendar-user-address-set property contains the substring "mailto:bernard@example.com". In addition, the client requests the DAV:displayname of each principal to also be returned for the matching principals.

The response shows that only one principal resource meets the search specification, "mailto:bernard@example.com".

>> Request <<

-              
-REPORT /users/ HTTP/1.1
-Host: cal.example.com
-Content-Type: text/xml; charset="utf-8"
-Content-Length: xxxx
-Depth: 0
-
-<?xml version="1.0" encoding="utf-8" ?>
-<D:principal-property-search xmlns:D="DAV:"
-            xmlns:C="urn:ietf:params:xml:ns:caldav">
-  <D:property-search>
-    <D:prop>
-      <C:calendar-user-address-set/>
-    </D:prop>
-    <D:match>mailto:bernard@example.com</D:match>
-  </D:property-search>
-  <D:prop>
-    <C:calendar-home-URL/>
-    <D:displayname/>
-  </D:prop>
-</D:principal-property-search>
-

>> 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:C="urn:ietf:params:xml:ns:caldav">
-  <D:response>
-    <D:href>/users/bernard</D:href>
-    <D:propstat>
-      <D:prop>
-        <C:calendar-home-URL>
-          <D:href>/home/bernard/</D:href>
-        </C:calendar-home-URL>
-        <D:displayname>Bernard Desruisseaux</D:displayname>
-      </D:prop>
-      <D:status>HTTP/1.1 200 OK</D:status>
-    </D:propstat>
-  </D:response>
-</D:multistatus>
-

8.2.5 Example: Finding the scheduling Inbox and Outbox belonging to the currently authenticated user

In this example, the client requests the CALDAV:schedule-inbox-URL and CALDAV:schedule-outbox-URL of the currently authenticated user.

TODO: principal-match report

9. Reports

When the calendar-access feature is supported in addition to calendar-schedule, this specification extends the CALDAV:calendar-query and CALDAV:calendar-multiget reports to return results for calendar object resources in scheduling Inbox and Outbox collections when the report directly targets such a collection. i.e. the Request-URI for a REPORT MUST be the URI of the scheduling Inbox or Outbox or of a child resource within a scheduling Inbox or Outbox collection. A report run on a regular collection that includes a scheduling Inbox or Outbox as a child resource at any depth MUST NOT examine or return any calendar object resources from within any scheduling Inbox or Outbox collections.

Note that the CALDAV:free-busy-query report is NOT supported on scheduling Inbox or Outbox collections when the calendar-access feature is also present.

10. XML Element Definitions

10.1 CALDAV:schedule-response XML Element

Name:
schedule-response
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Contains the set of responses for a POST method request.
Description:
See Section 6.1.4.
Definition:
-                
-    <!ELEMENT schedule-response (response*)>
-            
-

10.2 CALDAV:response XML Element

Name:
response
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
Contains a single response for a POST method request.
Description:
See Section 6.1.4.
Definition:
-<!ELEMENT response (recipient,
-                    request-status,
-                    calendar-data?,
-                    DAV:error?,
-                    DAV:responsedescription?)>
-

10.3 CALDAV:recipient XML Element

Name:
recipient
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
The calendar user address (recipient header value) that the enclosing response for a POST method request is for.
Description:
See Section 6.1.4.
Definition:
-                
-    <!ELEMENT recipient (#PCDATA)>
-            
-

10.4 CALDAV:request-status XML Element

Name:
request-status
Namespace:
urn:ietf:params:xml:ns:caldav
Purpose:
The iTIP REQUEST-STATUS property value for this response.
Description:
See Section 6.1.4.
Definition:
-                
-    <!ELEMENT request-status (#PCDATA)>
-            
-

11. Security Considerations

The process of scheduling involves the sending and receiving of scheduling messages. As a result, the security problems related to messaging in general are relevant here. In particular the authenticity of the scheduling messages needs to be verified absolutely. Servers and clients MUST use an HTTP connection protected with TLS as defined in [RFC2818] for all scheduling transactions.

11.1 Verifying scheduling requests

When handling a POST request on a scheduling Outbox:

Servers MUST verify that the principal associated with the calendar user address specified in the Originator request header in the request matches the currently authenticated user.
Servers MUST verify that the currently authenticated user has the CALDAV:schedule privilege or a suitable sub-privilege on the scheduling Outbox targeted by the request.
Servers MUST verify that the principal associated with the calendar user address specified in the ORGANIZER property of the scheduling message data in the request contains a CALDAV:schedule-outbox-URL property value that matches the scheduling Outbox targeted by the request.
Servers MUST verify that the principal associated with the calendar user address specified in the ORGANIZER property of the scheduling message data in the request has the CALDAV:schedule privilege or a suitable sub-privilege on all of the scheduling Inbox collections for the principals associated with all of the calendar user addresses specified in any Recipient request headers in the request.
The CALDAV:calendar-free-busy-set property on principal resources SHOULD only be accessible when that principal is authenticated (i.e., the property SHOULD be hidden from other principals).

12. IANA Consideration

This specification does not require any IANA actions.

13. Acknowledgements

The authors would like to thank the following individuals for contributing their ideas and support for writing this specification: Julian F. Reschke and Jim Whitehead.

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. Normative References

[I-D.dusseault-caldav]Dusseault, L, “Calendaring Extensions to WebDAV (CalDAV)”, Internet-Draft draft-dusseault-caldav-15 (work in progress), September 2006.
[I-D.ietf-webdav-rfc2518bis]Dusseault, L, “HTTP Extensions for Distributed Authoring - WebDAV”, Internet-Draft draft-ietf-webdav-rfc2518bis-15 (work in progress), May 2006.
[RFC2119]Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[RFC2396]Berners-Lee, T., Fielding, R.T., and L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax”, RFC 2396, August 1998.
[RFC2445]Dawson, F., 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.
[RFC2447]Dawson, F., Mansour, S., and S. Silverberg, “iCalendar Message-Based Interoperability Protocol (iMIP)”, RFC 2447, 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.
[RFC3744]Clemm, G., Reschke, J. F., Sedlar, E., and J. Whitehead, “Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol”, RFC 3744, May 2004.
[W3C.REC-xml-20040204]Maler, E., Sperberg-McQueen, C., Bray, T., Yergeau, F., and J. Paoli, “Extensible Markup Language (XML) 1.0 (Third Edition)”, World Wide Web Consortium Recommendation REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.

Authors' Addresses

Cyrus DabooEMail:
Bernard DesruisseauxOracle Corporation600 blvd. de Maisonneuve WestSuite 1900Montreal, QC H3A 3J2CAEMail: URI: http://www.oracle.com/
Lisa Dusseault - Open Source Application Foundation - 2064 Edgewood Dr.Palo Alto, CA 94303USEMail: URI: http://www.osafoundation.org/

A. Changes

A.1 Changes in -02

  1. Split schedule privilege into three sub-privileges.
  2. Made support for caldav-access optional.
  3. Changed SCHEDULE method to POST.

A.2 Changes in -01

  1. Updated to latest references including 2518bis.
  2. Added principal property CALDAV:calendar-user-address-set.
  3. Major changes to schedule method, including addition of preconditions.
  4. New principal properties added.
  5. Text related to alternative ways of doing scheduling (some speculative) removed.
  6. Added Security Considerations text.
  7. Added IANA consideration text.

Full Copyright Statement

Copyright © 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.

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 provided by the IETF Administrative Support Activity (IASA).

\ No newline at end of file diff --git a/docs/draft-ietf-calsch-many-xcal-02.txt b/docs/draft-ietf-calsch-many-xcal-02.txt deleted file mode 100644 index 9f7acd3e..00000000 --- a/docs/draft-ietf-calsch-many-xcal-02.txt +++ /dev/null @@ -1,2971 +0,0 @@ -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-15.txt.html b/docs/dusseault-caldav-15.txt.html deleted file mode 100644 index 65596637..00000000 --- a/docs/dusseault-caldav-15.txt.html +++ /dev/null @@ -1,6502 +0,0 @@ - - - - - -dusseault-caldav-15.txt - - - -Internet DRAFT - draft-dusseault-caldav -

draft-dusseault-caldav

-

-
-
-
-
-
-Network Working Group                                           C. Daboo
-Internet-Draft                                            Apple Computer
-Expires: March 17, 2007                                  B. Desruisseaux
-                                                                  Oracle
-                                                            L. Dusseault
-                                                                    OSAF
-                                                      September 13, 2006
-
-
-               Calendaring Extensions to WebDAV (CalDAV)
-                       draft-dusseault-caldav-15
-
-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 March 17, 2007.
-
-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 March 17, 2007                 [Page 1]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   and calendar publishing.
-
-
-Table of Contents
-
-   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   5
-     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   5
-     1.2.  XML Namespaces and Processing . . . . . . . . . . . . . .   5
-     1.3.  Method Preconditions and Postconditions . . . . . . . . .   6
-   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  . . . . . . . . . . . . . . . . . . . . .   9
-     4.1.  Calendar Object Resources . . . . . . . . . . . . . . . .   9
-     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 . . . . . . . . . . . . . . .  12
-     5.2.  Calendar Collection Properties  . . . . . . . . . . . . .  12
-       5.2.1.  CALDAV:calendar-description Property  . . . . . . . .  12
-       5.2.2.  CALDAV:calendar-timezone Property . . . . . . . . . .  13
-       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 . . . . . . . . . .  16
-       5.2.6.  CALDAV:min-date-time Property . . . . . . . . . . . .  17
-       5.2.7.  CALDAV:max-date-time Property . . . . . . . . . . . .  18
-       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 . . . . . . . .  20
-     5.3.  Creating Resources  . . . . . . . . . . . . . . . . . . .  20
-       5.3.1.  MKCALENDAR Method . . . . . . . . . . . . . . . . . .  20
-         5.3.1.1.  Status Codes  . . . . . . . . . . . . . . . . . .  22
-         5.3.1.2.  Example: Successful MKCALENDAR request  . . . . .  23
-       5.3.2.  Creating Calendar Object Resources  . . . . . . . . .  25
-         5.3.2.1.  Additional Preconditions for PUT, COPY and MOVE .  26
-       5.3.3.  Non-standard components, properties and parameters  .  28
-       5.3.4.  Calendar Object Resource Entity Tag . . . . . . . . .  28
-   6.  Calendaring Access Control  . . . . . . . . . . . . . . . . .  29
-     6.1.  Calendaring Privilege . . . . . . . . . . . . . . . . . .  29
-       6.1.1.  CALDAV:read-free-busy Privilege . . . . . . . . . . .  29
-     6.2.  Additional Principal Property . . . . . . . . . . . . . .  30
-       6.2.1.  CALDAV:calendar-home-set Property . . . . . . . . . .  30
-   7.  Calendaring Reports . . . . . . . . . . . . . . . . . . . . .  31
-     7.1.  REPORT Method . . . . . . . . . . . . . . . . . . . . . .  31
-     7.2.  Ordinary collections  . . . . . . . . . . . . . . . . . .  31
-     7.3.  Date and floating time  . . . . . . . . . . . . . . . . .  32
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 2]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-     7.4.  Time range filtering  . . . . . . . . . . . . . . . . . .  32
-     7.5.  Searching Text: Collations  . . . . . . . . . . . . . . .  33
-       7.5.1.  CALDAV:supported-collation-set Property . . . . . . .  34
-     7.6.  Partial Retrieval . . . . . . . . . . . . . . . . . . . .  34
-     7.7.  Non-standard components, properties and parameters  . . .  35
-     7.8.  CALDAV:calendar-query Report  . . . . . . . . . . . . . .  35
-       7.8.1.  Example: Partial retrieval of events by time range  .  38
-       7.8.2.  Example: Partial retrieval of recurring events  . . .  42
-       7.8.3.  Example: Expanded retrieval of recurring events . . .  45
-       7.8.4.  Example: Partial retrieval of stored free busy
-               components  . . . . . . . . . . . . . . . . . . . . .  47
-       7.8.5.  Example: Retrieval of to-dos by alarm time range  . .  49
-       7.8.6.  Example: Retrieval of event by UID  . . . . . . . . .  51
-       7.8.7.  Example: Retrieval of events by PARTSTAT  . . . . . .  53
-       7.8.8.  Example: Retrieval of events only . . . . . . . . . .  55
-       7.8.9.  Example: Retrieval of all pending to-dos  . . . . . .  59
-       7.8.10. Example: Attempt to query unsupported property  . . .  62
-     7.9.  CALDAV:calendar-multiget Report . . . . . . . . . . . . .  63
-       7.9.1.  Example: Successful CALDAV:calendar-multiget Report .  64
-     7.10. CALDAV:free-busy-query Report . . . . . . . . . . . . . .  66
-       7.10.1. Example: Successful CALDAV:free-busy-query Report . .  68
-   8.  Guidelines  . . . . . . . . . . . . . . . . . . . . . . . . .  68
-     8.1.  Client-to-client Interoperability . . . . . . . . . . . .  69
-     8.2.  Synchronization Operations  . . . . . . . . . . . . . . .  69
-       8.2.1.  Use of Reports  . . . . . . . . . . . . . . . . . . .  69
-         8.2.1.1.  Restrict the Time Range . . . . . . . . . . . . .  69
-         8.2.1.2.  Synchronize by Time Range . . . . . . . . . . . .  69
-         8.2.1.3.  Synchronization Process . . . . . . . . . . . . .  70
-       8.2.2.  Restrict the Properties Returned  . . . . . . . . . .  72
-     8.3.  Use of Locking  . . . . . . . . . . . . . . . . . . . . .  72
-     8.4.  Finding calendars . . . . . . . . . . . . . . . . . . . .  72
-     8.5.  Storing and Using Attachments . . . . . . . . . . . . . .  74
-       8.5.1.  Inline attachments  . . . . . . . . . . . . . . . . .  74
-       8.5.2.  External attachments  . . . . . . . . . . . . . . . .  75
-     8.6.  Storing and Using Alarms  . . . . . . . . . . . . . . . .  76
-   9.  XML Element Definitions . . . . . . . . . . . . . . . . . . .  77
-     9.1.  CALDAV:calendar XML Element . . . . . . . . . . . . . . .  77
-     9.2.  CALDAV:mkcalendar XML Element . . . . . . . . . . . . . .  77
-     9.3.  CALDAV:mkcalendar-response XML Element  . . . . . . . . .  77
-     9.4.  CALDAV:supported-collation XML Element  . . . . . . . . .  78
-     9.5.  CALDAV:calendar-query XML Element . . . . . . . . . . . .  78
-     9.6.  CALDAV:calendar-data XML Element  . . . . . . . . . . . .  79
-       9.6.1.  CALDAV:comp XML Element . . . . . . . . . . . . . . .  80
-       9.6.2.  CALDAV:allcomp XML Element  . . . . . . . . . . . . .  80
-       9.6.3.  CALDAV:allprop XML Element  . . . . . . . . . . . . .  81
-       9.6.4.  CALDAV:prop XML Element . . . . . . . . . . . . . . .  81
-       9.6.5.  CALDAV:expand XML Element . . . . . . . . . . . . . .  82
-       9.6.6.  CALDAV:limit-recurrence-set XML Element . . . . . . .  83
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 3]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-       9.6.7.  CALDAV:limit-freebusy-set XML Element . . . . . . . .  84
-     9.7.  CALDAV:filter XML Element . . . . . . . . . . . . . . . .  84
-       9.7.1.  CALDAV:comp-filter XML Element  . . . . . . . . . . .  85
-       9.7.2.  CALDAV:prop-filter XML Element  . . . . . . . . . . .  85
-       9.7.3.  CALDAV:param-filter XML Element . . . . . . . . . . .  86
-       9.7.4.  CALDAV:is-not-defined XML Element . . . . . . . . . .  87
-       9.7.5.  CALDAV:text-match XML Element . . . . . . . . . . . .  87
-     9.8.  CALDAV:timezone XML Element . . . . . . . . . . . . . . .  88
-     9.9.  CALDAV:time-range XML Element . . . . . . . . . . . . . .  88
-     9.10. CALDAV:calendar-multiget XML Element  . . . . . . . . . .  93
-     9.11. CALDAV:free-busy-query XML Element  . . . . . . . . . . .  94
-   10. Internationalization Considerations . . . . . . . . . . . . .  94
-   11. Security Considerations . . . . . . . . . . . . . . . . . . .  94
-   12. IANA Consideration  . . . . . . . . . . . . . . . . . . . . .  95
-     12.1. Namespace Registration  . . . . . . . . . . . . . . . . .  95
-   13. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  96
-   14. References  . . . . . . . . . . . . . . . . . . . . . . . . .  96
-     14.1. Normative References  . . . . . . . . . . . . . . . . . .  96
-     14.2. Informative References  . . . . . . . . . . . . . . . . .  97
-   Appendix A.  CalDAV Method Privilege Table (Normative)  . . . . .  97
-   Appendix B.  Calendar collections used in the examples  . . . . .  98
-   Appendix C.  Changes (to be removed prior to publication as an
-                RFC) . . . . . . . . . . . . . . . . . . . . . . . . 104
-     C.1.  Changes in -15  . . . . . . . . . . . . . . . . . . . . . 104
-     C.2.  Changes in -14  . . . . . . . . . . . . . . . . . . . . . 105
-     C.3.  Changes in -13  . . . . . . . . . . . . . . . . . . . . . 105
-     C.4.  Changes in -12  . . . . . . . . . . . . . . . . . . . . . 106
-     C.5.  Changes in -11  . . . . . . . . . . . . . . . . . . . . . 106
-     C.6.  Changes in -10  . . . . . . . . . . . . . . . . . . . . . 107
-     C.7.  Changes in -09  . . . . . . . . . . . . . . . . . . . . . 108
-     C.8.  Changes in -08  . . . . . . . . . . . . . . . . . . . . . 109
-     C.9.  Changes in -07  . . . . . . . . . . . . . . . . . . . . . 110
-     C.10. Changes in -06  . . . . . . . . . . . . . . . . . . . . . 111
-     C.11. Changes in -05  . . . . . . . . . . . . . . . . . . . . . 111
-     C.12. Changes in -04  . . . . . . . . . . . . . . . . . . . . . 112
-     C.13. Changes in -03  . . . . . . . . . . . . . . . . . . . . . 113
-     C.14. Changes in -02  . . . . . . . . . . . . . . . . . . . . . 113
-     C.15. Changes in -01  . . . . . . . . . . . . . . . . . . . . . 113
-   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . 114
-   Intellectual Property and Copyright Statements  . . . . . . . . . 115
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 4]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-1.  Introduction
-
-   The concept of using HTTP [RFC2616] and WebDAV [RFC2518] 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.
-
-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-20060816].
-
-   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
-   defined by WebDAV [RFC2518] which use the "DAV:" namespace.  Wherever
-   such XML elements appear, they are explicitly prefixed with "DAV:" to
-   avoid confusion.
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 5]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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 [RFC2518], in particular Section 14, and Appendices 3
-   and 4 of that specification.
-
-1.3.  Method Preconditions and Postconditions
-
-   A "precondition" of a method describes the state of the server that
-   must be true for that method to be performed.  A "postcondition" of a
-   method describes the state of the server that must be true after that
-   method has been completed.  If a method precondition or postcondition
-   for a request is not satisfied, the response status of the request
-   MUST be either 403 (Forbidden) if the request should not be repeated
-   because it will always fail, or 409 (Conflict) if it is expected that
-   the user might be able to resolve the conflict and resubmit the
-   request.
-
-   In order to allow better client handling of 403 and 409 responses, a
-   distinct XML element type is associated with each method precondition
-   and postcondition of a request.  When a particular precondition is
-   not satisfied or a particular postcondition cannot be achieved, the
-   appropriate XML element MUST be returned as the child of a top-level
-   DAV:error element in the response body, unless otherwise negotiated
-   by the request.
-
-
-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 [RFC2518] (note that [I-D.ietf-webdav-
-      rfc2518bis] describes clarifications to [RFC2518] that aid
-      interoperability);
-
-   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]
-      (note that [RFC2246] has been obsoleted by [RFC4346]);
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 6]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.
-
-
-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
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 7]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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
-   calendar data and state information.  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.
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 8]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-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
-   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:
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                 [Page 9]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-    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
-
-   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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 10]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.
-
-   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.
-
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 11]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-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
-
-   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 12.14.1 of
-      [RFC2518]).  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.
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 12]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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 12.14.1 of [RFC2518]).
-
-   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
-      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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 13]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-               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>
-
-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 12.14.1 of
-      [RFC2518]).
-
-   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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 14]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-      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>
-
-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 12.14.1 of
-      [RFC2518]).
-
-   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 only accept data with the media type
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 15]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-      "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.
-
-   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 12.14.1 of
-      [RFC2518]).
-
-   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)
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 16]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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 12.14.1 of
-      [RFC2518]).
-
-   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
-      (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>
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 17]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-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 12.14.1 of
-      [RFC2518]).
-
-   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
-      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
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 18]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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 12.14.1 of
-      [RFC2518]).
-
-   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>
-
-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 12.14.1 of
-      [RFC2518]).
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 19]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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 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.
-
-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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 20]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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).
-      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 12.13.2 of [RFC2518].
-
-         <!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:
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 21]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-      (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
-      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;
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 22]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-         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 March 17, 2007                [Page 23]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 24]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 25]
-
-Internet-Draft                   CalDAV                   September 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 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 March 17, 2007                [Page 26]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 27]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 28]
-
-Internet-Draft                   CalDAV                   September 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 not
-   specified here, 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.10).  This privilege can be granted on calendar
-   collections, regular collections or calendar object resources.
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 29]
-
-Internet-Draft                   CalDAV                   September 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 SHOULD be defined on a principal resource.
-      If defined, it MAY be protected and SHOULD NOT be returned by a
-      PROPFIND DAV:allprop request (as defined in Section 12.14.1 of
-      [RFC2518]).
-
-   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 March 17, 2007                [Page 30]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 31]
-
-Internet-Draft                   CalDAV                   September 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.9 of this document.
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 32]
-
-Internet-Draft                   CalDAV                   September 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.  Searching Text: Collations
-
-   Some of the reports defined in this section do text matches of
-   character strings provided by the client and compared to stored
-   calendar data.  Since iCalendar data is by default encoded in the
-   UTF-8 charset and may include characters outside of the US-ASCII
-   charset range in some property and parameter values, there is a need
-   to ensure that text matching follows well-defined rules.
-
-   To deal with this, this specification makes use of the IANA Collation
-   Registry defined in [I-D.newman-i18n-comparator] to specify
-   collations that may be used to carry out the text comparison
-   operations with a well-defined rule.
-
-   The comparisons used in CalDAV are all "substring" matches as per
-   [I-D.newman-i18n-comparator] Section 4.2.  Collations supported by
-   the server MUST support "substring" match operations.
-
-   CalDAV servers are REQUIRED to support the "i;ascii-casemap" and
-   "i;octet" collations as described in [I-D.newman-i18n-comparator],
-   and MAY support other collations.
-
-   Servers MUST advertise the set of collations that they support via
-   the CALDAV:supported-collation-set property defined on any resource
-   that supports reports that use collations.
-
-   Clients MUST only use collations from the list advertised by the
-   server.
-
-   In the absence of a collation explicitly specified by the client, or
-   if the client specifies the "default" collation identifier (as
-   defined in [I-D.newman-i18n-comparator] Section 3.1), the server MUST
-   default to using "i;ascii-casemap" as the collation.
-
-   Wildcards (as defined in [I-D.newman-i18n-comparator] Section 3.2)
-   MUST NOT be used in the collation identifier.
-
-   If the client chooses a collation not supported by the server, the
-   server MUST respond with a CALDAV:supported-collation precondition
-   error response.
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 33]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-7.5.1.  CALDAV:supported-collation-set Property
-
-   Name: supported-collation-set
-
-   Namespace: urn:ietf:params:xml:ns:caldav
-
-   Purpose: Identifies the set of collations supported by the server for
-      text matching operations.
-
-   Conformance: This property MUST be defined on any resource that
-      supports a REPORT that does text matching.  If defined, it MUST be
-      protected and SHOULD NOT be returned by a PROPFIND DAV:allprop
-      request (as defined in Section 12.14.1 of [RFC2518]).
-
-   Description: The CALDAV:supported-collation-set property contains
-      zero or more CALDAV:supported-collation elements which specify the
-      collection identifiers of the collations supported by the server.
-
-   Definition:
-
-         <!ELEMENT supported-collation-set (supported-collation*)>
-           <!ELEMENT supported-collation (#PCDATA)>
-
-   Example:
-
-       <C:supported-collation-set
-           xmlns:C="urn:ietf:params:xml:ns:caldav">
-         <C:supported-collation>i;ascii-casemap</C:supported-collation>
-         <C:supported-collation>i;octet</C:supported-collation>
-       </C:supported-collation-set>
-
-7.6.  Partial Retrieval
-
-   Some calendaring REPORTs defined in this document allow partial
-   retrieval of calendar object resources.  A CalDAV client can specify
-   what information to return in the body of a calendaring REPORT
-   request.
-
-   A CalDAV client can request particular WebDAV property values, all
-   WebDAV property values, or a list of the names of the resource's
-   WebDAV properties.  A CalDAV client can 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.6.
-
-   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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 34]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   recurrence set, referred to as the "overridden components".
-
-   A CalDAV client only interested in the recurrence instances that
-   overlap a specified time range can 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.6.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 can 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.6.5.
-
-   Finally, in the case of VFREEBUSY components, a CalDAV client can
-   request to receive only the FREEBUSY property values that overlap a
-   specified time range.  See CALDAV:limit-freebusy-set in
-   Section 9.6.7.
-
-7.7.  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.8.  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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 35]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.5.
-
-      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.6) specify a media type supported by the server for
-      calendar object resources.
-
-      (CALDAV:valid-filter): The CALDAV:filter XML element (see
-      Section 9.7) specified in the REPORT request MUST be valid.  For
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 36]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-      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.7.1), CALDAV:prop-filter (see Section 9.7.2) and CALDAV:
-      param-filter (see Section 9.7.3) XML elements used in the CALDAV:
-      filter XML element (see Section 9.7) 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.
-
-      (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;
-
-      (CALDAV:supported-collation): Any XML attribute specifying a
-      collation MUST specify a collation supported by the server as
-      described in Section 7.5.
-
-   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.
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 37]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-7.8.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 March 17, 2007                [Page 38]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 39]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 40]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 41]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-7.8.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 March 17, 2007                [Page 42]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 43]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 44]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-     </D:response>
-   </D:multistatus>
-
-7.8.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 March 17, 2007                [Page 45]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 46]
-
-Internet-Draft                   CalDAV                   September 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.8.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 March 17, 2007                [Page 47]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 48]
-
-Internet-Draft                   CalDAV                   September 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.8.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 March 17, 2007                [Page 49]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 50]
-
-Internet-Draft                   CalDAV                   September 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.8.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 March 17, 2007                [Page 51]
-
-Internet-Draft                   CalDAV                   September 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 collation="i;octet"
-             >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 March 17, 2007                [Page 52]
-
-Internet-Draft                   CalDAV                   September 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.8.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 March 17, 2007                [Page 53]
-
-Internet-Draft                   CalDAV                   September 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 collation="i;ascii-casemap"
-              >mailto:lisa@example.com</C:text-match>
-             <C:param-filter name="PARTSTAT">
-               <C:text-match collation="i;ascii-casemap"
-                >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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 54]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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>
-     </D:response>
-   </D:multistatus>
-
-7.8.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 March 17, 2007                [Page 55]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 56]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 57]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 58]
-
-Internet-Draft                   CalDAV                   September 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.8.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 March 17, 2007                [Page 59]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 60]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 61]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-7.8.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 March 17, 2007                [Page 62]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-7.9.  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.8), 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.10).  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.6) 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 March 17, 2007                [Page 63]
-
-Internet-Draft                   CalDAV                   September 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.9.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 March 17, 2007                [Page 64]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 65]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-     </D:response>
-   </D:multistatus>
-
-7.10.  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 March 17, 2007                [Page 66]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   Marshalling:
-
-      The request body MUST be a CALDAV:free-busy-query XML element (see
-      Section 9.11, which MUST contain exactly one CALDAV:time-range XML
-      element, as defined in Section 9.9.
-
-      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 March 17, 2007                [Page 67]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-7.10.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 March 17, 2007                [Page 68]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 69]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 70]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 71]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 72]
-
-Internet-Draft                   CalDAV                   September 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 [RFC4511] 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 March 17, 2007                [Page 73]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 74]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-      attachment is unchanged.
-
-8.5.2.  External attachments
-
-   CalDAV clients SHOULD support downloading of external attachments
-   referenced by arbitrary URI schemes, by either processing them
-   directly, or by passing the attachment URI to a suitable "helper
-   application" for processing, if such an application exists.  CalDAV
-   clients MUST support downloading of external attachments referenced
-   by the "http" or "https" URI schemes.  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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 75]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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
-   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 alarms
-      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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 76]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   operations on a calendar and there is no risk of losing alarm
-   information, then the client MAY discard alarm information.
-
-   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
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 77]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   Name: mkcalendar-response
-
-   Namespace: urn:ietf:params:xml:ns:caldav
-
-   Purpose: Specifies a response body for a successful MKCALENDAR
-      request.
-
-   Description: See Section 5.3.1.
-
-   Definition:
-
-         <!ELEMENT mkcalendar-response ANY>
-
-9.4.  CALDAV:supported-collation XML Element
-
-   Name: supported-collation
-
-   Namespace: urn:ietf:params:xml:ns:caldav
-
-   Purpose: Identifies a single collation via its collation identifier
-      as defined by [I-D.newman-i18n-comparator].
-
-   Description: The CALDAV:supported-collation contains the text of a
-      collation identifier as described in Section 7.5.1.
-
-   Definition:
-
-         <!ELEMENT supported-collation (#PCDATA)>
-         PCDATA value: collation identifier
-
-9.5.  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.8.
-
-   Definition:
-
-         <!ELEMENT calendar-query ((DAV:allprop |
-                                    DAV:propname |
-                                    DAV:prop)?, filter, timezone?)>
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 78]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-9.6.  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.
-
-      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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 79]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-      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.6.1.  CALDAV:comp XML Element
-
-   Name: comp
-
-   Namespace: urn:ietf:params:xml:ns:caldav
-
-   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 [RFC2518].
-      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.6.2.  CALDAV:allcomp XML Element
-
-   Name: allcomp
-
-   Namespace: urn:ietf:params:xml:ns:caldav
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 80]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.6.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.
-
-   Definition:
-
-         <!ELEMENT allprop EMPTY>
-
-   Note: The CALDAV:allprop element has the same name as the DAV:allprop
-      element defined in [RFC2518].  However, the CALDAV:allprop element
-      is defined in the "urn:ietf:params:xml:ns:caldav" namespace
-      instead of the "DAV:" namespace.
-
-9.6.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.
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 81]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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 [RFC2518].  However, the CALDAV:prop element is
-      defined in the "urn:ietf:params:xml:ns:caldav" namespace instead
-      of the "DAV:" namespace.
-
-9.6.5.  CALDAV:expand XML Element
-
-   Name: expand
-
-   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:
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 82]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-         <!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.6.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
-      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"
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 83]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-9.6.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.
-
-   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.7.  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)>
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 84]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-9.7.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.
-
-      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.7.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
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 85]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-         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")
-
-9.7.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")
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 86]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-9.7.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>
-
-9.7.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 "collation" attribute is used to select the collation that the
-      server MUST use for character string matching.  In the absence of
-      this attribute the server MUST use the "i;ascii-casemap"
-      collation.
-
-      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:
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 87]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-         <!ELEMENT text-match (#PCDATA)>
-         PCDATA value: string
-
-         <!ATTLIST text-match collation        CDATA "i;ascii-casemap"
-                              negate-condition (yes | no) "no">
-
-9.8.  CALDAV:timezone XML Element
-
-   Name: timezone
-
-   Namespace: urn:ietf:params:xml:ns:caldav
-
-   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.9.  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.
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 88]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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
-      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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 89]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-      +---------------------------------------------------------------+
-      | 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
-      value MUST be a DATE-TIME value equal to or after the DTSTART
-      value, if specified.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 90]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   +-------------------------------------------------------------------+
-   | 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 March 17, 2007                [Page 91]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007                [Page 92]
-
-Internet-Draft                   CalDAV                   September 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.10.  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.9.
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 93]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   Definition:
-
-         <!ELEMENT calendar-multiget ((DAV:allprop |
-                                      DAV:propname |
-                                      DAV:prop)?, DAV:href+)>
-
-9.11.  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.10.
-
-   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).
-
-   The CALDAV:calendar-query report (Section 7.8) includes a text
-   searching option controlled by the CALDAV:text-match element and
-   details of character handling are covered in the description of that
-   element (see Section 9.7.5).
-
-
-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.
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 94]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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
-   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.
-
-   When rolling up free-busy information, more information about a
-   user's events is exposed if busy periods overlap or are adjacent
-   (this tells the client requesting the free-busy information that the
-   calendar owner has at least two events, rather than knowing only that
-   the calendar owner has one or more events during the busy period).
-   Thus, a conservative approach to calendar data privacy would have
-   servers always coalesce such busy periods when they are the same
-   type.
-
-   Procedure alarms are a known security risk for either clients or
-   servers to handle, particularly when the alarm was created by another
-   agent.  Clients and servers are not required to execute such
-   procedure alarms.
-
-   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 [RFC2518], [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.
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 95]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-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,
-   Ted Hardie, Sam Hartman, Helge Hess, Jeff McCullough, Alexey
-   Melnikov, Dan Mosedale, Brian Moseley, Kervin L. Pierre, Julian F.
-   Reschke, Wilfredo Sanchez Vega, Mike Shaver, Jari Urpalainen, Simon
-   Vaillancourt, Jim Whitehead.
-
-   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
-
-14.1.  Normative References
-
-   [I-D.newman-i18n-comparator]
-              Newman, C., "Internet Application Protocol Collation
-              Registry", draft-newman-i18n-comparator-13 (work in
-              progress), August 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.
-
-   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
-              Jensen, "HTTP Extensions for Distributed Authoring --
-              WEBDAV", RFC 2518, February 1999.
-
-   [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.
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 96]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   [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.
-
-   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
-              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
-
-   [W3C.REC-xml-20060816]
-              Yergeau, F., Paoli, J., Bray, T., Sperberg-McQueen, C.,
-              and E. Maler, "Extensible Markup Language (XML) 1.0
-              (Fourth Edition)", World Wide Web Consortium
-              Recommendation REC-xml-20060816, August 2006,
-              <http://www.w3.org/TR/2006/REC-xml-20060816>.
-
-14.2.  Informative References
-
-   [I-D.ietf-webdav-rfc2518bis]
-              Dusseault, L., "HTTP Extensions for Distributed Authoring
-              - WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in
-              progress), May 2006.
-
-   [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.
-
-   [RFC4511]  Sermersheim, J., "Lightweight Directory Access Protocol
-              (LDAP): The Protocol", RFC 4511, June 2006.
-
-
-Appendix A.  CalDAV Method Privilege Table (Normative)
-
-   The following table extends the WebDAV Method Privilege Table
-   specified in Appendix B of [RFC3744].
-
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 97]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   +------------+------------------------------------------------------+
-   | 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:
-
-   >> 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" ?>
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 98]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   <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/abcd2.ics</D:href>
-       <D:propstat>
-         <D:prop>
-
-
-
-Daboo, et al.            Expires March 17, 2007                [Page 99]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-           <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>
-         <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>
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 100]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-         <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
-   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>
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 101]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-           <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>
-       </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>
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 102]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-     <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
-   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>
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 103]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-     <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
-   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 -15
-
-   a.  Switched to using collations for text-match element in calendar-
-       query report.
-
-   b.  Removed caseless attribute from text-match element.
-
-   c.  Removed UNICODE4 reference.
-
-   d.  Removed mailing list comment.
-
-   e.  Made calendar-home-set property a SHOULD as it was in previous
-       drafts.
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 104]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   f.  Now require https download of external attachments.
-
-   g.  Changed some improper uses of 2119 terms to lowercase.
-
-   h.  Updated some references to latest specs.
-
-C.2.  Changes in -14
-
-   a.  Reverted to normative reference to 2518 and added informative
-       reference to 2518bis.
-
-   b.  Reinserted section describing preconditions/postconditions.
-
-   c.  Removed redundant compliance statement in last paragraph of
-       Section 3.
-
-   d.  Clarify that only text/calendar is allowed if supported-calendar-
-       data property is not present.
-
-   e.  Removed redundant compliance statement in Conformance paragraph
-       of Section 6.2.1.
-
-   f.  Removed redundant compliance statement in first paragraph of
-       Section 7.5.
-
-   g.  Fixed incorrect whitespace in elements in example in Section
-       7.7.6.
-
-   h.  Fixed incorrect CDATA descriptions in various places.
-
-C.3.  Changes in -13
-
-   a.  Changed mailing list draft description.
-
-   b.  Added security review suggested text to Security Considerations.
-
-   c.  Changed external attachment support to require http URI
-       downloads, and optionally others.
-
-   d.  Added reference to text-match element in Internationalization
-       Considerations section.
-
-   e.  Changed 'undefined' to 'not specified here' in ETag behavior
-       section.
-
-   f.  Added reference to RFC4346 with note that it obsoletes RFC2246
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 105]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-C.4.  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.5.  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.
-
-   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.
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 106]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.6.  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.
-
-   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.
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 107]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   j.  Add preconditions for calendar-timezone property/elements in
-       MKCALENDAR, PROPPATCH and calendar-query REPORT.
-
-   k.  Fix principal-match example.
-
-C.7.  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.
-
-   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.
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 108]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.
-
-   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.8.  Changes in -08
-
-   a.  Removed statement that said that client SHOULD always request
-       DAV:getetag in calendar REPORTs.
-
-   b.  Removed redefiniton of DAV:response.
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 109]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.
-
-C.9.  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.
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 110]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.10.  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.
-
-   g.  Moved "Sychronization Operations" section in the "Guidelines"
-       section.
-
-C.11.  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.
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 111]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-   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.12.  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.
-
-   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.
-
-
-
-
-
-
-
-Daboo, et al.            Expires March 17, 2007               [Page 112]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-C.13.  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.14.  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.15.  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 March 17, 2007               [Page 113]
-
-Internet-Draft                   CalDAV                   September 2006
-
-
-Authors' Addresses
-
-   Cyrus Daboo
-   Apple Computer, Inc.
-   1 Infinite Loop
-   Cupertino, CA  95014
-   USA
-
-   Email: cyrus@daboo.name
-   URI:   http://www.apple.com/
-
-
-   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 March 17, 2007               [Page 114]
-
-Internet-Draft                   CalDAV                   September 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 March 17, 2007               [Page 115]
-
-
-

-

-
-
diff --git a/docs/dusseault2005CalDAV.pdf b/docs/dusseault2005CalDAV.pdf
deleted file mode 100644
index 87ba07c372d2cad77117850ba6bba57957fd2814..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001

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/rfc2518.html b/docs/rfc2518.html
deleted file mode 100644
index e8300f6c..00000000
--- a/docs/rfc2518.html
+++ /dev/null
@@ -1,5109 +0,0 @@
-
-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
deleted file mode 100644
index 28385665..00000000
--- a/docs/rfc2616.html
+++ /dev/null
@@ -1,9901 +0,0 @@
-
-
-
-
-
-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

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