<?xml version="1.0" encoding="UTF-8"?><?rfc rfcedstyle="yes" ?><?rfc toc="yes"?><?rfc tocdepth="4"?><!-- default = 3 --><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><!--<?rfc strict="yes"?> --><!--<?rfc comments="yes"?> --><!--<?rfc inline="yes"?> --><rfc category="std" ipr="full3978" docName="draft-ietf-vcarddav-webdav-mkcol-02" obsoletes="" submissionType="IETF" xml:lang="en" updates="">
  <front>
    <title>Extended MKCOL for WebDAV</title>
    <author initials="C." surname="Daboo" fullname="Cyrus Daboo">
      <organization abbrev="Apple Inc.">
        Apple Inc. 
      </organization>
      <address>
        <postal>
          <street>
            1 Infinite Loop 
          </street>
          <city>
            Cupertino 
          </city>
          <region>
            CA 
          </region>
          <code> 95014 </code> 
          <country>
            USA 
          </country>
        </postal>
        <email>
          cyrus@daboo.name 
        </email>
        <uri>
          http://www.apple.com/ 
        </uri>
      </address>
    </author>
    <date year="2008" month="November" day="28"/>
    <area>
      Applications 
    </area>
    <abstract>
      <t>
        This specification extends the Web Distributed Authoring and Versioning (WebDAV) MKCOL method to allow collections of arbitrary resourcetype to be created and to allow properties to be set at the same time. 
      </t>
    </abstract>
  </front>
  <middle>
    <section title="Introduction" toc="default">
      <t>
        WebDAV <xref target="RFC4918" format="default" pageno="false"/> defines the HTTP <xref target="RFC2616" format="default" pageno="false"/> method MKCOL. This method is used to create WebDAV collections on the server. However, several WebDAV-based specifications (e.g., CalDAV <xref target="RFC4791" format="default" pageno="false"/>) define "special" collections - ones which are identified by additional values in the DAV:resourcetype property assigned to the collection resource, or through other means. These "special" collections are created by new methods (e.g., MKCALENDAR). The addition of a new MKxxx method for each new "special" collection adds to server complexity and is detrimental to overall reliability due to the need to make sure intermediaries are aware of these methods.
      </t>
      <t>
        This specification proposes an extension to the WebDAV MKCOL method that adds a request body allowing a client to specify WebDAV properties to be set on the newly created collection or resource. In particular, the DAV:resourcetype property can be used to create a "special" collection, or other properties used to create a "special" resource. This avoids the need to invent new MKxxx methods.
      </t>
    </section>
    <section title="Conventions Used in This Document" toc="default">
      <t>
        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 <xref target="RFC2119" format="default" pageno="false"/>. 
      </t>
	  <t>
		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 <xref target="W3C.REC-xml-20060816" format="default" pageno="false"/>.
	  </t>
      <t>
        When XML element types in the namespace "DAV:" are referenced in this document outside of the context of an XML fragment, the string "DAV:" will be prefixed to the element type names. 
      </t>
	  <t>
		Processing of XML by clients and servers MUST follow the rules described in Appendix A of <xref target="RFC4918" format="default" pageno="false"/>.
	  </t>
    </section>
    <section title="WebDAV extended MKCOL" toc="default">
      <t>
        The WebDAV MKCOL request is extended to allow the inclusion of a request body. The request body is an XML document containing a single DAV:mkcol XML element as the root element. The Content-Type request header MUST be set appropriately for an XML body (e.g., set to "text/xml" or "application/xml"). XML-typed bodies for an MKCOL request that do not have DAV:mkcol as the root element are reserved for future usage.
      </t>
      <t>
        One or more DAV:set XML elements MAY be included in the DAV:mkcol XML element to allow setting properties on the collection as it is created. In particular, to create a collection of a particular type, the DAV:resourcetype XML element MUST be included in a DAV:set XML element and MUST specify the expected resource type elements for the new resource, that MUST include the DAV:collection element that needs to be present for any WebDAV collection.
      </t>
      <t>
        As per the PROPPATCH method (<xref target="RFC4918" format="default" pageno="false"/>, Section 9.2), servers MUST process any DAV:set instructions in document order (an exception to the normal rule that ordering is irrelevant). Instructions MUST either all be executed or none executed.  Thus, if any error occurs during processing, all executed instructions MUST be undone and a proper error result returned. Failure to set a property value on the collection MUST result in a failure of the overall MKCOL request.
      </t>
      <t>
        If a server attempts to make any of the property changes in an extended MKCOL request (i.e., the request is not rejected for high-level errors before processing the body), the response MUST be an XML document containing a single DAV:mkcol-response XML element, which MUST contain DAV:propstat XML elements with the status of each property.
      </t>
      <t>
        In all other respects the behavior of the extended MKCOL request follows that of the standard MKCOL request.
      </t>

	  <section title="Extended MKCOL Support" anchor="capability" toc="default">
		<t>
			A server supporting the features described in this document, MUST include "extended-mkcol" as a field in the DAV response header from an OPTIONS request on any URI that supports use of the extended MKCOL method.
		</t>
		<section title="Example: Using OPTIONS for the Discovery of Support for Extended MKCOL" toc="default">
			<figure height="" suppress-title="false" width="" alt="" title="" align="left">
				<preamble>&gt;&gt; Request &lt;&lt;</preamble>
				<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
OPTIONS /addressbooks/users/ HTTP/1.1
Host: addressbook.example.com
				</artwork>
			</figure>
			<figure height="" suppress-title="false" width="" alt="" title="" align="left">
				<preamble>&gt;&gt; Response &lt;&lt;</preamble>
				<artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, COPY, MOVE
Allow: MKCOL, PROPFIND, PROPPATCH, LOCK, UNLOCK, REPORT, ACL
DAV: 1, 2, 3, access-control, extended-mkcol
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Length: 0
				</artwork>
			</figure>
		</section>
</section>
      <section title="Status Codes" toc="default">
        <t>
          As per Section 9.3.1 of <xref target="RFC4918" format="default" pageno="false"/>.
        </t>
      </section><!-- Status Codes -->

      <section title="Additional Precondition for Extended MKCOL" toc="default">
        <t>
          WebDAV (<xref target="RFC4918" format="default" pageno="false"/>, Section 16) defines preconditions and postconditions for request behavior. This specification adds the following precondition for the extended MKCOL request.
        </t>
        <t>
            <list style="hanging">
                <t hangText="Name:">
                    valid-resourcetype
                </t>
                <t hangText="Namespace:">
                    DAV:
                </t>
                <t hangText="Use with:">
                    Typically 403 (Forbidden)
                </t>
                <t hangText="Purpose:">
                    (precondition) -- The server MUST support the specified resourcetype value for the specified collection.
                </t>
			</list>
        </t>
      </section><!-- Status Codes -->

      <section title="Example: Successful Extended MKCOL Request" toc="default">

        <t>
          This example shows how the extended MKCOL request is used to create a collection of a fictitious type "special-resource".
        </t>

        <figure height="" suppress-title="false" width="" alt="" title="" align="left">
          <preamble>&gt;&gt; Request &lt;&lt;</preamble>
          <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
MKCOL /home/special/ HTTP/1.1
Host: special.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;D:mkcol xmlns:D="DAV:"
              xmlns:E="http://example.com/ns/"&gt;
  &lt;D:set&gt;
    &lt;D:prop&gt;
      &lt;D:resourcetype&gt;
        &lt;D:collection/&gt;
        &lt;E:special-resource/&gt;
      &lt;/D:resourcetype&gt;
      &lt;D:displayname&gt;Special Resource&lt;/D:displayname&gt;
    &lt;/D:prop&gt;
  &lt;/D:set&gt;
&lt;/D:mkcol&gt; 
          </artwork>
        </figure>
        <figure height="" suppress-title="false" width="" alt="" title="" align="left">
          <preamble>&gt;&gt; Response &lt;&lt;</preamble>
          <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
HTTP/1.1 201 Created
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;D:mkcol-response xmlns:D="DAV:"&gt;
  &lt;D:propstat&gt;
    &lt;D:prop&gt;
      &lt;D:resourcetype/&gt;
      &lt;D:displayname/&gt;
    &lt;/D:prop&gt;
    &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
  &lt;/D:propstat&gt;
&lt;/D:mkcol-response&gt; 
          </artwork>
        </figure>
      </section>

    </section>
    <section title="Replacing Existing MKxxx Methods" toc="default">
      <t>One of the goals of this extension is to eliminate the need for other extensions to define their own variant of MKCOL to create the special collections they need. This extension can be used to replace existing MKxxx methods in other extensions as detailed below. If a server supports this extension and the other extension listed, then the server MUST support use of the extended MKCOL method to achieve the same result as the MKxxx method of the other extension.</t>
      <section title="MKCALENDAR Replacement" toc="default">
        <t>CalDAV defines the MKCALENDAR method to create a calendar collection as well as set properties during creation (<xref target="RFC4791" format="default" pageno="false"/>, Section 5.3.1).</t>
        <t>The extended MKCOL method can be used instead by specifying both DAV:collection and CALDAV:calendar-collection XML elements in the DAV:resourcetype property, set during the extended MKCOL request.</t>
      <section title="Example: Replacing MKCALENDAR with MKCOL" toc="default">
        <t>
          The first example below shows an MKCALENDAR request containing a CALDAV:mkcalendar XML element in the request body, and returning a CALDAV:mkcalendar-response XML element in the response body. The second example shows the equivalent extended MKCOL request with the same request and response XML elements.
        </t>
        <figure height="" suppress-title="false" width="" alt="" title="" align="left">
          <preamble>&gt;&gt; MKCALENDAR Request &lt;&lt;</preamble>
          <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
MKCALENDAR /home/lisa/calendars/events/ HTTP/1.1
Host: calendar.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;C:mkcalendar xmlns:D="DAV:"
              xmlns:C="urn:ietf:params:xml:ns:caldav"&gt;
  &lt;D:set&gt;
    &lt;D:prop&gt;
      &lt;D:displayname&gt;Lisa's Events&lt;/D:displayname&gt;
    &lt;/D:prop&gt;
  &lt;/D:set&gt;
&lt;/C:mkcalendar&gt; 
          </artwork>
        </figure>
        <figure height="" suppress-title="false" width="" alt="" title="" align="left">
          <preamble>&gt;&gt; MKCALENDAR Response &lt;&lt;</preamble>
          <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
HTTP/1.1 201 Created
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;C:mkcalendar-response xmlns:D="DAV:"
              xmlns:C="urn:ietf:params:xml:ns:caldav"&gt;
  &lt;D:propstat&gt;
    &lt;D:prop&gt;
      &lt;D:displayname/&gt;
    &lt;/D:prop&gt;
    &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
  &lt;/D:propstat&gt;
&lt;/C:mkcalendar-response&gt; 
          </artwork>
        </figure>
        <figure height="" suppress-title="false" width="" alt="" title="" align="left">
          <preamble>&gt;&gt; MKCOL Request &lt;&lt;</preamble>
          <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
MKCOL /home/cyrus/calendars/events/ HTTP/1.1
Host: calendar.example.com
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;D:mkcol xmlns:D="DAV:"
              xmlns:C="urn:ietf:params:xml:ns:caldav"&gt;
  &lt;D:set&gt;
    &lt;D:prop&gt;
      &lt;D:resourcetype&gt;
        &lt;D:collection/&gt;
        &lt;C:calendar/&gt;
      &lt;/D:resourcetype&gt;
      &lt;D:displayname&gt;Cyrus' Events&lt;/D:displayname&gt;
    &lt;/D:prop&gt;
  &lt;/D:set&gt;
&lt;/D:mkcol&gt; 
          </artwork>
        </figure>
        <figure height="" suppress-title="false" width="" alt="" title="" align="left">
          <preamble>&gt;&gt; MKCOL Response &lt;&lt;</preamble>
          <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
HTTP/1.1 201 Created
Cache-Control: no-cache
Date: Sat, 11 Nov 2006 09:32:12 GMT
Content-Type: application/xml; charset="utf-8"
Content-Length: xxxx

&lt;?xml version="1.0" encoding="utf-8" ?&gt;
&lt;D:mkcol-response xmlns:D="DAV:"
              xmlns:C="urn:ietf:params:xml:ns:caldav"&gt;
  &lt;D:propstat&gt;
    &lt;D:prop&gt;
      &lt;D:resourcetype/&gt;
      &lt;D:displayname/&gt;
    &lt;/D:prop&gt;
    &lt;D:status&gt;HTTP/1.1 200 OK&lt;/D:status&gt;
  &lt;/D:propstat&gt;
&lt;/D:mkcol-response&gt; 
          </artwork>
        </figure>
      </section>
      </section>
    </section>
    <section title="XML Element Definitions" toc="default">
      <section title="mkcol XML Element" toc="default">
        <t>
            <list style="hanging">
                <t hangText="Name:">
                    mkcol
                </t>
                <t hangText="Namespace:">
                    DAV:
                </t>
                <t hangText="Purpose:">
                    Used in a request to specify properties to be set in an extended MKCOL request, as well as any additional information needed when creating the resource.
                </t>
                <t hangText="Description:">
                    This XML element is a container for the information required to modify the properties on a collection resource as it is created in an extended MKCOL request.
                </t>
                <t hangText="Definition:">
                    <figure height="" suppress-title="false" width="" alt="" title="" align="left">
                        <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
    &lt;!ELEMENT mkcol (set+)&gt;
                        </artwork>
                    </figure>
                </t>
            </list>
        </t>
      </section>
      <section title="mkcol-response XML Element" toc="default">
        <t>
            <list style="hanging">
                <t hangText="Name:">
                    mkcol-response
                </t>
                <t hangText="Namespace:">
                    DAV:
                </t>
                <t hangText="Purpose:">
                    Used in a response to indicate the status of properties that were set or failed to be set during an extended MKCOL request.
                </t>
                <t hangText="Description:">
                    This XML element is a container for the information returned about a resource that has been created in an extended MKCOL request.
                </t>
                <t hangText="Definition:">
                    <figure height="" suppress-title="false" width="" alt="" title="" align="left">
                        <artwork height="" name="" width="" type="" alt="" align="left" xml:space="preserve">
    &lt;!ELEMENT mkcol-response (propstat+, ANY)&gt;
                        </artwork>
                    </figure>
                </t>
            </list>
        </t>
      </section>
    </section>
    <section title="Security Considerations" toc="default">
      <t>
        This extension does not introduce any new security concerns beyond those already described in HTTP and WebDAV. 
      </t>
    </section>
    <section title="IANA Considerations" toc="default">
      <t>
        This document does not require any actions on the part of IANA. 
      </t>
    </section>
    <section title="Acknowledgments" toc="default">
      <t>
        Several people suggested this approach, including Julian Reschke and Bernard Desruisseaux. Thanks also to Mike Douglass.
      </t>
    </section>
  </middle>
  <back>
    <references title="Normative References">
      

<reference anchor="RFC2119">

<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   In many standards track documents several words are used to signify
   the requirements in the specification.  These words are often
   capitalized.  This document defines these words as they should be
   interpreted in IETF documents.  Authors who follow these guidelines
   should incorporate this phrase near the beginning of their document:

<list>
<t>
      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.
</t></list></t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t></abstract></front>

<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="14486" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5661" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
 
      

<reference anchor="RFC2616">

<front>
<title abbrev="HTTP/1.1">Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding">
<organization abbrev="UC Irvine">Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials="J." surname="Gettys" fullname="James Gettys">
<organization abbrev="Compaq/W3C">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials="J." surname="Mogul" fullname="Jeffrey C. Mogul">
<organization abbrev="Compaq">Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials="H." surname="Frystyk" fullname="Henrik Frystyk Nielsen">
<organization abbrev="MIT/LCS">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials="L." surname="Masinter" fullname="Larry Masinter">
<organization abbrev="Xerox">Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials="P." surname="Leach" fullname="Paul J. Leach">
<organization abbrev="Microsoft">Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
<organization abbrev="MIT/LCS">World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year="1999" month="June"/>
<abstract>
<t>
   The Hypertext Transfer Protocol (HTTP) is an application-level
   protocol for distributed, collaborative, hypermedia information
   systems. It is a generic, stateless, protocol which can be used for
   many tasks beyond its use for hypertext, such as name servers and
   distributed object management systems, through extension of its
   request methods, error codes and headers . A feature of HTTP is
   the typing and negotiation of data representation, allowing systems
   to be built independently of the data being transferred.
</t>
<t>
   HTTP has been in use by the World-Wide Web global information
   initiative since 1990. This specification defines the protocol
   referred to as "HTTP/1.1", and is an update to RFC 2068 .
</t></abstract></front>

<seriesInfo name="RFC" value="2616"/>
<format type="TXT" octets="422317" target="ftp://ftp.isi.edu/in-notes/rfc2616.txt"/>
<format type="PS" octets="5529857" target="ftp://ftp.isi.edu/in-notes/rfc2616.ps"/>
<format type="PDF" octets="550558" target="ftp://ftp.isi.edu/in-notes/rfc2616.pdf"/>
<format type="HTML" octets="528063" target="http://xml.resource.org/public/rfc/html/rfc2616.html"/>
<format type="XML" octets="476536" target="http://xml.resource.org/public/rfc/xml/rfc2616.xml"/>
</reference>

      

<reference anchor="RFC4791">

<front>
<title abbrev="CalDAV">Calendaring Extensions to WebDAV (CalDAV)</title>
<author initials="C." surname="Daboo" fullname="Cyrus Daboo">
<organization abbrev="Apple">Apple Inc.</organization>
<address>
<postal>
<street>1 Infinite Loop</street>
<city>Cupertino</city>
<region>CA</region>
<code>95014</code>
<country>USA</country></postal>
<email>cyrus@daboo.name</email>
<uri>http://www.apple.com/</uri></address></author>
<author initials="B." surname="Desruisseaux" fullname="Bernard Desruisseaux">
<organization abbrev="Oracle">Oracle Corporation</organization>
<address>
<postal>
<street>600 Blvd. de Maisonneuve West</street>
<street>Suite 1900</street>
<city>Montreal</city>
<region>QC</region>
<code>H3A 3J2</code>
<country>CANADA</country></postal>
<email>bernard.desruisseaux@oracle.com</email>
<uri>http://www.oracle.com/</uri></address></author>
<author initials="L.M." surname="Dusseault" fullname="Lisa Dusseault">
<organization abbrev="CommerceNet">CommerceNet</organization>
<address>
<postal>
<street>169 University Ave.</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>USA</country></postal>
<email>ldusseault@commerce.net</email>
<uri>http://commerce.net/</uri></address></author>
<date year="2007" month="March"/>
<area>Applications</area>
<keyword>calsched</keyword>
<keyword>calsch</keyword>
<keyword>caldav</keyword>
<keyword>calendar</keyword>
<keyword>calendaring</keyword>
<keyword>scheduling</keyword>
<keyword>webdav</keyword>
<keyword>iCal</keyword>
<keyword>iCalendar</keyword>
<keyword>iTIP</keyword>
<keyword>text/calendar</keyword>
<keyword>HTTP</keyword>
<abstract>
<t>
      This document defines extensions to the Web Distributed Authoring
      and Versioning (WebDAV) protocol to specify a standard way of
      accessing, managing, and sharing calendaring and scheduling
      information based on the iCalendar format. This document
	  defines the "calendar-access" feature of CalDAV.
    </t></abstract></front>

<seriesInfo name="RFC" value="4791"/>
<format type="TXT" octets="206801" target="ftp://ftp.isi.edu/in-notes/rfc4791.txt"/>
<format type="HTML" octets="300292" target="http://xml.resource.org/public/rfc/html/rfc4791.html"/>
<format type="XML" octets="265793" target="http://xml.resource.org/public/rfc/xml/rfc4791.xml"/>
</reference>

      

<reference anchor="RFC4918">

<front>
<title>HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)</title>
<author initials="L." surname="Dusseault" fullname="L. Dusseault">
<organization/></author>
<date year="2007" month="June"/>
<abstract>
<t>Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).&lt;/t&gt;&lt;t&gt; RFC 2518 was published in February 1999, and this specification obsoletes RFC 2518 with minor revisions mostly due to interoperability experience. [STANDARDS TRACK]</t></abstract></front>

<seriesInfo name="RFC" value="4918"/>
<format type="TXT" octets="276352" target="ftp://ftp.isi.edu/in-notes/rfc4918.txt"/>
</reference>

      

<reference anchor="W3C.REC-xml-20060816" target="http://www.w3.org/TR/2006/REC-xml-20060816">
<front>
<title>Extensible Markup Language (XML) 1.0 (Fourth Edition)</title>

<author initials="E." surname="Maler" fullname="Eve Maler">
    <organization/>
</author>

<author initials="J." surname="Paoli" fullname="Jean Paoli">
    <organization/>
</author>

<author initials="F." surname="Yergeau" fullname="François Yergeau">
    <organization/>
</author>

<author initials="C." surname="Sperberg-McQueen" fullname="C. M. Sperberg-McQueen">
    <organization/>
</author>

<author initials="T." surname="Bray" fullname="Tim Bray">
    <organization/>
</author>

<date month="August" day="16" year="2006"/>
</front>

<seriesInfo name="World Wide Web Consortium Recommendation" value="REC-xml-20060816"/>
<format type="HTML" target="http://www.w3.org/TR/2006/REC-xml-20060816"/>
</reference>

    </references>
    <!--<references title='Informative References'>
    </references>-->

<section title="Change History (to be removed prior to publication as an RFC)" toc="default">

<t>Changes from -01:
<list style="numbers">
<t>Minor formatting/wording changes proposed by Julian Reschke were applied.</t>
<t>Removed reference to DeltaV entirely as the spec no longer replaces the MKxxx DeltaV defines.</t>
<t>Added Namespace definition to precondition.</t>
<t>Added reference to 4918 XML extensibility rules.</t>
<t>Added statement that DAV:collection must be present in DAV:resourcetype in the request.</t>
<t>Added statement on use of DTD fragments.</t>
<t>Added statement about setting proper Content-Type for the MKCOL body.</t>
<t>Added statement that MKCOL bodies using a different root element are reserved for future extensions.</t>
</list>
</t>

<t>Changes from -00:
<list style="numbers">
<t>Fixed an example.</t>
</list>
</t>

<t>Changes from draft-daboo-webdav-mkcol-00:
<list style="numbers">
<t>Removed MKACTIVITY and MKWORKSPACE replacement behavior.</t>
<t>Added valid-resourcetype precondition.</t>
</list>
</t>

</section>

  </back>
</rfc>