Initial Release of the calendar plugin

dav/SabreDAV/docs/caldav-ctag.txt

@@ -0,0 +1,336 @@
+
+
+
+Calendar Server Extension                                       C. Daboo
+                                                                   Apple
+                                                             May 3, 2007
+
+
+            Calendar Collection Entity Tag (CTag) in CalDAV
+                             caldav-ctag-02
+
+Abstract
+
+   This specification defines an extension to CalDAV that provides a
+   fast way for a client to determine whether the contents of a calendar
+   collection may have changed.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
+   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     3.1.  Server  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+     3.2.  Client  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  New features in CalDAV  . . . . . . . . . . . . . . . . . . . . 3
+     4.1.  getctag WebDAV Property . . . . . . . . . . . . . . . . . . 4
+   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   7.  Normative References  . . . . . . . . . . . . . . . . . . . . . 5
+   Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . 5
+   Appendix B.  Change History . . . . . . . . . . . . . . . . . . . . 5
+   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                                                           [Page 1]
+
+                              CalDAV Proxy                      May 2007
+
+
+1.  Introduction
+
+   In CalDAV [RFC4791] calendar data is stored in calendar collection
+   resources.  Clients need to "poll" calendar collections in order to
+   find out what has changed since the last time they examined it.
+   Currently that involves having to do a PROPFIND Depth:1 HTTP request,
+   or a CALDAV:calendar-query REPORT request.  When a calendar
+   collection contains a large number of calendar resources those
+   operations become expensive on the server.
+
+   Calendar users often configure their clients to poll at short time
+   intervals.  So polling traffic to the server will be high, even
+   though the frequency at which changes actually occur to a calendar is
+   typically low.
+
+   To improve on performance, this specification defines a new "calendar
+   collection entity tag" (CTag) WebDAV property that is defined on
+   calendar collections.  When the calendar collection changes, the CTag
+   value changes.  Thus a client can cache the CTag at some point in
+   time, then poll the collection only (i.e.  PROPFIND Depth:0 HTTP
+   requests) and determine if a change has happened based on the
+   returned CTag value.  If there is a change, it can then fall back to
+   doing the full (Depth:1) poll of the collection to actually determine
+   which resources in the collection changed.
+
+   This extension also defines CTag's on CalDAV scheduling
+   [I-D.desruisseaux-caldav-sched] Inbox and Outbox collections.
+
+
+2.  Conventions Used in This Document
+
+   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 type names respectively.
+
+   The namespace "http://calendarserver.org/ns/" is used for XML
+   elements defined in this specification.  When XML element types in
+   this namespace are referenced in this document outside of the context
+   of an XML fragment, the string "CS:" will be prefixed to the element
+   type names respectively.
+
+
+
+
+
+
+Daboo                                                           [Page 2]
+
+                              CalDAV Proxy                      May 2007
+
+
+3.  Overview
+
+3.1.  Server
+
+   For each calendar or scheduling Inbox or Outbox collection on the
+   server, a new CS:getctag WebDAV property is present.
+
+   The property value is an "opaque" token whose value is guaranteed to
+   be unique over the lifetime of any calendar or scheduling Inbox or
+   Outbox collection at a specific URI.
+
+   Whenever a calendar resource is added to, modified or deleted from
+   the calendar collection, the value of the CS:getctag property MUST
+   change.  Typically this change will occur when the DAV:getetag
+   property on a child resource changes due to some protocol action.  It
+   could be the result of a change to the body or properties of the
+   resource.
+
+3.2.  Client
+
+   The client starts off with an empty string as the initial value for
+   the cached CTag of a calendar or scheduling Inbox or Outbox
+   collection that it intends to synchronize with.
+
+   When polling a calendar or scheduling Inbox or Outbox collection, the
+   client issues a PROPFIND Depth:0 HTTP request, asking for the CS:
+   getctag property to be returned.
+
+   If the returned value of CS:getctag property matches the one
+   currently cached for the calendar or scheduling Inbox or Outbox
+   collection, then the collection contents have not changed and no
+   further action is required until the next poll.
+
+   If the returned value of CS:getctag property does not match the one
+   found previously, then the contents of the calendar or scheduling
+   Inbox or Outbox collection have changed.  At that point the client
+   should re-issue the PROPFIND Depth:1 request to get the collection
+   changes in detail and the CS:getctag property value corresponding to
+   the new state.  The new CSgetctag property value should replace the
+   one currently cached for that calendar or scheduling Inbox or Outbox
+   collection.
+
+
+4.  New features in CalDAV
+
+
+
+
+
+
+
+Daboo                                                           [Page 3]
+
+                              CalDAV Proxy                      May 2007
+
+
+4.1.  getctag WebDAV Property
+
+   Name:  getctag
+
+   Namespace:  http://calendarserver.org/ns/
+
+   Purpose:  Specifies a "synchronization" token used to indicate when
+      the contents of a calendar or scheduling Inbox or Outbox
+      collection have changed.
+
+   Conformance:  This property MUST be defined on a calendar or
+      scheduling Inbox or Outbox collection resource.  It MUST be
+      protected and SHOULD be returned by a PROPFIND DAV:allprop request
+      (as defined in Section 12.14.1 of [RFC2518]).
+
+   Description:  The CS:getctag property allows clients to quickly
+      determine if the contents of a calendar or scheduling Inbox or
+      Outbox collection have changed since the last time a
+      "synchronization" operation was done.  The CS:getctag property
+      value MUST change each time the contents of the calendar or
+      scheduling Inbox or Outbox collection change, and each change MUST
+      result in a value that is different from any other used with that
+      collection URI.
+
+   Definition:
+
+       <!ELEMENT getctag #PCDATA>
+
+   Example:
+
+       <T:getctag xmlns:T="http://calendarserver.org/ns/"
+       >ABCD-GUID-IN-THIS-COLLECTION-20070228T122324010340</T:getctag>
+
+
+5.  Security Considerations
+
+   The CS:getctag property value changes whenever any resource in the
+   collection or scheduling Inbox or Outbox changes.  Thus a change to a
+   resource that a user does not have read access to will result in a
+   change in the CTag and the user will know that a change occurred.
+   However, that user will not able to get additional details about
+   exactly what changed as WebDAV ACLs [RFC3744] will prevent that.  So
+   this does expose the fact that there are potentially "hidden"
+   resources in a calendar collection, but it does not expose any
+   details about them.
+
+
+
+
+
+
+Daboo                                                           [Page 4]
+
+                              CalDAV Proxy                      May 2007
+
+
+6.  IANA Considerations
+
+   This document does not require any actions on the part of IANA.
+
+
+7.  Normative References
+
+   [I-D.desruisseaux-caldav-sched]
+              Desruisseaux, B., "Scheduling Extensions to CalDAV",
+              draft-desruisseaux-caldav-sched-03 (work in progress),
+              January 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
+              Jensen, "HTTP Extensions for Distributed Authoring --
+              WEBDAV", RFC 2518, February 1999.
+
+   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+              Distributed Authoring and Versioning (WebDAV) Access
+              Control Protocol", RFC 3744, May 2004.
+
+   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
+              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+              March 2007.
+
+
+Appendix A.  Acknowledgments
+
+   This specification is the result of discussions between the Apple
+   calendar server and client teams.
+
+
+Appendix B.  Change History
+
+   Changes from -01:
+
+   1.  Updated to RFC4791 reference.
+
+   2.  Added text indicating that ctag applies to schedule Inbox and
+       Outbox as well.
+
+   Changes from -00:
+
+   1.  Relaxed requirement so that any type of change to a child
+       resource can trigger a CTag change (similar behavior to ETag).
+
+
+
+
+Daboo                                                           [Page 5]
+
+                              CalDAV Proxy                      May 2007
+
+
+Author's Address
+
+   Cyrus Daboo
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   Email: cyrus@daboo.name
+   URI:   http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                                                           [Page 6]
+

dav/SabreDAV/docs/caldav-proxy.txt

@@ -0,0 +1,560 @@
+
+
+
+Calendar Server Extension                                       C. Daboo
+                                                          Apple Computer
+                                                             May 3, 2007
+
+
+              Calendar User Proxy Functionality in CalDAV
+                           caldav-cu-proxy-02
+
+Abstract
+
+   This specification defines an extension to CalDAV that makes it easy
+   for clients to setup and manage calendar user proxies, using the
+   WebDAV Access Control List extension as a basis.
+
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  2
+   3.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.1.  Server . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+     3.2.  Client . . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   4.  Open Issues  . . . . . . . . . . . . . . . . . . . . . . . . .  4
+   5.  New features in CalDAV . . . . . . . . . . . . . . . . . . . .  4
+     5.1.  Proxy Principal Resource . . . . . . . . . . . . . . . . .  4
+     5.2.  Privilege Provisioning . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
+   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
+   8.  Normative References . . . . . . . . . . . . . . . . . . . . .  9
+   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . .  9
+   Appendix B.  Change History  . . . . . . . . . . . . . . . . . . . 10
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                                                           [Page 1]
+
+                              CalDAV Proxy                      May 2007
+
+
+1.  Introduction
+
+   CalDAV [RFC4791] provides a way for calendar users to store calendar
+   data and exchange this data via scheduling operations.  Based on the
+   WebDAV protocol [RFC2518], it also includes the ability to manage
+   access to calendar data via the WebDAV ACL extension [RFC3744].
+
+   It is often common for a calendar user to delegate some form of
+   responsibility for their calendar and schedules to another calendar
+   user (e.g., a boss allows an assistant to check a calendar or to send
+   and accept scheduling invites on his behalf).  The user handling the
+   calendar data on behalf of someone else is often referred to as a
+   "calendar user proxy".
+
+   Whilst CalDAV does have fine-grained access control features that can
+   be used to setup complex sharing and management of calendars, often
+   the proxy behavior required is an "all-or-nothing" approach - i.e.
+   the proxy has access to all the calendars or to no calendars (in
+   which case they are of course not a proxy).  So a simple way to
+   manage access to an entire set of calendars and scheduling ability
+   would be handy.
+
+   In addition, calendar user agents will often want to display to a
+   user who has proxy access to their calendars, or to whom they are
+   acting as a proxy.  Again, CalDAV's access control discovery and
+   report features can be used to do that, but with fine-grained control
+   that exists, it can be hard to tell who is a "real" proxy as opposed
+   to someone just granted rights to some subset of calendars.  Again, a
+   simple way to discover proxy information would be handy.
+
+
+2.  Conventions Used in This Document
+
+   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 namespace "DAV:" are referenced in this
+   document outside of the context of an XML fragment, the string "DAV:"
+   will be prefixed to the element type names.
+
+   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.
+
+   The namespace "http://calendarserver.org/ns/" is used for XML
+   elements defined in this specification.  When XML element types in
+
+
+
+Daboo                                                           [Page 2]
+
+                              CalDAV Proxy                      May 2007
+
+
+   this namespace are referenced in this document outside of the context
+   of an XML fragment, the string "CS:" will be prefixed to the element
+   type names respectively.
+
+
+3.  Overview
+
+3.1.  Server
+
+   For each calendar user principal on the server, the server will
+   generate two group principals - "proxy groups".  One is used to hold
+   the list of principals who have read-only proxy access to the main
+   principal's calendars, the other holds the list of principals who
+   have read-write and scheduling proxy access.  NB these new group
+   principals would have no equivalent in Open Directory.
+
+   Privileges on each "proxy group" principal will be set so that the
+   "owner" has the ability to change property values.
+
+   The "proxy group" principals will be child resources of the user
+   principal resource with specific resource types and thus are easy to
+   discover.  As a result the user principal resources will also be
+   collection resources.
+
+   When provisioning the calendar user home collection, the server will:
+
+   a.  Add an ACE to the calendar home collection giving the read-only
+       "proxy group" inheritable read access.
+
+   b.  Add an ACE to the calendar home collection giving the read-write
+       "proxy group" inheritable read-write access.
+
+   c.  Add an ACE to each of the calendar Inbox and Outbox collections
+       giving the CALDAV:schedule privilege
+       [I-D.desruisseaux-caldav-sched] to the read-write "proxy group".
+
+3.2.  Client
+
+   A client can see who the proxies are for the current principal by
+   examining the principal resource for the two "proxy group" properties
+   and then looking at the DAV:group-member-set property of each.
+
+   The client can edit the list of proxies for the current principal by
+   editing the DAV:group-member-set property on the relevant "proxy
+   group" principal resource.
+
+   The client can find out who the current principal is a proxy for by
+   running a DAV:principal-match REPORT on the principal collection.
+
+
+
+Daboo                                                           [Page 3]
+
+                              CalDAV Proxy                      May 2007
+
+
+   Alternatively, the client can find out who the current principal is a
+   proxy for by examining the DAV:group-membership property on the
+   current principal resource looking for membership in other users'
+   "proxy groups".
+
+
+4.  Open Issues
+
+   1.  Do we want to separate read-write access to calendars vs the
+       ability to schedule as a proxy?
+
+   2.  We may want to restrict changing properties on the proxy group
+       collections to just the DAV:group-member-set property?
+
+   3.  There is no way for a proxy to be able to manage the list of
+       proxies.  We could allow the main calendar user DAV:write-acl on
+       their "proxy group" principals, in which case they could grant
+       others the right to modify the group membership.
+
+   4.  Should the "proxy group" principals also be collections given
+       that the regular principal resources will be?
+
+
+5.  New features in CalDAV
+
+5.1.  Proxy Principal Resource
+
+   Each "regular" principal resource that needs to allow calendar user
+   proxy support MUST be a collection resource. i.e. in addition to
+   including the DAV:principal XML element in the DAV:resourcetype
+   property on the resource, it MUST also include the DAV:collection XML
+   element.
+
+   Each "regular" principal resource MUST contain two child resources
+   with names "calendar-proxy-read" and "calendar-proxy-write" (note
+   that these are only suggested names - the server could choose any
+   unique name for these).  These resources are themselves principal
+   resources that are groups contain the list of principals for calendar
+   users who can act as a read-only or read-write proxy respectively.
+
+   The server MUST include the CS:calendar-proxy-read or CS:calendar-
+   proxy-write XML elements in the DAV:resourcetype property of the
+   child resources, respectively.  This allows clients to discover the
+   "proxy group" principals by using a PROPFIND, Depth:1 request on the
+   current user's principal resource and requesting the DAV:resourcetype
+   property be returned.  The element type declarations are:
+
+
+
+
+
+Daboo                                                           [Page 4]
+
+                              CalDAV Proxy                      May 2007
+
+
+   <!ELEMENT calendar-proxy-read EMPTY>
+
+   <!ELEMENT calendar-proxy-write EMPTY>
+
+   The server MUST allow the "parent" principal to change the DAV:group-
+   member-set property on each of the "child" "proxy group" principal
+   resources.  When a principal is listed as a member of the "child"
+   resource, the server MUST include the "child" resource URI in the
+   DAV:group-membership property on the included principal resource.
+   Note that this is just "normal" behavior for a group principal.
+
+   An example principal resource layout might be:
+
+           + /
+             + principals/
+               + users/
+                 + cyrus/
+                     calendar-proxy-read
+                     calendar-proxy-write
+                 + red/
+                     calendar-proxy-read
+                     calendar-proxy-write
+                 + wilfredo/
+                     calendar-proxy-read
+                     calendar-proxy-write
+
+   If the principal "cyrus" wishes to have the principal "red" act as a
+   calendar user proxy on his behalf and have the ability to change
+   items on his calendar or schedule meetings on his behalf, then he
+   would add the principal resource URI for "red" to the DAV:group-
+   member-set property of the principal resource /principals/users/
+   cyrus/calendar-proxy-write, giving:
+
+   <DAV:group-member-set>
+     <DAV:href>/principals/users/red/</DAV:href>
+   </DAV:group-member-set>
+
+   The DAV:group-membership property on the resource /principals/users/
+   red/ would be:
+
+   <DAV:group-membership>
+     <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
+   </DAV:group-membership>
+
+   If the principal "red" was also a read-only proxy for the principal
+   "wilfredo", then the DA:group-membership property on the resource
+   /principals/users/red/ would be:
+
+
+
+
+Daboo                                                           [Page 5]
+
+                              CalDAV Proxy                      May 2007
+
+
+   <DAV:group-membership>
+     <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
+     <DAV:href>/principals/users/wilfredo/calendar-proxy-read</DAV:href>
+   </DAV:group-membership>
+
+   Thus a client can discover to which principals a particular principal
+   is acting as a calendar user proxy for by examining the DAV:group-
+   membership property.
+
+   An alternative to discovering which principals a user can proxy as is
+   to use the WebDAV ACL principal-match report, targeted at the
+   principal collections available on the server.
+
+   Example:
+
+   >> Request <<
+
+   REPORT /principals/ HTTP/1.1
+   Host: cal.example.com
+   Depth: 0
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+   Authorization: Digest username="red",
+    realm="cal.example.com", nonce="...",
+    uri="/principals/", response="...", opaque="..."
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:principal-match xmlns:D="DAV:">
+     <D:self/>
+     <D:prop>
+       <D:resourcetype/>
+     </D:prop>
+   </D:principal-match>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                                                           [Page 6]
+
+                              CalDAV Proxy                      May 2007
+
+
+   >> Response <<
+
+   HTTP/1.1 207 Multi-Status
+   Date: Fri, 10 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:A="http://calendarserver.org/ns/">
+     <D:response>
+       <D:href>/principals/users/red/</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:resourcetype>
+             <D:principal/>
+             <D:collection/>
+           </D:resourcetype>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>/principals/users/cyrus/calendar-proxy-write</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:resourcetype>
+             <D:principal/>
+             <A:calendar-proxy-write/>
+           </D:resourcetype>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+     <D:response>
+       <D:href>/principals/users/wilfredo/calendar-proxy-read</D:href>
+       <D:propstat>
+         <D:prop>
+           <D:resourcetype>
+             <D:principal/>
+             <A:calendar-proxy-read/>
+           </D:resourcetype>
+         </D:prop>
+         <D:status>HTTP/1.1 200 OK</D:status>
+       </D:propstat>
+     </D:response>
+   </D:multistatus>
+
+
+
+
+Daboo                                                           [Page 7]
+
+                              CalDAV Proxy                      May 2007
+
+
+5.2.  Privilege Provisioning
+
+   In order for a calendar user proxy to be able to access the calendars
+   of the user they are proxying for the server MUST ensure that the
+   privileges on the relevant calendars are setup accordingly:
+
+      The DAV:read privilege MUST be granted for read-only and read-
+      write calendar user proxy principals
+
+      The DAV:write privilege MUST be granted for read-write calendar
+      user proxy principals.
+
+   Additionally, the CalDAV scheduling Inbox and Outbox calendar
+   collections for the user allowing proxy access, MUST have the CALDAV:
+   schedule privilege [I-D.desruisseaux-caldav-sched] granted for read-
+   write calendar user proxy principals.
+
+   Note that with a suitable repository layout, a server may be able to
+   grant the appropriate privileges on a parent collection and ensure
+   that all the contained collections and resources inherit that.  For
+   example, given the following repository layout:
+
+           + /
+             + calendars/
+               + users/
+                 + cyrus/
+                     inbox
+                     outbox
+                     home
+                     work
+                 + red/
+                     inbox
+                     outbox
+                     work
+                     soccer
+                 + wilfredo/
+                     inbox
+                     outbox
+                     home
+                     work
+                     flying
+
+   In order for the principal "red" to act as a read-write proxy for the
+   principal "cyrus", the following WebDAV ACE will need to be granted
+   on the resource /calendars/users/cyrus/ and all children of that
+   resource:
+
+
+
+
+
+Daboo                                                           [Page 8]
+
+                              CalDAV Proxy                      May 2007
+
+
+   <DAV:ace>
+     <DAV:principal>
+       <DAV:href>/principals/users/cyrus/calendar-proxy-write</DAV:href>
+     </DAV:principal>
+     <DAV:privileges>
+       <DAV:grant><DAV:read/><DAV:write/></DAV:grant>
+     </DAV:privileges>
+   </DAV:ace>
+
+
+6.  Security Considerations
+
+   TBD
+
+
+7.  IANA Considerations
+
+   This document does not require any actions on the part of IANA.
+
+
+8.  Normative References
+
+   [I-D.desruisseaux-caldav-sched]
+              Desruisseaux, B., "Scheduling Extensions to CalDAV",
+              draft-desruisseaux-caldav-sched-03 (work in progress),
+              January 2007.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2518]  Goland, Y., Whitehead, E., Faizi, A., Carter, S., and D.
+              Jensen, "HTTP Extensions for Distributed Authoring --
+              WEBDAV", RFC 2518, February 1999.
+
+   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+              Distributed Authoring and Versioning (WebDAV) Access
+              Control Protocol", RFC 3744, May 2004.
+
+   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
+              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+              March 2007.
+
+
+Appendix A.  Acknowledgments
+
+   This specification is the result of discussions between the Apple
+   calendar server and client teams.
+
+
+
+
+Daboo                                                           [Page 9]
+
+                              CalDAV Proxy                      May 2007
+
+
+Appendix B.  Change History
+
+   Changes from -00:
+
+   1.  Updated to RFC 4791 reference.
+
+   Changes from -00:
+
+   1.  Added more details on actual CalDAV protocol changes.
+
+   2.  Changed namespace from http://apple.com/ns/calendarserver/ to
+       http://calendarserver.org/ns/.
+
+   3.  Made "proxy group" principals child resources of their "owner"
+       principals.
+
+   4.  The "proxy group" principals now have their own resourcetype.
+
+
+Author's Address
+
+   Cyrus Daboo
+   Apple Computer, Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   Email: cyrus@daboo.name
+   URI:   http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                                                          [Page 10]
+

dav/SabreDAV/docs/draft-daboo-carddav-directory-gateway-02.txt

@@ -0,0 +1,560 @@
+
+
+
+Network Working Group                                           C. Daboo
+Internet-Draft                                                Apple Inc.
+Updates: XXXX-CardDAV                                    August 24, 2010
+(if approved)
+Intended status: Standards Track
+Expires: February 25, 2011
+
+
+                  CardDAV Directory Gateway Extension
+                draft-daboo-carddav-directory-gateway-02
+
+Abstract
+
+   This document defines an extension to the vCard Extensions to WebDAV
+   (CardDAV) protocol that allows a server to expose a directory as a
+   read-only address book collection.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on February 25, 2011.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+Daboo                   Expires February 25, 2011               [Page 1]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+Table of Contents
+
+   1.  Introduction and Overview  . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   3.  CARDDAV:directory-gateway Property . . . . . . . . . . . . . .  4
+   4.  XML Element Definitions  . . . . . . . . . . . . . . . . . . .  5
+     4.1.  CARDDAV:directory  . . . . . . . . . . . . . . . . . . . .  5
+   5.  Client Guidelines  . . . . . . . . . . . . . . . . . . . . . .  5
+   6.  Server Guidelines  . . . . . . . . . . . . . . . . . . . . . .  6
+   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
+   8.  IANA Consideration . . . . . . . . . . . . . . . . . . . . . .  8
+   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  8
+   10. References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
+     10.1. Normative References . . . . . . . . . . . . . . . . . . .  8
+     10.2. Informative References . . . . . . . . . . . . . . . . . .  9
+   Appendix A.  Change History (to be removed prior to
+                publication as an RFC)  . . . . . . . . . . . . . . .  9
+   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                   Expires February 25, 2011               [Page 2]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+1.  Introduction and Overview
+
+   The CardDAV [I-D.ietf-vcarddav-carddav] protocol defines a standard
+   way of accessing, managing, and sharing contact information based on
+   the vCard [RFC2426] format.  Often, in an enterprise or service
+   provider environment, a directory of all users hosted on the server
+   (or elsewhere) is available (for example via Lightweight Directory
+   Access Protocol (LDAP) [RFC4510] or some direct database access).  It
+   would be convenient for CardDAV clients if this directory were
+   exposed as a "global" address book on the CardDAV server so it could
+   be searched in the same way as personal address books are.  This
+   specification defines a "directory gateway" feature extension to
+   CardDAV to enable this.
+
+   This specification adds one new WebDAV property to principal
+   resources that contains the URL to one or more directory gateway
+   address book collection resources.  It is important for clients to be
+   able to distinguish this address book collection from others because
+   there are specific limitations involved in using it as described
+   below.  To aid that, this specification defines an XML element that
+   can be included as a child element of the DAV:resourcetype property
+   of address book collections to identify them as directory gateways.
+
+   Note that this feature is in no way intended to replace full
+   directory access - it is meant to simply provide a convenient way for
+   CardDAV clients to query contact-related attributes in directory
+   records.
+
+
+2.  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 15 of [RFC4918].
+
+   This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section
+   3.2) as a purely notational convention.  WebDAV request and response
+   bodies cannot be validated by a DTD due to the specific extensibility
+   rules defined in Section 17 of [RFC4918] and due to the fact that all
+   XML elements defined by this specification use the XML namespace name
+   "DAV:".  In particular:
+
+   1.  element names use the "DAV:" namespace,
+
+
+
+
+
+Daboo                   Expires February 25, 2011               [Page 3]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+   2.  element ordering is irrelevant unless explicitly stated,
+
+   3.  extension elements (elements not already defined as valid child
+       elements) may be added anywhere, except when explicitly stated
+       otherwise,
+
+   4.  extension attributes (attributes not already defined as valid for
+       this element) may be added anywhere, except when explicitly
+       stated otherwise.
+
+   When XML element types in the namespaces "DAV:" and
+   "urn:ietf:params:xml:ns:carddav" are referenced in this document
+   outside of the context of an XML fragment, the strings "DAV:" and
+   "CARDDAV:" will be prefixed to the element types, respectively.
+
+
+3.  CARDDAV:directory-gateway Property
+
+   Name:  directory-gateway
+
+   Namespace:  urn:ietf:params:xml:ns:carddav
+
+   Purpose:  Identifies URLs of CardDAV address book collections acting
+      as a directory gateway for the server.
+
+   Protected:  MUST be protected.
+
+   allprop behavior:  SHOULD NOT be returned by a PROPFIND DAV:allprop
+      request.
+
+   Description:  The CARDDAV:directory-gateway identifies address book
+      collection resources that are directory gateway address books for
+      the server.
+
+   Definition:
+
+       <!ELEMENT directory-gateway (DAV:href*)>
+
+   Example:
+
+       <C:directory-gateway xmlns:D="DAV:"
+          xmlns:C="urn:ietf:params:xml:ns:carddav">
+         <D:href>/directory</D:href>
+       </C:directory-gateway>
+
+
+
+
+
+
+
+Daboo                   Expires February 25, 2011               [Page 4]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+4.  XML Element Definitions
+
+4.1.  CARDDAV:directory
+
+   Name:  directory
+
+   Namespace:  urn:ietf:params:xml:ns:carddav
+
+   Purpose:  Used to indicate that an address book collection is a
+      directory gateway.
+
+   Description:  This element appears in the DAV:resourcetype property
+      on a address book collection resources that are directory
+      gateways.  Clients can use the presence of this element to
+      identify directory gateway collections when doing PROPFINDs to
+      list collection contents.
+
+   Definition:
+
+   <!ELEMENT directory EMPTY>
+
+   Example:
+
+       <D:resourcetype xmlns:D="DAV:"
+          xmlns:C="urn:ietf:params:xml:ns:carddav">
+         <D:collection/>
+         <C:addressbook/>
+         <C:directory/>
+       </D:resourcetype>
+
+
+5.  Client Guidelines
+
+   Clients wishing to make use of directory gateway address books can
+   request the CARDDAV:directory-gateway property (Section 3) when
+   examining other properties on the principal resource for the user.
+   If the property is not present, then the directory gateway feature is
+   not supported by the server at that time.
+
+   Clients can also detect the presence of directory gateway address
+   book collections by retrieving the DAV:resourcetype property on
+   collections that it lists, and look for the presence of the CARDDAV:
+   directory element (Section 4.1).
+
+   Since the directory being exposed via a directory gateway address
+   book collection could be large, clients SHOULD limit the number of
+   results returned in an CARDDAV:addressbook-query REPORT as defined in
+   Section 8.6.1 of [I-D.ietf-vcarddav-carddav].
+
+
+
+Daboo                   Expires February 25, 2011               [Page 5]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+   Clients MUST treat the directory gateway address book collection as a
+   read-only collection, so HTTP methods that modify resource data or
+   properties in the address book collection MUST NOT be used.
+
+   Clients SHOULD NOT attempt to cache the entire contents of the
+   directory gateway address book collection resource by retrieving all
+   resources, or trying to examine all the properties of all resources
+   (e.g., via a PROPFIND Depth:1 request).  Instead, CARDDAV:
+   addressbook-query REPORTs are used to search for specific address
+   book object resources, and CARDDAV:multiget REPORTs and individual
+   GET requests can be made to retrieve the actual vCard data for
+   address book object resources found via a query.
+
+   When presenting directory gateway collections to the user, clients
+   SHOULD use the DAV:displayname property on the corresponding address
+   book collections as the name of the directory gateway.  This is
+   important in the case where more than one directory gateway is
+   available.  Clients MAY also provide descriptive information about
+   each directory gateway by examining the CARDDAV:addressbook-
+   description property (see Section 6.2.1 of
+   [I-D.ietf-vcarddav-carddav]) on the resource.
+
+
+6.  Server Guidelines
+
+   Servers wishing to expose a directory gateway as an address book
+   collection MUST include the CARDDAV:directory-gateway property on all
+   principal resources of users expected to use the feature.
+
+   Since the directory being exposed via the directory gateway address
+   book collection could be large, servers SHOULD truncate the number of
+   results returned in an CARDDAV:addressbook-query REPORT as defined in
+   Section 8.6.2 of [I-D.ietf-vcarddav-carddav].  In addition, servers
+   SHOULD disallow requests that effectively enumerate the collection
+   contents (e.g., PROPFIND Depth:1, trivial CARDDAV:addressbook-query,
+   DAV:sync-collection REPORT).
+
+   Servers need to expose the directory information as a set of address
+   book object resources in the directory gateway address book
+   collection resource.  To do that, a mapping between the directory
+   record format and the vCard data has to be applied.  In general, only
+   directory record attributes that have a direct equivalent in vCard
+   SHOULD be mapped.  It is up to individual implementations to
+   determine which attributes to map.  But in all cases servers MUST
+   generate valid vCard data as returned to the client.  In addition, as
+   required by CardDAV, the UID vCard property MUST be present in the
+   vCard data, and this value MUST be persistent from query to query for
+   the same directory record.
+
+
+
+Daboo                   Expires February 25, 2011               [Page 6]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+   Multiple directory sources could be available to the server.  The
+   server MAY use a single directory gateway resource to aggregate
+   results from each directory source.  When doing so care is needed
+   when dealing with potential records that refer to the same entity.
+   Servers MAY suppress any duplicates that they are able to determine
+   themselves.  Alternatively, multiple directory sources can be exposed
+   as separate directory gateway resources.
+
+   For any directory source, a server MAY expose multiple directory
+   gateway resources where each represents a different query "scope" for
+   the directory.  Different scopes MAY be offered to different
+   principals on the server.  For example, the server might expose an
+   entire company directory for searching as the resource "/directory-
+   all" to all principals, but then provide "/directory-department-XYZ"
+   as another directory gateway that has a search scope that implicitly
+   limits the search results to just the "XYZ" department.  Users in
+   that department would then have a CARDDAV:directory-gateway property
+   on their principal resource that included the "/directory-department-
+   XYZ" resource.  Users in other departments would have corresponding
+   directory gateway resources available to them.
+
+   Records in a directory can include data for more than just people,
+   e.g, resources such as rooms or projectors, groups, computer systems
+   etc.  It is up to individual implementations to determine the most
+   appropriate "scope" for the data returned via the directory gateway
+   by filtering the appropriate record types.  As above, servers could
+   choose to expose people and resources under different directory
+   gateway resources by implicitly limiting the search "scope" for each
+   of those.
+
+   Servers MAY apply implementation defined access rules to determine,
+   on a per-user basis, what records are returned to a particularly user
+   and the content of those records exposed via vCard data.  This per-
+   user behavior is in addition to the general security requirements
+   detailed below.
+
+   When multiple directory gateway collections are present, servers
+   SHOULD provide a DAV:displayname property on each that disambiguates
+   them.  Servers MAY include a CARDDAV:addressbook-description property
+   (see Section 6.2.1 of [I-D.ietf-vcarddav-carddav]) on each directory
+   gateway resource to provide a description of the directory and any
+   search "scope" that might be used, or any other useful information
+   for users.
+
+
+7.  Security Considerations
+
+   Servers MUST ensure that client requests against the directory
+
+
+
+Daboo                   Expires February 25, 2011               [Page 7]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+   gateway address book collection cannot use excessive resources (CPU,
+   memory, network bandwidth etc), given that the directory could be
+   large.
+
+   Servers MUST take care not to expose sensitive directory record
+   attributes in the vCard data via the directory gateway address book.
+   In general only those properties that have direct correspondence in
+   vCard SHOULD be exposed.
+
+   Servers need to determine whether it is appropriate for the directory
+   information to be available via CardDAV to unauthenticated users.  If
+   not, servers MUST ensure that unauthenticated users do not have
+   access to the directory gateway address book object resource and its
+   contents.  If unauthenticated access is allowed, servers MAY choose
+   to limit the set of vCard properties that are searchable or returned
+   in the address book object resources when unauthenticated requests
+   are made.
+
+
+8.  IANA Consideration
+
+   This document does not require any actions on the part of IANA.
+
+
+9.  Acknowledgments
+
+
+10.  References
+
+10.1.  Normative References
+
+   [I-D.ietf-vcarddav-carddav]
+              Daboo, C., "vCard Extensions to WebDAV (CardDAV)",
+              draft-ietf-vcarddav-carddav-10 (work in progress),
+              November 2009.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2426]  Dawson, F. and T. Howes, "vCard MIME Directory Profile",
+              RFC 2426, September 1998.
+
+   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+   [W3C.REC-xml-20081126]
+              Paoli, J., Yergeau, F., Bray, T., Sperberg-McQueen, C.,
+              and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth
+
+
+
+Daboo                   Expires February 25, 2011               [Page 8]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+              Edition)", World Wide Web Consortium Recommendation REC-
+              xml-20081126, November 2008,
+              <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+10.2.  Informative References
+
+   [RFC4510]  Zeilenga, K., "Lightweight Directory Access Protocol
+              (LDAP): Technical Specification Road Map", RFC 4510,
+              June 2006.
+
+
+Appendix A.  Change History (to be removed prior to publication as an
+             RFC)
+
+   Changes in -02
+
+   1.  Added CARDDAV:directory element for use in DAV:resourcetype
+
+   2.  Allow CARDDAV:directory-gateway to be multi-valued
+
+   3.  Explain how a server could implicit "scope" queries on different
+       directory gateway resources
+
+   Changes in -01
+
+   1.  Remove duplicated text in a couple of sections
+
+   2.  Add example of LDAP/generic database as possible directory
+       "sources"
+
+   3.  Add text to explain why the client needs to treat this as special
+       and thus the need for a property
+
+   4.  Added text to server guidelines indicating requirements for
+       handling vCard UID properties
+
+   5.  Added text to server guidelines explain that different record
+       "types" may exist in the directory and the server is free to
+       filter those as appropriate
+
+   6.  Added text to server guidelines indicating that server are free
+       to aggregate directory records from multiple sources
+
+   7.  Added text to server guidelines indicating that servers are free
+       to apply implementation defined access control to the returned
+       data on a per-user basis
+
+
+
+
+
+Daboo                   Expires February 25, 2011               [Page 9]
+
+Internet-Draft     CardDAV Directory Gateway Extension       August 2010
+
+
+Author's Address
+
+   Cyrus Daboo
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   Email: cyrus@daboo.name
+   URI:   http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                   Expires February 25, 2011              [Page 10]
+

dav/SabreDAV/docs/draft-nottingham-http-new-status-04.txt

@@ -0,0 +1,560 @@
+
+
+
+Network Working Group                                      M. Nottingham
+Internet-Draft                                                 Rackspace
+Updates: 2616 (if approved)                                  R. Fielding
+Intended status: Standards Track                                   Adobe
+Expires: August 7, 2012                                 February 4, 2012
+
+
+                      Additional HTTP Status Codes
+                  draft-nottingham-http-new-status-04
+
+Abstract
+
+   This document specifies additional HyperText Transfer Protocol (HTTP)
+   status codes for a variety of common situations.
+
+Editorial Note (To be removed by RFC Editor before publication)
+
+   Distribution of this document is unlimited.  Although this is not a
+   work item of the HTTPbis Working Group, comments should be sent to
+   the Hypertext Transfer Protocol (HTTP) mailing list at
+   ietf-http-wg@w3.org [1], which may be joined by sending a message
+   with subject "subscribe" to ietf-http-wg-request@w3.org [2].
+
+   Discussions of the HTTPbis Working Group are archived at
+   <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
+
+Status of this Memo
+
+   This Internet-Draft is submitted in full conformance with the
+   provisions of BCP 78 and BCP 79.
+
+   Internet-Drafts are working documents of the Internet Engineering
+   Task Force (IETF).  Note that other groups may also distribute
+   working documents as Internet-Drafts.  The list of current Internet-
+   Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+   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."
+
+   This Internet-Draft will expire on August 7, 2012.
+
+Copyright Notice
+
+   Copyright (c) 2012 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 1]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   2.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . . . 3
+   3.  428 Precondition Required . . . . . . . . . . . . . . . . . . . 3
+   4.  429 Too Many Requests . . . . . . . . . . . . . . . . . . . . . 4
+   5.  431 Request Header Fields Too Large . . . . . . . . . . . . . . 4
+   6.  511 Network Authentication Required . . . . . . . . . . . . . . 5
+   7.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 8
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
+   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . . . 8
+   Appendix B.  Issues Raised by Captive Portals . . . . . . . . . . . 8
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 2]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+1.  Introduction
+
+   This document specifies additional HTTP [RFC2616] status codes for a
+   variety of common situations, to improve interoperability and avoid
+   confusion when other, less precise status codes are used.
+
+   Note that these status codes are optional; servers cannot be required
+   to support them.  However, because clients will treat unknown status
+   codes as a generic error of the same class (e.g., 499 is treated as
+   400 if it is not recognized), they can be safely deployed by existing
+   servers (see [RFC2616] Section 6.1.1 for more information).
+
+
+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 [RFC2119].
+
+
+3.  428 Precondition Required
+
+   The 428 status code indicates that the origin server requires the
+   request to be conditional.
+
+   Its typical use is to avoid the "lost update" problem, where a client
+   GETs a resource's state, modifies it, and PUTs it back to the server,
+   when meanwhile a third party has modified the state on the server,
+   leading to a conflict.  By requiring requests to be conditional, the
+   server can assure that clients are working with the correct copies.
+
+   Responses using this status code SHOULD explain how to resubmit the
+   request successfully.  For example:
+
+   HTTP/1.1 428 Precondition Required
+   Content-Type: text/html
+
+   <html>
+    <head>
+     <title>Precondition Required</title>
+    </head>
+    <body>
+     <h1>Precondition Required</h1>
+      <p>This request is required to be conditional;
+         try using "If-Match".</p>
+    </body>
+   </html>
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 3]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+   Responses with the 428 status code MUST NOT be stored by a cache.
+
+
+4.  429 Too Many Requests
+
+   The 429 status code indicates that the user has sent too many
+   requests in a given amount of time ("rate limiting").
+
+   The response representations SHOULD include details explaining the
+   condition, and MAY include a Retry-After header indicating how long
+   to wait before making a new request.
+
+   For example:
+
+   HTTP/1.1 429 Too Many Requests
+   Content-Type: text/html
+   Retry-After: 3600
+
+   <html>
+      <head>
+         <title>Too Many Requests</title>
+      </head>
+      <body>
+         <h1>Too Many Requests</h1>
+         <p>I only allow 50 requests per hour to this Web site per
+            logged in user. Try again soon.</p>
+      </body>
+   </html>
+
+   Note that this specification does not define how the origin server
+   identifies the user, nor how it counts requests.  For example, an
+   origin server that is limiting request rates can do so based upon
+   counts of requests on a per-resource basis, across the entire server,
+   or even among a set of servers.  Likewise, it might identify the user
+   by its authentication credentials, or a stateful cookie.
+
+   Responses with the 429 status code MUST NOT be stored by a cache.
+
+
+5.  431 Request Header Fields Too Large
+
+   The 431 status code indicates that the server is unwilling to process
+   the request because its header fields are too large.  The request MAY
+   be resubmitted after reducing the size of the request header fields.
+
+   It can be used both when the set of request header fields in total
+   are too large, and when a single header field is at fault.  In the
+   latter case, the response representation SHOULD specify which header
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 4]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+   field was too large.
+
+   For example:
+
+   HTTP/1.1 431 Request Header Fields Too Large
+   Content-Type: text/html
+
+   <html>
+      <head>
+         <title>Request Header Fields Too Large</title>
+      </head>
+      <body>
+         <h1>Request Header Fields Too Large</h1>
+         <p>The "Example" header was too large.</p>
+      </body>
+   </html>
+
+   Responses with the 431 status code MUST NOT be stored by a cache.
+
+
+6.  511 Network Authentication Required
+
+   The 511 status code indicates that the client needs to authenticate
+   to gain network access.
+
+   The response representation SHOULD contain a link to a resource that
+   allows the user to submit credentials (e.g. with a HTML form).
+
+   Note that the 511 response SHOULD NOT contain a challenge or the
+   login interface itself, because browsers would show the login
+   interface as being associated with the originally requested URL,
+   which may cause confusion.
+
+   The 511 status SHOULD NOT be generated by origin servers; it is
+   intended for use by intercepting proxies that are interposed as a
+   means of controlling access to the network.
+
+   Responses with the 511 status code MUST NOT be stored by a cache.
+
+6.1.  The 511 Status Code and Captive Portals
+
+   The 511 status code is designed to mitigate problems caused by
+   "captive portals" to software (especially non-browser agents) that is
+   expecting a response from the server that a request was made to, not
+   the intervening network infrastructure.  It is not intended to
+   encouraged deployment of captive portals, only to limit the damage
+   caused by them.
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 5]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+   A network operator wishing to require some authentication, acceptance
+   of terms or other user interaction before granting access usually
+   does so by identifing clients who have not done so ("unknown
+   clients") using their MAC addresses.
+
+   Unknown clients then have all traffic blocked, except for that on TCP
+   port 80, which is sent to a HTTP server (the "login server")
+   dedicated to "logging in" unknown clients, and of course traffic to
+   the login server itself.
+
+   For example, a user agent might connect to a network and make the
+   following HTTP request on TCP port 80:
+
+   GET /index.htm HTTP/1.1
+   Host: www.example.com
+
+   Upon receiving such a request, the login server would generate a 511
+   response:
+
+   HTTP/1.1 511 Network Authentication Required
+   Content-Type: text/html
+
+   <html>
+      <head>
+         <title>Network Authentication Required</title>
+         <meta http-equiv="refresh"
+               content="0; url=https://login.example.net/">
+      </head>
+      <body>
+         <p>You need to <a href="https://login.example.net/">
+         authenticate with the local network</a> in order to gain
+         access.</p>
+      </body>
+   </html>
+
+   Here, the 511 status code assures that non-browser clients will not
+   interpret the response as being from the origin server, and the META
+   HTML element redirects the user agent to the login server.
+
+
+7.  Security Considerations
+
+7.1.  428 Precondition Required
+
+   The 428 status code is optional; clients cannot rely upon its use to
+   prevent "lost update" conflicts.
+
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 6]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+7.2.  429 Too Many Requests
+
+   When a server is under attack or just receiving a very large number
+   of requests from a single party, responding to each with a 429 status
+   code will consume resources.
+
+   Therefore, servers are not required to use the 429 status code; when
+   limiting resource usage, it may be more appropriate to just drop
+   connections, or take other steps.
+
+7.3.  431 Request Header Fields Too Large
+
+   Servers are not required to use the 431 status code; when under
+   attack, it may be more appropriate to just drop connections, or take
+   other steps.
+
+7.4.  511 Network Authentication Required
+
+   In common use, a response carrying the 511 status code will not come
+   from the origin server indicated in the request's URL.  This presents
+   many security issues; e.g., an attacking intermediary may be
+   inserting cookies into the original domain's name space, may be
+   observing cookies or HTTP authentication credentials sent from the
+   user agent, and so on.
+
+   However, these risks are not unique to the 511 status code; in other
+   words, a captive portal that is not using this status code introduces
+   the same issues.
+
+   Also, note that captive portals using this status code on an SSL or
+   TLS connection (commonly, port 443) will generate a certificate error
+   on the client.
+
+
+8.  IANA Considerations
+
+   The HTTP Status Codes Registry should be updated with the following
+   entries:
+
+   o  Code: 428
+   o  Description: Precondition Required
+   o  Specification: [ this document ]
+
+   o  Code: 429
+   o  Description: Too Many Requests
+   o  Specification: [ this document ]
+
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 7]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+   o  Code: 431
+   o  Description: Request Header Fields Too Large
+   o  Specification: [ this document ]
+
+   o  Code: 511
+   o  Description: Network Authentication Required
+   o  Specification: [ this document ]
+
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+9.2.  Informative References
+
+   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
+              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+              March 2007.
+
+   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+URIs
+
+   [1]  <mailto:ietf-http-wg@w3.org>
+
+   [2]  <mailto:ietf-http-wg-request@w3.org?subject=subscribe>
+
+
+Appendix A.  Acknowledgements
+
+   Thanks to Jan Algermissen and Julian Reschke for their suggestions
+   and feedback.
+
+
+Appendix B.  Issues Raised by Captive Portals
+
+   Since clients cannot differentiate between a portal's response and
+   that of the HTTP server that they intended to communicate with, a
+   number of issues arise.  The 511 status code is intended to help
+   mitigate some of them.
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 8]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+   One example is the "favicon.ico"
+   <http://en.wikipedia.org/wiki/Favicon> commonly used by browsers to
+   identify the site being accessed.  If the favicon for a given site is
+   fetched from a captive portal instead of the intended site (e.g.,
+   because the user is unauthenticated), it will often "stick" in the
+   browser's cache (most implementations cache favicons aggressively)
+   beyond the portal session, so that it seems as if the portal's
+   favicon has "taken over" the legitimate site.
+
+   Another browser-based issue comes about when P3P
+   <http://www.w3.org/TR/P3P/> is supported.  Depending on how it is
+   implemented, it's possible a browser might interpret a portal's
+   response for the p3p.xml file as the server's, resulting in the
+   privacy policy (or lack thereof) advertised by the portal being
+   interpreted as applying to the intended site.  Other Web-based
+   protocols such as WebFinger
+   <http://code.google.com/p/webfinger/wiki/WebFingerProtocol>, CORS
+   <http://www.w3.org/TR/cors/> and OAuth
+   <http://tools.ietf.org/html/draft-ietf-oauth-v2> may also be
+   vulnerable to such issues.
+
+   Although HTTP is most widely used with Web browsers, a growing number
+   of non-browsing applications use it as a substrate protocol.  For
+   example, WebDAV [RFC4918] and CalDAV [RFC4791] both use HTTP as the
+   basis (for remote authoring and calendaring, respectively).  Using
+   these applications from behind a captive portal can result in
+   spurious errors being presented to the user, and might result in
+   content corruption, in extreme cases.
+
+   Similarly, other non-browser applications using HTTP can be affected
+   as well; e.g., widgets <http://www.w3.org/TR/widgets/>, software
+   updates, and other specialised software such as Twitter clients and
+   the iTunes Music Store.
+
+   It should be noted that it's sometimes believed that using HTTP
+   redirection to direct traffic to the portal addresses these issues.
+   However, since many of these uses "follow" redirects, this is not a
+   good solution.
+
+
+Authors' Addresses
+
+   Mark Nottingham
+   Rackspace
+
+   Email: mnot@mnot.net
+   URI:   http://www.mnot.net/
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                 [Page 9]
+
+Internet-Draft        Additional HTTP Status Codes         February 2012
+
+
+   Roy T. Fielding
+   Adobe Systems Incorporated
+   345 Park Ave
+   San Jose, CA  95110
+   USA
+
+   Email: fielding@gbiv.com
+   URI:   http://roy.gbiv.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Fielding    Expires August 7, 2012                [Page 10]
+

dav/SabreDAV/docs/rfc5051.txt

@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         M. Crispin
+Request for Comments: 5051                      University of Washington
+Category: Standards Track                                   October 2007
+
+
+         i;unicode-casemap - Simple Unicode Collation Algorithm
+
+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.
+
+Abstract
+
+   This document describes "i;unicode-casemap", a simple case-
+   insensitive collation for Unicode strings.  It provides equality,
+   substring, and ordering operations.
+
+1.  Introduction
+
+   The "i;ascii-casemap" collation described in [COMPARATOR] is quite
+   simple to implement and provides case-independent comparisons for the
+   26 Latin alphabetics.  It is specified as the default and/or baseline
+   comparator in some application protocols, e.g., [IMAP-SORT].
+
+   However, the "i;ascii-casemap" collation does not produce
+   satisfactory results with non-ASCII characters.  It is possible, with
+   a modest extension, to provide a more sophisticated collation with
+   greater multilingual applicability than "i;ascii-casemap".  This
+   extension provides case-independent comparisons for a much greater
+   number of characters.  It also collates characters with diacriticals
+   with the non-diacritical character forms.
+
+   This collation, "i;unicode-casemap", is intended to be an alternative
+   to, and preferred over, "i;ascii-casemap".  It does not replace the
+   "i;basic" collation described in [BASIC].
+
+2.  Unicode Casemap Collation Description
+
+   The "i;unicode-casemap" collation is a simple collation which is
+   case-insensitive in its treatment of characters.  It provides
+   equality, substring, and ordering operations.  The validity test
+   operation returns "valid" for any input.
+
+
+
+
+
+Crispin                     Standards Track                     [Page 1]
+
+RFC 5051                   i;unicode-casemap                October 2007
+
+
+   This collation allows strings in arbitrary (and mixed) character
+   sets, as long as the character set for each string is identified and
+   it is possible to convert the string to Unicode.  Strings which have
+   an unidentified character set and/or cannot be converted to Unicode
+   are not rejected, but are treated as binary.
+
+   Each input string is prepared by converting it to a "titlecased
+   canonicalized UTF-8" string according to the following steps, using
+   UnicodeData.txt ([UNICODE-DATA]):
+
+      (1) A Unicode codepoint is obtained from the input string.
+
+          (a) If the input string is in a known charset that can be
+              converted to Unicode, a sequence in the string's charset
+              is read and checked for validity according to the rules of
+              that charset.  If the sequence is valid, it is converted
+              to a Unicode codepoint.  Note that for input strings in
+              UTF-8, the UTF-8 sequence must be valid according to the
+              rules of [UTF-8]; e.g., overlong UTF-8 sequences are
+              invalid.
+
+          (b) If the input string is in an unknown charset, or an
+              invalid sequence occurs in step (1)(a), conversion ceases.
+              No further preparation is performed, and any partial
+              preparation results are discarded.  The original string is
+              used unchanged with the i;octet comparator.
+
+      (2) The following steps, using UnicodeData.txt ([UNICODE-DATA]),
+          are performed on the resulting codepoint from step (1)(a).
+
+          (a) If the codepoint has a titlecase property in
+              UnicodeData.txt (this is normally the same as the
+              uppercase property), the codepoint is converted to the
+              codepoints in the titlecase property.
+
+          (b) If the resulting codepoint from (2)(a) has a decomposition
+              property of any type in UnicodeData.txt, the codepoint is
+              converted to the codepoints in the decomposition property.
+              This step is recursively applied to each of the resulting
+              codepoints until no more decomposition is possible
+              (effectively Normalization Form KD).
+
+          Example: codepoint U+01C4 (LATIN CAPITAL LETTER DZ WITH CARON)
+          has a titlecase property of U+01C5 (LATIN CAPITAL LETTER D
+          WITH SMALL LETTER Z WITH CARON).  Codepoint U+01C5 has a
+          decomposition property of U+0044 (LATIN CAPITAL LETTER D)
+          U+017E (LATIN SMALL LETTER Z WITH CARON).  U+017E has a
+          decomposition property of U+007A (LATIN SMALL LETTER Z) U+030c
+
+
+
+Crispin                     Standards Track                     [Page 2]
+
+RFC 5051                   i;unicode-casemap                October 2007
+
+
+          (COMBINING CARON).  Neither U+0044, U+007A, nor U+030C have
+          any decomposition properties.  Therefore, U+01C4 is converted
+          to U+0044 U+007A U+030C by this step.
+
+      (3) The resulting codepoint(s) from step (2) is/are appended, in
+          UTF-8 format, to the "titlecased canonicalized UTF-8" string.
+
+      (4) Repeat from step (1) until there is no more data in the input
+          string.
+
+   Following the above preparation process on each string, the equality,
+   ordering, and substring operations are as for i;octet.
+
+   It is permitted to use an alternative implementation of the above
+   preparation process if it produces the same results.  For example, it
+   may be more convenient for an implementation to convert all input
+   strings to a sequence of UTF-16 or UTF-32 values prior to performing
+   any of the step (2) actions.  Similarly, if all input strings are (or
+   are convertible to) Unicode, it may be possible to use UTF-32 as an
+   alternative to UTF-8 in step (3).
+
+      Note: UTF-16 is unsuitable as an alternative to UTF-8 in step (3),
+      because UTF-16 surrogates will cause i;octet to collate codepoints
+      U+E0000 through U+FFFF after non-BMP codepoints.
+
+   This collation is not locale sensitive.  Consequently, care should be
+   taken when using OS-supplied functions to implement this collation.
+   Functions such as strcasecmp and toupper are sometimes locale
+   sensitive and may inconsistently casemap letters.
+
+   The i;unicode-casemap collation is well suited to use with many
+   Internet protocols and computer languages.  Use with natural language
+   is often inappropriate; even though the collation apparently supports
+   languages such as Swahili and English, in real-world use it tends to
+   mis-sort a number of types of string:
+
+   o  people and place names containing scripts that are not collated
+      according to "alphabetical order".
+   o  words with characters that have diacriticals.  However,
+      i;unicode-casemap generally does a better job than i;ascii-casemap
+      for most (but not all) languages.  For example, German umlaut
+      letters will sort correctly, but some Scandinavian letters will
+      not.
+   o  names such as "Lloyd" (which in Welsh sorts after "Lyon", unlike
+      in English),
+   o  strings containing other non-letter symbols; e.g., euro and pound
+      sterling symbols, quotation marks other than '"', dashes/hyphens,
+      etc.
+
+
+
+Crispin                     Standards Track                     [Page 3]
+
+RFC 5051                   i;unicode-casemap                October 2007
+
+
+3.  Unicode Casemap Collation Registration
+
+   <?xml version='1.0'?>
+   <!DOCTYPE collation SYSTEM 'collationreg.dtd'>
+   <collation rfc="5051" scope="global" intendedUse="common">
+   <identifier>i;unicode-casemap</identifier>
+   <title>Unicode Casemap</title>
+   <operations>equality order substring</operations>
+   <specification>RFC 5051</specification>
+   <owner>IETF</owner>
+   <submitter>mrc@cac.washington.edu</submitter>
+   </collation>
+
+4.  Security Considerations
+
+   The security considerations for [UTF-8], [STRINGPREP], and [UNICODE-
+   SECURITY] apply and are normative to this specification.
+
+   The results from this comparator will vary depending upon the
+   implementation for several reasons.  Implementations MUST consider
+   whether these possibilities are a problem for their use case:
+
+   1) New characters added in Unicode may have decomposition or
+      titlecase properties that will not be known to an implementation
+      based upon an older revision of Unicode.  This impacts step (2).
+
+   2) Step (2)(b) defines a subset of Normalization Form KD (NFKD) that
+      does not require normalization of out-of-order diacriticals.
+      However, an implementation MAY use an NFKD library routine that
+      does such normalization.  This impacts step (2)(b) and possibly
+      also step (1)(a), and is an issue only with ill-formed UTF-8
+      input.
+
+   3) The set of charsets handled in step (1)(a) is open-ended.  UTF-8
+      (and, by extension, US-ASCII) are the only mandatory-to-implement
+      charsets.  This impacts step (1)(a).
+
+      Implementations SHOULD, as far as feasible, support all the
+      charsets they are likely to encounter in the input data, in order
+      to avoid poor collation caused by the fall through to the (1)(b)
+      rule.
+
+   4) Other charsets may have revisions which add new characters that
+      are not known to an implementation based upon an older revision.
+      This impacts step (1)(a) and possibly also step (1)(b).
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 4]
+
+RFC 5051                   i;unicode-casemap                October 2007
+
+
+   An attacker may create input that is ill-formed or in an unknown
+   charset, with the intention of impacting the results of this
+   comparator or exploiting other parts of the system which process this
+   input in different ways.  Note, however, that even well-formed data
+   in a known charset can impact the result of this comparator in
+   unexpected ways.  For example, an attacker can substitute U+0041
+   (LATIN CAPITAL LETTER A) with U+0391 (GREEK CAPITAL LETTER ALPHA) or
+   U+0410 (CYRILLIC CAPITAL LETTER A) in the intention of causing a
+   non-match of strings which visually appear the same and/or causing
+   the string to appear elsewhere in a sort.
+
+5.  IANA Considerations
+
+   The i;unicode-casemap collation defined in section 2 has been added
+   to the registry of collations defined in [COMPARATOR].
+
+6.  Normative References
+
+   [COMPARATOR]          Newman, C., Duerst, M., and A. Gulbrandsen,
+                         "Internet Application Protocol Collation
+                         Registry", RFC 4790, February 2007.
+
+   [STRINGPREP]          Hoffman, P. and M. Blanchet, "Preparation of
+                         Internationalized Strings ("stringprep")", RFC
+                         3454, December 2002.
+
+   [UTF-8]               Yergeau, F., "UTF-8, a transformation format of
+                         ISO 10646", STD 63, RFC 3629, November 2003.
+
+   [UNICODE-DATA]        <http://www.unicode.org/Public/UNIDATA/
+                         UnicodeData.txt>
+
+                         Although the UnicodeData.txt file referenced
+                         here is part of the Unicode standard, it is
+                         subject to change as new characters are added
+                         to Unicode and errors are corrected in Unicode
+                         revisions.  As a result, it may be less stable
+                         than might otherwise be implied by the
+                         standards status of this specification.
+
+   [UNICODE-SECURITY]    Davis, M. and M. Suignard, "Unicode Security
+                         Considerations", February 2006,
+                         <http://www.unicode.org/reports/tr36/>.
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 5]
+
+RFC 5051                   i;unicode-casemap                October 2007
+
+
+7.  Informative References
+
+   [BASIC]               Newman, C., Duerst, M., and A. Gulbrandsen,
+                         "i;basic - the Unicode Collation Algorithm",
+                         Work in Progress, March 2007.
+
+   [IMAP-SORT]           Crispin, M. and K. Murchison, "Internet Message
+                         Access Protocol - SORT and THREAD Extensions",
+                         Work in Progress, September 2007.
+
+Author's Address
+
+   Mark R. Crispin
+   Networks and Distributed Computing
+   University of Washington
+   4545 15th Avenue NE
+   Seattle, WA  98105-4527
+
+   Phone: +1 (206) 543-5762
+   EMail: MRC@CAC.Washington.EDU
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 6]
+
+RFC 5051                   i;unicode-casemap                October 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   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, THE IETF TRUST 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Crispin                     Standards Track                     [Page 7]
+

dav/SabreDAV/docs/rfc5397.txt

@@ -0,0 +1,281 @@
+
+
+
+Network Working Group                                         W. Sanchez
+Request for Comments: 5397                                      C. Daboo
+Category: Standards Track                                     Apple Inc.
+                                                           December 2008
+
+
+                   WebDAV Current Principal Extension
+
+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) 2008 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.
+
+Abstract
+
+   This specification defines a new WebDAV property that allows clients
+   to quickly determine the principal corresponding to the current
+   authenticated user.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Conventions Used in This Document . . . . . . . . . . . . . . . 2
+   3.  DAV:current-user-principal  . . . . . . . . . . . . . . . . . . 3
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   5.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Normative References  . . . . . . . . . . . . . . . . . . . . . 4
+
+
+
+
+
+
+
+
+
+Sanchez & Daboo              Standards Track                    [Page 1]
+
+RFC 5397                WebDAV Current Principal           December 2008
+
+
+1.  Introduction
+
+   WebDAV [RFC4918] is an extension to HTTP [RFC2616] to support
+   improved document authoring capabilities.  The WebDAV Access Control
+   Protocol ("WebDAV ACL") [RFC3744] extension adds access control
+   capabilities to WebDAV.  It introduces the concept of a "principal"
+   resource, which is used to represent information about authenticated
+   entities on the system.
+
+   Some clients have a need to determine which [RFC3744] principal a
+   server is associating with the currently authenticated HTTP user.
+   While [RFC3744] defines a DAV:current-user-privilege-set property for
+   retrieving the privileges granted to that principal, there is no
+   recommended way to identify the principal in question, which is
+   necessary to perform other useful operations.  For example, a client
+   may wish to determine which groups the current user is a member of,
+   or modify a property of the principal resource associated with the
+   current user.
+
+   The DAV:principal-match REPORT provides some useful functionality,
+   but there are common situations where the results from that query can
+   be ambiguous.  For example, not only is an individual user principal
+   returned, but also every group principal that the user is a member
+   of, and there is no clear way to distinguish which is which.
+
+   This specification proposes an extension to WebDAV ACL that adds a
+   DAV:current-user-principal property to resources under access control
+   on the server.  This property provides a URL to a principal resource
+   corresponding to the currently authenticated user.  This allows a
+   client to "bootstrap" itself by performing additional queries on the
+   principal resource to obtain additional information from that
+   resource, which is the purpose of this extension.  Note that while it
+   is possible for multiple URLs to refer to the same principal
+   resource, or for multiple principal resources to correspond to a
+   single principal, this specification only allows for a single http(s)
+   URL in the DAV:current-user-principal property.  If a client wishes
+   to obtain alternate URLs for the principal, it can query the
+   principal resource for this information; it is not the purpose of
+   this extension to provide a complete list of such URLs, but simply to
+   provide a means to locate a resource which contains that (and other)
+   information.
+
+2.  Conventions Used in This Document
+
+   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].
+
+
+
+
+Sanchez & Daboo              Standards Track                    [Page 2]
+
+RFC 5397                WebDAV Current Principal           December 2008
+
+
+   When XML element types in the namespace "DAV:" are referenced in this
+   document outside of the context of an XML fragment, the string "DAV:"
+   will be prefixed to the element type names.
+
+   Processing of XML by clients and servers MUST follow the rules
+   defined in Section 17 of WebDAV [RFC4918].
+
+   Some of the declarations refer to XML elements defined by WebDAV
+   [RFC4918].
+
+3.  DAV:current-user-principal
+
+   Name:  current-user-principal
+
+   Namespace:  DAV:
+
+   Purpose:  Indicates a URL for the currently authenticated user's
+      principal resource on the server.
+
+   Value:  A single DAV:href or DAV:unauthenticated element.
+
+   Protected:  This property is computed on a per-request basis, and
+      therefore is protected.
+
+   Description:  The DAV:current-user-principal property contains either
+      a DAV:href or DAV:unauthenticated XML element.  The DAV:href
+      element contains a URL to a principal resource corresponding to
+      the currently authenticated user.  That URL MUST be one of the
+      URLs in the DAV:principal-URL or DAV:alternate-URI-set properties
+      defined on the principal resource and MUST be an http(s) scheme
+      URL.  When authentication has not been done or has failed, this
+      property MUST contain the DAV:unauthenticated pseudo-principal.
+
+      In some cases, there may be multiple principal resources
+      corresponding to the same authenticated principal.  In that case,
+      the server is free to choose any one of the principal resource
+      URIs for the value of the DAV:current-user-principal property.
+      However, servers SHOULD be consistent and use the same principal
+      resource URI for each authenticated principal.
+
+   COPY/MOVE behavior:  This property is computed on a per-request
+      basis, and is thus never copied or moved.
+
+   Definition:
+
+      <!ELEMENT current-user-principal (unauthenticated | href)>
+      <!-- href value: a URL to a principal resource -->
+
+
+
+
+Sanchez & Daboo              Standards Track                    [Page 3]
+
+RFC 5397                WebDAV Current Principal           December 2008
+
+
+   Example:
+
+      <D:current-user-principal xmlns:D="DAV:">
+        <D:href>/principals/users/cdaboo</D:href>
+      </D:current-user-principal>
+
+4.  Security Considerations
+
+   This specification does not introduce any additional security issues
+   beyond those defined for HTTP [RFC2616], WebDAV [RFC4918], and WebDAV
+   ACL [RFC3744].
+
+5.  Acknowledgments
+
+   This specification is based on discussions that took place within the
+   Calendaring and Scheduling Consortium's CalDAV Technical Committee.
+   The authors thank the participants of that group for their input.
+
+   The authors thank Julian Reschke for his valuable input via the
+   WebDAV working group mailing list.
+
+6.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC3744]  Clemm, G., Reschke, J., Sedlar, E., and J. Whitehead, "Web
+              Distributed Authoring and Versioning (WebDAV)
+              Access Control Protocol", RFC 3744, May 2004.
+
+   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+Authors' Addresses
+
+   Wilfredo Sanchez
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   EMail: wsanchez@wsanchez.net
+   URI:   http://www.apple.com/
+
+
+
+
+Sanchez & Daboo              Standards Track                    [Page 4]
+
+RFC 5397                WebDAV Current Principal           December 2008
+
+
+   Cyrus Daboo
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   EMail: cyrus@daboo.name
+   URI:   http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Sanchez & Daboo              Standards Track                    [Page 5]
+
+

dav/SabreDAV/docs/rfc5689.txt

@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group                                           C. Daboo
+Request for Comments: 5689                                    Apple Inc.
+Updates: 4791, 4918                                       September 2009
+Category: Standards Track
+
+
+  Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)
+
+Abstract
+
+   This specification extends the Web Distributed Authoring and
+   Versioning (WebDAV) MKCOL (Make Collection) method to allow
+   collections of arbitrary resourcetype to be created and to allow
+   properties to be set at the same time.
+
+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) 2009 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the BSD License.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+
+
+
+
+
+Daboo                       Standards Track                     [Page 1]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
+   2.  Conventions Used in This Document  . . . . . . . . . . . . . .  3
+   3.  WebDAV Extended MKCOL  . . . . . . . . . . . . . . . . . . . .  4
+     3.1.  Extended MKCOL Support . . . . . . . . . . . . . . . . . .  5
+       3.1.1.  Example: Using OPTIONS for the Discovery of
+               Support for Extended MKCOL . . . . . . . . . . . . . .  5
+     3.2.  Status Codes . . . . . . . . . . . . . . . . . . . . . . .  5
+     3.3.  Additional Precondition for Extended MKCOL . . . . . . . .  5
+     3.4.  Example: Successful Extended MKCOL Request . . . . . . . .  6
+     3.5.  Example: Unsuccessful Extended MKCOL Request . . . . . . .  6
+   4.  Using Extended MKCOL as an Alternative for MKxxx Methods . . .  8
+     4.1.  MKCALENDAR Alternative . . . . . . . . . . . . . . . . . .  8
+       4.1.1.  Example: Using MKCOL Instead of MKCALENDAR . . . . . .  8
+   5.  XML Element Definitions  . . . . . . . . . . . . . . . . . . . 10
+     5.1.  mkcol XML Element  . . . . . . . . . . . . . . . . . . . . 10
+     5.2.  mkcol-response XML Element . . . . . . . . . . . . . . . . 10
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
+   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 11
+   8.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                       Standards Track                     [Page 2]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+1.  Introduction
+
+   WebDAV [RFC4918] defines the HTTP [RFC2616] method MKCOL.  This
+   method is used to create WebDAV collections on the server.  However,
+   several WebDAV-based specifications (e.g., CalDAV [RFC4791]) define
+   "special" collections -- ones that are identified by additional
+   values in the DAV:resourcetype property assigned to the collection
+   resource or by other means.  These "special" collections are created
+   by new methods (e.g., MKCALENDAR).  The addition of a new MKxxx
+   method for each new "special" collection adds to server complexity
+   and is detrimental to overall reliability due to the need to make
+   sure intermediaries are aware of these methods.
+
+   This specification defines an extension to the WebDAV MKCOL method
+   that adds a request body allowing a client to specify WebDAV
+   properties to be set on the newly created collection or resource.  In
+   particular, the DAV:resourcetype property can be used to create a
+   "special" collection; alternatively, other properties can be used to
+   create a "special" resource.  This avoids the need to invent new
+   MKxxx methods.
+
+2.  Conventions Used in This Document
+
+   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].
+
+   This document uses XML DTD fragments (Section 3.2 of
+   [W3C.REC-xml-20081126]) as a purely notational convention.  WebDAV
+   request and response bodies cannot be validated by a DTD due to the
+   specific extensibility rules defined in Section 17 of [RFC4918] and
+   due to the fact that all XML elements defined by this specification
+   use the XML namespace name "DAV:".  In particular:
+
+   1.  Element names use the "DAV:" namespace.
+
+   2.  Element ordering is irrelevant unless explicitly stated.
+
+   3.  Extension elements (elements not already defined as valid child
+       elements) may be added anywhere, except when explicitly stated
+       otherwise.
+
+   4.  Extension attributes (attributes not already defined as valid for
+       this element) may be added anywhere, except when explicitly
+       stated otherwise.
+
+
+
+
+
+
+Daboo                       Standards Track                     [Page 3]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+   When an XML element type in the "DAV:" namespace is referenced in
+   this document outside of the context of an XML fragment, the string
+   "DAV:" will be prefixed to the element type.
+
+   This document inherits, and sometimes extends, DTD productions from
+   Section 14 of [RFC4918].
+
+3.  WebDAV Extended MKCOL
+
+   The WebDAV MKCOL request is extended to allow the inclusion of a
+   request body.  The request body is an XML document containing a
+   single DAV:mkcol XML element as the root element.  The Content-Type
+   request header MUST be set appropriately for an XML body (e.g., set
+   to "text/xml" or "application/xml").  XML-typed bodies for an MKCOL
+   request that do not have DAV:mkcol as the root element are reserved
+   for future usage.
+
+   One or more DAV:set XML elements may be included in the DAV:mkcol XML
+   element to allow setting properties on the collection as it is
+   created.  In particular, to create a collection of a particular type,
+   the DAV:resourcetype XML element MUST be included in a DAV:set XML
+   element and MUST specify the expected resource type elements for the
+   new resource, which MUST include the DAV:collection element that
+   needs to be present for any WebDAV collection.
+
+   As per the PROPPATCH method (Section 9.2 of [RFC4918]), servers MUST
+   process any DAV:set instructions in document order (an exception to
+   the normal rule that ordering is irrelevant).  If any one instruction
+   fails to execute successfully, all instructions MUST fail (i.e.,
+   either all succeed or all fail).  Thus, if any error occurs during
+   processing, all executed instructions MUST be undone and a proper
+   error result returned.  Failure to set a property value on the
+   collection MUST result in a failure of the overall MKCOL request --
+   i.e., the collection is not created.
+
+   The response to an extended MKCOL request MUST be an XML document
+   containing a single DAV:mkcol-response XML element, which MUST
+   contain DAV:propstat XML elements with the status of each property
+   when the request fails due to a failure to set one or more of the
+   properties specified in the request body.  The server MAY return a
+   response body in the case where the request is successful, indicating
+   success for setting each property specified in the request body.
+   When an empty response body is returned with a success request status
+   code, the client can assume that all properties were set.
+
+   In all other respects, the behavior of the extended MKCOL request
+   follows that of the standard MKCOL request.
+
+
+
+
+Daboo                       Standards Track                     [Page 4]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+3.1.  Extended MKCOL Support
+
+   A server supporting the features described in this document MUST
+   include "extended-mkcol" as a field in the DAV response header from
+   an OPTIONS request on any URI that supports use of the extended MKCOL
+   method.
+
+3.1.1.  Example: Using OPTIONS for the Discovery of Support for Extended
+        MKCOL
+
+   >> Request <<
+
+   OPTIONS /addressbooks/users/ HTTP/1.1
+   Host: addressbook.example.com
+
+   >> Response <<
+
+   HTTP/1.1 200 OK
+   Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
+   Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
+   DAV: 1, 2, 3, access-control, extended-mkcol
+   Date: Sat, 11 Nov 2006 09:32:12 GMT
+   Content-Length: 0
+
+3.2.  Status Codes
+
+   As per Section 9.3.1 of [RFC4918].
+
+3.3.  Additional Precondition for Extended MKCOL
+
+   WebDAV ([RFC4918], Section 16) defines preconditions and
+   postconditions for request behavior.  This specification adds the
+   following precondition for the extended MKCOL request.
+
+   Name:  valid-resourcetype
+
+   Namespace:  DAV:
+
+   Use with:  Typically 403 (Forbidden)
+
+   Purpose:  (precondition) -- The server MUST support the specified
+      resourcetype value for the specified collection.
+
+
+
+
+
+
+
+
+
+Daboo                       Standards Track                     [Page 5]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+3.4.  Example: Successful Extended MKCOL Request
+
+   This example shows how the extended MKCOL request is used to create a
+   collection of a fictitious type "special-resource".  The response
+   body is empty as the request completed successfully.
+
+   >> Request <<
+
+   MKCOL /home/special/ HTTP/1.1
+   Host: special.example.com
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:mkcol xmlns:D="DAV:"
+                 xmlns:E="http://example.com/ns/">
+     <D:set>
+       <D:prop>
+         <D:resourcetype>
+           <D:collection/>
+           <E:special-resource/>
+         </D:resourcetype>
+         <D:displayname>Special Resource</D:displayname>
+       </D:prop>
+     </D:set>
+   </D:mkcol>
+
+   >> Response <<
+
+   HTTP/1.1 201 Created
+   Cache-Control: no-cache
+   Date: Sat, 11 Nov 2006 09:32:12 GMT
+
+3.5.  Example: Unsuccessful Extended MKCOL Request
+
+   This example shows an attempt to use the extended MKCOL request to
+   create a collection of a fictitious type "special-resource", which is
+   not actually supported by the server.  The response body shows that
+   an error occurred specifically with the DAV:resourcetype property.
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                       Standards Track                     [Page 6]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+   >> Request <<
+
+   MKCOL /home/special/ HTTP/1.1
+   Host: special.example.com
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:mkcol xmlns:D="DAV:"
+                 xmlns:E="http://example.com/ns/">
+     <D:set>
+       <D:prop>
+         <D:resourcetype>
+           <D:collection/>
+           <E:special-resource/>
+         </D:resourcetype>
+         <D:displayname>Special Resource</D:displayname>
+       </D:prop>
+     </D:set>
+   </D:mkcol>
+
+   >> Response <<
+
+   HTTP/1.1 403 Forbidden
+   Cache-Control: no-cache
+   Date: Sat, 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:mkcol-response xmlns:D="DAV:">
+     <D:propstat>
+       <D:prop>
+         <D:resourcetype/>
+       </D:prop>
+       <D:status>HTTP/1.1 403 Forbidden</D:status>
+       <D:error><D:valid-resourcetype /></D:error>
+       <D:responsedescription>Resource type is not
+       supported by this server</D:responsedescription>
+     </D:propstat>
+     <D:propstat>
+       <D:prop>
+         <D:displayname/>
+       </D:prop>
+       <D:status>HTTP/1.1 424 Failed Dependency</D:status>
+     </D:propstat>
+   </D:mkcol-response>
+
+
+
+
+Daboo                       Standards Track                     [Page 7]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+4.  Using Extended MKCOL as an Alternative for MKxxx Methods
+
+   One of the goals of this extension is to eliminate the need for other
+   extensions to define their own variant of MKCOL to create the special
+   collections they need.  This extension can be used as an alternative
+   to existing MKxxx methods in other extensions as detailed below.  If
+   a server supports this extension and the other extension listed, then
+   the server MUST support use of the extended MKCOL method to achieve
+   the same result as the MKxxx method of the other extension.
+
+4.1.  MKCALENDAR Alternative
+
+   CalDAV defines the MKCALENDAR method to create a calendar collection
+   as well as to set properties during creation (Section 5.3.1 of
+   [RFC4791]).
+
+   The extended MKCOL method can be used instead by specifying both DAV:
+   collection and CALDAV:calendar-collection XML elements in the DAV:
+   resourcetype property, set during the extended MKCOL request.
+
+4.1.1.  Example: Using MKCOL Instead of MKCALENDAR
+
+   The first example below shows an MKCALENDAR request containing a
+   CALDAV:mkcalendar XML element in the request body and returning a
+   CALDAV:mkcalendar-response XML element in the response body.
+
+   >> MKCALENDAR Request <<
+
+   MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
+   Host: calendar.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>
+       </D:prop>
+     </D:set>
+   </C:mkcalendar>
+
+
+
+
+
+
+
+
+
+Daboo                       Standards Track                     [Page 8]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+   >> MKCALENDAR Response <<
+
+   HTTP/1.1 201 Created
+   Cache-Control: no-cache
+   Date: Sat, 11 Nov 2006 09:32:12 GMT
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <C:mkcalendar-response xmlns:D="DAV:"
+                 xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:propstat>
+       <D:prop>
+         <D:displayname/>
+       </D:prop>
+       <D:status>HTTP/1.1 200 OK</D:status>
+     </D:propstat>
+   </C:mkcalendar-response>
+
+   The second example shows the equivalent extended MKCOL request with
+   the same request and response XML elements.
+
+   >> MKCOL Request <<
+
+   MKCOL /home/lisa/calendars/events/ HTTP/1.1
+   Host: calendar.example.com
+   Content-Type: application/xml; charset="utf-8"
+   Content-Length: xxxx
+
+   <?xml version="1.0" encoding="utf-8" ?>
+   <D:mkcol xmlns:D="DAV:"
+                 xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:set>
+       <D:prop>
+         <D:resourcetype>
+           <D:collection/>
+           <C:calendar/>
+         </D:resourcetype>
+         <D:displayname>Lisa's Events</D:displayname>
+       </D:prop>
+     </D:set>
+   </D:mkcol>
+
+
+
+
+
+
+
+
+
+Daboo                       Standards Track                     [Page 9]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+   >> MKCOL Response <<
+
+   HTTP/1.1 201 Created
+   Cache-Control: no-cache
+   Date: Sat, 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:mkcol-response xmlns:D="DAV:"
+                 xmlns:C="urn:ietf:params:xml:ns:caldav">
+     <D:propstat>
+       <D:prop>
+         <D:resourcetype/>
+         <D:displayname/>
+       </D:prop>
+       <D:status>HTTP/1.1 200 OK</D:status>
+     </D:propstat>
+   </D:mkcol-response>
+
+5.  XML Element Definitions
+
+5.1.  mkcol XML Element
+
+   Name:  mkcol
+
+   Namespace:  DAV:
+
+   Purpose:  Used in a request to specify properties to be set in an
+      extended MKCOL request, as well as any additional information
+      needed when creating the resource.
+
+   Description:  This XML element is a container for the information
+      required to modify the properties on a collection resource as it
+      is created in an extended MKCOL request.
+
+   Definition:
+
+       <!ELEMENT mkcol (set+)>
+
+5.2.  mkcol-response XML Element
+
+   Name:  mkcol-response
+
+   Namespace:  DAV:
+
+
+
+
+
+
+Daboo                       Standards Track                    [Page 10]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+   Purpose:  Used in a response to indicate the status of properties
+      that were set or failed to be set during an extended MKCOL
+      request.
+
+   Description:  This XML element is a container for the information
+      returned about a resource that has been created in an extended
+      MKCOL request.
+
+   Definition:
+
+       <!ELEMENT mkcol-response (propstat+)>
+
+6.  Security Considerations
+
+   This extension does not introduce any new security concerns beyond
+   those already described in HTTP [RFC2616] and WebDAV [RFC4918].
+
+7.  Acknowledgments
+
+   Thanks to Bernard Desruisseaux, Mike Douglass, Alexey Melnikov,
+   Julian Reschke, and Simon Vaillancourt.
+
+
+8.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
+              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+              March 2007.
+
+   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+   [W3C.REC-xml-20081126]
+              Maler, E., Yergeau, F., Paoli, J., Bray, T., and C.
+              Sperberg-McQueen, "Extensible Markup Language (XML) 1.0
+              (Fifth Edition)", World Wide Web Consortium
+              Recommendation REC-xml-20081126, November 2008,
+              <http://www.w3.org/TR/2008/REC-xml-20081126>.
+
+
+
+
+
+
+Daboo                       Standards Track                    [Page 11]
+
+RFC 5689               Extended MKCOL for WebDAV          September 2009
+
+
+Author's Address
+
+   Cyrus Daboo
+   Apple Inc.
+   1 Infinite Loop
+   Cupertino, CA  95014
+   USA
+
+   EMail: cyrus@daboo.name
+   URI:   http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo                       Standards Track                    [Page 12]
+

dav/SabreDAV/docs/rfc5789.txt

@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                      L. Dusseault
+Request for Comments: 5789                                    Linden Lab
+Category: Standards Track                                       J. Snell
+ISSN: 2070-1721                                               March 2010
+
+
+                         PATCH Method for HTTP
+
+Abstract
+
+   Several applications extending the Hypertext Transfer Protocol (HTTP)
+   require a feature to do partial resource modification.  The existing
+   HTTP PUT method only allows a complete replacement of a document.
+   This proposal adds a new HTTP method, PATCH, to modify an existing
+   HTTP resource.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc5789.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 1]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. The PATCH Method ................................................2
+      2.1. A Simple PATCH Example .....................................4
+      2.2. Error Handling .............................................5
+   3. Advertising Support in OPTIONS ..................................7
+      3.1. The Accept-Patch Header ....................................7
+      3.2. Example OPTIONS Request and Response .......................7
+   4. IANA Considerations .............................................8
+      4.1. The Accept-Patch Response Header ...........................8
+   5. Security Considerations .........................................8
+   6. References ......................................................9
+      6.1. Normative References .......................................9
+      6.2. Informative References .....................................9
+   Appendix A.  Acknowledgements .....................................10
+
+1.  Introduction
+
+   This specification defines the new HTTP/1.1 [RFC2616] method, PATCH,
+   which is used to apply partial modifications to a resource.
+
+   A new method is necessary to improve interoperability and prevent
+   errors.  The PUT method is already defined to overwrite a resource
+   with a complete new body, and cannot be reused to do partial changes.
+   Otherwise, proxies and caches, and even clients and servers, may get
+   confused as to the result of the operation.  POST is already used but
+   without broad interoperability (for one, there is no standard way to
+   discover patch format support).  PATCH was mentioned in earlier HTTP
+   specifications, but not completely defined.
+
+   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
+   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
+   and "OPTIONAL" are to be interpreted as described in [RFC2119].
+
+   Furthermore, this document uses the ABNF syntax defined in Section
+   2.1 of [RFC2616].
+
+2.  The PATCH Method
+
+   The PATCH method requests that a set of changes described in the
+   request entity be applied to the resource identified by the Request-
+   URI.  The set of changes is represented in a format called a "patch
+   document" identified by a media type.  If the Request-URI does not
+   point to an existing resource, the server MAY create a new resource,
+   depending on the patch document type (whether it can logically modify
+   a null resource) and permissions, etc.
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 2]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+   The difference between the PUT and PATCH requests is reflected in the
+   way the server processes the enclosed entity to modify the resource
+   identified by the Request-URI.  In a PUT request, the enclosed entity
+   is considered to be a modified version of the resource stored on the
+   origin server, and the client is requesting that the stored version
+   be replaced.  With PATCH, however, the enclosed entity contains a set
+   of instructions describing how a resource currently residing on the
+   origin server should be modified to produce a new version.  The PATCH
+   method affects the resource identified by the Request-URI, and it
+   also MAY have side effects on other resources; i.e., new resources
+   may be created, or existing ones modified, by the application of a
+   PATCH.
+
+   PATCH is neither safe nor idempotent as defined by [RFC2616], Section
+   9.1.
+
+   A PATCH request can be issued in such a way as to be idempotent,
+   which also helps prevent bad outcomes from collisions between two
+   PATCH requests on the same resource in a similar time frame.
+   Collisions from multiple PATCH requests may be more dangerous than
+   PUT collisions because some patch formats need to operate from a
+   known base-point or else they will corrupt the resource.  Clients
+   using this kind of patch application SHOULD use a conditional request
+   such that the request will fail if the resource has been updated
+   since the client last accessed the resource.  For example, the client
+   can use a strong ETag [RFC2616] in an If-Match header on the PATCH
+   request.
+
+   There are also cases where patch formats do not need to operate from
+   a known base-point (e.g., appending text lines to log files, or non-
+   colliding rows to database tables), in which case the same care in
+   client requests is not needed.
+
+   The server MUST apply the entire set of changes atomically and never
+   provide (e.g., in response to a GET during this operation) a
+   partially modified representation.  If the entire patch document
+   cannot be successfully applied, then the server MUST NOT apply any of
+   the changes.  The determination of what constitutes a successful
+   PATCH can vary depending on the patch document and the type of
+   resource(s) being modified.  For example, the common 'diff' utility
+   can generate a patch document that applies to multiple files in a
+   directory hierarchy.  The atomicity requirement holds for all
+   directly affected files.  See "Error Handling", Section 2.2, for
+   details on status codes and possible error conditions.
+
+   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.  A response to this method is only cacheable if it
+
+
+
+Dusseault & Snell            Standards Track                    [Page 3]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+   contains explicit freshness information (such as an Expires header or
+   "Cache-Control: max-age" directive) as well as the Content-Location
+   header matching the Request-URI, indicating that the PATCH response
+   body is a resource representation.  A cached PATCH response can only
+   be used to respond to subsequent GET and HEAD requests; it MUST NOT
+   be used to respond to other methods (in particular, PATCH).
+
+   Note that entity-headers contained in the request apply only to the
+   contained patch document and MUST NOT be applied to the resource
+   being modified.  Thus, a Content-Language header could be present on
+   the request, but it would only mean (for whatever that's worth) that
+   the patch document had a language.  Servers SHOULD NOT store such
+   headers except as trace information, and SHOULD NOT use such header
+   values the same way they might be used on PUT requests.  Therefore,
+   this document does not specify a way to modify a document's Content-
+   Type or Content-Language value through headers, though a mechanism
+   could well be designed to achieve this goal through a patch document.
+
+   There is no guarantee that a resource can be modified with PATCH.
+   Further, it is expected that different patch document formats will be
+   appropriate for different types of resources and that no single
+   format will be appropriate for all types of resources.  Therefore,
+   there is no single default patch document format that implementations
+   are required to support.  Servers MUST ensure that a received patch
+   document is appropriate for the type of resource identified by the
+   Request-URI.
+
+   Clients need to choose when to use PATCH rather than PUT.  For
+   example, if the patch document size is larger than the size of the
+   new resource data that would be used in a PUT, then it might make
+   sense to use PUT instead of PATCH.  A comparison to POST is even more
+   difficult, because POST is used in widely varying ways and can
+   encompass PUT and PATCH-like operations if the server chooses.  If
+   the operation does not modify the resource identified by the Request-
+   URI in a predictable way, POST should be considered instead of PATCH
+   or PUT.
+
+2.1.  A Simple PATCH Example
+
+   PATCH /file.txt HTTP/1.1
+   Host: www.example.com
+   Content-Type: application/example
+   If-Match: "e0023aa4e"
+   Content-Length: 100
+
+   [description of changes]
+
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 4]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+   This example illustrates use of a hypothetical patch document on an
+   existing resource.
+
+   Successful PATCH response to existing text file:
+
+   HTTP/1.1 204 No Content
+   Content-Location: /file.txt
+   ETag: "e0023aa4f"
+
+   The 204 response code is used because the response does not carry a
+   message body (which a response with the 200 code would have).  Note
+   that other success codes could be used as well.
+
+   Furthermore, the ETag response header field contains the ETag for the
+   entity created by applying the PATCH, available at
+   http://www.example.com/file.txt, as indicated by the Content-Location
+   response header field.
+
+2.2.  Error Handling
+
+   There are several known conditions under which a PATCH request can
+   fail.
+
+   Malformed patch document:  When the server determines that the patch
+      document provided by the client is not properly formatted, it
+      SHOULD return a 400 (Bad Request) response.  The definition of
+      badly formatted depends on the patch document chosen.
+
+   Unsupported patch document:  Can be specified using a 415
+      (Unsupported Media Type) response when the client sends a patch
+      document format that the server does not support for the resource
+      identified by the Request-URI.  Such a response SHOULD include an
+      Accept-Patch response header as described in Section 3.1 to notify
+      the client what patch document media types are supported.
+
+   Unprocessable request:  Can be specified with a 422 (Unprocessable
+      Entity) response ([RFC4918], Section 11.2) when the server
+      understands the patch document and the syntax of the patch
+      document appears to be valid, but the server is incapable of
+      processing the request.  This might include attempts to modify a
+      resource in a way that would cause the resource to become invalid;
+      for instance, a modification to a well-formed XML document that
+      would cause it to no longer be well-formed.  There may also be
+      more specific errors like "Conflicting State" that could be
+      signaled with this status code, but the more specific error would
+      generally be more helpful.
+
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 5]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+   Resource not found:  Can be specified with a 404 (Not Found) status
+      code when the client attempted to apply a patch document to a non-
+      existent resource, but the patch document chosen cannot be applied
+      to a non-existent resource.
+
+   Conflicting state:  Can be specified with a 409 (Conflict) status
+      code when the request cannot be applied given the state of the
+      resource.  For example, if the client attempted to apply a
+      structural modification and the structures assumed to exist did
+      not exist (with XML, a patch might specify changing element 'foo'
+      to element 'bar' but element 'foo' might not exist).
+
+   Conflicting modification:  When a client uses either the If-Match or
+      If-Unmodified-Since header to define a precondition, and that
+      precondition failed, then the 412 (Precondition Failed) error is
+      most helpful to the client.  However, that response makes no sense
+      if there was no precondition on the request.  In cases when the
+      server detects a possible conflicting modification and no
+      precondition was defined in the request, the server can return a
+      409 (Conflict) response.
+
+   Concurrent modification:  Some applications of PATCH might require
+      the server to process requests in the order in which they are
+      received.  If a server is operating under those restrictions, and
+      it receives concurrent requests to modify the same resource, but
+      is unable to queue those requests, the server can usefully
+      indicate this error by using a 409 (Conflict) response.
+
+   Note that the 409 Conflict response gives reasonably consistent
+   information to clients.  Depending on the application and the nature
+   of the patch format, the client might be able to reissue the request
+   as is (e.g., an instruction to append a line to a log file), have to
+   retrieve the resource content to recalculate a patch, or have to fail
+   the operation.
+
+   Other HTTP status codes can also be used under the appropriate
+   circumstances.
+
+   The entity body of error responses SHOULD contain enough information
+   to communicate the nature of the error to the client.  The content-
+   type of the response entity can vary across implementations.
+
+
+
+
+
+
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 6]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+3.  Advertising Support in OPTIONS
+
+   A server can advertise its support for the PATCH method by adding it
+   to the listing of allowed methods in the "Allow" OPTIONS response
+   header defined in HTTP/1.1.  The PATCH method MAY appear in the
+   "Allow" header even if the Accept-Patch header is absent, in which
+   case the list of allowed patch documents is not advertised.
+
+3.1.  The Accept-Patch Header
+
+   This specification introduces a new response header Accept-Patch used
+   to specify the patch document formats accepted by the server.
+   Accept-Patch SHOULD appear in the OPTIONS response for any resource
+   that supports the use of the PATCH method.  The presence of the
+   Accept-Patch header in response to any method is an implicit
+   indication that PATCH is allowed on the resource identified by the
+   Request-URI.  The presence of a specific patch document format in
+   this header indicates that that specific format is allowed on the
+   resource identified by the Request-URI.
+
+   Accept-Patch = "Accept-Patch" ":" 1#media-type
+
+   The Accept-Patch header specifies a comma-separated listing of media-
+   types (with optional parameters) as defined by [RFC2616], Section
+   3.7.
+
+   Example:
+
+   Accept-Patch: text/example;charset=utf-8
+
+3.2.  Example OPTIONS Request and Response
+
+   [request]
+
+   OPTIONS /example/buddies.xml HTTP/1.1
+   Host: www.example.com
+
+   [response]
+
+   HTTP/1.1 200 OK
+   Allow: GET, PUT, POST, OPTIONS, HEAD, DELETE, PATCH
+   Accept-Patch: application/example, text/example
+
+   The examples show a server that supports PATCH generally using two
+   hypothetical patch document formats.
+
+
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 7]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+4.  IANA Considerations
+
+4.1.  The Accept-Patch Response Header
+
+   The Accept-Patch response header has been added to the permanent
+   registry (see [RFC3864]).
+
+   Header field name:  Accept-Patch
+
+   Applicable Protocol:  HTTP
+
+   Author/Change controller:  IETF
+
+   Specification document:  this specification
+
+5.  Security Considerations
+
+   The security considerations for PATCH are nearly identical to the
+   security considerations for PUT ([RFC2616], Section 9.6).  These
+   include authorizing requests (possibly through access control and/or
+   authentication) and ensuring that data is not corrupted through
+   transport errors or through accidental overwrites.  Whatever
+   mechanisms are used for PUT can be used for PATCH as well.  The
+   following considerations apply especially to PATCH.
+
+   A document that is patched might be more likely to be corrupted than
+   a document that is overridden in entirety, but that concern can be
+   addressed through the use of mechanisms such as conditional requests
+   using ETags and the If-Match request header as described in
+   Section 2.  If a PATCH request fails, the client can issue a GET
+   request to the resource to see what state it is in.  In some cases,
+   the client might be able to check the contents of the resource to see
+   if the PATCH request can be resent, but in other cases, the attempt
+   will just fail and/or a user will have to verify intent.  In the case
+   of a failure of the underlying transport channel, where a PATCH
+   response is not received before the channel fails or some other
+   timeout happens, the client might have to issue a GET request to see
+   whether the request was applied.  The client might want to ensure
+   that the GET request bypasses caches using mechanisms described in
+   HTTP specifications (see, for example, Section 13.1.6 of [RFC2616]).
+
+   Sometimes an HTTP intermediary might try to detect viruses being sent
+   via HTTP by checking the body of the PUT/POST request or GET
+   response.  The PATCH method complicates such watch-keeping because
+   neither the source document nor the patch document might be a virus,
+   yet the result could be.  This security consideration is not
+
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 8]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+   materially different from those already introduced by byte-range
+   downloads, downloading patch documents, uploading zipped (compressed)
+   files, and so on.
+
+   Individual patch documents will have their own specific security
+   considerations that will likely vary depending on the types of
+   resources being patched.  The considerations for patched binary
+   resources, for instance, will be different than those for patched XML
+   documents.  Servers MUST take adequate precautions to ensure that
+   malicious clients cannot consume excessive server resources (e.g.,
+   CPU, disk I/O) through the client's use of PATCH.
+
+6.  References
+
+6.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [RFC3864]  Klyne, G., Nottingham, M., and J. Mogul, "Registration
+              Procedures for Message Header Fields", BCP 90, RFC 3864,
+              September 2004.
+
+6.2.  Informative References
+
+   [RFC4918]  Dusseault, L., "HTTP Extensions for Web Distributed
+              Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusseault & Snell            Standards Track                    [Page 9]
+
+RFC 5789                       HTTP PATCH                     March 2010
+
+
+Appendix A.  Acknowledgements
+
+   PATCH is not a new concept, it first appeared in HTTP in drafts of
+   version 1.1 written by Roy Fielding and Henrik Frystyk and also
+   appears in Section 19.6.1.1 of RFC 2068.
+
+   Thanks to Adam Roach, Chris Sharp, Julian Reschke, Geoff Clemm, Scott
+   Lawrence, Jeffrey Mogul, Roy Fielding, Greg Stein, Jim Luther, Alex
+   Rousskov, Jamie Lokier, Joe Hildebrand, Mark Nottingham, Michael
+   Balloni, Cyrus Daboo, Brian Carpenter, John Klensin, Eliot Lear, SM,
+   and Bernie Hoeneisen for review and advice on this document.  In
+   particular, Julian Reschke did repeated reviews, made many useful
+   suggestions, and was critical to the publication of this document.
+
+Authors' Addresses
+
+   Lisa Dusseault
+   Linden Lab
+   945 Battery Street
+   San Francisco, CA  94111
+   USA
+
+   EMail: lisa.dusseault@gmail.com
+
+
+   James M. Snell
+
+   EMail: jasnell@gmail.com
+   URI:   http://www.snellspace.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusseault & Snell            Standards Track                   [Page 10]
+