draft-ietf-atompub-protocol-07.txt		draft-ietf-atompub-protocol-08.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft BitWorking, Inc
	Expires: July 5, 2006 B. de hOra, Ed.		Expires: August 5, 2006 B. de hOra, Ed.
	Propylon Ltd.		Propylon Ltd.
	January 01, 2006		February 01, 2006
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-07.txt		draft-ietf-atompub-protocol-08.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 July 5, 2006.		This Internet-Draft will expire on August 5, 2006.
	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 33		skipping to change at page 2, line 33
	6.1 Referring to Information Items . . . . . . . . . . . . . . 11		6.1 Referring to Information Items . . . . . . . . . . . . . . 11
	6.2 XML Namespace Usage . . . . . . . . . . . . . . . . . . . 11		6.2 XML Namespace Usage . . . . . . . . . . . . . . . . . . . 11
	6.3 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11		6.3 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11
	6.4 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 12		6.4 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 12
	7. Introspection Documents . . . . . . . . . . . . . . . . . . 13		7. Introspection Documents . . . . . . . . . . . . . . . . . . 13
	7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14		7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14
	7.2.1 The "app:service" Element . . . . . . . . . . . . . . 14		7.2.1 The "app:service" Element . . . . . . . . . . . . . . 14
	7.2.2 The "app:workspace" Element . . . . . . . . . . . . . 14		7.2.2 The "app:workspace" Element . . . . . . . . . . . . . 14
	7.2.3 The "app:collection" Element . . . . . . . . . . . . . 15		7.2.3 The "app:collection" Element . . . . . . . . . . . . . 15
	7.2.4 The "app:member-type" Element . . . . . . . . . . . . 15		7.2.4 The "app:member-type" Element . . . . . . . . . . . . 16
	8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 17		8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1 Creating resources with POST . . . . . . . . . . . . . . . 17		8.1 Creating resources with POST . . . . . . . . . . . . . . . 17
	8.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . 17		8.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1.2 Title: Header . . . . . . . . . . . . . . . . . . . . 17		8.1.2 Title: Header . . . . . . . . . . . . . . . . . . . . 17
	8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 18		8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 18
			8.2.1 Editing entries with foreign markup . . . . . . . . . 18
	8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 18		8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 18
	8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 18		8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 18
	9. Listing Collections . . . . . . . . . . . . . . . . . . . . 19		8.3.2 Editing Media Metadata . . . . . . . . . . . . . . . . 19
	9.1 Collection Paging . . . . . . . . . . . . . . . . . . . . 19		9. Listing Collections . . . . . . . . . . . . . . . . . . . . 20
	10. Atom Format Link Relation Extensions . . . . . . . . . . . . 21		9.1 Collection Paging . . . . . . . . . . . . . . . . . . . . 20
	10.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 21		10. Atom Format Link Relation Extensions . . . . . . . . . . . . 22
	11. Atom Publishing Control Extensions . . . . . . . . . . . . . 22		10.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 22
	11.1 The Atom Publishing Control Namespace . . . . . . . . . 22		11. Atom Publishing Control Extensions . . . . . . . . . . . . . 23
	11.2 The "pub:control" Element . . . . . . . . . . . . . . . 22		11.1 The Atom Publishing Control Namespace . . . . . . . . . 23
	11.2.1 The "pub:draft" Element . . . . . . . . . . . . . . 22		11.2 The "pub:control" Element . . . . . . . . . . . . . . . 23
	12. Atom Publishing Protocol Example . . . . . . . . . . . . . . 23		11.2.1 The "pub:draft" Element . . . . . . . . . . . . . . 23
	13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 25		12. Atom Publishing Protocol Example . . . . . . . . . . . . . . 24
	14. Security Considerations . . . . . . . . . . . . . . . . . . 26		13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 26
	15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27		14. Security Considerations . . . . . . . . . . . . . . . . . . 27
	16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
	16.1 Normative References . . . . . . . . . . . . . . . . . . 29		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
	16.2 Informative References . . . . . . . . . . . . . . . . . 30		16.1 Normative References . . . . . . . . . . . . . . . . . . 30
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31		16.2 Informative References . . . . . . . . . . . . . . . . . 31
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 32
	B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 33		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33
	C. Revision History . . . . . . . . . . . . . . . . . . . . . . 36		B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 34
	Intellectual Property and Copyright Statements . . . . . . . 39		C. Revision History . . . . . . . . . . . . . . . . . . . . . . 37
			Intellectual Property and Copyright Statements . . . . . . . 40
	1. Introduction		1. Introduction
	The Atom Publishing Protocol is an application-level protocol for		The Atom Publishing Protocol is an application-level protocol for
	publishing and editing Web resources using HTTP [RFC2616] and XML 1.0		publishing and editing Web resources using HTTP [RFC2616] and XML 1.0
	[W3C.REC-xml-20040204]. The protocol supports the creation of		[W3C.REC-xml-20040204]. The protocol supports the creation of
	arbitrary web resources and provides facilities for:		arbitrary web resources and provides facilities for:
	o Collections: Sets of resources, which may be retrieved in whole or		o Collections: Sets of resources, which may be retrieved in whole or
	in part.		in part.
	skipping to change at page 6, line 12		skipping to change at page 6, line 12
	Section 3.1 of Internationalized Resource Identifiers (IRIs)		Section 3.1 of Internationalized Resource Identifiers (IRIs)
	[RFC3987].		[RFC3987].
	3. Terminology		3. Terminology
	For convenience, this protocol may be referred to as the "Atom		For convenience, this protocol may 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].		are defined in [RFC3986] and [RFC3987]. Note that IRIs are mapped to
			URIs before dereferencing takes place.
	Resource - A network-accessible data object or service identified by		Resource - A network-accessible data object or service identified by
	an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for		an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for
	further discussion on resources.		further discussion on resources.
	The phrase "the IRI of a document" in this specification is shorthand		The phrase "the URI of a document" in this specification is shorthand
	for "an IRI which, when dereferenced, is expected to produce that		for "an URI which, when dereferenced, is expected to produce that
	document as a representation".		document as a representation".
	Representation - An entity included with a request or response as		Representation - An entity included with a request or response as
	defined in [RFC2616].		defined in [RFC2616].
	Collection - A resource that contains a set of member IRIs. See		Collection - A resource that contains a set of member IRIs. See
	Section 8.		Section 8.
	Member - A resource whose IRI is listed in a Collection.		Member - A resource whose IRI is listed in a Collection.
	skipping to change at page 7, line 23		skipping to change at page 7, line 23
	o POST is used to create a new, dynamically-named resource.		o POST is used to create a new, dynamically-named resource.
	o PUT is used to update a known resource.		o PUT is used to update a known resource.
	o DELETE is used to remove a resource.		o DELETE is used to remove a resource.
	Along with operations on resources, the Atom Protocol provides list-		Along with operations on resources, the Atom Protocol provides list-
	based structures, called Collections, for managing and organising		based structures, called Collections, for managing and organising
	resources, called Members. Collections contain the IRIs of, and		resources, called Members. Collections contain the IRIs of, and
	metadata about, their Member resources. For authoring and editing of		metadata about, their Member resources. For authoring and editing of
	resources to commence, an Atom Protocol client can examine server-		resources to commence, an Atom Protocol client can examine
	defined groups of Collections, called Introspection Documents.		Introspection Documents which represent server-defined groups of
			Collections.
			Note that when an IRI is used for resource retrieval over HTTP, the
			IRI is first converted to a URI according the procedure defined in
			[RFC3987] section 3.1. The resource that the IRI locates is the same
			as the one located by the URI obtained after converting the IRI.
	5. Protocol Operations		5. Protocol Operations
	5.1 Retrieving an Introspection Document		5.1 Retrieving an Introspection Document
	Client Server		Client Server
	| |		| |
	| 1.) GET to IRI of Introspection Document |		| 1.) GET to URI of Introspection Document |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Introspection Document |		| 2.) Introspection Document |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the IRI of the Introspection		1. The client sends a GET request to the URI of the Introspection
	Document.		Document.
	2. The server responds with the document which enumerates the IRIs		2. The server responds with the document enumerating the IRIs of a
	of all the Collections and the capabilities of those Collections		set of Collections and the capabilities of those Collections
	supported by the server. The content of this document can vary		supported by the server. The content of this document can vary
	based on aspects of the client request, including, but not		based on aspects of the client request, including, but not
	limited to, authentication credentials.		limited to, authentication credentials.
	5.2 Creating a Resource		5.2 Creating a Resource
	Client Server		Client Server
	| |		| |
	| 1.) POST to IRI of Collection |		| 1.) POST to URI of Collection |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 201 Created |		| 2.) 201 Created |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client POSTs a representation of the Member to the IRI 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 resource.		contains the URI of the newly created resource.
	5.3 Editing a Resource		5.3 Editing a Resource
	Once a resource has been created and its IRI is known, that IRI may		Once a resource has been created and its URI is known, that URI may
	be used to retrieve, update, and delete the resource.		be used to retrieve, update, and delete the resource.
	5.3.1 Retrieving a Resource		5.3.1 Retrieving a Resource
	Client Server		Client Server
	| |		| |
	| 1.) GET to Member IRI |		| 1.) GET to Member URI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) Member Representation |		| 2.) Member Representation |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a GET request to the Member's IRI to retrieve		1. The client sends a GET request to the Member's URI to retrieve
	its representation.		its representation.
	2. The server responds with the representation of the resource.		2. The server responds with the representation of the resource.
	5.3.2 Updating a Resource		5.3.2 Updating a Resource
	Client Server		Client Server
	| |		| |
	| 1.) PUT to Member IRI |		| 1.) PUT to Member URI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 OK |		| 2.) 200 OK |
	|<------------------------------------------|		|<------------------------------------------|
	1. The client PUTs an updated representation to the Member's IRI.		1. The client PUTs an updated representation to the Member's URI.
	2. Upon a successful update of the resource the server responds with		2. Upon a successful update of the resource the server responds with
	a status code of 200.		a status code of 200.
	5.3.3 Deleting a Resource		5.3.3 Deleting a Resource
	Client Server		Client Server
	| |		| |
	| 1.) DELETE to Member Resource IRI |		| 1.) DELETE to Member URI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 200 Ok |		| 2.) 200 Ok |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client sends a DELETE request to the Member's IRI.		1. The client sends a DELETE request to the Member's URI.
	2. Upon the successful deletion of the resource the server responds		2. Upon the successful deletion of the resource the server responds
	with a status code of 200.		with a status code of 200.
	5.4 Listing Collection Members		5.4 Listing Collection Members
	To list the members of a Collection the client sends a GET request to		To list the members of a Collection the client sends a GET request to
	the Collection's IRI. An Atom Feed Document is returned containing		the Collection's URI. An Atom Feed Document is returned containing
	one Atom Entry for each member resource. See Section 9 and		one Atom Entry for each member resource. See Section 9 and
	Section 10 for a description of the feed contents.		Section 10 for a description of the feed contents.
	Client Server		Client Server
	| |		| |
	| 1.) GET to List IRI |		| 1.) GET to Collection URI |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) 200 OK, Atom Feed Doc |		| 2.) 200 OK, Atom Feed Doc |
	|<-------------------------------|		|<-------------------------------|
	| |		| |
	1. The client sends a GET request to the Collection's IRI.		1. The client sends a GET request to the Collection's URI.
	2. The server responds with an Atom Feed Document containing the		2. The server responds with an Atom Feed Document containing the
	IRIs of all the collection members that match the selection		IRIs of the collection members.
	criteria.
	5.5 Use of HTTP Response codes		5.5 Use of HTTP Response codes
	The Atom Protocol uses the response status codes defined in HTTP to		The Atom Protocol uses the response status codes defined in HTTP to
	indicate the success or failure of an operation. Consult the HTTP		indicate the success or failure of an operation. Consult the HTTP
	specification [RFC2616] for detailed definitions of each status code.		specification [RFC2616] for detailed definitions of each status code.
	It is strongly recommended that entities contained within HTTP 4xx		It is RECOMMENDED that entities contained within HTTP 4xx and 5xx
	and 5xx responses include a human readable, natural language		responses include an explanation of the error using natural language.
	explanation of the error.
	6. XML-related Conventions		6. XML-related Conventions
	The data format in this specification is specified in terms of the		The Atom Protocol Introspection format is specified in terms of the
	XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204].		XML Information Set [W3C.REC-xml-infoset-20040204], serialised as XML
	Atom Publishing Protocol Documents MUST be well-formed XML. This		1.0 [W3C.REC-xml-20040204]. Atom Publishing Protocol Documents MUST
	specification does not define any DTDs for Atom Protocol, and hence		be well-formed XML. This specification does not define any DTDs for
	does not require them to be "valid" in the sense used by XML.		Atom Protocol, and hence does not require them to be "valid" in the
			sense used by XML.
	6.1 Referring to Information Items		6.1 Referring to Information Items
	This specification uses a shorthand for two common terms: the phrase		This specification uses a shorthand for two common terms: the phrase
	"Information Item" is omitted when discussing Element Information		"Information Item" is omitted when discussing Element Information
	Items and Attribute Information Items. Therefore, when this		Items and Attribute Information Items. Therefore, when this
	specification uses the term "element," it is referring to an Element		specification uses the term "element," it is referring to an Element
	Information Item in Infoset terms. Likewise, when it uses the term		Information Item in Infoset terms. Likewise, when it uses the term
	"attribute," it is referring to an Attribute Information Item.		"attribute," it is referring to an Attribute Information Item.
	skipping to change at page 11, line 40		skipping to change at page 11, line 41
	The choice of namespace prefix is not semantically significant.		The choice of namespace prefix is not semantically significant.
	This specification also uses the prefix "atom:" for		This specification also uses the prefix "atom:" for
	"http://www.w3.org/2005/Atom", the namespace name of the Atom		"http://www.w3.org/2005/Atom", the namespace name of the Atom
	Publishing Format [RFC4287].		Publishing Format [RFC4287].
	6.3 Use of xml:base and xml:lang		6.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 [RFC3986],		serves the function described in section 5.1.1 of URI Generic Syntax
	establishing the base URI (or IRI) for resolving any relative		[RFC3986], establishing the base URI (or IRI) for resolving any
	references found within the effective scope of the xml:base		relative references found within the effective scope of the xml:base
	attribute.		attribute.
	Any element defined by this specification MAY have an xml:lang		Any element defined by this specification MAY have an xml:lang
	attribute, whose content indicates the natural language for the		attribute, whose content indicates the natural language for the
	element and its descendents. The language context is only		element and its descendents. The language context is only
	significant for elements and attributes declared to be "Language-		significant for elements and attributes declared to be "Language-
	Sensitive" by this specification. Requirements regarding the content		Sensitive" by this specification. Requirements regarding the content
	and interpretation of xml:lang are specified in Section 2.12 of XML		and interpretation of xml:lang are specified in Section 2.12 of XML
	1.0 [W3C.REC-xml-20040204].		1.0 [W3C.REC-xml-20040204].
	skipping to change at page 13, line 28		skipping to change at page 13, line 28
	7.1 Example		7.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#">
	<workspace title="Main Site" >		<workspace title="Main Site" >
	<collection		<collection
	title="My Blog Entries"		title="My Blog Entries"
	href="http://example.org/reilly/main" >		href="http://example.org/reilly/main" >
	<member-type>entry</member-type>		<member-type>entry</member-type>
	<list-template>http://example.org/{index}</list-template>
	</collection>		</collection>
	<collection		<collection
	title="Pictures"		title="Pictures"
	href="http://example.org/reilly/pic" >		href="http://example.org/reilly/pic" >
	<member-type>media</member-type>		<member-type>media</member-type>
	<list-template>http://example.org/p/{index}</list-template>
	</collection>		</collection>
	</workspace>		</workspace>
	<workspace title="Side Bar Blog">		<workspace title="Side Bar Blog">
	<collection title="Remaindered Links"		<collection title="Remaindered Links"
	href="http://example.org/reilly/list" >		href="http://example.org/reilly/list" >
	<member-type>entry</member-type>		<member-type>entry</member-type>
	<list-template>http://example.org/l/{index}</list-template>
	</collection>		</collection>
	</workspace>		</workspace>
	</service>		</service>
	This Introspection Document describes two workspaces. The first,		This Introspection Document describes two workspaces. The first,
	called "Main Site", has two collections called "My Blog Entries" and		called "Main Site", has two collections called "My Blog Entries" and
	"Pictures" whose IRIs are "http://example.org/reilly/main" and		"Pictures" whose URIs are "http://example.org/reilly/main" and
	"http://example.org/reilly/pic" respectively. "My Blog Entries" is		"http://example.org/reilly/pic" respectively. "My Blog Entries" is
	an Entry collection and "Pictures" is a Media collection. Entry and		an Entry collection and "Pictures" is a Media collection. Entry and
	Media collections are discussed in Section 7.2.4.		Media collections are discussed in Section 7.2.4.
	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 collection IRI is		collection called "Remaindered Links" whose collection URI is
	"http://example.org/reilly/list". "Remaindered Links" is an Entry		"http://example.org/reilly/list". "Remaindered Links" is an Entry
	collection.		collection.
	7.2 Element Definitions		7.2 Element Definitions
	7.2.1 The "app:service" Element		7.2.1 The "app:service" Element
	The root of an introspection document is the "app:service" element.		The root of an introspection document is the "app:service" element.
	namespace app = "http://purl.org/atom/app#"
	start = appService
	The "app:service" element is the container for introspection		The "app:service" element is the container for introspection
	information associated with one or more workspaces. An app:service		information associated with one or more workspaces. An app:service
	element MUST contain one or more app:workspace elements.		element MUST contain one or more app:workspace elements.
			namespace app = "http://purl.org/atom/app#"
			start = appService
	appService =		appService =
	element app:service {		element app:service {
	appCommonAttributes,		appCommonAttributes,
	( appWorkspace+		( appWorkspace+
	& extensionElement* )		& extensionElement* )
	}		}
	7.2.2 The "app:workspace" Element		7.2.2 The "app:workspace" Element
	The "app:workspace" element contains information elements about the		The "app:workspace" element contains information elements about the
	skipping to change at page 14, line 43		skipping to change at page 14, line 40
	element MUST contain one or more app:collection elements.		element MUST contain one or more app:collection elements.
	appWorkspace =		appWorkspace =
	element app:workspace {		element app:workspace {
	appCommonAttributes,		appCommonAttributes,
	attribute title { text },		attribute title { text },
	( appCollection+		( appCollection+
	& extensionElement* )		& extensionElement* )
	}		}
	In an app:workspace element, the first app:collection element SHOULD		In an app:workspace element, the first app:collection element of each
	refer to the preferred or primary collection. In the following		type MUST refer to the preferred or primary collection. In the
	example, the "Entries" collection would be considered the "preferred"		following example, the "Entries" collection would be considered the
	or "primary" collection of the workspace:		preferred (or primary) entries collection of the workspace and the
			"Photos" collection would be considered the primary media collection:
	<service>		<service>
	<workspace title="My Blog">		<workspace title="My Blog">
	<collection title="Entries" ... >		<collection title="Entries"
	<collection title="Photos" ... >		href="http://example.org/myblog/entries">
			<member-type>entry</member-type>
			</collection>
			<collection title="Photos"
			href="http://example.org/myblog/fotes">
			<member-type>media</member-type>
			</collection>
	</workspace>		</workspace>
	</service>		</service>
	7.2.2.1 The "title" Attribute		7.2.2.1 The "title" Attribute
	The app:workspace element MUST contain a "title" attribute, which		The app:workspace element MUST contain a "title" attribute, which
	gives a human-readable name for the workspace. This attribute is		gives a human-readable name for the workspace. This attribute is
	Language-Sensitive.		Language-Sensitive.
	7.2.3 The "app:collection" Element		7.2.3 The "app:collection" Element
	The "app:collection" describes a collection. This specification		The "app:collection" describes an Atom Protocol collection. One
	defines one child element: app:member-type.		child element is defined here for app:collection: "app:member-type".
	appCollection =		appCollection =
	element app:collection {		element app:collection {
	appCommonAttributes,		appCommonAttributes,
	attribute title { text },		attribute title { text },
	attribute href { text },		attribute href { text },
	( appMemberType		( appMemberType
	& appListTemplate		& appListTemplate
	& extensionElement* )		& extensionElement* )
	}		}
	skipping to change at page 16, line 13		skipping to change at page 16, line 19
	members that can appear in the collection.		members that can appear in the collection.
	appMemberType =		appMemberType =
	element app:member-type {		element app:member-type {
	appCommonAttributes,		appCommonAttributes,
	( appTypeValue )		( appTypeValue )
	}		}
	appTypeValue = "entry" | "media"		appTypeValue = "entry" | "media"
	An Entry POSTed to a collection MUST meet the constraints of the app:
	member-type element.
	This specification defines two values for the app:member-type		This specification defines two values for the app:member-type
	element:		element:
	o "entry" - The collection contains only member resources whose		o "entry" - Indicates the collection contains only member resources
	representation MUST be an Atom Entry. Further constraints on the		whose representation MUST be an Atom Entry. Further constraints
	representations of members in a collection of type "entry" are		on the representations of members in a collection of type "entry"
	listed in Section 8.2.		are listed in Section 8.2.
	o "media" - The collection contains member resources whose		o "media" - Indicates the collection contains member resources whose
	representation can be of any media type. Additional constraints		representation can be of any media type. Additional constraints
	are listed in Section 8.3.		are listed in Section 8.3.
	8. Collections		8. Collections
	8.1 Creating resources with POST		8.1 Creating resources with POST
	To add members to a collection, clients send POST requests to the		To add members to a collection, clients send POST requests to the
	collection's URI. Collections MAY impose constraints on the media-		collection's URI. Collections MAY impose constraints on the media-
	types that are created in a collection and MAY generate a response		types that are created in a collection and MAY generate a response
	with a status code of 415 ("Unsupported Media Type"). On successful		with a status code of 415 ("Unsupported Media Type"). On successful
	creation, the response to the POST request MUST return a Location:		creation, the response to the POST request MUST return a Location:
	header with the URI of the newly created resource.		header with the URI of the newly created resource.
	8.1.1 Example		8.1.1 Example
	Below, the client requests to create a resource with an Atom Entry		Below, the client sends a POST request containing an Atom Entry
	representation in a collection:		representation to the URI of the Collection:
	POST /edit 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
	Content-Type: application/atom+xml		Content-Type: application/atom+xml
	Content-Length: nnn		Content-Length: nnn
	<entry xmlns="http://www.w3.org/2005/Atom">		<entry xmlns="http://www.w3.org/2005/Atom">
	<title>Atom-Powered Robots Run Amok</title>		<title>Atom-Powered Robots Run Amok</title>
	<link href="http://example.org/2003/12/13/atom03"/>
	<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>
	<summary>Some text.</summary>		<content>Some text.</content>
	</entry>		</entry>
	The resource is created by sending an Atom Entry as the entity body.
	Successful creation is indicated by a 201 created response and		The server signals a successful creation with a status code of 201
	includes a Location: header:		and the response includes a 'Location' header indicating the URI of
			the Atom Entry.
	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: 0		Content-Length: 0
	Location: http://example.org/edit/first-post.atom		Location: http://example.org/edit/first-post.atom
	8.1.2 Title: Header		8.1.2 Title: Header
	A POST to a collection creating a resource MAY contain a Title:		A POST to a Media Collection creating a resource SHOULD contain a
	header that indicates the client's suggested title for the resource.		Title: header that indicates the client's suggested title for the
	The Title header is primarily for use with Media collections and is		resource:
	RECOMMENDED for use with such collections. The server MAY ignore the
	content of the Title: header or modify the suggested title.
	Title = "Title" ":" [text]		POST /myblog/fotes HTTP/1.1
			Host: example.org
			User-Agent: Thingio/1.0
			Content-Type: image/png
			Content-Length: nnnn
			Title: An Atom-Powered Robot
			...binary data...
			The server MAY ignore the content of the Title: header or modify the
			suggested title.
			Title = "Title" ":" [TEXT]
	The syntax of this header MUST conform to the augmented BNF grammar		The syntax of this header MUST conform to the augmented BNF grammar
	in section 2.1 of the HTTP/1.1 specification [RFC2616].		in section 2.1 of the HTTP/1.1 specification [RFC2616]. The [TEXT]
			rule is described in section 2.2 of the same document. Words of
			*TEXT MAY contain characters from character sets other than
			[ISO88591] [ISO-8859-1] only when encoded according to the rules of
			[RFC2047] [RFC2047].
	8.2 Entry Collections		8.2 Entry Collections
	Entry Collections are collections that restrict their membership to		Entry Collections are collections that restrict their membership to
	Atom Entries. They are identified by having an app:member-type of		Atom Entries. They are identified by having an app:member-type of
	"entry". Every member representation MUST contain an atom:link		"entry". Every member representation MAY contain an atom:link
	element with a link relation of "edit" that contains the IRI of the		element with a link relation of "edit" that contains the IRI of the
	member resource. Member representations MAY contain an app:control		member resource. Member representations MAY contain a pub:control
	element (Section 11).		element (Section 11).
			8.2.1 Editing entries with foreign markup
			To avoid unintentional loss of data when editing entry collection
			members, Atom Protocol clients SHOULD preserve all metadata,
			including unknown foreign markup, that has not been intentionally
			modified.
	8.3 Media Collections		8.3 Media Collections
	Media Collections are collections whose member representations are		Media Collections are collections whose member representations are
	not constrained. They are identified by having an app:member-type of		not constrained. They are identified by having an app:member-type of
	"media".		"media".
	8.3.1 Editing Media Resources		8.3.1 Editing Media Resources
	When a membership list resource returns an Atom Feed enumerating the		When listing the contents of a Media Collection, every Entry in the
	contents of a Media Collection, all the Entries MUST have an atom:		Atom Feed Document MUST have an atom:content element with a "src"
	content element with a "src" attribute. When creating a public,		attribute containing the IRI of the media resource itself. This
	read-only reference to the member resource, a client SHOULD use the		value may be used to update and delete resources as described in
	"atom:content/@src" attribute value.		Section 5.3. When creating a public, read-only reference to the
			member resource, a client SHOULD use this value.
			8.3.2 Editing Media Metadata
			Entries in a Media Collection MAY contain an atom:link element with a
			link relation of "edit" that contains the IRI of an Atom Entry
			document representing the metadata of the member resource. A client
			MAY use this to edit the metadata associated with the resource.
	9. Listing Collections		9. Listing Collections
	Collections, as identified in an Introspection Document, are		Collection resources MUST provide representations in the form of Atom
	resources that MUST provide representations in the form of Atom Feed		Feed documents. Each entry in the Feed Document MUST have an atom:
	documents when dereferencing the collection IRI. The entries in the		link element with a relation of "edit" (See Section 10.1).
	returned Feed MUST be ordered by their 'atom:updated' property, with
	the most recently updated entries coming first in the document order.		The entries in the returned Atom Feed MUST be ordered by their "atom:
	Every entry in the Feed Document MUST have an atom:link element with		updated" property, with the most recently updated entries coming
	a relation of "edit" (See Section 10.1). Clients MUST NOT assume		first in the document order. Clients SHOULD be constructed in
	that an Atom Entry returned in the Feed is a full representation of a		consideration that changes which do not alter the entry's atom:
	member resource. The value of atom:updated is only changed when the		updated value will not affect the position of the entry in a
	change to a member resource is considered significant. Insignificant		collection.
	changes do not result in changes to the atom:updated value and thus
	do not change the position of the corresponding entry in a membership		Clients MUST NOT assume that an Atom Entry returned in the Feed is a
	list. Clients SHOULD be constructed with this in mind and SHOULD		full representation of a member resource and SHOULD perform a GET on
	perform a GET on the member resource before editing.		the member resource before editing.
	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 containing the most recently updated member		return a partial listing containing 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 IRI of the next partial		"next" relation whose "href" value is the URI of the next partial
	listing of the collection (the least recently updated member		listing of the collection (the least recently updated member
	resources) where it exists. This is called "collection paging".		resources) where it exists. This is called "collection paging".
	9.1 Collection Paging		9.1 Collection Paging
	Atom Protocol servers MUST provide representations of collections as		Atom Protocol servers MUST provide representations of collections as
	Atom feed documents whose entries represent the collection's members.		Atom feed documents whose entries represent the collection's members.
	The returned Atom feed MAY NOT contain entries for all the		The returned Atom feed MAY NOT contain entries for all the
	collection's members. Instead, the Atom feed document MAY contain		collection's members. Instead, the Atom feed document MAY contain
	link elements with "rel" attribute values of "next", "previous",		link elements with "rel" attribute values of "next", "previous",
	"start" and "end" that can be used to navigate through the complete		"first" and "last" that can be used to navigate through the complete
	set of matching entries.		set of matching entries.
	For instance, suppose the client is supplied this IRI		For instance, suppose a client is supplied the URI
	http://example.org/entries/go		"http://example.org/entries/go" of a collection of member entries,
			where the server as a matter of policy avoids generating feed
	Supposing the collection contains member entries and the server as a		documents containing more than 10 entries. The Atom feed document
	matter of policy wishes to avoid generating feed documents with more		for the collection will then represent the first 'page' in a set of
	than 10 entries, then the resulting Atom feed document represents the		10 linked feed documents. The "first" relation will reference the
	first page in a linked set of 10 feed documents. Within each feed		initial feed document in the set and the "last" relation references
	document served, "next" and "prev" link elements reference the		the final feed document in the set. Within each document, the "next"
	preceding and subsequent feed documents in the set. The "start" link		and "previous" link relations reference the preceding and subsequent
	element references the first feed document in the set. The "end"		documents.
	link element references the final feed document in the set.
	<feed xmlns="http://www.w3.org/2005/Atom">		<feed xmlns="http://www.w3.org/2005/Atom">
	...		<link rel="first"
	<link rel="start"
	href="http://example.org/entries/go" />		href="http://example.org/entries/go" />
	<link rel="next"		<link rel="next"
	href="http://example.org/entries/2" />		href="http://example.org/entries/2" />
	<link rel="last"		<link rel="last"
	href="http://example.org/entries/10" />		href="http://example.org/entries/10" />
			...
	</feed>		</feed>
	The 'next' and 'prev' link elements for the feed located at		The "next" and "previous" link elements for the feed 'page' located
	http://example.org/entries/2 would look like this:		at "http://example.org/entries/2" would look like this:
	<feed xmlns="http://www.w3.org/2005/Atom">		<feed xmlns="http://www.w3.org/2005/Atom">
	...		<link rel="first"
	<link rel="start"
	href="http://example.org/entries/go" />		href="http://example.org/entries/go" />
	<link rel="previous"		<link rel="previous"
	href="http://example.org/entries/go" />		href="http://example.org/entries/go" />
	<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. Atom Format Link Relation Extensions		10. Atom Format Link Relation Extensions
	10.1 The "edit" Link Relation		10.1 The "edit" Link Relation
	The Atom Protocol adds the value "edit" to the Atom Registry of Link		The Atom Protocol 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 IRI in the value of the href attribute is the IRI		specifies that the IRI in the value of the href attribute is the IRI
	of the member resource, and is intended to be used to update and		of an editable Atom Entry Document associated with a resource. In a
	delete resources as described in this specification. This link		Media Collection this IRI may be used to update the metadata
	relation MAY appear in both membership lists and in member		associated with a Media Resource. In an Entry Collection this IRI
	representations.		may be used to update and delete the member resource itself. The
			link relation MAY appear in Atom Entry representations as well as
			Entry and Media Collections.
	11. Atom Publishing Control Extensions		11. Atom Publishing Control Extensions
	11.1 The Atom Publishing Control Namespace		11.1 The Atom Publishing Control Namespace
	This specification defines an Atom Format extension for publishing		This specification defines an Atom Format extension for publishing
	control called Atom Publishing Control. The namespace name for the		control called Atom Publishing Control. The namespace name for the
	Atom Publishing Control's XML vocabulary is		Atom Publishing Control's XML vocabulary is
	"http://example.net/appns/". This specification uses "pub:" for the		"http://example.net/appns/". This specification uses "pub:" for the
	namespace prefix. The choice of namespace prefix is not semantically		namespace prefix. The choice of namespace prefix is not semantically
	skipping to change at page 22, line 48		skipping to change at page 23, line 48
	The "pub:control" element MAY contain exactly one "pub:draft" element		The "pub:control" element MAY contain exactly one "pub:draft" element
	as defined here, and MAY contain zero or more extension elements as		as defined here, and MAY contain zero or more extension elements as
	outlined in Section 6 of [RFC4287]. Both clients and servers MUST		outlined in Section 6 of [RFC4287]. Both clients and servers MUST
	ignore foreign markup present in the pub:control element.		ignore foreign markup present in the pub:control element.
	11.2.1 The "pub:draft" Element		11.2.1 The "pub:draft" Element
	The number of "pub:draft" elements in "pub:control" MUST be zero or		The number of "pub:draft" elements in "pub:control" MUST be zero or
	one. Its value MUST be one of "yes" or "no". A value of "no" means		one. Its value MUST be one of "yes" or "no". A value of "no" means
	that the entry may be made publicly visible. If the "pub:draft"		that the entry MAY be made publicly visible. If the "pub:draft"
	element is missing then the value is understood to be "no". If "pub:		element is missing then the value MUST be understood to be "no". The
	control" and/or the "pub:draft" elements are missing from an entry		pub:draft element MAY be ignored.
	then the entry is not considered a draft and can be made publicly
	visible.
	12. Atom Publishing Protocol Example		12. Atom Publishing Protocol Example
	This is an example of a client creating a new entry with an image.		This is an example of a client creating a new entry with an image.
	The client has an image to publish and an entry that includes an HTML		The client has an image to publish and an entry that includes an HTML
	"img" element that uses that image. In this scenario we consider a		"img" element that uses that image. In this scenario we consider a
	client that has IRIs of two collections, an entry collection and a		client that has IRIs of two collections, an entry collection and a
	media collection, both of which were discovered through an		media collection, both of which were discovered through an
	introspection document. The IRI of the entry collection is:		introspection document. The IRI of the entry collection is:
	skipping to change at page 23, line 43		skipping to change at page 24, line 43
	returned.		returned.
	HTTP/1.1 201 Created		HTTP/1.1 201 Created
	Date: Fri, 25 Mar 2005 17:17:11 GMT		Date: Fri, 25 Mar 2005 17:17:11 GMT
	Content-Length: nnnn		Content-Length: nnnn
	Content-Type: application/atom+xml		Content-Type: application/atom+xml
	Location: http://example.net/binary/edit/b/129.png		Location: http://example.net/binary/edit/b/129.png
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	<entry xmlns="http://www.w3.org/2005/Atom">		<entry xmlns="http://www.w3.org/2005/Atom">
	<title>A picture of the beach.</title>		<title>A picture of the beach</title>
	<link rel="edit"		<link rel="edit"
	href="http://example.net/binary/edit/b/129.png"/>		href="http://example.net/binary/edit/b/129.png"/>
	<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-568596895695</id>		<id>urn:uuid:1225c695-cfb8-4ebb-aaaa-568596895695</id>
	<updated>2005-09-02T10:30:00Z</updated>		<updated>2005-09-02T10:30:00Z</updated>
	<summary>Waves</summary>		<summary>Waves</summary>
	<content type="image/png"		<content type="image/png"
	src="http://example.net/binary/readonly/129.png"/>		src="http://example.net/binary/readonly/129.png"/>
	</entry>		</entry>
	The client then POSTs the Atom Entry that refers to the newly created		The client then POSTs the Atom Entry that refers to the newly created
	image resource. Note that the client takes the IRI		image resource. Note that the client takes the URI
	http://example.net/binary/readonly/129.png and uses it in the 'img'		http://example.net/binary/readonly/129.png and uses it in the 'img'
	element in the Entry content:		element in the Entry content:
	POST /blog/edit/ HTTP/1.1		POST /blog/edit/ HTTP/1.1
	Host: example.net		Host: example.net
	User-Agent: Thingio/1.0		User-Agent: Thingio/1.0
	Content-Type: application/atom+xml		Content-Type: application/atom+xml
	Content-Length: nnnn		Content-Length: nnnn
	<?xml version="1.0" encoding="utf-8"?>		<?xml version="1.0" encoding="utf-8"?>
	skipping to change at page 24, line 28		skipping to change at page 25, line 28
	<link href="http://example.org/atom05"/>		<link href="http://example.org/atom05"/>
	<id>urn:uuid:1225c695-ffb8-4ebb-aaaa-80da354efa6a</id>		<id>urn:uuid:1225c695-ffb8-4ebb-aaaa-80da354efa6a</id>
	<updated>2005-09-02T10:30:00Z</updated>		<updated>2005-09-02T10:30:00Z</updated>
	<summary>Beach!</summary>		<summary>Beach!</summary>
	<content type="xhtml" xml:lang="en">		<content type="xhtml" xml:lang="en">
	<div xmlns="http://www.w3.org/1999/xhtml">		<div xmlns="http://www.w3.org/1999/xhtml">
	<p>We went to the beach for summer vacation.		<p>We went to the beach for summer vacation.
	Here is a picture of the waves rolling in:		Here is a picture of the waves rolling in:
	<img		<img
	src="http://example.net/binary/readonly/129.png"		src="http://example.net/binary/readonly/129.png"
	alt="A picture of the beach."		alt="A picture of the beach"
	/>		/>
	</p>		</p>
	</div>		</div>
	</content>		</content>
	</entry>		</entry>
	13. Securing the Atom Protocol		13. Securing the Atom Protocol
	All instances of publishing Atom Format entries SHOULD be protected		All instances of publishing Atom Format entries SHOULD be protected
	by authentication to prevent posting or editing by unknown sources.		by authentication to prevent posting or editing by unknown sources.
	Atom Protocol servers and clients MUST support one of the following		Atom Protocol servers and clients MUST support one of the following
	authentication mechanisms, and SHOULD support both.		authentication mechanisms, and SHOULD support both.
	o HTTP Digest Authentication [RFC2617]		o HTTP Digest Authentication [RFC2617]
	o CGI Authentication		o CGI Authentication
	Atom Protocol servers and clients MAY support encryption of the		Atom Protocol servers and clients MAY support encryption of the
	session using TLS (see [RFC2246]).		session using TLS (see [RFC2246]).
	There are cases where an authentication mechanism is not be required,		There are cases where an authentication mechanism might not be
	such as a publicly editable Wiki, or when using POST to send comments		required, such as a publicly editable Wiki, or when using POST to
	to a site that does not require authentication from a commenter.		send comments to a site that does not require authentication from a
			commenter.
	13.1 CGI Authentication		13.1 CGI Authentication
	[[anchor26: This section is incomplete; cgi-authentication is		[[anchor27: note: this section is incomplete; cgi-authentication is
	described but is unspecified.]] This authentication method is		described but is unspecified.]] This authentication method is
	included as part of the protocol to allow Atom Protocol servers and		included as part of the protocol to allow Atom Protocol servers and
	clients that cannot use HTTP Digest Authentication but where the user		clients that cannot use HTTP Digest Authentication but where the user
	can both insert its own HTTP headers and create a CGI program to		can both insert its own HTTP headers and create a CGI program to
	authenticate entries to the server. This scenario is common in		authenticate entries to the server. This scenario is common in
	environments where the user cannot control what services the server		environments where the user cannot control what services the server
	employs, but the user can write their own HTTP services.		employs, but the user can write their own HTTP services.
	14. Security Considerations		14. Security Considerations
	The security of the Atom Protocol is based on HTTP Digest		The security of the Atom Protocol is based on HTTP Digest
	Authentication and/or CGI Authentication [[anchor28: refers to		Authentication and/or CGI Authentication [[anchor29: note: refers to
	incomplete section]]. Any weaknesses in either of these		incomplete section]]. Any weaknesses in either of these
	authentication schemes will affect the security of the Atom		authentication schemes will affect the security of the Atom
	Publishing Protocol.		Publishing Protocol.
	Both HTTP Digest Authentication and CGI Authentication [[anchor29:		Both HTTP Digest Authentication and CGI Authentication [[anchor30:
	refers to incomplete section]] are susceptible to dictionary-based		note: refers to incomplete section]] are susceptible to dictionary-
	attacks on the shared secret. If the shared secret is a password		based attacks on the shared secret. If the shared secret is a
	(instead of a random string with sufficient entropy), an attacker can		password (instead of a random string with sufficient entropy), an
	determine the secret by exhaustively comparing the authenticating		attacker can determine the secret by exhaustively comparing the
	string with hashed results of the public string and dictionary		authenticating string with hashed results of the public string and
	entries.		dictionary entries.
	See [RFC2617] for the description of the security properties of HTTP		See [RFC2617] for the description of the security properties of HTTP
	Digest Authentication.		Digest Authentication.
	[[anchor30: expand on HTTP basic and digest authentication, or		[[anchor31: expand on HTTP basic and digest authentication, or
	refer.]]		refer.]]
	[[anchor31: talk here about denial of service attacks using large XML		[[anchor32: note: talk here about denial of service attacks using
	files, or the billion laughs DTD attack.]]		large XML files, or the billion laughs DTD attack.]]
	15. IANA Considerations		15. IANA Considerations
	An Atom Publishing Protocol Introspection Document, when serialized		An Atom Publishing Protocol Introspection Document, when serialized
	as XML 1.0, can be identified with the following media type:		as XML 1.0, can be identified with the following media type:
	MIME media type name: application		MIME media type name: application
	MIME subtype name: atomserv+xml		MIME subtype name: atomserv+xml
	skipping to change at page 27, line 26		skipping to change at page 28, line 26
	Optional parameters:		Optional parameters:
	"charset": This parameter has identical semantics to the charset		"charset": This parameter has identical semantics to the charset
	parameter of the "application/xml" media type as specified in		parameter of the "application/xml" media type as specified in
	[RFC3023].		[RFC3023].
	Encoding considerations: Identical to those of "application/xml" as		Encoding considerations: Identical to those of "application/xml" as
	described in [RFC3023], section 3.2.		described in [RFC3023], section 3.2.
	Security considerations: As defined in this specification.		Security considerations: As defined in this specification.
	[[anchor32: update upon publication]]		[[anchor33: update upon publication]]
	In addition, as this media type uses the "+xml" convention, it		In addition, as this media type uses the "+xml" convention, it
	shares the same security considerations as described in [RFC3023],		shares the same security considerations as described in [RFC3023],
	section 10.		section 10.
	Interoperability considerations: There are no known interoperability		Interoperability considerations: There are no known interoperability
	issues.		issues.
	Published specification: This specification. [[anchor33: update upon		Published specification: This specification. [[anchor34: update upon
	publication]]		publication]]
	Applications that use this media type: No known applications		Applications that use this media type: No known applications
	currently use this media type.		currently use this media type.
	Additional information:		Additional information:
	Magic number(s): As specified for "application/xml" in [RFC3023],		Magic number(s): As specified for "application/xml" in [RFC3023],
	section 3.2.		section 3.2.
	skipping to change at page 28, line 14		skipping to change at page 29, line 14
	Base URI: As specified in [RFC3023], section 6.		Base URI: As specified in [RFC3023], section 6.
	Macintosh File Type code: TEXT		Macintosh File Type code: TEXT
	Person and email address to contact for further information: Joe		Person and email address to contact for further information: Joe
	Gregorio <joe@bitworking.org>		Gregorio <joe@bitworking.org>
	Intended usage: COMMON		Intended usage: COMMON
	Author/Change controller: This specification's author(s). [[anchor34:		Author/Change controller: This specification's author(s). [[anchor35:
	update upon publication]]		update upon publication]]
	16. References		16. References
	16.1 Normative References		16.1 Normative References
			[ISO88591]
			ISO, "International Standard -- Information Processing --
			8-bit Single-Byte Coded Graphic Character Sets -- Part 1:
			Latin alphabet No. 1,", January 1987.
			[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
			Part Three: Message Header Extensions for Non-ASCII Text",
			RFC 2047, November 1996.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",		[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
	RFC 2246, January 1999.		RFC 2246, January 1999.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	skipping to change at page 29, line 42		skipping to change at page 30, line 51
	Identifiers (IRIs)", RFC 3987, January 2005.		Identifiers (IRIs)", RFC 3987, January 2005.
	[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication		[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
	Format", RFC 4287, December 2005.		Format", RFC 4287, December 2005.
	[W3C.REC-xml-20040204]		[W3C.REC-xml-20040204]
	Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,		Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T.,
	and E. Maler, "Extensible Markup Language (XML) 1.0 (Third		and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
	Edition)", W3C REC REC-xml-20040204, February 2004.		Edition)", W3C REC REC-xml-20040204, February 2004.
			[W3C.REC-xml-infoset-20040204]
			Cowan, J., Tobin, R., and A. Layman, "XML Information Set
			(Second Edition)", W3C REC W3C.REC-xml-infoset-20040204,
			February 2004.
	[W3C.REC-xml-names-19990114]		[W3C.REC-xml-names-19990114]
	Hollander, D., Bray, T., and A. Layman, "Namespaces in		Hollander, D., Bray, T., and A. Layman, "Namespaces in
	XML", W3C REC REC-xml-names-19990114, January 1999.		XML", W3C REC REC-xml-names-19990114, January 1999.
	[W3C.REC-xmlbase-20010627]		[W3C.REC-xmlbase-20010627]
	Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627,		Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627,
	June 2001.		June 2001.
	16.2 Informative References		16.2 Informative References
	skipping to change at page 34, line 15		skipping to change at page 35, line 15
	( appCollection+		( appCollection+
	& extensionElement* )		& extensionElement* )
	}		}
	# app:collection		# app:collection
	appCollection =		appCollection =
	element app:collection {		element app:collection {
	appCommonAttributes,		appCommonAttributes,
	attribute title { text },		attribute title { text },
	attribute href { text },		attribute href { atomUri },
	( appMemberType		( appMemberType
	& appListTemplate
	& extensionElement* )		& extensionElement* )
	}		}
	# app:member		# app:member
	appMemberType =		appMemberType =
	element app:member-type {		element app:member-type {
	appCommonAttributes,		appCommonAttributes,
	( appTypeValue )		( appTypeValue )
	}		}
	appTypeValue = "entry" | "media"		appTypeValue = "entry" | "media"
	# app:list-template
	appListTemplate =
	element app:list-template {
	appCommonAttributes,
	( appUriTemplate )
	}
	# Whatever an IRI template is, it contains at least {index}
	appUriTemplate = xsd:string { pattern = ".+\{index\}.*" }
	# Simple Extension		# Simple Extension
	simpleExtensionElement =		simpleExtensionElement =
	element * - app:* {		element * - app:* {
	text		text
	}		}
	# Structured Extension		# Structured Extension
	structuredExtensionElement =		structuredExtensionElement =
	element * - app:* {		element * - app:* {
	(attribute * { text }+,		(attribute * { text }+,
	(text|anyElement)*)		(text|anyElement)*)
	| (attribute * { text }*,		| (attribute * { text }*,
	(text?, anyElement+, (text|anyElement)*))		(text?, anyElement+, (text|anyElement)*))
	}		}
	skipping to change at page 36, line 7		skipping to change at page 37, line 7
	element * {		element * {
	(attribute * { text }		(attribute * { text }
	| text		| text
	| anyElement)*		| anyElement)*
	}		}
	# EOF		# EOF
	Appendix C. Revision History		Appendix C. Revision History
			draft-ietf-atompub-protocol-08: added infoset ref; added wording re
			IRI/URI; fixed URI/IRI ; next/previous fixed as per Atom
			LinkRelations Attribute
			(http://www.imc.org/atom-protocol/mail-archive/msg04095.html);
			incorporated: PaceEditLinkMustToMay; PaceMissingDraftHasNoMeaning,
			PaceRemoveMemberTypeMust, PaceRemoveMemberTypePostMust,
			PaceTitleHeaderOnlyInMediaCollections, PacePreserveForeignMarkup,
			PaceClarifyTitleHeader, PaceClarifyMediaResourceLinks,
			PaceTwoPrimaryCollections;
	draft-ietf-atompub-protocol-07: updated Atom refs to RFC4287;		draft-ietf-atompub-protocol-07: updated Atom refs to RFC4287;
	incorporated PaceBetterHttpResponseCode;		incorporated PaceBetterHttpResponseCode;
	PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore;		PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore;
	PaceRemoveAcceptPostText; PaceRemoveListTemplate2;		PaceRemoveAcceptPostText; PaceRemoveListTemplate2;
	PaceRemoveRegistry; PaceRemoveWhoWritesWhat;		PaceRemoveRegistry; PaceRemoveWhoWritesWhat;
	PaceSimplifyClarifyBetterfyRemoveBogusValidityText;		PaceSimplifyClarifyBetterfyRemoveBogusValidityText;
	PaceCollectionOrderSignificance; PaceFixLostIntrospectionText;		PaceCollectionOrderSignificance; PaceFixLostIntrospectionText;
	PaceListPaging; PaceCollectionControl; element typo in Listing		PaceListPaging; PaceCollectionControl; element typo in Listing
	collections para3 (was app:member-type, not app:list-template);		collections para3 (was app:member-type, not app:list-template);
	changed post atom entry example to be valid. Dropped inline use of		changed post atom entry example to be valid. Dropped inline use of
End of changes.
This html diff was produced by rfcdiff 1.12, available from http://www.levkowetz.com/ietf/tools/rfcdiff/