draft-ietf-atompub-protocol-12.txt		draft-ietf-atompub-protocol-13.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft IBM		Internet-Draft IBM
	Expires: June 13, 2007 B. de hOra, Ed.		Intended status: Standards Track B. de hOra, Ed.
	Propylon Ltd.		Expires: August 9, 2007 Propylon Ltd.
	December 10, 2006		February 5, 2007
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-12.txt		draft-ietf-atompub-protocol-13.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 June 13, 2007.		This Internet-Draft will expire on August 9, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5		2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 6
	2.1 XML-related Conventions . . . . . . . . . . . . . . . . . 5		2.1. XML-related Conventions . . . . . . . . . . . . . . . . . 6
	2.1.1 Referring to Information Items . . . . . . . . . . . . 5		2.1.1. Referring to Information Items . . . . . . . . . . . . 6
	2.1.2 RELAX NG Schema . . . . . . . . . . . . . . . . . . . 5		2.1.2. RELAX NG Schema . . . . . . . . . . . . . . . . . . . 6
	2.1.3 Use of xml:base and xml:lang . . . . . . . . . . . . . 5		2.1.3. Use of xml:base and xml:lang . . . . . . . . . . . . . 6
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 9		4.1. Client Implementation Considerations . . . . . . . . . . . 9
	5.1 Retrieving a Service Document . . . . . . . . . . . . . . 9		5. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 11
	5.2 Listing Collection Members . . . . . . . . . . . . . . . . 9		5.1. Retrieving a Service Document . . . . . . . . . . . . . . 11
	5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 10		5.2. Listing Collection Members . . . . . . . . . . . . . . . . 11
	5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 10		5.3. Creating a Resource . . . . . . . . . . . . . . . . . . . 12
	5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 10		5.4. Editing a Resource . . . . . . . . . . . . . . . . . . . . 12
	5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 11		5.4.1. Retrieving a Resource . . . . . . . . . . . . . . . . 12
	5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 11		5.4.2. Updating a Resource . . . . . . . . . . . . . . . . . 13
	5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 11		5.4.3. Deleting a Resource . . . . . . . . . . . . . . . . . 13
	6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 12		5.5. Use of HTTP Response codes . . . . . . . . . . . . . . . . 13
	6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 12		6. Atom Publishing Protocol Documents . . . . . . . . . . . . . . 14
	6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 12		6.1. Document Types . . . . . . . . . . . . . . . . . . . . . . 14
	7. Category Documents . . . . . . . . . . . . . . . . . . . . . 14		6.2. Document Extensibility . . . . . . . . . . . . . . . . . . 14
	7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14		7. Category Documents . . . . . . . . . . . . . . . . . . . . . . 16
	7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14		7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2.1 The "app:categories" element . . . . . . . . . . . . . 14		7.2. Element Definitions . . . . . . . . . . . . . . . . . . . 16
	8. Service Documents . . . . . . . . . . . . . . . . . . . . . 16		7.2.1. The "app:categories" element . . . . . . . . . . . . . 16
	8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 17		8. Service Documents . . . . . . . . . . . . . . . . . . . . . . 18
	8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 18		8.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.2.1 The "app:service" Element . . . . . . . . . . . . . . 18		8.2. Element Definitions . . . . . . . . . . . . . . . . . . . 20
	8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 18		8.2.1. The "app:service" Element . . . . . . . . . . . . . . 20
	8.2.3 The "app:collection" Element . . . . . . . . . . . . . 19		8.2.2. The "app:workspace" Element . . . . . . . . . . . . . 20
	8.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 19		8.2.3. The "app:collection" Element . . . . . . . . . . . . . 21
	8.2.5 The "app:categories" Element . . . . . . . . . . . . . 20		8.2.4. The "app:accept" Element . . . . . . . . . . . . . . . 21
	9. Creating and Editing Resources . . . . . . . . . . . . . . . 22		8.2.5. The "app:categories" Element . . . . . . . . . . . . . 22
	9.1 Member URIs . . . . . . . . . . . . . . . . . . . . . . . 22		9. Creating and Editing Resources . . . . . . . . . . . . . . . . 24
	9.2 Creating resources with POST . . . . . . . . . . . . . . . 22		9.1. Member URIs . . . . . . . . . . . . . . . . . . . . . . . 24
	9.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . 23		9.2. Creating resources with POST . . . . . . . . . . . . . . . 24
	9.3 Updating Resources with PUT . . . . . . . . . . . . . . . 24		9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 25
	9.4 Deleting Resources with DELETE . . . . . . . . . . . . . . 24		9.3. Updating Resources with PUT . . . . . . . . . . . . . . . 26
	9.5 Media Resources and Media Link Entries . . . . . . . . . . 25		9.4. Deleting Resources with DELETE . . . . . . . . . . . . . . 26
	9.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . . 26		9.5. Media Resources and Media Link Entries . . . . . . . . . . 26
	9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 31		9.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 27
	9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 32		9.6. The Slug: Header . . . . . . . . . . . . . . . . . . . . . 32
	9.6.2 Example . . . . . . . . . . . . . . . . . . . . . . . 32		9.6.1. Slug: Header syntax . . . . . . . . . . . . . . . . . 33
	10. Listing Collections . . . . . . . . . . . . . . . . . . . . 33		9.6.2. Example . . . . . . . . . . . . . . . . . . . . . . . 33
	10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 33		10. Listing Collections . . . . . . . . . . . . . . . . . . . . . 34
	10.2 The "app:edited" Element . . . . . . . . . . . . . . . . 34		10.1. Collection Paging . . . . . . . . . . . . . . . . . . . . 34
	11. Atom Format Link Relation Extensions . . . . . . . . . . . . 35		10.2. The "app:edited" Element . . . . . . . . . . . . . . . . . 35
	11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 35		11. Atom Format Link Relation Extensions . . . . . . . . . . . . . 36
	11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 35		11.1. The "edit" Link Relation . . . . . . . . . . . . . . . . . 36
	12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 36		11.2. The "edit-media" Link Relation . . . . . . . . . . . . . . 36
	12.1 The "app:control" Element . . . . . . . . . . . . . . . 36		12. The Atom Format Type Parameter . . . . . . . . . . . . . . . . 37
	12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 36		12.1. The 'type' parameter . . . . . . . . . . . . . . . . . . . 37
	13. Securing the Atom Publishing Protocol . . . . . . . . . . . 37		12.1.1. Conformance . . . . . . . . . . . . . . . . . . . . . 37
	14. Security Considerations . . . . . . . . . . . . . . . . . . 38		13. Atom Publishing Controls . . . . . . . . . . . . . . . . . . . 38
	14.1 Denial of Service . . . . . . . . . . . . . . . . . . . 38		13.1. The "app:control" Element . . . . . . . . . . . . . . . . 38
	14.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . . 38		13.1.1. The "app:draft" Element . . . . . . . . . . . . . . . 38
	14.3 Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 38		14. Securing the Atom Publishing Protocol . . . . . . . . . . . . 39
	14.4 Linked Resources . . . . . . . . . . . . . . . . . . . . 38		15. Security Considerations . . . . . . . . . . . . . . . . . . . 40
	14.5 Digital Signatures and Encryption . . . . . . . . . . . 38		15.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
	14.6 URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 38		15.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 40
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39		15.3. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . 40
	15.1 Content-type registration for		15.4. Linked Resources . . . . . . . . . . . . . . . . . . . . . 40
	'application/atomserv+xml' . . . . . . . . . . . . . . . 39		15.5. Digital Signatures and Encryption . . . . . . . . . . . . 40
	15.2 Content-type registration for		15.6. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 40
	'application/atomcat+xml' . . . . . . . . . . . . . . . 40		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
	15.3 Header field registration for 'SLUG' . . . . . . . . . . 41		16.1. Content-type registration for
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43		'application/atomserv+xml' . . . . . . . . . . . . . . . . 41
	16.1 Normative References . . . . . . . . . . . . . . . . . . 43		16.2. Content-type registration for 'application/atomcat+xml' . 42
	16.2 Informative References . . . . . . . . . . . . . . . . . 44		16.3. Header field registration for 'SLUG' . . . . . . . . . . . 43
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45		16.4. The Link Relation registration "edit" . . . . . . . . . . 44
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46		16.5. The Link Relation registration "edit-media" . . . . . . . 44
	B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 47		16.6. The Atom Format Media Type Parameter . . . . . . . . . . . 44
	C. Revision History . . . . . . . . . . . . . . . . . . . . . . 53		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
	Intellectual Property and Copyright Statements . . . . . . . 56		17.1. Normative References . . . . . . . . . . . . . . . . . . . 45
			17.2. Informative References . . . . . . . . . . . . . . . . . . 46
			Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 48
			Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 49
			Appendix C. Revision History . . . . . . . . . . . . . . . . . . 55
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58
			Intellectual Property and Copyright Statements . . . . . . . . . . 59
	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-20060816]. The protocol supports the creation of		[W3C.REC-xml]. The protocol supports the creation of Web resources
	arbitrary Web resources and provides facilities for:		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 Service: Discovering and describing Collections.		o Service: Discovering and describing Collections.
	o Editing: Creating, updating and deleting resources.		o Editing: Creating, updating and deleting resources.
			The Atom Publishing Protocol is different from many contemporary
			protocols in that the server is given wide latitude in processing
			requests from clients. See Section 4 for more details.
	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].
	2.1 XML-related Conventions		2.1. XML-related Conventions
	2.1.1 Referring to Information Items		2.1.1. Referring to Information Items
	Atom Protocol Document formats are specified in terms of the XML		Atom Protocol Document formats are specified in terms of the XML
	Information Set [W3C.REC-xml-infoset-20040204], serialized as XML 1.0		Information Set [W3C.REC-xml-infoset], serialized as XML 1.0
	[W3C.REC-xml-20060816].		[W3C.REC-xml].
	The Infoset terms "Element Information Item" and "Attribute		The Infoset terms "Element Information Item" and "Attribute
	Information Item" are shortened to "element" and "attribute"		Information Item" are shortened to "element" and "attribute"
	respectively. Therefore, when this specification uses the term		respectively. Therefore, when this specification uses the term
	"element", it is referring to an Element Information Item, and when		"element", it is referring to an Element Information Item, and when
	it uses the term "attribute", it is referring to an Attribute		it uses the term "attribute", it is referring to an Attribute
	Information Item.		Information Item.
	2.1.2 RELAX NG Schema		2.1.2. RELAX NG Schema
	Some sections of this specification are illustrated with fragments of		Some sections of this specification are illustrated with fragments of
	a non-normative RELAX NG Compact schema [RNC]. However, the text of		a non-normative RELAX NG Compact schema [RNC]. However, the text of
	this specification provides the definition of conformance. Complete		this specification provides the definition of conformance. Complete
	schemas appear in Appendix B.		schemas appear in Appendix B.
	2.1.3 Use of xml:base and xml:lang		2.1.3. Use of xml:base and xml:lang
	XML elements defined by this specification MAY have an xml:base		XML elements defined by this specification MAY have an xml:base
	attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it		attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it
	serves the function described in Section 5.1.1 of URI Generic Syntax		serves the function described in Section 5.1.1 of URI Generic Syntax
	[RFC3986], by establishing the base URI (or IRI) for resolving		[RFC3986], by establishing the base URI (or IRI) for resolving
	relative references found within the scope of the xml:base attribute.		relative references found within the scope of the xml:base attribute.
	Any element defined by this specification MAY have an xml:lang		Any element defined by this specification MAY have an xml:lang
	attribute, whose content indicates the natural language for the		attribute, whose content indicates the natural language for the
	element and its descendents. The language context is only		element and its descendents. The language context is only
	significant for elements and attributes declared to be "Language-		significant for elements and attributes declared to be "Language-
	Sensitive" by this specification. Requirements regarding the content		Sensitive" by this specification. Requirements regarding the content
	and interpretation of xml:lang are specified in Section 2.12 of XML		and interpretation of xml:lang are specified in Section 2.12 of XML
	1.0 [W3C.REC-xml-20060816].		1.0 [W3C.REC-xml].
	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]. Before an IRI found in a		are defined in [RFC3986] and [RFC3987]. Before an IRI found in a
	document is used by HTTP, the IRI is first converted to a URI (see		document is used by HTTP, the IRI is first converted to a URI (see
	skipping to change at page 7, line 22		skipping to change at page 8, line 22
	o POST is used to create a new, dynamically-named, resource. When		o POST is used to create a new, dynamically-named, resource. When
	the client submits non-Atom-Entry representations to a Collection		the client submits non-Atom-Entry representations to a Collection
	for creation, two resources are always created - a Media Entry for		for creation, two resources are always created - a Media Entry for
	the requested resource, and a Media Link Entry for metadata (in		the requested resource, and a Media Link Entry for metadata (in
	Atom Entry format) about the resource.		Atom Entry format) about the 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 known resource.		o DELETE is used to remove a known resource.
	The Atom Protocol imposes few restrictions on the actions of servers.
	Unless a constraint is specified here, servers can be expected to
	vary in behavior, in particular around the manipulation of Atom
	Entries sent by clients. For example this specification only defines
	the expected behavior of Collections with respect to GET and POST,
	but this does not imply that PUT, DELETE, PROPPATCH and others are
	forbidden on Collection resources - only that this specification does
	not define what the servers response would be to those methods.
	Similarly while some HTTP status codes are mentioned explicitly,
	clients should be prepared to handle any valid status code from a
	server.
	This document does not specify the form of the URIs that are used.		This document does not specify the form of the URIs that are used.
	HTTP ([RFC2616]) specifies that the URI space of each server is		HTTP ([RFC2616]) specifies that the URI space of each server is
	controlled by that server and the Atom Protocol imposes no		controlled by that server and the Atom Protocol imposes no
	constraints on that control. What this RFC does specify are the		constraints on that control. What this RFC does specify are the
	formats of the representations that are exchanged and the actions		formats of the representations that are exchanged and the actions
	that can be performed on the IRIs embedded in those documents.		that can be performed on the IRIs embedded in those documents.
	This document only covers the creation, update and deletion of Entry		This document only covers the creation, update and deletion of Entry
	and Media resources. Other resources can be created, updated, and		and Media resources. Other resources can be created, updated, and
	deleted as the result of manipulating a Collection, but the number of		deleted as the result of manipulating a Collection, but the number of
	those resources, their mime-types, and effects of Atom Protocol		those resources, their media-types, and effects of Atom Protocol
	operations on them are outside the scope of this specification.		operations on them are outside the scope of this specification.
	Since all aspects of client-server interaction are defined in terms		Since all aspects of client-server interaction are defined in terms
	of HTTP, [RFC2616] should be consulted for any areas not covered in		of HTTP, [RFC2616] should be consulted for any areas not covered in
	this specification.		this specification.
	Along with operations on Member Resources, the Atom Protocol defines		Along with operations on Member Resources, the Atom Protocol defines
	Collection Resources for managing and organizing Member Resources.		Collection Resources for managing and organizing Member Resources.
	Collections are represented by Atom Feed documents and contain the		Collections are represented by Atom Feed documents and contain the
	IRIs of, and metadata about, their Member Resources. The Atom		IRIs of, and metadata about, their Member Resources. The Atom
	Protocol does not make a distinction between Feeds used for		Protocol does not make a structural distinction between Feeds used
	Collections and other Atom Feeds. The only mechanism that this		for Collections and other Atom Feeds. The only mechanism that this
	specification supplies for distinguishing a Collection Feed is its		specification supplies for distinguishing a Collection Feed is its
	appearance in a Service Document.		appearance in a Service Document.
	Atom Protocol documents allow the use of IRIs [RFC3987], as well as		Atom Protocol documents allow the use of IRIs [RFC3987], as well as
	URIs [RFC3986]. Before an IRI found in a document is used by HTTP,		URIs [RFC3986]. Before an IRI found in a document is used by HTTP,
	the IRI is first converted to a URI according the procedure defined		the IRI is first converted to a URI according the procedure defined
	in Section 3.1 of [RFC3987]. In accordance with that specification,		in Section 3.1 of [RFC3987]. In accordance with that specification,
	this conversion SHOULD be applied as late as possible. The IRI, and		this conversion SHOULD be applied as late as possible. The IRI, and
	the URI into which it is converted, identify the same resource.		the URI into which it is converted, identify the same resource.
	skipping to change at page 8, line 31		skipping to change at page 9, line 18
	Entries [RFC4287]. Media Resources can have representations in any		Entries [RFC4287]. Media Resources can have representations in any
	media type. A Media Link Entry is a Member Entry that contains		media type. A Media Link Entry is a Member Entry that contains
	metadata about a Media Resource. This diagram shows the		metadata about a Media Resource. This diagram shows the
	classification of the resources:		classification of the resources:
	Member Resource		Member Resource
	-> Member Entry Resource		-> Member Entry Resource
	-> Media Link Entry Resource		-> Media Link Entry Resource
	-> Media Resource		-> Media Resource
	Collections, represented by Atom feeds, contain Entries. Those		A Collection's Atom Entries contain the Member Entry and Media
	Entries contain the Member Entry and Media Resources IRIs of the		Resources IRIs of the Collection. A Collection can contain any
	Collection. A Collection can contain any number of Entries of either		number of Entries for either kind. In the diagram of a Collection
	kind. In the diagram of a Collection below, there are two Entries.		below, there are two Entries. The first contains the IRI of a Member
	The first contains the IRI of a Member Entry Resource. The second		Entry Resource. The second contains the IRIs of both a Media
	contains the IRIs of both a Media Resource and a Media Link Entry		Resource and a Media Link Entry Resource, which contains the metadata
	Resource, which contains the metadata for that Media Resource:		for that Media Resource:
	Collection		Collection
	Entry		Entry
	Member Entry IRI -> Member Entry Resource		Member Entry IRI -> Member Entry Resource
	Entry		Entry
	Member Entry IRI -> Media Link Entry Resource		Member Entry IRI -> Media Link Entry Resource
	Media IRI -> Media Resource		Media IRI -> Media Resource
	Service Documents represent server-defined groups of Collections, and		Service Documents represent server-defined groups of Collections, and
	are used to initialize the process of creating and editing resources.		are used to initialize the process of creating and editing resources.
			4.1. Client Implementation Considerations
			The Atom Protocol imposes few restrictions on the actions of servers.
			Unless a constraint is specified here, servers can be expected to
			vary in behavior, in particular around the manipulation of Atom
			Entries sent by clients. For example, although this specification
			only defines the expected behavior of Collections with respect to GET
			and POST, this does not imply that PUT, DELETE, PROPPATCH and others
			are forbidden on Collection resources - only that this specification
			does not define what the servers response would be to those methods.
			Similarly while some HTTP status codes are mentioned explicitly,
			clients should be prepared to handle any status code from a server.
			Servers can choose to accept, reject, delay, moderate, censor,
			reformat, translate, relocate or recategorize the content submitted
			to them. Only some of these choices are immediately relayed back to
			the client in responses to client requests; other choices may only
			become apparent later, in the feed or published entries. The same
			series of requests to two different publishing sites can result in a
			different series of HTTP responses, different resulting feeds or
			different entry contents.
			As a result, client software has to be written flexibly to accept
			what the server decides are the results of its submissions. Any
			server response or server content modification not explicitly
			forbidden by this specification or HTTP ([RFC2616]) is therefore
			allowed.
	5. Protocol Operations		5. Protocol Operations
	5.1 Retrieving a Service Document		5.1. Retrieving a Service Document
	Client Server		Client Server
	| |		| |
	| 1.) GET to Service Document |		| 1.) GET to Service Document |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Service Document |		| 2.) Service Document |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request using the URI of the Service		1. The client sends a GET request using 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
	group of Collections and the capabilities of those Collections		group 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 Listing Collection Members		5.2. Listing Collection Members
	To list the members of a Collection, the client sends a GET request		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 whose		to the URI of a Collection. An Atom Feed Document is returned whose
	Entries contain the IRIs of Member Resources. The returned Feed may		Entries contain the IRIs of Member Resources. The returned Feed may
	describe all, or only a subset, of the Members in a Collection (see		describe all, or only a subset, of the Members in a Collection (see
	Section 10). Section 11 describes extensions to the Atom Syndication		Section 10). Section 11 describes extensions to the Atom Syndication
	Format used in the Atom Protocol.		Format used in the Atom Protocol.
	Client Server		Client Server
	| |		| |
	skipping to change at page 10, line 5		skipping to change at page 12, line 5
	| |		| |
	| 2.) Atom Feed Doc |		| 2.) Atom Feed Doc |
	|<-------------------------------|		|<-------------------------------|
	| |		| |
	1. The client sends a GET request to the URI of the Collection.		1. The client sends a GET request to the URI of the Collection.
	2. The server responds with an Atom Feed Document containing the		2. The server responds with an Atom Feed Document containing the
	IRIs of the Collection members.		IRIs of the Collection members.
	5.3 Creating a Resource		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 |		| Location: Member Entry URI |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	skipping to change at page 10, line 27		skipping to change at page 12, line 27
	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 IRI of the newly created Member Entry Resource.		contains the IRI of the newly created Member Entry Resource.
	Media Resources could have also been created and their IRIs can		Media Resources could have also been created and their IRIs can
	be found through the Member Entry Resource. See Section 9.5 for		be found through the Member Entry Resource. See Section 9.5 for
	more details.		more details.
	5.4 Editing a Resource		5.4. Editing a Resource
	Once a resource has been created and its Member URI is known, that		Once a resource has been created and its Member URI is known, that
	URI can be used to retrieve, update, and delete the resource.		URI can be used to retrieve, update, and delete the resource.
	5.4.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 URI of a Member Resource to		1. The client sends a GET request to the URI of a Member Resource to
	retrieve 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.4.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 URI of a Member		1. The client PUTs an updated representation to the URI of a Member
	Resource.		Resource.
	2. If the update is successful the server responds with a status		2. If the update is successful the server responds with a status
	code of 200.		code of 200.
	5.4.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 URI of a Member		1. The client sends a DELETE request to the URI of a Member
	Resource.		Resource.
	2. If the deletion is successful the server responds with a status		2. If the deletion is successful the server responds with a status
	code of 200.		code of 200.
	A different approach is taken for deleting Media Resources, see		A different approach is taken for deleting Media Resources, see
	Section 9.5 for details.		Section 9.5 for details.
	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.
	Implementers are asked to note that per the HTTP specification, HTTP		Implementers are asked to note that according to the HTTP
	4xx and 5xx response entities SHOULD include a human-readable		specification, HTTP 4xx and 5xx response entities SHOULD include a
	explanation of the error.		human-readable explanation of the error.
	6. Atom Publishing Protocol Documents		6. Atom Publishing Protocol Documents
	6.1 Document Types		6.1. Document Types
	This specification describes two kinds of Documents - Category		This specification describes two kinds of Documents - Category
	Documents and Service Documents.		Documents and Service Documents.
	A Category Document (Section 7) contain lists of categories specified		A Category Document (Section 7) contains lists of categories
	using the "atom:category" element from the Atom Syndication Format.		specified using the "atom:category" element from the Atom Syndication
	A Service Document (Section 8) describes Workspaces, which are		Format. A Service Document (Section 8) describes Workspaces, which
	server-defined groups of Collections. This specification assigns no		are server-defined groups of Collections. This specification assigns
	meaning to Workspaces; that is, a Workspace does not imply any		no meaning to Workspaces; that is, a Workspace does not imply any
	specific processing assumptions. Operations on Workspaces		specific processing assumptions. Operations on Workspaces
	themselves, such as creation or deletion, are not defined by this		themselves, such as creation or deletion, are not defined by this
	specification.		specification.
	The namespace name [W3C.REC-xml-names-20060816] for either kind of		The namespace name [W3C.REC-xml-names] for either kind of document
	document is:		is:
	http://purl.org/atom/app#		http://purl.org/atom/app#
	[[anchor8: The namespace name needs to be updated with the final URI		[[anchor8: The namespace name needs to be updated with the final URI
	upon publication]]		upon publication]]
	This specification uses the prefix "app:" for the namespace name.		This specification uses the prefix "app:" for the namespace name.
	The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the		The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the
	namespace name of the Atom Syndication Format [RFC4287]. The		namespace name of the Atom Syndication Format [RFC4287]. The
	namespace prefixes are not semantically significant.		namespace prefixes are not semantically significant.
	Atom Publishing Protocol Documents MUST be well-formed XML. This		Atom Publishing Protocol Documents MUST be well-formed XML. This
	specification does not define any DTDs for Atom Protocol formats, and		specification does not define any DTDs for Atom Protocol formats, and
	hence does not require them to be "valid" in the sense used by XML.		hence does not require them to be "valid" in the sense used by XML.
	6.2 Document Extensibility		6.2. Document Extensibility
	Unrecognized markup in an Atom Publishing Protocol document is		Unrecognized markup in an Atom Publishing Protocol document is
	considered "foreign markup" as defined in [RFC4287]. Such foreign		considered "foreign markup" as defined in [RFC4287]. Such foreign
	markup can be used anywhere within a Category or Service Document		markup can be used anywhere within a Category or Service Document
	unless it is explicitly forbidden. Processors that encounter foreign		unless it is explicitly forbidden. Processors that encounter foreign
	markup MUST NOT stop processing and MUST NOT signal an error.		markup MUST NOT stop processing and MUST NOT signal an error.
	Clients SHOULD preserve foreign markup when transmitting such		Clients SHOULD preserve foreign markup when transmitting such
	documents.		documents.
	The namespace name "http://purl.org/atom/app#" is reserved for		The namespace name "http://purl.org/atom/app#" is reserved for
	forward compatible revisions of the Category and Service Document		forward compatible revisions of the Category and Service Document
	types - this does not exclude the addition of elements and attributes		types - this does not exclude the addition of elements and attributes
	that might not be recognized by processors conformant to this		that might not be recognized by processors conformant t