draft-ietf-atompub-protocol-15.txt		draft-ietf-atompub-protocol-16.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft IBM		Internet-Draft IBM
	Intended status: Standards Track B. de hOra, Ed.		Intended status: Standards Track B. de hOra, Ed.
	Expires: November 23, 2007 Propylon Ltd.		Expires: December 29, 2007 June 27, 2007
	May 22, 2007
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-15.txt		draft-ietf-atompub-protocol-16.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 34
	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 November 23, 2007.		This Internet-Draft will expire on December 29, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	The Atom Publishing Protocol (APP) is an application-level protocol		The Atom Publishing Protocol (APP) is an application-level protocol
	for publishing and editing Web resources. The protocol is based on		for publishing and editing Web resources. The protocol is based on
	HTTP transfer of Atom-formatted representations. The Atom format is		HTTP transfer of Atom-formatted representations. The Atom format is
	skipping to change at page 3, line 38		skipping to change at page 3, line 38
	5.2. Listing Collection Members . . . . . . . . . . . . . . . . 14		5.2. Listing Collection Members . . . . . . . . . . . . . . . . 14
	5.3. Creating a Resource . . . . . . . . . . . . . . . . . . . 15		5.3. Creating a Resource . . . . . . . . . . . . . . . . . . . 15
	5.4. Editing a Resource . . . . . . . . . . . . . . . . . . . . 15		5.4. Editing a Resource . . . . . . . . . . . . . . . . . . . . 15
	5.4.1. Retrieving a Resource . . . . . . . . . . . . . . . . 15		5.4.1. Retrieving a Resource . . . . . . . . . . . . . . . . 15
	5.4.2. Editing a Resource . . . . . . . . . . . . . . . . . . 16		5.4.2. Editing a Resource . . . . . . . . . . . . . . . . . . 16
	5.4.3. Deleting a Resource . . . . . . . . . . . . . . . . . 16		5.4.3. Deleting a Resource . . . . . . . . . . . . . . . . . 16
	5.5. Use of HTTP Response codes . . . . . . . . . . . . . . . . 16		5.5. Use of HTTP Response codes . . . . . . . . . . . . . . . . 16
	6. Protocol Documents . . . . . . . . . . . . . . . . . . . . . . 18		6. Protocol Documents . . . . . . . . . . . . . . . . . . . . . . 18
	6.1. Document Types . . . . . . . . . . . . . . . . . . . . . . 18		6.1. Document Types . . . . . . . . . . . . . . . . . . . . . . 18
	6.2. Document Extensibility . . . . . . . . . . . . . . . . . . 18		6.2. Document Extensibility . . . . . . . . . . . . . . . . . . 18
	7. Category Documents . . . . . . . . . . . . . . . . . . . . . . 20		7. Category Documents . . . . . . . . . . . . . . . . . . . . . . 19
	7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 20		7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19
	7.2. Element Definitions . . . . . . . . . . . . . . . . . . . 20		7.2. Element Definitions . . . . . . . . . . . . . . . . . . . 19
	7.2.1. The "app:categories" element . . . . . . . . . . . . . 20		7.2.1. The "app:categories" element . . . . . . . . . . . . . 19
	8. Service Documents . . . . . . . . . . . . . . . . . . . . . . 22		8. Service Documents . . . . . . . . . . . . . . . . . . . . . . 21
	8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . . . . 22		8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . . . . 21
	8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 23		8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 22
	8.3. Element Definitions . . . . . . . . . . . . . . . . . . . 24		8.3. Element Definitions . . . . . . . . . . . . . . . . . . . 23
	8.3.1. The "app:service" Element . . . . . . . . . . . . . . 24		8.3.1. The "app:service" Element . . . . . . . . . . . . . . 23
	8.3.2. The "app:workspace" Element . . . . . . . . . . . . . 24		8.3.2. The "app:workspace" Element . . . . . . . . . . . . . 23
	8.3.3. The "app:collection" Element . . . . . . . . . . . . . 25		8.3.3. The "app:collection" Element . . . . . . . . . . . . . 24
	8.3.4. The "app:accept" Element . . . . . . . . . . . . . . . 26		8.3.4. The "app:accept" Element . . . . . . . . . . . . . . . 25
	8.3.5. Usage in Atom Feed Documents . . . . . . . . . . . . . 26		8.3.5. Usage in Atom Feed Documents . . . . . . . . . . . . . 25
	8.3.6. The "app:categories" Element . . . . . . . . . . . . . 26		8.3.6. The "app:categories" Element . . . . . . . . . . . . . 25
	9. Creating and Editing Resources . . . . . . . . . . . . . . . . 28		9. Creating and Editing Resources . . . . . . . . . . . . . . . . 27
	9.1. Member URIs . . . . . . . . . . . . . . . . . . . . . . . 28		9.1. Member URIs . . . . . . . . . . . . . . . . . . . . . . . 27
	9.2. Creating Resources with POST . . . . . . . . . . . . . . . 28		9.2. Creating Resources with POST . . . . . . . . . . . . . . . 27
	9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 29		9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 28
	9.3. Editing Resources with PUT . . . . . . . . . . . . . . . . 30		9.3. Editing Resources with PUT . . . . . . . . . . . . . . . . 29
	9.4. Deleting Resources with DELETE . . . . . . . . . . . . . . 30		9.4. Deleting Resources with DELETE . . . . . . . . . . . . . . 29
	9.5. Caching and entity tags . . . . . . . . . . . . . . . . . 30		9.5. Caching and entity tags . . . . . . . . . . . . . . . . . 29
	9.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 30		9.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 29
	9.6. Media Resources and Media Link Entries . . . . . . . . . . 32		9.6. Media Resources and Media Link Entries . . . . . . . . . . 31
	9.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 33		9.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 32
	9.7. The Slug: Header . . . . . . . . . . . . . . . . . . . . . 39		9.7. The Slug: Header . . . . . . . . . . . . . . . . . . . . . 38
	9.7.1. Slug: Header syntax . . . . . . . . . . . . . . . . . 40		9.7.1. Slug: Header syntax . . . . . . . . . . . . . . . . . 39
	9.7.2. Example . . . . . . . . . . . . . . . . . . . . . . . 40		9.7.2. Example . . . . . . . . . . . . . . . . . . . . . . . 39
	10. Listing Collections . . . . . . . . . . . . . . . . . . . . . 41		10. Listing Collections . . . . . . . . . . . . . . . . . . . . . 40
	10.1. Collection partial lists . . . . . . . . . . . . . . . . . 41		10.1. Collection partial lists . . . . . . . . . . . . . . . . . 40
	10.2. The "app:edited" Element . . . . . . . . . . . . . . . . . 42		10.2. The "app:edited" Element . . . . . . . . . . . . . . . . . 41
	11. Atom Format Link Relation Extensions . . . . . . . . . . . . . 43		11. Atom Format Link Relation Extensions . . . . . . . . . . . . . 42
	11.1. The "edit" Link Relation . . . . . . . . . . . . . . . . . 43		11.1. The "edit" Link Relation . . . . . . . . . . . . . . . . . 42
	11.2. The "edit-media" Link Relation . . . . . . . . . . . . . . 43		11.2. The "edit-media" Link Relation . . . . . . . . . . . . . . 42
	12. The Atom Format Type Parameter . . . . . . . . . . . . . . . . 44		12. The Atom Format Type Parameter . . . . . . . . . . . . . . . . 43
	12.1. The 'type' parameter . . . . . . . . . . . . . . . . . . . 44		12.1. The 'type' parameter . . . . . . . . . . . . . . . . . . . 43
	12.1.1. Conformance . . . . . . . . . . . . . . . . . . . . . 44		12.1.1. Conformance . . . . . . . . . . . . . . . . . . . . . 43
	13. Atom Publishing Controls . . . . . . . . . . . . . . . . . . . 45		13. Atom Publishing Controls . . . . . . . . . . . . . . . . . . . 44
	13.1. The "app:control" Element . . . . . . . . . . . . . . . . 45		13.1. The "app:control" Element . . . . . . . . . . . . . . . . 44
	13.1.1. The "app:draft" Element . . . . . . . . . . . . . . . 45		13.1.1. The "app:draft" Element . . . . . . . . . . . . . . . 44
	14. Securing the Atom Publishing Protocol . . . . . . . . . . . . 46		14. Securing the Atom Publishing Protocol . . . . . . . . . . . . 45
	15. Security Considerations . . . . . . . . . . . . . . . . . . . 47		15. Security Considerations . . . . . . . . . . . . . . . . . . . 46
	15.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 47		15.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 46
	15.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 47		15.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 46
	15.3. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . 47		15.3. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . 46
	15.4. Linked Resources . . . . . . . . . . . . . . . . . . . . . 47		15.4. Linked Resources . . . . . . . . . . . . . . . . . . . . . 46
	15.5. Digital Signatures and Encryption . . . . . . . . . . . . 47		15.5. Digital Signatures and Encryption . . . . . . . . . . . . 46
	15.6. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 47		15.6. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 47
	15.7. Code Injection and Cross Site Scripting . . . . . . . . . 48		15.7. Code Injection and Cross Site Scripting . . . . . . . . . 47
	16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49		16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
	16.1. Content-type registration for 'application/atomcat+xml' . 49		16.1. Content-type registration for 'application/atomcat+xml' . 48
	16.2. Content-type registration for 'application/atomsvc+xml' . 50		16.2. Content-type registration for 'application/atomsvc+xml' . 49
	16.3. Header field registration for 'SLUG' . . . . . . . . . . . 51		16.3. Header field registration for 'SLUG' . . . . . . . . . . . 50
	16.4. The Link Relation registration "edit" . . . . . . . . . . 52		16.4. The Link Relation registration "edit" . . . . . . . . . . 51
	16.5. The Link Relation registration "edit-media" . . . . . . . 52		16.5. The Link Relation registration "edit-media" . . . . . . . 51
	16.6. The Atom Format Media Type Parameter . . . . . . . . . . . 52		16.6. The Atom Format Media Type Parameter . . . . . . . . . . . 51
	17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53		17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
	17.1. Normative References . . . . . . . . . . . . . . . . . . . 53		17.1. Normative References . . . . . . . . . . . . . . . . . . . 52
	17.2. Informative References . . . . . . . . . . . . . . . . . . 54		17.2. Informative References . . . . . . . . . . . . . . . . . . 53
	Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 56		Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 55
	Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 57		Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 56
	Appendix C. Revision History . . . . . . . . . . . . . . . . . . 63		Appendix C. Revision History . . . . . . . . . . . . . . . . . . 62
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66
	Intellectual Property and Copyright Statements . . . . . . . . . . 68		Intellectual Property and Copyright Statements . . . . . . . . . . 67
	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
	[REC-xml]. The protocol supports the creation of Web Resources and		[REC-xml]. The protocol supports the creation of Web Resources and
	provides facilities for:		provides facilities for:
	o Collections: Sets of Resources, which can be retrieved in whole or		o Collections: Sets of Resources, which can be retrieved in whole or
	in part.		in part.
	skipping to change at page 7, line 42		skipping to change at page 7, line 42
	2.1.3. Use of xml:base and xml:lang		2.1.3. Use of xml:base and xml:lang
	XML elements defined by this specification MAY have an xml:base		XML elements defined by this specification MAY have an xml:base
	attribute [REC-xmlbase]. When xml:base is used, it serves the		attribute [REC-xmlbase]. When xml:base is used, it serves the
	function described in Section 5.1.1 of URI Generic Syntax [RFC3986],		function described in Section 5.1.1 of URI Generic Syntax [RFC3986],
	by establishing the base URI (or IRI) for resolving relative		by establishing the base URI (or IRI) for resolving relative
	references found within the scope of the xml:base attribute.		references found within the scope of the xml:base attribute.
	Any element defined by this specification MAY have an xml:lang		Any element defined by this specification MAY have an xml:lang
	attribute, whose content indicates the natural language for the		attribute, whose content indicates the natural language for the
	element and its descendents. Requirements regarding the content and		element and its descendants. Requirements regarding the content and
	interpretation of xml:lang are specified in Section 2.12 of XML 1.0		interpretation of xml:lang are specified in Section 2.12 of XML 1.0
	[REC-xml].		[REC-xml].
	3. Terminology		3. Terminology
	For convenience, this protocol can be referred to as the "Atom		For convenience, this protocol can be referred to as the "Atom
	Protocol" or "APP". The following terminology is used by this		Protocol" or "APP". The following terminology is used by this
	specification:		specification:
	o URI - A Uniform Resource Identifier as defined in [RFC3986]. In		o URI - A Uniform Resource Identifier as defined in [RFC3986]. In
	skipping to change at page 18, line 21		skipping to change at page 18, line 21
	A Category Document (Section 7) contains lists of categories		A Category Document (Section 7) contains lists of categories
	specified using the "atom:category" element from the Atom Syndication		specified using the "atom:category" element from the Atom Syndication
	Format (see Section 4.2.2 of [RFC4287]).		Format (see Section 4.2.2 of [RFC4287]).
	A Service Document (Section 8) groups available Collections into		A Service Document (Section 8) groups available Collections into
	Workspaces.		Workspaces.
	The namespace name [REC-xml-names] for either kind of document is:		The namespace name [REC-xml-names] for either kind of document is:
	http://purl.org/atom/app#		http://www.w3.org/2007/app
	[[anchor9: The namespace name 'http://purl.org/atom/app#' needs to be
	updated throughout the document with the final URI upon publication]]
	Atom Publishing Protocol XML Documents MUST be "namespace-well-		Atom Publishing Protocol XML Documents MUST be "namespace-well-
	formed" as specified in Section 7 of [REC-xml-names].		formed" as specified in Section 7 of [REC-xml-names].
	This specification uses the prefix "app:" for the namespace name.		This specification uses the prefix "app:" for the namespace name.
	The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the		The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the
	namespace name of the Atom Syndication Format [RFC4287]. These		namespace name of the Atom Syndication Format [RFC4287]. These
	namespace prefixes are not semantically significant.		namespace prefixes are not semantically significant.
	This specification does not define any DTDs for Atom Protocol		This specification does not define any DTDs for Atom Protocol
	skipping to change at page 18, line 48		skipping to change at page 18, line 45
	6.2. Document Extensibility		6.2. Document Extensibility
	Unrecognized markup in an Atom Publishing Protocol document is		Unrecognized markup in an Atom Publishing Protocol document is
	considered "foreign markup" as defined in Section 6 of the Atom		considered "foreign markup" as defined in Section 6 of the Atom
	Syndication Format [RFC4287]. Foreign markup can be used anywhere		Syndication Format [RFC4287]. Foreign markup can be used anywhere
	within a Category or Service Document unless it is explicitly		within a Category or Service Document unless it is explicitly
	forbidden. Processors that encounter foreign markup MUST NOT stop		forbidden. Processors that encounter foreign markup MUST NOT stop
	processing and MUST NOT signal an error. Clients SHOULD preserve		processing and MUST NOT signal an error. Clients SHOULD preserve
	foreign markup when transmitting such documents.		foreign markup when transmitting such documents.
	The namespace name "http://purl.org/atom/app#" is reserved for		The namespace name "http://www.w3.org/2007/app" is reserved for
	forward compatible revisions of the Category and Service Document		forward compatible revisions of the Category and Service Document
	types - this does not exclude the addition of elements and attributes		types - this does not exclude the addition of elements and attributes
	that might not be recognized by processors conformant to this		that might not be recognized by processors conformant to this
	specification. Such unrecognized markup from the		specification. Such unrecognized markup from the
	"http://purl.org/atom/app#" namespace MUST be treated as foreign		"http://www.w3.org/2007/app" namespace MUST be treated as foreign
	markup.		markup.
	7. Category Documents		7. Category Documents
	Category Documents contain lists of categories described using the		Category Documents contain lists of categories described using the
	"atom:category" element from the Atom Syndication Format [RFC4287].		"atom:category" element from the Atom Syndication Format [RFC4287].
	Categories can also appear in Service Documents, where they indicate		Categories can also appear in Service Documents, where they indicate
	the categories allowed in a Collection (see Section 8.3.6).		the categories allowed in a Collection (see Section 8.3.6).
	Category Documents are identified with the "application/atomcat+xml"		Category Documents are identified with the "application/atomcat+xml"
	media type (see Section 16.1).		media type (see Section 16.1).
	7.1. Example		7.1. Example
	<?xml version="1.0" ?>		<?xml version="1.0" ?>
	<app:categories		<app:categories
	xmlns:app="http://purl.org/atom/app#"		xmlns:app="http://www.w3.org/2007/app"
	xmlns:atom="http://www.w3.org/2005/Atom"		xmlns:atom="http://www.w3.org/2005/Atom"
	fixed="yes" scheme="http://example.com/cats/big3">		fixed="yes" scheme="http://example.com/cats/big3">
	<atom:category term="animal" />		<atom:category term="animal" />
	<atom:category term="vegetable" />		<atom:category term="vegetable" />
	<atom:category term="mineral" />		<atom:category term="mineral" />
	</app:categories>		</app:categories>
	This Category Document contains atom:category elements, with the		This Category Document contains atom:category elements, with the
	terms 'animal', 'vegetable', and 'mineral'. None of the categories		terms 'animal', 'vegetable', and 'mineral'. None of the categories
	use the "label" attribute defined in [RFC4287]. They all inherit the		use the "label" attribute defined in [RFC4287]. They all inherit the
	skipping to change at page 23, line 8		skipping to change at page 22, line 8
	specification. This specification assigns no meaning to Workspaces;		specification. This specification assigns no meaning to Workspaces;
	that is, a Workspace does not imply any specific processing		that is, a Workspace does not imply any specific processing
	assumptions.		assumptions.
	There is no requirement that a server support multiple Workspaces.		There is no requirement that a server support multiple Workspaces.
	In addition, a Collection MAY appear in more than one Workspace.		In addition, a Collection MAY appear in more than one Workspace.
	8.2. Example		8.2. 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://www.w3.org/2007/app"
	xmlns:atom="http://www.w3.org/2005/Atom">		xmlns:atom="http://www.w3.org/2005/Atom">
	<workspace>		<workspace>
	<atom:title>Main Site</atom:title>		<atom:title>Main Site</atom:title>
	<collection		<collection
	href="http://example.org/blog/main" >		href="http://example.org/blog/main" >
	<atom:title>My Blog Entries</atom:title>		<atom:title>My Blog Entries</atom:title>
	<categories		<categories
	href="http://example.com/cats/forMain.cats" />		href="http://example.com/cats/forMain.cats" />
	</collection>		</collection>
	<collection		<collection
	skipping to change at page 24, line 29		skipping to change at page 23, line 29
	8.3. Element Definitions		8.3. Element Definitions
	8.3.1. The "app:service" Element		8.3.1. The "app:service" Element
	The root of a Service Document is the "app:service" element.		The root of a Service Document is the "app:service" element.
	The app:service element is the container for service information		The app:service element is the container for service information
	associated with one or more Workspaces. An app:service element MUST		associated with one or more Workspaces. An app:service element MUST
	contain one or more app:workspace elements.		contain one or more app:workspace elements.
	namespace app = "http://purl.org/atom/app#"		namespace app = "http://www.w3.org/2007/app"
	start = appService		start = appService
	appService =		appService =
	element app:service {		element app:service {
	appCommonAttributes,		appCommonAttributes,
	( appWorkspace+		( appWorkspace+
	& extensionElement* )		& extensionElement* )
	}		}
	8.3.2. The "app:workspace" Element		8.3.2. The "app:workspace" Element
	skipping to change at page 26, line 51		skipping to change at page 25, line 51
	collection element is considered foreign markup as defined in Section		collection element is considered foreign markup as defined in Section
	6 of [RFC4287].		6 of [RFC4287].
	8.3.6. The "app:categories" Element		8.3.6. The "app:categories" Element
	The "app:categories" element provides a list of the categories that		The "app:categories" element provides a list of the categories that
	can be applied to the members of a Collection. See Section 7.2.1 for		can be applied to the members of a Collection. See Section 7.2.1 for
	the detailed definition of app:categories.		the detailed definition of app:categories.
	The server MAY reject attempts to create or store members whose		The server MAY reject attempts to create or store members whose
	categories are not present in it's categories list. Collections that		categories are not present in its categories list. Collections that
	indicate the category set is open SHOULD NOT reject otherwise		indicate the category set is open SHOULD NOT reject otherwise
	acceptable members whose categories are not in its categories list.		acceptable members whose categories are not in its categories list.
	The absence of an "app:categories" element means that the category		The absence of an "app:categories" element means that the category
	handling of the Collection is unspecified. A "fixed" category list		handling of the Collection is unspecified. A "fixed" category list
	that contains zero categories indicates the Collection does not		that contains zero categories indicates the Collection does not
	accept category data.		accept category data.
	9. Creating and Editing Resources		9. Creating and Editing Resources
	9.1. Member URIs		9.1. Member URIs
	skipping to change at page 33, line 14		skipping to change at page 32, line 14
	an atom:content element with a "src" attribute. The value of the		an atom:content element with a "src" attribute. The value of the
	"src" attribute is an IRI for the newly created Media Resource. It		"src" attribute is an IRI for the newly created Media Resource. It
	is OPTIONAL that the IRI of the "src" attribute on the atom:content		is OPTIONAL that the IRI of the "src" attribute on the atom:content
	element be the same as the Media Resource IRI. For example, the		element be the same as the Media Resource IRI. For example, the
	"src" attribute value might instead be a link into a static cache or		"src" attribute value might instead be a link into a static cache or
	content distribution network and not the Media Resource IRI.		content distribution network and not the Media Resource IRI.
	Implementers are asked to note that [RFC4287] specifies that Atom		Implementers are asked to note that [RFC4287] specifies that Atom
	Entries MUST contain an atom:summary element. Thus, upon successful		Entries MUST contain an atom:summary element. Thus, upon successful
	creation of a Media Link Entry, a server MAY choose to populate the		creation of a Media Link Entry, a server MAY choose to populate the
	atom:summary element (as well as any other required elements such as		atom:summary element (as well as any other mandatory elements such as
	atom:id, atom:author and atom:title) with content derived from the		atom:id, atom:author and atom:title) with content derived from the
	POSTed entity or from any other source. A server might not allow a		POSTed entity or from any other source. A server might not allow a
	client to modify the server selected values for these elements.		client to modify the server selected values for these elements.
	For Resource creation this specification only defines cases where the		For Resource creation this specification only defines cases where the
	POST body has an Atom Entry entity declared as an Atom media type		POST body has an Atom Entry entity declared as an Atom media type
	("application/atom+xml"), or a non-Atom entity declared as a non-Atom		("application/atom+xml"), or a non-Atom entity declared as a non-Atom
	media type. When a client is POSTing an Atom Entry to a collection,		media type. When a client is POSTing an Atom Entry to a collection,
	it may use a media-type of either "application/atom+xml" or		it may use a media-type of either "application/atom+xml" or
	"application/atom +xml;type=entry". This specification does not		"application/atom +xml;type=entry". This specification does not
	skipping to change at page 39, line 36		skipping to change at page 38, line 36
	</xhtml:p>		</xhtml:p>
	</xhtml:div>		</xhtml:div>
	</content>		</content>
	<link rel="edit"		<link rel="edit"
	href="http://example.org/blog/edit/a-day-at-the-beach.atom"/>		href="http://example.org/blog/edit/a-day-at-the-beach.atom"/>
	<link rel="alternate" type="text/html"		<link rel="alternate" type="text/html"
	href="http://example.org/blog/a-day-at-the-beach.html"/>		href="http://example.org/blog/a-day-at-the-beach.html"/>
	</entry>		</entry>
	Note that the returned Entry contains a link with a relation of		Note that the returned Entry contains a link with a relation of
	"alternate" that points to the associated HTML page that was created.		"alternate" that points to the associated HTML page that was created
	This is not required by this specification, but is included to show		- this is not required by this specification, but is included to show
	the kinds of changes a server can make to an Entry.		the kinds of changes a server can make to an Entry.
	9.7. The Slug: Header		9.7. The Slug: Header
	Slug is an HTTP entity-header whose presence in a POST to a		Slug is an HTTP entity-header whose presence in a POST to a
	Collection constitutes a request by the client to use the header's		Collection constitutes a request by the client to use the header's
	value as part of any URIs that would normally used to retrieve the		value as part of any URIs that would normally used to retrieve the
	to-be-created Entry or Media resources.		to-be-created Entry or Media resources.
	Servers MAY use the value of the Slug header when creating the Member		Servers MAY use the value of the Slug header when creating the Member
	skipping to change at page 40, line 13		skipping to change at page 39, line 13
	Link Entry (see Section 9.6.).		Link Entry (see Section 9.6.).
	Servers MAY choose to ignore the Slug entity-header. Servers MAY		Servers MAY choose to ignore the Slug entity-header. Servers MAY
	alter the header value before using it. For instance, a server might		alter the header value before using it. For instance, a server might
	filter out some characters or replace accented letters with non-		filter out some characters or replace accented letters with non-
	accented ones, replace spaces with underscores, change case, and so		accented ones, replace spaces with underscores, change case, and so
	on.		on.
	9.7.1. Slug: Header syntax		9.7.1. Slug: Header syntax
	The syntax of this header MUST conform to the augmented BNF grammar		The syntax of the Slug header is defined using the augmented BNF
	in section 2.1 of the HTTP/1.1 specification [RFC2616]. The TEXT		syntax defined in Section 2.1 of [RFC2616]:
	rule is described in section 2.2 of the same document.
	Slug = "Slug" ":" *TEXT		LWS = <defined in Section 2.2 of [RFC2616]>
			slugtext = %x20-7E | LWS
			Slug = "Slug" ":" *slugtext
	The field-value of the Slug header is a percent-encoded utf-8 Unicode		The field-value is the percent-encoded value of the UTF-8 encoding of
	string that does not contain CR or LF, where CR and LF are defined in		the character sequence to be included (see Section 2.1 of [RFC3986]
	[RFC2616]. All non-ASCII characters in the utf-8 representation MUST		for the definition of percent encoding, and [RFC3629] for the
	be percent-encoded according to the rules in Section 2.1 of		definition of the UTF-8 encoding).
	[RFC3986].
			Implementation note: to produce the field value from a character
			sequence, first encode it using the UTF-8 encoding, then encode all
			octets outside the ranges %20-24 and %26-7E using percent encoding
			(%25 is the ASCII encoding of "%", thus it needs to be escaped). To
			consume the field value first reverse the percent encoding, then run
			the resulting octet sequence through a UTF-8 decoding process.
	9.7.2. Example		9.7.2. Example
	Here is an example of the Slug: header that uses percent-encoding to		Here is an example of the Slug: header that uses percent-encoding to
	represent the Unicode character U+00E8 (LATIN SMALL LETTER E WITH		represent the Unicode character U+00E8 (LATIN SMALL LETTER E WITH
	GRAVE):		GRAVE):
	POST /myblog/entries HTTP/1.1		POST /myblog/entries HTTP/1.1
	Host: example.org		Host: example.org
	Content-Type: image/png		Content-Type: image/png
	skipping to change at page 44, line 12		skipping to change at page 43, line 12
	"hreflang" attributes then the client SHOULD pick the first "edit-		"hreflang" attributes then the client SHOULD pick the first "edit-
	media" link relation in document order.		media" link relation in document order.
	12. The Atom Format Type Parameter		12. The Atom Format Type Parameter
	The Atom Syndication Format [RFC4287] defines the "application/		The Atom Syndication Format [RFC4287] defines the "application/
	atom+xml" media type to identify both Atom Feed and Atom Entry		atom+xml" media type to identify both Atom Feed and Atom Entry
	Documents. Implementation experience has demonstrated that Atom Feed		Documents. Implementation experience has demonstrated that Atom Feed
	and Entry Documents can have different processing models and that		and Entry Documents can have different processing models and that
	there are situations where they need to be differentiated. This		there are situations where they need to be differentiated. This
	document defines an optional "type" parameter used to differentiate		specification defines an optional "type" parameter used to
	the two types of Atom documents.		differentiate the two types of Atom documents.
	12.1. The 'type' parameter		12.1. The 'type' parameter
	This document defines a new "type" parameter for use with the		This specification defines a new "type" parameter for use with the
	"application/atom+xml" media type. The "type" parameter has a value		"application/atom+xml" media type. The "type" parameter has a value
	of "entry" or "feed".		of "entry" or "feed".
	Neither the parameter name nor its value are case sensitive.		Neither the parameter name nor its value are case sensitive.
	The value "entry" indicates that the media type identifies an Atom		The value "entry" indicates that the media type identifies an Atom
	Entry Document. The root element of the document MUST be atom:entry.		Entry Document. The root element of the document MUST be atom:entry.
	The value "feed" indicates that the media type identifies an Atom		The value "feed" indicates that the media type identifies an Atom
	Feed Document. The root element of the document MUST be atom:feed.		Feed Document. The root element of the document MUST be atom:feed.
	If not specified, the type is assumed to be unspecified, requiring		If not specified, the type is assumed to be unspecified, requiring
	Atom processors to examine the root element to determine the type of		Atom processors to examine the root element to determine the type of
	Atom document.		Atom document.
	12.1.1. Conformance		12.1.1. Conformance
	New specifications MAY require that the "type" parameter be used to		New specifications MAY require that the "type" parameter be used to
	identify the Atom Document type. Producers of Atom Entry Documents		identify the Atom Document type. Producers of Atom Entry Documents
	SHOULD use the "type" parameter regardless of whether or not it is		SHOULD use the "type" parameter regardless of whether or not it is
	required. Producers of Atom Feed Documents MAY use the parameter.		mandatory. Producers of Atom Feed Documents MAY use the parameter.
	Atom processors that do not recognize the "type" parameter MUST		Atom processors that do not recognize the "type" parameter MUST
	ignore its value and examine the root element to determine the		ignore its value and examine the root element to determine the
	document type.		document type.
	Atom processors that do recognize the "type" parameter SHOULD detect		Atom processors that do recognize the "type" parameter SHOULD detect
	and report inconsistencies between the parameter's value and the		and report inconsistencies between the parameter's value and the
	actual type of the document's root element.		actual type of the document's root element.
	13. Atom Publishing Controls		13. Atom Publishing Controls
	This specification defines an Atom Format Structured Extension, as		This specification defines an Atom Format Structured Extension, as
	defined in Section 6 of [RFC4287], for publishing control within the		defined in Section 6 of [RFC4287], for publishing control within the
	"http://purl.org/atom/app#" namespace.		"http://www.w3.org/2007/app" namespace.
	13.1. The "app:control" Element		13.1. The "app:control" Element
	namespace app = "http://purl.org/atom/app#"		namespace app = "http://www.w3.org/2007/app"
	pubControl =		pubControl =
	element app:control {		element app:control {
	atomCommonAttributes,		atomCommonAttributes,
	pubDraft?		pubDraft?
	& extensionElement		& extensionElement
	}		}
	pubDraft =		pubDraft =
	element app:draft { "yes" | "no" }		element app:draft { "yes" | "no" }
	The "app:control" element MAY appear as a child of an atom:entry that		The "app:control" element MAY appear as a child of an atom:entry that
	is being created or updated via the Atom Publishing Protocol. The		is being created or updated via the Atom Publishing Protocol. The
	app:control element MUST appear only once in an Entry. The app:		app:control element MUST appear only once in an Entry. The app:
	control element is considered foreign markup as defined in Section 6		control element is considered foreign markup as defined in Section 6
	of [RFC4287].		of [RFC4287].
	The app:control element and its child elements MAY be included in		The app:control element and its child elements MAY be included in
	Atom Feed or Entry Documents.		Atom Feed or Entry Documents.
	The app:control element can contain an optional "app:draft" element		The app:control element can contain an "app:draft" element as defined
	as defined below, and can contain extension elements as defined in		below, and can contain extension elements as defined in Section 6 of
	Section 6 of [RFC4287].		[RFC4287].
	13.1.1. The "app:draft" Element		13.1.1. The "app:draft" Element
	The inclusion of the "app:draft" element represents a request by the		The inclusion of the "app:draft" element represents a request by the
	client to control the visibility of a Member Resource. Server		client to control the visibility of a Member Resource. The app:draft
	support is optional and thus the app:draft element MAY be ignored by		element MAY be ignored by the server.
	the server.
	The number of app:draft elements in app:control MUST be zero or one.		The number of app:draft elements in app:control MUST be zero or one.
	The content of an app:draft element MUST be one of "yes" or "no". If		The content of an app:draft element MUST be one of "yes" or "no". If
	the element contains "no" this indicates a client request that the		the element contains "no" this indicates a client request that the
	Member Resource be made publicly visible. If the app:draft element		Member Resource be made publicly visible. If the app:draft element
	is not present then servers that support the extension MUST behave as		is not present then servers that support the extension MUST behave as
	though an app:draft element containing "no" was sent.		though an app:draft element containing "no" was sent.
	14. Securing the Atom Publishing Protocol		14. Securing the Atom Publishing Protocol
	The Atom Publishing Protocol is based on HTTP. Authentication		The Atom Publishing Protocol is based on HTTP. Authentication
	requirements for HTTP are covered in Section 11 of [RFC2616].		requirements for HTTP are covered in Section 11 of [RFC2616].
	The use of authentication mechanisms to prevent POSTing or editing by		The use of authentication mechanisms to prevent POSTing or editing by
	unknown or unauthorized clients is RECOMMENDED but not required.		unknown or unauthorized clients is recommended but not required.
	When authentication is not used, clients and servers are vulnerable		When authentication is not used, clients and servers are vulnerable
	to trivial spoofing, denial of service, and defacement attacks.		to trivial spoofing, denial of service, and defacement attacks.
	However, in some contexts, this is an acceptable risk.		However, in some contexts, this is an acceptable risk.
	The type of authentication deployed is a local decision made by the		The type of authentication deployed is a local decision made by the
	server operator. Clients are likely to face authentication schemes		server operator. Clients are likely to face authentication schemes
	that vary across server deployments. At a minimum, client and server		that vary across server deployments. At a minimum, client and server
	implementations MUST be capable of being configured to use HTTP Basic		implementations MUST be capable of being configured to use HTTP Basic
	Authentication [RFC2617] in conjunction with a TLS [RFC2246]		Authentication [RFC2617] in conjunction with a connection made with
	connection as defined in [RFC2818] (but note that [RFC2246] has been		TLS 1.0 [RFC2246] or a subsequent standards-track version of TLS,
	superseded by [RFC4346]). See [RFC4346] for more information on TLS.		supporting the conventions for using HTTP over TLS described in
			[RFC2818]. At a minimum, client and server implementations MUST be
			capable of being configured to use HTTP Basic Authentication
			[RFC2617] in conjunction with a TLS 1.0 [RFC2246] or a subsequent
			standards-track version of TLS, supporting the conventions for using
			HTTP over TLS described in [RFC2818].
	The choice of authentication mechanism will impact interoperability.		The choice of authentication mechanism will impact interoperability.
	The minimum level of security referenced above (Basic Authentication		The minimum level of security referenced above (Basic Authentication
	with TLS) is considered good practice for Internet applications at		with TLS) is considered good practice for Internet applications at
	the time of publication of this specification and sufficient for		the time of publication of this specification and sufficient for
	establishing a baseline for interoperability. Implementers are		establishing a baseline for interoperability. Implementers are
	encouraged to investigate and use alternative mechanisms regarded as		encouraged to investigate and use alternative mechanisms regarded as
	equivalently good or better at the time of deployment. It is		equivalently good or better at the time of deployment. It is
	RECOMMENDED that clients be implemented in such a way that new		RECOMMENDED that clients be implemented in such a way that new
	authentication schemes can be deployed.		authentication schemes can be deployed.
	Because this protocol uses HTTP response status codes as the primary		Because this protocol uses HTTP response status codes as the primary
	means of reporting the result of a request, servers are advised to		means of reporting the result of a request, servers are advised to
	respond to unauthorized or unauthenticated requests using an		respond to unauthorized or unauthenticated requests using an
	appropriate 4xx HTTP response code (e.g. 401 "Unauthorized" or 403		appropriate 4xx HTTP response code (e.g., 401 "Unauthorized" or 403
	"Forbidden") in accordance with [RFC2617].		"Forbidden") in accordance with [RFC2617].
	15. Security Considerations		15. Security Considerations
	The Atom Publishing Protocol is based on HTTP and thus subject to the		The Atom Publishing Protocol is based on HTTP and thus subject to the
	security considerations found in Section 15 of [RFC2616].		security considerations found in Section 15 of [RFC2616].
			The threats listed in this section apply to many protocols that run
			under HTTP. The Atompub Working Group decided that the protection
			afforded by running authenticated HTTP under TLS (as described in
			Section 14) was sufficient to mitigate many of the problems presented
			by the attacks listed in this section.
	15.1. Denial of Service		15.1. Denial of Service
	Atom Publishing Protocol server implementations need to take adequate		Atom Publishing Protocol server implementations need to take adequate
	precautions to ensure malicious clients cannot consume excessive		precautions to ensure malicious clients cannot consume excessive
	server resources (CPU, memory, disk, etc).		server resources (CPU, memory, disk, etc).
	15.2. Replay Attacks		15.2. Replay Attacks
	Atom Publishing Protocol server implementations are susceptible to		Atom Publishing Protocol server implementations are susceptible to
	replay attacks. Specifically, this specification does not define a		replay attacks. Specifically, this specification does not define a
	means of detecting duplicate requests. Accidentally sent duplicate		means of detecting duplicate requests. Accidentally sent duplicate
	requests are indistinguishable from intentional and malicious replay		requests are indistinguishable from intentional and malicious replay
	attacks.		attacks.
	15.3. Spoofing Attacks		15.3. Spoofing Attacks
	Atom Publishing Protocol implementations are susceptible to a variety		Atom Publishing Protocol implementations are susceptible to a variety
	of spoofing attacks. Malicious clients may send Atom Entries		of spoofing attacks. Malicious clients might send Atom Entries
	containing inaccurate information anywhere in the document.		containing inaccurate information anywhere in the document.
	15.4. Linked Resources		15.4. Linked Resources
	Atom Feed and Entry documents can contain XML External Entities as		Atom Feed and Entry documents can contain XML External Entities as
	defined in Section 4.2.2 of [REC-xml]. Atom implementations are not		defined in Section 4.2.2 of [REC-xml]. Atom implementations are not
	required to load external entities. External entities are subject to		required to load external entities. External entities are subject to
	the same security concerns as any network operation and can alter the		the same security concerns as any network operation and can alter the
	semantics of an Atom document. The same issues exist for Resources		semantics of an Atom document. The same issues exist for Resources
	linked to by Atom elements such as atom:link and atom:content.		linked to by Atom elements such as atom:link and atom:content.
	15.5. Digital Signatures and Encryption		15.5. Digital Signatures and Encryption
	Atom Entry Documents sent to a server might contain XML Digital		Atom Entry and Feed Documents can contain XML Digital Signatures
	Signatures [REC-xmldsig-core] and might be encrypted using XML		[REC-xmldsig-core] and can be encrypted using XML Encryption
	Encryption [REC-xmlenc-core] as specified in Section 5 of [RFC4287].		[REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling
			of signatures and encrypted elements in Atom documents is discussed
			in sections 5 and 6.3 of [RFC4287].
	Servers are allowed to modify received Resource representations in		Neither servers nor clients are under any obligation to support
	ways that can invalidate signatures covering those representations.		encryption and digital signature of entries or feeds, although it is
			certainly possible that in some installations, clients or servers
			might require signing or encrypting of the documents exchanged in the
			Atom protocol.
			Because servers are allowed (and in some cases expected) to modify
			the contents of an Entry Document before publishing it, signatures
			within an entry are only likely to be useful to the server to which
			the entry is being sent. Clients cannot assume that the signature
			will be valid when viewed by a third party, or even that the server
			will publish the client's signature.
			A server is allowed to strip client-applied signatures, to strip
			client-applied signatures and then re-sign with its own public key,
			and to oversign an entry with its own public key. The meaning to a
			third party of a signature applied by a server is the same as a
			signature from anyone, as described in [RFC4287]. It is recommended
			that a server that is aware that it has changed any part of an Entry
			Document that was signed by the client should strip that signature
			before publishing the entry in order to prevent third parties from
			trying to interpret a signature that cannot be validated.
	15.6. URIs and IRIs		15.6. URIs and IRIs
	Atom Publishing Protocol implementations handle URIs and IRIs. See		Atom Publishing Protocol implementations handle URIs and IRIs. See
	Section 7 of [RFC3986] and Section 8 of [RFC3987] for security		Section 7 of [RFC3986] and Section 8 of [RFC3987] for security
	considerations related to their handling and use.		considerations related to their handling and use.
			The Atom Publishing Protocol leaves the server in control of minting
			URIs. The use of any client-supplied data for creating new URIs is
			subject to the same concerns as described in the next section.
	15.7. Code Injection and Cross Site Scripting		15.7. Code Injection and Cross Site Scripting
	Atom Feed and Entry documents can contain a broad range of content		Atom Feed and Entry documents can contain a broad range of content
	types including code that might be executable in some contexts.		types including code that might be executable in some contexts.
	Malicious clients could attempt to attack servers or other clients by		Malicious clients could attempt to attack servers or other clients by
	injecting code into a Collection Document's Entry or Media Resources.		injecting code into a Collection Document's Entry or Media Resources.
	Server implementations are strongly encouraged to verify that client		Server implementations are strongly encouraged to verify that client
	supplied content is safe prior to accepting, processing or publishing		supplied content is safe prior to accepting, processing or publishing
	it. In the case of HTML, experience indicates that verification		it. In the case of HTML, experience indicates that verification
	based on a white list of acceptable content is more effective than a		based on a white list of acceptable content is more effective than a
	black list of forbidden content.		black list of forbidden content.
	Additional information about XHTML and HTML content safety can be		Additional information about XHTML and HTML content safety can be
	found in Section 8.1 of [RFC4287]		found in Section 8.1 of [RFC4287]
	16. IANA Considerations		16. IANA Considerations
	This document uses two new media types that conform to the registry		This specification uses two new media types that conform to the
	mechanism described in [RFC4288], a new message header that conforms		registry mechanism described in [RFC4288], a new message header that
	to the registry mechanism described in [RFC3864], and two new link		conforms to the registry mechanism described in [RFC3864], and two
	relations that conform to the registry mechanism described in		new link relations that conform to the registry mechanism described
	[RFC4287].		in [RFC4287].
	16.1. Content-type registration for 'application/atomcat+xml'		16.1. Content-type registration for 'application/atomcat+xml'
	An Atom Publishing Protocol Category Document, when serialized as XML		An Atom Publishing Protocol Category Document, when serialized as XML
	1.0, can be identified with the following media type:		1.0, can be identified with the following media type:
	MIME media type name: application		MIME media type name: application
	MIME subtype name: atomcat+xml		MIME subtype name: atomcat+xml
	skipping to change at page 49, line 34		skipping to change at page 48, line 34
	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.
	[[anchor31: update upon publication]]		[[anchor30: 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. [[anchor32: update upon		Published specification: This specification. [[anchor31: 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 50, line 22		skipping to change at page 49, line 22
	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).		Author/Change controller: IETF (iesg@ietf.org) Internet Engineering
	[[anchor33: update upon publication]]		Task Force
	16.2. Content-type registration for 'application/atomsvc+xml'		16.2. Content-type registration for 'application/atomsvc+xml'
	An Atom Publishing Protocol Service Document, when serialized as XML		An Atom Publishing Protocol Service Document, when serialized as XML
	1.0, can be identified with the following media type:		1.0, can be identified with the following media type:
	MIME media type name: application		MIME media type name: application
	MIME subtype name: atomsvc+xml		MIME subtype name: atomsvc+xml
	skipping to change at page 50, line 46		skipping to change at page 49, line 46
	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.
	[[anchor34: 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. [[anchor35: 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 51, line 33		skipping to change at page 50, line 33
	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).		Author/Change controller: IETF (iesg@ietf.org) Internet Engineering
	[[anchor36: update upon publication]]		Task Force
	16.3. Header field registration for 'SLUG'		16.3. Header field registration for 'SLUG'
	Header field: SLUG		Header field: SLUG
	Applicable protocol: http [RFC2616]		Applicable protocol: http [RFC2616]
	Status: standard.		Status: standard.
	Author/Change controller: IETF (iesg@ietf.org) Internet Engineering		Author/Change controller: IETF (iesg@ietf.org) Internet Engineering
	Task Force		Task Force
	Specification document(s): This specification. [[anchor37: update on		Specification document(s): This specification. [[anchor34: update on
	rfc number assignment]])		rfc number assignment]])
	Related information:		Related information:
	16.4. The Link Relation registration "edit"		16.4. The Link Relation registration "edit"
	Attribute Value: edit		Attribute Value: edit
	Description: An IRI of an editable Member Entry. When appearing		Description: An IRI of an editable Member Entry. When appearing
	within an atom:entry, the href IRI can be used to retrieve, update		within an atom:entry, the href IRI can be used to retrieve, update
	and delete the Resource represented by that Entry.		and delete the Resource represented by that Entry.
	skipping to change at page 54, line 15		skipping to change at page 53, line 15
	[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,		[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
	Leach, P., Luotonen, A., and L. Stewart, "HTTP		Leach, P., Luotonen, A., and L. Stewart, "HTTP
	Authentication: Basic and Digest Access Authentication",		Authentication: Basic and Digest Access Authentication",
	RFC 2617, June 1999.		RFC 2617, June 1999.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[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.
			[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
			10646", STD 63, RFC 3629, November 2003.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[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		[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
	Format", RFC 4287, December 2005.		Format", RFC 4287, December 2005.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", BCP 13, RFC 4288, December 2005.
	[RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.1", RFC 4346, April 2006.
	17.2. Informative References		17.2. Informative References
	[NOTE-detect-lost-update]		[NOTE-detect-lost-update]
	Nielsen, H. and D. LaLiberte, "Editing the Web: Detecting		Nielsen, H. and D. LaLiberte, "Editing the Web: Detecting
	the Lost Update Problem Using Unreserved Checkout", World		the Lost Update Problem Using Unreserved Checkout", World
	Wide Web Consortium NOTE NOTE-detect-lost-update,		Wide Web Consortium NOTE NOTE-detect-lost-update,
	May 1999, <http://www.w3.org/1999/04/Editing/>.		May 1999, <http://www.w3.org/1999/04/Editing/>.
	[REC-webarch]		[REC-webarch]
	Walsh, N. and I. Jacobs, "Architecture of the World Wide		Walsh, N. and I. Jacobs, "Architecture of the World Wide
	skipping to change at page 57, line 20		skipping to change at page 56, line 20
	namespace which are not defined in this revision of the		namespace which are not defined in this revision of the
	specification. Requirements for Atom Protocol processors		specification. Requirements for Atom Protocol processors
	encountering such markup are given in Section 6.2 and Section 6.3 of		encountering such markup are given in Section 6.2 and Section 6.3 of
	[RFC4287].		[RFC4287].
	The Schema for Service Documents:		The Schema for Service Documents:
	# -*- 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://www.w3.org/2007/app"
	namespace atom = "http://www.w3.org/2005/Atom"		namespace atom = "http://www.w3.org/2005/Atom"
	namespace xsd = "http://www.w3.org/2001/XMLSchema"		namespace xsd = "http://www.w3.org/2001/XMLSchema"
	namespace xhtml = "http://www.w3.org/1999/xhtml"		namespace xhtml = "http://www.w3.org/1999/xhtml"
	namespace local = ""		namespace local = ""
	start = appService		start = appService
	# common:attrs		# common:attrs
	atomURI = text		atomURI = text
	skipping to change at page 61, line 16		skipping to change at page 60, line 16
	| anyXHTML)*		| anyXHTML)*
	}		}
	# EOF		# EOF
	The Schema for Category Documents:		The Schema for Category Documents:
	# -*- 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://www.w3.org/2007/app"
	namespace atom = "http://www.w3.org/2005/Atom"		namespace atom = "http://www.w3.org/2005/Atom"
	namespace xsd = "http://www.w3.org/2001/XMLSchema"		namespace xsd = "http://www.w3.org/2001/XMLSchema"
	namespace local = ""		namespace local = ""
	start = appCategories		start = appCategories
	atomCommonAttributes =		atomCommonAttributes =
	attribute xml:base { atomURI }?,		attribute xml:base { atomURI }?,
	attribute xml:lang { atomLanguageTag }?,		attribute xml:lang { atomLanguageTag }?,
	undefinedAttribute*		undefinedAttribute*
	skipping to change at page 63, line 7		skipping to change at page 62, line 7
	element * - atom:* {		element * - atom:* {
	(attribute * { text }		(attribute * { text }
	| text		| text
	| anyElement)*		| anyElement)*
	}		}
	# EOF		# EOF
	Appendix C. Revision History		Appendix C. Revision History
	[[anchor42: This section to be removed upon publication.]]		[[anchor39: This section to be removed upon publication.]]
	draft-ietf-atompub-protocol-14: typos; removed "The language context		draft-ietf-atompub-protocol-14: typos; removed "The language context
	is only significant for elements and attributes declared to be		is only significant for elements and attributes declared to be
	"Language-Sensitive" by this specification. "; "Successful member		"Language-Sensitive" by this specification. "; "Successful member
	creation is normally indicated with a 201 ("Created") response code."		creation is normally indicated with a 201 ("Created") response code."
	removed "normally" from that sentence (9.2); Added "Media Link		removed "normally" from that sentence (9.2); Added "Media Link
	Entries are represented as Atom Entries and appear in the		Entries are represented as Atom Entries and appear in the
	Collection." to 9.6; said that an app:accept value of "entry" is		Collection." to 9.6; said that an app:accept value of "entry" is
	equivalent to "application/atom+xml;type=entry"; double-check spec		equivalent to "application/atom+xml;type=entry"; double-check spec
	terms; Member Entry resource -> Entry Resource; Added MLE, Entry		terms; Member Entry resource -> Entry Resource; Added MLE, Entry
	skipping to change at page 67, line 18		skipping to change at page 66, line 18
	IBM		IBM
	4205 South Miama Blvd.		4205 South Miama Blvd.
	Research Triangle Park, NC 27709		Research Triangle Park, NC 27709
	US		US
	Phone: +1 919 272 3764		Phone: +1 919 272 3764
	Email: joe@bitworking.org		Email: joe@bitworking.org
	URI: http://ibm.com/		URI: http://ibm.com/
	Bill de hOra (editor)		Bill de hOra (editor)
	Propylon Ltd.
	45 Blackbourne Square, Rathfarnham Gate
	Dublin, Dublin D14
	IE
	Phone: +353-1-4927444
	Email: bill@dehora.net		Email: bill@dehora.net
	URI: http://www.propylon.com/		URI: http://dehora.net/
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
End of changes. 49 change blocks.
	138 lines changed or deleted		172 lines changed or added
This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/