draft-ietf-atompub-protocol-16.txt		draft-ietf-atompub-protocol-17.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: December 29, 2007 June 27, 2007		Expires: January 10, 2008 July 09, 2007
	The Atom Publishing Protocol		The Atom Publishing Protocol
	draft-ietf-atompub-protocol-16.txt		draft-ietf-atompub-protocol-17.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 34		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 December 29, 2007.		This Internet-Draft will expire on January 10, 2008.
	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 43, 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
	specification defines an optional "type" parameter used to		specification defines a "type" parameter used to differentiate the
	differentiate the two types of Atom documents.		two types of Atom documents.
	12.1. The 'type' parameter		12.1. The 'type' parameter
	This specification 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
	skipping to change at page 45, line 11		skipping to change at page 45, line 11
	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 connection made with		Authentication [RFC2617] in conjunction with a connection made with
	TLS 1.0 [RFC2246] or a subsequent standards-track version of TLS,		TLS 1.0 [RFC2246] or a subsequent standards-track version of TLS,
	supporting the conventions for using HTTP over TLS described in		supporting the conventions for using HTTP over TLS described in
	[RFC2818]. At a minimum, client and server implementations MUST be		[RFC2818].
	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.
	skipping to change at page 47, line 22		skipping to change at page 47, line 22
	the contents of an Entry Document before publishing it, signatures		the contents of an Entry Document before publishing it, signatures
	within an entry are only likely to be useful to the server to which		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		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 be valid when viewed by a third party, or even that the server
	will publish the client's signature.		will publish the client's signature.
	A server is allowed to strip client-applied signatures, to strip		A server is allowed to strip client-applied signatures, to strip
	client-applied signatures and then re-sign with its own public key,		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		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		third party of a signature applied by a server is the same as a
	signature from anyone, as described in [RFC4287]. It is recommended		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		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		Document that was signed by the client should strip that signature
	before publishing the entry in order to prevent third parties from		before publishing the entry in order to prevent third parties from
	trying to interpret a signature that cannot be validated.		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.
End of changes. 7 change blocks.
	12 lines changed or deleted		8 lines changed or added
This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/