[CalendarServer-changes] [4899] CalendarServer/trunk/doc/RFC
source_changes at macosforge.org
source_changes at macosforge.org
Wed Jan 6 07:01:27 PST 2010
Revision: 4899
http://trac.macosforge.org/projects/calendarserver/changeset/4899
Author: cdaboo at apple.com
Date: 2010-01-06 07:01:26 -0800 (Wed, 06 Jan 2010)
Log Message:
-----------
New drafts for features we may want to support.
Added Paths:
-----------
CalendarServer/trunk/doc/RFC/draft-daboo-srv-caldav.txt
CalendarServer/trunk/doc/RFC/draft-daboo-webdav-sync.txt
CalendarServer/trunk/doc/RFC/draft-desruisseaux-ischedule.txt
CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt
CalendarServer/trunk/doc/RFC/draft-reschke-webdav-post.txt
Copied: CalendarServer/trunk/doc/RFC/draft-daboo-srv-caldav.txt (from rev 4897, CalendarServer/branches/users/cdaboo/webdav-extensions-4888/doc/RFC/draft-daboo-srv-caldav.txt)
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-daboo-srv-caldav.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/draft-daboo-srv-caldav.txt 2010-01-06 15:01:26 UTC (rev 4899)
@@ -0,0 +1,504 @@
+
+
+
+Network Working Group C. Daboo
+Internet-Draft Apple Inc.
+Intended status: Standards Track October 4, 2009
+Expires: April 7, 2010
+
+
+ Use of SRV records for locating CalDAV and CardDAV services
+ draft-daboo-srv-caldav-01
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on April 7, 2010.
+
+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 in effect on the date of
+ publication of this document (http://trustee.ietf.org/license-info).
+ Please review these documents carefully, as they describe your rights
+ and restrictions with respect to this document.
+
+Abstract
+
+ This specification describes how SRV records and well-known URIs can
+ be used to locate Calendaring Extensions to WebDAV (CalDAV) or vCard
+ Extensions to WebDAV (CardDAV) services.
+
+
+
+Daboo Expires April 7, 2010 [Page 1]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . . 3
+ 3. CalDAV SRV Service Types . . . . . . . . . . . . . . . . . . . 4
+ 4. CalDAV and CardDAV Service Well-Known URI . . . . . . . . . . . 4
+ 4.1. Example: well-known URI as context path . . . . . . . . . . 4
+ 4.2. Example: well-known URI redirects to actual context
+ path . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 5. Client "Bootstrapping" Guidelines . . . . . . . . . . . . . . . 5
+ 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
+ 7.1. caldav Well-Known URI Registration . . . . . . . . . . . . 7
+ 7.2. carddav Well-Known URI Registration . . . . . . . . . . . . 7
+ 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7
+ 9.2. Informative References . . . . . . . . . . . . . . . . . . 8
+ Appendix A. Change History (to be removed prior to
+ publication as an RFC) . . . . . . . . . . . . . . . . 9
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Expires April 7, 2010 [Page 2]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+1. Introduction
+
+ [RFC2782] defines a DNS-based service discovery protocol that has
+ been widely adopted as a means of locating particular services within
+ a local area network and beyond, using SRV RR records.
+
+ [RFC4791] defines the CalDAV Calendar Access protocol, based on HTTP
+ [RFC2616], for accessing calendar data stored on a server. CalDAV
+ clients need to be able to discover appropriate CalDAV servers within
+ their local area network and at other domains, e.g., to minimize the
+ need for end users to know specific details such as hostname and port
+ for their servers.
+
+ [I-D.ietf-vcarddav-carddav] defines the CardDAV vCard Access protocol
+ based on HTTP [RFC2616], for accessing contact data stored on a
+ server. As with CalDAV, clients also need to be able to discover
+ CardDAV servers.
+
+ This specification defines new SRV service types for the CalDAV
+ protocol, and gives an example of how clients can use this together
+ with other protocol features to enable simple client configuration.
+ SRV service types for CardDAV are already defined in Section 11 of
+ [I-D.ietf-vcarddav-carddav].
+
+ Another issue with CalDAV or CardDAV service discovery is that the
+ service may not be located at the "root" URI of the HTTP server
+ hosting it. For example, if CalDAV is implemented as a "servlet" in
+ a web server "container", the servlet "context path" might be
+ "/caldav/". So the URI for the CalDAV service would be, e.g.,
+ "http://caldav.example.com/caldav/" rather than
+ "http://caldav.example.com/". SRV records by themselves only provide
+ a hostname and port for the service, not a path. Since the client
+ "bootstrapping" process requires initial access to the "context path"
+ of the service, there needs to be a simple way for clients to also
+ discover what that path is.
+
+ This specification makes use of the "well known URI" feature
+ [I-D.nottingham-site-meta] of HTTP servers to provide a well known
+ URI for CalDAV or CardDAV services that clients can make use of. The
+ well known URI will point to a resource on the server that might be
+ the actual "context path" of the CalDAV or CardDAV service, or it
+ might simply be a "stub" resource that provides a redirect to the
+ actual "context path".
+
+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
+
+
+
+Daboo Expires April 7, 2010 [Page 3]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+ document are to be interpreted as described in [RFC2119].
+
+3. CalDAV SRV Service Types
+
+ This specification adds two service types for use with SRV records:
+
+ caldav: Identifies a CalDAV server that uses HTTP without transport
+ layer security ([RFC2818]).
+
+ caldavs: Identifies a CalDAV server that uses HTTP with transport
+ layer security ([RFC2818]).
+
+ Clients SHOULD honor "TTL", "Priority" and "Weight" values in the SRV
+ records, as described by [RFC2782].
+
+ Example: service record for server without transport layer security
+
+ _caldav._tcp SRV 0 1 80 calendar.example.com.
+
+ Example: service record for server with transport layer security
+
+ _caldavs._tcp SRV 0 1 443 calendar.example.com.
+
+4. CalDAV and CardDAV Service Well-Known URI
+
+ Two "well-known" URIs are registered by this specification for CalDAV
+ and CardDAV services, "caldav" and "carddav" respectively (see
+ Section 7). These URIs point to a resource that the client can use
+ as the "context path" for the service they are trying to use. The
+ actual service could be located at that specific path. Alternatively
+ the server MAY redirect HTTP requests for that resource (using the
+ "301 Moved Permanently" status response) to the actual "context
+ path". Clients MUST handle HTTP redirects on the well-known URI.
+
+4.1. Example: well-known URI as context path
+
+ A CalDAV server has a "context path" that is the same as the well-
+ known URI, so the client will use "/.well-known/caldav" as the path
+ for its "bootstrapping" process after it has first found the hostname
+ and port via an SRV lookup.
+
+4.2. Example: well-known URI redirects to actual context path
+
+ A CalDAV server has a "context path" that is "/servlet/caldav". The
+ client will use "/.well-known/caldav" as the path for its
+ "bootstrapping" process after it has first found the hostname and
+ port via an SRV lookup. When the client makes its initial HTTP
+ request against "/.well-known/caldav", the server would issue an HTTP
+
+
+
+Daboo Expires April 7, 2010 [Page 4]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+ 301 redirect response with a Location response header using the path
+ "/servlet/caldav". The client would then "follow" this redirect to
+ the new resource and continue making HTTP requests there to complete
+ its "bootstrapping" process.
+
+5. Client "Bootstrapping" Guidelines
+
+ This section describes a procedure that CalDAV or CardDAV clients MAY
+ use to do their initial configuration based on minimal user input.
+
+ For a CalDAV server, minimal input from a user would consist of a
+ calendar user address. A calendar user address is defined by
+ iCalendar [RFC5545] to be a URI [RFC3986]. Provided a user
+ identifier and a domain name can be extracted from the URI, this
+ simple "bootstrap" configuration can be done.
+
+ If the calendar user address is a "mailto:" [RFC2368] URI, the
+ "mailbox" portion of the URI is examined and the "local-part" and
+ "domain" portions extracted. The "local-part" is used for the user
+ identifier and the "domain" is used as the service domain.
+
+ If the calendar user address is an "http:" [RFC2616] or "https:"
+ [RFC2818] URI, the "userinfo" and "host" portion of the URI is
+ extracted. The "userinfo" is used for the user identifier and the
+ "host" is used as the service domain.
+
+ For a CardDAV server, minimal input from a user would consist of
+ their email address [RFC5322] for the domain where the CardDAV
+ service is hosted. The "mailbox" portion of the email address is
+ examined and the "local-part" and "domain" portions extracted. The
+ "local-part" is used for the user identifier and the "domain" is used
+ as the service domain.
+
+ Once the user identifier and service domain have been extracted, the
+ following is done:
+
+ 1. An SRV lookup for _caldavs._tcp (for CalDAV) or _carddavs._tcp
+ (for CardDAV) is done against the extracted service domain.
+
+ 2. If no result is found for that, the client can try _caldav._tcp
+ (for CalDAV) or _carddav._tcp (for CardDAV) provided non-SSL
+ connections are appropriate.
+
+ 3. If an SRV record is returned the client extracts the server host
+ name and port number.
+
+ 4. The client does an authenticated "PROPFIND" [RFC4791] request
+ using the user identifier, host name and port number and a
+
+
+
+Daboo Expires April 7, 2010 [Page 5]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+ request URI of "/.well-known/caldav" (for CalDAV) or "/.well-
+ known/carddav" (for CardDAV). The body of the request should
+ include the DAV:current-user-principal [RFC5397] property as one
+ of the properties to return. Note that clients MUST properly
+ handle HTTP redirect responses for the request.
+
+ 5. If the server returns a 404 Not Found HTTP status response to the
+ request on the well-known URI, clients MAY try repeating the
+ request on the "root" URI "/".
+
+ 6. If the DAV:current-user-principal property is returned on the
+ initial request, the client uses that value for the principal-URI
+ of the authenticated user. With that, it can do a "PROPFIND" on
+ the principal-URI and discover additional properties for
+ configuration.
+
+ 7. If the DAV:current-user-principal property is not returned, then
+ the client will need to request the principal-URI path from the
+ user in order to continue with configuration.
+
+6. Security Considerations
+
+ Clients that support transport layer security as defined by [RFC2818]
+ SHOULD try the "caldavs" or "carddavs" services first before trying
+ the "caldav" or "carddav" services respectively. If a user has
+ explicitly requested a connection with transport layer security, the
+ client MUST NOT use any service information returned for the "caldav"
+ or "carddav" services. Clients MUST follow the certificate
+ verification process specified in
+ [I-D.saintandre-tls-server-id-check].
+
+ A malicious attacker with access to the DNS server data can
+ potentially cause clients to connect to any server chosen by the
+ attacker. In the absence of a secure DNS option, clients SHOULD
+ check that the host name returned in the SRV record matches the
+ original service domain that was queried. If the host is not in the
+ queried domain, clients SHOULD verify with the user that the SRV host
+ name is suitable for use before executing any CalDAV or CardDAV
+ requests against the host.
+
+7. IANA Considerations
+
+ This document defines two "well-known" URIs using the registration
+ procedure and template from Section 5.1 of
+ [I-D.nottingham-site-meta].
+
+
+
+
+
+
+Daboo Expires April 7, 2010 [Page 6]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+7.1. caldav Well-Known URI Registration
+
+ URI suffix: caldav
+
+ Change controller: IETF.
+
+ Specification document(s): This RFC.
+
+ Related information: See also [RFC4791].
+
+7.2. carddav Well-Known URI Registration
+
+ URI suffix: carddav
+
+ Change controller: IETF.
+
+ Specification document(s): This RFC.
+
+ Related information: See also [I-D.ietf-vcarddav-carddav].
+
+8. Acknowledgments
+
+ This specification was suggested by discussion 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 "bootstrapping" process is based on diagrams
+ developed by Wilfredo Sanchez.
+
+9. References
+
+9.1. Normative References
+
+ [I-D.ietf-vcarddav-carddav] Daboo, C., "vCard Extensions to
+ WebDAV (CardDAV)",
+ draft-ietf-vcarddav-carddav-09
+ (work in progress),
+ September 2009.
+
+ [I-D.nottingham-site-meta] Nottingham, M. and E. Hammer-
+ Lahav, "Defining Well-Known
+ URIs",
+ draft-nottingham-site-meta-03
+ (work in progress),
+ September 2009.
+
+ [I-D.saintandre-tls-server-id-check] Saint-Andre, P., Zeilenga, K.,
+ and J. Hodges, "Server Identity
+ Verification in Application
+
+
+
+Daboo Expires April 7, 2010 [Page 7]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+ Protocols", draft-saintandre-
+ tls-server-id-check-02 (work in
+ progress), October 2009.
+
+ [RFC2119] Bradner, S., "Key words for use
+ in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119,
+ March 1997.
+
+ [RFC2368] Hoffman, P., Masinter, L., and
+ J. Zawinski, "The mailto URL
+ scheme", RFC 2368, July 1998.
+
+ [RFC2616] Fielding, R., Gettys, J.,
+ Mogul, J., Frystyk, H.,
+ Masinter, L., Leach, P., and T.
+ Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and
+ L. Esibov, "A DNS RR for
+ specifying the location of
+ services (DNS SRV)", RFC 2782,
+ February 2000.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS",
+ RFC 2818, May 2000.
+
+ [RFC3986] Berners-Lee, T., Fielding, R.,
+ and L. Masinter, "Uniform
+ Resource Identifier (URI):
+ Generic Syntax", STD 66,
+ RFC 3986, January 2005.
+
+ [RFC4791] Daboo, C., Desruisseaux, B.,
+ and L. Dusseault, "Calendaring
+ Extensions to WebDAV (CalDAV)",
+ RFC 4791, March 2007.
+
+9.2. Informative References
+
+ [RFC5322] Resnick, P., Ed., "Internet
+ Message Format", RFC 5322,
+ October 2008.
+
+ [RFC5397] Sanchez, W. and C. Daboo,
+ "WebDAV Current Principal
+
+
+
+Daboo Expires April 7, 2010 [Page 8]
+
+Internet-Draft SRV for CalDAV October 2009
+
+
+ Extension", RFC 5397,
+ December 2008.
+
+ [RFC5545] Desruisseaux, B., "Internet
+ Calendaring and Scheduling Core
+ Object Specification
+ (iCalendar)", RFC 5545,
+ September 2009.
+
+Appendix A. Change History (to be removed prior to publication as an
+ RFC)
+
+ Changes in -01:
+
+ 1. Added discovery of CardDAV service.
+
+ 2. Now makes use of well-known URIs for the service "context path".
+
+ 3. Updated to RFC 5545 reference.
+
+ 4. Added reference to certificate verification spec.
+
+Author's Address
+
+ Cyrus Daboo
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ EMail: cyrus at daboo.name
+ URI: http://www.apple.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo Expires April 7, 2010 [Page 9]
+
Copied: CalendarServer/trunk/doc/RFC/draft-daboo-webdav-sync.txt (from rev 4897, CalendarServer/branches/users/cdaboo/webdav-extensions-4888/doc/RFC/draft-daboo-webdav-sync.txt)
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-daboo-webdav-sync.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/draft-daboo-webdav-sync.txt 2010-01-06 15:01:26 UTC (rev 4899)
@@ -0,0 +1,952 @@
+
+
+
+Network Working Group C. Daboo
+Internet-Draft Apple, Inc.
+Intended status: Standards Track A. Quillaud
+Expires: May 22, 2010 Sun Microsystems
+ November 18, 2009
+
+
+ Collection Synchronization for WebDAV
+ draft-daboo-webdav-sync-02
+
+Abstract
+
+ This specification defines an extension to WebDAV that allows
+ efficient synchronization of the contents of a WebDAV collection.
+
+Editorial Note (To be removed by RFC Editor before publication)
+
+ Please send comments to the Distributed Authoring and Versioning
+ (WebDAV) working group at <mailto:w3c-dist-auth at w3.org>, which may be
+ joined by sending a message with subject "subscribe" to
+ <mailto:w3c-dist-auth-request at w3.org>. Discussions of the WEBDAV
+ working group are archived at
+ <http://lists.w3.org/Archives/Public/w3c-dist-auth/>.
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 22, 2010.
+
+Copyright Notice
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 1]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ 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
+ 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 2]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Conventions Used in This Document . . . . . . . . . . . . . . 3
+ 3. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4. WebDAV Synchronization . . . . . . . . . . . . . . . . . . . . 4
+ 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 4.2. DAV:sync-collection report . . . . . . . . . . . . . . . . 5
+ 4.3. Types of changes reported . . . . . . . . . . . . . . . . 7
+ 4.3.1. New resource . . . . . . . . . . . . . . . . . . . . . 7
+ 4.3.2. Modified resource . . . . . . . . . . . . . . . . . . 7
+ 4.3.3. Removed resource . . . . . . . . . . . . . . . . . . . 7
+ 4.4. Example: Initial DAV:sync-collection REPORT . . . . . . . 8
+ 4.5. Example: DAV:sync-collection Report with token . . . . . . 10
+ 5. DAV:sync-token Property . . . . . . . . . . . . . . . . . . . 11
+ 6. XML Element Definitions . . . . . . . . . . . . . . . . . . . 12
+ 6.1. DAV:sync-collection XML Element . . . . . . . . . . . . . 12
+ 6.2. DAV:sync-token XML Element . . . . . . . . . . . . . . . . 12
+ 6.3. DAV:multistatus XML Element . . . . . . . . . . . . . . . 13
+ 6.4. DAV:sync-response XML Element . . . . . . . . . . . . . . 13
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 14
+ Appendix A. Change History (to be removed prior to
+ publication as an RFC) . . . . . . . . . . . . . . . 15
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 3]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+1. Introduction
+
+ WebDAV [RFC4918] defines the concept of 'collections' which are
+ hierarchical groupings of WebDAV resources on an HTTP [RFC2616]
+ server. Collections can be of arbitrary size and depth (i.e.,
+ collections within collections). WebDAV clients that cache resource
+ content need a way to synchronize that data with the server (i.e.,
+ detect what has changed and update their cache). This can currently
+ be done using a WebDAV PROPFIND request on a collection to list all
+ members of a collection along with their DAV:getetag property values,
+ which allows the client to determine which resources were changed,
+ added or deleted. However, this does not scale well to large
+ collections as the XML response to the PROPFIND request will grow
+ with the collection size.
+
+ This specification defines a new WebDAV report that results in the
+ server returning to the client only information about those resources
+ which have changed, are new or were deleted since a previous
+ execution of the report on the collection.
+
+ Additionally, a new property is added to collection resources that is
+ used to convey a "synchronization token" that is guaranteed to change
+ when resources within the collection have changed.
+
+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 ([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,
+
+ 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 & Quillaud Expires May 22, 2010 [Page 4]
+
+Internet-Draft WebDAV Sync November 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. Open Issues
+
+ 1. We are extending the multistatus response element in a
+ significant way. The DAV:sync-response differs from a regular
+ DAV:response because, in the case of a created or modified
+ resource, it contains both a DAV:status (201 for created, 200 for
+ modified) and a DAV:propstat. The DAV:response on the other hand
+ contains either a DAV:status or a DAV:propstat but not both.
+ Shall we define a DAV:multisyncstatus response element instead of
+ overloading DAV:multistatus ?
+
+ 2. Do clients really need to be notified that a resource was created
+ versus modified ? They should be able to figure that out by
+ looking at the state of their current cache. If this information
+ is not necessary, the response would not need to contain a DAV:
+ status along with the DAV:propstat. This would allow the use of
+ a regular multistatus (simply extended with a sync-token
+ element).
+
+4. WebDAV Synchronization
+
+4.1. Overview
+
+ One way to synchronize data between two entities is to use some form
+ of synchronization token. The token defines the state of the data
+ being synchronized at a particular point in time. It can then be
+ used to determine what has changed since one point in time and
+ another.
+
+ This specification defines a new WebDAV report that is used to enable
+ client-server collection synchronization based on such a token.
+
+ In order to synchronize the contents of a collection between a server
+ and client, the server provides the client with a synchronization
+ token each time the synchronization report is executed. That token
+ represents the state of the data being synchronized at that point in
+ time. The client can then present that same token back to the server
+ at some later time and the server will return only those items that
+ are new, have changed or were deleted since that token was generated.
+ The server also returns a new token representing the new state at the
+ time the report was run.
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 5]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ Typically the first time a client connects to the server it will need
+ to be informed of the entire state of the collection (i.e., a full
+ list of all resources that are currently contained in the
+ collection). That is done by the client sending an empty token value
+ to the server. This indicates to the server that a full listing is
+ required. As an alternative, the client may choose to do its first
+ synchronization using some other mechanism on the collection (e.g.
+ some other form of batch resource information retrieval such as
+ PROPFIND, SEARCH [RFC5323], or specialized REPORTs such as those
+ defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav])
+ and ask for the DAV:sync-token property to be returned. This
+ property (defined in Section 5) contains the same token that can be
+ used later on to issue a DAV:sync-collection report.
+
+ In some cases a server may only wish to maintain a limited amount of
+ history about changes to a collection. In that situation it will
+ return an error to the client when the client presents a token that
+ is "out of date". At that point the client has to fall back to
+ synchronizing the entire collection by re-running the report request
+ using an empty token value. ACL changes may also cause a token to
+ become invalid.
+
+4.2. DAV:sync-collection report
+
+ This specification defines the DAV:sync-collection report.
+
+ If this report is implemented by a WebDAV server, then the server
+ MUST list the report in the "DAV:supported-report-set" property on
+ any collection supporting synchronization.
+
+ To implement the behavior for this report a server needs to keep
+ track of changes to any resources in a collection. This includes
+ noting the addition of new resources, changes to existing resources
+ and removal of resources (where "removal" could be the result of a
+ DELETE or MOVE WebDAV request). Only internal members of the
+ collection (as defined in [RFC4918]) are to be considered. The
+ server will track each change and provide a synchronization "token"
+ to the client that describes the state of the server at a specific
+ point in time. This "token" is returned as part of the response to
+ the "sync-collection" report. Clients include the last token they
+ got from the server in the next "sync-collection" report that they
+ execute and the server provides the changes from the previous state,
+ represented by the token, to the current state, represented by the
+ new token returned.
+
+ The synchronization token itself is an "opaque" string - i.e., the
+ actual string data has no specific meaning or syntax. A simple
+ implementation of such a token would be a numeric counter that counts
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 6]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ each change as it occurs and relates that change to the specific
+ object that changed.
+
+ Marshalling:
+
+ The request URI MUST be a collection. The request body MUST be a
+ DAV:sync-collection XML element (see Section 6.1), which MUST
+ contain one DAV:sync-token XML element, and optionally a DAV:
+ propstat XML element.
+
+ The request MUST include a Depth header with a value of "1".
+
+ The response body for a successful request MUST be a DAV:
+ multistatus XML element, which MUST contain one DAV:sync-token
+ element in addition to any DAV:sync-response elements.
+
+ The response body for a successful DAV:sync-collection report
+ request MUST contain a DAV:sync-response element for each resource
+ that was created, has changed or been deleted since the last
+ synchronization operation as specified by the DAV:sync-token
+ provided in the request. A given resource MUST appear only once
+ in the response.
+
+ The DAV:status element in each DAV:sync-response element is used
+ to indicate how the resource may have changed:
+
+ A status code of '201 Created' is used to indicate resources
+ that are new.
+
+ A status code of '200 OK' is used to indicate resources that
+ have changed.
+
+ A status code of '404 Not Found' is used to indicate resources
+ that have been removed.
+
+ The conditions under which each type of change may occur is
+ further described in Section 4.3.
+
+ Preconditions:
+
+ (DAV:valid-sync-token): The DAV:sync-token element value MUST map
+ to a valid token previously returned by the server. A token may
+ become invalid as the result of being "out of date" (out of the
+ range of change history maintained by the server), or for other
+ reasons (e.g. collection deleted, then recreated, ACL changes,
+ etc...).
+
+ Postconditions:
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 7]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ None.
+
+4.3. Types of changes reported
+
+ Three types of resource state changes can be returned by the DAV:
+ sync-collection report (new, modified, removed). This section
+ further defines under which condition each of them shall be used. It
+ also clarifies the case where a resource may have undergone multiple
+ changes in between two synchronizations.
+
+4.3.1. New resource
+
+ A resource MUST be reported as new if it has been mapped directly
+ under the target collection since the request sync token was
+ generated. This includes resources that have been mapped as the
+ result of a COPY, MOVE or BIND ([I-D.ietf-webdav-bind]) operation.
+ This also includes collection resources that have been created.
+
+ In the case where a mapping between a resource and the target
+ collection was removed, then a new mapping with the same URI created,
+ the new resource MUST be reported as new, while the old resource MUST
+ NOT be reported as removed. For example, if a resource was deleted,
+ then recreated using the same URI, it should be reported as a new
+ resource only.
+
+ A resource MAY be reported as new if the user issuing the request was
+ granted access to this resource, due to access control changes.
+
+4.3.2. Modified resource
+
+ A resource MUST be reported as modified if it is not reported as new
+ and if its entity tag value (defined in [RFC2616]) has changed since
+ the request sync token was generated. In other words, the new
+ resource change indicator takes precedence over the modified resource
+ change indicator.
+
+ Collection resources MUST NOT be returned as modified. Instead
+ clients are expected to synchronize changes in child collection
+ resources on an individual basis.
+
+4.3.3. Removed resource
+
+ A resource MUST be reported as removed if its mapping under the
+ target collection has been removed since the request sync token was
+ generated, and it has not been re-mapped since it was removed. This
+ includes resources that have been unmapped as the result of a MOVE or
+ UNBIND ([I-D.ietf-webdav-bind]) operation. This also includes
+ collection resources that have been removed.
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 8]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ If a resource was created (and possibly modified), then removed in
+ between two synchronizations, it MUST NOT be reported as new,
+ modified or removed.
+
+ A resource MAY be reported as removed if the user issuing the request
+ has no longer access to this resource, due to access control changes.
+
+4.4. Example: Initial DAV:sync-collection REPORT
+
+ In this example, the client is making its first synchronization
+ request to the server, so the DAV:sync-token element in the request
+ is empty. It also asks for the DAV:getetag property. The server
+ responds with the items currently in the targeted collection
+ (indicating that they are 'new' via the '201 Created' status code).
+ The current synchronization token is also returned.
+
+ >> Request <<
+
+
+ REPORT /home/cyrusdaboo/ HTTP/1.1
+ Host: webdav.example.com
+ Depth: 1
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:sync-collection xmlns:D="DAV:">
+ <D:sync-token/>
+ <D:prop>
+ <D:getetag/>
+ </D:prop>
+ </D:sync-collection>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 9]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ >> Response <<
+
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:sync-response>
+ <D:href
+ >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href>
+ <D:status>HTTP/1.1 201 Created</D:status>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"00001-abcd1"</D:getetag>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:sync-response>
+ <D:sync-response>
+ <D:href
+ >http://webdav.example.com/home/cyrusdaboo/vcard.vcf</D:href>
+ <D:status>HTTP/1.1 201 Created</D:status>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"00002-abcd1"</D:getetag>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:sync-response>
+ <D:sync-response>
+ <D:href
+ >http://webdav.example.com/home/cyrusdaboo/calendar.ics</D:href>
+ <D:status>HTTP/1.1 201 Created</D:status>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"00003-abcd1"</D:getetag>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:sync-response>
+ <D:sync-token>1234</D:sync-token>
+ </D:multistatus>
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 10]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+4.5. Example: DAV:sync-collection Report with token
+
+ In this example, the client is making a synchronization request to
+ the server and is using the DAV:sync-token element returned from the
+ last report it ran on this collection. The server responds listing
+ the items that have been added, changed or removed. The (new)
+ current synchronization token is also returned.
+
+ >> Request <<
+
+
+ REPORT /home/cyrusdaboo/ HTTP/1.1
+ Host: webdav.example.com
+ Depth: 1
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:sync-collection xmlns:D="DAV:">
+ <D:sync-token>1234</D:sync-token>
+ <D:prop>
+ <D:getetag/>
+ </D:prop>
+ </D:sync-collection>
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 11]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ >> Response <<
+
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: text/xml; charset="utf-8"
+ Content-Length: xxxx
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <D:multistatus xmlns:D="DAV:">
+ <D:sync-response>
+ <D:href
+ >http://webdav.example.com/home/cyrusdaboo/file.xml</D:href>
+ <D:status>HTTP/1.1 201 Created</D:status>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"00004-abcd1"</D:getetag>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:sync-response>
+ <D:sync-response>
+ <D:href
+ >http://webdav.example.com/home/cyrusdaboo/vcard.vcf</D:href>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ <D:propstat>
+ <D:prop>
+ <D:getetag>"00002-abcd2"</D:getetag>
+ </D:prop>
+ <D:status>HTTP/1.1 200 OK</D:status>
+ </D:propstat>
+ </D:sync-response>
+ <D:sync-response>
+ <D:href
+ >http://webdav.example.com/home/cyrusdaboo/test.doc</D:href>
+ <D:status>HTTP/1.1 404 Not Found</D:status>
+ </D:sync-response>
+ <D:sync-token>1238</D:sync-token>
+ </D:multistatus>
+
+
+5. DAV:sync-token Property
+
+ Name: sync-token
+
+ Namespace: DAV:
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 12]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ Purpose: Contains the value of the synchronization token as it would
+ be returned by a DAV:sync-collection report.
+
+ Value: Any text.
+
+ Protected: MUST be protected because this value is created and
+ controlled by the server.
+
+ COPY/MOVE behavior: This property value is dependent on the final
+ state of the destination resource, not the value of the property
+ on the source resource.
+
+ Description: The DAV:sync-token property MUST be defined on all
+ resources that support the DAV:sync-collection report. It
+ contains the value of the synchronization token as it would be
+ returned by a DAV:sync-collection report on that resource at the
+ same point in time. It SHOULD NOT be returned by a PROPFIND DAV:
+ allprop request (as defined in [RFC4918]).
+
+ Definition:
+
+
+ <!ELEMENT sync-token #PCDATA>
+
+
+6. XML Element Definitions
+
+6.1. DAV:sync-collection XML Element
+
+ Name: sync-collection
+
+ Namespace: DAV:
+
+ Purpose: WebDAV report used to synchronize data between client and
+ server.
+
+ Description: See Section 4.
+
+
+
+ <!ELEMENT sync-collection (sync-token, DAV:prop?)>
+
+
+6.2. DAV:sync-token XML Element
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 13]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ Name: sync-token
+
+ Namespace: DAV:
+
+ Purpose: The synchronization token provided by the server and
+ returned by the client.
+
+ Description: See Section 4.
+
+
+
+ <!ELEMENT sync-token CDATA>
+
+
+6.3. DAV:multistatus XML Element
+
+ Name: multistatus
+
+ Namespace: DAV:
+
+ Purpose: Extends the DAV:multistatus element to include
+ synchronization details.
+
+ Description: See Section 4.
+
+
+
+ <!ELEMENT multistatus ((DAV:response*, DAV:responsedescription?) |
+ (DAV:sync-response*, DAV:sync-token,
+ DAV:responsedescription?))>
+
+
+6.4. DAV:sync-response XML Element
+
+ Name: sync-response
+
+ Namespace: DAV:
+
+ Purpose: Contains the synchronization results returned by the
+ server.
+
+ Description: See Section 4.
+
+
+
+ <!ELEMENT sync-response (DAV:href, DAV:status, DAV:propstat?)>
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 14]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+7. Security Considerations
+
+ This extension does not introduce any new security concerns than
+ those already described in HTTP and WebDAV.
+
+8. IANA Considerations
+
+ This document does not require any actions on the part of IANA.
+
+9. Acknowledgments
+
+ The following individuals contributed their ideas and support for
+ writing this specification: Bernard Desruisseaux, Mike Douglass, Ciny
+ Joy and Julian Reschke.
+
+10. References
+
+10.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.
+
+ [RFC4918] Dusseault, L., "HTTP Extensions for Web
+ Distributed Authoring and Versioning
+ (WebDAV)", RFC 4918, June 2007.
+
+ [W3C.REC-xml-20081126] Sperberg-McQueen, C., Yergeau, F., Bray,
+ T., Paoli, J., and E. Maler, "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>.
+
+10.2. Informative References
+
+ [I-D.ietf-vcarddav-carddav] Daboo, C., "vCard Extensions to WebDAV
+ (CardDAV)",
+ draft-ietf-vcarddav-carddav-10 (work in
+ progress), November 2009.
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 15]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+ [I-D.ietf-webdav-bind] Clemm, G., Crawford, J., Reschke, J.,
+ and J. Whitehead, "Binding Extensions to
+ Web Distributed Authoring and Versioning
+ (WebDAV)", draft-ietf-webdav-bind-26
+ (work in progress), September 2009.
+
+ [RFC4791] Daboo, C., Desruisseaux, B., and L.
+ Dusseault, "Calendaring Extensions to
+ WebDAV (CalDAV)", RFC 4791, March 2007.
+
+ [RFC5323] Reschke, J., Reddy, S., Davis, J., and
+ A. Babich, "Web Distributed Authoring
+ and Versioning (WebDAV) SEARCH",
+ RFC 5323, November 2008.
+
+Appendix A. Change History (to be removed prior to publication as an
+ RFC)
+
+ Changes in -02:
+
+ 1. Added definition of sync-token WebDAV property.
+
+ 2. Added references to SEARCH, CalDAV, CardDAV as alternative ways
+ to first synchronize a collection.
+
+ 3. Added section defining under which condition each state change
+ (new, modified, removed) should be reported. Added reference to
+ BIND.
+
+ 4. Incorporated feedback from Julian Reschke and Ciny Joy.
+
+ 5. More details on the use of the DAV:valid-sync-token precondition.
+
+ Changes in -01:
+
+ 1. Updated to 4918 reference.
+
+ 2. Fixed examples to properly include DAV:status in DAV:propstat
+
+ 3. Switch to using XML conventions text from RFC5323.
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 16]
+
+Internet-Draft WebDAV Sync November 2009
+
+
+Authors' Addresses
+
+ Cyrus Daboo
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ EMail: cyrus at daboo.name
+ URI: http://www.apple.com/
+
+
+ Arnaud Quillaud
+ Sun Microsystems
+ 180, Avenue de l'Europe
+ Saint Ismier cedex, 38334
+ France
+
+ EMail: arnaud.quillaud at sun.com
+ URI: http://www.sun.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Quillaud Expires May 22, 2010 [Page 17]
+
\ No newline at end of file
Copied: CalendarServer/trunk/doc/RFC/draft-desruisseaux-ischedule.txt (from rev 4897, CalendarServer/branches/users/cdaboo/webdav-extensions-4888/doc/RFC/draft-desruisseaux-ischedule.txt)
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-desruisseaux-ischedule.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/draft-desruisseaux-ischedule.txt 2010-01-06 15:01:26 UTC (rev 4899)
@@ -0,0 +1,1904 @@
+
+
+
+Network Working Group C. Daboo
+Internet-Draft Apple
+Intended status: Standards Track B. Desruisseaux
+Expires: May 19, 2010 Oracle
+ November 15, 2009
+
+
+ Internet Calendar Scheduling Protocol (iSchedule)
+ draft-desruisseaux-ischedule-00
+
+Abstract
+
+ This document defines the Internet Calendar Scheduling Protocol
+ (iSchedule), which is a binding from the iCalendar Transport-
+ independent Interoperability Protocol (iTIP) to the Hypertext
+ Transfer Protocol (HTTP) to enable interoperability between
+ calendaring and scheduling systems over the Internet.
+
+Status of This Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 19, 2010.
+
+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
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 1]
+
+Internet-Draft iSchedule November 2009
+
+
+ (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.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.1. Motivations . . . . . . . . . . . . . . . . . . . . . . . 4
+ 1.2. Related Memos . . . . . . . . . . . . . . . . . . . . . . 5
+ 1.3. Notational Conventions . . . . . . . . . . . . . . . . . . 5
+ 2. iSchedule Model . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. iSchedule Intermediaries . . . . . . . . . . . . . . . . . . . 6
+ 4. iSchedule Receiver Discovery . . . . . . . . . . . . . . . . . 7
+ 4.1. iSchedule SRV Service Types . . . . . . . . . . . . . . . 7
+ 4.2. iSchedule Receiver Request-URI . . . . . . . . . . . . . . 8
+ 4.3. Resolving Calendar User Addresses . . . . . . . . . . . . 8
+ 4.4. Using the SRV Record Result . . . . . . . . . . . . . . . 9
+ 5. iSchedule Receiver Capabilities . . . . . . . . . . . . . . . 9
+ 5.1. Example: Querying iSchedule Receiver Capabilities . . . . 9
+ 6. Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 6.1. POST Method . . . . . . . . . . . . . . . . . . . . . . . 11
+ 6.1.1. Schedule Response . . . . . . . . . . . . . . . . . . 11
+ 6.1.2. Status Codes for use with the POST method . . . . . . 12
+ 6.1.3. Example: Simple meeting invitation . . . . . . . . . . 13
+ 6.1.4. Example: Search for Busy Time Information . . . . . . 15
+ 6.1.5. Example: Simple Task Assignment . . . . . . . . . . . 17
+ 7. HTTP Headers . . . . . . . . . . . . . . . . . . . . . . . . . 18
+ 7.1. iSchedule-Version General Header . . . . . . . . . . . . . 18
+ 7.2. iSchedule-Via General Header . . . . . . . . . . . . . . . 18
+ 7.3. Originator Request Header . . . . . . . . . . . . . . . . 19
+ 7.4. Recipient Request Header . . . . . . . . . . . . . . . . . 19
+ 8. XML Element Definitions . . . . . . . . . . . . . . . . . . . 19
+ 8.1. schedule-response XML Element . . . . . . . . . . . . . . 19
+ 8.1.1. response XML Element . . . . . . . . . . . . . . . . . 20
+ 8.1.1.1. recipient XML Element . . . . . . . . . . . . . . 20
+ 8.1.1.2. request-status XML Element . . . . . . . . . . . . 20
+ 8.1.1.3. calendar-data XML Element . . . . . . . . . . . . 21
+ 8.1.1.4. error XML Element . . . . . . . . . . . . . . . . 21
+ 8.1.1.5. responsedescription XML Element . . . . . . . . . 21
+ 8.2. query-result XML Element . . . . . . . . . . . . . . . . . 22
+ 8.2.1. capability-set XML Element . . . . . . . . . . . . . . 22
+ 8.2.1.1. supported-version-set XML Element . . . . . . . . 23
+ 8.2.1.2. supported-scheduling-message-set XML Element . . . 23
+ 8.2.1.3. supported-calendar-data XML Element . . . . . . . 24
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 2]
+
+Internet-Draft iSchedule November 2009
+
+
+ 8.2.1.4. supported-attachment-values XML Element . . . . . 25
+ 8.2.1.5. supported-recipient-uri-scheme-set XML Element . . 26
+ 8.2.1.6. max-content-length XML Element . . . . . . . . . . 27
+ 8.2.1.7. min-date-time XML Element . . . . . . . . . . . . 27
+ 8.2.1.8. max-date-time XML Element . . . . . . . . . . . . 28
+ 8.2.1.9. max-instances XML Element . . . . . . . . . . . . 28
+ 8.2.1.10. max-recipients XML Element . . . . . . . . . . . . 28
+ 8.2.1.11. administrator XML Element . . . . . . . . . . . . 29
+ 9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
+ 9.1. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 29
+ 9.2. Authentication . . . . . . . . . . . . . . . . . . . . . . 29
+ 9.3. Authorization . . . . . . . . . . . . . . . . . . . . . . 30
+ 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
+ 10.1. Namespace Registration . . . . . . . . . . . . . . . . . . 30
+ 10.1.1. iSchedule Namespace Registration . . . . . . . . . . . 30
+ 10.2. HTTP Headers Registration . . . . . . . . . . . . . . . . 30
+ 10.2.1. iSchedule-Version General Header Registration . . . . 30
+ 10.2.2. iSchedule-Via General Header Registration . . . . . . 31
+ 10.2.3. Originator Request Header Registration . . . . . . . . 31
+ 10.2.4. Recipient Request Header Registration . . . . . . . . 31
+ 10.3. Well-Known URI Registration . . . . . . . . . . . . . . . 31
+ 10.3.1. iSchedule Well-Known URI Registration . . . . . . . . 32
+ 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
+ 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+ 12.1. Normative References . . . . . . . . . . . . . . . . . . . 32
+ 12.2. Informative References . . . . . . . . . . . . . . . . . . 33
+ Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 34
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 3]
+
+Internet-Draft iSchedule November 2009
+
+
+1. Introduction
+
+ This binding document provides the transport specific information
+ necessary to convey iCalendar Transport-independent Interoperability
+ Protocol (iTIP) [I-D.ietf-calsify-2446bis] messages over the
+ Hypertext Transfer Protocol (HTTP) [RFC2616].
+
+ The Internet Calendar Scheduling Protocol (iSchedule) enables
+ interoperability between different calendaring and scheduling
+ systems. Calendaring and scheduling systems that provide support for
+ iSchedule allows their users to perform scheduling transactions such
+ as schedule, reschedule, respond to scheduling request or cancel
+ scheduled calendar components, as well as search for busy time
+ information with users of other calendaring and scheduling systems on
+ the Internet.
+
+ Discussion of this Internet-Draft is taking place on the mailing list
+ <https://www.ietf.org/mailman/listinfo/ischedule>.
+
+1.1. Motivations
+
+ The iCalendar Message-Based Interoperability Protocol (iMIP)
+ [I-D.ietf-calsify-rfc2447bis], has proven to be insufficient to allow
+ users to seamlessly perform the same scheduling operations with users
+ of other calendaring and scheduling systems on the Internet than with
+ users of their own system. This section clarifies the motivations
+ for a binding from the iCalendar Transport-independent
+ Interoperability Protocol (iTIP) [I-D.ietf-calsify-2446bis] to a
+ transport that allows synchronous end-to-end connectivity.
+
+ A binding to an email-based transport is clearly inadequate to search
+ for busy time information since users need and expect to get an
+ immediate response. As such, some calendaring and scheduling systems
+ allow users to publish their free busy information in a resource
+ accessible to others on the Internet. In the absence of a
+ standardized mechanism to locate the resource that provides the free
+ busy information of a user, one thus needs to know the location of
+ this resource in addition to the calendar user address of the users
+ one wish to schedule with.
+
+ With an email-based transport, the transparent processing of incoming
+ scheduling messages on the server is only possible when the
+ calendaring and scheduling system is integrated with the email
+ system. Commonly, the processing of incoming scheduling messages
+ occurs on the client instead and requires user intervention, which
+ yield the following consequences:
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 4]
+
+Internet-Draft iSchedule November 2009
+
+
+ 1. The processing of incoming scheduling messages and the
+ corresponding updates to the calendar only occurs when the client
+ is active. As such, free busy information may be inaccurate
+ (e.g., user still appears busy when the organizer actually
+ rescheduled or canceled the meeting).
+
+ 2. Calendaring and scheduling systems generally restrain the number
+ of updates sent to users to reduce the number of messages that
+ will clutter their email inbox. As a result, attendees rarely
+ obtain up to date participation status of other attendees.
+
+ 3. The client becomes responsible to verify the authenticity and
+ integrity of the scheduling message.
+
+1.2. Related Memos
+
+ Implementers will need to be familiar with other documents that,
+ along with this document, form a framework for Internet calendaring
+ and scheduling standards.
+
+ This document specifies a binding from iTIP to HTTP.
+
+ o iCalendar [RFC5545] specifies a core specification of objects,
+ data types, properties and property parameters;
+
+ o iTIP [I-D.ietf-calsify-2446bis] specifies an interoperability
+ protocol for scheduling between different implementations.
+
+ This document does not attempt to repeat the specification of
+ concepts or definitions from these other documents. Where possible,
+ references are made to the document that provides the specification
+ of these concepts or definitions.
+
+1.3. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+ The augmented BNF used by this document to describe protocol elements
+ is described in Section 2.1 of [RFC2616]. Because this augmented BNF
+ uses the basic production rules provided in Section 2.2 of [RFC2616],
+ those rules apply to this document as well.
+
+ Definitions of XML elements in this document use XML element type
+ declarations (as found in XML Document Type Declarations), described
+ in Section 3.2 of [W3C.REC-xml-20081126].
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 5]
+
+Internet-Draft iSchedule November 2009
+
+
+ The namespace "urn:ietf:params:xml:ns:ischedule" is reserved for the
+ XML elements defined in this specification, or in other Standards
+ Track IETF RFCs written to extend iSchedule. It MUST NOT be used for
+ proprietary extensions.
+
+ Note that the XML declarations used in this document are incomplete,
+ in that they do not include namespace information. Thus, the reader
+ MUST NOT use these declarations as the only way to validate iSchedule
+ XML element types.
+
+2. iSchedule Model
+
+ The iSchedule design can be pictured as:
+
+
+ +----------+ +----------+ +----------+ +----------+
+ | Calendar | | Calendar | iSchedule | Calendar | | Calendar |
+ | User |-->| Service |------------>| Service |-->| Store |
+ | Agent | | | | | | |
+ +----------+ +----------+ +----------+ +----------+
+ iSchedule iSchedule
+ Sender Receiver
+
+ When an iSchedule Sender has a scheduling message to transmit, it
+ determines the iSchedule Receivers to delivers the message to and
+ sends the appropriate iSchedule requests. The responsability of an
+ iSchedule Sender is to transfer scheduling messages to one or more
+ iSchedule Receivers, or report its failure to do so.
+
+ The means by which a Calendar User Agent instructs a Calendar
+ Service, acting as an iSchedule Sender, to transmit scheduling
+ messages is outside the scope of this document. A Calendar Service
+ could provide support for a standard calendar access protocol, such
+ as CalDAV [RFC4791], [I-D.desruisseaux-caldav-sched] or any other
+ protocol, to allow a Calendar User Agent to perform scheduling
+ operations with users of other Calendar Services.
+
+ Likewise, the actual processing of scheduling messages received by a
+ Calendar Service, acting as an iSchedule Receiver, is also outside
+ the scope of this document. Some Calendar Service implementations
+ may decide to process some or all received scheduling messages, while
+ other implementations may decide to leave that work to Calendar User
+ Agent implementations.
+
+3. iSchedule Intermediaries
+
+ From the end-to-end view, an iSchedule request is sent to an
+ iSchedule Receiver and a response is returned to the iSchedule
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 6]
+
+Internet-Draft iSchedule November 2009
+
+
+ Sender. In practice, this may not always be the case. An iSchedule
+ request may travel through several iSchedule intermediaries.
+
+ iSchedule intermediaries can be used for different purposes, namely:
+
+ o Dispatch iSchedule request to the appropriate iSchedule Receivers
+ for each specified Recipient; Users of the same domain could
+ actually be hosted on different iSchedule Receivers.
+
+ o Dispatch iSchedule request to the appropriate iSchedule Receivers
+ according to the calendar component type specified in the
+ requests. Different iSchedule Receivers could be responsible of
+ handling, VEVENT, VTODO, VJOURNAL and VFREEBUSY requests.
+
+ o Scan iSchedule requests, particularly attachments, for virus.
+
+ iSchedule intermediaries are REQUIRED to identify their hostname and
+ the version number of the preceding server from which the request or
+ response arrived. iSchedule intermediaries append this information to
+ the "iSchedule-Via" general header, in sequential order, as the
+ request travels between Sender and Receiver.
+
+ For example, an iSchedule request might be submitted to an iSchedule
+ Receiver with the following "iSchedule-Via" header:
+
+
+ iSchedule-Via: 1.0 ischedule.example.com:443 (VendorX/2.0),
+ 1.0 cal.internal.example.com:80 (VendorZ/4.3)
+
+4. iSchedule Receiver Discovery
+
+ This section describes how an iSchedule Sender can discover the host
+ name, the port as well as the Request-URI to use to submit a request
+ to an iSchedule Receiver.
+
+4.1. iSchedule SRV Service Types
+
+ This specification adds two service types for use with SRV records:
+
+ ischedule: Identifies an iSchedule Receiver that uses HTTP without
+ transport layer security ([RFC2818]).
+
+ ischedules: Identifies an iSchedule Receiver that uses HTTP with
+ transport layer security ([RFC2818]).
+
+ Example: service record for server without transport layer security
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 7]
+
+Internet-Draft iSchedule November 2009
+
+
+ _ischedule._tcp SRV 0 1 80 ischedule.example.com.
+
+ Example: service record for server with transport layer security
+
+
+ _ischedules._tcp SRV 0 1 443 ischedule.example.com.
+
+4.2. iSchedule Receiver Request-URI
+
+ This specification registers a well-known URI for the iSchedule
+ service, namely, "ischedule" (see Section 10.3.1). iSchedule
+ Receivers MUST support requests targeted at this well-known URI.
+ iSchedule Sender MUST handle HTTP redirects on the well-known URI.
+
+4.3. Resolving Calendar User Addresses
+
+ To deliver a scheduling message via the iSchedule protocol, an
+ iSchedule Sender needs to determine what iSchedule Receiver it needs
+ to deliver a scheduling message to for a particular Recipient. Each
+ Recipient's calendar user address is specified in the Recipient
+ request header.
+
+ A calendar user address as defined by iCalendar is simply a URI.
+ This is typically a mailto URI, but could potentially be any URI
+ type.
+
+ To map a mailto URI to an SRV record name to query, the "domain"
+ portion of the URI is extracted and appended to the service
+ identifier "_ischedule._tcp." or "_ischedules._tcp." to form the
+ record name.
+
+ Example:
+
+
+ Calendar User Address: mailto:cyrus at example.com
+
+ Query SRV Record Names: _ischedules._tcp.example.com
+ _ischedule._tcp.example.com
+
+ In cases where the "domain" portion of the mailto URI contains one or
+ more levels of sub-domain, clients MAY choose to remove successive
+ levels of "sub-domain" if queries for that sub-domain fail to return
+ any SRV records. For example, a mailto URI with the full domain
+ "host.calendar.example.com" would first trigger a querying using the
+ domain "host.calendar.example.com", then if that failed, the domain
+ "calendar.example.com" would be tried, then if that failed the domain
+ "example.com" would be tried.
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 8]
+
+Internet-Draft iSchedule November 2009
+
+
+4.4. Using the SRV Record Result
+
+ As defined in [RFC2782] the result of an SRV record lookup will be a
+ target host name and a port. An iSchedule Sender uses these to
+ contact the iSchedule Receiver. iSchedule Senders MUST honor the full
+ behavior of SRV records as defined by [RFC2782], in particular the
+ TTL, Priority and Weight options in the record, as well as handling
+ multiple records being returned.
+
+ Since an iSchedule server is an HTTP server, an iSchedule client
+ needs to supply a Request-URI in the HTTP request it makes to the
+ server, in addition to the host name and port information. When SRV
+ records are being used there is no way to specify the Request-URI in
+ the SRV record. As a result clients MUST use "/" as the Request-URI
+ for the iSchedule server identified by an SRV record.
+
+5. iSchedule Receiver Capabilities
+
+ iSchedule Receivers supporting the features described in this
+ document MUST allow iSchedule Sender to query their capabilities by
+ accepting GET requests targeted at the Request-URI "/.well-known/
+ ischedule?query=capabilities". The response body for a successful
+ GET request targeted at this URI MUST be an XML document with query-
+ result as its root element.
+
+5.1. Example: Querying iSchedule Receiver Capabilities
+
+ >> Request <<
+
+
+ GET /.well-known/ischedule?query=capabilities HTTP/1.1
+ Host: cal.example.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 9]
+
+Internet-Draft iSchedule November 2009
+
+
+ >> Response <<
+
+
+ HTTP/1.1 200 OK
+ Date: Mon, 15 Dec 2008 09:32:12 GMT
+ Content-Type: application/xml; charset=utf-8
+ Content-Length: xxxx
+ iSchedule-Version: 1.0
+ ETag: "afasdf-132afds"
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <query-result xmlns="urn:ietf:params:xml:ns:ischedule">
+ <capability-set>
+ <supported-version-set>
+ <version>1</version>
+ </supported-version-set>
+ <supported-scheduling-message-set>
+ <comp name="VEVENT">
+ <method name="REQUEST"/>
+ <method name="ADD"/>
+ <method name="REPLY"/>
+ <method name="CANCEL"/>
+ </comp>
+ <comp name="VTODO"/>
+ <comp name="VFREEBUSY"/>
+ </supported-scheduling-message-set>
+ <supported-calendar-data>
+ <calendar-data content-type="text/calendar" version="2.0"/>
+ </supported-calendar-data>
+ <supported-attachment-values>
+ <inline-attachment/>
+ <external-attachment/>
+ </supported-attachment-values>
+ <supported-recipient-uri-scheme-set>
+ <scheme>mailto</scheme>
+ </supported-recipient-uri-scheme-set>
+ <max-content-length>102400</max-content-length>
+ <min-date-time>19910101T000000Z</min-date-time>
+ <max-date-time>20381231T000000Z</max-date-time>
+ <max-instances>150</max-instances>
+ <max-recipients>250</max-recipients>
+ <administrator>mailto:ischedule-admin at example.com</administrator>
+ </capability-set>
+ </query-result>
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 10]
+
+Internet-Draft iSchedule November 2009
+
+
+6. Scheduling
+
+ This section defines how an iSchedule Sender can use the HTTP POST
+ method to submit a scheduling message to an iSchedule Receiver.
+
+6.1. POST Method
+
+ The POST method submits a scheduling message to one or more
+ recipients by targeting the request at the Request-URI of an
+ iSchedule Receiver. The request body of a POST method MUST contain a
+ scheduling message or free-busy message (e.g., an iCalendar object
+ that follows the iTIP semantic).
+
+ A submitted scheduling message will be delivered to the calendar user
+ addresses specified in the Recipient request header. A submitted
+ free-busy message will be immediately executed and a free-busy
+ response returned.
+
+ Every POST request MUST include the iSchedule-Version request header.
+
+ Every POST request MUST include a single Originator request header
+ that specifies the calendar user address of the originator of the
+ scheduling message.
+
+ Every POST request MUST include one or more Recipient request
+ headers. The value of this header is a list of one or more calendar
+ user addresses and corresponds to the set of calendar users who will
+ have the scheduling message delivered to them.
+
+6.1.1. Schedule Response
+
+ A POST request may deliver a scheduling message to one or more
+ calendar users specified in the Recipient request header. Since the
+ behavior of each recipient may vary, it is useful to get response
+ status information for each recipient in the overall POST response.
+ This specification defines a new XML response to convey multiple
+ recipient status.
+
+ A response to a POST method that indicates status for one or more
+ recipients MUST be a schedule-response XML element. This MUST
+ contain one or more response elements for each recipient, with each
+ of those containing elements that indicate which recipient they
+ correspond to, the scheduling status of the request for that
+ recipient, any error codes and an optional description.
+
+ In the case of a free-busy request, the response elements can also
+ contain calendar-data elements which contain free busy information
+ (e.g., an iCalendar VFREEBUSY component) indicating the busy state of
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 11]
+
+Internet-Draft iSchedule November 2009
+
+
+ the corresponding recipient, assuming that the free-busy request for
+ that recipient succeeded.
+
+ TODO: Define the response body for a failed request.
+
+ (supported-calendar-data): The resource submitted in the POST
+ request MUST be a supported media type (i.e. text/calendar) for
+ scheduling or free-busy messages;
+
+ (valid-calendar-data): The resource submitted in the POST request
+ MUST be valid data for the media type being specified (i.e. valid
+ iCalendar object);
+
+ (valid-scheduling-message): The resource submitted in the POST
+ request MUST obey all restrictions specified for the POST request
+ (e.g., the scheduling message follows the restrictions of iTIP);
+
+ (originator-specified): The POST request MUST include a valid
+ Originator request header specifying a single calendar user
+ address of the currently authenticated user;
+
+ (recipient-specified): The POST request MUST include one or more
+ valid Recipient request headers specifying the calendar user
+ address of users to whom the scheduling message will be delivered.
+
+ (originator-reply): The calendar user identified by the Originator
+ request header in the POST request MUST have previously received
+ the scheduling message that is being replied to when the
+ scheduling message is an incoming scheduling message;
+
+ (max-content-length): The request body submitted in the POST
+ request MUST have an octet size less than or equal to the value of
+ the max-content-length capability of the iSchedule Receiver.
+
+6.1.2. Status Codes for use with the POST method
+
+ The following are examples of response codes one would expect to be
+ used for this method. Note, however, that unless explicitly
+ prohibited any 2/3/4/5xx series response code may be used in a
+ response.
+
+ 200 (OK) - The command succeeded.
+
+ 400 (Bad Request) - The Sender has provided an invalid scheduling
+ message.
+
+ 403 (Forbidden) - The Sender cannot submit a scheduling message to
+ the specified Request-URI.
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 12]
+
+Internet-Draft iSchedule November 2009
+
+
+ 404 (Not Found) - The URL in the Request-URI was not present.
+
+ 507 (Insufficient Storage) - The server did not have sufficient
+ space to record the scheduling message.
+
+6.1.3. Example: Simple meeting invitation
+
+ >> Request <<
+
+
+ POST /.well-known/ischedule HTTP/1.1
+ Host: cal.example.org
+ iSchedule-Version: 1.0
+ Originator: mailto:bernard at example.com
+ Recipient: mailto:cyrus at example.org
+ Content-Type: text/calendar
+ Content-Length: xxxx
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//EN
+ METHOD:REQUEST
+ BEGIN:VEVENT
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:bernard at example.com
+ DTSTART:20040902T130000Z
+ DTEND:20040902T140000Z
+ SUMMARY:Design meeting
+ UID:34222-232 at example.com
+ ATTENDEE;PARTSTAT=ACCEPTED;ROLE=CHAIR;CUTYPE=IND
+ IVIDUAL;CN=Bernard Desruisseaux:mailto:bernard@
+ example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
+ Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
+ mailto:cyrus at example.org
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 13]
+
+Internet-Draft iSchedule November 2009
+
+
+ >> Response <<
+
+
+ HTTP/1.1 200 OK
+ Date: Thu, 02 Sep 2004 16:53:32 GMT
+ Content-Type: application/xml; charset=utf-8
+ Content-Length: xxxx
+ iSchedule-Version: 1.0
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <schedule-response xmlns="urn:ietf:params:xml:ns:ischedule">
+ <response>
+ <recipient>mailto:cyrus at example.org</recipient>
+ <request-status>2.0;Success</request-status>
+ <responsedescription>Delivered to recipient
+ scheduling inbox</responsedescription>
+ </response>
+ </schedule-response>
+
+
+ In this example, the iSchedule Sender requests the iSchedule Receiver
+ to deliver a meeting invitation (scheduling REQUEST) to the calendar
+ user mailto:cyrus at example.org. The response indicates that delivery
+ of the scheduling message was successful.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 14]
+
+Internet-Draft iSchedule November 2009
+
+
+6.1.4. Example: Search for Busy Time Information
+
+ >> Request <<
+
+
+ POST /.well-known/ischedule HTTP/1.1
+ Host: cal.example.org
+ iSchedule-Version: 1.0
+ Originator: mailto:bernard at example.com
+ Recipient: mailto:cyrus at example.org
+ Content-Type: text/calendar
+ Content-Length: xxxx
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//EN
+ METHOD:REQUEST
+ BEGIN:VFREEBUSY
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:bernard at example.com
+ DTSTART:20040902T000000Z
+ DTEND:20040903T000000Z
+ UID:34222-232 at example.com
+ ATTENDEE;CN=Cyrus Daboo:mailto:cyrus at example.org
+ END:VFREEBUSY
+ END:VCALENDAR
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 15]
+
+Internet-Draft iSchedule November 2009
+
+
+ >> Response <<
+
+
+ HTTP/1.1 200 OK
+ Date: Thu, 02 Sep 2004 16:53:32 GMT
+ Content-Type: application/xml; charset=utf-8
+ Content-Length: xxxx
+ iSchedule-Version: 1.0
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <schedule-response xmlns="urn:ietf:params:xml:ns:ischedule">
+ <response>
+ <recipient>mailto:cyrus at example.org</recipient>
+ <request-status>2.0;Success</request-status>
+ <calendar-data>BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//EN
+ METHOD:REPLY
+ BEGIN:VFREEBUSY
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:bernard at example.com
+ DTSTART:20040902T000000Z
+ DTEND:20040903T000000Z
+ UID:34222-232 at example.com
+ ATTENDEE;CN=Cyrus Daboo:mailto:cyrus at example.org
+ FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:20040902T000000Z/
+ 20040902T090000Z,20040902T170000Z/20040903T000000Z
+ FREEBUSY;FBTYPE=BUSY:20040902T120000Z/20040902T130000Z
+ END:VFREEBUSY
+ END:VCALENDAR
+ </calendar-data>
+ </response>
+ </schedule-response>
+
+
+ In this example, the iSchedule Sender requests the iSchedule Receiver
+ to determine the busy information of the calendar user
+ mailto:cyrus at example.org, over the time range specified by the
+ scheduling message sent in the request. The response includes
+ VFREEBUSY components with the busy time of the requested calendar
+ user.
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 16]
+
+Internet-Draft iSchedule November 2009
+
+
+6.1.5. Example: Simple Task Assignment
+
+ >> Request <<
+
+
+ POST /.well-known/ischedule HTTP/1.1
+ Host: cal.example.org
+ iSchedule-Version: 1.0
+ Originator: mailto:bernard at example.com
+ Recipient: mailto:cyrus at example.org
+ Content-Type: text/calendar
+ Content-Length: xxxx
+
+ BEGIN:VCALENDAR
+ VERSION:2.0
+ PRODID:-//Example Corp.//CalDAV Client//EN
+ METHOD:REQUEST
+ BEGIN:VTODO
+ DTSTAMP:20040901T200200Z
+ ORGANIZER:mailto:bernard at example.com
+ DUE:20070505
+ SUMMARY:Review Internet-Draft
+ UID:34222-456 at example.com
+ ATTENDEE;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;ROLE=RE
+ Q-PARTICIPANT;CUTYPE=INDIVIDUAL;CN=Cyrus Daboo:
+ mailto:cyrus at example.org
+ END:VEVENT
+ END:VCALENDAR
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 17]
+
+Internet-Draft iSchedule November 2009
+
+
+ >> Response <<
+
+
+ HTTP/1.1 200 OK
+ Date: Thu, 02 Sep 2004 16:53:32 GMT
+ Content-Type: application/xml; charset=utf-8
+ Content-Length: xxxx
+ iSchedule-Version: 1.0
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <schedule-response
+ xmlns="urn:ietf:params:xml:ns:ischedule">
+ <response>
+ <recipient>mailto:cyrus at example.org</recipient>
+ <request-status>2.0;Success</request-status>
+ <responsedescription>Delivered to recipient
+ scheduling inbox</responsedescription>
+ </response>
+ </schedule-response>
+
+
+ In this example, the iSchedule Sender requests the iSchedule Sender
+ to deliver a task assignment (scheduling REQUEST) to the calendar
+ user mailto:cyrus at example.org. The response indicates that delivery
+ of the scheduling message was successful.
+
+7. HTTP Headers
+
+7.1. iSchedule-Version General Header
+
+
+ iSchedule-Version = "iSchedule-Version" ":" 1*DIGIT "." 1*DIGIT
+
+ The iSchedule-Version general header field MUST be specified by the
+ iSchedule Sender on requests, and by the iSchedule Receiver on
+ responses.
+
+ TODO: Consider whether the iSchedule-Version should be returned on a
+ per recipient basis in the response body.
+
+7.2. iSchedule-Via General Header
+
+
+ iSchedule-Via = "iSchedule-Via" ":" 1#( received-protocol
+ received-by [ comment ] )
+ ; received-protocol as defined in [RFC2616]
+ ; received-by as defined in [RFC2616]
+ ; comment as defined in [RFC2616]
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 18]
+
+Internet-Draft iSchedule November 2009
+
+
+ The iSchedule-Via general header field MUST be used by iSchedule
+ intermediaries to indicate the intermediate protocols and recipients
+ between the iSchedule Sender and the iSchedule Receiver on requests.
+
+ TODO: Consider whether the iSchedule-Via should be returned on a per
+ recipient basis in the response body.
+
+7.3. Originator Request Header
+
+
+ Originator = "Originator" ":" absoluteURI
+
+ ; absoluteURI as defined in [RFC3986]
+
+
+ The Originator request header value is a URI which specifies the
+ calendar user address of the originator of the scheduling message.
+ Note that the absoluteURI production is defined in RFC3986 [RFC3986].
+
+7.4. Recipient Request Header
+
+
+ Recipient = "Recipient" ":" 1#absoluteURI
+
+ ; absoluteURI as defined in [RFC3986]
+
+ The Recipient request header value is a URI which specifies the
+ calendar user address of the recipients to which the POST method
+ should deliver the submitted scheduling message. Note that the
+ absoluteURI production is defined in RFC3986 [RFC3986]
+
+8. XML Element Definitions
+
+8.1. schedule-response XML Element
+
+ Name: schedule-response
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Contains the set of responses for a POST method request.
+
+ Description: See Section 6.1.1.
+
+ Definition:
+
+
+ <!ELEMENT schedule-response (response*)>
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 19]
+
+Internet-Draft iSchedule November 2009
+
+
+8.1.1. response XML Element
+
+ Name: response
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Contains a single response for a POST method request.
+
+ Description: See Section 6.1.1.
+
+ Definition:
+
+
+ <!ELEMENT response (recipient,
+ request-status,
+ calendar-data?,
+ error?,
+ responsedescription?)>
+
+8.1.1.1. recipient XML Element
+
+ Name: recipient
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: The calendar user address (recipient header value) that the
+ enclosing response for a POST method request is for.
+
+ Description: See Section 6.1.1.
+
+ Definition:
+
+
+ <!ELEMENT recipient (href)>
+
+8.1.1.2. request-status XML Element
+
+ Name: request-status
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: The iTIP REQUEST-STATUS property value for this response.
+
+ Description: See Section 6.1.1.
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 20]
+
+Internet-Draft iSchedule November 2009
+
+
+ Definition:
+
+
+ <!ELEMENT request-status (#PCDATA)>
+
+8.1.1.3. calendar-data XML Element
+
+ Name: calendar-data
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: An iCalendar object in a response to a seach for busy time
+ information.
+
+ Description: See Section 6.1.1.
+
+ Definition:
+
+
+ <!ELEMENT calendar-data (#PCDATA)>
+
+8.1.1.4. error XML Element
+
+ Name: error
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Error responses sometimes need more information to indicate
+ what went wrong.
+
+ Description: See Section 6.1.1.
+
+ Definition:
+
+
+ <!ELEMENT error ANY>
+
+8.1.1.5. responsedescription XML Element
+
+ Name: responsedescription
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Contains information about a status response
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 21]
+
+Internet-Draft iSchedule November 2009
+
+
+ Description: See Section 6.1.1.
+
+ Definition:
+
+
+ <!ELEMENT responsedescription (#PCDATA)>
+
+8.2. query-result XML Element
+
+ Name: query-result
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Contains result of a query request.
+
+ Description: A generic container for the result of a query request,
+ such as a query of the capabilities of an iSchedule Receiver.
+
+ Definition:
+
+
+ <!ELEMENT query-result (capability-set)>
+
+8.2.1. capability-set XML Element
+
+ Name: capability-set
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Contains iSchedule Receiver capabilities.
+
+ Description: The capability-set element contains capabilities of the
+ iSchedule Receiver.
+
+ Definition:
+
+
+ <!ELEMENT capability-set (supported-version-set,
+ supported-scheduling-message-set,
+ supported-calendar-data,
+ supported-attachment-values,
+ supported-recipient-uri-scheme-set,
+ max-content-length,
+ min-date-time,
+ max-date-time,
+ max-instances,
+ max-recipients,
+ administrator) >
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 22]
+
+Internet-Draft iSchedule November 2009
+
+
+8.2.1.1. supported-version-set XML Element
+
+ Name: supported-version-set
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Identifies the iSchedule versions supported by the
+ iSchedule Receiver.
+
+ Description: An iSchedule Receiver MAY advertise support for
+ multiple versions of the iSchedule protocol.
+
+ Definition:
+
+
+ <!ELEMENT supported-version-set (version)+>
+
+8.2.1.1.1. version XML Element
+
+ Name: version
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies an iSchedule version.
+
+ Definition:
+
+
+ <!ELEMENT version (#PCDATA)>
+ <!-- PCDATA value: version number -->
+
+8.2.1.2. supported-scheduling-message-set XML Element
+
+ Name: supported-scheduling-message-set
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Identifies the type of supported scheduling messages.
+
+ Description: An iSchedule Receiver could advertise that it only
+ provides support for event and free-busy scheduling messages, and
+ not for to-do scheduling messages, with this capabilities.
+
+ Definition:
+
+
+ <!ELEMENT supported-scheduling-message-set (comp)+>
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 23]
+
+Internet-Draft iSchedule November 2009
+
+
+8.2.1.2.1. comp XML Element
+
+ Name: comp
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Identifies a calendar component type.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT comp (method)*>
+
+ <!ATTLIST comp name CDATA #REQUIRED>
+ <!-- name value: a calendar component name -->
+
+8.2.1.2.1.1. method XML Element
+
+ Name: method
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies an iCalendar method type.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT method EMPTY>
+
+ <!ATTLIST method name CDATA #REQUIRED>
+ <!-- name value: a method type -->
+
+8.2.1.3. supported-calendar-data XML Element
+
+ Name: supported-calendar-data
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Contains
+
+ Description:
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 24]
+
+Internet-Draft iSchedule November 2009
+
+
+ Definition:
+
+
+ <!ELEMENT supported-calendar-data (calendar-data)+>
+
+8.2.1.3.1. calendar-data XML Element
+
+ Name: calendar-data
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specified a supported media type for scheduling messages.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT calendar-data EMPTY>
+
+ <!ATTLIST calendar-data content-type CDATA "text/calendar"
+ version CDATA "2.0">
+ <!-- content-type value: a MIME media type -->
+ <!-- version value: a version string -->
+
+8.2.1.4. supported-attachment-values XML Element
+
+ Name: supported-attachment-values
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Identifies the attachment values supported.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT supported-attachment-values (inline-attachment?,
+ external-attachment?)>
+
+8.2.1.4.1. inline-attachment XML Element
+
+ Name: inline-attachment
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 25]
+
+Internet-Draft iSchedule November 2009
+
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies inline attachment as a supported attachment
+ value.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT inline-attachment EMPTY>
+
+8.2.1.4.2. external-attachment XML Element
+
+ Name: external-attachment
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies external attachment as a supported attachment
+ value.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT external-attachment EMPTY>
+
+8.2.1.5. supported-recipient-uri-scheme-set XML Element
+
+ Name: supported-recipient-uri-scheme-set
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Identifies the supported URI schemes supported in the
+ Recipient HTTP request header.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT supported-recipient-uri-scheme-set (scheme+)>
+
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 26]
+
+Internet-Draft iSchedule November 2009
+
+
+8.2.1.5.1. scheme XML Element
+
+ Name: scheme
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies a supported URI scheme.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT scheme (#PCDATA)>
+ <!-- PCDATA value: URI scheme (e.g., mailto) -->
+
+8.2.1.6. max-content-length XML Element
+
+ Name: max-content-length
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies the maximum size allowed for a scheduling message
+ in octets.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT max-content-length (#PCDATA)>
+ <!-- PCDATA value: a numeric value (positive integer) -->
+
+8.2.1.7. min-date-time XML Element
+
+ Name: min-date-time
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies a DATE-TIME value indicating the earliest date
+ and time in UTC that the server is willing to accept for any DATE
+ or DATE-TIME value in a scheduling message.
+
+ Description:
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 27]
+
+Internet-Draft iSchedule November 2009
+
+
+ Definition:
+
+
+ <!ELEMENT min-date-time (#PCDATA)>
+ <!-- PCDATA value: an iCalendar format DATE-TIME value in UTC -->
+
+8.2.1.8. max-date-time XML Element
+
+ Name: max-date-time
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies a DATE-TIME value indicating the latest date and
+ time in UTC that the server is willing to accept for any DATE or
+ DATE-TIME value in a scheduling message.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT max-date-time (#PCDATA)>
+ <!-- PCDATA value: an iCalendar format DATE-TIME value in UTC -->
+
+8.2.1.9. max-instances XML Element
+
+ Name: max-instances
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies the maximum number of recurrence instances
+ allowed in a scheduling message.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT max-instances (#PCDATA)>
+ <!-- PCDATA value: a numeric value (positive integer) -->
+
+8.2.1.10. max-recipients XML Element
+
+ Name: max-recipients
+
+
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 28]
+
+Internet-Draft iSchedule November 2009
+
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Specifies the maximum number of recipients allowed for a
+ scheduling message.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT max-recipients (#PCDATA)>
+ <!-- PCDATA value: a numeric value (positive integer) -->
+
+8.2.1.11. administrator XML Element
+
+ Name: administrator
+
+ Namespace: urn:ietf:params:xml:ns:ischedule
+
+ Purpose: Provides contact information for the administrator of the
+ iSchedule Receiver.
+
+ Description:
+
+ Definition:
+
+
+ <!ELEMENT administrator (#PCDATA)>
+ <!-- PCDATA value: URI to contact administrator -->
+
+9. Security Considerations
+
+ The process of scheduling involves the sending and receiving of
+ scheduling messages. As a result, the security problems related to
+ messaging in general are relevant here. In particular the
+ authenticity of the scheduling messages needs to be verified.
+
+9.1. Privacy
+
+ iSchedule Senders and iSchedule Receivers MUST use an HTTP connection
+ protected with TLS as defined in [RFC2818] for all scheduling
+ transactions.
+
+9.2. Authentication
+
+ Mutual authentication is done with TLS [RFC5246] using certificates
+ exchanged between both the iSchedule Sender and the iSchedule
+ Receiver.
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 29]
+
+Internet-Draft iSchedule November 2009
+
+
+9.3. Authorization
+
+ Once an iSchedule Sender has been successfully authenticated, the
+ iSchedule Receiver MUST verify that the iSchedule Sender has the
+ authority to send a scheduling message on behalf of the Originator.
+
+ TODO: Clarify how verification must be done. Should trusted
+ iSchedule Sender be identified as such in DNS (e.g., by storing their
+ certificate in the DNS (see [RFC4398])) Should the iSchedule Receiver
+ contact the iSchedule Receiver of the domain of the iSchedule Sender
+ to find out whether it should be trusted or not?
+
+10. IANA Considerations
+
+10.1. Namespace Registration
+
+ This specification registers a new URN to identify a new XML
+ namespace as per [RFC3688].
+
+10.1.1. iSchedule Namespace Registration
+
+ Registration request for the iSchedule namespace:
+
+ URI: urn:ietf:params:xml:ns:ischedule
+
+ Registrant Contact: See the "Authors' Addresses" section of this
+ document.
+
+ XML: None. Namespace URIs do not represent an XML specification.
+
+10.2. HTTP Headers Registration
+
+ This specification registers three new headers for use with HTTP as
+ per [RFC3864].
+
+10.2.1. iSchedule-Version General Header Registration
+
+ Header field name: iSchedule-Version
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document(s): this specification
+
+ Related information: none
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 30]
+
+Internet-Draft iSchedule November 2009
+
+
+10.2.2. iSchedule-Via General Header Registration
+
+ Header field name: iSchedule-Via
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document(s): this specification
+
+ Related information: none
+
+10.2.3. Originator Request Header Registration
+
+ Header field name: Originator
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document(s): this specification
+
+ Related information: none
+
+10.2.4. Recipient Request Header Registration
+
+ Header field name: Recipient
+
+ Applicable protocol: http
+
+ Status: standard
+
+ Author/Change controller: IETF
+
+ Specification document(s): this specification
+
+ Related information: none
+
+10.3. Well-Known URI Registration
+
+ This specification registers a new well-known URI as per
+ [I-D.nottingham-site-meta].
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 31]
+
+Internet-Draft iSchedule November 2009
+
+
+10.3.1. iSchedule Well-Known URI Registration
+
+ URI suffix: ischedule
+
+ Change controller: IETF.
+
+ Specification document(s): this specification
+
+ Related information: none
+
+11. Acknowledgments
+
+ The authors would like to thank the following individuals for
+ contributing their ideas and support for writing this specification:
+ Mattias Amnefelt, Mike Douglass, Tomas Hnetila, Ciny Joy, Arnaud
+ Quillaud, Simon Vaillancourt, and Wilfredo Sanchez Vega.
+
+ The authors would also like to thank the Calendaring and Scheduling
+ Consortium for advice with this specification, and for organizing
+ interoperability testing events to help refine it.
+
+12. References
+
+12.1. Normative References
+
+ [I-D.desruisseaux-caldav-sched] Daboo, C. and B. Desruisseaux,
+ "CalDAV Scheduling Extensions to
+ WebDAV",
+ draft-desruisseaux-caldav-sched-08
+ (work in progress), August 2009.
+
+ [I-D.ietf-calsify-2446bis] Daboo, C., "iCalendar Transport-
+ Independent Interoperability
+ Protocol (iTIP)",
+ draft-ietf-calsify-2446bis-10 (work
+ in progress), October 2009.
+
+ [I-D.nottingham-site-meta] Nottingham, M. and E. Hammer-Lahav,
+ "Defining Well-Known URIs",
+ draft-nottingham-site-meta-03 (work
+ in progress), September 2009.
+
+ [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.,
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 32]
+
+Internet-Draft iSchedule November 2009
+
+
+ Frystyk, H., Masinter, L., Leach,
+ P., and T. Berners-Lee, "Hypertext
+ Transfer Protocol -- HTTP/1.1",
+ RFC 2616, June 1999.
+
+ [RFC2782] Gulbrandsen, A., Vixie, P., and L.
+ Esibov, "A DNS RR for specifying the
+ location of services (DNS SRV)",
+ RFC 2782, February 2000.
+
+ [RFC2818] Rescorla, E., "HTTP Over TLS",
+ RFC 2818, May 2000.
+
+ [RFC3688] Mealling, M., "The IETF XML
+ Registry", BCP 81, RFC 3688,
+ January 2004.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and
+ L. Masinter, "Uniform Resource
+ Identifier (URI): Generic Syntax",
+ STD 66, RFC 3986, January 2005.
+
+ [RFC5246] Dierks, T. and E. Rescorla, "The
+ Transport Layer Security (TLS)
+ Protocol Version 1.2", RFC 5246,
+ August 2008.
+
+ [RFC5545] Desruisseaux, B., "Internet
+ Calendaring and Scheduling Core
+ Object Specification (iCalendar)",
+ RFC 5545, September 2009.
+
+ [W3C.REC-xml-20081126] Yergeau, F., Maler, E., Paoli, J.,
+ Sperberg-McQueen, C., and T. Bray,
+ "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>.
+
+12.2. Informative References
+
+ [I-D.faltstrom-uri] Faltstrom, P. and O. Kolkman, "The
+ Uniform Resource Identifier (URI)
+ DNS Resource Record",
+ draft-faltstrom-uri-04 (work in
+ progress), May 2009.
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 33]
+
+Internet-Draft iSchedule November 2009
+
+
+ [I-D.ietf-calsify-rfc2447bis] Melnikov, A., "iCalendar Message-
+ Based Interoperability Protocol
+ (iMIP)",
+ draft-ietf-calsify-rfc2447bis-07
+ (work in progress), October 2009.
+
+ [RFC3864] Klyne, G., Nottingham, M., and J.
+ Mogul, "Registration Procedures for
+ Message Header Fields", BCP 90,
+ RFC 3864, September 2004.
+
+ [RFC4398] Josefsson, S., "Storing Certificates
+ in the Domain Name System (DNS)",
+ RFC 4398, March 2006.
+
+ [RFC4791] Daboo, C., Desruisseaux, B., and L.
+ Dusseault, "Calendaring Extensions
+ to WebDAV (CalDAV)", RFC 4791,
+ March 2007.
+
+Appendix A. Open Issues
+
+ 1. Should we consider [I-D.faltstrom-uri] as another approach to
+ discover iSchedule Receiver?
+
+Authors' Addresses
+
+ Cyrus Daboo
+ Apple Inc.
+ 1 Infinite Loop
+ Cupertino, CA 95014
+ USA
+
+ EMail: cyrus at daboo.name
+ URI: http://www.apple.com/
+
+
+ Bernard Desruisseaux
+ Oracle Corporation
+ 600 Blvd. de Maisonneuve West
+ Suite 1900
+ Montreal, QC H3A 3J2
+ CANADA
+
+ EMail: bernard.desruisseaux at oracle.com
+ URI: http://www.oracle.com/
+
+
+
+
+
+Daboo & Desruisseaux Expires May 19, 2010 [Page 34]
+
\ No newline at end of file
Copied: CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt (from rev 4897, CalendarServer/branches/users/cdaboo/webdav-extensions-4888/doc/RFC/draft-nottingham-site-meta.txt)
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/draft-nottingham-site-meta.txt 2010-01-06 15:01:26 UTC (rev 4899)
@@ -0,0 +1,448 @@
+
+
+
+Network Working Group M. Nottingham
+Internet-Draft E. Hammer-Lahav
+Updates: 2616 2818 November 20, 2009
+(if approved)
+Intended status: Standards Track
+Expires: May 24, 2010
+
+
+ Defining Well-Known URIs
+ draft-nottingham-site-meta-04
+
+Abstract
+
+ This memo defines a path prefix for "well-known locations", "/.well-
+ known/" in selected URI schemes.
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 24, 2010.
+
+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
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 1]
+
+Internet-Draft Defining Well-Known URIs November 2009
+
+
+ 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.
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 3
+ 3. Well-Known URIs . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+ 5.1. The Well-Known URI Registry . . . . . . . . . . . . . . . . 4
+ 5.1.1. Registration Template . . . . . . . . . . . . . . . . . 5
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . . 5
+ 6.2. Informative References . . . . . . . . . . . . . . . . . . 6
+ Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 6
+ Appendix B. Frequently Asked Questions . . . . . . . . . . . . . . 6
+ B.1. Aren't well-known locations bad for the Web? . . . . . . . 6
+ B.2. Why /.well-known? . . . . . . . . . . . . . . . . . . . . . 7
+ B.3. What impact does this have on existing mechanisms,
+ such as P3P and robots.txt? . . . . . . . . . . . . . . . . 7
+ B.4. Why aren't per-directory well-known locations defined? . . 7
+ Appendix C. Document History . . . . . . . . . . . . . . . . . . . 7
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 2]
+
+Internet-Draft Defining Well-Known URIs November 2009
+
+
+1. Introduction
+
+ It is increasingly common for Web-based protocols to require the
+ discovery of policy or metadata before making a request. For
+ example, the Robots Exclusion Protocol specifies a way for automated
+ processes to obtain permission to access resources; likewise, the
+ Platform for Privacy Preferences [W3C.REC-P3P-20020416] tells user-
+ agents how to discover privacy policy beforehand.
+
+ While there are several ways to access per-resource metadata (e.g.,
+ HTTP headers, WebDAV's PROPFIND [RFC4918]), the perceived overhead
+ associated with them often precludes their use in these scenarios.
+
+ When this happens, it is common to designate a "well-known location"
+ for such metadata, so that it can be easily located. However, this
+ approach has the drawback of risking collisions, both with other such
+ designated "well-known locations" and with pre-existing resources.
+
+ To address this, this memo defines a path prefix in HTTP(S) URIs for
+ these "well-known locations", "/.well-known/". Future specifications
+ that need to define a resource for such site-wide metadata can
+ register their use to avoid collisions and minimise impingement upon
+ sites' URI space.
+
+ [[ Please discuss this draft on the apps-discuss at ietf.org [1] mailing
+ list. ]]
+
+
+2. Notational Conventions
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+3. Well-Known URIs
+
+ A well-known URI is a URI [RFC3986] whose path component begins with
+ the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
+ or another scheme which has explicitly been specified to use well-
+ known URIs.
+
+ Applications that wish to mint new well-known URIs MUST register
+ them, following the procedures in Section 5.1.
+
+ For example, if an application registers the value 'example', the
+ corresponding well-known URI on 'http://www.example.com/' would be
+ 'http://www.example.com/.well-known/example'.
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 3]
+
+Internet-Draft Defining Well-Known URIs November 2009
+
+
+ Note that this specification defines neither how to determine the
+ authority to use for a particular context, nor the scope of the
+ metadata discovered by dereferencing the well-known URI; both should
+ be defined by the application itself.
+
+ Typically, a registration will reference a specification that defines
+ the format and associated media type to be obtained by dereferencing
+ the well-known URI.
+
+ It MAY also contain additional information, such as the syntax of
+ additional path components, query strings and/or fragment identifiers
+ to be appended to the well-known URI, or protocol-specific details
+ (e.g., HTTP [RFC2616] method handling).
+
+ Note that this specification also does not define a format or media-
+ type for the resource at located at "/.well-known/" and clients
+ should not expect a resource to exist at that location.
+
+
+4. Security Considerations
+
+ This memo does not specify the scope of applicability of metadata or
+ policy obtained from a well-known URI, and does not specify how to
+ discover a well-known URI for a particular application. Individual
+ applications using this mechanism must define both aspects.
+
+ An attacker with certain types of limited access to a server may be
+ able to affect how well-known URIs are served; for example, they may
+ be able to upload a file at that location, or they may be able to
+ cause a server to redirect a well-known URI to a URI that they
+ control.
+
+ Because most URI schemes rely on DNS to resolve names, they are
+ vulnerable to "DNS rebinding" attacks, whereby a request can be
+ directed to a server under the control of an attacker.
+
+
+5. IANA Considerations
+
+5.1. The Well-Known URI Registry
+
+ This document establishes the well-known URI registry.
+
+ Well-known URIs are registered on the advice of one or more
+ Designated Experts (appointed by the IESG or their delegate), with a
+ Specification Required (using terminology from [RFC5226]).
+
+ Registration requests consist of the completed registration template
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 4]
+
+Internet-Draft Defining Well-Known URIs November 2009
+
+
+ (see Section 5.1.1), typically published in an RFC or Open Standard
+ (in the sense described by [RFC2026], section 7). However, to allow
+ for the allocation of values prior to publication, the Designated
+ Expert(s) may approve registration once they are satisfied that an
+ RFC (or other Open Standard) will be published.
+
+ Registration requests should be sent to the [TBD]@ietf.org mailing
+ list for review and comment, with an appropriate subject (e.g.,
+ "Request for well-known URI: example").
+
+ [[NOTE TO RFC-EDITOR: The name of the mailing list should be
+ determined in consultation with the IESG and IANA. Suggested name:
+ wellknown-uri-review. ]]
+
+ Before a period of 14 days has passed, the Designated Expert(s) will
+ either approve or deny the registration request, communicating this
+ decision both to the review list and to IANA. Denials should include
+ an explanation and, if applicable, suggestions as to how to make the
+ request successful.
+
+5.1.1. Registration Template
+
+ URI suffix: The name requested for the well-known URI, relative to
+ "/.well-known/"; e.g., "example". MUST conform to the segment-nz
+ production in [RFC3986].
+ Change controller: For standards-track RFCs, state "IETF". For
+ other open standards, give the name of the publishing body (e.g.,
+ ANSI, ISO, ITU, W3C, etc.). A postal address, home page URI,
+ telephone and fax numbers may also be included.
+ Specification document(s): Reference to document that specifies the
+ field, preferably including a URI that can be used to retrieve a
+ copy of the document. An indication of the relevant sections may
+ also be included, but is not required.
+ Related information: Optionally, citations to additional documents
+ containing further relevant information.
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
+ 3", BCP 9, RFC 2026, October 1996.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 5]
+
+Internet-Draft Defining Well-Known URIs November 2009
+
+
+ Resource Identifier (URI): Generic Syntax", STD 66,
+ RFC 3986, January 2005.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+6.2. Informative References
+
+ [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.
+
+ [RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed
+ Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+ [W3C.REC-P3P-20020416]
+ Marchiori, M., "The Platform for Privacy Preferences 1.0
+ (P3P1.0) Specification", W3C REC REC-P3P-20020416,
+ April 2002.
+
+URIs
+
+ [1] <https://www.ietf.org/mailman/listinfo/apps-discuss>
+
+
+Appendix A. Acknowledgements
+
+ We would like to acknowledge the contributions of everyone who
+ provided feedback and use cases for this draft; in particular, Phil
+ Archer, Dirk Balfanz, Adam Barth, Tim Bray, Brian Eaton, Brad
+ Fitzpatrick, Joe Gregorio, Paul Hoffman, Barry Leiba, Ashok Malhotra,
+ Breno de Medeiros, John Panzer, and Drummond Reed. However, they are
+ not responsible for errors and omissions.
+
+
+Appendix B. Frequently Asked Questions
+
+B.1. Aren't well-known locations bad for the Web?
+
+ They are, but for various reasons -- both technical and social --
+ they are commonly used, and their use is increasing. This memo
+ defines a "sandbox" for them, to reduce the risks of collision and to
+ minimise the impact upon pre-existing URIs on sites.
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 6]
+
+Internet-Draft Defining Well-Known URIs November 2009
+
+
+B.2. Why /.well-known?
+
+ It's short, descriptive and according to search indices, not widely
+ used.
+
+B.3. What impact does this have on existing mechanisms, such as P3P and
+ robots.txt?
+
+ None, until they choose to use this mechanism.
+
+B.4. Why aren't per-directory well-known locations defined?
+
+ Allowing every URI path segment to have a well-known location (e.g.,
+ "/images/.well-known/") would increase the risks of colliding with a
+ pre-existing URI on a site, and generally these solutions are found
+ not to scale well, because they're too "chatty".
+
+
+Appendix C. Document History
+
+ [[RFC Editor: please remove this section before publication.]]
+
+ o -04
+ * Restrict to HTTP(S) by default.
+ * Shorten review SLA to 14 days.
+ * Allow for multiple designated experts.
+ * Identify mailing list for request submission and discussion.
+ o -03
+ * Add fragment identifiers to list of things an application might
+ define.
+ * Note that the /.well-known/ URI doesn't have anything there.
+ o -02
+ * Rewrote to just define a namespace for well-known URIs.
+ * Changed discussion forum to apps-discuss.
+ o -01
+ * Changed "site-meta" to "host-meta" after feedback.
+ * Changed from XML to text-based header-like format.
+ * Remove capability for generic inline content.
+ * Added registry for host-meta fields.
+ * Clarified scope of metadata application.
+ * Added security consideration about HTTP vs. HTTPS, expanding
+ scope.
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 7]
+
+Internet-Draft Defining Well-Known URIs November 2009
+
+
+Authors' Addresses
+
+ Mark Nottingham
+
+ Email: mnot at mnot.net
+ URI: http://www.mnot.net/
+
+
+ Eran Hammer-Lahav
+
+ Email: eran at hueniverse.com
+ URI: http://hueniverse.com/
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Nottingham & Hammer-Lahav Expires May 24, 2010 [Page 8]
+
\ No newline at end of file
Copied: CalendarServer/trunk/doc/RFC/draft-reschke-webdav-post.txt (from rev 4897, CalendarServer/branches/users/cdaboo/webdav-extensions-4888/doc/RFC/draft-reschke-webdav-post.txt)
===================================================================
--- CalendarServer/trunk/doc/RFC/draft-reschke-webdav-post.txt (rev 0)
+++ CalendarServer/trunk/doc/RFC/draft-reschke-webdav-post.txt 2010-01-06 15:01:26 UTC (rev 4899)
@@ -0,0 +1,784 @@
+
+
+
+Network Working Group J. Reschke
+Internet-Draft greenbytes
+Intended status: Standards Track November 22, 2009
+Expires: May 26, 2010
+
+
+ Using POST to add Members to Web Distributed Authoring and Versioning
+ (WebDAV) Collections
+ draft-reschke-webdav-post-05
+
+Abstract
+
+ The Hypertext Transfer Protocol (HTTP) Extensions for the Web
+ Distributed Authoring and Versioning (WebDAV) do not define the
+ behavior for the "POST" method when applied to collections, as the
+ base specification (HTTP) leaves implementers lots of freedom for the
+ semantics of "POST".
+
+ This has led to a situation where many WebDAV servers do not
+ implement POST for collections at all, although it is well suited to
+ be used for the purpose of adding new members to a collection, where
+ the server remains in control of the newly assigned URL. As a matter
+ of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for
+ that purpose. On the other hand, WebDAV-based protocols such as the
+ Calendar Extensions to WebDAV (CalDAV) frequently require clients to
+ pick a unique URL, although the server could easily perform that
+ task.
+
+ This specification defines a discovery mechanism through which
+ servers can advertise support for POST requests with the
+ aforementioned "add collection member" semantics.
+
+Editorial Note (To be removed by RFC Editor before publication)
+
+ Please send comments to the Distributed Authoring and Versioning
+ (WebDAV) working group at <mailto:w3c-dist-auth at w3.org>, which may be
+ joined by sending a message with subject "subscribe" to
+ <mailto:w3c-dist-auth-request at w3.org>. Discussions of the WEBDAV
+ working group are archived at
+ <http://lists.w3.org/Archives/Public/w3c-dist-auth/>.
+
+ Note that although discussion takes place on the WebDAV working
+ group's mailing list, this is not a working group document.
+
+ XML versions, latest edits and the issues list for this document are
+ available from
+ <http://greenbytes.de/tech/webdav/#draft-reschke-webdav-post>.
+
+
+
+
+Reschke Expires May 26, 2010 [Page 1]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+Status of this Memo
+
+ This Internet-Draft is submitted to IETF in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF), its areas, and its working groups. Note that
+ other groups may also distribute working documents as Internet-
+ Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ The list of current Internet-Drafts can be accessed at
+ http://www.ietf.org/ietf/1id-abstracts.txt.
+
+ The list of Internet-Draft Shadow Directories can be accessed at
+ http://www.ietf.org/shadow.html.
+
+ This Internet-Draft will expire on May 26, 2010.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reschke Expires May 26, 2010 [Page 2]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3. Protocol Extension . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.1. Definition of 'Add-Member' URI . . . . . . . . . . . . . . 6
+ 3.2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2.1. DAV:add-member Property (protected) . . . . . . . . . 7
+ 3.2.2. Example . . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.3. Relation to AtomPub's 'Slug' Header Field . . . . . . . . 8
+ 3.4. Example Operation . . . . . . . . . . . . . . . . . . . . 9
+ 4. Additional Semantics for existing Methods . . . . . . . . . . 9
+ 4.1. Additional Preconditions . . . . . . . . . . . . . . . . . 9
+ 4.2. Example: Failed PUT Request . . . . . . . . . . . . . . . 10
+ 5. Relationship to WebDAV Access Control Protocol . . . . . . . . 10
+ 6. Internationalization Considerations . . . . . . . . . . . . . 10
+ 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
+ 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
+ 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
+ 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11
+ 10.2. Informative References . . . . . . . . . . . . . . . . . . 12
+ Appendix A. Change Log (to be removed by RFC Editor before
+ publication) . . . . . . . . . . . . . . . . . . . . 12
+ A.1. since draft-reschke-webdav-post-00 . . . . . . . . . . . . 12
+ A.2. since draft-reschke-webdav-post-01 . . . . . . . . . . . . 13
+ A.3. since draft-reschke-webdav-post-02 . . . . . . . . . . . . 13
+ A.4. since draft-reschke-webdav-post-03 . . . . . . . . . . . . 13
+ A.5. since draft-reschke-webdav-post-04 . . . . . . . . . . . . 13
+ Appendix B. Open issues (to be removed by RFC Editor prior to
+ publication) . . . . . . . . . . . . . . . . . . . . 13
+ B.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
+ B.2. collection . . . . . . . . . . . . . . . . . . . . . . . . 13
+ Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reschke Expires May 26, 2010 [Page 3]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+1. Introduction
+
+ The Hypertext Transfer Protocol (HTTP) Extensions for the Web
+ Distributed Authoring and Versioning (WebDAV) ([RFC4918], Section
+ 9.5) do not define the behavior for the "POST" method when applied to
+ collections, as the base specification (HTTP) leaves implementers
+ lots of freedom for the semantics of "POST":
+
+ 9.5 POST for Collections
+
+ Since by definition the actual function performed by POST is
+ determined by the server and often depends on the particular
+ resource, the behavior of POST when applied to collections cannot
+ be meaningfully modified because it is largely undefined. Thus,
+ the semantics of POST are unmodified when applied to a collection.
+
+ This has led to a situation where many WebDAV servers do not
+ implement POST for collections at all, although it is well suited to
+ be used for the purpose of adding new members to a collection, where
+ the server remains in control of the newly assigned URL. As a matter
+ of fact, the Atom Publishing Protocol (AtomPub) uses POST exactly for
+ that purpose ([RFC5023], Section 9.2):
+
+ 9.2 Creating Resources with POST
+
+ To add members to a Collection, clients send POST requests to the
+ URI of the Collection.
+
+ On the other hand, WebDAV-based protocols such as Calendaring
+ Extensions to WebDAV (CalDAV) frequently require clients to pick a
+ unique URL, although the server could easily perform that task
+ ([RFC4791], Section 5.3.2):
+
+ 5.3.2 Creating Calendar Object Resources
+
+ ...
+
+ When servers create new resources, it's not hard for the server to
+ choose an unmapped URI. It's slightly tougher for clients,
+ because a client might not want to examine all resources in the
+ collection and might not want to lock the entire collection to
+ ensure that a new resource isn't created with a name collision.
+ (...)
+
+ As a matter of fact, letting the server choose the member URI not
+ only is a simplification for certain types of clients, but can also
+ reduce the complexity of the server (in that it doesn't need to
+ persist an additional client-supplied identifier where it already has
+
+
+
+Reschke Expires May 26, 2010 [Page 4]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+ an internal one like a UUID or a primary key).
+
+ Note: the vCard Extensions to WebDAV (CardDAV)
+ ([draft-ietf-vcarddav-carddav]) suffer from the same issue, and
+ may be able to take advantage of this specification.
+
+ This specification defines a discovery mechanism through which
+ servers can advertise support for POST requests with the
+ aforementioned "add collection member" semantics.
+
+ Note that this specification deliberately only adresses the use case
+ of creating new non-collection resources, and that it was not a goal
+ to supply the same functionality for creating collection resources
+ (MKCOL), or for other operations that require the client to specify a
+ new URL (LOCK, MOVE, or COPY).
+
+ Note: the author previously proposed a new HTTP method for exactly
+ this purpose ([draft-reschke-http-addmember]), but quite a few
+ reviewers pointed out that this would duplicate the original
+ semantics of POST. Thus this proposal that avoids adding a new
+ HTTP method is made.
+
+
+2. Terminology
+
+ The terminology used here follows that in the WebDAV specification
+ ([RFC4918]).
+
+ 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 ([XML]) as a purely notational
+ convention. In particular:
+
+ o Element ordering is irrelevant.
+
+ o Extension elements/attributes (elements/attributes not already
+ defined as valid child elements) may be added anywhere, except
+ when explicitly stated otherwise.
+
+ Note: this specification defines new properties and precondition
+ names in the "DAV:" namespace, which the WebDAV specification
+ reserves for use by the IETF ([RFC4918], Section 21.1). However,
+ there was rough consensus in the WebDAV community that the
+ specification is of general applicability to other WebDAV related
+ standards efforts, and thus deserves inclusion into the base
+ namespace.
+
+
+
+Reschke Expires May 26, 2010 [Page 5]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+3. Protocol Extension
+
+ Due to the reasons stated in Section 1, clients can not rely on a
+ specific server behavior when POST is applied to a collection. This
+ problem is addressed by this specification by allowing servers to
+ advertise a URI that has the desired "add member" semantics.
+
+ Note that servers that already use POST for a different purpose can
+ just expose a separate URI. Other servers can just advertise the
+ collection's own URI, thus avoiding minting another URI for a limited
+ purpose.
+
+3.1. Definition of 'Add-Member' URI
+
+ The "Add-Member" URI of a WebDAV collection is a URI that will accept
+ HTTP POST requests, and will interpret these as requests to store the
+ enclosed entity as a new internal member of the collection (see
+ Section 3 of [RFC4918] for the definition of "internal member"). It
+ MUST identify a resource on the same server as the WebDAV collection
+ (the host and port components ([RFC2616], Section 3.2.2) of the URIs
+ must match).
+
+ If there are pre-conditions related to creating a resource in the
+ collection using a PUT request, then those same pre-conditions apply
+ to the new POST request behavior, and the same HTTP response body
+ will returned on failure.
+
+ The URI of the newly created resource is returned in the HTTP
+ Location response header field ([RFC2616], Section 14.30).
+
+ Note: the fact that a server advertises an "Add-Member" URI does
+ not imply any special semantics of the collection itself. For
+ instance, member URIs assigned by the server are not necessarily
+ unique over time (a member URI may be assigned again to a new
+ resource when it previously was removed).
+
+ Note: the "Add-Member" URI can be the identical to the
+ collection's URI (in which case the server just advertises the
+ fact that POST to the WebDAV collection's URI is supported as
+ defined within this specification). But it can also be different
+ from it, in which case it doesn't need to have any relation to the
+ collection's URI.
+
+ Given a collection URI of
+
+ /docs/collection/
+
+
+
+
+
+Reschke Expires May 26, 2010 [Page 6]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+ all of the URIs below might occur as "Add-Member" URIs:
+
+ /docs/collection/
+ /docs/collection/;post
+ /docs/collection;post/
+ /docs/collection/&post
+ /post-service?path=/collection/
+
+ The remainder of the document uses the same format just for
+ reasons of consistency; any other HTTP URI on the same server
+ would do as well.
+
+3.2. Discovery
+
+3.2.1. DAV:add-member Property (protected)
+
+ DAV:add-member is a protected property (see [RFC4918], Section 15)
+ defined on WebDAV collections, and contains the "Add-Member" URI for
+ that collection (embedded inside a DAV:href element).
+
+ <!ELEMENT add-member (href)>
+ <!-- href: defined in [RFC4918], Section 14.7 -->
+
+ A PROPFIND/allprop request SHOULD NOT return this property (see
+ [RFC4918], Section 9.1). Servers MUST implement the DAV:supported-
+ live-property-set property defined in Section 3.1.4 of [RFC3253], and
+ report the property DAV:add-member as a supported live property.
+
+3.2.2. Example
+
+ >>Request
+
+ PROPFIND /collection/ HTTP/1.1
+ Host: example.com
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: 118
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <propfind xmlns="DAV:">
+ <prop>
+ <add-member/>
+ </prop>
+ </propfind>
+
+
+
+
+
+
+
+
+Reschke Expires May 26, 2010 [Page 7]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+ >>Response
+
+ HTTP/1.1 207 Multi-Status
+ Content-Type: application/xml; charset="utf-8"
+ Content-Length: 340
+
+ <?xml version="1.0" encoding="utf-8" ?>
+ <multistatus xmlns="DAV:">
+ <response>
+ <href>/collection/</href>
+ <propstat>
+ <prop>
+ <add-member>
+ <href>/collection;add-member/</href>
+ </add-member>
+ </prop>
+ <status>HTTP/1.1 200 OK</status>
+ </propstat>
+ </response>
+ </multistatus>
+
+ Note that in this case, the server has minted a separate URI for the
+ purpose of adding new content.
+
+3.3. Relation to AtomPub's 'Slug' Header Field
+
+ In the AtomPub protocol, clients can use the entity header field
+ "Slug" to suggest parts of the URI to be created (see [RFC5023],
+ Section 9.7). Note that servers are free to ignore this suggestion,
+ or to use whatever algorithm that makes sense to generate the new
+ URI.
+
+ The same applies to the extension defined here: clients can use the
+ "Slug" header field as by its definition of a generic HTTP header
+ field. Servers should process it exactly in the way defined by
+ AtomPub.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Reschke Expires May 26, 2010 [Page 8]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+3.4. Example Operation
+
+ >>Request
+
+ POST /collection;add-member/ HTTP/1.1
+ Host: example.com
+ Content-Type: text/plain
+ Slug: Sample Title
+ Content-Length: 12
+
+ Sample text.
+
+ >>Response
+
+ HTTP/1.1 201 Created
+ Location: http://example.com/collection/sample%20title
+
+
+4. Additional Semantics for existing Methods
+
+ One important use case for this specification are collections that
+ act as WebDAV collections for the purpose of read access (PROPFIND
+ Depth 1/Infinity), but which only support internal member URIs
+ assigned by the server. These collections will not allow a client to
+ create a new member using methods like PUT, MKCOL, LOCK, COPY or
+ MOVE. Therefore, this specification defines a new precondition name
+ ([RFC4918], Section 16) that can be used to provide the client with
+ additional information about why exactly the request failed.
+
+ Note: although the precondition defined below can be used for
+ methods other than PUT, the "Add-Member" mechanism defined by this
+ specification deliberately is restricted to PUT.
+
+4.1. Additional Preconditions
+
+ (DAV:allow-client-defined-URI): the server allows clients to specify
+ the last path segment for newly created resources.
+
+ The precondition element MAY contain a add-member-uri XML element
+ specifying the "Add-Member" URI associated with the collection, on
+ which the creation of a new child resource was attempted:
+
+ <!ELEMENT allow-client-defined-uri (add-member?)>
+
+
+
+
+
+
+
+
+Reschke Expires May 26, 2010 [Page 9]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+4.2. Example: Failed PUT Request
+
+ In this example, the client tries to use PUT to create a new internal
+ member of /collection/.
+
+ >>Request
+
+ PUT /collection/new.txt HTTP/1.1
+ Host: example.com
+ Content-Type: text/plain
+ Content-Length: 12
+
+ Sample text.
+
+ >>Response
+
+ HTTP/1.1 405 Method Not Allowed
+ Allow: GET, HEAD, TRACE, PROPFIND, COPY, MOVE
+ Content-Type: application/xml; charset=UTF-8
+ Content-Length: 172
+
+ <error xmlns="DAV:">
+ <allow-client-defined-uri>
+ <add-member>
+ <href>/collection;add-member/</href>
+ </add-member>
+ </allow-client-defined-uri>
+ </error>
+
+ The request fails with a 405 (Method Not Allowed) status, but also
+ provides the reason, and a pointer to the "Add-Member" URI in the
+ response body.
+
+
+5. Relationship to WebDAV Access Control Protocol
+
+ The WebDAV ACL specification requires the DAV:bind privilege to be
+ granted on a collection for the client to be able add new collection
+ members ([RFC3744], Section 3.9). Consistent with that, a server
+ MUST reject a POST request to the Add-Member URI of a collection
+ unless the principal executing the request is granted DAV:bind
+ privilege on the associated WebDAV collection resource.
+
+
+6. Internationalization Considerations
+
+ This document does not introduce any new internationalization
+ considerations beyond those discussed in Section 20 of [RFC4918].
+
+
+
+Reschke Expires May 26, 2010 [Page 10]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+7. IANA Considerations
+
+ This specification does not require any actions from IANA.
+
+
+8. Security Considerations
+
+ All security considerations connected to HTTP/WebDAV and XML apply
+ for this specification as well, namely, [RFC4918] (Section 20) and
+ [RFC3470] (Section 7).
+
+ Furthermore, servers should be aware that deriving the member path
+ from the data being stored in the resource could potentially expose
+ confidential information. This could even be the case when only a
+ hash code of the content is used.
+
+ In addition, on servers that do not support this specification, a
+ malevolent user could set the DAV:add-member URI as a custom
+ property, tricking other users to post content to an entirely
+ different URI. Clients can protect themselves against this scenario
+ by
+
+ o not following DAV:add-member URIs to different servers, and/or
+
+ o verifying that the DAV:add-member property is indeed a live
+ property (this can be achieved by testing the DAV:supported-live-
+ property-set property, or by checking whether DAV:add-member is
+ returned upon PROPFIND/allprop)
+
+
+9. Acknowledgements
+
+ This document has benefited from thoughtful discussion by Cyrus Daboo
+ and Bernard Desruissaux.
+
+
+10. References
+
+10.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.
+
+ [RFC3253] Clemm, G., Amsden, J., Ellison, T., Kaler, C., and J.
+
+
+
+Reschke Expires May 26, 2010 [Page 11]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+ Whitehead, "Versioning Extensions to WebDAV", RFC 3253,
+ March 2002.
+
+ [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., Ed., "HTTP Extensions for Web Distributed
+ Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
+
+ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and
+ F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
+ Edition)", W3C REC-xml-20081126, November 2008,
+ <http://www.w3.org/TR/2008/REC-xml-20081126/>.
+
+10.2. Informative References
+
+ [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
+ the Use of Extensible Markup Language (XML) within IETF
+ Protocols", RFC 3470, BCP 70, January 2003.
+
+ [RFC4791] Daboo, C., Desruisseaux, B., and L. Dusseault,
+ "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
+ March 2007.
+
+ [RFC5023] Gregorio, J. and B. de hOra, "The Atom Publishing
+ Protocol", RFC 5023, October 2007.
+
+ [draft-ietf-vcarddav-carddav]
+ Daboo, C., "vCard Extensions to WebDAV (CardDAV)",
+ draft-ietf-vcarddav-carddav-10 (work in progress),
+ November 2009.
+
+ [draft-reschke-http-addmember]
+ Reschke, J., "The HTTP ADDMEMBER Method",
+ draft-reschke-http-addmember-00 (work in progress),
+ February 2005.
+
+
+Appendix A. Change Log (to be removed by RFC Editor before publication)
+
+A.1. since draft-reschke-webdav-post-00
+
+ Added Acknowledgements.
+
+ Added and resolved issues "acl", "forbidden-put", "member-uri-
+ content", "post-error-semantics", "property-trust", "rational-server-
+ uri", ""remote-uri", "uri-format" and "uri-uniqueness".
+
+
+
+Reschke Expires May 26, 2010 [Page 12]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+A.2. since draft-reschke-webdav-post-01
+
+ Add and resolve issue "containment".
+
+ Update draft-ietf-vcarddav-carddav reference.
+
+A.3. since draft-reschke-webdav-post-02
+
+ Update XML, draft-ietf-vcarddav-carddav and
+ draft-nottingham-http-link-header references.
+
+ Add and resolve issues "link-header" and "ns".
+
+A.4. since draft-reschke-webdav-post-03
+
+ Add and resolve issues "put-only" and "protected".
+
+A.5. since draft-reschke-webdav-post-04
+
+ Update vcarddav reference. In the example, do not use the same
+ content for Slug header field and request body. Add issue
+ "collection".
+
+
+Appendix B. Open issues (to be removed by RFC Editor prior to
+ publication)
+
+B.1. edit
+
+ Type: edit
+
+ julian.reschke at greenbytes.de (2008-09-22): Umbrella issue for
+ editorial fixes/enhancements.
+
+B.2. collection
+
+ Type: change
+
+ cyrus at daboo.name (2009-11-05): I have heard from some implementors
+ that they would like collection creation to also be part of this
+ draft. In particular, CalDAV and/or CardDAV clients creating
+ calendars or address books would prefer to leave specification of the
+ resource name to the client.
+ Proposal:
+ - Add a DAV:add-collection property containing a URI (which must be
+ different than DAV:add-member)
+ - A POST on that URI creates a collection within the parent
+ collection, with a server chosen resource name
+
+
+
+Reschke Expires May 26, 2010 [Page 13]
+
+Internet-Draft POST to add to WebDAV Collections November 2009
+
+
+ - If the POST contains an XML body with DAV:mkcol as the root
+ element, then that body is interpreted the same way as MKCOL ext.
+
+
+Index
+
+ A
+ Add-Member URI 6
+
+ C
+ Condition Names
+ DAV:allow-client-defined-URI (pre) 9
+ COPY method
+ Additional Preconditions 9
+
+ D
+ DAV:allow-client-defined-URI 9
+
+ L
+ LOCK method
+ Additional Preconditions 9
+
+ M
+ MKCOL method
+ Additional Preconditions 9
+ MOVE method
+ Additional Preconditions 9
+
+ P
+ PUT method
+ Additional Preconditions 9
+
+
+Author's Address
+
+ Julian F. Reschke
+ greenbytes GmbH
+ Hafenweg 16
+ Muenster, NW 48155
+ Germany
+
+ Phone: +49 251 2807760
+ Email: julian.reschke at greenbytes.de
+ URI: http://greenbytes.de/tech/webdav/
+
+
+
+
+
+
+
+Reschke Expires May 26, 2010 [Page 14]
+
\ No newline at end of file
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/calendarserver-changes/attachments/20100106/7dda53a5/attachment-0001.html>
More information about the calendarserver-changes
mailing list