INTERNET-DRAFT R Jones Intended Status: Experimental (OneOverZero/SWORD) Expires: September 2011 Marchs 2011 SWORD 001 Packaged Content Delivery over HTTP Status of this Memo This memo defines an Experimental Protocol for the Internet community. This memo does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. Copyright and License Notice Copyright (C) SWORD (2011). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to SWORD, 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 SWORD or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and SWORD 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. R Jones Expires September 2011 [Page 1] SWORD 001 Packaged Content Delivery March 2011 Abstract Often in information systems there is a requirement to move content between applications and servers in groups of files and associated metadata. This document describes HTTP Headers and Media Features to aid this process over HTTP. Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Packaging . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 Accept-Packaging . . . . . . . . . . . . . . . . . . . . . . . . 3 4 On-Behalf-Of . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5 In-Progress . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6 Suppress-Metadata . . . . . . . . . . . . . . . . . . . . . . . . 4 7 Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8.1 Packaging . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.2 Accept-Packaging . . . . . . . . . . . . . . . . . . . . . . 6 8.3 On-Behalf-Of . . . . . . . . . . . . . . . . . . . . . . . . 6 8.3 In-Progress . . . . . . . . . . . . . . . . . . . . . . . . 6 8.4 Suppress-Metadata . . . . . . . . . . . . . . . . . . . . . 7 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1 Normative References . . . . . . . . . . . . . . . . . . . 7 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 R Jones Expires September 2011 [Page 2] SWORD 001 Packaged Content Delivery March 2011 1 Introduction This specification describes HTTP headers and Media Features to enhance the delivery of packaged content over HTTP to document servers and similar systems from client software. 1.1 Terminology 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]. 1.2 Notation The version of BNF used in this document is taken from [RFC2068], and many of the nonterminals used are defined there. Note that the underlying charset is US-ASCII. 2 Packaging The Packaging header is constructed as follows: Packaging = "Packaging" ":" packaging-expression packaging-expression = token | quoted-string | absoluteURI Note that token, quoted-string and absoluteURI are defined in [RFC2068]. For example: Packaging: http://purl.org/net/terms/package/default The Packaging request header SHOULD be used by the user agent during HTTP POST to give information to the server about the packaging format used to construct the content being POSTed or PUT. Servers SHOULD use this information to unpack the supplied content into its component parts. If the server does not understand the package format it MUST either store the content as delivered without unpacking or respond with 415 (Unsupported Media Type). 3 Accept-Packaging The Accept-Packaging header is constructed as follows: Accept-Packaging = "Accept-Packaging" ":" packaging-expression packaging-expression = token | quoted-string | absoluteURI R Jones Expires September 2011 [Page 3] SWORD 001 Packaged Content Delivery March 2011 Note that token, quoted-string and absoluteURI are defined in [RFC2068]. For example: Accept-Packaging: http://purl.org/net/terms/package/default The Accept-Packaging request header SHOULD be used by the user agent during HTTP GET to indicate to the server the package format that the content identified by the URI should be returned in. Servers MUST either return the content in the specified format or return a 406 Not Acceptable. 4 On-Behalf-Of The On-Behalf-Of request header MAY be used by the user agent to alert the server as to the identity of the true owner of the content during PUT, POST, DELETE and GET. Traditional HTTP authentication is insufficient in this regard as it is possible that content will be delivered machine-to-machine and the authenticating user will be the user agent not the content owner. Servers SHOULD use this information to determine whether and how they accept the content. On-Behalf-Of = "On-Behalf-Of" ":" (token | quoted-string) For example: Authorization: Basic [digested auth information for user agent] On-Behalf-Of: jbloggs 5 In-Progress The In-Progress request header MAY be used by the user agent to inform the server that the current content payload is not yet complete in some unspecified way during PUT, POST or DELETE. For example, there may by further content packages that the user agent plans to deliver to the server before the full content has been delivered, or the user agent may need to carry out other actions against the server before confirming that the server can proceed to fully process the content. Exact interpretation of this header is left to the server, so it is necessary that server/client pairs will have to have a common understanding of its meaning which is beyond the scope of this document. In-Progress = "In-Progress" ":" ("true" | "false") 6 Suppress-Metadata R Jones Expires September 2011 [Page 4] SWORD 001 Packaged Content Delivery March 2011 The Suppress-Metadata request header MAY be used by the user agent to instruct the server not to attempt to extract metadata from the supplied content package, during PUT, POST or DELETE. Content packages commonly contain both file content and metadata about its contents, and during unpacking servers may process this metadata in a way which is meaningful to them. This directive allows the user agent to suppress that behaviour for its own purposes. Furthermore, a DELETE operation may be requested which removes content previously delivered from the server, and in this case the header instructs the server to retain a copy of the metadata while deleting the content. Suppress-Metadata = "Suppress-Metadata" ":" ("true" | "false") R Jones Expires September 2011 [Page 5] SWORD 001 Packaged Content Delivery March 2011 7 Security Considerations This document is based on HTTP and thus subject to the security considerations found in Section 15 of [RFC2068]. 8 IANA Considerations This document specifies 5 new message headers which conform to the registry mechanism for provisional message headers in [RFC3864] and one new media feature which conforms to the URI tree registry mechanism in [RFC2506]. 8.1 Packaging Header field name: Packaging Applicable protocol: HTTP Status: provisional Author/Change controller: Richard Jones c/o UKOLN, University of Bath; richard@swordapp.org 8.2 Accept-Packaging Header field name: Accept-Packaging Applicable protocol: HTTP Status: provisional Author/Change controller: Richard Jones c/o UKOLN, University of Bath; richard@swordapp.org 8.3 On-Behalf-Of Header field name: On-Behalf-Of Applicable protocol: HTTP Status: provisional Author/Change controller: Richard Jones c/o UKOLN, University of Bath; richard@swordapp.org 8.3 In-Progress R Jones Expires September 2011 [Page 6] SWORD 001 Packaged Content Delivery March 2011 Header field name: In-Progress Applicable protocol: HTTP Status: provisional Author/Change controller: Richard Jones c/o UKOLN, University of Bath; richard@swordapp.org 8.4 Suppress-Metadata Header field name: Packaging Applicable protocol: HTTP Status: provisional Author/Change controller: Richard Jones c/o UKOLN, University of Bath; richard@swordapp.org 9 References 9.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2533] Klyne, G. "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, September 2004. [RFC2506] Holtman, et. al. "Media Feature Tag Registration Procedure", RFC 2506, March 1999 Author's Addresses Richard Jones c/o UKOLN University of Bath R Jones Expires September 2011 [Page 7] SWORD 001 Packaged Content Delivery March 2011 EMail: richard@swordapp.org R Jones Expires September 2011 [Page 8]