draft-ietf-atompub-protocol-06.txt		draft-ietf-atompub-protocol-07.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft BitWorking, Inc
	Expires: April 30, 2006 B. de hOra, Ed.		Expires: July 5, 2006 B. de hOra, Ed.
	Propylon Ltd.		Propylon Ltd.
	October 27, 2005		January 01, 2006
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-06.txt		draft-ietf-atompub-protocol-07.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 30, 2006.		This Internet-Draft will expire on July 5, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2006).
	Abstract		Abstract
	The Atom Publishing Protocol (APP) is an application-level protocol		The Atom Publishing Protocol (APP) is an application-level protocol
	for publishing and editing Web resources. The protocol is based on		for publishing and editing Web resources. The protocol is based on
	HTTP transport of Atom-formatted representations. The Atom format is		HTTP transport of Atom-formatted representations. The Atom format is
	documented in the Atom Syndication Format		documented in the Atom Syndication Format (RFC4287).
	(draft-ietf-atompub-format-11.txt).
	Editorial Note		Editorial Note
	To provide feedback on this Internet-Draft, join the atom-protocol		To provide feedback on this Internet-Draft, join the atom-protocol
	mailing list (http://www.imc.org/atom-protocol/index.html) [1].		mailing list (http://www.imc.org/atom-protocol/index.html) [1].
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5		2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
	4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7		4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
	5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 8		5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 8
	5.1 Retrieving an Introspection Document . . . . . . . . . . . 8		5.1 Retrieving an Introspection Document . . . . . . . . . . . 8
	5.2 Creating a Resource . . . . . . . . . . . . . . . . . . . 8		5.2 Creating a Resource . . . . . . . . . . . . . . . . . . . 8
	5.3 Editing a Resource . . . . . . . . . . . . . . . . . . . . 8		5.3 Editing a Resource . . . . . . . . . . . . . . . . . . . . 8
	5.3.1 Retrieving a Resource . . . . . . . . . . . . . . . . 9		5.3.1 Retrieving a Resource . . . . . . . . . . . . . . . . 9
	5.3.2 Updating a Resource . . . . . . . . . . . . . . . . . 9		5.3.2 Updating a Resource . . . . . . . . . . . . . . . . . 9
	5.3.3 Deleting a Resource . . . . . . . . . . . . . . . . . 9		5.3.3 Deleting a Resource . . . . . . . . . . . . . . . . . 9
	5.4 Listing Collections . . . . . . . . . . . . . . . . . . . 10		5.4 Listing Collection Members . . . . . . . . . . . . . . . . 10
	5.5 Success and Failure . . . . . . . . . . . . . . . . . . . 10		5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 10
	6. XML-related Conventions . . . . . . . . . . . . . . . . . . 11		6. XML-related Conventions . . . . . . . . . . . . . . . . . . 11
	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 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 11		6.3 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11
	6.4 Use of xml:base and xml:lang . . . . . . . . . . . . . . . 11		6.4 RELAX NG Schema . . . . . . . . . . . . . . . . . . . . . 12
	7. Introspection Documents . . . . . . . . . . . . . . . . . . 13		7. Introspection Documents . . . . . . . . . . . . . . . . . . 13
	7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 13		7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13		7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14
	7.3 Element Definitions . . . . . . . . . . . . . . . . . . . 14		7.2.1 The "app:service" Element . . . . . . . . . . . . . . 14
	7.3.1 The 'app:service' Element . . . . . . . . . . . . . . 14		7.2.2 The "app:workspace" Element . . . . . . . . . . . . . 14
	7.3.2 The 'app:workspace' Element . . . . . . . . . . . . . 14		7.2.3 The "app:collection" Element . . . . . . . . . . . . . 15
	7.3.3 The 'app:collection' Element . . . . . . . . . . . . . 15		7.2.4 The "app:member-type" Element . . . . . . . . . . . . 15
	7.3.4 The 'app:member-type' Element . . . . . . . . . . . . 15		8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.3.5 The 'app:list-template' Element . . . . . . . . . . . 16		8.1 Creating resources with POST . . . . . . . . . . . . . . . 17
	8. Collections . . . . . . . . . . . . . . . . . . . . . . . . 18		8.1.1 Example . . . . . . . . . . . . . . . . . . . . . . . 17
	8.1 Creating resources with POST . . . . . . . . . . . . . . . 18		8.1.2 Title: Header . . . . . . . . . . . . . . . . . . . . 17
	8.1.1 Title: Header . . . . . . . . . . . . . . . . . . . . 18		8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 18
	8.2 Entry Collections . . . . . . . . . . . . . . . . . . . . 19		8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 18
	8.2.1 Role of Atom Entry Elements During Editing . . . . . . 19		8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 18
	8.3 Media Collections . . . . . . . . . . . . . . . . . . . . 20		9. Listing Collections . . . . . . . . . . . . . . . . . . . . 19
	8.3.1 Editing Media Resources . . . . . . . . . . . . . . . 20		9.1 Collection Paging . . . . . . . . . . . . . . . . . . . . 19
	9. Listing Collections . . . . . . . . . . . . . . . . . . . . 21		10. Atom Format Link Relation Extensions . . . . . . . . . . . . 21
	10. Atom Entry Extensions . . . . . . . . . . . . . . . . . . . 23		10.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 21
	10.1 The 'edit' Link Relation . . . . . . . . . . . . . . . . 23		11. Atom Publishing Control Extensions . . . . . . . . . . . . . 22
	10.2 Publishing Control . . . . . . . . . . . . . . . . . . . 23		11.1 The Atom Publishing Control Namespace . . . . . . . . . 22
	10.2.1 The app:draft Element . . . . . . . . . . . . . . . 24		11.2 The "pub:control" Element . . . . . . . . . . . . . . . 22
	11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 25		11.2.1 The "pub:draft" Element . . . . . . . . . . . . . . 22
	12. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 27		12. Atom Publishing Protocol Example . . . . . . . . . . . . . . 23
	13. Security Considerations . . . . . . . . . . . . . . . . . . 28		13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 25
	14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29		14. Security Considerations . . . . . . . . . . . . . . . . . . 26
	15. References . . . . . . . . . . . . . . . . . . . . . . . . . 31		15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 27
	15.1 Normative References . . . . . . . . . . . . . . . . . . 31		16. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
	15.2 Informative References . . . . . . . . . . . . . . . . . 32		16.1 Normative References . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 33		16.2 Informative References . . . . . . . . . . . . . . . . . 30
	A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 34		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31
	B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 35		A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
	C. Revision History . . . . . . . . . . . . . . . . . . . . . . 38		B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 33
	Intellectual Property and Copyright Statements . . . . . . . 40		C. Revision History . . . . . . . . . . . . . . . . . . . . . . 36
			Intellectual Property and Copyright Statements . . . . . . . 39
	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 7		skipping to change at page 6, line 7
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	Note: The Introspection Document allows the use of IRIs [RFC3987], as		Note: The Introspection Document allows the use of IRIs [RFC3987], as
	well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used		well as URIs [RFC3986]. Every URI is an IRI, so any URI can be used
	where an IRI is needed. How to map an IRI to a URI is specified in		where an IRI is needed. How to map an IRI to a URI is specified in
	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 "Atom Protocol"		For convenience, this protocol may be referred to as the "Atom
	or "APP".		Protocol" or "APP".
			URI/IRI - A Uniform Resource Identifier and Internationalized
			Resource Identifier. These terms and the distinction between them
			are defined in [RFC3986] and [RFC3987].
			Resource - A network-accessible data object or service identified by
			an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for
			further discussion on resources.
	The phrase "the IRI of a document" in this specification is shorthand		The phrase "the IRI of a document" in this specification is shorthand
	for "an IRI which, when dereferenced, is expected to produce that		for "an IRI which, when dereferenced, is expected to produce that
	document as a representation".		document as a representation".
	URI/IRI - A Uniform Resource Identifier and Internationalized		Representation - An entity included with a request or response as
	Resource Identifier, respectively. These terms (and the distinction
	between them) are defined in [RFC3986] and [RFC3987].
	resource - A network data object or service that can be identified
	by a IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215]
	for further discussion on resources.
	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, as		Collection - A resource that contains a set of member IRIs. See
	described in Section 8 of this specification.		Section 8.
	member - A resource whose IRI is listed in a collection.
	IRI template - A parameterized string that becomes a IRI when the
	parameters are filled in. See Section 9.
	introspection document - A document that describes the location and
	capabilities of one or more collections. See Section 7
	client writable element - An element of an Atom Entry whose value is		Member - A resource whose IRI is listed in a Collection.
	editable by the client and not enforced by the server.
	server-controlled element - An element of an Atom Entry whose value		Introspection Document - A document that describes the location and
	is enforced by the server and not editable by the client.		capabilities of one or more Collections. See Section 7.
	4. Protocol Model		4. Protocol Model
	The Atom Publishing Protocol uses HTTP to edit resources on the web.		The Atom Publishing Protocol uses HTTP to edit and author web
	It provides a list based mechanism for managing collections of		resources. The Atom Protocol uses the following HTTP methods:
	editable resources called member resources. Collections contain the
	IRIs and metadata describing member resources. The APP uses these
	HTTP verbs:
	o GET is used to retrieve a representation of a resource or perform		o GET is used to retrieve a representation of a resource or perform
	a query.		a query.
	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.
	This diagram shows the APP model:		Along with operations on resources, the Atom Protocol provides list-
			based structures, called Collections, for managing and organising
	+---------------+		resources, called Members. Collections contain the IRIs of, and
	| Introspection | +------------+		metadata about, their Member resources. For authoring and editing of
	| |-->| Collection |		resources to commence, an Atom Protocol client can examine server-
	+---------------+ | |		defined groups of Collections, called Introspection Documents.
	| | +--------+
	| |-->| Member |
	| | +--------+
	| |
	| | .
	| | .
	| | .
	| |
	| | +--------+
	| |-->| Member |
	| | +--------+
	| |
	+------------+
	The introspection document contains the IRIs of one or more
	collections. A collection contains IRIs and metadata describing
	member resources. The protocol allows editing of resources with
	representations of any media-type. Some types of collections are
	specialized and restrict the resource representations of their
	members.
	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 IRI 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 IRI of the Introspection
	document.		Document.
	2. The server responds with the introspection document which		2. The server responds with the document which enumerates the IRIs
	enumerates the IRIs of all the collections, and the capabilities		of all the Collections and the capabilities of those Collections
	of those collections, that the service supports.		supported by the server. The content of this document can vary
			based on aspects of the client request, including, but not
			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 IRI of Collection |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 2.) 201 Created |		| 2.) 201 Created |
	|<------------------------------------------|		|<------------------------------------------|
	| |		| |
	1. The client POSTs a representation to the IRI of the collection.		1. The client POSTs a representation of the Member to the IRI of the
			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 resource.		contains the IRI 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 IRI is known, that IRI may
	be used to retrieve, update, and delete it.		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 IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 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 IRI 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 IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 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 IRI.
	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 Resource IRI |
	|------------------------------------------>|		|------------------------------------------>|
	| |		| |
	| 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 IRI.
	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.
	Note: deleting a member also removes it from all the collections to		5.4 Listing Collection Members
	which it belongs.
	5.4 Listing Collections
	To enumerate the members of a collection the client sends a GET to		To list the members of a Collection the client sends a GET request to
	its IRI. This IRI is constructed from information in the		the Collection's IRI. An Atom Feed Document is returned containing
	introspection document. An Atom Feed Document is returned with one		one Atom Entry for each member resource. See Section 9 and
	Atom Entry for each member resource that matches the selection		Section 10 for a description of the feed contents.
	criteria in the IRI. See Section 9 and Section 10 for a description
	of the feed contents.
	Client Server		Client Server
	| |		| |
	| 1.) GET to List IRI |		| 1.) GET to List IRI |
	|------------------------------->|		|------------------------------->|
	| |		| |
	| 2.) 200 OK, Atom Feed Doc |		| 2.) 200 OK, Atom Feed Doc |
	|<-------------------------------|		|<-------------------------------|
	| |		| |
	1. The client sends a GET request to the membership list IRI.		1. The client sends a GET request to the Collection's IRI.
	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 all the collection members that match the selection
	criteria.		criteria.
	5.5 Success and Failure		5.5 Use of HTTP Response codes
	The Atom Protocol uses HTTP status codes to signal the results of		The Atom Protocol uses the response status codes defined in HTTP to
	protocol operations. Status codes of the form 2xx signal that a		indicate the success or failure of an operation. Consult the HTTP
	request was successful. HTTP status codes of the form 4xx or 5xx		specification [RFC2616] for detailed definitions of each status code.
	signal that an error has occurred. Consult the HTTP specification		It is strongly recommended that entities contained within HTTP 4xx
	[RFC2616] for the definitions of HTTP status codes.		and 5xx responses include a human readable, 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 data format in this specification is specified in terms of the
	XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204].		XML Information Set, serialised as XML 1.0 [W3C.REC-xml-20040204].
	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, and hence		specification does not define any DTDs for Atom Protocol, and hence
	does not require them to be valid (in the sense used by XML).		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 naming Element Information Items		"Information Item" is omitted when discussing Element Information
	and Attribute Information Items. Therefore, when this specification		Items and Attribute Information Items. Therefore, when this
	uses the term "element," it is referring to an Element Information		specification uses the term "element," it is referring to an Element
	Item in Infoset terms. Likewise, when it uses the term "attribute,"		Information Item in Infoset terms. Likewise, when it uses the term
	it is referring to an Attribute Information Item.		"attribute," it is referring to an Attribute Information Item.
	6.2 XML Namespace Usage		6.2 XML Namespace Usage
	The Namespace URI [W3C.REC-xml-names-19990114] for the data format		The namespace name [W3C.REC-xml-names-19990114] for the XML format
	described in this specification is:		described in this specification is:
	http://purl.org/atom/app#		http://purl.org/atom/app#
	This specification uses the prefix "app:" for the Namespace URI. The		This specification uses the prefix "app:" for the namespace name.
	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 the Namespace URI
	identified in [AtomFormat].
	6.3 RELAX NG Schema
	Some sections of this specification are illustrated with fragments of		This specification also uses the prefix "atom:" for
	a non-normative RELAX NG Compact schema [RNC]. However, the text of		"http://www.w3.org/2005/Atom", the namespace name of the Atom
	this specification provides the definition of conformance. A		Publishing Format [RFC4287].
	complete schema appears in Appendix B.
	6.4 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 [RFC3986],
	establishing the base URI (or IRI) for resolving any relative		establishing the base URI (or IRI) for resolving any relative
	references found within the effective scope of the xml:base		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].
	appCommonAttributes =		appCommonAttributes =
	attribute xml:base { atomUri }?,		attribute xml:base { atomUri }?,
	attribute xml:lang { atomLanguageTag }?,		attribute xml:lang { atomLanguageTag }?,
	undefinedAttribute*		undefinedAttribute*
	7. Introspection Documents		6.4 RELAX NG Schema
	7.1 Introduction		Some sections of this specification are illustrated with fragments of
			a non-normative RELAX NG Compact schema [RNC]. A complete schema
			appears in Appendix B. However, the text of this specification
			provides the definition of conformance.
			7. Introspection Documents
	For authoring to commence, a client needs to first discover the		For authoring to commence, a client needs to first discover the
	capabilities and locations of collections offered. This is done		capabilities and locations of collections offered. This is done
	using Introspection Documents. An Introspection Document describes		using Introspection Documents. An Introspection Document describes
	workspaces, which are server-defined groupings of collections.		workspaces, which are server-defined groupings of collections.
	7.2 Example		Introspection documents are identified with the "application/
			atomserv+xml" media type (see Section 15).
			While an introspection document allows multiple workspaces, there is
			no requirement that a service support multiple workspaces. In
			addition, a collection MAY appear in more than one workspace.
			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>		<list-template>http://example.org/{index}</list-template>
	</collection>		</collection>
	skipping to change at page 13, line 42		skipping to change at page 13, line 47
	<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>		<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 IRIs 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.3.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 IRI is
	'http://example.org/reilly/list'. 'Remaindered Links' is an Entry		"http://example.org/reilly/list". "Remaindered Links" is an Entry
	collection.		collection.
	Introspection documents are identified with the "application/		7.2 Element Definitions
	atomserv+xml" media type (see Section 14).
	While an introspection document allows multiple workspaces, there is
	no requirement that a service support multiple workspaces. In
	addition, a collection MAY appear in more than one workspace.
	7.3 Element Definitions
	7.3.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#"		namespace app = "http://purl.org/atom/app#"
	start = appService		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.
	appService =		appService =
	element app:service {		element app:service {
	appCommonAttributes,		appCommonAttributes,
	( appWorkspace+		( appWorkspace+
	& extensionElement* )		& extensionElement* )
	}		}
	7.3.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
	collections of resources available for editing. The app:workspace		collections of resources available for editing. The app:workspace
	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* )
	}		}
	7.3.2.1 The 'title' Attribute		In an app:workspace element, the first app:collection element SHOULD
			refer to the preferred or primary collection. In the following
			example, the "Entries" collection would be considered the "preferred"
			or "primary" collection of the workspace:
	The app:workspace element MUST contain a 'title' attribute, which		<service>
	conveys a human-readable name for the workspace. This attribute is		<workspace title="My Blog">
			<collection title="Entries" ... >
			<collection title="Photos" ... >
			</workspace>
			</service>
			7.2.2.1 The "title" Attribute
			The app:workspace element MUST contain a "title" attribute, which
			gives a human-readable name for the workspace. This attribute is
	Language-Sensitive.		Language-Sensitive.
	7.3.3 The 'app:collection' Element		7.2.3 The "app:collection" Element
	The app:collection contains information elements that describe the		The "app:collection" describes a collection. This specification
	location and capabilities of a collection.		defines one child element: 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* )
	}		}
	7.3.3.1 The 'title' Attribute		7.2.3.1 The "title" Attribute
	The app:collection element MUST contain a 'title' attribute, whose
	value conveys a human-readable name for the collection. This
	attribute is Language-Sensitive.
	7.3.3.2 The 'href' Attribute
	The app:collection element MUST contain an 'href' attribute, whose
	value conveys the IRI of the collection.
	This specification defines two child elements for app:collection:		The app:collection element MUST contain a "title" attribute, whose
			value gives a human-readable name for the collection. This attribute
			is Language-Sensitive.
	o app:member-type: a single element that contains the type of		7.2.3.2 The "href" Attribute
	members that the collection can contain.
	o app:list-template: a single element that contains a IRI template		The app:collection element MUST contain a "href" attribute, whose
	of a membership list. (See Section 9).		value gives the IRI of the collection.
	7.3.4 The 'app:member-type' Element		7.2.4 The "app:member-type" Element
	The app:collection element MUST contain one 'app:member-type'		The app:collection element MUST contain one "app:member-type"
	element. The app:member-type element value specifies the types of		element. The app:member-type element value specifies the types of
	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:		An Entry POSTed to a collection MUST meet the constraints of the app:
	member-type element.		member-type element.
	This specification defines two initial values for the app:member-type		This specification defines two values for the app:member-type
	IANA registry:		element:
	o "entry" - The collection contains only member resources whose		o "entry" - The collection contains only member resources whose
	representation MUST be an Atom Entry. Further constraints on the		representation MUST be an Atom Entry. Further constraints on the
	representations of members in a collection of type "entry" are		representations of members in a collection of type "entry" are
	listed in Section 8.2.		listed in Section 8.2.
	o "media" - The collection contains member resources whose		o "media" - 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.
	In general the value of app:member-type MUST be a string that is non-
	empty, and matches either the "isegment-nz-nc" or the "IRI"
	production in [RFC3987]. Note that use of a relative reference other
	than a simple name is not allowed. If a name is given,
	implementations MUST consider the link relation type to be equivalent
	to the same name registered within the IANA Registry of Link
	Relations Section 14, and thus the IRI that would be obtained by
	appending the value of the rel attribute to the string
	"http://www.iana.org/assignments/member-type/".
	7.3.5 The 'app:list-template' Element
	The app:collection element MUST contain one 'app:list-template'
	elements. The element content of app:list-template is an IRI
	template (Section 9) for a collection.
	appListTemplate =
	element app:list-template {
	appCommonAttributes,
	( appUriTemplate )
	}
	appUriTemplate = xsd:string { pattern = ".+\{.+\}.*" }
	8. Collections		8. Collections
	8.1 Creating resources with POST		8.1 Creating resources with POST
	Every collection accepts POST requests to create resources - the		To add members to a collection, clients send POST requests to the
	client POSTs a representation of the desired resource to the IRI of		collection's URI. Collections MAY impose constraints on the media-
	the collection. 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").		with a status code of 415 ("Unsupported Media Type"). On successful
			creation, the response to the POST request MUST return a Location:
	The status code returned for a successful creation POST MUST be 201		header with the URI of the newly created resource.
	("Created").
	A successful creation POST MUST return a Location: header with the
	URI of the newly created resource.
	Clients MAY POST invalid Atom for initial resource creation -		8.1.1 Example
	specifically the id and link elements MAY be omitted.
	Below, the client requests to create a resource in a collection:		Below, the client requests to create a resource with an Atom Entry
			representation in a collection:
	POST /edit HTTP/1.1		POST /edit 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>
	<updated>2003-12-13T18:30:02Z</updated>		<updated>2003-12-13T18:30:02Z</updated>
	<summary>Some text.</summary>		<summary>Some text.</summary>
	</entry>		</entry>
	The resource is created by sending an Atom Entry as the entity body.		The resource is created by sending an Atom Entry as the entity body.
	Successful creation is indicated by a 201 created response and		Successful creation is indicated by a 201 created response and
	includes a Location: header.		includes a Location: header:
	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.1 Title: Header		8.1.2 Title: Header
	The POST to a collection MAY contain a Title: header that indicates		A POST to a collection creating a resource MAY contain a Title:
	the client's suggested title for the resource. The server MAY ignore		header that indicates the client's suggested title for the resource.
	the Title: header or modify the requested title.		The Title header is primarily for use with Media collections and is
			RECOMMENDED for use with such collections. The server MAY ignore the
			content of the Title: header or modify the suggested title.
	Title = "Title" ":" [text]		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].
	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 MUST contain an atom:link
	element with a relation of rel="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 an app:control
	element (Section 10.2).		element (Section 11).
	8.2.1 Role of Atom Entry Elements During Editing
	The elements of an Atom Entry Document are either a client writable
	or server controlled.
	Client Writable - An element of an Atom Entry whose value is editable
	by the client. Servers MAY modify the content of client writable
	elements. Some reasons that a server may change client writable
	content include length limits, obscenity filters or the addition of
	boilerplate text.
	Server Controlled - An element of an Atom Entry whose value is
	enforced by the server and not editable by the client. Clients
	SHOULD NOT change the value of server controlled elements. Servers
	MUST NOT rely on clients preserving the values of server controlled
	elements.
	+--------------------+--------------------+
	| Atom Entry Element | Property |
	+--------------------+--------------------+
	| atom:author | Client Writable |
	| | |
	| atom:category | Client Writable |
	| | |
	| atom:content | Client Writable |
	| | |
	| atom:contributor | Client Writable |
	| | |
	| atom:id | Server Controlled |
	| | |
	| atom:link | Client Writable |
	| | |
	| atom:published | Client Writable |
	| | |
	| atom:source | Client Writable |
	| | |
	| atom:summary | Client Writable |
	| | |
	| atom:title | Client Writable |
	| | |
	| atom:updated | Server Controlled |
	| | |
	| app:control | Client Writable |
	+--------------------+--------------------+
	Table 1
	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 a membership list resource returns an Atom Feed enumerating the
	contents of a Media Collection, all the Entries MUST have an atom:		contents of a Media Collection, all the Entries MUST have an atom:
	content element with a 'src' attribute. When creating a public,		content element with a "src" attribute. When creating a public,
	read-only reference to the member resource, a client SHOULD use the		read-only reference to the member resource, a client SHOULD use the
	"atom:content/@src" attribute value.		"atom:content/@src" attribute value.
	9. Listing Collections		9. Listing Collections
	Collections, as identified in an Introspection Document, are		Collections, as identified in an Introspection Document, are
	resources that MUST provide representations in the form of Atom Feed		resources that MUST provide representations in the form of Atom Feed
	documents. The entries in the returned Feed MUST be ordered by their		documents when dereferencing the collection IRI. The entries in the
	'atom:updated' property, with the most recently updated entries		returned Feed MUST be ordered by their 'atom:updated' property, with
	coming first in the document order. Every entry in the Feed Document		the most recently updated entries coming first in the document order.
	MUST have an atom:link element with a relation of "edit" (See		Every entry in the Feed Document MUST have an atom:link element with
	Section 10.1). Clients MUST NOT assume that an Atom Entry returned		a relation of "edit" (See Section 10.1). Clients MUST NOT assume
	in the Feed is a full representation of a member resource. The value		that an Atom Entry returned in the Feed is a full representation of a
	of atom:updated is only changed when the change to a member resource		member resource. The value of atom:updated is only changed when the
	is considered significant. Insignificant changes do not result in		change to a member resource is considered significant. Insignificant
	changes to the atom:updated value and thus do not change the position		changes do not result in changes to the atom:updated value and thus
	of the corresponding entry in a membership list. Clients SHOULD be		do not change the position of the corresponding entry in a membership
	constructed with this in mind and SHOULD perform a GET on the member		list. Clients SHOULD be constructed with this in mind and SHOULD
	resource before editing.		perform a GET on the member resource before editing.
	Collections can contain extremely large numbers of resources. A		Collections can contain large numbers of resources. A naive client
	naive client such as a web spider or web browser would be overwhelmed		such as a web spider or web browser could be overwhelmed if the
	if the response to a GET contained every entry in the feed, 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.		clients unable to handle the response. For this reason, servers MAY
			return a partial listing containing the most recently updated member
			resources. Such partial feed documents MUST have an atom:link with a
			"next" relation whose "href" value is the IRI of the next partial
			listing of the collection (the least recently updated member
			resources) where it exists. This is called "collection paging".
	For this reason, Introspection documents refer to collections not		9.1 Collection Paging
	with IRIs but with IRI Templates, contained in the "app:member-type"
	child of "app:collection". An IRI Template is a string containing
	the embedded token "{index}".
	To produce an IRI that can be used to retrieve part or all of the		Atom Protocol servers MUST provide representations of collections as
	collection, software replaces the "{index}" with a pair of positive		Atom feed documents whose entries represent the collection's members.
	integer indices separated by a dash character. An IRI template MUST,		The returned Atom feed MAY NOT contain entries for all the
	after such substitution has been performed, constitute a		collection's members. Instead, the Atom feed document MAY contain
	syntactically valid IRI.		link elements with "rel" attribute values of "next", "previous",
			"start" and "end" that can be used to navigate through the complete
			set of matching entries.
	One or other index MAY be omitted, in which case the range is		For instance, suppose the client is supplied this IRI
	understood as stretching to 0 or infinity. The index values are 0		http://example.org/entries/go
	based and select members from the collection based on the member's
	index, with all of the members ordered by their 'atom:updated'
	property. The response to the selection request MUST be an Atom Feed
	where all the entries fall within the requested criteria. The
	request range is considered a closed set - if an entry matches one
	end of the range exactly it MUST be included in the response. If no
	members fall in the requested range, the server MUST respond with an
	Atom Feed containing no entries. If a membership list is returned
	with a number of entries that is less than the number of entries
	requested than the client MAY assume that it has made a request that
	exceeds the last index of the members.
	For example, suppose the client is supplied this IRI template:		Supposing the collection contains member entries and the server as a
			matter of policy wishes to avoid generating feed documents with more
			than 10 entries, then the resulting Atom feed document represents the
			first page in a linked set of 10 feed documents. Within each feed
			document served, "next" and "prev" link elements reference the
			preceding and subsequent feed documents in the set. The "start" link
			element references the first feed document in the set. The "end"
			link element references the final feed document in the set.
	http://example.org/blog/edit/{index}		<feed xmlns="http://www.w3.org/2005/Atom">
	If the client wants the first 15 entries in the collection it would		...
	substitute the brace-delimited parameter {index}, with the value		<link rel="start"
	0-14, giving:		href="http://example.org/entries/go" />
			<link rel="next"
			href="http://example.org/entries/2" />
			<link rel="last"
			href="http://example.org/entries/10" />
			</feed>
	http://example.org/blog/edit/0-14		The 'next' and 'prev' link elements for the feed located at
			http://example.org/entries/2 would look like this:
	10. Atom Entry Extensions		<feed xmlns="http://www.w3.org/2005/Atom">
			...
			<link rel="start"
			href="http://example.org/entries/go" />
			<link rel="previous"
			href="http://example.org/entries/go" />
			<link rel="next"
			href="http://example.org/entries/3" />
			<link rel="last"
			href="http://example.org/entries/10" />
			</feed>
	This specification adds one new value to the Registry of Link		10. Atom Format Link Relation Extensions
	Relations and also adds a new element to Atom Entries called "app:
	control" for controlling publishing. These new links and app:		10.1 The "edit" Link Relation
	control elements MAY appear in both membership lists and in member
			The Atom Protocol adds the value "edit" to the Atom Registry of Link
			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
			of the member resource, and is intended to be used to update and
			delete resources as described in this specification. This link
			relation MAY appear in both membership lists and in member
	representations.		representations.
	10.1 The 'edit' Link Relation		11. Atom Publishing Control Extensions
	This specification adds the value "edit" to the Registry of Link		11.1 The Atom Publishing Control Namespace
	Relations. The value of "edit" signifies 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 delete resources as described in
	this specification.
	10.2 Publishing Control		This specification defines an Atom Format extension for publishing
			control called Atom Publishing Control. The namespace name for the
			Atom Publishing Control's XML vocabulary is
			"http://example.net/appns/". This specification uses "pub:" for the
			namespace prefix. The choice of namespace prefix is not semantically
			significant.
	This specification also adds a new element to Atom Entries for		11.2 The "pub:control" Element
	controlling publishing.
			namespace pub = "http://example.net/appns/"
	pubControl =		pubControl =
	element app:control {		element pub:control {
	atomCommonAttributes,		atomCommonAttributes,
	pubDraft?		pubDraft?
	& extensionElement		& extensionElement
	}		}
	pubDraft =		pubDraft =
	element app:draft { "yes" | "no" }		element pub:draft { "yes" | "no" }
	The "app:control" element MAY appear as a child of an "atom:entry"		The "pub:control" element MAY appear as a child of an "atom:entry"
	which is being created or updated via the Atom Publishing Protocol.		which is being created or updated via the Atom Publishing Protocol.
	The "app:control" element, if it does appear in an entry, MUST only		The "pub:control" element, if it does appear in an entry, MUST only
	appear at most one time.		appear at most one time. The "pub:control" element is considered
			foreign markup as defined in Section 6 of [RFC4287].
	The "app:control" element and its children elements MAY be included
	in Atom Feed or Entry Documents. The "app:control" element is
	considered "foreign markup" as defined in Section 6 of the Atom
	Syndication Format.
	The "app:control" element MAY contain exactly one app:draft element		The "pub:control" element and its child elements MAY be included in
	and MAY contain zero or more extension elements as outlined in the		Atom Feed or Entry Documents.
	Atom Syndication Format, Section 6. Both clients and servers MUST
	ignore foreign markup present in the app:control element that they do
	not know.
	10.2.1 The app: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
			outlined in Section 6 of [RFC4287]. Both clients and servers MUST
			ignore foreign markup present in the pub:control element.
	This specification defines only one child element for "app:control",		11.2.1 The "pub:draft" Element
	"app:draft".
	The number of "app:draft" elements in "app:control" MUST be zero or		The number of "pub:draft" elements in "pub:control" MUST be zero or
	one. Its content MUST be one of the values "yes" or "no". A value		one. Its value MUST be one of "yes" or "no". A value of "no" means
	of "no" means that the entry MAY be made publicly visible. If the		that the entry may be made publicly visible. If the "pub:draft"
	"app:draft" element is missing then the value is understood to be		element is missing then the value is understood to be "no". If "pub:
	"no". That is, if "app:control" and/or the "app:draft" elements are		control" and/or the "pub:draft" elements are missing from an entry
	missing from an entry then the entry is considered not a draft and		then the entry is not considered a draft and can be made publicly
	can be made publicly visible. Clients MUST understand "app:draft"		visible.
	elements and MUST NOT drop them from Atom Entries during editing.
	Clients MUST NOT operate on the expectation that a server will honor
	the value of an "app:draft" element. Servers MAY ignore "app:draft"
	elements and drop them from Atom Entries.
	11. 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:
	http://example.net/blog/edit/		http://example.net/blog/edit/
	The IRI of the media collection is:		The IRI of the media collection is:
	http://example.net/binary/edit		http://example.net/binary/edit
	skipping to change at page 26, line 18		skipping to change at page 24, line 18
	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"?>
	<entry xmlns="http://www.w3.org/2005/Atom">		<entry xmlns="http://www.w3.org/2005/Atom">
	<title>What I did on my summer vacation</title>		<title>What I did on my summer vacation</title>
			<link href="http://example.org/atom05"/>
			<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>
	12. Securing the Atom Protocol		13. Securing the Atom Protocol
	All instances of publishing Atom entries SHOULD be protected by		All instances of publishing Atom Format entries SHOULD be protected
	authentication to prevent posting or editing by unknown sources.		by authentication to prevent posting or editing by unknown sources.
	Atom 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 [@@TBD@@ CGI Authentication ref]		o CGI Authentication
	Atom servers and clients MAY support encryption of the session using		Atom Protocol servers and clients MAY support encryption of the
	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 is not be required,
	such as a publicly editable Wiki, or when using POST to send comments		such as a publicly editable Wiki, or when using POST to send comments
	to a site that does not require authentication from a commenter.		to a site that does not require authentication from a commenter.
	12.1 [@@TBD@@ CGI Authentication]		13.1 CGI Authentication
	This authentication method is included as part of the protocol to		[[anchor26: This section is incomplete; cgi-authentication is
	allow Atom servers and clients that cannot use HTTP Digest		described but is unspecified.]] This authentication method is
	Authentication but where the user can both insert its own HTTP		included as part of the protocol to allow Atom Protocol servers and
	headers and create a CGI program to authenticate entries to the		clients that cannot use HTTP Digest Authentication but where the user
	server. This scenario is common in environments where the user		can both insert its own HTTP headers and create a CGI program to
	cannot control what services the server employs, but the user can		authenticate entries to the server. This scenario is common in
	write their own HTTP services.		environments where the user cannot control what services the server
			employs, but the user can write their own HTTP services.
	13. Security Considerations		14. Security Considerations
	The security of Atom is based on HTTP Digest Authentication and/or		The security of the Atom Protocol is based on HTTP Digest
	[@@TBD@@ CGI Authentication]. Any weaknesses in either of these		Authentication and/or CGI Authentication [[anchor28: refers to
			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 [@@TBD@@ CGI Authentication] are		Both HTTP Digest Authentication and CGI Authentication [[anchor29:
	susceptible to dictionary-based attacks on the shared secret. If the		refers to incomplete section]] are susceptible to dictionary-based
	shared secret is a password (instead of a random string with		attacks on the shared secret. If the shared secret is a password
	sufficient entropy), an attacker can determine the secret by		(instead of a random string with sufficient entropy), an attacker can
	exhaustively comparing the authenticating string with hashed results		determine the secret by exhaustively comparing the authenticating
	of the public string and dictionary entries.		string with hashed results of the public string and 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.
	@@TBD@@ Talk here about using HTTP basic and digest authentication.		[[anchor30: expand on HTTP basic and digest authentication, or
			refer.]]
	@@TBD@@ Talk here about denial of service attacks using large XML		[[anchor31: talk here about denial of service attacks using large XML
	files, or the billion laughs DTD attack.		files, or the billion laughs DTD attack.]]
	14. IANA Considerations		15. IANA Considerations
	An Atom Introspection Document, when serialized as XML 1.0, can be		An Atom Publishing Protocol Introspection Document, when serialized
	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
	Mandatory parameters: None.		Mandatory parameters: None.
	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.
	[[anchor22: update upon publication]]		[[anchor32: 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. [[anchor23: update upon		Published specification: This specification. [[anchor33: 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 30, line 14		skipping to change at page 28, 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). [[anchor24:		Author/Change controller: This specification's author(s). [[anchor34:
	update upon publication]]		update upon publication]]
	15. References		16. References
	15.1 Normative References
	[AtomFormat]		16.1 Normative References
	Nottingham, M. and R. Sayre, "The Atom Syndication
	Format", 1.0, July 2005.
	[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 31, line 38		skipping to change at page 29, line 34
	[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media		[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
	Types", RFC 3023, January 2001.		Types", RFC 3023, January 2001.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource		[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
	Identifiers (IRIs)", RFC 3987, January 2005.		Identifiers (IRIs)", RFC 3987, January 2005.
			[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
			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-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.
	15.2 Informative References		16.2 Informative References
	[RNC] Clark, J., "RELAX NG Compact Syntax", December 2001.		[RNC] Clark, J., "RELAX NG Compact Syntax", December 2001.
	[W3C.REC-webarch-20041215]		[W3C.REC-webarch-20041215]
	Walsh, N. and I. Jacobs, "Architecture of the World Wide		Walsh, N. and I. Jacobs, "Architecture of the World Wide
	Web, Volume One", W3C REC REC-webarch-20041215,		Web, Volume One", W3C REC REC-webarch-20041215,
	December 2004.		December 2004.
	URIs		URIs
	skipping to change at page 35, line 9		skipping to change at page 33, line 9
	Appendix A. Contributors		Appendix A. Contributors
	The content and concepts within are a product of the Atom community		The content and concepts within are a product of the Atom community
	and the Atompub Working Group.		and the Atompub Working Group.
	Appendix B. RELAX NG Compact Schema		Appendix B. RELAX NG Compact Schema
	This appendix is informative.		This appendix is informative.
	The Relax NG schema explicitly excludes elements in the APP namespace		The Relax NG schema explicitly excludes elements in the Atom Protocol
	which are not defined in this revision of the specification.		namespace which are not defined in this revision of the
	Requirements for APP Processors encountering such markup are given in		specification. Requirements for Atom Protocol processors
	Section 6.2 and Section 6.3 of [AtomFormat].		encountering such markup are given in Section 6.2 and Section 6.3 of
			[RFC4287].
	# -*- rnc -*-		# -*- rnc -*-
	# RELAX NG Compact Syntax Grammar for the Atom Protocol		# RELAX NG Compact Syntax Grammar for the Atom Protocol
	namespace app = "http://purl.org/atom/app#"		namespace app = "http://purl.org/atom/app#"
	namespace local = ""		namespace local = ""
	start = appService		start = appService
	# common:attrs		# common:attrs
	skipping to change at page 38, line 7		skipping to change at page 36, 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-07: updated Atom refs to RFC4287;
			incorporated PaceBetterHttpResponseCode;
			PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore;
			PaceRemoveAcceptPostText; PaceRemoveListTemplate2;
			PaceRemoveRegistry; PaceRemoveWhoWritesWhat;
			PaceSimplifyClarifyBetterfyRemoveBogusValidityText;
			PaceCollectionOrderSignificance; PaceFixLostIntrospectionText;
			PaceListPaging; PaceCollectionControl; element typo in Listing
			collections para3 (was app:member-type, not app:list-template);
			changed post atom entry example to be valid. Dropped inline use of
			'APP'. Removed nested diagram from section 4. Added ed notes in the
			security section.
	draft-ietf-atompub-protocol-06 - Removed: Robert Sayre from the		draft-ietf-atompub-protocol-06 - Removed: Robert Sayre from the
	contributors section per his request. Added in		contributors section per his request. Added in
	PaceCollectionControl. Fixed all the {daterange} verbage and		PaceCollectionControl. Fixed all the {daterange} verbage and
	examples so they all use a dash. Added full rnc schema. Collapsed		examples so they all use a dash. Added full rnc schema. Collapsed
	Introspection and Collection documents into a single document.		Introspection and Collection documents into a single document.
	Removed {dateRange} queries. Renamed search to list. Moved		Removed {dateRange} queries. Renamed search to list. Moved
	discussion of media and entry collection until later in the document		discussion of media and entry collection until later in the document
	and tied the discussion to the Introspection element app:member-type.		and tied the discussion to the Introspection element app:member-type.
	draft-ietf-atompub-protocol-05 - Added: Contributors section. Added:		draft-ietf-atompub-protocol-05 - Added: Contributors section. Added:
	skipping to change at page 40, line 46		skipping to change at page 39, line 46
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Copyright Statement		Copyright Statement
	Copyright (C) The Internet Society (2005). This document is subject		Copyright (C) The Internet Society (2006). This document is subject
	to the rights, licenses and restrictions contained in BCP 78, and		to the rights, licenses and restrictions contained in BCP 78, and
	except as set forth therein, the authors retain all their rights.		except as set forth therein, the authors retain all their rights.
	Acknowledgment		Acknowledgment
	Funding for the RFC Editor function is currently provided by the		Funding for the RFC Editor function is currently provided by the
	Internet Society.		Internet Society.
End of changes.
This html diff was produced by rfcdiff 1.12, available from http://www.levkowetz.com/ietf/tools/rfcdiff/