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/ |