draft-ietf-atompub-protocol-00.txt		draft-ietf-atompub-protocol-01.txt
	Network Working Group J. Gregorio, Ed.		Network Working Group J. Gregorio, Ed.
	Internet-Draft BitWorking, Inc		Internet-Draft BitWorking, Inc
	Expires: December 30, 2004 R. Sayre, Ed.		Expires: January 17, 2005 R. Sayre, Ed.
	Boswijck Memex Consulting		Boswijck Memex Consulting
	July 1, 2004		July 19, 2004
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-00.txt		draft-ietf-atompub-protocol-01.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, I certify that any applicable		By submitting this Internet-Draft, I certify that any applicable
	patent or other IPR claims of which I am aware have been disclosed,		patent or other IPR claims of which I am aware have been disclosed,
	and any of which I become aware will be disclosed, in accordance with		and any of which I become aware will be disclosed, in accordance with
	RFC 3668.		RFC 3668.
	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 December 30, 2004.		This Internet-Draft will expire on January 17, 2005.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2004). All Rights Reserved.		Copyright (C) The Internet Society (2004). All Rights Reserved.
	Abstract		Abstract
	This memo presents a protocol for using XML (Extensible Markup		This memo presents a protocol for using XML (Extensible Markup
	Language) and HTTP (HyperText Transport Protocol) to edit content.		Language) and HTTP (HyperText Transport Protocol) to edit content.
	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 belonging to periodically		publishing and editing Web resources belonging to periodically
	updated websites. The protocol at its core is the HTTP transport of		updated websites. The protocol at its core is the HTTP transport of
	Atom-formatted representations. The Atom format is documented in the		Atom-formatted representations. The Atom format is documented in the
	Atom Syndication Format 0.3 PRE-DRAFT		Atom Syndication Format (draft-ietf-atompub-format-00.txt).
	(http://www.mnot.net/drafts/draft-nottingham-atom-format-02.html).
	To provide feedback on this Internet-Draft, join the atom-syntax		Editorial Note
	mailing list (http://www.imc.org/atom-syntax/index.html).
			To provide feedback on this Internet-Draft, join the
			<http://www.imc.org/atom-syntax/index.html>.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4		1.1 Notational Conventions . . . . . . . . . . . . . . . . . . 4
	1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
	2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4		2. The Atom Publishing Protocol Model . . . . . . . . . . . . . 4
	3. Functional Specification . . . . . . . . . . . . . . . . . . 5		3. Functional Specification . . . . . . . . . . . . . . . . . . 5
	3.1 PostURI . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1 PostURI . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1.1 Locating the PostURI . . . . . . . . . . . . . . . . . 5		3.1.1 Locating the PostURI . . . . . . . . . . . . . . . . . 5
	3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 5		3.1.2 Request . . . . . . . . . . . . . . . . . . . . . . . 5
	3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5		3.1.3 Response . . . . . . . . . . . . . . . . . . . . . . . 5
	3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.2 EditURI . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 7		3.2.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . 7		3.2.2 Request . . . . . . . . . . . . . . . . . . . . . . . 7
	3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.3 FeedURI . . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 8		3.3.1 Locating . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 8		3.3.2 Request . . . . . . . . . . . . . . . . . . . . . . . 9
	3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 8		3.3.3 Response . . . . . . . . . . . . . . . . . . . . . . . 9
	3.4 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.4 Link Tag . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.4.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 8		3.4.1 rel . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.4.2 href . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4.3 title . . . . . . . . . . . . . . . . . . . . . . . . 9		3.4.3 title . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.4.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.4.4 type . . . . . . . . . . . . . . . . . . . . . . . . . 10
	3.5 Atom Request and Response Body Constraints . . . . . . . . 9		3.5 Atom Request and Response Body Constraints . . . . . . . . 11
	3.5.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.5.1 id . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.5.2 link . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 10		3.5.3 title . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.4 summary . . . . . . . . . . . . . . . . . . . . . . . 10		3.5.4 summary . . . . . . . . . . . . . . . . . . . . . . . 11
	3.5.5 content . . . . . . . . . . . . . . . . . . . . . . . 10		3.5.5 content . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 11		3.5.6 issued . . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5.7 modified . . . . . . . . . . . . . . . . . . . . . . . 11		3.5.7 modified . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5.8 created . . . . . . . . . . . . . . . . . . . . . . . 11		3.5.8 created . . . . . . . . . . . . . . . . . . . . . . . 12
	3.5.9 author . . . . . . . . . . . . . . . . . . . . . . . . 11		3.5.9 author . . . . . . . . . . . . . . . . . . . . . . . . 13
	3.5.10 contributor . . . . . . . . . . . . . . . . . . . . 12		3.5.10 contributor . . . . . . . . . . . . . . . . . . . . 13
	3.5.11 generator . . . . . . . . . . . . . . . . . . . . . 12		3.5.11 generator . . . . . . . . . . . . . . . . . . . . . 13
	4. Security Considerations . . . . . . . . . . . . . . . . . . 12		3.6 Securing the Atom Protocol . . . . . . . . . . . . . . . . 13
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 13		3.6.1 [@@TBD@@ CGI Authentication] . . . . . . . . . . . . . 14
	6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 13		4. Security Considerations . . . . . . . . . . . . . . . . . . 14
	6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 13		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 14
	6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 13		6. Appendix A - SOAP Enabling . . . . . . . . . . . . . . . . . 15
	7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 13		6.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 13		6.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 13		7. Appendix B - Examples . . . . . . . . . . . . . . . . . . . 15
	8. Revision History . . . . . . . . . . . . . . . . . . . . . . 14		7.1 Example for a weblog . . . . . . . . . . . . . . . . . . . 15
	9. Normative References . . . . . . . . . . . . . . . . . . . . 15		7.2 Example for a wiki . . . . . . . . . . . . . . . . . . . . 15
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 15		8. Revision History . . . . . . . . . . . . . . . . . . . . . . 15
	Intellectual Property and Copyright Statements . . . . . . . 16		9. Normative References . . . . . . . . . . . . . . . . . . . . 17
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 17
			Intellectual Property and Copyright Statements . . . . . . . 19
	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.		publishing and editing Web resources using HTTP [RFC2616] and XML.
	1.1 Notational Conventions		1.1 Notational Conventions
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", the and "OPTIONAL" in		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	this document are to be interpreted as described in RFC2119.		document are to be interpreted as described in [RFC2119].
	1.2 Terminology		1.2 Terminology
	Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this		Atom Entry: An Atom Entry is a fragment of a full Atom feed. In this
	case, the fragment is a single 'entry' element and all its child		case, the fragment is a single 'entry' element and all its child
	elements. Each Atom Entry describes a single Web resource,		elements. Each Atom Entry describes a single Web resource,
	providing metadata and optionally a textual representation of that		providing metadata and optionally a textual representation of that
	resource.		resource.
	PostURI: A URI that is used to create new resources. POSTing an Atom		PostURI: A URI that is used to create new resources. POSTing an Atom
	Entry to this URI will create a new resource.		Entry to this URI will create a new resource.
	skipping to change at page 5, line 46		skipping to change at page 5, line 46
	href="URI for Posting goes here"		href="URI for Posting goes here"
	title="The name of the site.">		title="The name of the site.">
	3.1.2 Request		3.1.2 Request
	The request contains a filled-in Atom entry, subject to the		The request contains a filled-in Atom entry, subject to the
	constraints in section Section 3.5.		constraints in section Section 3.5.
	3.1.3 Response		3.1.3 Response
	The possible status codes from a POST are 201, 303, 400, 401, 404,		The possible status codes from a POST are 201, 303, 400, 404, 410 and
	410 and 500.		500.
	3.1.3.1 Response code 201		3.1.3.1 Response code 201
	Response includes a Location: header with the URI of the created		Response includes a Location: header with the URI of the created
	resource, i.e. the URI used to edit the entry, as opposed to the URI		resource, i.e. the URI used to edit the entry, as opposed to the URI
	used to display the content. The body of the response will contain		used to display the content. The body of the response will contain
	the entry "filled-in" with time stamps and any other data the server		the entry "filled-in" with time stamps and any other data the server
	chooses to reveal. This must contain enough information to enable a		chooses to reveal. This must contain enough information to enable a
	client to issue a subsequent PUT to this location. Note that the		client to issue a subsequent PUT to this location. Note that the
	server may chose to omit the content in the response, particularly if		server may chose to omit the content in the response, particularly if
	skipping to change at page 6, line 21		skipping to change at page 6, line 21
	3.1.3.2 Response code 303		3.1.3.2 Response code 303
	The body of this response does not contain the filled-in Entry, but		The body of this response does not contain the filled-in Entry, but
	the filled-in Entry can be found under a different URI and can be		the filled-in Entry can be found under a different URI and can be
	retrieved using a GET method on that resource. The URI SHOULD be		retrieved using a GET method on that resource. The URI SHOULD be
	given by the Location field in the response.		given by the Location field in the response.
	3.1.3.3 Response code 400		3.1.3.3 Response code 400
	Indicates that the server believes that that data sent constitutes an		Indicates that the server believes that the data sent constitutes an
	invalid request. A short description of the error will appear on the		invalid request. As an example, the data posted may not be
	<http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1>		well-formed XML. The server SHOULD include an entity containing an
	itself. A longer description will appear in the body.		explanation of the error situation, and whether it is a temporary or
			permanent condition.
	3.1.3.4 Response code 500		3.1.3.4 Response code 500
	Indicates that the server detected an internal error on the server		Indicates that the server detected an internal error on the server
	processing this request (such as an unhandled exception). A short		processing this request (such as an unhandled exception). The server
	description of the error will appear on the		SHOULD include an entity containing an explanation of the error
	<http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1>		situation, and whether it is a temporary or permanent condition.
	itself. A longer description will appear in the body.
	3.2 EditURI		3.2 EditURI
	An EditURI is used to edit a single entry. Each entry that is		An EditURI is used to edit a single entry. Each entry that is
	editable MUST have a unique URI. This URI supports both GET and PUT		editable MUST have a unique URI. This URI supports both GET and PUT
	and they are used in tandem for an editing cycle. The client GETs		and they are used in tandem for an editing cycle. The client GETs
	the representation which is formatted as an Atom entry. The client		the representation which is formatted as an Atom entry. The client
	may then update the entry and then PUT it back to the same URI. The		may then update the entry and then PUT it back to the same URI. The
	PUT will cause all the related resources to be updated, for example,		PUT will cause all the related resources to be updated, for example,
	the HTML representation.		the HTML representation.
	skipping to change at page 7, line 29		skipping to change at page 7, line 29
	title="Readable desc of the entry.">		title="Readable desc of the entry.">
	Note: The critical characteristic of this link tag is the @rel of		Note: The critical characteristic of this link tag is the @rel of
	'service.edit' and the @type of 'application/atom+xml'.		'service.edit' and the @type of 'application/atom+xml'.
	3.2.2 Request		3.2.2 Request
	A PUT request, and a GET response both contain a filled-in Atom		A PUT request, and a GET response both contain a filled-in Atom
	entry, subject to the constraints in section Section 3.5.		entry, subject to the constraints in section Section 3.5.
			The expected status codes from a GET are 200, 301, 307, and 500.
			400, 404, and 410 are also possible.
			The expected status codes from a PUT are 2xx, 301, 307, 500 and 501.
			400, 404, and 410 are also possible.
			3.2.2.1 Successful Requests
			Servers MUST indicate successful GET requests with a 200 response.
			Servers MUST indicate successful PUT requests with a 2xx response.
			Servers MAY include additional information in the PUT response.
			Clients SHOULD NOT expect any additional information in a PUT
			response.
			3.2.2.2 Response code 301
			The entry has moved permanently, the new URI is given in the Location
			header. The client SHOULD retry the GET using the URI returned in
			the Location header. When a PUT operation is attempted the user
			agent should prompt the user before attempting the PUT on the URI
			returned in the Location header.
			3.2.2.3 Response code 307
			The entry has moved temporarily, the new URI is given in the Location
			header. The client SHOULD retry the GET using the URI returned in
			the Location header. When a PUT operation is attempted the user
			agent should prompt the user before attempting the PUT on the URI
			returned in the Location header.
			3.2.2.4 Response code 401
			Indicates that the server believes that the data sent constitutes an
			invalid request. As an example, the data posted may not be
			well-formed XML. The server SHOULD include an entity containing an
			explanation of the error situation, and whether it is a temporary or
			permanent condition.
			3.2.2.5 Response code 410
			Indicates that the requested resource is gone permanently. The
			client SHOULD NOT repeat the request again.
			3.2.2.6 Response code 500
			Indicates that the server detected an internal error on the server
			processing this request (such as an unhandled exception). The server
			SHOULD include an entity containing an explanation of the error
			situation, and whether it is a temporary or permanent condition.
	3.3 FeedURI		3.3 FeedURI
	The FeedURI is used to retrieve a representation in Atom format.		The FeedURI is used to retrieve a representation in Atom format.
	Note that this feed is different from a typical Atom feed in that it		Note that this feed is different from a typical Atom feed in that it
	contains "link" elements for navigating and manipulating the content		contains "link" elements for navigating and manipulating the content
	of the site. For example there should be a "link" element with		of the site. For example there should be a "link" element with
	rel="next" whose URI points to the next block of entries on the site.		rel="next" whose URI points to the next block of entries on the site.
	Similarly, the feed element can contain a "link" element with		Similarly, the feed element can contain a "link" element with
	rel="service.post", the URI of which is a PostURI. Individual		rel="service.post", the URI of which is a PostURI. Individual
	entries should contain "link" elements with rel="service.edit" whose		entries should contain "link" elements with rel="service.edit" whose
	URIs are EditURIs.		URIs are EditURIs.
			This document only uses some of the methods available for each type
			of URI. For example, the only method described by this document for
			the FeedURI is GET. Any other method may be supported by the URI
			types described, but defining their behavior is beyond the scope of
			this document. In this light you may notice that the PostURI only
			supports the POST method. It is possible, and allowable, that for
			some implementations the PostURI and the FeedURI are the same URI.
	@@ Editor's Note: @@ Note that the "service.feed" takes the place of		@@ Editor's Note: @@ Note that the "service.feed" takes the place of
	the Introspection File and the Search facet in previous versions of		the Introspection File and the Search facet in previous versions of
	the specification. That is, facet discovery, which was previously		the specification. That is, facet discovery, which was previously
	done by inspecting the Introspection file is now done by looking for		done by inspecting the Introspection file is now done by looking for
	"link" tags with an attribute "rel" set to "service.[something]" in		"link" tags with an attribute "rel" set to "service.[something]" in
	the "service.feed" file. At the same time the same representation		the "service.feed" file. At the same time the same representation
	replaces the search facet by having "link" tags that point to other		replaces the search facet by having "link" tags that point to other
	feeds using well knows 'rel' attribute values such as 'next' and		feeds using well-known 'rel' attribute values such as 'next' and
	'prev', or the search can branch in multiple directions by specifying		'prev', or the search can branch in multiple directions by specifying
	multiple link tags with rel="service.feed" and having differing title		multiple link tags with rel="service.feed" and having differing title
	attributes that announce the kind of search results in that feed.		attributes that announce the kind of search results in that feed.
	3.3.1 Locating		3.3.1 Locating
	A link tag of the following format points to the FeedURI.		A link tag of the following format points to the FeedURI.
	<link rel="service.feed"		<link rel="service.feed"
	type="application/atom+xml"		type="application/atom+xml"
	skipping to change at page 8, line 27		skipping to change at page 9, line 39
	for this URI.		for this URI.
	3.3.3 Response		3.3.3 Response
	The expected status codes from a GET are 200, 301, 307, and 500.		The expected status codes from a GET are 200, 301, 307, and 500.
	401, 404, and 410 are also possible.		401, 404, and 410 are also possible.
	3.3.3.1 Response code 301		3.3.3.1 Response code 301
	The Feed has moved permanently, the new URI is given in the Location		The Feed has moved permanently, the new URI is given in the Location
	header.		header. The client SHOULD do a GET on the URI returned in the
			Location header.
	3.3.3.2 Response code 307		3.3.3.2 Response code 307
	The Feed has moved temporarily, the new URI is given in the Location		The Feed has moved temporarily, the new URI is given in the Location
	header.		header. The client SHOULD do a GET on the URI returned in the
			Location header.
	3.4 Link Tag		3.4 Link Tag
	The link tag is used in both HTML and Atom formats. There are slight		The link tag is used in both HTML and Atom formats. There are slight
	differences between the two usages. Here are the commonalities,		differences between the two usages. Here are the commonalities,
	differences, and a list of well-known values for the rel attribute.		differences, and a list of well-known values for the rel attribute.
	<http://www.w3.org/TR/html4/struct/links.html#edef-LINK> appears in		<http://www.w3.org/TR/html4/struct/links.html#edef-LINK> appears in
	the 'head' of the document. The 'head' section only allows a linear		the 'head' of the document. The 'head' section only allows a linear
	list of 'link' tags. The Atom format allows 'link' tags as children		list of 'link' tags. The Atom format allows 'link' tags as children
	skipping to change at page 12, line 28		skipping to change at page 13, line 42
	3.5.11 generator		3.5.11 generator
	PostURI MUST be present and contain a URI. The value of the element		PostURI MUST be present and contain a URI. The value of the element
	indicates the code base used to create this request. MUST also		indicates the code base used to create this request. MUST also
	have an attribute 'version' with a version number.		have an attribute 'version' with a version number.
	FeedURI MUST NOT be present.		FeedURI MUST NOT be present.
	EditURI		EditURI
	GET MUST NOT be present.		GET MUST NOT be present.
	PUT MUST NOT be present.		PUT MUST NOT be present.
			3.6 Securing the Atom Protocol
			All instances of publishing Atom entries SHOULD be protected by
			authentication to prevent posting or editing by unknown sources.
			Atom servers and clients MUST support one of the following
			authentication mechanisms, and SHOULD support both.
			o HTTP Digest Authentication [RFC2617]
			o [@@TBD@@ CGI Authentication ref]
			Atom servers and clients MAY support encryption of the Atom session
			using TLS [RFC2246].
			There are cases where an authentication mechanism may not be
			required, such as a publicly editable Wiki, or when using the PostURI
			to post comments to a site that does not require authentication to
			create comments.
			3.6.1 [@@TBD@@ CGI Authentication]
			This authentication method is included as part of the protocol to
			allow Atom servers and clients that cannot use HTTP Digest
			Authentication but where the user can both insert its own HTTP
			headers and create a CGI program to authenticate entries to the
			server. This scenario is common in environments where the user
			cannot control what services the server employs, but the user can
			write their own HTTP services.
	4. Security Considerations		4. Security Considerations
	Because Atom is a publishing protocol, it is important that only		Because Atom is a publishing protocol, it is important that only
	authorized users can create and edit entries. The security of Atom		authorized users can create and edit entries.
	is based on HTTP Digest Authentication and/or the WSSE-style
	authentication described in this document. Any weaknesses in either
	of these two protocols will obviously affect the security of the Atom
	publishing protocol.
	Both HTTP Digest Authentication and the WSSE-style authentication		The security of Atom is based on HTTP Digest Authentication and/or
	described in this document are susceptible to dictionary-based		[@@TBD@@ CGI Authentication]. Any weaknesses in either of these
	attacks on the shared secret. If the shared secret is a password		authentication schemes will obviously affect the security of the Atom
	(instead of a random string with sufficient entropy), an attacker can		Publishing Protocol.
	determine the secret by exhaustively comparing the authenticating
	string with hashed results of the public string and dictionary		Both HTTP Digest Authentication and [@@TBD@@ CGI Authentication] are
	entries.		susceptible to dictionary-based attacks on the shared secret. If the
			shared secret is a password (instead of a random string with
			sufficient entropy), an attacker can determine the secret by
			exhaustively comparing the authenticating string with hashed results
			of the public string and dictionary entries.
	See RFC 2617 for more detailed description of the security properties		See RFC 2617 for more detailed description of the security properties
	of HTTP Digest Authentication.		of HTTP Digest Authentication.
	@@TBD@@ Talk here about using HTTP basic and digest authentication.		@@TBD@@ Talk here about using HTTP basic and digest authentication.
	@@TBD@@ Talk here about denial of service attacks using large XML		@@TBD@@ Talk here about denial of service attacks using large XML
	files, or the billion laughs DTD attack.		files, or the billion laughs DTD attack.
	5. IANA Considerations		5. IANA Considerations
	skipping to change at page 14, line 7		skipping to change at page 15, line 52
	the 'introspection' file. 1. Creating a new entry 2. Finding an		the 'introspection' file. 1. Creating a new entry 2. Finding an
	old entry 3. editing an old entry 4. commenting on a entry (via		old entry 3. editing an old entry 4. commenting on a entry (via
	HTML and Atom)		HTML and Atom)
	7.2 Example for a wiki		7.2 Example for a wiki
	Fill this in like above but for a wiki.		Fill this in like above but for a wiki.
	8. Revision History		8. Revision History
			draft-ietf-atompub-protocol-01 - Added in sections on Responses for
			the EditURI. Allow 2xx for response to EditURI PUTs. Elided all
			mentions of WSSE. Started adding in some normative references.
			Added the section "Securing the Atom Protocol". Clarified that it is
			possible that the PostURI and FeedURI could be the same URI. Cleaned
			up descriptions for Response codes 400 and 500.
	Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and		Rev draft-ietf-atompub-protocol-00 - 5Jul2004 - Renamed the file and
	re-titled the document to conform to IETF submission guidelines.		re-titled the document to conform to IETF submission guidelines.
	Changed MIME type to match the one selected for the Atom format.		Changed MIME type to match the one selected for the Atom format.
	Numerous typographical fixes. We used to have two 'Introduction'		Numerous typographical fixes. We used to have two 'Introduction'
	sections. One of them was moved into the Abstract the other absorbed		sections. One of them was moved into the Abstract the other absorbed
	the Scope section. IPR and copyright notifications were added.		the Scope section. IPR and copyright notifications were added.
	Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and		Rev 09 - 10Dec2003 - Added the section on SOAP enabled clients and
	servers.		servers.
	skipping to change at page 15, line 14		skipping to change at page 17, line 18
	changed to application/atom+xml.		changed to application/atom+xml.
	Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more		Rev 01 - 5Jul2003 - Renamed from EchoAPI.html to follow the more
	commonly used format: draft-gregorio-NN.html. Renamed all references		commonly used format: draft-gregorio-NN.html. Renamed all references
	to URL to URI. Broke out introspection into it's own section. Added		to URL to URI. Broke out introspection into it's own section. Added
	the Revision History section. Added more to the warning that the		the Revision History section. Added more to the warning that the
	example URIs are not normative.		example URIs are not normative.
	9 Normative References		9 Normative References
	[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	June 1999.		Requirement Levels", BCP 14, RFC 2119, March 1997.
			[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
			RFC 2246, January 1999.
			[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
			Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
			Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
			[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
			Leach, P., Luotonen, A. and L. Stewart, "HTTP
			Authentication: Basic and Digest Access Authentication",
			RFC 2617, June 1999.
	Authors' Addresses		Authors' Addresses
	Joe Gregorio (editor)		Joe Gregorio (editor)
	BitWorking, Inc		BitWorking, Inc
	1002 Heathwood Dairy Rd.		1002 Heathwood Dairy Rd.
	Apex, NC 27502		Apex, NC 27502
	US		US
	Phone: +1 919 272 3764		Phone: +1 919 272 3764
End of changes.
This html diff was produced by rfcdiff 1.12, available from http://www.levkowetz.com/ietf/tools/rfcdiff/