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 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.
End of changes. 5 change blocks.
	9 lines changed or deleted		5 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/