< 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/