Network Working Group John Stracke, eCal Internet-Draft draft-stracke-webdav-mime-resource-00.txt Expires six months after: 25 Feb. 1999 Encoding a DAV resource in MIME Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, andits 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. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a "working draft" or "work in progress". To view the entire list of current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Distribution of this document is unlimited. Copyright (C) The Internet Society 1999. All Rights Reserved. Abstract This memo proposes a mechanism for representing a [WEBDAV] resource as a MIME entity, bundling together the resource's body, properties, and member resources. Table of Contents 1. Introduction 2. XML Syntax 2.1 2.2 2.3 2.4 3. Use of multipart/related 4. Examples 4.1 An XML resource with an inline body 4.2 A GIF resource with an external body 4.3 A collection, containing three external HTML pages 4.4 A reference 5. Use with MKCOL 6. Acknowledgments 7. Security Considerations 8. Bibliography 9. Author's Address 10. Full Copyright Statement 1. Introduction [WEBDAV] defines behavior for HTTP resources beyond that defined in [HTTP1.1]; this behavior includes storing metainformation (called "properties", and formatted as [XML]) and being able to list the members of collection resources (which correspond to subdirectories in a filesystem). In some applications, it will be useful to be able to encapsulate all aspects of such an enhanced resource into a single document; for example, if a DAV server implementor wishes to support cross-server COPY, it will be most efficient if there is some way to deliver the resource being copied to the destination server in a single operation. This memo proposes an [XML] syntax for describing a resource, and a profile for bundling the description together with the resource's MIME content into a multipart/related entity ([RFC-2387]). 2. XML Syntax (Author's note: the following is an informal description of the proposed syntax. A DTD can be created if and when necessary.) 2.1 The description of a DAV resource is represented by an XML element (where DAV: represents the same namespace as in [WEBDAV]). A element may contain the following elements (each is optional; none may appear more than once): as defined in [WEBDAV]; represents properties of the resource defined below defined below as defined in [WEBDAV]; used only in a contained in a . Must be a relative URI with no path separators. Represents the URI of the resource, relative to the URI of the resource described by the enclosing . a 2.2 A element supplies a MIME entity which is to constitute the resource's body (that is, the entity which would be supplied in response to a successful GET). It may contain either a element ([WEBDAV]), which supplies a URI for an external entity, or a (below), which supplies XML for an inline XML entity. These two are mutually exclusive. Note that it is legal for a to contain both a and a , since GET on a collection resource is legal (and quite common). If this is the case, and the also contains a member resource which might otherwise be provided in response to GET (e.g., a resource whose relative href is "index.html"), then the MUST take precedence over the member resource. (This is to ensure predictability: if a server is provided with a representing a collection, the creator of the collection may not know which relative hrefs the server recognizes as default documents.) 2.3 A is used to include an XML document in the resource description, rather than referring to an external entity. When is used, it means that the resource's body is the contents of the element. The element may have a "type" attribute, which corresponds to a Content-type header on the entity (this is necessary because an XML document may be either text/xml or application/xml). 2.4 A element lists the member resources of a collection. A element MUST NOT be present if the element specifies (via DAV:resourcetype) that the resource is not a collection. The element contains zero or more elements which describe the collection's member resources. 3. Use of multipart/related A multipart/related entity may be used to bundle the description of a resource with entities representing the body of the resource and its members (if applicable). In this case, elements may use cid: URIs to refer to body parts of the multipart/related. 4. Examples (DUBLIN: properties are Dublin Core metadata, as described in [DUBLIN] and [DUBLIN-DAV].) 4.1 An XML resource with an inline body text/xml Moonlight and Vines Charles de Lint Sweetgrass & City Streets ... Saskia ... In This Soul Of A Woman ... ... 4.2 A GIF resource with an external body image/gif IETF Logo http://www.ietf.org/images/ietflogo2e.gif 4.3 A collection, containing three external HTML pages IETF Home Page http://www.ietf.org/index.html index.html IETF Overview http://www.ietf.org/overview.html overview.html IESG http://www.ietf.org/iesg.html iesg.html 4.4 A reference Note that this resource does not have a body; it is defined wholly by its properties. http://www.ietf.org 5. Use with MKCOL [WEBDAV] specifies that MKCOL may have a request body, but does not specify any legal formats. The syntax defined in this memo could be used for a MKCOL request body; by submitting either a or a multipart/related containing a , a client could provide the complete contents of a collection to be created. 6. Acknowledgments The impetus for this memo was a discussion with Geoff Clemm on the WebDAV mailing list about the best way to represent structured documents. 7. Security Considerations Security issues are not discussed in detail in this memo. This memo describes only a means of encoding data which is already present in WebDAV; it does not introduce any new security risks beyond those of WebDAV itself. 8. Bibliography [WEBDAV] E. Whitehead, A. Faizi, S. Carter, and D. Jensen, "HTTP Extensions for Distributed Authoring -- WEBDAV", RFC 2518, ftp://ftp.isi.edu/in-notes/rfc2518.txt, February 1999. [HTTP1.1] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, ftp://ftp.isi.edu/in-notes/rfc2068.txt, January 1997. [XML] T. Bray, J. Paoli, C. M. Sperberg-McQueen, "Extensible Markup Language (XML)" World Wide Web Consortium Recommendation REC- xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210. [RFC-2387] E. Levinson, "The MIME Multipart/Related Content-type", RFC 2387, ftp://ftp.isi.edu/in-notes/rfc2387.txt, August 1998. [DUBLIN] S. Weibel, J. Kunze, C. Lagoze, and M. Wolf, "Dublin Core Metadata for Resource Discovery", RFC 2413, ftp://ftp.isi.edu/in-notes/rfc2413.txt, September 1998. [DUBLIN-DAV] J. Stracke, "Use of Dublin Core Metadata in WebDAV", Internet-Draft, http://www.ietf.org/internet-drafts/draft-ietf-webdav-dublin-core-00.txt, October 1998. 9. Author's Address The following address information is provided in a vCard v3.0, Electronic Business Card, format. begin:vcard n:Stracke;John tel;home:610-519-1215 tel;work:215-574-4900x27 x-mozilla-html:TRUE url:http://www.ecal.com org:eCal, Inc. version:2.1 email;internet:francis@appoint.net title:Chief Scientist adr;quoted-printable:;;234 N Columbus Blvd.=0D=0A3rd Floor;Philadelphia;PA;19106-1401;USA fn:John Stracke end:vcard 10. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process MUST be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.