draft-ietf-atompub-protocol-10.txt   draft-ietf-atompub-protocol-11.txt 
Network Working Group J. Gregorio, Ed. Network Working Group J. Gregorio, Ed.
Internet-Draft IBM Internet-Draft IBM
Expires: March 9, 2007 B. de hOra, Ed. Expires: April 6, 2007 B. de hOra, Ed.
Propylon Ltd. Propylon Ltd.
September 05, 2006 October 03, 2006
The Atom Publishing Protocol The Atom Publishing Protocol
draft-ietf-atompub-protocol-10.txt draft-ietf-atompub-protocol-11.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 35 skipping to change at page 1, line 35
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 March 9, 2007. This Internet-Draft will expire on April 6, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
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 transport of Atom-formatted representations. The Atom format is HTTP transport of Atom-formatted representations. The Atom format is
documented in the Atom Syndication Format (RFC4287). documented in the Atom Syndication Format [RFC4287].
Editorial Note Editorial Note
To provide feedback on this Internet-Draft, join the atom-protocol To provide feedback on this Internet-Draft, join the atom-protocol
mailing list (http://www.imc.org/atom-protocol/index.html) [1]. mailing list (http://www.imc.org/atom-protocol/index.html) [1].
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5 2. Notational Conventions . . . . . . . . . . . . . . . . . . . 5
2.1 XML-related Conventions . . . . . . . . . . . . . . . . . 5 2.1 XML-related Conventions . . . . . . . . . . . . . . . . . 5
2.1.1 Referring to Information Items . . . . . . . . . . . . 5 2.1.1 Referring to Information Items . . . . . . . . . . . . 5
2.1.2 RELAX NG Schema . . . . . . . . . . . . . . . . . . . 5 2.1.2 RELAX NG Schema . . . . . . . . . . . . . . . . . . . 5
2.1.3 Use of xml:base and xml:lang . . . . . . . . . . . . . 5 2.1.3 Use of xml:base and xml:lang . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 8 4. Protocol Model . . . . . . . . . . . . . . . . . . . . . . . 7
5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 10 5. Protocol Operations . . . . . . . . . . . . . . . . . . . . 9
5.1 Retrieving a Service Document . . . . . . . . . . . . . . 10 5.1 Retrieving a Service Document . . . . . . . . . . . . . . 9
5.2 Listing Collection Members . . . . . . . . . . . . . . . . 10 5.2 Listing Collection Members . . . . . . . . . . . . . . . . 9
5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 11 5.3 Creating a Resource . . . . . . . . . . . . . . . . . . . 10
5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 11 5.4 Editing a Resource . . . . . . . . . . . . . . . . . . . . 10
5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 11 5.4.1 Retrieving a Resource . . . . . . . . . . . . . . . . 10
5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 12 5.4.2 Updating a Resource . . . . . . . . . . . . . . . . . 11
5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 12 5.4.3 Deleting a Resource . . . . . . . . . . . . . . . . . 11
5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 12 5.5 Use of HTTP Response codes . . . . . . . . . . . . . . . . 11
6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 13 6. Atom Publishing Protocol Documents . . . . . . . . . . . . . 12
6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 13 6.1 Document Types . . . . . . . . . . . . . . . . . . . . . . 12
6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 13 6.2 Document Extensibility . . . . . . . . . . . . . . . . . . 12
7. Category Documents . . . . . . . . . . . . . . . . . . . . . 14 7. Category Documents . . . . . . . . . . . . . . . . . . . . . 13
7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 14 7.2 Element Definitions . . . . . . . . . . . . . . . . . . . 13
7.2.1 The "app:categories" element . . . . . . . . . . . . . 14 7.2.1 The "app:categories" element . . . . . . . . . . . . . 13
8. Service Documents . . . . . . . . . . . . . . . . . . . . . 16 8. Service Documents . . . . . . . . . . . . . . . . . . . . . 15
8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1 Example . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 17 8.2 Element Definitions . . . . . . . . . . . . . . . . . . . 17
8.2.1 The "app:service" Element . . . . . . . . . . . . . . 17 8.2.1 The "app:service" Element . . . . . . . . . . . . . . 17
8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 17 8.2.2 The "app:workspace" Element . . . . . . . . . . . . . 17
8.2.3 The "app:collection" Element . . . . . . . . . . . . . 18 8.2.3 The "app:collection" Element . . . . . . . . . . . . . 18
8.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 19 8.2.4 The "app:accept" Element . . . . . . . . . . . . . . . 19
8.2.5 The "app:categories" Element . . . . . . . . . . . . . 20 8.2.5 The "app:categories" Element . . . . . . . . . . . . . 20
9. Creating and Editing Resources . . . . . . . . . . . . . . . 22 9. Creating and Editing Resources . . . . . . . . . . . . . . . 22
9.1 Member URIs . . . . . . . . . . . . . . . . . . . . . . . 22 9.1 Member URIs . . . . . . . . . . . . . . . . . . . . . . . 22
9.2 Creating resources with POST . . . . . . . . . . . . . . . 22 9.2 Creating resources with POST . . . . . . . . . . . . . . . 22
9.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . 23 9.2.1 Example . . . . . . . . . . . . . . . . . . . . . . . 23
9.3 Updating Resources with PUT . . . . . . . . . . . . . . . 24 9.3 Updating Resources with PUT . . . . . . . . . . . . . . . 24
9.4 Deleting Resources with DELETE . . . . . . . . . . . . . . 24 9.4 Deleting Resources with DELETE . . . . . . . . . . . . . . 24
9.5 Media Resources and Media Link Entries . . . . . . . . . . 24 9.5 Media Resources and Media Link Entries . . . . . . . . . . 24
9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 25 9.6 The Slug: Header . . . . . . . . . . . . . . . . . . . . . 25
9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 25 9.6.1 Slug: Header syntax . . . . . . . . . . . . . . . . . 25
9.6.2 Examples . . . . . . . . . . . . . . . . . . . . . . . 26 9.6.2 Examples . . . . . . . . . . . . . . . . . . . . . . . 26
10. Listing Collections . . . . . . . . . . . . . . . . . . . . 28 10. Listing Collections . . . . . . . . . . . . . . . . . . . . 28
10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 28 10.1 Collection Paging . . . . . . . . . . . . . . . . . . . 28
10.2 The "app:edited" Element . . . . . . . . . . . . . . . . 29
11. Atom Format Link Relation Extensions . . . . . . . . . . . . 30 11. Atom Format Link Relation Extensions . . . . . . . . . . . . 30
11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 30 11.1 The "edit" Link Relation . . . . . . . . . . . . . . . . 30
11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 30 11.2 The "edit-media" Link Relation . . . . . . . . . . . . . 30
12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 31 12. Atom Publishing Controls . . . . . . . . . . . . . . . . . . 31
12.1 The "app:control" Element . . . . . . . . . . . . . . . 31 12.1 The "app:control" Element . . . . . . . . . . . . . . . 31
12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 31 12.1.1 The "app:draft" Element . . . . . . . . . . . . . . 31
13. Securing the Atom Protocol . . . . . . . . . . . . . . . . . 32 13. Securing the Atom Publishing Protocol . . . . . . . . . . . 32
14. Security Considerations . . . . . . . . . . . . . . . . . . 33 14. Security Considerations . . . . . . . . . . . . . . . . . . 33
14.1 Denial of Service . . . . . . . . . . . . . . . . . . . 33
14.2 Replay Attacks . . . . . . . . . . . . . . . . . . . . . 33
14.3 Spoofing Attacks . . . . . . . . . . . . . . . . . . . . 33
14.4 Linked Resources . . . . . . . . . . . . . . . . . . . . 33
14.5 Digital Signatures and Encryption . . . . . . . . . . . 33
14.6 URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 33
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34
15.1 Content-type registration for 15.1 Content-type registration for
'application/atomserv+xml' . . . . . . . . . . . . . . . 34 'application/atomserv+xml' . . . . . . . . . . . . . . . 34
15.2 Content-type registration for 15.2 Content-type registration for
'application/atomcat+xml' . . . . . . . . . . . . . . . 35 'application/atomcat+xml' . . . . . . . . . . . . . . . 35
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 15.3 Header field registration for 'SLUG' . . . . . . . . . . 36
16.1 Normative References . . . . . . . . . . . . . . . . . . 37 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
16.2 Informative References . . . . . . . . . . . . . . . . . 38 16.1 Normative References . . . . . . . . . . . . . . . . . . 38
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 39 16.2 Informative References . . . . . . . . . . . . . . . . . 39
A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 40
B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 41 A. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 41
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 47 B. RELAX NG Compact Schema . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . 50 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 48
Intellectual Property and Copyright Statements . . . . . . . 51
1. Introduction 1. Introduction
The Atom Publishing Protocol is an application-level protocol for The Atom Publishing Protocol is an application-level protocol for
publishing and editing Web resources using HTTP [RFC2616] and XML 1.0 publishing and editing Web resources using HTTP [RFC2616] and XML 1.0
[W3C.REC-xml-20040204]. The protocol supports the creation of [W3C.REC-xml-20060816]. The protocol supports the creation of
arbitrary web resources and provides facilities for: arbitrary web resources and provides facilities for:
o Collections: Sets of resources, which can be retrieved in whole or o Collections: Sets of resources, which can be retrieved in whole or
in part. in part.
o Service: Discovering and describing Collections. o Service: Discovering and describing Collections.
o Editing: Creating, updating and deleting resources. o Editing: Creating, updating and deleting resources.
2. Notational Conventions 2. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Atom Protocol documents allow the use of IRIs [RFC3987], as well as
URIs [RFC3986]. Before an IRI found in a document is used by HTTP,
the IRI is first converted to a URI according the procedure defined
in [RFC3987] (Section 3.1). The resource identified by the URI after
conversion is the same as the one identified by the IRI.
2.1 XML-related Conventions 2.1 XML-related Conventions
2.1.1 Referring to Information Items 2.1.1 Referring to Information Items
Atom Protocol Document formats are specified in terms of the XML Atom Protocol Document formats are specified in terms of the XML
Information Set [W3C.REC-xml-infoset-20040204], serialized as XML 1.0 Information Set [W3C.REC-xml-infoset-20040204], serialized as XML 1.0
[W3C.REC-xml-20040204]. [W3C.REC-xml-20060816].
The Infoset terms "Element Information Item" and "Attribute The Infoset terms "Element Information Item" and "Attribute
Information Item" are shortened to "element" and "attribute" Information Item" are shortened to "element" and "attribute"
respectively. Therefore, when this specification uses the term respectively. Therefore, when this specification uses the term
"element", it is referring to an Element Information Item, and when "element", it is referring to an Element Information Item, and when
it uses the term "attribute", it is referring to an Attribute it uses the term "attribute", it is referring to an Attribute
Information Item. Information Item.
2.1.2 RELAX NG Schema 2.1.2 RELAX NG Schema
Some sections of this specification are illustrated with fragments of Some sections of this specification are illustrated with fragments of
a non-normative RELAX NG Compact schema [RNC]. However, the text of a non-normative RELAX NG Compact schema [RNC]. However, the text of
this specification provides the definition of conformance. Complete this specification provides the definition of conformance. Complete
schemas appear in Appendix B. schemas appear in Appendix B.
2.1.3 Use of xml:base and xml:lang 2.1.3 Use of xml:base and xml:lang
XML elements defined by this specification MAY have an xml:base XML elements defined by this specification MAY have an xml:base
attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it attribute [W3C.REC-xmlbase-20010627]. When xml:base is used, it
serves the function described in section 5.1.1 of URI Generic Syntax serves the function described in Section 5.1.1 of URI Generic Syntax
[RFC3986], by establishing the base URI (or IRI) for resolving [RFC3986], by establishing the base URI (or IRI) for resolving
relative references found within the scope of the xml:base attribute. relative references found within the scope of the xml:base attribute.
Any element defined by this specification MAY have an xml:lang Any element defined by this specification MAY have an xml:lang
attribute, whose content indicates the natural language for the attribute, whose content indicates the natural language for the
element and its descendents. The language context is only element and its descendents. The language context is only
significant for elements and attributes declared to be "Language- significant for elements and attributes declared to be "Language-
Sensitive" by this specification. Requirements regarding the content Sensitive" by this specification. Requirements regarding the content
and interpretation of xml:lang are specified in Section 2.12 of XML and interpretation of xml:lang are specified in Section 2.12 of XML
1.0 [W3C.REC-xml-20040204]. 1.0 [W3C.REC-xml-20060816].
3. Terminology 3. Terminology
For convenience, this protocol can be referred to as the "Atom For convenience, this protocol can be referred to as the "Atom
Protocol" or "APP". Protocol" or "APP".
URI/IRI - A Uniform Resource Identifier and Internationalized URI/IRI - A Uniform Resource Identifier and Internationalized
Resource Identifier. These terms and the distinction between them Resource Identifier. These terms and the distinction between them
are defined in [RFC3986] and [RFC3987]. IRIs are mapped to URIs are defined in [RFC3986] and [RFC3987]. Before an IRI found in a
before dereferencing takes place. document is used by HTTP, the IRI is first converted to a URI (see
Section 4
The phrase "the URI of a document" in this specification is shorthand The phrase "the URI of a document" in this specification is shorthand
for "a URI which, when dereferenced, is expected to produce that for "a URI which, when dereferenced, is expected to produce that
document as a representation". document as a representation".
Resource - A network-accessible data object or service identified by Resource - A network-accessible data object or service identified by
an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for an IRI, as defined in [RFC2616]. See [W3C.REC-webarch-20041215] for
further discussion on resources. further discussion on resources.
Representation - An entity included with a request or response as Representation - An entity included with a request or response as
defined in [RFC2616]. defined in [RFC2616].
Collection - A resource that contains a set of Member IRIs. See Collection - A resource that contains a set of Member Entries. See
Section 9. Section 9.
Member - A resource whose IRI is listed in a Collection by a link Member - A resource whose IRI is listed in a Collection by a link
element with a relation of "edit" or "edit-media". See Section 9.1. element with a relation of "edit" or "edit-media". See Section 9.1.
Workspace - A group of collections. See Section 8. Workspace - A group of collections. See Section 8.
Service Document - A document that describes the location and Service Document - A document that describes the location and
capabilities of one or more Collections. See Section 8. capabilities of one or more Collections. See Section 8.
Category Document - A document that describes the categories allowed Category Document - A document that describes the categories allowed
in a Collection. See Section 7. in a Collection. See Section 7.
4. Protocol Model 4. Protocol Model
The Atom Publishing Protocol uses HTTP methods to edit and author The Atom Publishing Protocol uses HTTP methods to author Member
Member Resources as follows: Resources as follows:
o GET is used to retrieve a representation of a known resource. o GET is used to retrieve a representation of a known resource.
o POST is used to create a new, dynamically-named, resource. o POST is used to create a new, dynamically-named, resource.
o PUT is used to update a known resource. o PUT is used to update a known resource.
o DELETE is used to remove a known resource. o DELETE is used to remove a known resource.
Along with operations on Member Resources the Atom Protocol defines Along with operations on Member Resources the Atom Protocol defines
Collection resources for managing and organizing Member Resources. Collection resources for managing and organizing Member Resources.
Collections are represented by Atom Feed documents and contain the Collections are represented by Atom Feed documents and contain the
IRIs of, and metadata about, their Member Resources. IRIs of, and metadata about, their Member Resources.
Atom Protocol documents allow the use of IRIs [RFC3987], as well as
URIs [RFC3986]. Before an IRI found in a document is used by HTTP,
the IRI is first converted to a URI according the procedure defined
in Section 3.1 of [RFC3987]. The resource identified by the URI
after conversion is the same as the one identified by the IRI.
There are two kinds of Member Resources - Member Entry Resources and There are two kinds of Member Resources - Member Entry Resources and
Media Resources. Member Entry Resources are represented as Atom Media Resources. Member Entry Resources are represented as Atom
Entries. Media Resources MAY have representations in any media type. Entries [RFC4287]. Media Resources can have representations in any
A Media Link Entry is a Member Entry that contains metadata about a media type. A Media Link Entry is a Member Entry that contains
Media Resource. This diagram shows the classification of the metadata about a Media Resource. This diagram shows the
resources: classification of the resources:
Member Resource Member Resource
-> Member Entry Resource -> Member Entry Resource
-> Media Link Entry Resource -> Media Link Entry Resource
-> Media Resource -> Media Resource
Collections, represented by Atom feeds, contain entries. Those Collections, represented by Atom feeds, contain entries. Those
entries contain the Member Entry and Media Resources IRIs of the entries contain the Member Entry and Media Resources IRIs of the
Collection. A Collection can contain any number of entries of either Collection. A Collection can contain any number of entries of either
kind. In the diagram of a Collection below there are two entries. kind. In the diagram of a Collection below there are two entries.
skipping to change at page 10, line 11 skipping to change at page 9, line 11
Service Documents represent server-defined groups of Collections, and Service Documents represent server-defined groups of Collections, and
are used to initialize the process of creating and editing resources. are used to initialize the process of creating and editing resources.
5. Protocol Operations 5. Protocol Operations
5.1 Retrieving a Service Document 5.1 Retrieving a Service Document
Client Server Client Server
| | | |
| 1.) GET to URI of Service Document | | 1.) GET to Service Document |
|------------------------------------------>| |------------------------------------------>|
| | | |
| 2.) Service Document | | 2.) Service Document |
|<------------------------------------------| |<------------------------------------------|
| | | |
1. The client sends a GET request to the URI of the Service 1. The client sends a GET request using the URI of the Service
Document. Document.
2. The server responds with the document enumerating the IRIs of a 2. The server responds with the document enumerating the IRIs of a
set of Collections and the capabilities of those Collections set of Collections and the capabilities of those Collections
supported by the server. The content of this document can vary supported by the server. The content of this document can vary
based on aspects of the client request, including, but not based on aspects of the client request, including, but not
limited to, authentication credentials. limited to, authentication credentials.
5.2 Listing Collection Members 5.2 Listing Collection Members
To list the members of a Collection the client sends a GET request to To list the members of a Collection, the client sends a GET request
the URI of a Collection. An Atom Feed Document is returned to the URI of a Collection. An Atom Feed Document is returned
containing one Atom Entry for each Member Entry Resource. See containing one Atom Entry for each Member Entry Resource. See
Section 10 and Section 11 for a description of the feed contents. Section 10 and Section 11 for a description of the feed contents.
Client Server Client Server
| | | |
| 1.) GET to Collection URI | | 1.) GET to Collection URI |
|------------------------------->| |------------------------------->|
| | | |
| 2.) 200 OK, Atom Feed Doc | | 2.) 200 OK, Atom Feed Doc |
|<-------------------------------| |<-------------------------------|
skipping to change at page 12, line 46 skipping to change at page 11, line 46
with a status code of 200. with a status code of 200.
A different approach is taken for deleting Media Resources, see A different approach is taken for deleting Media Resources, see
Section 9.5 for details. Section 9.5 for details.
5.5 Use of HTTP Response codes 5.5 Use of HTTP Response codes
The Atom Protocol uses the response status codes defined in HTTP to The Atom Protocol uses the response status codes defined in HTTP to
indicate the success or failure of an operation. Consult the HTTP indicate the success or failure of an operation. Consult the HTTP
specification [RFC2616] for detailed definitions of each status code. specification [RFC2616] for detailed definitions of each status code.
It is RECOMMENDED that entities contained within HTTP 4xx and 5xx Implementers are asked to note that per the HTTP specification, HTTP
responses include a human-readable explanation of the error. 4xx and 5xx response entities SHOULD include a human-readable
explanation of the error.
6. Atom Publishing Protocol Documents 6. Atom Publishing Protocol Documents
6.1 Document Types 6.1 Document Types
This specification describes two kinds of Documents - Category This specification describes two kinds of Documents - Category
Documents and Service Documents. Documents and Service Documents.
A Category Document (Section 7) contain lists of categories specified A Category Document (Section 7) contain lists of categories specified
using the "atom:category" element from the Atom Syndication Format. using the "atom:category" element from the Atom Syndication Format.
A Service Document (Section 8) describes capabilities of workspaces, A Service Document (Section 8) describes capabilities of workspaces,
which are server-defined groupings of Collections. which are server-defined groupings of Collections.
The namespace name [W3C.REC-xml-names-19990114] for either kind of The namespace name [W3C.REC-xml-names-20060816] for either kind of
document is: document is:
http://purl.org/atom/app# http://purl.org/atom/app#
[[anchor8: Needs to be updated with the final URI upon publication]]
This specification uses the prefix "app:" for the namespace name. This specification uses the prefix "app:" for the namespace name.
The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the The prefix "atom:" is used for "http://www.w3.org/2005/Atom", the
namespace name of the Atom Syndication Format [RFC4287]. The namespace name of the Atom Syndication Format [RFC4287]. The
namespace prefixes are not semantically significant. namespace prefixes are not semantically significant.
Atom Publishing Protocol Documents MUST be well-formed XML. This Atom Publishing Protocol Documents MUST be well-formed XML. This
specification does not define any DTDs for Atom Protocol formats, and specification does not define any DTDs for Atom Protocol formats, and
hence does not require them to be "valid" in the sense used by XML. hence does not require them to be "valid" in the sense used by XML.
6.2 Document Extensibility 6.2 Document Extensibility
The namespace name "http://purl.org/atom/app#" is reserved for future
forward-compatible revisions of the document types. Future versions
of this specification could add new elements and attributes.
Software written to conform to this version of the specification will
not be able to process such markup correctly and in fact will not be
able to distinguish it from markup error.
Unrecognized markup in an Atom Publishing Protocol document is Unrecognized markup in an Atom Publishing Protocol document is
considered "foreign markup" as defined in [RFC4287]. considered "foreign markup" as defined in [RFC4287]. Such 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 or signal an error, and SHOULD
preserve foreign markup when transmitting such documents.
Markup from other vocabularies ("foreign markup") can be used The namespace name "http://purl.org/atom/app#" is reserved for
anywhere within a Category or Service Document unless it is forward compatible revisions of the Category and Service Document
explicitly forbidden. Processors that encounter foreign markup MUST types - this does not exclude the addition of elements and attributes
NOT stop processing or signal an error, and SHOULD preserve foreign that might not be recognised by processors conformant to this
markup when transmitting such documents. specification. Such unrecognised markup from the
"http://purl.org/atom/app#" namespace MUST be treated as foreign
markup.
7. Category Documents 7. Category Documents
Category Documents contain lists of categories described using the Category Documents contain lists of categories described using the
"atom:category" element from the Atom Syndication Format [RFC4287]. "atom:category" element from the Atom Syndication Format [RFC4287].
Categories can also appear in Service Documents and describe the Categories can also appear in Service Documents and describe the
categories allowed in a Collection (see Section 8.2.5). categories allowed in a Collection (see Section 8.2.5).
Category Documents are identified with the "application/atomcat+xml" Category Documents are identified with the "application/atomcat+xml"
media type (see Section 15). media type (see Section 15).
skipping to change at page 14, line 27 skipping to change at page 13, line 27
<?xml version="1.0" ?> <?xml version="1.0" ?>
<app:categories <app:categories
xmlns:app="http://purl.org/atom/app#" xmlns:app="http://purl.org/atom/app#"
xmlns="http://www.w3.org/2005/Atom" xmlns="http://www.w3.org/2005/Atom"
fixed="yes" scheme="http://example.com/cats/big3"> fixed="yes" scheme="http://example.com/cats/big3">
<category term="animal" /> <category term="animal" />
<category term="vegetable" /> <category term="vegetable" />
<category term="mineral" /> <category term="mineral" />
</app:categories> </app:categories>
This Category Document contains three categories with the terms This Category Document contains three categories, with the terms
"animal", "vegetable", and "mineral". None of the categories has a "animal", "vegetable", and "mineral". None of the categories use the
label attribute (as defined in [RFC4287]). They all inherit the 'label' attribute defined in [RFC4287]. They all inherit the
"http://example.com/cats/big3" category 'scheme' (in the [RFC4287] "http://example.com/cats/big3" 'scheme' attribute declared on the
sense) declared on the app:categories element. Therefore if the app:categories element. Therefore if the "mineral" category were to
"mineral" category were to appear in an Atom Entry or Feed Document, appear in an Atom Entry or Feed Document, it would appear as:
it would appear as:
<category scheme="http://example.com/cats/big3" term="mineral" /> <category scheme="http://example.com/cats/big3" term="mineral" />
7.2 Element Definitions 7.2 Element Definitions
7.2.1 The "app:categories" element 7.2.1 The "app:categories" element
The root of a Category Document is the "app:categories" element. An The root of a Category Document is the "app:categories" element. An
app:categories element MAY contain one or more "atom:category" app:categories element can contain zero or more "atom:category"
elements from the Atom namespace ("http://www.w3.org/2005/Atom"). elements from the Atom namespace ("http://www.w3.org/2005/Atom").
If an app:category child element has no "scheme" attribute it An app:category child element that has no "scheme" attribute inherits
inherits the attribute from its app:categories parent. An app: the attribute from its app:categories parent. An app:category child
category child element with an existing "scheme" attribute does not element with an existing "scheme" attribute does not inherit the
inherit the "scheme" value of its "app:categories" parent element. "scheme" value of its "app:categories" parent element.
7.2.1.1 Attributes of "app:categories" 7.2.1.1 Attributes of "app:categories"
The app:categories element MAY contain a "fixed" attribute, with a The app:categories element can contain a "fixed" attribute, with a
value of either "yes" or "no", indicating if the list of categories value of either "yes" or "no", indicating whether the list of
is a fixed or an open set. Collections that indicate the set is categories is a fixed or an open set. Newly created or updated
fixed MAY reject members whose categories are not listed in the members whose categories are not listed in the Collection Document
Collection Document. Collections that indicate the set is open MAY be rejected by the server. Collections that indicate the set is
SHOULD NOT reject otherwise acceptable members whose categories are open SHOULD NOT reject otherwise acceptable members whose categories
not listed in the Collection. are not listed in the Collection.
Alternatively, the app:categories element MAY contain an "href" Alternatively, the app:categories element MAY contain an "href"
attribute, whose value MUST be an IRI reference identifying a attribute, whose value MUST be an IRI reference identifying a
Category Document. If the "href" attribute is provided, the app: Category Document. If the "href" attribute is provided the app:
categories element MUST be empty and MUST NOT have the "fixed" or categories element MUST be empty and MUST NOT have the "fixed" or
"scheme" attributes. "scheme" attributes.
atomCategory = atomCategory =
element atom:category { element atom:category {
atomCommonAttributes, atomCommonAttributes,
attribute term { text }, attribute term { text },
attribute scheme { atomURI }?, attribute scheme { atomURI }?,
attribute label { text }?, attribute label { text }?,
undefinedContent undefinedContent
skipping to change at page 15, line 40 skipping to change at page 14, line 36
appInlineCategories = appInlineCategories =
element app:categories { element app:categories {
attribute fixed { "yes" | "no" }?, attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?, attribute scheme { atomURI }?,
(atomCategory*) (atomCategory*)
} }
appOutOfLineCategories = appOutOfLineCategories =
element app:categories { element app:categories {
attribute href { atomURI }, attribute href { atomURI },
(empty) undefinedContent
} }
appCategories = appInlineCategories | appOutOfLineCategories appCategories = appInlineCategories | appOutOfLineCategories
8. Service Documents 8. Service Documents
For authoring to commence, a client needs to first discover the For authoring to commence, a client needs to first discover the
capabilities and locations of the available collections. Service capabilities and locations of the available collections. Service
Documents are designed to support this discovery process. Documents are designed to support this discovery process. How
Service Documents are in turn discovered is not defined in this
specification.
A Service Document describes workspaces, which are server-defined A Service Document describes workspaces, which are server-defined
groupings of Collections. Service Documents are identified with the groupings of Collections. Service Documents are identified with the
"application/atomserv+xml" media type (see Section 15). "application/atomserv+xml" media type (see Section 15).
There is no requirement that a server support multiple workspaces. There is no requirement that a server support multiple workspaces.
In addition, a Collection MAY appear in more than one Workspace. In addition, a Collection MAY appear in more than one Workspace.
8.1 Example 8.1 Example
skipping to change at page 18, line 10 skipping to change at page 17, line 42
8.2.2 The "app:workspace" Element 8.2.2 The "app:workspace" Element
The "app:workspace" element contains information elements about the The "app:workspace" element contains information elements about the
collections of resources available for editing. The app:workspace collections of resources available for editing. The app:workspace
element contains zero or more app:collection elements. element contains zero or more app:collection elements.
appWorkspace = appWorkspace =
element app:workspace { element app:workspace {
appCommonAttributes, appCommonAttributes,
( appCollection* ( atomTitle
& appCollection*
& extensionElement* ) & extensionElement* )
} }
atomTitle = element atom:title { atomTextConstruct } atomTitle = element atom:title { atomTextConstruct }
In an app:workspace element, the first app:collection element MUST In an app:workspace element, the first app:collection element MUST
refer to the preferred or primary Collection. In the following refer to the preferred or primary Collection. This distinction is
example, the "Entries" collection would be considered the preferred considered useful in scenarios where Members and Media Link Entries
are POSTed to different Collections. In the following example, the
"Eintragungen" collection would be considered the preferred
Collection: Collection:
<service xmlns="http://purl.org/atom/app#" <service xmlns="http://purl.org/atom/app#"
xmlns:atom="http://www.w3.org/2005/Atom"> xmlns:atom="http://www.w3.org/2005/Atom">
<workspace> <workspace xml:lang="de">
<atom:title>My Blog</atom:title> <atom:title>Das Blog</atom:title>
<collection <collection
href="http://example.org/myblog/entries" > href="http://example.org/blog/eintragungen" >
<atom:title>Entries</atom:title> <atom:title>Eintragungen</atom:title>
</collection> </collection>
<collection <collection
href="http://example.org/myblog/fotes"> href="http://example.org/blog/fotos">
<atom:title>Photos</atom:title> <atom:title>Fotos</atom:title>
<accept>image/*</accept> <accept>image/*</accept>
</collection> </collection>
</workspace> </workspace>
</service> </service>
8.2.2.1 The "atom:title" Element 8.2.2.1 The "atom:title" Element
The app:workspace element MUST contain one "atom:title" element, The app:workspace element MUST contain one "atom:title" element (as
giving a human-readable title for the workspace. defined in [RFC4287]), giving a human-readable title for the
workspace.
8.2.3 The "app:collection" Element 8.2.3 The "app:collection" Element
The "app:collection" element describes a Collection. The app: The "app:collection" element describes a Collection. The app:
collection element MAY contain one app:accept element and MAY contain collection element MAY contain one app:accept element and MAY contain
any number of app:categories elements. The app:collection element any number of app:categories elements. The app:collection element
MUST NOT contain more that one app:accept element. MUST NOT contain more than one app:accept element.
appCollection = appCollection =
element app:collection { element app:collection {
appCommonAttributes, appCommonAttributes,
attribute href { atomURI }, attribute href { atomURI },
( appAccept? ( atomTitle
& appAccept?
& appCategories* & appCategories*
& extensionElement* ) & extensionElement* )
} }
8.2.3.1 Usage in Atom Feed Documents 8.2.3.1 Usage in Atom Feed Documents
The app:collection element MAY appear as a child of an atom:feed or The app:collection element MAY appear as a child of an atom:feed or
atom:source element in an Atom Feed Document. Its value identifies a atom:source element in an Atom Feed Document. Its value identifies a
Collection by which new entries can be added to appear in the feed. Collection by which new entries can be added to appear in the feed.
The app:control element is considered foreign markup as defined in
Section 6 of [RFC4287].
8.2.3.2 The "href" Attribute 8.2.3.2 The "href" Attribute
The app:collection element MUST contain an "href" attribute, whose The app:collection element MUST contain an "href" attribute, whose
value gives the IRI of the Collection. value gives the IRI of the Collection.
8.2.3.3 The "atom:title" Element 8.2.3.3 The "atom:title" Element
The app:collection Element MUST contain one "atom:title" element, The app:collection Element MUST contain one "atom:title" element,
giving a human-readable title for the Workspace. giving a human-readable title for the Workspace.
8.2.4 The "app:accept" Element 8.2.4 The "app:accept" Element
The "app:accept" element value specifies a comma-separated list of The "app:accept" element value specifies a comma-separated list of
media-ranges (see [RFC2616]) identifying the types of representations media-ranges (see [RFC2616]) identifying the types of representations
that can be POSTed to the URI of a Collection. Whitespace separation that can be POSTed to the URI of a Collection. Whitespace around and
of the media-range values is considered insignificant and MUST be between media-range values is considered insignificant and MUST be
ignored. ignored.
The app:accept element is similar to the HTTP Accept request-header The app:accept element is similar to the HTTP Accept request-header
[RFC2616] with the exception that app:accept has no notion of [RFC2616] with the exception that app:accept has no notion of
preference. As a result, the value syntax of app:accept does not use preference. As a result, the value syntax of app:accept does not use
"accept-params" or "q" arguments as specified in [RFC2616], section "accept-params" or "q" arguments as specified in [RFC2616], section
14.1. 14.1.
The order of media-ranges is not significant. The following lists The order of media-ranges is not significant. The following lists
are all equivalent: are all equivalent:
skipping to change at page 20, line 44 skipping to change at page 20, line 39
appInlineCategories = appInlineCategories =
element app:categories { element app:categories {
attribute fixed { "yes" | "no" }?, attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?, attribute scheme { atomURI }?,
(atomCategory*) (atomCategory*)
} }
appOutOfLineCategories = appOutOfLineCategories =
element app:categories { element app:categories {
attribute href { atomURI }, attribute href { atomURI },
(empty) undefinedContent
} }
appCategories = appInlineCategories | appOutOfLineCategories appCategories = appInlineCategories | appOutOfLineCategories
The app:categories element MAY contain a "fixed" attribute, with a The app:categories element MAY contain a "fixed" attribute, with a
value of either "yes" or "no", indicating whether or not the listing value of either "yes" or "no", indicating whether or not the listing
of categories is considered to be a fixed, or closed set. The of categories is considered to be a fixed, or closed set. The
absence of the "fixed" attribute is equivalent to the presence of a absence of the "fixed" attribute is equivalent to the presence of a
"fixed" attribute with a value of "no". Collections that indicate a "fixed" attribute with a value of "no". Collections that indicate a
fixed set MAY reject members that include categories not specified in fixed set MAY reject members that include categories not specified in
the provided listing. Collections that indicate an open set SHOULD the provided listing. Collections that indicate an open set SHOULD
NOT reject otherwise acceptable members whose categories are not NOT reject otherwise acceptable members whose categories are not
present in the provided list. present in the provided list.
skipping to change at page 22, line 25 skipping to change at page 22, line 25
a Location header after successful resource creation using POST, as a Location header after successful resource creation using POST, as
described below. Second, in the entries of a Collection document, by described below. Second, in the entries of a Collection document, by
an atom:link element with a link relation of "edit". an atom:link element with a link relation of "edit".
Each Member Entry SHOULD contain such an atom:link element providing Each Member Entry SHOULD contain such an atom:link element providing
its Member Entry URI. its Member Entry URI.
9.2 Creating resources with POST 9.2 Creating resources with POST
To add members to a Collection, clients send POST requests to the URI To add members to a Collection, clients send POST requests to the URI
of a Collection. Collections MAY impose constraints on the media- of a Collection. Successful member creation is normally indicated
types of request entities POSTed to the Collection and MAY generate a with a 201 ("Created") response code. Collections MAY generate a
response with a status code of 415 ("Unsupported Media Type"). response with a status code of 415 ("Unsupported Media Type") to
indicate media-type of POSTed entity is not allowed or supported by
the Collection.
If a Member Resource was created in the Collection which received the When a Member Resource is created in the Collection which received
POST, its Member Entry URI MUST be returned in an HTTP Location the POST, its Member Entry URI MUST be returned in an HTTP Location
header. header.
When the server generates a response with a status code of 201 When the server generates a response with a status code of 201
("Created"), it SHOULD also return a response body, which if ("Created"), it SHOULD also return a response body, which if
provided, MUST be an Atom Entry Document representing the newly- provided, MUST be an Atom Entry Document representing the newly-
created resource, and SHOULD include its Member Entry URI in an atom: created resource.
link element that has a relation of "edit".
Since the server is free to alter the posted entry, for example by Since the server is free to alter the posted entry, for example by
changing the content of the "id" element, returning the Entry as changing the content of the "id" element, returning the Entry as
described in the previous paragraph can be useful to the client, described in the previous paragraph can be useful to the client,
enabling it to correlate the client and server views of the new enabling it to correlate the client and server views of the new
Entry. Entry.
When the POST request contains an Atom Entry Document, the response When the POST request contains an Atom Entry Document, the response
from the server SHOULD contain a Content-Location header that from the server SHOULD contain a Content-Location header that
contains the same character-by-character value as the Location contains the same character-by-character value as the Location
skipping to change at page 24, line 38 skipping to change at page 24, line 40
as specified in [RFC2616]. For Media Resources, deletion of a Media as specified in [RFC2616]. For Media Resources, deletion of a Media
Link Entry SHOULD result in the deletion of the associated Media Link Entry SHOULD result in the deletion of the associated Media
Resource. Resource.
9.5 Media Resources and Media Link Entries 9.5 Media Resources and Media Link Entries
A client can POST a media type other than application/atom+xml to a A client can POST a media type other than application/atom+xml to a
Collection. Such a request creates two new resources - one that Collection. Such a request creates two new resources - one that
corresponds to the entity sent in the request, called the Media corresponds to the entity sent in the request, called the Media
Resource, and an associated Member Entry, called the Media Link Resource, and an associated Member Entry, called the Media Link
Entry. The server can signal the media types it will accept via the Entry. Media Link Entries are represented as Atom Entries. The
"accept" element in the Service Document (Section 8.2.4). server can signal the media types it will accept via the "accept"
element in the Service Document (Section 8.2.4).
The Media Link Entry contains the IRI of the Media Resource and makes The Media Link Entry contains the IRI of the Media Resource and makes
metadata about it separately available for retrieval and update. The metadata about it separately available for retrieval and update. The
Media Link Entry is used to store metadata about the (perhaps non- Media Link Entry is used to store metadata about the (perhaps non-
textual) Media Resource. textual) Media Resource.
Successful responses to creation requests MUST include the URI of the Successful responses to creation requests MUST include the URI of the
Media Link Entry in the Location header. The Media Link Entry SHOULD Media Link Entry in the Location header. The Media Link Entry SHOULD
contain an atom:link element with a link relation of "edit-media" contain an atom:link element with a link relation of "edit-media"
that contains the Media Resource IRI. The Media Link Entry MUST have that contains the Media Resource IRI. The Media Link Entry MUST have
skipping to change at page 25, line 29 skipping to change at page 25, line 33
POST body has an Atom Entry entity declared as an Atom media type POST body has an Atom Entry entity declared as an Atom media type
("application/atom+xml"), or a non-Atom entity declared as a non-Atom ("application/atom+xml"), or a non-Atom entity declared as a non-Atom
media type. It does not specify any request semantics or server media type. It does not specify any request semantics or server
behavior in the case where the POSTed media-type is "application/ behavior in the case where the POSTed media-type is "application/
atom+xml" but the body is something other than an Atom Entry. In atom+xml" but the body is something other than an Atom Entry. In
particular, what happens on POSTing an Atom Feed Document to a particular, what happens on POSTing an Atom Feed Document to a
Collection using the "application/atom+xml" media type is undefined. Collection using the "application/atom+xml" media type is undefined.
9.6 The Slug: Header 9.6 The Slug: Header
Slug is a HTTP entity-header whose value is a "slug", i.e. a short Slug is a HTTP entity-header whose value is a "slug" - a short name
name that can be used as part of URI for a Member Resource. that can be used as part of the URI for a Member Resource.
When posting an entity to a Collection to add a new Member, the When posting an entity to a Collection to add a new Member, the
server MAY use this information when creating the Member URI of the server MAY use this information when creating the Member URI of the
newly-created resource, for instance by using some or all of the newly-created resource, for instance by using some or all of the
words in the last URI segment. It MAY also use it when creating the words in the last URI segment. It MAY also use it when creating the
atom:id or as the title of a Media Link Entry (see Section 9.5.). atom:id or as the title of a Media Link Entry (see Section 9.5.).
Servers MAY ignore the Slug entity-header and MAY alter its value Servers MAY ignore the Slug entity-header and MAY alter its value
before using it. For example, the server MAY filter out some before using it. For example, the server MAY filter out some
characters or replace accented letters with non-accented ones, spaces characters or replace accented letters with non-accented ones, spaces
skipping to change at page 28, line 12 skipping to change at page 28, line 12
See Section 9.2.1 for an example of the Slug: header applied to the See Section 9.2.1 for an example of the Slug: header applied to the
creation of a Member Entry Resource. creation of a Member Entry Resource.
10. Listing Collections 10. Listing Collections
Collection resources MUST provide representations in the form of Atom Collection resources MUST provide representations in the form of Atom
Feed documents whose entries represent the Members in the Collection. Feed documents whose entries represent the Members in the Collection.
Each entry in the Feed Document SHOULD have an atom:link element with Each entry in the Feed Document SHOULD have an atom:link element with
a relation of "edit" (See Section 11.1). a relation of "edit" (See Section 11.1).
The entries in the returned Atom Feed MUST be ordered by their "atom: The entries in the returned Atom Feed SHOULD be ordered by their
updated" property, with the most recently updated entries coming "atom:updated" property, with the most recently updated entries
first in the document order. Clients SHOULD be constructed in coming first in the document order. Clients SHOULD be constructed in
consideration of the fact that changes which do not alter the atom: consideration of the fact that changes which do not alter the atom:
updated value of an entry will not affect the position of the entry updated value of an entry will not affect the position of the entry
in a Collection. in a Collection.
Clients MUST NOT assume that an Atom Entry returned in the Feed is a Clients MUST NOT assume that an Atom Entry returned in the Feed is a
full representation of a Member Entry Resource and SHOULD perform a full representation of a Member Entry Resource and SHOULD perform a
GET on the URI of the Member Entry before editing. GET on the URI of the Member Entry before editing.
10.1 Collection Paging 10.1 Collection Paging
skipping to change at page 28, line 36 skipping to change at page 28, line 36
such as a web spider or web browser could be overwhelmed if the such as a web spider or web browser could be overwhelmed if the
response to a GET contained every entry in the Collection, and the response to a GET contained every entry in the Collection, and the
server would waste large amounts of bandwidth and processing time on server would waste large amounts of bandwidth and processing time on
clients unable to handle the response. For this reason, servers MAY clients unable to handle the response. For this reason, servers MAY
return a partial listing of the most recently updated Member return a partial listing of the most recently updated Member
Resources. Such partial feed documents MUST have an atom:link with a Resources. Such partial feed documents MUST have an atom:link with a
"next" relation whose "href" value is the URI of the next partial "next" relation whose "href" value is the URI of the next partial
listing of the Collection (the next most recently updated Member listing of the Collection (the next most recently updated Member
Resources) where it exists. This is called "Collection paging". Resources) where it exists. This is called "Collection paging".
The returned Atom Feed MAY NOT contain entries for all the Members in The returned Atom Feed MAY contain a subset the Member Entries for a
a Collection. Instead, the Atom Feed document MAY contain link Collection. In addition, the Atom Feed document MAY contain link
elements with "rel" attribute values of "next", "previous", "first" elements with "rel" attribute values of "next", "previous", "first"
and "last" that can be used to navigate through the complete set of and "last" that can be used to navigate through the complete set of
matching entries. matching entries.
For instance, suppose a client is supplied the URI For instance, suppose a client is supplied the URI
"http://example.org/entries/go" of a Collection of Member entries, "http://example.org/entries/go" of a Collection of Member entries,
where the server as a matter of policy avoids generating feed where the server as a matter of policy avoids generating feed
documents containing more than 10 entries. The Atom Feed document documents containing more than 10 entries. The Atom Feed document
for the Collection will then represent the first 'page' in a set of for the Collection will then represent the first 'page' in a set of
10 linked feed documents. The "first" relation will reference the 10 linked feed documents. The "first" relation will reference the
skipping to change at page 30, line 5 skipping to change at page 29, line 30
href="http://example.org/entries/go" /> href="http://example.org/entries/go" />
<link rel="previous" <link rel="previous"
href="http://example.org/entries/go" /> href="http://example.org/entries/go" />
<link rel="next" <link rel="next"
href="http://example.org/entries/3" /> href="http://example.org/entries/3" />
<link rel="last" <link rel="last"
href="http://example.org/entries/10" /> href="http://example.org/entries/10" />
... ...
</feed> </feed>
10.2 The "app:edited" Element
The "app:edited" element is a Date construct as defined by [RFC4287]
whose value indicates the most recent instant in time when an entry
was edited, including when created. Atom entry elements in
Collection documents SHOULD contain one "app:edited" element, and
MUST NOT contain more than one.
appEdited = element app:edited ( atomDateConstruct )
The server SHOULD change the value of this element every time a
Collection Member Resource or an associated Media Resource has been
edited by any means.
11. Atom Format Link Relation Extensions 11. Atom Format Link Relation Extensions
11.1 The "edit" Link Relation 11.1 The "edit" Link Relation
This specification adds the value "edit" to the Atom Registry of Link This specification adds the value "edit" to the Atom Registry of Link
Relations (see section 7.1 of [RFC4287]). The value of "edit" Relations (see section 7.1 of [RFC4287]). The value of "edit"
specifies that the value of the href attribute is the IRI of an specifies that the value of the href attribute is the IRI of an
editable Member Entry. When appearing within an atom:entry, the href editable Member Entry. When appearing within an atom:entry, the href
IRI MAY be used to retrieve, update and delete the resource IRI can be used to retrieve, update and delete the resource
represented by that entry. An atom:entry MUST contain no more than represented by that entry. An atom:entry MUST contain no more than
one "edit" link relation. one "edit" link relation.
11.2 The "edit-media" Link Relation 11.2 The "edit-media" Link Relation
This specification adds the value "edit-media" to the Atom Registry This specification adds the value "edit-media" to the Atom Registry
of Link Relations (see section 7.1 of [RFC4287]). When appearing of Link Relations (see section 7.1 of [RFC4287]). When appearing
within an atom:entry, the value of the href attribute is an IRI that within an atom:entry, the value of the href attribute is an IRI that
MAY be used to modify a Media Resource associated with that entry. can be used to modify a Media Resource associated with that entry.
An atom:entry element MAY contain zero or more "edit-media" link An atom:entry element MAY contain zero or more "edit-media" link
relations. An atom:entry MUST NOT contain more than one atom:link relations. An atom:entry MUST NOT contain more than one atom:link
element with a rel attribute value of "edit-media" that has the same element with a rel attribute value of "edit-media" that has the same
type and hreflang attribute values. All "edit-media" link relations type and hreflang attribute values. All "edit-media" link relations
in the same entry reference the same resource. If a client in the same entry reference the same resource. If a client
encounters multiple "edit-media" link relations in an entry then it encounters multiple "edit-media" link relations in an entry then it
SHOULD choose a link based on the client preferences for type and SHOULD choose a link based on the client preferences for type and
hreflang. If a client encounters multiple "edit-media" link hreflang. If a client encounters multiple "edit-media" link
relations in an entry and has no preference based on the type and relations in an entry and has no preference based on the type and
skipping to change at page 31, line 34 skipping to change at page 31, line 34
The "app:control" element MAY appear as a child of an atom:entry The "app:control" element MAY appear as a child of an atom:entry
which is being created or updated via the Atom Publishing Protocol. which is being created or updated via the Atom Publishing Protocol.
The app:control element MUST appear only once in an Entry. The app: The app:control element MUST appear only once in an Entry. The app:
control element is considered foreign markup as defined in Section 6 control element is considered foreign markup as defined in Section 6
of [RFC4287]. of [RFC4287].
The app:control element and its child elements MAY be included in The app:control element and its child elements MAY be included in
Atom Feed or Entry Documents. Atom Feed or Entry Documents.
The app:control element MAY contain exactly one "app:draft" element The app:control element can contain an optional "app:draft" element
as defined below, and MAY contain zero or more extension elements as as defined below, and can contain extension elements as defined in
defined in Section 6 of [RFC4287]. Section 6 of [RFC4287].
12.1.1 The "app:draft" Element 12.1.1 The "app:draft" Element
The number of app:draft elements in app:control MUST be zero or one. The number of app:draft elements in app:control MUST be zero or one.
Its value MUST be one of "yes" or "no". A value of "no" indicates a Its value MUST be one of "yes" or "no". A value of "no" indicates a
client request that the Member Resource be made publicly visible. If client request that the Member Resource be made publicly visible. If
the app:draft element is missing then the value MUST be understood to the app:draft element is missing then the value MUST be understood to
be "no". The inclusion of the app:draft element represents a request be "no". The inclusion of the app:draft element represents a request
by the client to control the visibility of a Member Resource and the by the client to control the visibility of a Member Resource and the
app:draft element MAY be ignored by the server. app:draft element MAY be ignored by the server.
13. Securing the Atom Protocol 13. Securing the Atom Publishing Protocol
All instances of publishing Atom Format entries SHOULD be protected The Atom Publishing Protocol is based on HTTP. Authentication
by authentication to prevent posting or editing by unknown sources. requirements for HTTP are covered in Section 11 of [RFC2616].
[[anchor23: note: this section is currently under discussion.]]
The use of authentication mechanisms to prevent posting or editing by
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 connection
[RFC4346] as specified by [RFC2818].
The choice of authentication mechanism will impact interoperability.
The minimum level of security referenced above (Basic Auth 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 should, in general,
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 allows new authentication
schemes to 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
"Forbidden") in accordance with [RFC2617].
14. Security Considerations 14. Security Considerations
The security of the Atom Protocol is based on [[anchor25: note: As an HTTP-based protocol, APP is subject to the security
refers to incomplete section]]. considerations found in Section 15 of [RFC2616].
[[anchor26: note: talk here about denial of service attacks using 14.1 Denial of Service
large XML files, or the billion laughs DTD attack.]]
Atom Publishing server implementations need to take adequate
precautions to ensure malicious clients cannot consume excessive
server resources (CPU, memory, disk, etc).
14.2 Replay Attacks
Atom Publishing 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.
14.3 Spoofing Attacks
Atom Publishing implementations are susceptible to a variety of
spoofing attacks. Malicious clients may send Atom entries containing
inaccurate information anywhere in the document.
14.4 Linked Resources
Atom Feed and Entry documents can contain XML External Entities as
defined in Section 4.2.2 of [W3C.REC-xml-20060816]. 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.
14.5 Digital Signatures and Encryption
Atom Entry Documents sent to a server might contain XML Digital
Signatures [W3C.REC-xmldsig-core-20020212] and might be encrypted
using XML Encryption [W3C.REC-xmlenc-core-20021210] as specified in
Section 5 of [RFC4287].
Servers are allowed to modify received resource representations in
ways that can invalidate signatures covering those representations.
14.6 URIs and IRIs
Atom Publishing Protocol implementations handle URIs and IRIs. See
Section 7 of [RFC3986] and Section 8 of [RFC3987].
15. IANA Considerations 15. IANA Considerations
15.1 Content-type registration for 'application/atomserv+xml' 15.1 Content-type registration for 'application/atomserv+xml'
An Atom Publishing Protocol Service Document, when serialized as XML An Atom Publishing Protocol Service Document, when serialized as XML
1.0, can be identified with the following media type: 1.0, can be identified with the following media type:
MIME media type name: application MIME media type name: application
skipping to change at page 34, line 28 skipping to change at page 34, line 28
Optional parameters: Optional parameters:
"charset": This parameter has identical semantics to the charset "charset": This parameter has identical semantics to the charset
parameter of the "application/xml" media type as specified in parameter of the "application/xml" media type as specified in
[RFC3023]. [RFC3023].
Encoding considerations: Identical to those of "application/xml" as Encoding considerations: Identical to those of "application/xml" as
described in [RFC3023], section 3.2. described in [RFC3023], section 3.2.
Security considerations: As defined in this specification. Security considerations: As defined in this specification.
[[anchor27: update upon publication]] [[anchor31: update upon publication]]
In addition, as this media type uses the "+xml" convention, it In addition, as this media type uses the "+xml" convention, it
shares the same security considerations as described in [RFC3023], shares the same security considerations as described in [RFC3023],
section 10. section 10.
Interoperability considerations: There are no known interoperability Interoperability considerations: There are no known interoperability
issues. issues.
Published specification: This specification. [[anchor28: update upon Published specification: This specification. [[anchor32: update upon
publication]] publication]]
Applications that use this media type: No known applications Applications that use this media type: No known applications
currently use this media type. currently use this media type.
Additional information: Additional information:
Magic number(s): As specified for "application/xml" in [RFC3023], Magic number(s): As specified for "application/xml" in [RFC3023],
section 3.2. section 3.2.
skipping to change at page 35, line 16 skipping to change at page 35, line 16
Base URI: As specified in [RFC3023], section 6. Base URI: As specified in [RFC3023], section 6.
Macintosh File Type code: TEXT Macintosh File Type code: TEXT
Person and email address to contact for further information: Joe Person and email address to contact for further information: Joe
Gregorio <joe@bitworking.org> Gregorio <joe@bitworking.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: This specification's author(s). [[anchor29: Author/Change controller: This specification's author(s). [[anchor33:
update upon publication]] update upon publication]]
15.2 Content-type registration for 'application/atomcat+xml' 15.2 Content-type registration for 'application/atomcat+xml'
An Atom Publishing Protocol Category Document, when serialized as XML An Atom Publishing Protocol Category Document, when serialized as XML
1.0, can be identified with the following media type: 1.0, can be identified with the following media type:
MIME media type name: application MIME media type name: application
MIME subtype name: atomcat+xml MIME subtype name: atomcat+xml
skipping to change at page 35, line 40 skipping to change at page 35, line 40
Optional parameters: Optional parameters:
"charset": This parameter has identical semantics to the charset "charset": This parameter has identical semantics to the charset
parameter of the "application/xml" media type as specified in parameter of the "application/xml" media type as specified in
[RFC3023]. [RFC3023].
Encoding considerations: Identical to those of "application/xml" as Encoding considerations: Identical to those of "application/xml" as
described in [RFC3023], section 3.2. described in [RFC3023], section 3.2.
Security considerations: As defined in this specification. Security considerations: As defined in this specification.
[[anchor30: update upon publication]] [[anchor34: update upon publication]]
In addition, as this media type uses the "+xml" convention, it In addition, as this media type uses the "+xml" convention, it
shares the same security considerations as described in [RFC3023], shares the same security considerations as described in [RFC3023],
section 10. section 10.
Interoperability considerations: There are no known interoperability Interoperability considerations: There are no known interoperability
issues. issues.
Published specification: This specification. [[anchor31: update upon Published specification: This specification. [[anchor35: update upon
publication]] publication]]
Applications that use this media type: No known applications Applications that use this media type: No known applications
currently use this media type. currently use this media type.
Additional information: Additional information:
Magic number(s): As specified for "application/xml" in [RFC3023], Magic number(s): As specified for "application/xml" in [RFC3023],
section 3.2. section 3.2.
skipping to change at page 36, line 30 skipping to change at page 36, line 30
Base URI: As specified in [RFC3023], section 6. Base URI: As specified in [RFC3023], section 6.
Macintosh File Type code: TEXT Macintosh File Type code: TEXT
Person and email address to contact for further information: Joe Person and email address to contact for further information: Joe
Gregorio <joe@bitworking.org> Gregorio <joe@bitworking.org>
Intended usage: COMMON Intended usage: COMMON
Author/Change controller: This specification's author(s). [[anchor32: Author/Change controller: This specification's author(s). [[anchor36:
update upon publication]] update upon publication]]
15.3 Header field registration for 'SLUG'
[[anchor37: incomplete section --dehora]]
Header field: SLUG
Applicable protocol: http [RFC2616]
Status: standard.
Author/Change controller: IETF (iesg@ietf.org) Internet Engineering
Task Force
Specification document(s): draft-ietf-atompub-protocol-11.txt
([[anchor38: update on rfc number assignment --dehora]])
Related information:
16. References 16. References
16.1 Normative References 16.1 Normative References
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions)
Part Three: Message Header Extensions for Non-ASCII Text", Part Three: Message Header Extensions for Non-ASCII Text",
RFC 2047, November 1996. RFC 2047, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[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 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media
Types", RFC 3023, January 2001. Types", RFC 3023, January 2001.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication [RFC4287] Nottingham, M. and R. Sayre, "The Atom Syndication
Format", RFC 4287, December 2005. Format", RFC 4287, December 2005.
[W3C.REC-xml-20040204] [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., (TLS) Protocol Version 1.1", RFC 4346, April 2006.
and E. Maler, "Extensible Markup Language (XML) 1.0 (Third
Edition)", W3C REC REC-xml-20040204, February 2004. [W3C.REC-xml-20060816]
Bray, T., Paoli, J., Maler, E., Sperberg-McQueen, C., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fourth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20060816, August 2006.
[W3C.REC-xml-infoset-20040204] [W3C.REC-xml-infoset-20040204]
Cowan, J., Tobin, R., and A. Layman, "XML Information Set Cowan, J., Tobin, R., and A. Layman, "XML Information Set
(Second Edition)", W3C REC W3C.REC-xml-infoset-20040204, (Second Edition)", W3C REC W3C.REC-xml-infoset-20040204,
February 2004. February 2004.
[W3C.REC-xml-names-19990114] [W3C.REC-xml-names-20060816]
Hollander, D., Bray, T., and A. Layman, "Namespaces in Hollander, D., Bray, T., and A. Layman, "Namespaces in
XML", W3C REC REC-xml-names-19990114, January 1999. XML", World Wide Web Consortium Recommendation REC-xml-
names-20060816, August 2006.
[W3C.REC-xmlbase-20010627] [W3C.REC-xmlbase-20010627]
Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627, Marsh, J., "XML Base", W3C REC W3C.REC-xmlbase-20010627,
June 2001. June 2001.
[W3C.REC-xmldsig-core-20020212]
Solo, D., Reagle, J., and D. Eastlake, "XML-Signature
Syntax and Processing", World Wide Web Consortium
Recommendation REC-xmldsig-core-20020212, February 2002,
<http://www.w3.org/TR/2002/REC-xmldsig-core-20020212>.
[W3C.REC-xmlenc-core-20021210]
Eastlake, D. and J. Reagle, "XML Encryption Syntax and
Processing", World Wide Web Consortium Recommendation REC-
xmlenc-core-20021210, December 2002,
<http://www.w3.org/TR/2002/REC-xmlenc-core-20021210>.
16.2 Informative References 16.2 Informative References
[RNC] Clark, J., "RELAX NG Compact Syntax", December 2001. [RNC] Clark, J., "RELAX NG Compact Syntax", December 2001.
[W3C.REC-webarch-20041215] [W3C.REC-webarch-20041215]
Walsh, N. and I. Jacobs, "Architecture of the World Wide Walsh, N. and I. Jacobs, "Architecture of the World Wide
Web, Volume One", W3C REC REC-webarch-20041215, Web, Volume One", W3C REC REC-webarch-20041215,
December 2004. December 2004.
URIs URIs
skipping to change at page 41, line 5 skipping to change at page 41, line 10
Phone: +353-1-4927444 Phone: +353-1-4927444
Email: bill.dehora@propylon.com Email: bill.dehora@propylon.com
URI: http://www.propylon.com/ URI: http://www.propylon.com/
Appendix A. Contributors Appendix A. Contributors
The content and concepts within are a product of the Atom community The content and concepts within are a product of the Atom community
and the Atompub Working Group. and the Atompub Working Group.
[[anchor42: chairs to compile a contribution list for 1.0 --dehora]]
Appendix B. RELAX NG Compact Schema Appendix B. RELAX NG Compact Schema
This appendix is informative. This appendix is informative.
The Relax NG schema explicitly excludes elements in the Atom Protocol The Relax NG schema explicitly excludes elements in the Atom Protocol
namespace which are not defined in this revision of the namespace which are not defined in this revision of the
specification. Requirements for Atom Protocol processors specification. Requirements for Atom Protocol processors
encountering such markup are given in Section 6.2 and Section 6.3 of encountering such markup are given in Section 6.2 and Section 6.3 of
[RFC4287]. [RFC4287].
skipping to change at page 42, line 18 skipping to change at page 43, line 18
appCommonAttributes, appCommonAttributes,
( appWorkspace+ ( appWorkspace+
& extensionElement* ) & extensionElement* )
} }
# app:workspace # app:workspace
appWorkspace = appWorkspace =
element app:workspace { element app:workspace {
appCommonAttributes, appCommonAttributes,
( appCollection* ( atomTitle
& appCollection*
& extensionElement* ) & extensionElement* )
} }
atomTitle = element atom:title { atomTextConstruct } atomTitle = element atom:title { atomTextConstruct }
# app:collection # app:collection
appCollection = appCollection =
element app:collection { element app:collection {
appCommonAttributes, appCommonAttributes,
attribute href { atomURI }, attribute href { atomURI },
( appAccept? ( atomTitle
& appAccept?
& appCategories* & appCategories*
& extensionElement* ) & extensionElement* )
} }
# app:categories # app:categories
atomCategory = atomCategory =
element atom:category { element atom:category {
atomCommonAttributes, atomCommonAttributes,
attribute term { text }, attribute term { text },
skipping to change at page 43, line 9 skipping to change at page 44, line 10
appInlineCategories = appInlineCategories =
element app:categories { element app:categories {
attribute fixed { "yes" | "no" }?, attribute fixed { "yes" | "no" }?,
attribute scheme { atomURI }?, attribute scheme { atomURI }?,
(atomCategory*) (atomCategory*)
} }
appOutOfLineCategories = appOutOfLineCategories =
element app:categories { element app:categories {
attribute href { atomURI }, attribute href { atomURI },
(empty) undefinedContent
} }
appCategories = appInlineCategories | appOutOfLineCategories appCategories = appInlineCategories | appOutOfLineCategories
# app:accept # app:accept
appAccept = appAccept =
element app:accept { element app:accept {
appCommonAttributes, appCommonAttributes,
( appTypeValue? ) ( appTypeValue? )
skipping to change at page 47, line 7 skipping to change at page 48, line 7
element * - atom:* { element * - atom:* {
(attribute * { text } (attribute * { text }
| text | text
| anyElement)* | anyElement)*
} }
# EOF # EOF
Appendix C. Revision History Appendix C. Revision History
draft-ietf-atompub-protocol-11: Parts of PaceAppEdited.
PaceSecurityConsiderationsRevised.
draft-ietf-atompub-protocol-10: PaceRemoveTitleHeader2, draft-ietf-atompub-protocol-10: PaceRemoveTitleHeader2,
PaceSlugHeader4, PaceOnlyMemberURI,PaceOneAppNamespaceOnly, PaceSlugHeader4, PaceOnlyMemberURI,PaceOneAppNamespaceOnly,
PaceAppCategories, PaceExtendIntrospection, PaceAppCategories, PaceExtendIntrospection,
UseElementsForAppCollectionTitles3, renamed Introspection to Service, UseElementsForAppCollectionTitles3, renamed Introspection to Service,
lots of good editorials suggestions, updated media example with slug, lots of good editorials suggestions, updated media example with slug,
moved xml conventions to convention sections, renamed XMl related moved xml conventions to convention sections, renamed XMl related
Conventions to Atom Publishing Protocol Documents, added auth header Conventions to Atom Publishing Protocol Documents, added auth header
to examples, consolidated definition of all resource types into the to examples, consolidated definition of all resource types into the
model section, added IANA reg info for application/atomcat+xml. model section, added IANA reg info for application/atomcat+xml.
 End of changes. 81 change blocks. 
157 lines changed or deleted 307 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/