draft-ietf-atompub-protocol-11.txt		draft-ietf-atompub-protocol-12.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft IBM		Internet-Draft IBM
	Expires: April 6, 2007 B. de hOra, Ed.		Expires: June 13, 2007 B. de hOra, Ed.
	Propylon Ltd.		Propylon Ltd.
	October 03, 2006		December 10, 2006
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-11.txt		draft-ietf-atompub-protocol-12.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 April 6, 2007.		This Internet-Draft will expire on June 13, 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
	skipping to change at page 2, line 29		skipping to change at page 2, line 29
	5.2 Listing Collection Members . . . . . . . . . . . . . . . . 9		5.2 Listing Collection Members . . . . . . . . . . . . . . . . 9
	5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 10		5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 10
	5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 10		5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 10
	5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 10		5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 10
	5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 11		5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 11
	5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 11		5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 11
	5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 11		5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 11
	6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 12		6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 12
	6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 12		6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 12
	6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 12		6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 12
	7. Category Documents . . . . . . . . . . . . . . . . . . . . . 13		7. Category Documents . . . . . . . . . . . . . . . . . . . . . 14
	7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 13		7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14
	7.2.1 The "app:categories" element . . . . . . . . . . . . . 13		7.2.1 The "app:categories" element . . . . . . . . . . . . . 14
	8. Service Documents . . . . . . . . . . . . . . . . . . . . . 15		8. Service Documents . . . . . . . . . . . . . . . . . . . . . 16
	8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16		8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 17		8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 18
	8.2.1 The "app:service" Element . . . . . . . . . . . . . . 17		8.2.1 The "app:service" Element . . . . . . . . . . . . . . 18
	8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 17		8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 18
	8.2.3 The "app:collection" Element . . . . . . . . . . . . . 18		8.2.3 The "app:collection" Element . . . . . . . . . . . . . 19
	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 . . . . . . . . . . 25
	9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 25		9.5.1 Examples . . . . . . . . . . . . . . . . . . . . . . . 26
	9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 25		9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 31
	9.6.2 Examples . . . . . . . . . . . . . . . . . . . . . . . 26		9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 32
	10. Listing Collections . . . . . . . . . . . . . . . . . . . . 28		9.6.2 Example . . . . . . . . . . . . . . . . . . . . . . . 32
	10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 28		10. Listing Collections . . . . . . . . . . . . . . . . . . . . 33
	10.2 The "app:edited" Element . . . . . . . . . . . . . . . . 29		10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 33
	11. Atom Format Link Relation Extensions . . . . . . . . . . . . 30		10.2 The "app:edited" Element . . . . . . . . . . . . . . . . 34
	11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 30		11. Atom Format Link Relation Extensions . . . . . . . . . . . . 35
	11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 30		11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 35
	12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 31		11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 35
	12.1 The "app:control" Element . . . . . . . . . . . . . . . 31		12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 36
	12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 31		12.1 The "app:control" Element . . . . . . . . . . . . . . . 36
	13. Securing the Atom Publishing Protocol . . . . . . . . . . . 32		12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 36
	14. Security Considerations . . . . . . . . . . . . . . . . . . 33		13. Securing the Atom Publishing Protocol . . . . . . . . . . . 37
	14.1 Denial of Service . . . . . . . . . . . . . . . . . . . 33		14. Security Considerations . . . . . . . . . . . . . . . . . . 38
	14.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . . 33		14.1 Denial of Service . . . . . . . . . . . . . . . . . . . 38
	14.3 Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 33		14.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . . 38
	14.4 Linked Resources . . . . . . . . . . . . . . . . . . . . 33		14.3 Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 38
	14.5 Digital Signatures and Encryption . . . . . . . . . . . 33		14.4 Linked Resources . . . . . . . . . . . . . . . . . . . . 38
	14.6 URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 33		14.5 Digital Signatures and Encryption . . . . . . . . . . . 38
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34		14.6 URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 38
			15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 39
	15.1 Content-type registration for		15.1 Content-type registration for
	'application/atomserv+xml' . . . . . . . . . . . . . . . 34		'application/atomserv+xml' . . . . . . . . . . . . . . . 39
	15.2 Content-type registration for		15.2 Content-type registration for
	'application/atomcat+xml' . . . . . . . . . . . . . . . 35		'application/atomcat+xml' . . . . . . . . . . . . . . . 40
	15.3 Header field registration for 'SLUG' . . . . . . . . . . 36		15.3 Header field registration for 'SLUG' . . . . . . . . . . 41
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
	16.1 Normative References . . . . . . . . . . . . . . . . . . 38		16.1 Normative References . . . . . . . . . . . . . . . . . . 43
	16.2 Informative References . . . . . . . . . . . . . . . . . 39		16.2 Informative References . . . . . . . . . . . . . . . . . 44
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 45
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46
	B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 42		B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 47
	C. Revision History . . . . . . . . . . . . . . . . . . . . . . 48		C. Revision History . . . . . . . . . . . . . . . . . . . . . . 53
	Intellectual Property and Copyright Statements . . . . . . . 51		Intellectual Property and Copyright Statements . . . . . . . 56
	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-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
	skipping to change at page 6, line 14		skipping to change at page 6, line 14
	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		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 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.
	Workspace - A group of collections. See Section 8.		Workspace - A named 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 author Member		The Atom Publishing Protocol uses HTTP methods to author 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. When
			the client submits non-Atom-Entry representations to a Collection
			for creation, two resources are always created - a Media Entry for
			the requested resource, and a Media Link Entry for metadata (in
			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.
	Along with operations on Member Resources the Atom Protocol defines		The Atom Protocol imposes few restrictions on the actions of servers.
	Collection resources for managing and organizing Member Resources.		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.
			HTTP ([RFC2616]) specifies that the URI space of each server is
			controlled by that server and the Atom Protocol imposes no
			constraints on that control. What this RFC does specify are the
			formats of the representations that are exchanged and the actions
			that can be performed on the IRIs embedded in those documents.
			This document only covers the creation, update and deletion of Entry
			and Media resources. Other resources can be created, updated, and
			deleted as the result of manipulating a Collection, but the number of
			those resources, their mime-types, and effects of Atom Protocol
			operations on them are outside the scope of this specification.
			Since all aspects of client-server interaction are defined in terms
			of HTTP, [RFC2616] should be consulted for any areas not covered in
			this specification.
			Along with operations on Member Resources, the Atom Protocol defines
			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. The Atom
			Protocol does not make a distinction between Feeds used for
			Collections and other Atom Feeds. The only mechanism that this
			specification supplies for distinguishing a 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]. The resource identified by the URI		in Section 3.1 of [RFC3987]. In accordance with that specification,
	after conversion is the same as the one identified by the IRI.		this conversion SHOULD be applied as late as possible. 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 - Member Entry Resources and
	Media Resources. Member Entry Resources are represented as Atom		Media Resources. Member Entry Resources are represented as Atom
	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		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.
	The first contains the IRI of a Member Entry Resource. The second		The first contains the IRI of a Member Entry Resource. The second
	contains the IRIs of both a Media Resource and a Media Link Entry		contains the IRIs of both a Media Resource and a Media Link Entry
	Resource, which contains the metadata for that Media Resource:		Resource, which contains the metadata 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
	skipping to change at page 9, line 22		skipping to change at page 9, line 22
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 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
	set 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		to the URI of a Collection. An Atom Feed Document is returned whose
	containing one Atom Entry for each Member Entry Resource. See		Entries contain the IRIs of Member Resources. The returned Feed may
	Section 10 and Section 11 for a description of the feed contents.		describe all, or only a subset, of the Members in a Collection (see
			Section 10). Section 11 describes extensions to the Atom Syndication
			Format used in the Atom Protocol.
	Client Server		Client Server
	| |		| |
	| 1.) GET to Collection URI |		| 1.) GET to Collection URI |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) 200 OK, 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
	skipping to change at page 10, line 23		skipping to change at page 10, line 23
	| 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 Member Entry Resource.
	Media Resources may have also been created and their IRIs can be		Media Resources could have also been created and their IRIs can
	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
	skipping to change at page 11, line 18		skipping to change at page 11, line 18
	| |		| |
	| 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. Upon a successful update of the resource the server responds with		2. If the update is successful the server responds with a status
	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. Upon the successful deletion of the resource the server responds		2. If the deletion is successful the server responds with a status
	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 per the HTTP specification, HTTP
	skipping to change at page 12, line 14		skipping to change at page 12, line 14
	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 Workspaces, which are
	which are server-defined groupings of Collections.		server-defined groups of Collections. This specification assigns no
			meaning to Workspaces; that is, a Workspace does not imply any
			specific processing assumptions. Operations on Workspaces
			themselves, such as creation or deletion, are not defined by this
			specification.
	The namespace name [W3C.REC-xml-names-20060816] 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]]		[[anchor8: The namespace name 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
	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 or signal an error, and SHOULD		markup MUST NOT stop processing and MUST NOT signal an error.
	preserve foreign markup when transmitting such documents.		Clients SHOULD preserve foreign markup when transmitting 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 recognised by processors conformant to this		that might not be recognized by processors conformant to this
	specification. Such unrecognised 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.
	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, where they describe
	categories allowed in a Collection (see Section 8.2.5).		the 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).
	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 14, line 5		skipping to change at page 15, line 5
	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"		7.2.1.1 Attributes of "app:categories"
	The app:categories element can contain a "fixed" attribute, with a		The app:categories element can contain a "fixed" attribute, with a
	value of either "yes" or "no", indicating whether the list of		value of either "yes" or "no", indicating whether the list of
	categories is a fixed or an open set. Newly created or updated		categories is a fixed or an open set. Attempts to create or update
	members whose categories are not listed in the Collection Document		members whose categories are not listed in the Collection Document
	MAY be rejected by the server. Collections that indicate the set is		MAY be rejected by the server. Collections that indicate the
	open SHOULD NOT reject otherwise acceptable members whose categories		category set is open SHOULD NOT reject otherwise acceptable members
	are not listed in the Collection.		whose categories are not listed by 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 7		skipping to change at page 16, line 7
	appOutOfLineCategories =		appOutOfLineCategories =
	element app:categories {		element app:categories {
	attribute href { atomURI },		attribute href { atomURI },
	undefinedContent		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 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. How		Documents are designed to support this discovery process. How
	Service Documents are in turn discovered is not defined in this		Service Documents are discovered is not defined in this
	specification.		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		groups 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
	<?xml version="1.0" encoding='utf-8'?>		<?xml version="1.0" encoding='utf-8'?>
	<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>
	<atom:title>Main Site</atom:title>		<atom:title>Main Site</atom:title>
	<collection		<collection
	skipping to change at page 16, line 42		skipping to change at page 17, line 42
	scheme="http://example.org/extra-cats/"		scheme="http://example.org/extra-cats/"
	term="joke" />		term="joke" />
	<atom:category		<atom:category
	scheme="http://example.org/extra-cats/"		scheme="http://example.org/extra-cats/"
	term="serious" />		term="serious" />
	</categories>		</categories>
	</collection>		</collection>
	</workspace>		</workspace>
	</service>		</service>
	This Service Document describes two workspaces. The first Workspace		This Service Document describes two Workspaces. The first Workspace
	is called "Main Site", has two collections called "My Blog Entries"		is called "Main Site", has two Collections called "My Blog Entries"
	and "Pictures" whose IRIs are "http://example.org/reilly/main" and		and "Pictures" whose IRIs are "http://example.org/reilly/main" and
	"http://example.org/reilly/pic" respectively. The "Pictures"		"http://example.org/reilly/pic" respectively. The "Pictures"
	Workspace includes an "accept" element indicating that a client can		Workspace includes an "accept" element indicating that a client can
	post image files to the Collection to create new entries. Entries		post image files to the Collection to create new Media Resources.
	with associated media resources are discussed in Section 9.5.		Entries with associated Media Resources are discussed in Section 9.5.
	The second Workspace is called "Side Bar Blog" and has a single		The second Workspace is called "Side Bar Blog" and has a single
	Collection called "Remaindered Links" whose IRI is		Collection called "Remaindered Links" whose IRI is
	"http://example.org/reilly/list".		"http://example.org/reilly/list".
	Within each of the two entry collections, the categories element		Within each of the two Entry collections, the categories element
	provides a list of available categories for member entries. In the		provides a list of available categories for Member Entries. In the
	"My Blog Entries" Collection, the list of available categories is		"My Blog Entries" Collection, the list of available categories is
	obtainable through the "href" attribute. The "Side Bar Blog"		obtainable through the "href" attribute. The "Side Bar Blog"
	Collection provides a category list within the Service Document, but		Collection provides a category list within the Service Document, but
	states the list is fixed, signaling a request from the server that		states the list is fixed, signaling a request from the server that
	entries be posted using only those two categories.		Entries be POSTed using only those two categories.
	8.2 Element Definitions		8.2 Element Definitions
	8.2.1 The "app:service" Element		8.2.1 The "app:service" Element
	The root of a Service Document is the "app:service" element.		The root of a Service Document is the "app:service" element.
	The "app:service" element is the container for service information		The "app:service" element is the container for service information
	associated with one or more workspaces. An app:service element MUST		associated with one or more Workspaces. An app:service element MUST
	contain one or more app:workspace elements.		contain one or more app:workspace elements.
	namespace app = "http://purl.org/atom/app#"		namespace app = "http://purl.org/atom/app#"
	start = appService		start = appService
	appService =		appService =
	element app:service {		element app:service {
	appCommonAttributes,		appCommonAttributes,
	( appWorkspace+		( appWorkspace+
	& extensionElement* )		& extensionElement* )
	}		}
	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,
	( atomTitle		( atomTitle
	& appCollection*		& appCollection*
	& extensionElement* )		& extensionElement* )
	}		}
	atomTitle = element atom:title { atomTextConstruct }		atomTitle = element atom:title { atomTextConstruct }
	In an app:workspace element, the first app:collection element MUST
	refer to the preferred or primary Collection. This distinction is
	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:
	<service xmlns="http://purl.org/atom/app#"
	xmlns:atom="http://www.w3.org/2005/Atom">
	<workspace xml:lang="de">
	<atom:title>Das Blog</atom:title>
	<collection
	href="http://example.org/blog/eintragungen" >
	<atom:title>Eintragungen</atom:title>
	</collection>
	<collection
	href="http://example.org/blog/fotos">
	<atom:title>Fotos</atom:title>
	<accept>image/*</accept>
	</collection>
	</workspace>
	</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 (as		The app:workspace element MUST contain one "atom:title" element (as
	defined in [RFC4287]), giving a human-readable title for the		defined in [RFC4287]), giving a human-readable title for the
	workspace.		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
	MUST NOT contain more than one app:accept element.		MUST NOT contain more than one app:accept element.
	appCollection =		appCollection =
	element app:collection {		element app:collection {
	skipping to change at page 19, line 9		skipping to change at page 19, line 32
	( atomTitle		( atomTitle
	& appAccept?		& appAccept?
	& appCategories*		& appCategories*
	& extensionElement* )		& extensionElement* )
	}		}
	8.2.3.1 Usage in Atom Feed Documents		8.2.3.1 Usage in Atom Feed Documents
	The app:collection element MAY appear as a child of an atom:feed or		The app:collection element MAY appear as a child of an atom:feed or
	atom:source element in an Atom Feed Document. Its value identifies a		atom:source element in an Atom Feed Document. Its value identifies a
	Collection by which new entries can be added to appear in the feed.		Collection by which new Entries can be added to appear in the feed.
	The app:control element is considered foreign markup as defined in		The app:collection element is considered foreign markup as defined in
	Section 6 of [RFC4287].		Section 6 of [RFC4287].
	8.2.3.2 The "href" Attribute		8.2.3.2 The "href" Attribute
	The app:collection element MUST contain an "href" attribute, whose		The app:collection element MUST contain an "href" attribute, whose
	value gives the IRI of the Collection.		value gives the IRI of the Collection.
	8.2.3.3 The "atom:title" Element		8.2.3.3 The "atom:title" Element
	The app:collection Element MUST contain one "atom:title" element,		The app:collection 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
			Collection.
	8.2.4 The "app:accept" Element		8.2.4 The "app:accept" Element
	The "app:accept" element value specifies a comma-separated list of		The "app:accept" element value specifies a comma-separated list of
	media-ranges (see [RFC2616]) identifying the types of representations		media-ranges (see [RFC2616]) identifying the types of representations
	that can be POSTed to the URI of a Collection. Whitespace around and		that can be POSTed to the URI of a Collection. Whitespace around and
	between media-range values is considered insignificant and MUST be		between media-range values is considered insignificant and MUST be
	ignored.		ignored.
	The app:accept element is similar to the HTTP Accept request-header		The app:accept element is similar to the HTTP Accept request-header
	skipping to change at page 19, line 45		skipping to change at page 20, line 22
	14.1.		14.1.
	The order of media-ranges is not significant. The following lists		The order of media-ranges is not significant. The following lists
	are all equivalent:		are all equivalent:
	<app:accept>image/png,image/*</app:accept>		<app:accept>image/png,image/*</app:accept>
	<app:accept>image/*, image/png</app:accept>		<app:accept>image/*, image/png</app:accept>
	<app:accept> image/* </app:accept>		<app:accept> image/* </app:accept>
	A value of "entry" may appear in any list of media-ranges in an		A value of "entry" may appear in any list of media-ranges in an
	accept element and indicates that Atom Entry Documents can be posted		accept element and indicates that Atom Entry Documents can be POSTed
	to the Collection. If the accept element is omitted or empty,		to the Collection. If the accept element exists but is empty,
	clients SHOULD assume that only Atom Entry documents will be accepted		clients SHOULD assume that the Collection does not support the
	by the Collection.		creation of new Entries. If the accept element is not present,
			clients SHOULD treat this as equivalent to <app:accept>entry</
			app:accept>.
	appAccept =		appAccept =
	element app:accept {		element app:accept {
	appCommonAttributes,		appCommonAttributes,
	( appTypeValue? )		( appTypeValue? )
	}		}
	appTypeValue = ( "entry" | media-type |entry-or-media-type )		appTypeValue = ( "entry" | media-type |entry-or-media-type )
	media-type = xsd:string { pattern = "entry,(.+/.+,?)*" }		media-type = xsd:string { pattern = "entry,(.+/.+,?)*" }
	entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" }		entry-or-media-type = xsd:string { pattern = "(.+/.+,?)*" }
	skipping to change at page 22, line 10		skipping to change at page 22, line 10
	The app:categories element MAY contain an "href" attribute, whose		The app:categories element MAY contain an "href" attribute, whose
	value MUST be an IRI reference identifying a Category Document. If		value MUST be an IRI reference identifying a Category Document. If
	the "href" attribute is provided, the app:categories element MUST be		the "href" attribute is provided, the app:categories element MUST be
	empty and the "fixed" and "scheme" attributes MUST NOT be present.		empty and the "fixed" and "scheme" attributes MUST NOT be present.
	9. Creating and Editing Resources		9. Creating and Editing Resources
	9.1 Member URIs		9.1 Member URIs
	The Member URI supports retrieving, updating and deleting the		The Member URI supports retrieving, updating and deleting the
	resource using HTTP GET, PUT and DELETE as described in this section.		resource using HTTP GET, PUT and DELETE. Retrieval and updating of
	Retrieval and updating of Member Entry Resources are done via Atom		Member Entry Resources are done by exchanging Atom Entry
	Entry representations.		representations.
	Member Entry URIs appear in two places. First, they are returned in		Member Entry URIs appear in two places. First, they are returned in
	a Location header after successful resource creation using POST, as		a Location header after successful resource creation using POST, as
	described below. Second, in the entries of a Collection document, by		described below. Second, they appear in the Entries of a Collection
	an atom:link element with a link relation of "edit".		document as atom:link elements with a link relation of "edit".
	Each Member Entry SHOULD contain such an atom:link element providing		Each Member Entry SHOULD contain such an atom:link element providing
	its Member Entry URI.		its Member Entry URI.
	9.2 Creating resources with POST		9.2 Creating resources with POST
	To add members to a Collection, clients send POST requests to the URI		To add members to a Collection, clients send POST requests to the URI
	of a Collection. Successful member creation is normally indicated		of a Collection. Successful member creation is normally indicated
	with a 201 ("Created") response code. Collections MAY generate a		with a 201 ("Created") response code. Collections MAY generate a
	response with a status code of 415 ("Unsupported Media Type") to		response with a status code of 415 ("Unsupported Media Type") to
	indicate media-type of POSTed entity is not allowed or supported by		indicate that the media-type of the POSTed entity is not allowed or
	the Collection.		supported by the Collection.
	When a Member Resource is created in the Collection which received		When a Member Resource is created in the Collection which received
	the POST, its Member Entry URI MUST be returned in an HTTP Location		the POST, its Member Entry URI MUST be returned in an HTTP Location
	header.		header.
	When the server generates a response with a status code of 201		When the server generates a response with a status code of 201
	("Created"), it SHOULD also return a response body, which if		("Created"), it SHOULD also return a response body, which if
	provided, MUST be an Atom Entry Document representing the newly-		provided, MUST be an Atom Entry Document representing the newly-
	created resource.		created resource.
	Since the server is free to alter the posted entry, for example by		Since the server is free to alter the POSTed Entry, for example by
	changing the content of the "id" element, returning the Entry as		changing the content of the "id" element, returning the Entry as
	described in the previous paragraph can be useful to the client,		described in the previous paragraph can be useful to the client,
	enabling it to correlate the client and server views of the new		enabling it to correlate the client and server views of the new
	Entry.		Entry.
	When the POST request contains an Atom Entry Document, the response		If the POST request contained an Atom Entry Document, and the
	from the server SHOULD contain a Content-Location header that		subsequent response from the server contains a Content-Location
	contains the same character-by-character value as the Location		header that matches the Location header character-for-character, then
	header.		the client is authorized to interpret the response entity as being
			the representation of the newly created Entry. Without a matching
			Content-Location header the client MUST NOT assume the returned
			entity is a complete representation of the created resource.
	The request body sent with the POST need not be an Atom Entry. For		The request body sent with the POST need not be an Atom Entry. For
	example, it might be a picture, or a movie. For a discussion of the		example, it might be a picture, or a movie. For a discussion of the
	issues in posting such content, see Section 9.5.		issues in POSTing such content, see Section 9.5.
	9.2.1 Example		9.2.1 Example
	Below, the client sends a POST request containing an Atom Entry		Below, the client sends a POST request containing an Atom Entry
	representation to the URI of the Collection:		representation to the URI of the Collection:
	POST /myblog/entries HTTP/1.1		POST /myblog/entries HTTP/1.1
	Host: example.org		Host: example.org
	User-Agent: Thingio/1.0		User-Agent: Thingio/1.0
	Authorization: Basic ZGFmZnk6c2VjZXJldA==		Authorization: Basic ZGFmZnk6c2VjZXJldA==
	skipping to change at page 23, line 30		skipping to change at page 23, line 33
	<entry xmlns="http://www.w3.org/2005/Atom"		<entry xmlns="http://www.w3.org/2005/Atom"
	xmlns:app="http://purl.org/atom/app#">		xmlns:app="http://purl.org/atom/app#">
	<title>Atom-Powered Robots Run Amok</title>		<title>Atom-Powered Robots Run Amok</title>
	<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>		<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
	<updated>2003-12-13T18:30:02Z</updated>		<updated>2003-12-13T18:30:02Z</updated>
	<author><name>John Doe</name></author>		<author><name>John Doe</name></author>
	<content>Some text.</content>		<content>Some text.</content>
	</entry>		</entry>
	The server signals a successful creation with a status code of 201.		The server signals a successful creation with a status code of 201.
	The response includes a "Location" header indicating the Member Entry		The response includes a Location: header indicating the Member Entry
	URI of the Atom Entry and a representation of that Entry in the body		URI of the Atom Entry and a representation of that Entry in the body
	of the response.		of the response.
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	Date: Fri, 7 Oct 2005 17:17:11 GMT		Date: Fri, 7 Oct 2005 17:17:11 GMT
	Content-Length: nnn		Content-Length: nnn
	Content-Type: application/atom+xml; charset="utf-8"		Content-Type: application/atom+xml; charset="utf-8"
	Content-Location: http://example.org/edit/first-post.atom
	Location: http://example.org/edit/first-post.atom		Location: http://example.org/edit/first-post.atom
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<entry xmlns="http://www.w3.org/2005/Atom"		<entry xmlns="http://www.w3.org/2005/Atom"
	xmlns:app="http://purl.org/atom/app#">		xmlns:app="http://purl.org/atom/app#">
	<title>Atom-Powered Robots Run Amok</title>		<title>Atom-Powered Robots Run Amok</title>
	<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>		<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
	<updated>2003-12-13T18:30:02Z</updated>		<updated>2003-12-13T18:30:02Z</updated>
	<author><name>John Doe</name></author>		<author><name>John Doe</name></author>
	<content>Some text.</content>		<content>Some text.</content>
	<link rel="edit"		<link rel="edit"
	href="http://example.org/edit/first-post.atom"/>		href="http://example.org/edit/first-post.atom"/>
	</entry>		</entry>
	The Entry created and returned by the server might not match the		The created Entry returned by the server might not match the Entry
	Entry POSTed by the client. A server MAY change the values of		POSTed by the client. A server MAY change the values of various
	various elements in the Entry such as the atom:id, atom:updated and		elements in the Entry such as the atom:id, atom:updated and atom:
	atom:author values and MAY choose to remove or add other elements and		author values and MAY choose to remove or add other elements and
	attributes, or change element and attribute values.		attributes, or change element and attribute values.
	In particular, the publishing system in this example filled in some		In particular, the publishing system in this example filled in some
	values not provided in the original POST. For example, it		values not provided in the original POST. For example, it
	ascertained the name of the author, presumably via the authentication		ascertained the name of the author, presumably via the authentication
	protocol used to establish the right to post.		protocol used to establish the right to post.
	9.3 Updating Resources with PUT		9.3 Updating Resources with PUT
	To update a resource, clients send PUT requests to its Member URI, as		To update a resource, clients send PUT requests to its Member URI, as
	skipping to change at page 24, line 37		skipping to change at page 25, line 8
	9.4 Deleting Resources with DELETE		9.4 Deleting Resources with DELETE
	To delete a resource, clients send DELETE requests to its Member URI,		To delete a resource, clients send DELETE requests to its Member URI,
	as specified in [RFC2616]. For Media Resources, deletion of a Media		as specified in [RFC2616]. For Media Resources, deletion of a Media
	Link Entry SHOULD result in the deletion of the associated Media		Link Entry SHOULD result in the deletion of the associated Media
	Resource.		Resource.
	9.5 Media Resources and Media Link Entries		9.5 Media Resources and Media Link Entries
	A client can POST a media type other than application/atom+xml to a		A client can POST a media type other than application/atom+xml to a
	Collection. Such a request creates two new resources - one that		Collection. Such a request always creates two new resources - one
	corresponds to the entity sent in the request, called the Media		that corresponds to the entity sent in the request, called the Media
	Resource, and an associated Member Entry, called the Media Link		Resource, and an associated Member Entry, called the Media Link
	Entry. Media Link Entries are represented as Atom Entries. The		Entry. Media Link Entries are represented as Atom Entries. The
	server can signal the media types it will accept via the "accept"		server can signal the media types it will accept via the "accept"
	element in the Service Document (Section 8.2.4).		element in the Service Document (Section 8.2.4).
	The Media Link Entry contains the IRI of the Media Resource and makes		The Media Link Entry contains the IRI of, and metadata about, the
	metadata about it separately available for retrieval and update. The		(perhaps non-textual) Media Resource. The Media Link Entry makes the
	Media Link Entry is used to store metadata about the (perhaps non-		metadata about the Media Resource separately available for retrieval
	textual) Media Resource.		and update.
	Successful responses to creation requests MUST include the URI of the		Successful responses to creation requests MUST include the URI of the
	Media Link Entry in the Location header. The Media Link Entry SHOULD		Media Link Entry in the Location header. The Media Link Entry SHOULD
	contain an atom:link element with a link relation of "edit-media"		contain an atom:link element with a link relation of "edit-media"
	that contains the Media Resource IRI. The Media Link Entry MUST have		that contains the Media Resource IRI. The Media Link Entry MUST have
	an "atom:content" element with a non-empty "src" attribute. The		an "atom:content" element with a "src" attribute. The value of the
	value of the "src" attribute is an IRI of the newly created Media		"src" attribute is an IRI of the newly created Media Resource. It is
	Resource. It is OPTIONAL that the IRI of the "src" attribute on the		OPTIONAL that the IRI of the "src" attribute on the atom:content
	atom:content element be the same as the Media Resource IRI. That is,		element be the same as the Media Resource IRI. For example, the
	the "src" attribute value might instead be a link into a static cache		"src" attribute value might instead be a link into a static cache or
	or content distribution network and not be the Media Resource IRI.		content distribution network and not the Media Resource IRI.
	Implementers are asked to note that according to the requirements of		Implementers are asked to note that according to the requirements of
	[RFC4287], entries, and thus Media Link Entries, MUST contain an		[RFC4287], Entries, and thus Media Link Entries, MUST contain an
	atom:summary element. Upon successful creation of a Media Link		atom:summary element. Upon successful creation of a Media Link
	Entry, a server MAY choose to populate the atom:summary element (as		Entry, a server MAY choose to populate the atom:summary element (as
	well as other required elements such as atom:id, atom:author and		well as any other required elements such as atom:id, atom:author and
	atom:title) with content derived from the POSTed entity or from any		atom:title) with content derived from the POSTed entity or from any
	other source. A server might not allow a client to modify the server		other source. A server might not allow a client to modify the server
	selected values for these elements.		selected values for these elements.
	For resource creation this specification only defines cases where the		For resource creation this specification only defines cases where the
	POST body has an Atom Entry entity declared as an Atom media type		POST body has an Atom Entry entity declared as an Atom media type
	("application/atom+xml"), or a non-Atom entity declared as a non-Atom		("application/atom+xml"), or a non-Atom entity declared as a non-Atom
	media type. It does not specify any request semantics or server		media type. It does not specify any request semantics or server
	behavior in the case where the POSTed media-type is "application/		behavior in the case where the POSTed media-type is "application/
	atom+xml" but the body is something other than an Atom Entry. In		atom+xml" but the body is something other than an Atom Entry. In
	particular, what happens on POSTing an Atom Feed Document to a		particular, what happens on POSTing an Atom Feed Document to a
	Collection using the "application/atom+xml" media type is undefined.		Collection using the "application/atom+xml" media type is undefined.
	9.6 The Slug: Header		The Atom Protocol does not specify a means to create multiple
			representations of the same resource (for example a PNG and a JPG of
	Slug is a HTTP entity-header whose value is a "slug" - a short name		the same image) on creation or update.
	that can be used as part of the URI for a Member Resource.
	When posting an entity to a Collection to add a new Member, the
	server MAY use this information when creating the Member URI of the
	newly-created resource, for instance by using some or all of the
	words in the last URI segment. It MAY also use it when creating the
	atom:id or as the title of a Media Link Entry (see Section 9.5.).
	Servers MAY ignore the Slug entity-header and MAY alter its value
	before using it. For example, the server MAY filter out some
	characters or replace accented letters with non-accented ones, spaces
	with underscores, etc.
	9.6.1 Slug: Header syntax
	The syntax of this header MUST conform to the augmented BNF grammar
	in section 2.1 of the HTTP/1.1 specification [RFC2616]. The TEXT
	rule is described in section 2.2 of the same document.
	Slug = "Slug" ":" *TEXT
	Clients MAY send non-ASCII characters in the Slug entity-header,
	which they MUST encode using "encoded-words", as defined in
	[RFC2047]. Servers SHOULD treat the slug as [RFC2047] encoded if it
	matches the "encoded-words" production.
	9.6.2 Examples		9.5.1 Examples
	Below, the client sends a POST request containing a PNG image to the		Below, the client sends a POST request containing a PNG image to the
	URI of the Collection:		URI of a Collection that accepts PNG images:
	POST /myblog/entries HTTP/1.1		POST /media/ HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: image/png		Content-Type: image/png
	Slug: The Beach		Slug: The Beach
	Authorization: Basic ZGFmZnk6c2VjZXJldA==		Authorization: Basic ZGFmZnk6c2VjZXJldA==
	Content-Length: nnn		Content-Length: nnn
	...binary data...		...binary data...
	The server signals a successful creation with a status code of 201.		The server signals a successful creation with a status code of 201.
	The response includes a Location header indicating the Member URI of		The response includes a Location header indicating the Member URI of
	the Media Link Entry and a representation of that entry in the body		the Media Link Entry and a representation of that entry in the body
	of the response. The Media Link Entry includes a content element		of the response. The Media Link Entry includes a content element
	with a src attribute, and a link using the link relation "edit-media"		with a src attribute. It also contains a link using the link
	specifying the IRI to be used for modifying the Media Resource.		relation "edit-media" specifying the IRI to be used for modifying the
			Media Resource.
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	Date: Fri, 7 Oct 2005 17:17:11 GMT		Date: Fri, 7 Oct 2005 17:17:11 GMT
	Content-Length: nnn		Content-Length: nnn
	Content-Type: application/atom+xml; charset="utf-8"		Content-Type: application/atom+xml; charset="utf-8"
	Content-Location: http://example.org/myblog/edit/the_beach		Location: http://example.org/media/edit/the_beach.atom
	Location: http://example.org/myblog/edit/the_beach
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<entry xmlns="http://www.w3.org/2005/Atom">		<entry xmlns="http://www.w3.org/2005/Atom">
	<title>The Beach</title>		<title>The Beach</title>
	<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>		<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
	<updated>2005-10-07T17:17:08Z</updated>		<updated>2005-10-07T17:17:08Z</updated>
	<author><name>Daffy</name></author>		<author><name>Daffy</name></author>
	<summary type="text" />		<summary type="text" />
	<content type="image/png"		<content type="image/png"
	src="http://example.org/media/the_beach.png"/>		src="http://media.example.org/the_beach.png"/>
	<link rel="edit-media"		<link rel="edit-media"
	href="http://example.org/media/edit/the_beach.png" />		href="http://media.example.org/edit/the_beach.png" />
	<link rel="edit"		<link rel="edit"
	href="http://example.org/myblog/edit/the_beach />		href="http://example.org/media/edit/the_beach.atom" />
			</entry>
			Later, the client PUTS a new PNG to the URI indicated in the Media
			Link Entry's "edit-media" link:
			PUT /edit/the_beach.png HTTP/1.1
			Host: media.example.org
			Content-Type: image/png
			Authorization: Basic ZGFmZnk6c2VjZXJldA==
			Content-Length: nnn
			...binary data...
			The server signals a successful update with a status code of 200.
			HTTP/1.1 200 Ok
			Date: Fri, 8 Oct 2006 17:17:11 GMT
			Content-Length: nnn
			The client can update the metadata for the picture. First GET the
			Media Link Entry:
			GET /media/edit/the_beach.atom HTTP/1.1
			Host: example.org
			Authorization: Basic ZGFmZnk6c2VjZXJldA==
			The Media Link Entry is returned.
			HTTP/1.1 200 Ok
			Date: Fri, 7 Oct 2005 17:18:11 GMT
			Content-Length: nnn
			Content-Type: application/atom+xml; charset="utf-8"
			<?xml version="1.0"?>
			<entry xmlns="http://www.w3.org/2005/Atom">
			<title>The Beach</title>
			<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
			<updated>2005-10-07T17:17:08Z</updated>
			<author><name>Daffy</name></author>
			<summary type="text" />
			<content type="image/png"
			src="http://media.example.org/the_beach.png"/>
			<link rel="edit-media"
			href="http://media.example.org/edit/the_beach.png" />
			<link rel="edit"
			href="http://example.org/media/edit/the_beach.atom" />
			</entry>
			The metadata can be updated, in this case to add a summary, and then
			PUT back to the server.
			PUT /media/edit/the_beach.atom HTTP/1.1
			Host: example.org
			Authorization: Basic ZGFmZnk6c2VjZXJldA==
			Content-Type: application/atom+xml
			Content-Length: nnn
			<?xml version="1.0"?>
			<entry xmlns="http://www.w3.org/2005/Atom">
			<title>The Beach</title>
			<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
			<updated>2005-10-07T17:17:08Z</updated>
			<author><name>Daffy</name></author>
			<summary type="text">
			A nice sunset picture over the water.
			</summary>
			<content type="image/png"
			src="http://media.example.org/the_beach.png"/>
			<link rel="edit-media"
			href="http://media.example.org/edit/the_beach.png" />
			<link rel="edit"
			href="http://example.org/media/edit/the_beach.atom" />
			</entry>
			The update was successful.
			HTTP/1.1 200 Ok
			Date: Fri, 7 Oct 2005 17:19:11 GMT
			Content-Length: 0
			Multiple media resources can be added to the Collection.
			POST /media/ HTTP/1.1
			Host: example.org
			Content-Type: image/png
			Slug: The Pier
			Authorization: Basic ZGFmZnk6c2VjZXJldA==
			Content-Length: nnn
			...binary data...
			The resource is created successfully.
			HTTP/1.1 201 Created
			Date: Fri, 7 Oct 2005 17:17:11 GMT
			Content-Length: nnn
			Content-Type: application/atom+xml; charset="utf-8"
			Location: http://example.org/media/edit/the_pier.atom
			<?xml version="1.0"?>
			<entry xmlns="http://www.w3.org/2005/Atom">
			<title>The Pier</title>
			<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efe6b</id>
			<updated>2005-10-07T17:26:43Z</updated>
			<author><name>Daffy</name></author>
			<summary type="text" />
			<content type="image/png"
			src="http://media.example.org/the_pier.png"/>
			<link rel="edit-media"
			href="http://media.example.org/edit/the_pier.png" />
			<link rel="edit"
			href="http://example.org/media/edit/the_pier.atom" />
			</entry>
			The client can now create a new Atom Entry in the blog Entry
			Collection that references the two newly created Media Resources.
			POST /blog/ HTTP/1.1
			Host: example.org
			Content-Type: application/atom+xml
			Slug: A day at the beach
			Authorization: Basic ZGFmZnk6c2VjZXJldA==
			Content-Length: nnn
			<?xml version="1.0"?>
			<entry xmlns="http://www.w3.org/2005/Atom">
			<title>A fun day at the beach</title>
			<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6b</id>
			<updated>2005-10-07T17:40:02Z</updated>
			<author><name>Daffy</name></author>
			<content type="xhtml">
			<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
			<xhtml:p>We had a good day at the beach.
			<xhtml:img
			src="http://media.example.org/the_beach.png"/>
			</xhtml:p>
			<xhtml:p>Later we walked down to the pier.
			<xhtml:img
			src="http://media.example.org/the_pier.png"/>
			</xhtml:p>
			</xhtml:div>
			</content>
	</entry>		</entry>
			The resource is created successfully.
			HTTP/1.1 200 Ok
			Date: Fri, 7 Oct 2005 17:20:11 GMT
			Content-Length: nnn
			Content-Type: application/atom+xml; charset="utf-8"
			Location: http://example.org/blog/atom/a-day-at-the-beach.atom
			<?xml version="1.0"?>
			<entry xmlns="http://www.w3.org/2005/Atom">
			<title>A fun day at the beach</title>
			<id>http://example.org/blog/a-day-at-the-beach.xhtml</id>
			<updated>2005-10-07T17:43:07Z</updated>
			<author><name>Daffy</name></author>
			<content type="xhtml">
			<xhtml:div xmlns:xhtml="http://www.w3.org/1999/xhtml">
			<xhtml:p>We had a good day at the beach.
			<xhtml:img
			src="http://media.example.org/the_beach.png"/>
			</xhtml:p>
			<xhtml:p>Later we walked down to the pier.
			<xhtml:img
			src="http://media.example.org/the_pier.png"/>
			</xhtml:p>
			</xhtml:div>
			</content>
			<link rel="edit"
			href="http://example.org/blog/edit/a-day-at-the-beach.atom"/>
			<link rel="alternate" type="application/xhtml+xml"
			href="http://example.org/blog/a-day-at-the-beach.xhtml"/>
			</entry>
			Note that the returned Entry contains a link with a relation of
			"alternate" that points to the associated XHTML page that was
			created. This is not required by this specification, but is included
			to show the kinds of changes a server may make to an Entry.
			9.6 The Slug: Header
			Slug is a HTTP entity-header whose value is a short name that, when
			accompanying a POST to a Collection, constitutes a request by the
			client that its value be used as part of the URI for the to-be-
			created Member Resource.
			When POSTing an entity to a Collection to add a new Member, the
			server MAY use this information when creating the Member URI of the
			newly-created resource, for instance by using some or all of the
			words in the last URI segment. It MAY also use it when creating the
			atom:id or as the title of a Media Link Entry (see Section 9.5.).
			Servers MAY ignore the Slug entity-header and MAY alter its value
			before using it. For example, the server MAY filter out some
			characters or replace accented letters with non-accented ones, spaces
			with underscores, etc.
			9.6.1 Slug: Header syntax
			The syntax of this header MUST conform to the augmented BNF grammar
			in section 2.1 of the HTTP/1.1 specification [RFC2616]. The TEXT
			rule is described in section 2.2 of the same document.
			Slug = "Slug" ":" *TEXT
			Clients MAY send non-ASCII characters in the Slug entity-header,
			which they MUST encode using "encoded-words", as defined in
			[RFC2047]. Servers SHOULD treat the slug as [RFC2047] encoded if it
			matches the "encoded-words" production.
			9.6.2 Example
	Here is an example of the Slug: header that uses the encoding rules		Here is an example of the Slug: header that uses the encoding rules
	of [RFC2047].		of [RFC2047].
	POST /myblog/entries HTTP/1.1		POST /myblog/entries HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: image/png		Content-Type: image/png
	Slug: =?iso-8859-1?q?The_Beach?=		Slug: =?iso-8859-1?q?The_Beach?=
	Authorization: Basic ZGFmZnk6c2VjZXJldA==		Authorization: Basic ZGFmZnk6c2VjZXJldA==
	Content-Length: nnn		Content-Length: nnn
	...binary data...		...binary data...
	See Section 9.2.1 for an example of the Slug: header applied to the		See Section 9.2.1 for an example of the Slug: header applied to the
	creation of a Member Entry Resource.		creation of a Member Entry Resource.
	10. Listing Collections		10. Listing Collections
	Collection resources MUST provide representations in the form of Atom		Collection Resources MUST provide representations in the form of Atom
	Feed documents whose entries represent the Members in the Collection.		Feed documents whose Entries contain the IRIs of the Members in the
	Each entry in the Feed Document SHOULD have an atom:link element with		Collection. No structural distinction is made between Collection
			Feeds and other kinds of Feeds - a Feed might act both as a 'public'
			feed for subscription purposes and as a Collection Feed.
			Each Entry in the Feed Document SHOULD have an atom:link element with
	a relation of "edit" (See Section 11.1).		a relation of "edit" (See Section 11.1).
	The entries in the returned Atom Feed SHOULD be ordered by their		The Entries in the returned Atom Feed SHOULD be ordered by their
	"atom:updated" property, with the most recently updated entries		"atom:updated" property, with the most recently updated Entries
	coming first in the document order. Clients SHOULD be constructed in		coming first in the document order. Clients SHOULD be constructed in
	consideration of the fact that changes which do not alter the atom:		consideration of the fact that changes which do not alter the atom:
	updated value of an entry will not affect the position of the entry		updated value of an Entry will not affect the position of the Entry
	in a Collection.		in a Collection. That is, the Atom Syndication Format states that
			the value of atom:updated is altered when the changes to an Entry are
			something that "the publisher considers significant." The atom:
			updated value is not equivalent to the HTTP Last-Modified: header and
			can not be used to determine the freshness of cached responses.
	Clients MUST NOT assume that an Atom Entry returned in the Feed is a		Clients MUST NOT assume that an Atom Entry returned in the Feed is a
	full representation of a Member Entry Resource and SHOULD perform a		full representation of a Member Entry Resource and SHOULD perform a
	GET on the URI of the Member Entry before editing.		GET on the URI of the Member Entry before editing.
	10.1 Collection Paging		10.1 Collection Paging
	Collections can contain large numbers of resources. A naive client		Collections can contain large numbers of resources. A naive client
	such as a web spider or web browser could be overwhelmed if the		such as a web spider or web browser could be overwhelmed if the
	response to a GET contained every entry in the Collection, and the		response to a GET contained every Entry in the Collection, and the
	server would waste large amounts of bandwidth and processing time on		server would waste large amounts of bandwidth and processing time on
	clients unable to handle the response. For this reason, servers MAY		clients unable to handle the response. For this reason, servers MAY
	return a partial listing of the most recently updated Member		return a partial listing of the most recently updated Member
	Resources. Such partial feed documents MUST have an atom:link with a		Resources. Such partial feed documents MUST have an atom:link with a
	"next" relation whose "href" value is the URI of the next partial		"next" relation whose "href" value is the URI of the next partial
	listing of the Collection (the next most recently updated Member		listing of the Collection (the next most recently updated Member
	Resources) where it exists. This is called "Collection paging".		Resources) where it exists. This is called "Collection paging".
	The returned Atom Feed MAY contain a subset the Member Entries for a		The returned Atom Feed MAY contain a subset the Member Entries for a
	Collection. In addition, the Atom Feed document MAY contain link		Collection. In addition, the Atom Feed document MAY contain link
	elements with "rel" attribute values of "next", "previous", "first"		elements with "rel" attribute values of "next", "previous", "first"
	and "last" that can be used to navigate through the complete set of		and "last" that can be used to navigate through the complete set of
	matching entries.		matching Entries.
	For instance, suppose a client is supplied the URI		For instance, suppose a client is supplied the URI
	"http://example.org/entries/go" of a Collection of Member entries,		"http://example.org/entries/go" of a Collection of Member entries,
	where the server as a matter of policy avoids generating feed		where the server as a matter of policy avoids generating feed
	documents containing more than 10 entries. The Atom Feed document		documents containing more than 10 Entries. The Atom Feed document
	for the Collection will then represent the first 'page' in a set of		for the Collection will then represent the first 'page' in a set of
	10 linked feed documents. The "first" relation will reference the		10 linked feed documents. The "first" relation will reference the
	initial feed document in the set and the "last" relation references		initial feed document in the set and the "last" relation references
	the final Atom Feed Document in the set. Within each document, the		the final Atom Feed Document in the set. Within each document, the
	"next" and "previous" link relations reference the preceding and		"next" and "previous" link relations reference the preceding and
	subsequent documents.		subsequent documents.
	<feed xmlns="http://www.w3.org/2005/Atom">		<feed xmlns="http://www.w3.org/2005/Atom">
	<link rel="first"		<link rel="first"
	href="http://example.org/entries/go" />		href="http://example.org/entries/go" />
	skipping to change at page 29, line 33		skipping to change at page 34, line 40
	<link rel="next"		<link rel="next"
	href="http://example.org/entries/3" />		href="http://example.org/entries/3" />
	<link rel="last"		<link rel="last"
	href="http://example.org/entries/10" />		href="http://example.org/entries/10" />
	...		...
	</feed>		</feed>
	10.2 The "app:edited" Element		10.2 The "app:edited" Element
	The "app:edited" element is a Date construct as defined by [RFC4287]		The "app:edited" element is a Date construct as defined by [RFC4287]
	whose value indicates the most recent instant in time when an entry		whose value indicates the most recent instant in time when an Entry
	was edited, including when created. Atom entry elements in		was edited, including when created. Atom Entry elements in
	Collection documents SHOULD contain one "app:edited" element, and		Collection documents SHOULD contain one "app:edited" element, and
	MUST NOT contain more than one.		MUST NOT contain more than one.
	appEdited = element app:edited ( atomDateConstruct )		appEdited = element app:edited ( atomDateConstruct )
	The server SHOULD change the value of this element every time a		The server SHOULD change the value of this element every time a
	Collection Member Resource or an associated Media Resource has been		Collection Member Resource or an associated Media Resource has been
	edited by any means.		edited.
	11. Atom Format Link Relation Extensions		11. Atom Format Link Relation Extensions
	11.1 The "edit" Link Relation		11.1 The "edit" Link Relation
	This specification adds the value "edit" to the Atom Registry of Link		This specification adds the value "edit" to the Atom Registry of Link
	Relations (see section 7.1 of [RFC4287]). The value of "edit"		Relations (see section 7.1 of [RFC4287]). The value of "edit"
	specifies that the value of the href attribute is the IRI of an		specifies that the value of the href attribute is the IRI of an
	editable Member Entry. When appearing within an atom:entry, the href		editable Member Entry. When appearing within an atom:entry, the href
	IRI can be used to retrieve, update and delete the resource		IRI can be used to retrieve, update and delete the resource
	represented by that entry. An atom:entry MUST contain no more than		represented by that Entry. An atom:entry MUST contain no more than
	one "edit" link relation.		one "edit" link relation.
	11.2 The "edit-media" Link Relation		11.2 The "edit-media" Link Relation
	This specification adds the value "edit-media" to the Atom Registry		This specification adds the value "edit-media" to the Atom Registry
	of Link Relations (see section 7.1 of [RFC4287]). When appearing		of Link Relations (see section 7.1 of [RFC4287]). When appearing
	within an atom:entry, the value of the href attribute is an IRI that		within an atom:entry, the value of the href attribute is an IRI that
	can be used to modify a Media Resource associated with that entry.		can be used to modify a Media Resource associated with that Entry.
	An atom:entry element MAY contain zero or more "edit-media" link		An atom:entry element MAY contain zero or more "edit-media" link
	relations. An atom:entry MUST NOT contain more than one atom:link		relations. An atom:entry MUST NOT contain more than one atom:link
	element with a rel attribute value of "edit-media" that has the same		element with a rel attribute value of "edit-media" that has the same
	type and hreflang attribute values. All "edit-media" link relations		"type" and "hreflang" attribute values. All "edit-media" link
	in the same entry reference the same resource. If a client		relations in the same Entry reference the same resource. If a client
	encounters multiple "edit-media" link relations in an entry then it		encounters multiple "edit-media" link relations in an Entry then it
	SHOULD choose a link based on the client preferences for type and		SHOULD choose a link based on the client preferences for "type" and
	hreflang. If a client encounters multiple "edit-media" link		"hreflang". If a client encounters multiple "edit-media" link
	relations in an entry and has no preference based on the type and		relations in an Entry and has no preference based on the "type" and
	hreflang attributes then the client SHOULD pick the first "edit-		"hreflang" attributes then the client SHOULD pick the first "edit-
	media" link relation in document order.		media" link relation in document order.
	12. Atom Publishing Controls		12. Atom Publishing Controls
	This specification defines an Atom Format Structured Extension, as		This specification defines an Atom Format Structured Extension, as
	defined in Section 6 of [RFC4287], for publishing control within the		defined in Section 6 of [RFC4287], for publishing control within the
	http://purl.org/atom/app# namespace.		"http://purl.org/atom/app#" namespace.
	12.1 The "app:control" Element		12.1 The "app:control" Element
	namespace app = "http://purl.org/atom/app#"		namespace app = "http://purl.org/atom/app#"
	pubControl =		pubControl =
	element app:control {		element app:control {
	atomCommonAttributes,		atomCommonAttributes,
	pubDraft?		pubDraft?
	& extensionElement		& extensionElement
	skipping to change at page 32, line 10		skipping to change at page 37, line 10
	the app:draft element is missing then the value MUST be understood to		the app:draft element is missing then the value MUST be understood to
	be "no". The inclusion of the app:draft element represents a request		be "no". The inclusion of the app:draft element represents a request
	by the client to control the visibility of a Member Resource and the		by the client to control the visibility of a Member Resource and the
	app:draft element MAY be ignored by the server.		app:draft element MAY be ignored by the server.
	13. Securing the Atom Publishing Protocol		13. Securing the Atom Publishing Protocol
	The Atom Publishing Protocol is based on HTTP. Authentication		The Atom Publishing Protocol is based on HTTP. Authentication
	requirements for HTTP are covered in Section 11 of [RFC2616].		requirements for HTTP are covered in Section 11 of [RFC2616].
	The use of authentication mechanisms to prevent posting or editing by		The use of authentication mechanisms to prevent POSTing or editing by
	unknown or unauthorized clients is RECOMMENDED but not required.		unknown or unauthorized clients is RECOMMENDED but not required.
	When authentication is not used, clients and servers are vulnerable		When authentication is not used, clients and servers are vulnerable
	to trivial spoofing, denial of service and defacement attacks,		to trivial spoofing, denial of service and defacement attacks,
	however, in some contexts, this is an acceptable risk.		however, in some contexts, this is an acceptable risk.
	The type of authentication deployed is a local decision made by the		The type of authentication deployed is a local decision made by the
	server operator. Clients are likely to face authentication schemes		server operator. Clients are likely to face authentication schemes
	that vary across server deployments. At a minimum, client and server		that vary across server deployments. At a minimum, client and server
	implementations MUST be capable of being configured to use HTTP Basic		implementations MUST be capable of being configured to use HTTP Basic
	Authentication [RFC2617] in conjunction with a TLS connection		Authentication [RFC2617] in conjunction with a TLS connection as
	[RFC4346] as specified by [RFC2818].		specified by [RFC2818]. See [RFC4346] for more information on TLS.
	The choice of authentication mechanism will impact interoperability.		The choice of authentication mechanism will impact interoperability.
	The minimum level of security referenced above (Basic Auth with TLS)		The minimum level of security referenced above (Basic Authentication
	is considered good practice for Internet applications at the time of		with TLS) is considered good practice for Internet applications at
	publication of this specification and sufficient for establishing a		the time of publication of this specification and sufficient for
	baseline for interoperability. Implementers should, in general,		establishing a baseline for interoperability. Implementers can
	investigate and use alternative mechanisms regarded as equivalently		investigate and use alternative mechanisms regarded as equivalently
	good or better at the time of deployment. It is RECOMMENDED that		good or better at the time of deployment. It is RECOMMENDED that
	clients be implemented in such a way that allows new authentication		clients be implemented in such a way that allows new authentication
	schemes to be deployed.		schemes to be deployed.
	Because this protocol uses HTTP response status codes as the primary		Because this protocol uses HTTP response status codes as the primary
	means of reporting the result of a request, servers are advised to		means of reporting the result of a request, servers are advised to
	respond to unauthorized or unauthenticated requests using an		respond to unauthorized or unauthenticated requests using an
	appropriate 4xx HTTP response code (e.g. 401 "Unauthorized" or 403		appropriate 4xx HTTP response code (e.g. 401 "Unauthorized" or 403
	"Forbidden") in accordance with [RFC2617].		"Forbidden") in accordance with [RFC2617].
	skipping to change at page 33, line 26		skipping to change at page 38, line 26
	14.2 Replay Attacks		14.2 Replay Attacks
	Atom Publishing server implementations are susceptible to replay		Atom Publishing server implementations are susceptible to replay
	attacks. Specifically, this specification does not define a means of		attacks. Specifically, this specification does not define a means of
	detecting duplicate requests. Accidentally sent duplicate requests		detecting duplicate requests. Accidentally sent duplicate requests
	are indistinguishable from intentional and malicious replay attacks.		are indistinguishable from intentional and malicious replay attacks.
	14.3 Spoofing Attacks		14.3 Spoofing Attacks
	Atom Publishing implementations are susceptible to a variety of		Atom Publishing implementations are susceptible to a variety of
	spoofing attacks. Malicious clients may send Atom entries containing		spoofing attacks. Malicious clients may send Atom Entries containing
	inaccurate information anywhere in the document.		inaccurate information anywhere in the document.
	14.4 Linked Resources		14.4 Linked Resources
	Atom Feed and Entry documents can contain XML External Entities as		Atom Feed and Entry documents can contain XML External Entities as
	defined in Section 4.2.2 of [W3C.REC-xml-20060816]. Atom		defined in Section 4.2.2 of [W3C.REC-xml-20060816]. Atom
	implementations are not required to load external entities. External		implementations are not required to load external entities. External
	entities are subject to the same security concerns as any network		entities are subject to the same security concerns as any network
	operation and can alter the semantics of an Atom document. The same		operation and can alter the semantics of an Atom document. The same
	issues exist for resources linked to by Atom elements such as atom:		issues exist for resources linked to by Atom elements such as atom:
End of changes. 85 change blocks.
	233 lines changed or deleted		459 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/