draft-ietf-atompub-protocol-13.txt		draft-ietf-atompub-protocol-14.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft IBM		Internet-Draft IBM
	Intended status: Standards Track B. de hOra, Ed.		Intended status: Standards Track B. de hOra, Ed.
	Expires: August 9, 2007 Propylon Ltd.		Expires: September 5, 2007 Propylon Ltd.
	February 5, 2007		March 4, 2007
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-13.txt		draft-ietf-atompub-protocol-14.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 August 9, 2007.		This Internet-Draft will expire on September 5, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		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 transfer 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	skipping to change at page 3, line 38		skipping to change at page 3, line 38
	5.4.3. Deleting a Resource . . . . . . . . . . . . . . . . . 13		5.4.3. Deleting a Resource . . . . . . . . . . . . . . . . . 13
	5.5. Use of HTTP Response codes . . . . . . . . . . . . . . . . 13		5.5. Use of HTTP Response codes . . . . . . . . . . . . . . . . 13
	6. Atom Publishing Protocol Documents . . . . . . . . . . . . . . 14		6. Atom Publishing Protocol Documents . . . . . . . . . . . . . . 14
	6.1. Document Types . . . . . . . . . . . . . . . . . . . . . . 14		6.1. Document Types . . . . . . . . . . . . . . . . . . . . . . 14
	6.2. Document Extensibility . . . . . . . . . . . . . . . . . . 14		6.2. Document Extensibility . . . . . . . . . . . . . . . . . . 14
	7. Category Documents . . . . . . . . . . . . . . . . . . . . . . 16		7. Category Documents . . . . . . . . . . . . . . . . . . . . . . 16
	7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16		7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7.2. Element Definitions . . . . . . . . . . . . . . . . . . . 16		7.2. Element Definitions . . . . . . . . . . . . . . . . . . . 16
	7.2.1. The "app:categories" element . . . . . . . . . . . . . 16		7.2.1. The "app:categories" element . . . . . . . . . . . . . 16
	8. Service Documents . . . . . . . . . . . . . . . . . . . . . . 18		8. Service Documents . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19		8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.2. Element Definitions . . . . . . . . . . . . . . . . . . . 20		8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.2.1. The "app:service" Element . . . . . . . . . . . . . . 20		8.3. Element Definitions . . . . . . . . . . . . . . . . . . . 20
	8.2.2. The "app:workspace" Element . . . . . . . . . . . . . 20		8.3.1. The "app:service" Element . . . . . . . . . . . . . . 20
	8.2.3. The "app:collection" Element . . . . . . . . . . . . . 21		8.3.2. The "app:workspace" Element . . . . . . . . . . . . . 20
	8.2.4. The "app:accept" Element . . . . . . . . . . . . . . . 21		8.3.3. The "app:collection" Element . . . . . . . . . . . . . 21
	8.2.5. The "app:categories" Element . . . . . . . . . . . . . 22		8.3.4. The "app:accept" Element . . . . . . . . . . . . . . . 21
			8.3.5. The "app:categories" Element . . . . . . . . . . . . . 22
	9. Creating and Editing Resources . . . . . . . . . . . . . . . . 24		9. Creating and Editing Resources . . . . . . . . . . . . . . . . 24
	9.1. Member URIs . . . . . . . . . . . . . . . . . . . . . . . 24		9.1. Member URIs . . . . . . . . . . . . . . . . . . . . . . . 24
	9.2. Creating resources with POST . . . . . . . . . . . . . . . 24		9.2. Creating resources with POST . . . . . . . . . . . . . . . 24
	9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 25		9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 25
	9.3. Updating Resources with PUT . . . . . . . . . . . . . . . 26		9.3. Updating Resources with PUT . . . . . . . . . . . . . . . 26
	9.4. Deleting Resources with DELETE . . . . . . . . . . . . . . 26		9.4. Deleting Resources with DELETE . . . . . . . . . . . . . . 26
	9.5. Media Resources and Media Link Entries . . . . . . . . . . 26		9.5. Caching and entity tags . . . . . . . . . . . . . . . . . 26
	9.5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 27		9.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 26
	9.6. The Slug: Header . . . . . . . . . . . . . . . . . . . . . 32		9.6. Media Resources and Media Link Entries . . . . . . . . . . 28
	9.6.1. Slug: Header syntax . . . . . . . . . . . . . . . . . 33		9.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 29
	9.6.2. Example . . . . . . . . . . . . . . . . . . . . . . . 33		9.7. The Slug: Header . . . . . . . . . . . . . . . . . . . . . 35
	10. Listing Collections . . . . . . . . . . . . . . . . . . . . . 34		9.7.1. Slug: Header syntax . . . . . . . . . . . . . . . . . 36
	10.1. Collection Paging . . . . . . . . . . . . . . . . . . . . 34		9.7.2. Example . . . . . . . . . . . . . . . . . . . . . . . 36
	10.2. The "app:edited" Element . . . . . . . . . . . . . . . . . 35		10. Listing Collections . . . . . . . . . . . . . . . . . . . . . 37
	11. Atom Format Link Relation Extensions . . . . . . . . . . . . . 36		10.1. Collection partial lists . . . . . . . . . . . . . . . . . 37
	11.1. The "edit" Link Relation . . . . . . . . . . . . . . . . . 36		10.2. The "app:edited" Element . . . . . . . . . . . . . . . . . 38
	11.2. The "edit-media" Link Relation . . . . . . . . . . . . . . 36		11. Atom Format Link Relation Extensions . . . . . . . . . . . . . 40
	12. The Atom Format Type Parameter . . . . . . . . . . . . . . . . 37		11.1. The "edit" Link Relation . . . . . . . . . . . . . . . . . 40
	12.1. The 'type' parameter . . . . . . . . . . . . . . . . . . . 37		11.2. The "edit-media" Link Relation . . . . . . . . . . . . . . 40
	12.1.1. Conformance . . . . . . . . . . . . . . . . . . . . . 37		12. The Atom Format Type Parameter . . . . . . . . . . . . . . . . 41
	13. Atom Publishing Controls . . . . . . . . . . . . . . . . . . . 38		12.1. The 'type' parameter . . . . . . . . . . . . . . . . . . . 41
	13.1. The "app:control" Element . . . . . . . . . . . . . . . . 38		12.1.1. Conformance . . . . . . . . . . . . . . . . . . . . . 41
	13.1.1. The "app:draft" Element . . . . . . . . . . . . . . . 38		13. Atom Publishing Controls . . . . . . . . . . . . . . . . . . . 42
	14. Securing the Atom Publishing Protocol . . . . . . . . . . . . 39		13.1. The "app:control" Element . . . . . . . . . . . . . . . . 42
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 40		13.1.1. The "app:draft" Element . . . . . . . . . . . . . . . 42
	15.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 40		14. Securing the Atom Publishing Protocol . . . . . . . . . . . . 43
	15.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 40		15. Security Considerations . . . . . . . . . . . . . . . . . . . 44
	15.3. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . 40		15.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 44
	15.4. Linked Resources . . . . . . . . . . . . . . . . . . . . . 40		15.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 44
	15.5. Digital Signatures and Encryption . . . . . . . . . . . . 40		15.3. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . 44
	15.6. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 40		15.4. Linked Resources . . . . . . . . . . . . . . . . . . . . . 44
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41		15.5. Digital Signatures and Encryption . . . . . . . . . . . . 44
			15.6. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 44
			16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
	16.1. Content-type registration for		16.1. Content-type registration for
	'application/atomserv+xml' . . . . . . . . . . . . . . . . 41		'application/atomserv+xml' . . . . . . . . . . . . . . . . 45
	16.2. Content-type registration for 'application/atomcat+xml' . 42		16.2. Content-type registration for 'application/atomcat+xml' . 46
	16.3. Header field registration for 'SLUG' . . . . . . . . . . . 43		16.3. Header field registration for 'SLUG' . . . . . . . . . . . 47
	16.4. The Link Relation registration "edit" . . . . . . . . . . 44		16.4. The Link Relation registration "edit" . . . . . . . . . . 48
	16.5. The Link Relation registration "edit-media" . . . . . . . 44		16.5. The Link Relation registration "edit-media" . . . . . . . 48
	16.6. The Atom Format Media Type Parameter . . . . . . . . . . . 44		16.6. The Atom Format Media Type Parameter . . . . . . . . . . . 48
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 45		17.1. Normative References . . . . . . . . . . . . . . . . . . . 49
	17.2. Informative References . . . . . . . . . . . . . . . . . . 46		17.2. Informative References . . . . . . . . . . . . . . . . . . 50
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 48		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 52
	Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 49		Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 53
	Appendix C. Revision History . . . . . . . . . . . . . . . . . . 55		Appendix C. Revision History . . . . . . . . . . . . . . . . . . 59
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 58		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63
	Intellectual Property and Copyright Statements . . . . . . . . . . 59		Intellectual Property and Copyright Statements . . . . . . . . . . 64
	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]. The protocol supports the creation of Web resources		[W3C.REC-xml]. The protocol supports the creation of 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 Services: Discovery and description of Collections.
	o Editing: Creating, updating and deleting resources.		o Editing: Creating, updating and deleting resources.
	The Atom Publishing Protocol is different from many contemporary		The Atom Publishing Protocol is different from many contemporary
	protocols in that the server is given wide latitude in processing		protocols in that the server is given wide latitude in processing
	requests from clients. See Section 4 for more details.		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",
	skipping to change at page 6, line 43		skipping to change at page 6, line 43
	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. Requirements regarding the content and
	significant for elements and attributes declared to be "Language-		interpretation of xml:lang are specified in Section 2.12 of XML 1.0
	Sensitive" by this specification. Requirements regarding the content		[W3C.REC-xml].
	and interpretation of xml:lang are specified in Section 2.12 of XML
	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
	Section 4).		Section 4).
	The phrase "the URI of a document" in this specification is shorthand		In this specification the phrase "the URI of a document" 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 Entries. 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.
			The protocol defines two kinds of Members - Entry and Media
			resources.
	Workspace - A named group of Collections. See Section 8.		Entry Resource - Member Resources of a Collection that are
			represented using the "application/atom+xml" media type.
			Media Resource -Member Resources of a Collection that are represented
			with a media type other than "application/atom+xml".
			Media Link Entry - an Entry Resource that contains metadata about a
			Media Resource.
			Workspace - A named group of Collections. See Section 8.1.
	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 author Member		The Atom Publishing Protocol uses HTTP methods to author Member
	skipping to change at page 8, 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.
	This document does not specify the form of the URIs that are used.		The Atom Protocol does not specify the form of the URIs that are
	HTTP ([RFC2616]) specifies that the URI space of each server is		used. HTTP ([RFC2616]) specifies that the URI space of each server
	controlled by that server and the Atom Protocol imposes no		is controlled by that server, and this protocol imposes no further
	constraints on that control. What this RFC does specify are the		constraints on that control. What is specified here are the formats
	formats of the representations that are exchanged and the actions		of the representations that are exchanged and the actions that can be
	that can be performed on the IRIs embedded in those documents.		performed on the IRIs embedded in those representations.
	This document only covers the creation, update and deletion of Entry		The Atom Protocol only covers the creation, update and deletion of
	and Media resources. Other resources can be created, updated, and		Entry and Media resources. Other resources could be created,
	deleted as the result of manipulating a Collection, but the number of		updated, and deleted as the result of manipulating a Collection, but
	those resources, their media-types, and effects of Atom Protocol		the number of those resources, their media-types, and effects of Atom
	operations on them are outside the scope of this specification.		Protocol 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		The representation of Collections are Atom Feed documents, and
	IRIs of, and metadata about, their Member Resources. The Atom		contain the IRIs of, and metadata about the Collection's Member
	Protocol does not make a structural distinction between Feeds used		Resources. The Atom Protocol does not make a structural distinction
	for Collections and other Atom Feeds. The only mechanism that this		between Feeds used for Collections and other Atom Feeds. The only
	specification supplies for distinguishing a Collection Feed is its		mechanism that this specification supplies for indicating a
	appearance in a Service Document.		Collection Feed is its 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. Conversion
	the URI into which it is converted, identify the same resource.		does not imply resource creation - the IRI and the URI into which it
			is converted identify the same resource.
	There are two kinds of Member Resources - Member Entry Resources and		There are two kinds of Member Resources - Entry Resources and Media
	Media Resources. Member Entry Resources are represented as Atom		Resources. Entry Resources are represented as Atom Entries
	Entries [RFC4287]. Media Resources can have representations in any		[RFC4287]. Media Resources can have representations in any media
	media type. A Media Link Entry is a Member Entry that contains		type. A Media Link Entry is an Entry Resource that contains metadata
	metadata about a Media Resource. This diagram shows the		about a Media Resource. This diagram shows the classification of the
	classification of the resources:		resources:
	Member Resource		Member Resource
	-> Member Entry Resource		-> Entry Resource
	-> Media Link Entry Resource		-> Media Link Entry
	-> Media Resource		-> Media Resource
	A Collection's Atom Entries contain the Member Entry and Media		A Collection Feed's Atom Entries contain the Entry and Media Resource
	Resources IRIs of the Collection. A Collection can contain any		IRIs of the Collection. A Collection Feed can contain any number of
	number of Entries for either kind. In the diagram of a Collection		Entries for either kind, or an ordered subset of the Entries (see
	below, there are two Entries. The first contains the IRI of a Member		Section 10.1). In the diagram of a Collection below, there are two
	Entry Resource. The second contains the IRIs of both a Media		Entries. The first contains the IRI of an Entry Resource. The
	Resource and a Media Link Entry Resource, which contains the metadata		second contains the IRIs of both a Media Resource and a Media Link
	for that Media Resource:		Entry Resource, which contains the metadata for that Media Resource:
	Collection		Collection
	Entry		Entry
	Member Entry IRI -> Member Entry Resource		Member Entry IRI -> Entry Resource
	Entry		Entry
	Member Entry IRI -> Media Link Entry Resource		Member Entry IRI -> Media Link Entry
	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		4.1. Client Implementation Considerations
	The Atom Protocol imposes few restrictions on the actions of servers.		The Atom Protocol imposes few restrictions on the actions of servers.
	Unless a constraint is specified here, servers can be expected to		Unless a constraint is specified here, servers can be expected to
	vary in behavior, in particular around the manipulation of Atom		vary in behavior, in particular around the manipulation of Atom
	Entries sent by clients. For example, although this specification		Entries sent by clients. For example, although this specification
	only defines the expected behavior of Collections with respect to GET		only defines the expected behavior of Collections with respect to GET
	and POST, this does not imply that PUT, DELETE, PROPPATCH and others		and POST, this does not imply that PUT, DELETE, PROPPATCH and others
	are forbidden on Collection resources - only that this specification		are forbidden on Collection resources - only that this specification
	does not define what the servers response would be to those methods.		does not define what the server's response would be to those methods.
	Similarly while some HTTP status codes are mentioned explicitly,		Similarly while some HTTP status codes are mentioned explicitly,
	clients should be prepared to handle any status code from a server.		clients ought to be prepared to handle any status code from a server.
	Servers can choose to accept, reject, delay, moderate, censor,		Servers can choose to accept, reject, delay, moderate, censor,
	reformat, translate, relocate or recategorize the content submitted		reformat, translate, relocate or recategorize the content submitted
	to them. Only some of these choices are immediately relayed back to		to them. Only some of these choices are immediately relayed back to
	the client in responses to client requests; other choices may only		the client in responses to client requests; other choices may only
	become apparent later, in the feed or published entries. The same		become apparent later, in the feed or published entries. The same
	series of requests to two different publishing sites can result in a		series of requests to two different publishing sites can result in a
	different series of HTTP responses, different resulting feeds or		different series of HTTP responses, different resulting feeds or
	different entry contents.		different entry contents.
	As a result, client software has to be written flexibly to accept		As a result, client software has to be written flexibly to accept
	skipping to change at page 11, line 32		skipping to change at page 11, line 32
	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 partial list of the Members in a Collection
	Section 10). Section 11 describes extensions to the Atom Syndication		(see Section 10).
	Format used in the Atom Protocol.
	Client Server		Client Server
	| |		| |
	| 1.) GET to Collection URI |		| 1.) GET to Collection URI |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) Atom Feed Doc |		| 2.) Atom Feed Doc |
	|<-------------------------------|		|<-------------------------------|
	| |		| |
	skipping to change at page 12, line 22		skipping to change at page 12, line 22
	| 2.) 201 Created |		| 2.) 201 Created |
	| Location: Member Entry URI |		| 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 IRI of the newly created Member Entry Resource.		contains the IRI of the newly created Entry Resource. Media
	Media Resources could have also been created and their IRIs can		Resources could have also been created and their IRIs can be
	be found through the Member Entry Resource. See Section 9.5 for		found through the Entry Resource. See Section 9.6 for more
	more details.		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.
			Section 11 describes extensions to the Atom Syndication Format used
			in the Atom Protocol for editing purposes.
	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 |
	|<------------------------------------------|		|<------------------------------------------|
	skipping to change at page 13, line 28		skipping to change at page 13, line 28
	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.6 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 according to the HTTP		Implementers are asked to note that according to the HTTP
	specification, HTTP 4xx and 5xx response entities SHOULD include a		specification, HTTP 4xx and 5xx response entities SHOULD include a
	human-readable 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 defines two kinds of Documents - Category
	Documents and Service Documents.		Documents and Service Documents.
	A Category Document (Section 7) contains lists of categories		A Category Document (Section 7) contains lists of categories
	specified using the "atom:category" element from the Atom Syndication		specified using the "atom:category" element from the Atom Syndication
	Format. A Service Document (Section 8) describes Workspaces, which		Format.
	are server-defined groups of Collections. This specification assigns
	no meaning to Workspaces; that is, a Workspace does not imply any		A Service Document (Section 8) groups available Collections into
	specific processing assumptions. Operations on Workspaces		Workspaces.
	themselves, such as creation or deletion, are not defined by this
	specification.
	The namespace name [W3C.REC-xml-names] for either kind of document		The namespace name [W3C.REC-xml-names] for either kind of 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]. These
	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 Section 6 of [RFC4287].
	markup can be used anywhere within a Category or Service Document		Such foreign markup can be used anywhere within a Category or Service
	unless it is explicitly forbidden. Processors that encounter foreign		Document unless it is explicitly forbidden. Processors that
	markup MUST NOT stop processing and MUST NOT signal an error.		encounter foreign markup MUST NOT stop processing and MUST NOT signal
	Clients SHOULD preserve foreign markup when transmitting such		an error. Clients SHOULD preserve foreign markup when transmitting
	documents.		such 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 to this
	specification. Such unrecognized markup from the		specification. Such unrecognized markup from the
	"http://purl.org/atom/app#" namespace MUST be treated as foreign		"http://purl.org/atom/app#" namespace MUST be treated as foreign
	markup.		markup.
	[[anchor9: The namespace name needs to be updated with the final URI		[[anchor9: The namespace name needs to be updated with the final URI
	upon publication]]		upon publication]]
	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, where they describe		Categories can also appear in Service Documents, where they describe
	the categories allowed in a Collection (see Section 8.2.5).		the categories allowed in a Collection (see Section 8.3.5).
	Category Documents are identified with the "application/atomcat+xml"		Category Documents are identified with the "application/atomcat+xml"
	media type (see Section 16).		media type (see Section 16).
	7.1. Example		7.1. Example
	<?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"
	skipping to change at page 16, line 49		skipping to change at page 17, line 5
	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 can contain zero 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").
	An app:category child element that has no "scheme" attribute inherits		An app:category child element that has no "scheme" attribute inherits
	the attribute from its app:categories parent. An app:category child		the attribute from its app:categories parent. An app:category child
	element with an existing "scheme" attribute does not inherit the		element with an existing "scheme" attribute does not 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"
	The app:categories element can contain a "fixed" attribute, with a
	value of either "yes" or "no", indicating whether the list of
	categories is a fixed or an open set. Attempts to create or update
	members whose categories are not listed in the Collection Document
	MAY be rejected by the server. Collections that indicate the
	category set is open SHOULD NOT reject otherwise acceptable members
	whose categories are not listed by the Collection.
	Alternatively, the app:categories element MAY contain an "href"
	attribute, whose value MUST be an IRI reference identifying a
	Category Document. If the "href" attribute is provided, the app:
	categories element MUST be empty and MUST NOT have the "fixed" or
	"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
	}		}
	appInlineCategories =		appInlineCategories =
	skipping to change at page 18, line 5		skipping to change at page 17, line 29
	}		}