draft-ietf-atompub-protocol-10.txt		draft-ietf-atompub-protocol-11.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft IBM		Internet-Draft IBM
	Expires: March 9, 2007 B. de hOra, Ed.		Expires: April 6, 2007 B. de hOra, Ed.
	Propylon Ltd.		Propylon Ltd.
	September 05, 2006		October 03, 2006
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-10.txt		draft-ietf-atompub-protocol-11.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 March 9, 2007.		This Internet-Draft will expire on April 6, 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
	2.1 XML-related Conventions . . . . . . . . . . . . . . . . . 5		2.1 XML-related Conventions . . . . . . . . . . . . . . . . . 5
	2.1.1 Referring to Information Items . . . . . . . . . . . . 5		2.1.1 Referring to Information Items . . . . . . . . . . . . 5
	2.1.2 RELAX NG Schema . . . . . . . . . . . . . . . . . . . 5		2.1.2 RELAX NG Schema . . . . . . . . . . . . . . . . . . . 5
	2.1.3 Use of xml:base and xml:lang . . . . . . . . . . . . . 5		2.1.3 Use of xml:base and xml:lang . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 8		4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 10		5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 9
	5.1 Retrieving a Service Document . . . . . . . . . . . . . . 10		5.1 Retrieving a Service Document . . . . . . . . . . . . . . 9
	5.2 Listing Collection Members . . . . . . . . . . . . . . . . 10		5.2 Listing Collection Members . . . . . . . . . . . . . . . . 9
	5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 11		5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 10
	5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 11		5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 10
	5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 11		5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 10
	5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 12		5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 11
	5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 12		5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 11
	5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 12		5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 11
	6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 13		6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 12
	6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 13		6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 12
	6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 13		6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 12
	7. Category Documents . . . . . . . . . . . . . . . . . . . . . 14		7. Category Documents . . . . . . . . . . . . . . . . . . . . . 13
	7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14		7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14		7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 13
	7.2.1 The "app:categories" element . . . . . . . . . . . . . 14		7.2.1 The "app:categories" element . . . . . . . . . . . . . 13
	8. Service Documents . . . . . . . . . . . . . . . . . . . . . 16		8. Service Documents . . . . . . . . . . . . . . . . . . . . . 15
	8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
	8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 17		8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 17
	8.2.1 The "app:service" Element . . . . . . . . . . . . . . 17		8.2.1 The "app:service" Element . . . . . . . . . . . . . . 17
	8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 17		8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 17
	8.2.3 The "app:collection" Element . . . . . . . . . . . . . 18		8.2.3 The "app:collection" Element . . . . . . . . . . . . . 18
	8.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 19		8.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 19
	8.2.5 The "app:categories" Element . . . . . . . . . . . . . 20		8.2.5 The "app:categories" Element . . . . . . . . . . . . . 20
	9. Creating and Editing Resources . . . . . . . . . . . . . . . 22		9. Creating and Editing Resources . . . . . . . . . . . . . . . 22
	9.1 Member URIs . . . . . . . . . . . . . . . . . . . . . . . 22		9.1 Member URIs . . . . . . . . . . . . . . . . . . . . . . . 22
	9.2 Creating resources with POST . . . . . . . . . . . . . . . 22		9.2 Creating resources with POST . . . . . . . . . . . . . . . 22
	9.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . 23		9.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . 23
	9.3 Updating Resources with PUT . . . . . . . . . . . . . . . 24		9.3 Updating Resources with PUT . . . . . . . . . . . . . . . 24
	9.4 Deleting Resources with DELETE . . . . . . . . . . . . . . 24		9.4 Deleting Resources with DELETE . . . . . . . . . . . . . . 24
	9.5 Media Resources and Media Link Entries . . . . . . . . . . 24		9.5 Media Resources and Media Link Entries . . . . . . . . . . 24
	9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 25		9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 25
	9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 25		9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 25
	9.6.2 Examples . . . . . . . . . . . . . . . . . . . . . . . 26		9.6.2 Examples . . . . . . . . . . . . . . . . . . . . . . . 26
	10. Listing Collections . . . . . . . . . . . . . . . . . . . . 28		10. Listing Collections . . . . . . . . . . . . . . . . . . . . 28
	10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 28		10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 28
			10.2 The "app:edited" Element . . . . . . . . . . . . . . . . 29
	11. Atom Format Link Relation Extensions . . . . . . . . . . . . 30		11. Atom Format Link Relation Extensions . . . . . . . . . . . . 30
	11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 30		11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 30
	11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 30		11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 30
	12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 31		12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 31
	12.1 The "app:control" Element . . . . . . . . . . . . . . . 31		12.1 The "app:control" Element . . . . . . . . . . . . . . . 31
	12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 31		12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 31
	13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 32		13. Securing the Atom Publishing Protocol . . . . . . . . . . . 32
	14. Security Considerations . . . . . . . . . . . . . . . . . . 33		14. Security Considerations . . . . . . . . . . . . . . . . . . 33
			14.1 Denial of Service . . . . . . . . . . . . . . . . . . . 33
			14.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . . 33
			14.3 Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 33
			14.4 Linked Resources . . . . . . . . . . . . . . . . . . . . 33
			14.5 Digital Signatures and Encryption . . . . . . . . . . . 33
			14.6 URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 33
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
	15.1 Content-type registration for		15.1 Content-type registration for
	'application/atomserv+xml' . . . . . . . . . . . . . . . 34		'application/atomserv+xml' . . . . . . . . . . . . . . . 34
	15.2 Content-type registration for		15.2 Content-type registration for
	'application/atomcat+xml' . . . . . . . . . . . . . . . 35		'application/atomcat+xml' . . . . . . . . . . . . . . . 35
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37		15.3 Header field registration for 'SLUG' . . . . . . . . . . 36
	16.1 Normative References . . . . . . . . . . . . . . . . . . 37		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
	16.2 Informative References . . . . . . . . . . . . . . . . . 38		16.1 Normative References . . . . . . . . . . . . . . . . . . 38
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39		16.2 Informative References . . . . . . . . . . . . . . . . . 39
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
	B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 41		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
	C. Revision History . . . . . . . . . . . . . . . . . . . . . . 47		B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 42
	Intellectual Property and Copyright Statements . . . . . . . 50		C. Revision History . . . . . . . . . . . . . . . . . . . . . . 48
			Intellectual Property and Copyright Statements . . . . . . . 51
	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-20060816]. 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 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.
	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].
	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,
	the IRI is first converted to a URI according the procedure defined
	in [RFC3987] (Section 3.1). The resource identified by the URI after
	conversion is the same as the one identified by the IRI.
	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-20040204], serialized as XML 1.0
	[W3C.REC-xml-20040204].		[W3C.REC-xml-20060816].
	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-20040204].		1.0 [W3C.REC-xml-20060816].
	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]. IRIs are mapped to URIs		are defined in [RFC3986] and [RFC3987]. Before an IRI found in a
	before dereferencing takes place.		document is used by HTTP, the IRI is first converted to a URI (see
			Section 4
	The phrase "the URI of a document" in this specification is shorthand		The phrase "the URI of a document" in this specification is shorthand
	for "a URI which, when dereferenced, is expected to produce that		for "a URI which, when dereferenced, is expected to produce that
	document as a representation".		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.
	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 Entries. See
	Section 9.		Section 9.
	Member - A resource whose IRI is listed in a Collection by a link		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.		element with a relation of "edit" or "edit-media". See Section 9.1.
	Workspace - A group of collections. See Section 8.		Workspace - A group of collections. See Section 8.
	Service Document - A document that describes the location and		Service Document - A document that describes the location and
	capabilities of one or more Collections. See Section 8.		capabilities of one or more Collections. See Section 8.
	Category Document - A document that describes the categories allowed		Category Document - A document that describes the categories allowed
	in a Collection. See Section 7.		in a Collection. See Section 7.
	4. Protocol Model		4. Protocol Model
	The Atom Publishing Protocol uses HTTP methods to edit and author		The Atom Publishing Protocol uses HTTP methods to author Member
	Member Resources as follows:		Resources as follows:
	o GET is used to retrieve a representation of a known resource.		o GET is used to retrieve a representation of a known resource.
	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 known resource.		o DELETE is used to remove a known resource.
	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.		IRIs of, and metadata about, their Member Resources.
			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,
			the IRI is first converted to a URI according the procedure defined
			in Section 3.1 of [RFC3987]. The resource identified by the URI
			after conversion is the same as the one identified by the IRI.
	There are two kinds of Member Resources - Member Entry Resources and		There are two kinds of Member Resources - Member Entry Resources and
	Media Resources. Member Entry Resources are represented as Atom		Media Resources. Member Entry Resources are represented as Atom
	Entries. Media Resources MAY have representations in any media type.		Entries [RFC4287]. Media Resources can have representations in any
	A Media Link Entry is a Member Entry that contains metadata about a		media type. A Media Link Entry is a Member Entry that contains
	Media Resource. This diagram shows the classification of the		metadata about a Media Resource. This diagram shows 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		Collections, represented by Atom feeds, contain entries. Those
	entries contain the Member Entry and Media Resources IRIs of the		entries contain the Member Entry and Media Resources IRIs of the
	Collection. A Collection can contain any number of entries of either		Collection. A Collection can contain any number of entries of either
	kind. In the diagram of a Collection below there are two entries.		kind. In the diagram of a Collection below there are two entries.
	skipping to change at page 10, line 11		skipping to change at page 9, line 11
	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.
	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 URI of Service Document |		| 1.) GET to Service Document |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Service Document |		| 2.) Service Document |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to 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
	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 Listing Collection Members		5.2 Listing Collection Members
	To list the members of a Collection the client sends a GET request to		To list the members of a Collection, the client sends a GET request
	the URI of a Collection. An Atom Feed Document is returned		to the URI of a Collection. An Atom Feed Document is returned
	containing one Atom Entry for each Member Entry Resource. See		containing one Atom Entry for each Member Entry Resource. See
	Section 10 and Section 11 for a description of the feed contents.		Section 10 and Section 11 for a description of the feed contents.
	Client Server		Client Server
	| |		| |
	| 1.) GET to Collection URI |		| 1.) GET to Collection URI |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) 200 OK, Atom Feed Doc |		| 2.) 200 OK, Atom Feed Doc |
	|<-------------------------------|		|<-------------------------------|
	skipping to change at page 12, line 46		skipping to change at page 11, line 46
	with a status code of 200.		with a status 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.
	It is RECOMMENDED that entities contained within HTTP 4xx and 5xx		Implementers are asked to note that per the HTTP specification, HTTP
	responses include a human-readable explanation of the error.		4xx and 5xx response entities SHOULD include a 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) contain lists of categories specified
	using the "atom:category" element from the Atom Syndication Format.		using the "atom:category" element from the Atom Syndication Format.
	A Service Document (Section 8) describes capabilities of workspaces,		A Service Document (Section 8) describes capabilities of workspaces,
	which are server-defined groupings of Collections.		which are server-defined groupings of Collections.
	The namespace name [W3C.REC-xml-names-19990114] for either kind of		The namespace name [W3C.REC-xml-names-20060816] for either kind of
	document is:		document is:
	http://purl.org/atom/app#		http://purl.org/atom/app#
			[[anchor8: Needs to be updated with the final URI 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
	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.
	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].		considered "foreign markup" as defined in [RFC4287]. Such foreign
			markup can be used anywhere within a Category or Service Document
			unless it is explicitly forbidden. Processors that encounter foreign
			markup MUST NOT stop processing or signal an error, and SHOULD
			preserve foreign markup when transmitting such documents.
	Markup from other vocabularies ("foreign markup") can be used		The namespace name "http://purl.org/atom/app#" is reserved for
	anywhere within a Category or Service Document unless it is		forward compatible revisions of the Category and Service Document
	explicitly forbidden. Processors that encounter foreign markup MUST		types - this does not exclude the addition of elements and attributes
	NOT stop processing or signal an error, and SHOULD preserve foreign		that might not be recognised by processors conformant to this
	markup when transmitting such documents.		specification. Such unrecognised markup from the
			"http://purl.org/atom/app#" namespace MUST be treated as foreign
			markup.
	7. Category Documents		7. Category Documents
	Category Documents contain lists of categories described using the		Category Documents contain lists of categories described using the
	"atom:category" element from the Atom Syndication Format [RFC4287].		"atom:category" element from the Atom Syndication Format [RFC4287].
	Categories can also appear in Service Documents and describe the		Categories can also appear in Service Documents and describe the
	categories allowed in a Collection (see Section 8.2.5).		categories allowed in a Collection (see Section 8.2.5).
	Category Documents are identified with the "application/atomcat+xml"		Category Documents are identified with the "application/atomcat+xml"
	media type (see Section 15).		media type (see Section 15).
	skipping to change at page 14, line 27		skipping to change at page 13, line 27
	<?xml version="1.0" ?>		<?xml version="1.0" ?>
	<app:categories		<app:categories
	xmlns:app="http://purl.org/atom/app#"		xmlns:app="http://purl.org/atom/app#"
	xmlns="http://www.w3.org/2005/Atom"		xmlns="http://www.w3.org/2005/Atom"
	fixed="yes" scheme="http://example.com/cats/big3">		fixed="yes" scheme="http://example.com/cats/big3">
	<category term="animal" />		<category term="animal" />
	<category term="vegetable" />		<category term="vegetable" />
	<category term="mineral" />		<category term="mineral" />
	</app:categories>		</app:categories>
	This Category Document contains three categories with the terms		This Category Document contains three categories, with the terms
	"animal", "vegetable", and "mineral". None of the categories has a		"animal", "vegetable", and "mineral". None of the categories use the
	label attribute (as defined in [RFC4287]). They all inherit the		'label' attribute defined in [RFC4287]. They all inherit the
	"http://example.com/cats/big3" category 'scheme' (in the [RFC4287]		"http://example.com/cats/big3" 'scheme' attribute declared on the
	sense) declared on the app:categories element. Therefore if the		app:categories element. Therefore if the "mineral" category were to
	"mineral" category were to appear in an Atom Entry or Feed Document,		appear in an Atom Entry or Feed Document, it would appear as:
	it would appear as:
	<category scheme="http://example.com/cats/big3" term="mineral" />		<category scheme="http://example.com/cats/big3" term="mineral" />
	7.2 Element Definitions		7.2 Element Definitions
	7.2.1 The "app:categories" element		7.2.1 The "app:categories" element
	The root of a Category Document is the "app:categories" element. An		The root of a Category Document is the "app:categories" element. An
	app:categories element MAY contain one or more "atom:category"		app:categories element can contain zero or more "atom:category"
	elements from the Atom namespace ("http://www.w3.org/2005/Atom").		elements from the Atom namespace ("http://www.w3.org/2005/Atom").
	If an app:category child element has no "scheme" attribute it		An app:category child element that has no "scheme" attribute inherits
	inherits the attribute from its app:categories parent. An app:		the attribute from its app:categories parent. An app:category child
	category child element with an existing "scheme" attribute does not		element with an existing "scheme" attribute does not inherit the
	inherit the "scheme" value of its "app:categories" parent element.		"scheme" value of its "app:categories" parent element.
	7.2.1.1 Attributes of "app:categories"		7.2.1.1 Attributes of "app:categories"
	The app:categories element MAY contain a "fixed" attribute, with a		The app:categories element can contain a "fixed" attribute, with a
	value of either "yes" or "no", indicating if the list of categories		value of either "yes" or "no", indicating whether the list of
	is a fixed or an open set. Collections that indicate the set is		categories is a fixed or an open set. Newly created or updated
	fixed MAY reject members whose categories are not listed in the		members whose categories are not listed in the Collection Document
	Collection Document. Collections that indicate the set is open		MAY be rejected by the server. Collections that indicate the set is
	SHOULD NOT reject otherwise acceptable members whose categories are		open SHOULD NOT reject otherwise acceptable members whose categories
	not listed in the Collection.		are not listed in the Collection.
	Alternatively, the app:categories element MAY contain an "href"		Alternatively, the app:categories element MAY contain an "href"
	attribute, whose value MUST be an IRI reference identifying a		attribute, whose value MUST be an IRI reference identifying a
	Category Document. If the "href" attribute is provided, the app:		Category Document. If the "href" attribute is provided the app:
	categories element MUST be empty and MUST NOT have the "fixed" or		categories element MUST be empty and MUST NOT have the "fixed" or
	"scheme" attributes.		"scheme" attributes.
	atomCategory =		atomCategory =
	element atom:category {		element atom:category {
	atomCommonAttributes,		atomCommonAttributes,
	attribute term { text },		attribute term { text },
	attribute scheme { atomURI }?,		attribute scheme { atomURI }?,
	attribute label { text }?,		attribute label { text }?,
	undefinedContent		undefinedContent
	skipping to change at page 15, line 40		skipping to change at page 14, line 36
	appInlineCategories =		appInlineCategories =
	element app:categories {		element app:categories {
	attribute fixed { "yes" | "no" }?,		attribute fixed { "yes" | "no" }?,
	attribute scheme { atomURI }?,		attribute scheme { atomURI }?,
	(atomCategory*)		(atomCategory*)
	}		}
	appOutOfLineCategories =		appOutOfLineCategories =
	element app:categories {		element app:categories {
	attribute href { atomURI },		attribute href { atomURI },
	(empty)		undefinedContent
	}		}
	appCategories = appInlineCategories | appOutOfLineCategories		appCategories = appInlineCategories | appOutOfLineCategories
	8. Service Documents		8. Service Documents
	For authoring to commence, a client needs to first discover the		For authoring to commence, a client needs to first discover the
	capabilities and locations of the available collections. Service		capabilities and locations of the available collections. Service
	Documents are designed to support this discovery process.		Documents are designed to support this discovery process. How
			Service Documents are in turn discovered is not defined in this
			specification.
	A Service Document describes workspaces, which are server-defined		A Service Document describes workspaces, which are server-defined
	groupings of Collections. Service Documents are identified with the		groupings of Collections. Service Documents are identified with the
	"application/atomserv+xml" media type (see Section 15).		"application/atomserv+xml" media type (see Section 15).
	There is no requirement that a server support multiple workspaces.		There is no requirement that a server support multiple workspaces.
	In addition, a Collection MAY appear in more than one Workspace.		In addition, a Collection MAY appear in more than one Workspace.
	8.1 Example		8.1 Example
	skipping to change at page 18, line 10		skipping to change at page 17, line 42
	8.2.2 The "app:workspace" Element		8.2.2 The "app:workspace" Element
	The "app:workspace" element contains information elements about the		The "app:workspace" element contains information elements about the
	collections of resources available for editing. The app:workspace		collections of resources available for editing. The app:workspace
	element contains zero or more app:collection elements.		element contains zero or more app:collection elements.
	appWorkspace =		appWorkspace =
	element app:workspace {		element app:workspace {
	appCommonAttributes,		appCommonAttributes,
	( appCollection*		( atomTitle
			& appCollection*
	& extensionElement* )		& extensionElement* )
	}		}
	atomTitle = element atom:title { atomTextConstruct }		atomTitle = element atom:title { atomTextConstruct }
	In an app:workspace element, the first app:collection element MUST		In an app:workspace element, the first app:collection element MUST
	refer to the preferred or primary Collection. In the following		refer to the preferred or primary Collection. This distinction is
	example, the "Entries" collection would be considered the preferred		considered useful in scenarios where Members and Media Link Entries
			are POSTed to different Collections. In the following example, the
			"Eintragungen" collection would be considered the preferred
	Collection:		Collection:
	<service xmlns="http://purl.org/atom/app#"		<service xmlns="http://purl.org/atom/app#"
	xmlns:atom="http://www.w3.org/2005/Atom">		xmlns:atom="http://www.w3.org/2005/Atom">
	<workspace>		<workspace xml:lang="de">
	<atom:title>My Blog</atom:title>		<atom:title>Das Blog</atom:title>
	<collection		<collection
	href="http://example.org/myblog/entries" >		href="http://example.org/blog/eintragungen" >
	<atom:title>Entries</atom:title>		<atom:title>Eintragungen</atom:title>
	</collection>		</collection>
	<collection		<collection
	href="http://example.org/myblog/fotes">		href="http://example.org/blog/fotos">
	<atom:title>Photos</atom:title>		<atom:title>Fotos</atom:title>
	<accept>image/*</accept>		<accept>image/*</accept>
	</collection>		</collection>
	</workspace>		</workspace>
	</service>		</service>
	8.2.2.1 The "atom:title" Element		8.2.2.1 The "atom:title" Element
	The app:workspace element MUST contain one "atom:title" element,		The app:workspace element MUST contain one "atom:title" element (as
	giving a human-readable title for the workspace.		defined in [RFC4287]), giving a human-readable title for the
			workspace.
	8.2.3 The "app:collection" Element		8.2.3 The "app:collection" Element
	The "app:collection" element describes a Collection. The app:		The "app:collection" element describes a Collection. The app:
	collection element MAY contain one app:accept element and MAY contain		collection element MAY contain one app:accept element and MAY contain
	any number of app:categories elements. The app:collection element		any number of app:categories elements. The app:collection element