draft-ietf-atompub-protocol-09.txt		draft-ietf-atompub-protocol-10.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft IBM
	Expires: December 25, 2006 B. de hOra, Ed.		Expires: March 9, 2007 B. de hOra, Ed.
	Propylon Ltd.		Propylon Ltd.
	June 23, 2006		September 05, 2006
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-09.txt		draft-ietf-atompub-protocol-10.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 35		skipping to change at page 1, line 35
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on December 25, 2006.		This Internet-Draft will expire on March 9, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The Atom Publishing Protocol (APP) is an application-level protocol		The Atom Publishing Protocol (APP) is an application-level protocol
	for publishing and editing Web resources. The protocol is based on		for publishing and editing Web resources. The protocol is based on
	HTTP transport of Atom-formatted representations. The Atom format is		HTTP transport of Atom-formatted representations. The Atom format is
	documented in the Atom Syndication Format (RFC4287).		documented in the Atom Syndication Format (RFC4287).
	Editorial Note		Editorial Note
	To provide feedback on this Internet-Draft, join the atom-protocol		To provide feedback on this Internet-Draft, join the atom-protocol
	mailing list (http://www.imc.org/atom-protocol/index.html) [1].		mailing list (http://www.imc.org/atom-protocol/index.html) [1].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6		2.1 XML-related Conventions . . . . . . . . . . . . . . . . . 5
	4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7		2.1.1 Referring to Information Items . . . . . . . . . . . . 5
	5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 8		2.1.2 RELAX NG Schema . . . . . . . . . . . . . . . . . . . 5
	5.1 Retrieving an Introspection Document . . . . . . . . . . . 8		2.1.3 Use of xml:base and xml:lang . . . . . . . . . . . . . 5
	5.2 Creating a Resource . . . . . . . . . . . . . . . . . . . 8		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7
	5.3 Editing a Resource . . . . . . . . . . . . . . . . . . . . 8		4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 8
	5.3.1 Retrieving a Resource . . . . . . . . . . . . . . . . 9		5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 10
	5.3.2 Updating a Resource . . . . . . . . . . . . . . . . . 9		5.1 Retrieving a Service Document . . . . . . . . . . . . . . 10
	5.3.3 Deleting a Resource . . . . . . . . . . . . . . . . . 9		5.2 Listing Collection Members . . . . . . . . . . . . . . . . 10
	5.4 Listing Collection Members . . . . . . . . . . . . . . . . 10		5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 11
	5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 10		5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 11
	6. XML-related Conventions . . . . . . . . . . . . . . . . . . 11		5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 11
	6.1 Referring to Information Items . . . . . . . . . . . . . . 11		5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 12
	6.2 XML Namespace Usage . . . . . . . . . . . . . . . . . . . 11		5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 12
	6.3 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11		5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 12
	6.4 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 12		6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 13
	7. Introspection Documents . . . . . . . . . . . . . . . . . . 13		6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 13
	7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13		6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 13
			7. Category Documents . . . . . . . . . . . . . . . . . . . . . 14
			7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14		7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14
	7.2.1 The "app:service" Element . . . . . . . . . . . . . . 14		7.2.1 The "app:categories" element . . . . . . . . . . . . . 14
	7.2.2 The "app:workspace" Element . . . . . . . . . . . . . 14		8. Service Documents . . . . . . . . . . . . . . . . . . . . . 16
	7.2.3 The "app:collection" Element . . . . . . . . . . . . . 15		8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 16		8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 17
	8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 17		8.2.1 The "app:service" Element . . . . . . . . . . . . . . 17
	8.1 Creating resources with POST . . . . . . . . . . . . . . . 17		8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 17
	8.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . 17		8.2.3 The "app:collection" Element . . . . . . . . . . . . . 18
	8.3 The 'edit' Link . . . . . . . . . . . . . . . . . . . . . 19		8.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 19
	8.4 Media Resources and Media Link Entries . . . . . . . . . . 19		8.2.5 The "app:categories" Element . . . . . . . . . . . . . 20
	8.4.1 Title: Header . . . . . . . . . . . . . . . . . . . . 20		9. Creating and Editing Resources . . . . . . . . . . . . . . . 22
	8.4.2 Example . . . . . . . . . . . . . . . . . . . . . . . 20		9.1 Member URIs . . . . . . . . . . . . . . . . . . . . . . . 22
	8.5 Editing Entries with Foreign Markup . . . . . . . . . . . 21		9.2 Creating resources with POST . . . . . . . . . . . . . . . 22
	9. Listing Collections . . . . . . . . . . . . . . . . . . . . 22		9.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . 23
	9.1 Collection Paging . . . . . . . . . . . . . . . . . . . . 22		9.3 Updating Resources with PUT . . . . . . . . . . . . . . . 24
	10. Atom Format Link Relation Extensions . . . . . . . . . . . . 24		9.4 Deleting Resources with DELETE . . . . . . . . . . . . . . 24
	10.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 24		9.5 Media Resources and Media Link Entries . . . . . . . . . . 24
	10.2 The "edit-media" Link Relation . . . . . . . . . . . . . 24		9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 25
	11. Atom Publishing Control Extensions . . . . . . . . . . . . . 25		9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 25
	11.1 The Atom Publishing Control Namespace . . . . . . . . . 25		9.6.2 Examples . . . . . . . . . . . . . . . . . . . . . . . 26
	11.2 The "pub:control" Element . . . . . . . . . . . . . . . 25		10. Listing Collections . . . . . . . . . . . . . . . . . . . . 28
	11.2.1 The "pub:draft" Element . . . . . . . . . . . . . . 25		10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 28
	12. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 26		11. Atom Format Link Relation Extensions . . . . . . . . . . . . 30
	13. Security Considerations . . . . . . . . . . . . . . . . . . 27		11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 30
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28		11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 30
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 30		12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 31
	15.1 Normative References . . . . . . . . . . . . . . . . . . 30		12.1 The "app:control" Element . . . . . . . . . . . . . . . 31
	15.2 Informative References . . . . . . . . . . . . . . . . . 31		12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 31
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32		13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 32
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33		14. Security Considerations . . . . . . . . . . . . . . . . . . 33
	B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 34		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
	C. Revision History . . . . . . . . . . . . . . . . . . . . . . 37		15.1 Content-type registration for
	Intellectual Property and Copyright Statements . . . . . . . 40		'application/atomserv+xml' . . . . . . . . . . . . . . . 34
			15.2 Content-type registration for
			'application/atomcat+xml' . . . . . . . . . . . . . . . 35
			16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37
			16.1 Normative References . . . . . . . . . . . . . . . . . . 37
			16.2 Informative References . . . . . . . . . . . . . . . . . 38
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39
			A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40
			B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 41
			C. Revision History . . . . . . . . . . . . . . . . . . . . . . 47
			Intellectual Property and Copyright Statements . . . . . . . 50
	1. Introduction		1. Introduction
	The Atom Publishing Protocol is an application-level protocol for		The Atom Publishing Protocol is an application-level protocol for
	publishing and editing Web resources using HTTP [RFC2616] and XML 1.0		publishing and editing Web resources using HTTP [RFC2616] and XML 1.0
	[W3C.REC-xml-20040204]. The protocol supports the creation of		[W3C.REC-xml-20040204]. The protocol supports the creation of
	arbitrary web resources and provides facilities for:		arbitrary web resources and provides facilities for:
	o Collections: Sets of resources, which can be retrieved in whole or		o Collections: Sets of resources, which can be retrieved in whole or
	in part.		in part.
	o Introspection: Discovering and describing collections.		o Service: Discovering and describing Collections.
	o Editing: Creating, updating and deleting resources.		o Editing: Creating, updating and deleting resources.
	2. Notational Conventions		2. Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Note: The Introspection Document allows the use of IRIs [RFC3987], as		Atom Protocol documents allow the use of IRIs [RFC3987], as well as
	well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used		URIs [RFC3986]. Before an IRI found in a document is used by HTTP,
	where an IRI is needed. How to map an IRI to a URI is specified in		the IRI is first converted to a URI according the procedure defined
	Section 3.1 of Internationalized Resource Identifiers (IRIs)		in [RFC3987] (Section 3.1). The resource identified by the URI after
	[RFC3987].		conversion is the same as the one identified by the IRI.
			2.1 XML-related Conventions
			2.1.1 Referring to Information Items
			Atom Protocol Document formats are specified in terms of the XML
			Information Set [W3C.REC-xml-infoset-20040204], serialized as XML 1.0
			[W3C.REC-xml-20040204].
			The Infoset terms "Element Information Item" and "Attribute
			Information Item" are shortened to "element" and "attribute"
			respectively. Therefore, when this specification uses the term
			"element", it is referring to an Element Information Item, and when
			it uses the term "attribute", it is referring to an Attribute
			Information Item.
			2.1.2 RELAX NG Schema
			Some sections of this specification are illustrated with fragments of
			a non-normative RELAX NG Compact schema [RNC]. However, the text of
			this specification provides the definition of conformance. Complete
			schemas appear in Appendix B.
			2.1.3 Use of xml:base and xml:lang
			XML elements defined by this specification MAY have an xml:base
			attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it
			serves the function described in section 5.1.1 of URI Generic Syntax
			[RFC3986], by establishing the base URI (or IRI) for resolving
			relative references found within the scope of the xml:base attribute.
			Any element defined by this specification MAY have an xml:lang
			attribute, whose content indicates the natural language for the
			element and its descendents. The language context is only
			significant for elements and attributes declared to be "Language-
			Sensitive" by this specification. Requirements regarding the content
			and interpretation of xml:lang are specified in Section 2.12 of XML
			1.0 [W3C.REC-xml-20040204].
	3. Terminology		3. Terminology
	For convenience, this protocol can be referred to as the "Atom		For convenience, this protocol can be referred to as the "Atom
	Protocol" or "APP".		Protocol" or "APP".
	URI/IRI - A Uniform Resource Identifier and Internationalized		URI/IRI - A Uniform Resource Identifier and Internationalized
	Resource Identifier. These terms and the distinction between them		Resource Identifier. These terms and the distinction between them
	are defined in [RFC3986] and [RFC3987]. Note that IRIs are mapped to		are defined in [RFC3986] and [RFC3987]. IRIs are mapped to URIs
	URIs before dereferencing takes place.		before dereferencing takes place.
			The phrase "the URI of a document" in this specification is shorthand
			for "a URI which, when dereferenced, is expected to produce that
			document as a representation".
	Resource - A network-accessible data object or service identified by		Resource - A network-accessible data object or service identified by
	an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for		an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for
	further discussion on resources.		further discussion on resources.
	The phrase "the URI of a document" in this specification is shorthand
	for "an URI which, when dereferenced, is expected to produce that
	document as a representation".
	Representation - An entity included with a request or response as		Representation - An entity included with a request or response as
	defined in [RFC2616].		defined in [RFC2616].
	Collection - A resource that contains a set of member IRIs. See		Collection - A resource that contains a set of Member IRIs. See
	Section 8.		Section 9.
	Member - A resource whose IRI is listed in a Collection.		Member - A resource whose IRI is listed in a Collection by a link
			element with a relation of "edit" or "edit-media". See Section 9.1.
	Introspection Document - A document that describes the location and		Workspace - A group of collections. See Section 8.
	capabilities of one or more Collections. See Section 7.
			Service Document - A document that describes the location and
			capabilities of one or more Collections. See Section 8.
			Category Document - A document that describes the categories allowed
			in a Collection. See Section 7.
	4. Protocol Model		4. Protocol Model
	The Atom Publishing Protocol uses HTTP to edit and author web		The Atom Publishing Protocol uses HTTP methods to edit and author
	resources. The Atom Protocol uses the following HTTP methods:		Member Resources as follows:
	o GET is used to retrieve a representation of a resource or perform		o GET is used to retrieve a representation of a known resource.
	a query.
	o POST is used to create a new, dynamically-named resource.		o POST is used to create a new, dynamically-named, resource.
	o PUT is used to update a known resource.		o PUT is used to update a known resource.
	o DELETE is used to remove a resource.		o DELETE is used to remove a known resource.
	Along with operations on resources the Atom Protocol provides		Along with operations on Member Resources the Atom Protocol defines
	structures, called Collections, for managing and organising		Collection resources for managing and organizing Member Resources.
	resources, called Members. Collections contain the IRIs of, and		Collections are represented by Atom Feed documents and contain the
	metadata about, their Member resources. Atom Protocol clients can		IRIs of, and metadata about, their Member Resources.
	use Introspection documents, which represent server-defined groups of
	Collections, to initialize the process of creating and editing
	resources.
	Note that when an IRI is used for resource retrieval over HTTP, the		There are two kinds of Member Resources - Member Entry Resources and
	IRI is first converted to a URI according the procedure defined in		Media Resources. Member Entry Resources are represented as Atom
	[RFC3987] section 3.1. The resource that the IRI locates is the same		Entries. Media Resources MAY have representations in any media type.
	as the one located by the URI obtained after converting the IRI.		A Media Link Entry is a Member Entry that contains metadata about a
			Media Resource. This diagram shows the classification of the
			resources:
			Member Resource
			-> Member Entry Resource
			-> Media Link Entry Resource
			-> Media Resource
			Collections, represented by Atom feeds, contain entries. Those
			entries contain the Member Entry and Media Resources IRIs of the
			Collection. A Collection can contain any number of entries of either
			kind. In the diagram of a Collection below there are two entries.
			The first contains the IRI of a Member Entry Resource. The second
			contains the IRIs of both a Media Resource and a Media Link Entry
			Resource, which contains the metadata for that Media Resource:
			Collection
			Entry
			Member Entry IRI -> Member Entry Resource
			Entry
			Member Entry IRI -> Media Link Entry Resource
			Media IRI -> Media Resource
			Service Documents represent server-defined groups of Collections, and
			are used to initialize the process of creating and editing resources.
	5. Protocol Operations		5. Protocol Operations
	5.1 Retrieving an Introspection Document		5.1 Retrieving a Service Document
	Client Server		Client Server
	| |		| |
	| 1.) GET to URI of Introspection Document |		| 1.) GET to URI of Service Document |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Introspection Document |		| 2.) Service Document |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the URI of the Introspection		1. The client sends a GET request to the URI of the Service
	Document.		Document.
	2. The server responds with the document enumerating the IRIs of a		2. The server responds with the document enumerating the IRIs of a
	set of Collections and the capabilities of those Collections		set of Collections and the capabilities of those Collections
	supported by the server. The content of this document can vary		supported by the server. The content of this document can vary
	based on aspects of the client request, including, but not		based on aspects of the client request, including, but not
	limited to, authentication credentials.		limited to, authentication credentials.
	5.2 Creating a Resource		5.2 Listing Collection Members
			To list the members of a Collection the client sends a GET request to
			the URI of a Collection. An Atom Feed Document is returned
			containing one Atom Entry for each Member Entry Resource. See
			Section 10 and Section 11 for a description of the feed contents.
			Client Server
			| |
			| 1.) GET to Collection URI |
			|------------------------------->|
			| |
			| 2.) 200 OK, Atom Feed Doc |
			|<-------------------------------|
			| |
			1. The client sends a GET request to the URI of the Collection.
			2. The server responds with an Atom Feed Document containing the
			IRIs of the Collection members.
			5.3 Creating a Resource
	Client Server		Client Server
	| |		| |
	| 1.) POST to URI of Collection |		| 1.) POST to URI of Collection |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 201 Created |		| 2.) 201 Created |
			| Location: Member Entry URI |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client POSTs a representation of the Member to the URI of the		1. The client POSTs a representation of the Member to the URI of the
	collection.		Collection.
	2. If the Member resource was created successfully, the server		2. If the Member Resource was created successfully, the server
	responds with a status code of 201 and a Location: header that		responds with a status code of 201 and a Location: header that
	contains the URI of the newly created resource.		contains the IRI of the newly created Member Entry Resource.
			Media Resources may have also been created and their IRIs can be
			found through the Member Entry Resource. See Section 9.5 for
			more details.
	5.3 Editing a Resource		5.4 Editing a Resource
	Once a resource has been created and its URI is known, that URI can		Once a resource has been created and its Member URI is known, that
	be used to retrieve, update, and delete the resource.		URI can be used to retrieve, update, and delete the resource.
	5.3.1 Retrieving a Resource		5.4.1 Retrieving a Resource
	Client Server		Client Server
	| |		| |
	| 1.) GET to Member URI |		| 1.) GET to Member URI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Member Representation |		| 2.) Member Representation |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the Member's URI to retrieve		1. The client sends a GET request to the URI of a Member Resource to
	its representation.		retrieve its representation.
	2. The server responds with the representation of the resource.		2. The server responds with the representation of the resource.
	5.3.2 Updating a Resource		5.4.2 Updating a Resource
	Client Server		Client Server
	| |		| |
	| 1.) PUT to Member URI |		| 1.) PUT to Member URI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 OK |		| 2.) 200 OK |
	|<------------------------------------------|		|<------------------------------------------|
	1. The client PUTs an updated representation to the Member's URI.		1. The client PUTs an updated representation to the URI of a Member
			Resource.
	2. Upon a successful update of the resource the server responds with		2. Upon a successful update of the resource the server responds with
	a status code of 200.		a status code of 200.
	5.3.3 Deleting a Resource		5.4.3 Deleting a Resource
	Client Server		Client Server
	| |		| |
	| 1.) DELETE to Member URI |		| 1.) DELETE to Member URI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 Ok |		| 2.) 200 Ok |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a DELETE request to the Member's URI.		1. The client sends a DELETE request to the URI of a Member
			Resource.
	2. Upon the successful deletion of the resource the server responds		2. Upon the successful deletion of the resource the server responds
	with a status code of 200.		with a status code of 200.
	5.4 Listing Collection Members		A different approach is taken for deleting Media Resources, see
			Section 9.5 for details.
	To list the members of a Collection the client sends a GET request to
	the Collection's URI. An Atom Feed Document is returned containing
	one Atom Entry for each member resource. See Section 9 and
	Section 10 for a description of the feed contents.
	Client Server
	| |
	| 1.) GET to Collection URI |
	|------------------------------->|
	| |
	| 2.) 200 OK, Atom Feed Doc |
	|<-------------------------------|
	| |
	1. The client sends a GET request to the Collection's URI.
	2. The server responds with an Atom Feed Document containing the
	IRIs of the collection members.
	5.5 Use of HTTP Response codes		5.5 Use of HTTP Response codes
	The Atom Protocol uses the response status codes defined in HTTP to		The Atom Protocol uses the response status codes defined in HTTP to
	indicate the success or failure of an operation. Consult the HTTP		indicate the success or failure of an operation. Consult the HTTP
	specification [RFC2616] for detailed definitions of each status code.		specification [RFC2616] for detailed definitions of each status code.
	It is RECOMMENDED that entities contained within HTTP 4xx and 5xx		It is RECOMMENDED that entities contained within HTTP 4xx and 5xx
	responses include a human-readable explanation of the error.		responses include a human-readable explanation of the error.
	6. XML-related Conventions		6. Atom Publishing Protocol Documents
	The Atom Protocol Introspection format is specified in terms of the
	XML Information Set [W3C.REC-xml-infoset-20040204], serialised as XML
	1.0 [W3C.REC-xml-20040204]. Atom Publishing Protocol Documents MUST
	be well-formed XML. This specification does not define any DTDs for
	Atom Protocol, and hence does not require them to be "valid" in the
	sense used by XML.
	6.1 Referring to Information Items
	This specification uses a shorthand for two common terms: the phrase		6.1 Document Types
	"Information Item" is omitted when discussing Element Information
	Items and Attribute Information Items. Therefore, when this
	specification uses the term "element," it is referring to an Element
	Information Item in Infoset terms. Likewise, when it uses the term
	"attribute," it is referring to an Attribute Information Item.
	6.2 XML Namespace Usage		This specification describes two kinds of Documents - Category
			Documents and Service Documents.
	The namespace name [W3C.REC-xml-names-19990114] for the XML format		A Category Document (Section 7) contain lists of categories specified
	described in this specification is:		using the "atom:category" element from the Atom Syndication Format.
			A Service Document (Section 8) describes capabilities of workspaces,
			which are server-defined groupings of Collections.
			The namespace name [W3C.REC-xml-names-19990114] for either kind of
			document is:
	http://purl.org/atom/app#		http://purl.org/atom/app#
	This specification uses the prefix "app:" for the namespace name.		This specification uses the prefix "app:" for the namespace name.
	The choice of namespace prefix is not semantically significant.		The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the
			namespace name of the Atom Syndication Format [RFC4287]. The
			namespace prefixes are not semantically significant.
	The "app:" namespace is reserved for future forward-compatible		Atom Publishing Protocol Documents MUST be well-formed XML. This
	revisions of the Atom Publishing Protocol. Future versions of this		specification does not define any DTDs for Atom Protocol formats, and
	specification could add new elements and attributes to the markup		hence does not require them to be "valid" in the sense used by XML.
	vocabulary. Software written to conform to this version of the
	specification will not be able to process such markup correctly and,
	in fact, will not be able to distinguish it from markup error. For
	the purposes of this discussion, unrecognized markup from the Atom
	Publishing Protocol vocabulary will be considered "foreign markup".
	This specification also uses the prefix "atom:" for		6.2 Document Extensibility
	"http://www.w3.org/2005/Atom", the namespace name of the Atom
	Syndication Format [RFC4287].
	6.3 Use of xml:base and xml:lang		The namespace name "http://purl.org/atom/app#" is reserved for future
			forward-compatible revisions of the document types. Future versions
			of this specification could add new elements and attributes.
			Software written to conform to this version of the specification will
			not be able to process such markup correctly and in fact will not be
			able to distinguish it from markup error.
	XML elements defined by this specification MAY have an xml:base		Unrecognized markup in an Atom Publishing Protocol document is
	attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it		considered "foreign markup" as defined in [RFC4287].
	serves the function described in section 5.1.1 of URI Generic Syntax
	[RFC3986], establishing the base URI (or IRI) for resolving any
	relative references found within the effective scope of the xml:base
	attribute.
	Any element defined by this specification MAY have an xml:lang		Markup from other vocabularies ("foreign markup") can be used
	attribute, whose content indicates the natural language for the		anywhere within a Category or Service Document unless it is
	element and its descendents. The language context is only		explicitly forbidden. Processors that encounter foreign markup MUST
	significant for elements and attributes declared to be "Language-		NOT stop processing or signal an error, and SHOULD preserve foreign
	Sensitive" by this specification. Requirements regarding the content		markup when transmitting such documents.
	and interpretation of xml:lang are specified in Section 2.12 of XML
	1.0 [W3C.REC-xml-20040204].
	appCommonAttributes =
	attribute xml:base { atomUri }?,
	attribute xml:lang { atomLanguageTag }?,
	undefinedAttribute*
	6.4 RELAX NG Schema		7. Category Documents
	Some sections of this specification are illustrated with fragments of		Category Documents contain lists of categories described using the
	a non-normative RELAX NG Compact schema [RNC]. A complete schema		"atom:category" element from the Atom Syndication Format [RFC4287].
	appears in Appendix B. However, the text of this specification		Categories can also appear in Service Documents and describe the
	provides the definition of conformance.		categories allowed in a Collection (see Section 8.2.5).
	7. Introspection Documents		Category Documents are identified with the "application/atomcat+xml"	<