SWORD APP Profile 0.5
From DigiRepWiki
This profile has been replaced by the most recent version: http://purl.org/net/sword/
SWORD Profile of the Atom Publishing Protocol
Version 0.5, created 11th July 2007.
Introduction
This document is a profile of the Atom Publishing Protocol (APP). APP is an application-level protocol for publishing and editing Web resources. The APP is based on HTTP transfer of Atom-formatted representations. This Profile specifies a subset of elements from the APP for use in depositing content into information systems, such as repositories. The Profile also specifies a number of element extensions to APP, defined to adhere to the extensions mechanism outlined in APP. This profile also makes use of the Atom Syndication Format (ATOM) as used in APP, with extensions.
This profile has been produced to support the work of the JISC-funded SWORD project.
Document 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 (see APP).
SWORD Profile of APP elements
The following section identifies the elements of APP which are implemented by SWORD and those which are not. It also provides additional requirements and recommendations, and identifies SWORD extensions to APP, using elements from other namespaces and elements from the sword namespace.
The section is organised according to the sections of the APP document.
5. Protocol Operations
5.1 Retrieving a Service Document
SWORD supports the use of HTTP GET requests.
GET to Service Document
In addition, SWORD defines an additional HTTP header 'X-On-Behalf-Of' used to specify the username of a target user on whose behalf a deposit is being made.
GET to Service Document X-On-Behalf-Of: on-behalf-of-user
This facilitates the SWORD requirement to support mediated deposits. See also the notes about Authentication below (relating to APP section 14). In this case, the returned Service Document SHOULD identify only those collections to which the target user is able to deposit. If the target repository does not support mediated deposit, the returned Service Document SHOULD contain a <sword:mediation> extension element with a value of false.
5.2 Listing Collections - NOT USED
5.3 Creating a Resource
SWORD supports the use of HTTP POST.
POST to URI of Collection
201 Created Location: Member Entry URI
See further refinements to the SWORD use of HTTP POST in APP Section 9.
5.4 Editing a Resource - NOT USED
5.5 use of HTTP Response Codes
SWORD supports the use of the following HTTP response codes. Implementers MUST support the following codes. It is RECOMMENDED that human-readable explanations are supplied along with HTTP response codes. A number of additional error codes have been defined for use with any of the following error codes. SEE SWORD Extensions to the APP.
- 201 Created - indicates that a deposit was successful and has been added into some part of the repository workflow.
- 202 Accepted - indicates that the deposit was successful and has been accepted pending checking by the repository.
- 400 Bad Request - indicates that there is some problem with the structure of the request.
- 401 Unauthorized - indicates that the is not authorised to deposit in the specified collection.
- 403 Forbidden - indicates that there was a problem making the deposit, it may be that the depositor is not authorised to deposit on behalf of the target owner, or the target owner does not have permission to deposit into the specified collection.
- 412 Precondition failed - indicates a checksum mismatch.
- level 0 implementations MAY, and level 1 implementations MUST return a 412 if the MD5 checksum does not match.
- 415 Unsupported Media Type - indicates that the format supplied in not accepted by the repository.
- level 0 implementations MAY, and level 1 implementations MUST return a 415 if the content-type supplied is not supported by the server.
- 500 Internal Server Error -
- level 1 implementations SHOULD return a 500 for any other error.
- 501 Not implemented - indicates that the supplied URI has been allocated to the item, but cannot yet be dereferenced
7. Category Documents - NOT USED
8. Service Documents
In line with APP, a service document (<app:service>) is identified with the "application/atomsvc+xml" media type.
8.1 Workspaces
The SWORD profile supports the APP definition of a Workspace.
For this profile, a Workspace is defined as an arbitrary aggregation of collections of resources.
For the SWORD profile one or more <app:collection> elements SHOULD be present. The absence of any <app:collection> elements implies that the authenticated user does not have permission to deposit.
For level 1 compliance the <app:accept> element MUST be used to specify accepted media-ranges. It is anticipated that these ranges MAY include media ranges relating to accepted packaging formats, e.g. application/zip, application/xml. SWORD also specifies an extension point for supplying a namespace for a specific deposit format.
Implementers SHOULD support application/zip used for simple cases of deposit of a document and some metadata, it is anticipated that the following packaging formats MAY be supported:
- IMS content packaging
- METS
- DIDL
The SWORD profile supports the element definitions identified at 8.3.1, 8.3.2, 8.3.2.1, 8.3.3, 8.3.3.2, 8.3.3.3, 8.3.4. SWORD defines the following extensions to the <app:collection> element:
<sword:collectionPolicy> - text/URI <dcterms:abstract> - text/URI <sword:mediation> - true|false <sword:treatment> - text <sword:formatNamespace> - URI
and the following extensions to the <app:service> element:
<sword:verbose> - true|false <sword:noOp> - true|false <sword:level> - 0|1
Consult the SWORD extensions to the APP for further definitions and usage guidelines.
8.3.5 - NOT USED
9. Creating and Editing Resources
9.1 Member URIs
SWORD supports Member URIs.
9.2 Creating resources with POST
SWORD supports the APP use of 'POST to URI of collection' as outlined in section 9.6 of the APP. Additionally SWORD uses a set of SWORD-defined HTTP headers to supply additional parameters with the POST. The following headers are defined:
X-On-Behalf-Of: on-behalf-of-user X-Verbose: true|false X-No-Op: true|false X-Format-Namespace: format-namespace-uri
Consult the SWORD extensions to the APP for further definitions and usage guidelines.
9.3 Updating Resources with PUT - NOT USED
9.4 Deleting Resources with DELETE - NOT USED
9.5 Caching and entity tags - NOT USED
9.6 Media Resources and Media Link Entries
SWORD supports the APP mechanism for posting media types other than appliation/atom+xml to a Collection. Implementers are recommended to pay particular attention to section 9.6 of the APP.
SWORD makes the following additional recommendations:
For level 1 compliance the server MUST signal the media types it will accept using the app:accept element in the Service Document, as specified in Section 8.3.4.
The Location: element of the HTTP header response MUST contain a URI for the Media Link Entry. The Media Link Entry is the Atom Entry Document created for the deposit and returned with the response. This MUST be a unique identifier.
The <atom:id> element MUST contain a unique identifier for the deposit; this MAY be supplied by the deposit client using the Slug header. For level 1 compliance this identifier MUST be stored within the metadata associated with that deposit, but there is no requirement for the server to make further use of this identifier.
According to APP, The Media Link Entry MUST contain an <atom:content> element with a src attribute containing a URI for the deposited Media Resource (the deposited package). For SWORD implementations, this URI SHOULD identify the original deposited package. It MAY dereference to the package.
According to APP, an <atom:link> element SHOULD be supplied with a rel="edit-media" attribute and a href attribute containing a URI for the Media Resource. It is OPTIONAL that this URI be the same as that supplied as the src attribute of the <atom:content> element. SWORD makes no further recommendations about what this link element should resolve to; examples might include a representation which supplies metadata from the package and access to unpacked binary files. Alternatively, a repository might supply multiple <atom:link> elements to identify each unpacked resource.
According to APP, an <atom:link> element MAY be supplied with a rel="edit" attribute and a href attribute containing a URI for the Media Link Entry metadata. SWORD makes no further recommendations about what this link element should resolve to; examples might include a jump-off page, users private metadata or workflow management page. This link MAY allow authorized users to make further edits to the atom, or other, metadata.
Wherever practical, URIs SHOULD dereference to a logical location, SHOULD be unique and SHOULD persist.
Where URIs do not dereference a 501 Not Implemented HTTP error code SHOULD be returned, with a human-readable explanation.
9.7 The Slug: Header
The SWORD Profile does not require the use of The Slug header at level 0. For level 1 compliance the Slug header SHOULD be used to supply a deposit identifier, for use by but as the <atom:id> value. For level 0 compliance servers MAY choose to ignore the header or alter its value.
The Atom Entry Document
On successfully accepting a POST (deposit), implementers MUST return an Atom Entry Document with the HTTP response.
The following elements are mandatory in the Atom Entry Document (as specified by ATOM) and thus are also mandatory for SWORD level 0. The <atom:author> element should be used for a username or similar for the depositor. The <atom:content> and <atom:id> elements should be used as outlined above.
<atom:id> <atom:author> <atom:title> <atom:updated> <atom:content>
For full SWORD level 1 compliance the Atom Entry Document MAY contain the following extensions; it MUST contain treatment, source/generator and formatNamespace:
<atom:contributor>
<atom:source>
<atom:generator> - id of the source repository
<sword:treatment> - text
<sword:verboseDescription> - text description
<sword:noOp> - true/false (true = no action has been taken;
false = deposit has been made as requested)
<sword:formatNamespace> - uri for the format namespace
Consult the SWORD extensions to the APP for further definitions and usage guidelines.
10. Listing Collections - Not Used
- APP states that "Collection Resources MUST provide representations in the form of Atom Feed couments whose Entries contain the IRIs of Members in the Collection".
- The SWORD profile does not require Collection lists, but implementers MAY wish to support this feature in order to be APP compliant.
10.1 Collection partial lists - NOT USED
- see notes above - implementers MAY wish to use Collection partial lists.
10.2 The "app:edited" Element - NOT USED
11. Atom Format
The SWORD Profile uses the "edit" and "edit-media" link relations. The SWORD profile does not currently support edits or modification of deposited items, therefore a URI with an edit or edit-media link relation points to a Member Entry which MAY be editable, but is not required to be.
12. The Atom Format Type Parameter
The SWORD Profile uses the "entry" type parameter.
13. Publishing Controls - NOT USED
14. Securing the Atom Publishing Protocol
The SWORD Profile adheres to the statement: "At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC2617] in conjunction with a TLS connection as specified by [RFC2818]."
It is the responsibility of implementers to integrate existing authentication solutions.
15. Security Considerations
The SWORD Profile recommends implementers refer to this section of APP.
Compliance
Compliance to APP and ATOM
The SWORD profile adds extensions to the APP to support a particular set of requirements for offering 'deposit' services. Update, delete and listing collections are out of scope for SWORD. Implementers of the SWORD profile of APP SHOULD aim to support all of the mandatory elements of APP. Implementers MAY wish to support additional APP functions and should refer to the APP specification for further details.
SWORD Compliance
SWORD identifies two levels of compliance.
Level 0 requires implementation of a minimal set of mandatory elements as defined below.
Full level 1 compliance REQUIRES implementation of the full set of extension elements and compliance with APP as indicated by the SWORD profile of APP specified in this document.
Implementers MUST as a minimum implement the APP sufficiently to support SWORD Level 0 Compliance. It is RECOMMENDED that implementers support Level 1 Compliance.
Level 0 compliance
Compliance to SWORD level 0 REQUIRES the use of only one sword 'extension' element, <sword:level>. This is used to indicate the compliance level. In more general terms, it indicates that the APP implementation is cognisant of the SWORD profile.
Mandatory elements for Level 0 compliance are listed below; M indicates mandatory APP/ATOM elements:
| SWORD parameter | APP element | Extension | In |
| Collection ID (M) | <app:collection href=""> (atom uri) | Service Document | |
| Deposit Status (M) | HTTP Status Code | HTTP Response | |
| Error Code (M) | HTTP Status Code | HTTP Response | |
| Error Description | with HTTP status code | HTTP Response | |
| Target Collection (M) | POST to URI of Collection | ||
| Identifier (URI) (M) |
Location: |
HTTP header (response> | |
| Transaction/deposit ID (M) | <atom:id> | Atom Entry Document (response) | |
| Server Level | <sword:level> | Service Document |
Level 1 compliance
These elements are mandatory for full level 1 compliance and optional for partial compliance; ; M indicates mandatory APP/ATOM elements:.
| SWORD parameter | APP element / HTTP header | Extension APP / HTTP header | In |
| Repository / Collection Name |
<app:collection> |
Service Document | |
| Repository / Collection Policy |
<sword:collectionPolicy> |
Service Document | |
| Collection Description |
<dcterms:abstract> |
Service Document | Accepted formats | <app:accept> | Service Document |
| Format Namespace | <sword:formatNamespace> | Service Document | |
| Format Namespace | X-Format-Namespace | HTTP header (POST) HTTP header (response) |
|
| Treatment Description |
<sword:treatment> |
Service Description Atom Entry Document (response) |
|
| Mediation Allowed |
<sword:mediation> |
Service Document | |
| Source Repository or Client |
<atom:source> |
Atom Entry Document (response) | |
| Checksum | Content-MD5: md5-digest | HTTP header (POST) | |
| On Behalf Of | X-On-Behalf-Of | GET Service Document HTTP header (POST) |
|
| On Behalf Of | <atom:contributor> | Atom Entry Document (response) | |
| Object URI (M) |
<atom:content src=""> |
Atom Entry Document (response) | |
| Display URI | <atom:link rel="edit" href""> | Atom Entry Document (response) | |
| Transaction/deposit ID (M) | The Slug: <atom:id> (M at Level 0) |
HTTP header (POST) Atom Entry Document (response) |
|
| Depositor | <atom:author> (M) | Atom Entry Document (response) | |
| Date of deposit | <atom:atom:updated>(M) | Atom Entry Document (response) |
Optional developers compliance
The following elements are optional.
| SWORD parameter | APP element / HTTP header | Extension APP / HTTP header | In |
| Verbose Supported |
<sword:verbose> |
Service Description | |
| NoOp Supported |
<sword:noOp> |
Service Description | |
| Verbose |
X-Verbose |
HTTP header (POST) | |
| Verbose Description |
<sword:verboseDescription> |
Atom Entry Document (response) | |
| NoOp | X-No-Op | HTTP header (POST) |
SWORD Conventions
SWORD RECOMMENDS that the APP implementation is accessed from /app (e.g. www.myrepository.ac.uk/app)
SWORD RECOMMENDS that the service document is is accessed from /app/servicedocument (e.g. www.myrepository.ac.uk/app/servicedocument)
Authentication and Mediation
There are four possible use cases for mediated and non-mediated deposit:
- unauthenticated POSTs
- authenticated POSTs by the author/owner, i.e. that don't use X-On-Behalf-Of
- authenticated POSTs that use X-On-Behalf-Of, and the authenticated user is a "Person construct" (meditated deposit)
- authenticated POSTs that use X-On-Behalf-Of, but where the authenticated user is not a "Person construct" (mediated deposit)
For case (2), the <atom:author> element MAY be used to capture a name or username for the authenticated user (the depositor). For case (3), the <atom:author> element MAY be used to capture a name or username for the authenticated user (the depositor) and the <atom:contributor> element MAY be used to capture a name or username for the user on-behalf-of whom that deposit is being made. For full level 1 compliance these are mandatory. For case (4) the <atom:author> and <atom:contributor> elements are not mandatory, although implementers should note that <atom:author> is mandatory for ATOM compliance. In this case, implementers may choose to populate these elements.
In the SWORD Profile, author and contributor relate to the 'deposit', not to the package being deposited, i.e. the author refers to the person making the deposit, not to the author of the package.
In cases (1) to (4), the <atom:generator> element MAY be used to indicate the repository or client making the deposit. This is mandatory for full level 1 compliance.
Also see section 14. Securing the Atom Publishing Protocol.
SWORD Extensions to the APP
This section defines SWORD extensions to the APP, as used in this document.
APP Element extensions
SWORD defines the use of additional elements, as follows:
| Element | Namespace | APP / ATOM extension point | Usage notes |
| <sword:collectionPolicy> |
http://purl.org/net/sword/ | <app:collection> (Service Document) | Use for a human-readable repository or collection policy. Include either a text description or a URI. |
| <dcterms:abstract> | http://purl.org/dc/terms/ | <app:collection> (Service Document) | Use for a human-readable repository or collection description. Include either a text description or a URI. |
| <sword:mediation> | <app:collection> (Service Document) | Use to indicate if mediated deposit is allowed on the defined collection. Value=true|false |
|
| <sword:treatment> | <app:collection> (Service Document) | Use for a human-readable statement about what treatment the deposited resource will receive. Include either a text description or a URI. | |
| <sword:treatment> | <atom:entry> (Atom Entry Document (response)) | Use for a human-readable statement about what treatment the deposited resource has received. Include either a text description or a URI. | |
| <sword:verbose> | <app:service> (Service Document) | Use to indicate if verbose descriptions are supported. This extension is intended for use by developers for testing implementation. Value=true|false |
|
| <sword:verboseDescription> | <atom:entry> (Atom Entry
Document (response)) |
Use to supply a verbose descriptions are supported. This extension is intended for use by developers for testing implementation Include either a text description or a URI. Value=true|false |
|
| <sword:noOp> | <app:service> (Service Document) | Use 'true' to indicate if the server supports the noOp facility. This extension is intended for use by developers for testing implementation. Value=true|false |
|
| <sword:noOp> | <atom:entry> (Atom Entry Document (response)) | Use 'true' to indicate that the server has taken no action on receipt of this deposit. This extension is intended for use by developers for testing implementation. Value=true|false |
|
| <sword:formatNamespace> | <app:collection> (Service Document) | Used to supply a URI for the format namespace. | |
| <sword:level> | http://purl.org/net/sword/ | <app:service> (Service Document) | Used to indicate the compliance level supported by the server. Value=0|1 |
HTTP Header extensions
| Header | Usage | Usage notes |
| Content-MD5 | HTTP Header (POST) | Used to supply a MD5 checksum. |
| X-On-Behalf-Of | HTTP Header (POST) | Used to supply the username of the target owner for the deposit, on whose behalf the authenticated user is making the deposit. |
| X-Format-Namespace | HTTP Header (POST) | Used for a the identifier for a namespace for the particular packaging format supplied. |
| X-Verbose | HTTP Header (POST) | Use to request a verbose description with the response. This header
is intended for use by developers for testing implementation. |
| X-No-Op | HTTP Header (POST) | Use 'true' to indicate if the server should take no action on receipt of this deposit. This extension is intended for use by developers for testing implementation. Value=true|false |
| X-Error-Code | HTTP Header (response) | Used in conjunction with 4xx or 5xx error codes, to provide additional information about the error:
|
Examples
Retrieve Service Document
GET to Service Document (simple user)
GET /app/servicedocument HTTP/1.1 Host: www.myrepository.ac.uk
GET to Service Document onBehalfOf TargetUser (mediated user)
GET /app/servicedocument HTTP/1.1 Host: www.myrepository.ac.uk X-On-Behalf-Of: lcarr
Service Document
Example 1: level 0
<?xml version="1.0" encoding='utf-8'?> <service xmlns="http://www.w3.org/2007/app" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sword="http://purl.org/net/sword/"> <sword:level>0</sword:level> <workspace> <atom:title>Main Site</atom:title> <collection href="http://www.myrepository.ac.uk/atom/geography-collection" > <atom:title>My Repository : Geography Collection</atom:title> </collection> </workspace> </service>
Example 2: level 1
<?xml version="1.0" encoding='utf-8'?> <service xmlns="http://www.w3.org/2007/app#" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sword="http://purl.org/net/sword/" xmlns:dcterms="http://purl.org/dc/terms/"> <sword:level>1</sword:level> <sword:verbose>true</sword:verbose> <sword:noOp>true</sword:noOp> <workspace> <atom:title>Main Site</atom:title> <collection href="http://www.myrepository.ac.uk/atom/geography-collection" > <atom:title>My Repository : Geography Collection</atom:title> <app:accept>application/xml</app:accept> <app:accept>application/zip</app:accept> <app:accept>application/atom+xml</app:accept> <sword:collectionPolicy>Collection Policy</sword:collectionPolicy> <dcterms:abstract>Collection description</dcterms:abstract> <sword:mediation>true</sword:mediation> <sword:treatment>treatment description</sword:treatment> <sword:formatNamespace>uri</sword:formatNamespace> </collection> </workspace> </service>
Deposit
Example 1: POST binary (level 0)
http://www.myrepository.ac.uk/atom/geography-collection
POST /geography-collection/ HTTP/1.1 Host: www.myrepository.ac.uk/app Content-Type: application/zip Content-Length: nnn ...binary data...
Example 2: POST binary (mediated user)
POST /geography-collection HTTP/1.1 Host: www.myrepository.ac.uk/app Content-Type: application/zip Authorization: Basic ZGFmZnk6c2VjZXJldA== Content-Length: nnn X-On-Behalf-Of: lcarr ...binary data...
Example 3: POST (level 1, mediated user)
POST /geography-collection HTTP/1.1 Host: www.myrepository.ac.uk/app Content-Type: application/zip Slug: deposit-id Authorization: Basic ZGFmZnk6c2VjZXJldA== Content-Length: nnn Content-MD5: md5-digest X-On-Behalf-Of: lcarr X-Verbose: true X-No-Op: true X-Format-Namespace: agreed-format-namespace
Response
Example 1: level 0 response
HTTP/1.1 201 Created Date: Mon, 14 May 2007 14:27:11 GMT Content-Length: nnn Content-Type: application/atom+xml; charset="utf-8" Location: http://www.myrepository.ac.uk/collection/edit/my_deposit.atom
<?xml version="1.0"?> <entry xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sword="http://purl.org/net/sword/"> <title>My Deposit</title> <id>deposit-id</id> <updated>2007-05-14T14:27:08Z</updated> <author><name>lcarr</name></author> <summary type="text" /> <content type="application/zip" src="http://www.myrepository.ac.uk/my_deposit.zip"/> <link rel="edit-media" href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit" /> <link rel="edit" href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit.atom" /> <sword:treatment>Treatment description</sword:treatment> </entry>
Example 2: mediated user
HTTP/1.1 201 Created Date: Mon, 14 May 2007 14:27:11 GMT Content-Length: nnn Content-Type: application/atom+xml; charset="utf-8" Location: http://www.myrepository.ac.uk/collection/edit/my_deposit.atom
<?xml version="1.0"?> <entry xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sword="http://purl.org/net/sword/"> <title>My Deposit</title> <id>deposit-id</id> <updated>2007-05-14T14:27:08Z</updated> <author><name>mmorrey</name></author> <summary type="text" /> <content type="application/zip" src="http://www.myrepository.ac.uk/my_deposit.zip"/> <link rel="edit-media" href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit" /> <link rel="edit" href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit.atom" /> <contributor><name>lcarr</name></contributor> <source> <generator>Repository id</generator> </source> <sword:treatment>Treatment description</sword:treatment> </entry>
Example 3: level 1 response
HTTP/1.1 201 Created Date: Mon, 14 May 2007 14:27:11 GMT Content-Length: nnn Content-Type: application/atom+xml; charset="utf-8" Content-MD5: md5-digest Location: http://www.myrepository.ac.uk/collection/edit/my_deposit.atom
<?xml version="1.0"?> <entry xmlns:atom="http://www.w3.org/2005/Atom" xmlns:sword="http://purl.org/net/sword/"> <title>My Deposit</title> <id>deposit-id</id> <updated>2007-05-14T14:27:08Z</updated> <author><name>mmorrey</name></author> <summary type="text" /> <content type="application/zip" src="http://www.myrepository.ac.uk/my_deposit.zip"/> <link rel="edit-media" href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit" /> <link rel="edit" href="http://www.myrepository.ac.uk/lcarr/workflow/my_deposit.atom" /> <contributor><name>lcarr</name></contributor> <source> <generator>Repository id</generator> </source> <sword:treatment>Treatment description</sword:treatment> <sword:verboseDescription>description</sword:verboseDescription> <sword:noOp>true</<sword:noOp> <sword:formatNamespace>http://www.loc.gov/METS_Profile/</sword:formatNamespace>> </entry>
References
Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005. [RFC4287]. http://www.ietf.org/rfc/rfc4287.txt (see also non-normative html version at http://atompub.org/rfc4287.html)
Gregario, J. and B. de hOra, "The Atom Publishing Protocol", Internet Draft, June 2007. http://www.ietf.org/internet-drafts/draft-ietf-atompub-protocol-17.txt (see also non-normative html version at http://bitworking.org/projects/atom/draft-ietf-atompub-protocol-17.html)
Fielding et al, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999 http://www.w3.org/Protocols/rfc2616/rfc2616.html
"HTTP/1.1: Status Code Definitions", part of "Hypertext Transfer Protocol -- HTTP/1.1" RFC 2616 Fielding, et al. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
Klyne, G., Nottingham, M. and Mogul, J. "Registration Procedures for Message Header Fields", RFC 3864, September 2004 http://www.rfc-editor.org/rfc/rfc3864.txt
