--- 1/draft-ietf-atompub-protocol-15.txt 2007-07-05 21:12:05.000000000 +0200 +++ 2/draft-ietf-atompub-protocol-16.txt 2007-07-05 21:12:05.000000000 +0200 @@ -1,19 +1,18 @@ Network Working Group J. Gregorio, Ed. Internet-Draft IBM Intended status: Standards Track B. de hOra, Ed. -Expires: November 23, 2007 Propylon Ltd. - May 22, 2007 +Expires: December 29, 2007 June 27, 2007 The Atom Publishing Protocol - draft-ietf-atompub-protocol-15.txt + draft-ietf-atompub-protocol-16.txt Status of this Memo By submitting this Internet-Draft, each author represents that any 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 aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -24,21 +23,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on November 23, 2007. + This Internet-Draft will expire on December 29, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is @@ -70,83 +69,83 @@ 5.2. Listing Collection Members . . . . . . . . . . . . . . . . 14 5.3. Creating a Resource . . . . . . . . . . . . . . . . . . . 15 5.4. Editing a Resource . . . . . . . . . . . . . . . . . . . . 15 5.4.1. Retrieving a Resource . . . . . . . . . . . . . . . . 15 5.4.2. Editing a Resource . . . . . . . . . . . . . . . . . . 16 5.4.3. Deleting a Resource . . . . . . . . . . . . . . . . . 16 5.5. Use of HTTP Response codes . . . . . . . . . . . . . . . . 16 6. Protocol Documents . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Document Types . . . . . . . . . . . . . . . . . . . . . . 18 6.2. Document Extensibility . . . . . . . . . . . . . . . . . . 18 - 7. Category Documents . . . . . . . . . . . . . . . . . . . . . . 20 - 7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 7.2. Element Definitions . . . . . . . . . . . . . . . . . . . 20 - 7.2.1. The "app:categories" element . . . . . . . . . . . . . 20 - 8. Service Documents . . . . . . . . . . . . . . . . . . . . . . 22 - 8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . . . . 22 - 8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 23 - 8.3. Element Definitions . . . . . . . . . . . . . . . . . . . 24 - 8.3.1. The "app:service" Element . . . . . . . . . . . . . . 24 - 8.3.2. The "app:workspace" Element . . . . . . . . . . . . . 24 - 8.3.3. The "app:collection" Element . . . . . . . . . . . . . 25 - 8.3.4. The "app:accept" Element . . . . . . . . . . . . . . . 26 - 8.3.5. Usage in Atom Feed Documents . . . . . . . . . . . . . 26 - 8.3.6. The "app:categories" Element . . . . . . . . . . . . . 26 - 9. Creating and Editing Resources . . . . . . . . . . . . . . . . 28 - 9.1. Member URIs . . . . . . . . . . . . . . . . . . . . . . . 28 - 9.2. Creating Resources with POST . . . . . . . . . . . . . . . 28 - 9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 29 - 9.3. Editing Resources with PUT . . . . . . . . . . . . . . . . 30 - 9.4. Deleting Resources with DELETE . . . . . . . . . . . . . . 30 - 9.5. Caching and entity tags . . . . . . . . . . . . . . . . . 30 - 9.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 30 - 9.6. Media Resources and Media Link Entries . . . . . . . . . . 32 - 9.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 33 - 9.7. The Slug: Header . . . . . . . . . . . . . . . . . . . . . 39 - 9.7.1. Slug: Header syntax . . . . . . . . . . . . . . . . . 40 - 9.7.2. Example . . . . . . . . . . . . . . . . . . . . . . . 40 - 10. Listing Collections . . . . . . . . . . . . . . . . . . . . . 41 - 10.1. Collection partial lists . . . . . . . . . . . . . . . . . 41 - 10.2. The "app:edited" Element . . . . . . . . . . . . . . . . . 42 - 11. Atom Format Link Relation Extensions . . . . . . . . . . . . . 43 - 11.1. The "edit" Link Relation . . . . . . . . . . . . . . . . . 43 - 11.2. The "edit-media" Link Relation . . . . . . . . . . . . . . 43 - 12. The Atom Format Type Parameter . . . . . . . . . . . . . . . . 44 - 12.1. The 'type' parameter . . . . . . . . . . . . . . . . . . . 44 - 12.1.1. Conformance . . . . . . . . . . . . . . . . . . . . . 44 - 13. Atom Publishing Controls . . . . . . . . . . . . . . . . . . . 45 - 13.1. The "app:control" Element . . . . . . . . . . . . . . . . 45 - 13.1.1. The "app:draft" Element . . . . . . . . . . . . . . . 45 - 14. Securing the Atom Publishing Protocol . . . . . . . . . . . . 46 - 15. Security Considerations . . . . . . . . . . . . . . . . . . . 47 - 15.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 47 - 15.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 47 - 15.3. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . 47 - 15.4. Linked Resources . . . . . . . . . . . . . . . . . . . . . 47 - 15.5. Digital Signatures and Encryption . . . . . . . . . . . . 47 + 7. Category Documents . . . . . . . . . . . . . . . . . . . . . . 19 + 7.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.2. Element Definitions . . . . . . . . . . . . . . . . . . . 19 + 7.2.1. The "app:categories" element . . . . . . . . . . . . . 19 + 8. Service Documents . . . . . . . . . . . . . . . . . . . . . . 21 + 8.1. Workspaces . . . . . . . . . . . . . . . . . . . . . . . . 21 + 8.2. Example . . . . . . . . . . . . . . . . . . . . . . . . . 22 + 8.3. Element Definitions . . . . . . . . . . . . . . . . . . . 23 + 8.3.1. The "app:service" Element . . . . . . . . . . . . . . 23 + 8.3.2. The "app:workspace" Element . . . . . . . . . . . . . 23 + 8.3.3. The "app:collection" Element . . . . . . . . . . . . . 24 + 8.3.4. The "app:accept" Element . . . . . . . . . . . . . . . 25 + 8.3.5. Usage in Atom Feed Documents . . . . . . . . . . . . . 25 + 8.3.6. The "app:categories" Element . . . . . . . . . . . . . 25 + 9. Creating and Editing Resources . . . . . . . . . . . . . . . . 27 + 9.1. Member URIs . . . . . . . . . . . . . . . . . . . . . . . 27 + 9.2. Creating Resources with POST . . . . . . . . . . . . . . . 27 + 9.2.1. Example . . . . . . . . . . . . . . . . . . . . . . . 28 + 9.3. Editing Resources with PUT . . . . . . . . . . . . . . . . 29 + 9.4. Deleting Resources with DELETE . . . . . . . . . . . . . . 29 + 9.5. Caching and entity tags . . . . . . . . . . . . . . . . . 29 + 9.5.1. Example . . . . . . . . . . . . . . . . . . . . . . . 29 + 9.6. Media Resources and Media Link Entries . . . . . . . . . . 31 + 9.6.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.7. The Slug: Header . . . . . . . . . . . . . . . . . . . . . 38 + 9.7.1. Slug: Header syntax . . . . . . . . . . . . . . . . . 39 + 9.7.2. Example . . . . . . . . . . . . . . . . . . . . . . . 39 + 10. Listing Collections . . . . . . . . . . . . . . . . . . . . . 40 + 10.1. Collection partial lists . . . . . . . . . . . . . . . . . 40 + 10.2. The "app:edited" Element . . . . . . . . . . . . . . . . . 41 + 11. Atom Format Link Relation Extensions . . . . . . . . . . . . . 42 + 11.1. The "edit" Link Relation . . . . . . . . . . . . . . . . . 42 + 11.2. The "edit-media" Link Relation . . . . . . . . . . . . . . 42 + 12. The Atom Format Type Parameter . . . . . . . . . . . . . . . . 43 + 12.1. The 'type' parameter . . . . . . . . . . . . . . . . . . . 43 + 12.1.1. Conformance . . . . . . . . . . . . . . . . . . . . . 43 + 13. Atom Publishing Controls . . . . . . . . . . . . . . . . . . . 44 + 13.1. The "app:control" Element . . . . . . . . . . . . . . . . 44 + 13.1.1. The "app:draft" Element . . . . . . . . . . . . . . . 44 + 14. Securing the Atom Publishing Protocol . . . . . . . . . . . . 45 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 46 + 15.1. Denial of Service . . . . . . . . . . . . . . . . . . . . 46 + 15.2. Replay Attacks . . . . . . . . . . . . . . . . . . . . . . 46 + 15.3. Spoofing Attacks . . . . . . . . . . . . . . . . . . . . . 46 + 15.4. Linked Resources . . . . . . . . . . . . . . . . . . . . . 46 + 15.5. Digital Signatures and Encryption . . . . . . . . . . . . 46 15.6. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 47 - 15.7. Code Injection and Cross Site Scripting . . . . . . . . . 48 - 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 - 16.1. Content-type registration for 'application/atomcat+xml' . 49 - 16.2. Content-type registration for 'application/atomsvc+xml' . 50 - 16.3. Header field registration for 'SLUG' . . . . . . . . . . . 51 - 16.4. The Link Relation registration "edit" . . . . . . . . . . 52 - 16.5. The Link Relation registration "edit-media" . . . . . . . 52 - 16.6. The Atom Format Media Type Parameter . . . . . . . . . . . 52 - 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 - 17.1. Normative References . . . . . . . . . . . . . . . . . . . 53 - 17.2. Informative References . . . . . . . . . . . . . . . . . . 54 - Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 56 - Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 57 - Appendix C. Revision History . . . . . . . . . . . . . . . . . . 63 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 67 - Intellectual Property and Copyright Statements . . . . . . . . . . 68 + 15.7. Code Injection and Cross Site Scripting . . . . . . . . . 47 + 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 + 16.1. Content-type registration for 'application/atomcat+xml' . 48 + 16.2. Content-type registration for 'application/atomsvc+xml' . 49 + 16.3. Header field registration for 'SLUG' . . . . . . . . . . . 50 + 16.4. The Link Relation registration "edit" . . . . . . . . . . 51 + 16.5. The Link Relation registration "edit-media" . . . . . . . 51 + 16.6. The Atom Format Media Type Parameter . . . . . . . . . . . 51 + 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 + 17.1. Normative References . . . . . . . . . . . . . . . . . . . 52 + 17.2. Informative References . . . . . . . . . . . . . . . . . . 53 + Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 55 + Appendix B. RELAX NG Compact Schema . . . . . . . . . . . . . . . 56 + Appendix C. Revision History . . . . . . . . . . . . . . . . . . 62 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 66 + Intellectual Property and Copyright Statements . . . . . . . . . . 67 1. Introduction The Atom Publishing Protocol is an application-level protocol for publishing and editing Web Resources using HTTP [RFC2616] and XML 1.0 [REC-xml]. The protocol supports the creation of Web Resources and provides facilities for: o Collections: Sets of Resources, which can be retrieved in whole or in part. @@ -189,21 +188,21 @@ 2.1.3. Use of xml:base and xml:lang XML elements defined by this specification MAY have an xml:base attribute [REC-xmlbase]. When xml:base is used, it serves the function described in Section 5.1.1 of URI Generic Syntax [RFC3986], by establishing the base URI (or IRI) for resolving relative references found within the scope of the xml:base attribute. Any element defined by this specification MAY have an xml:lang attribute, whose content indicates the natural language for the - element and its descendents. Requirements regarding the content and + element and its descendants. Requirements regarding the content and interpretation of xml:lang are specified in Section 2.12 of XML 1.0 [REC-xml]. 3. Terminology For convenience, this protocol can be referred to as the "Atom Protocol" or "APP". The following terminology is used by this specification: o URI - A Uniform Resource Identifier as defined in [RFC3986]. In @@ -555,24 +554,21 @@ A Category Document (Section 7) contains lists of categories specified using the "atom:category" element from the Atom Syndication Format (see Section 4.2.2 of [RFC4287]). A Service Document (Section 8) groups available Collections into Workspaces. The namespace name [REC-xml-names] for either kind of document is: - http://purl.org/atom/app# - - [[anchor9: The namespace name 'http://purl.org/atom/app#' needs to be - updated throughout the document with the final URI upon publication]] + http://www.w3.org/2007/app Atom Publishing Protocol XML Documents MUST be "namespace-well- formed" as specified in Section 7 of [REC-xml-names]. This specification uses the prefix "app:" for the namespace name. The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the namespace name of the Atom Syndication Format [RFC4287]. These namespace prefixes are not semantically significant. This specification does not define any DTDs for Atom Protocol @@ -582,43 +578,43 @@ 6.2. Document Extensibility Unrecognized markup in an Atom Publishing Protocol document is considered "foreign markup" as defined in Section 6 of the Atom Syndication Format [RFC4287]. Foreign markup can be used anywhere within a Category or Service Document unless it is explicitly forbidden. Processors that encounter foreign markup MUST NOT stop processing and MUST NOT signal an error. Clients SHOULD preserve foreign markup when transmitting such documents. - The namespace name "http://purl.org/atom/app#" is reserved for + The namespace name "http://www.w3.org/2007/app" is reserved for forward compatible revisions of the Category and Service Document types - this does not exclude the addition of elements and attributes that might not be recognized by processors conformant to this specification. Such unrecognized markup from the - "http://purl.org/atom/app#" namespace MUST be treated as foreign + "http://www.w3.org/2007/app" namespace MUST be treated as foreign markup. 7. Category Documents Category Documents contain lists of categories described using the "atom:category" element from the Atom Syndication Format [RFC4287]. Categories can also appear in Service Documents, where they indicate the categories allowed in a Collection (see Section 8.3.6). Category Documents are identified with the "application/atomcat+xml" media type (see Section 16.1). 7.1. Example This Category Document contains atom:category elements, with the terms 'animal', 'vegetable', and 'mineral'. None of the categories use the "label" attribute defined in [RFC4287]. They all inherit the @@ -700,21 +696,21 @@ specification. This specification assigns no meaning to Workspaces; that is, a Workspace does not imply any specific processing assumptions. There is no requirement that a server support multiple Workspaces. In addition, a Collection MAY appear in more than one Workspace. 8.2. Example - Main Site My Blog Entries Note that the returned Entry contains a link with a relation of - "alternate" that points to the associated HTML page that was created. - This is not required by this specification, but is included to show + "alternate" that points to the associated HTML page that was created + - this is not required by this specification, but is included to show the kinds of changes a server can make to an Entry. 9.7. The Slug: Header Slug is an HTTP entity-header whose presence in a POST to a Collection constitutes a request by the client to use the header's value as part of any URIs that would normally used to retrieve the to-be-created Entry or Media resources. Servers MAY use the value of the Slug header when creating the Member @@ -1400,31 +1396,38 @@ Link Entry (see Section 9.6.). Servers MAY choose to ignore the Slug entity-header. Servers MAY alter the header value before using it. For instance, a server might filter out some characters or replace accented letters with non- accented ones, replace spaces with underscores, change case, and so on. 9.7.1. Slug: Header syntax - The syntax of this header MUST conform to the augmented BNF grammar - in section 2.1 of the HTTP/1.1 specification [RFC2616]. The TEXT - rule is described in section 2.2 of the same document. + The syntax of the Slug header is defined using the augmented BNF + syntax defined in Section 2.1 of [RFC2616]: - Slug = "Slug" ":" *TEXT + LWS = + slugtext = %x20-7E | LWS + Slug = "Slug" ":" *slugtext - The field-value of the Slug header is a percent-encoded utf-8 Unicode - string that does not contain CR or LF, where CR and LF are defined in - [RFC2616]. All non-ASCII characters in the utf-8 representation MUST - be percent-encoded according to the rules in Section 2.1 of - [RFC3986]. + The field-value is the percent-encoded value of the UTF-8 encoding of + the character sequence to be included (see Section 2.1 of [RFC3986] + for the definition of percent encoding, and [RFC3629] for the + definition of the UTF-8 encoding). + + Implementation note: to produce the field value from a character + sequence, first encode it using the UTF-8 encoding, then encode all + octets outside the ranges %20-24 and %26-7E using percent encoding + (%25 is the ASCII encoding of "%", thus it needs to be escaped). To + consume the field value first reverse the percent encoding, then run + the resulting octet sequence through a UTF-8 decoding process. 9.7.2. Example Here is an example of the Slug: header that uses percent-encoding to represent the Unicode character U+00E8 (LATIN SMALL LETTER E WITH GRAVE): POST /myblog/entries HTTP/1.1 Host: example.org Content-Type: image/png @@ -1562,210 +1565,246 @@ "hreflang" attributes then the client SHOULD pick the first "edit- media" link relation in document order. 12. The Atom Format Type Parameter The Atom Syndication Format [RFC4287] defines the "application/ atom+xml" media type to identify both Atom Feed and Atom Entry Documents. Implementation experience has demonstrated that Atom Feed and Entry Documents can have different processing models and that there are situations where they need to be differentiated. This - document defines an optional "type" parameter used to differentiate - the two types of Atom documents. + specification defines an optional "type" parameter used to + differentiate the two types of Atom documents. 12.1. The 'type' parameter - This document 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 of "entry" or "feed". Neither the parameter name nor its value are case sensitive. The value "entry" indicates that the media type identifies an Atom Entry Document. The root element of the document MUST be atom:entry. The value "feed" indicates that the media type identifies an Atom Feed Document. The root element of the document MUST be atom:feed. If not specified, the type is assumed to be unspecified, requiring Atom processors to examine the root element to determine the type of Atom document. 12.1.1. Conformance New specifications MAY require that the "type" parameter be used to identify the Atom Document type. Producers of Atom Entry Documents SHOULD use the "type" parameter regardless of whether or not it is - required. Producers of Atom Feed Documents MAY use the parameter. + mandatory. Producers of Atom Feed Documents MAY use the parameter. Atom processors that do not recognize the "type" parameter MUST ignore its value and examine the root element to determine the document type. Atom processors that do recognize the "type" parameter SHOULD detect and report inconsistencies between the parameter's value and the actual type of the document's root element. 13. Atom Publishing Controls This specification defines an Atom Format Structured Extension, as defined in Section 6 of [RFC4287], for publishing control within the - "http://purl.org/atom/app#" namespace. + "http://www.w3.org/2007/app" namespace. 13.1. The "app:control" Element - namespace app = "http://purl.org/atom/app#" + namespace app = "http://www.w3.org/2007/app" pubControl = element app:control { atomCommonAttributes, pubDraft? & extensionElement } pubDraft = element app:draft { "yes" | "no" } The "app:control" element MAY appear as a child of an atom:entry that is being created or updated via the Atom Publishing Protocol. The app:control element MUST appear only once in an Entry. The app: control element is considered foreign markup as defined in Section 6 of [RFC4287]. The app:control element and its child elements MAY be included in Atom Feed or Entry Documents. - The app:control element can contain an optional "app:draft" element - as defined below, and can contain extension elements as defined in - Section 6 of [RFC4287]. + The app:control element can contain an "app:draft" element as defined + below, and can contain extension elements as defined in Section 6 of + [RFC4287]. 13.1.1. The "app:draft" Element The inclusion of the "app:draft" element represents a request by the - client to control the visibility of a Member Resource. Server - support is optional and thus the app:draft element MAY be ignored by - the server. + client to control the visibility of a Member Resource. The app:draft + element MAY be ignored by the server. The number of app:draft elements in app:control MUST be zero or one. The content of an app:draft element MUST be one of "yes" or "no". If the element contains "no" this indicates a client request that the Member Resource be made publicly visible. If the app:draft element is not present then servers that support the extension MUST behave as though an app:draft element containing "no" was sent. 14. Securing the Atom Publishing Protocol The Atom Publishing Protocol is based on HTTP. Authentication requirements for HTTP are covered in Section 11 of [RFC2616]. 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 to trivial spoofing, denial of service, and defacement attacks. However, in some contexts, this is an acceptable risk. The type of authentication deployed is a local decision made by the server operator. Clients are likely to face authentication schemes that vary across server deployments. At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic - Authentication [RFC2617] in conjunction with a TLS [RFC2246] - connection as defined in [RFC2818] (but note that [RFC2246] has been - superseded by [RFC4346]). See [RFC4346] for more information on TLS. + Authentication [RFC2617] in conjunction with a connection made with + TLS 1.0 [RFC2246] or a subsequent standards-track version of TLS, + supporting the conventions for using HTTP over TLS described in + [RFC2818]. At a minimum, client and server implementations MUST be + 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 minimum level of security referenced above (Basic Authentication with TLS) is considered good practice for Internet applications at the time of publication of this specification and sufficient for establishing a baseline for interoperability. Implementers are encouraged to investigate and use alternative mechanisms regarded as equivalently good or better at the time of deployment. It is RECOMMENDED that clients be implemented in such a way that new authentication schemes can be deployed. Because this protocol uses HTTP response status codes as the primary means of reporting the result of a request, servers are advised to respond to unauthorized or unauthenticated requests using an - appropriate 4xx HTTP response code (e.g. 401 "Unauthorized" or 403 + appropriate 4xx HTTP response code (e.g., 401 "Unauthorized" or 403 "Forbidden") in accordance with [RFC2617]. 15. Security Considerations The Atom Publishing Protocol is based on HTTP and thus subject to the security considerations found in Section 15 of [RFC2616]. + The threats listed in this section apply to many protocols that run + under HTTP. The Atompub Working Group decided that the protection + afforded by running authenticated HTTP under TLS (as described in + Section 14) was sufficient to mitigate many of the problems presented + by the attacks listed in this section. + 15.1. Denial of Service Atom Publishing Protocol server implementations need to take adequate precautions to ensure malicious clients cannot consume excessive server resources (CPU, memory, disk, etc). 15.2. Replay Attacks Atom Publishing Protocol server implementations are susceptible to replay attacks. Specifically, this specification does not define a means of detecting duplicate requests. Accidentally sent duplicate requests are indistinguishable from intentional and malicious replay attacks. 15.3. Spoofing Attacks Atom Publishing Protocol implementations are susceptible to a variety - of spoofing attacks. Malicious clients may send Atom Entries + of spoofing attacks. Malicious clients might send Atom Entries containing inaccurate information anywhere in the document. 15.4. Linked Resources Atom Feed and Entry documents can contain XML External Entities as defined in Section 4.2.2 of [REC-xml]. Atom implementations are not required to load external entities. External entities are subject to the same security concerns as any network operation and can alter the semantics of an Atom document. The same issues exist for Resources linked to by Atom elements such as atom:link and atom:content. 15.5. Digital Signatures and Encryption - Atom Entry Documents sent to a server might contain XML Digital - Signatures [REC-xmldsig-core] and might be encrypted using XML - Encryption [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. + Atom Entry and Feed Documents can contain XML Digital Signatures + [REC-xmldsig-core] and can be encrypted using XML Encryption + [REC-xmlenc-core] as specified in Section 5 of [RFC4287]. Handling + of signatures and encrypted elements in Atom documents is discussed + in sections 5 and 6.3 of [RFC4287]. - Servers are allowed to modify received Resource representations in - ways that can invalidate signatures covering those representations. + Neither servers nor clients are under any obligation to support + encryption and digital signature of entries or feeds, although it is + certainly possible that in some installations, clients or servers + might require signing or encrypting of the documents exchanged in the + Atom protocol. + + Because servers are allowed (and in some cases expected) to modify + the contents of an Entry Document before publishing it, signatures + 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 + will be valid when viewed by a third party, or even that the server + will publish the client's signature. + + A server is allowed to strip client-applied signatures, to strip + 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 + third party of a signature applied by a server is the same as a + 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 + Document that was signed by the client should strip that signature + before publishing the entry in order to prevent third parties from + trying to interpret a signature that cannot be validated. 15.6. URIs and IRIs Atom Publishing Protocol implementations handle URIs and IRIs. See Section 7 of [RFC3986] and Section 8 of [RFC3987] for security considerations related to their handling and use. + The Atom Publishing Protocol leaves the server in control of minting + URIs. The use of any client-supplied data for creating new URIs is + subject to the same concerns as described in the next section. + 15.7. Code Injection and Cross Site Scripting Atom Feed and Entry documents can contain a broad range of content types including code that might be executable in some contexts. Malicious clients could attempt to attack servers or other clients by injecting code into a Collection Document's Entry or Media Resources. Server implementations are strongly encouraged to verify that client supplied content is safe prior to accepting, processing or publishing it. In the case of HTML, experience indicates that verification based on a white list of acceptable content is more effective than a black list of forbidden content. Additional information about XHTML and HTML content safety can be found in Section 8.1 of [RFC4287] 16. IANA Considerations - This document uses two new media types that conform to the registry - mechanism described in [RFC4288], a new message header that conforms - to the registry mechanism described in [RFC3864], and two new link - relations that conform to the registry mechanism described in - [RFC4287]. + This specification uses two new media types that conform to the + registry mechanism described in [RFC4288], a new message header that + conforms to the registry mechanism described in [RFC3864], and two + new link relations that conform to the registry mechanism described + in [RFC4287]. 16.1. Content-type registration for 'application/atomcat+xml' An Atom Publishing Protocol Category Document, when serialized as XML 1.0, can be identified with the following media type: MIME media type name: application MIME subtype name: atomcat+xml @@ -1774,30 +1813,30 @@ Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], section 3.2. Security considerations: As defined in this specification. - [[anchor31: update upon publication]] + [[anchor30: update upon publication]] In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. - Published specification: This specification. [[anchor32: update upon + Published specification: This specification. [[anchor31: update upon publication]] Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2. @@ -1808,22 +1847,22 @@ Base URI: As specified in [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Joe Gregorio Intended usage: COMMON - Author/Change controller: This specification's author(s). - [[anchor33: update upon publication]] + Author/Change controller: IETF (iesg@ietf.org) Internet Engineering + Task Force 16.2. Content-type registration for 'application/atomsvc+xml' An Atom Publishing Protocol Service Document, when serialized as XML 1.0, can be identified with the following media type: MIME media type name: application MIME subtype name: atomsvc+xml @@ -1832,30 +1871,30 @@ Optional parameters: "charset": This parameter has identical semantics to the charset parameter of the "application/xml" media type as specified in [RFC3023]. Encoding considerations: Identical to those of "application/xml" as described in [RFC3023], section 3.2. Security considerations: As defined in this specification. - [[anchor34: update upon publication]] + [[anchor32: update upon publication]] In addition, as this media type uses the "+xml" convention, it shares the same security considerations as described in [RFC3023], section 10. Interoperability considerations: There are no known interoperability issues. - Published specification: This specification. [[anchor35: update upon + Published specification: This specification. [[anchor33: update upon publication]] Applications that use this media type: No known applications currently use this media type. Additional information: Magic number(s): As specified for "application/xml" in [RFC3023], section 3.2. @@ -1866,35 +1905,35 @@ Base URI: As specified in [RFC3023], section 6. Macintosh File Type code: TEXT Person and email address to contact for further information: Joe Gregorio Intended usage: COMMON - Author/Change controller: This specification's author(s). - [[anchor36: update upon publication]] + Author/Change controller: IETF (iesg@ietf.org) Internet Engineering + Task Force 16.3. Header field registration for 'SLUG' Header field: SLUG Applicable protocol: http [RFC2616] Status: standard. Author/Change controller: IETF (iesg@ietf.org) Internet Engineering Task Force - Specification document(s): This specification. [[anchor37: update on + Specification document(s): This specification. [[anchor34: update on rfc number assignment]]) Related information: 16.4. The Link Relation registration "edit" Attribute Value: edit Description: An IRI of an editable Member Entry. When appearing within an atom:entry, the href IRI can be used to retrieve, update and delete the Resource represented by that Entry. @@ -1980,40 +2019,40 @@ [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. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication Format", RFC 4287, December 2005. [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005. - [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security - (TLS) Protocol Version 1.1", RFC 4346, April 2006. - 17.2. Informative References [NOTE-detect-lost-update] Nielsen, H. and D. LaLiberte, "Editing the Web: Detecting the Lost Update Problem Using Unreserved Checkout", World Wide Web Consortium NOTE NOTE-detect-lost-update, May 1999, . [REC-webarch] Walsh, N. and I. Jacobs, "Architecture of the World Wide @@ -2041,21 +2080,21 @@ namespace which are not defined in this revision of the specification. Requirements for Atom Protocol processors encountering such markup are given in Section 6.2 and Section 6.3 of [RFC4287]. The Schema for Service Documents: # -*- rnc -*- # RELAX NG Compact Syntax Grammar for the Atom Protocol - namespace app = "http://purl.org/atom/app#" + namespace app = "http://www.w3.org/2007/app" namespace atom = "http://www.w3.org/2005/Atom" namespace xsd = "http://www.w3.org/2001/XMLSchema" namespace xhtml = "http://www.w3.org/1999/xhtml" namespace local = "" start = appService # common:attrs atomURI = text @@ -2226,21 +2265,21 @@ | anyXHTML)* } # EOF The Schema for Category Documents: # -*- rnc -*- # RELAX NG Compact Syntax Grammar for the Atom Protocol - namespace app = "http://purl.org/atom/app#" + namespace app = "http://www.w3.org/2007/app" namespace atom = "http://www.w3.org/2005/Atom" namespace xsd = "http://www.w3.org/2001/XMLSchema" namespace local = "" start = appCategories atomCommonAttributes = attribute xml:base { atomURI }?, attribute xml:lang { atomLanguageTag }?, undefinedAttribute* @@ -2294,21 +2333,21 @@ element * - atom:* { (attribute * { text } | text | anyElement)* } # EOF Appendix C. Revision History - [[anchor42: This section to be removed upon publication.]] + [[anchor39: This section to be removed upon publication.]] draft-ietf-atompub-protocol-14: typos; removed "The language context is only significant for elements and attributes declared to be "Language-Sensitive" by this specification. "; "Successful member creation is normally indicated with a 201 ("Created") response code." removed "normally" from that sentence (9.2); Added "Media Link Entries are represented as Atom Entries and appear in the Collection." to 9.6; said that an app:accept value of "entry" is equivalent to "application/atom+xml;type=entry"; double-check spec terms; Member Entry resource -> Entry Resource; Added MLE, Entry @@ -2472,28 +2511,23 @@ IBM 4205 South Miama Blvd. Research Triangle Park, NC 27709 US Phone: +1 919 272 3764 Email: joe@bitworking.org URI: http://ibm.com/ Bill de hOra (editor) - Propylon Ltd. - 45 Blackbourne Square, Rathfarnham Gate - Dublin, Dublin D14 - IE - Phone: +353-1-4927444 Email: bill@dehora.net - URI: http://www.propylon.com/ + URI: http://dehora.net/ Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an