The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: December 28, 2007
Atom Publishing Format and Protocol

Final Deliverables:

Update 2005-12-09: In August 2005, the IESG announced the approval of "The Atom Syndication Format" as an IETF Proposed Standard. On December 05, 2005 the IETF issued RFC 4287: The Atom Syndication Format as an official RFC. Mark Nottingham: "Atom has finally realised its most important advantage over the various flavours of RSS: it's a Standards-Track RFC. What does this mean? It doesn't mean that it's (necessarily) technically better, is easier to use, or will be more broadly adopted. Hopefully, it will have these things due to the quality of the WG participants and exposure to the resources of the IETF. What it does mean is that there isn't any contention at all about who owns it and the specification is stable, with a well-understood change process. This doesn't sound like much, but it can be sorely missed when you don't have it, whether you're dealing with a single person or with a huge company..."

Overview

On June 16, 2004 the Internet Engineering Steering Group (IESG) announced the formation of an Atom Publishing Format and Protocol Working Group (atompub) in the IETF Applications Area. According to the initial Working Group Charter, Atom "defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern."

On October 22, 2007 the IESG announced the completion of the Atom Publishing Format and Protocol WG: The AtomPub WG was chartered to work on two items: the syndication format in RFC 4287, and the publishing protocol in RFC 5023. Implementations of these specs have been shown to work together and interoperate well to support publishing and syndication of text content and media resources. Since both documents are now Proposed Standards, the WG has completed its charter and therefore closes as a WG. A mailing list will remain open for further discussion. Congratulations and thanks to the chairs Tim Bray and Paul Hoffman, to the editors of the two WG RFCs (Mark Nottingham, Robert Sayre, Bill de HÓra and Joe Gregorio), and to the many contributors and implementors. The IESG contact persons are Lisa Dusseault and Chris Newman.

IETF atompub Working Group Charter

Extracted from the initial IETF Working Group announcement:

IETF atompub Working Group Chair(s)

Paul Hoffman <paul.hoffman@vpnc.org>
Tim Bray <tbray@textuality.com>

Applications Area Director(s)

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor

Scott Hollenbeck <sah@428cobrajet.net>

Secretary(ies)

Sam Ruby <rubys@intertwingly.net>

Mailing Lists

General Discussion: atom-syntax@imc.org
To Subscribe: atom-syntax-request@imc.org
In Body: subscribe
Archive: http://www.imc.org/atom-syntax/mail-archive/

Description of Working Group

Atom defines a feed format for representing and a protocol for editing Web resources such as Weblogs, online journals, Wikis, and similar content. The feed format enables syndication; that is, provision of a channel of information by representing multiple resources in a single document. The editing protocol enables agents to interact with resources by nominating a way of using existing Web standards in a pattern.

Atom consists of:

  • A conceptual model of a resource
  • A concrete syntax for this model
  • A syndication and archiving format (the Atom feed format) using this syntax
  • An editing protocol using this syntax

The format must be able to represent:

  • a resource that is a Weblog entry or article (e.g., it has an author, date, identifier, and content)
  • a feed or channel of entries, with or without enclosed content
  • a complete archive of all entries in a feed
  • existing well-formed XML (especially XHTML) content
  • additional information in an user-extensible manner

The editing protocol must enable:

  • creating, editing, and deleting feed entries
  • multiple authors for a feed
  • multiple subjects or categories in a feed
  • user authentication
  • adding, editing, and deleting users
  • setting and getting user preferences
  • creating, getting and setting related resources such as comments, templates, etc.

The working group will use experience gained with RSS (variably used as a name by itself and as an acronym for "RDF Site Summary", "Rich Site Summary", or "Really Simple Syndication") as the basis for a standards-track document specifying the model, syntax, and feed format. The feed format and HTTP will be used as the basis of work on a standards-track document specifying the editing protocol. The goal for the working group is to produce a single feed format and a single editing protocol; the working group will only consider additional formats or additional protocols if those charter changes are approved by the IESG.

The working group will also take steps to ensure interoperability, by:

  • unambiguously identifying required elements in formats
  • clearly nominating conformance levels for different types of software
  • providing clear extensibility mechanisms and constraints upon them

The Atom protocol will be designed to provide security services for updating and accessing dynamic online resources. The working group will consider current known issues with requirements for remote access, along with the fact that many such resources are constrained by providers who provide the resource owners with little configuration control.

The working group's primary focus will be on delivering an interoperable format and corresponding protocol; it is expected that all but the most basic, generic metadata and functions will be accommodated through extensions, rather than in the core documents.

Extension development is not included in this charter. The working group will consider the need to either close or to modify the charter and document extensions once the core document set has been approved by the IESG.

Atom Before the IETF Working Group

As of October 2003, when the Atom project was growing in the wild, an had no official home in a standards organization:

Overview

The Atom Project, to the extent that anyone can declare authoritatively what it is, or is quintessentially meant to support, is "an initiative to develop a common syntax for syndication, archiving, and publishing." Sam Ruby (Emerging Technologies Group, IBM) is most often credited for originating the core ideas, and design work spread across several wikis and weblog Internet sites is now being shared by some of the brightest developer minds focused upon the future of Web content creation and distribution.

The developers agree that Atom "will be vendor neutral, implemented by everybody, freely extensible by anybody, and cleanly and thoroughly specified." Atom is sometimes characterized as the successor to RSS (Really Simple Syndication or RDF Site Summary), which is variably used for news headline syndication, website metadata description, and content syndication. Like RSS, Atom is being created through an informal consensus process by volunteers in the Web developer community at large.

Sam Ruby appears to recognize that the function of Atom will be revealed in unpredictable ways, escaping any telos imagined by the current designers. The key insights are these: design Atom such that content is not treated as a second class citizen (allow its conceptual model and syntax to blur the subjective distinction between metadata and data); insist upon a uniform mechanism for expressing the core concepts independent of the usage (e.g., allow multiple implementation designs conforming to abstract API requirements, and anticipate multiple schema formalisms for validation); keep the format open and simple (e.g., not requiring special serialization of the XML, implementable using simple POST and GET operations under HTTP).

The Atom design is envisioned as extensible for different application areas (license terms, access control, content categorization, versioning, related resources, etc.) The core features are those common to most creations of intellectual works: source/author, editing date(s), resource identifier/location, and content. Given these minimal but central goals, we can understand the simplicity and generality of the abstract for the draft Atom API specification: the API document "presents a technique for using XML and HTTP to edit content." In this context, "edit" means "read, write, modify, delete" (approximately: GET, POST, PUT, DELETE).

The goal of extreme generality remains in tension with the competing objective of ensuring that the new syndication format, while extensible, has predictable consistency at the semantic level. This probably means that the formalism in final draft will specify some required elements. In particular, if an agreed design goal is to capture time sensitive information, then an element for time information would be required. In the draft syntax description [as of 2003-10-22], the top-level <feed> element has required subelements title, link, modified (date in UTC), and author. An <entry> element would have required subelements title, link (URI permanent link), id, issued (W3DTF +/- timezone), and modified.

RoadMap snapshot for Atom (Echo/Pie) as of 2003-10-17: The project roadmap involves: "(1) Decide on the conceptual model of a log entry. Primer, ConceptualModel; (2) Decide on a syntax for this model. Syntax, SyntaxConsiderations; (3) Build a syndication format using this syntax; (4) Build an archiving format using this syntax; (5) Build a weblog editing protocol using this syntax (the Atom API)." According to this RoadMap document, sixty-some companies have pledged support for Atom (aka Echo/Pie/etc) along with 170+ individual developers.

The Internet domain intertwingly.net is host for Sam Ruby's weblog and for the Atom Project wiki, both serving as publication organs for Atom design and development. The www.intertwingly.net "It's Just Data" blog for Atom and related topics is built in XHTML 1.1 code. This is important to one of Sam Ruby's goals for the new syndication format: a desire to enable such things as XPath queries over the content. A blog entry for September 26, 2003 "Fun with XPath" documents some of the details.

Note: Descriptive text above is based in part upon a summary provided by Sam Ruby. Sam presented an overview of Atom at the News Standards Summit on December 8, 2003 (XML 2003 venue).

Atom Entry and Content Model

The content, structure, and (lexical) syntax for Atom <entry> and <content> elements are still [2003-10] under discussion. Mark Pilgrim presents draft examples and some of the key concepts in his article "The Atom API," published by XML.com. Excerpts:

[An Atom entry has] "lots of information: a title, an excerpt or summary, and an author who has a name, email address, and URL of his own. The entry has a 'created' date and a 'modified' date (usually server-generated), and an 'issued' date (which is a date that the author would like to give to this entry, separate from when he actually posted it). The entry is viewable at a specific link, has an internal ID (a URN), and finally has some XHTML content.

The Atom content model is probably worth a whole article by itself, but for the moment let me just handwave and say that it can handle more than just XHTML. Any MIME type can be expressed (specify it in the @type attribute), and non-XML content (such as HTML or plain text) is simply escaped or put in a CDATA block, with a mode="escaped" attribute on the content element. It can even handle binary content (such as an image) by specifying @mode="base64" and including a base64-encoded representation of the data...

The Atom API has several other methods beyond add, edit, delete, retrieve, search. It can be used for posting comments on entries, managing users and user preferences, managing categories, managing site templates; eventually it will be usable for everything you can do manually with your weblog through your server's browser-based interface... [As for] Atom authentication: it does not involve sending plain text passwords in the clear..."

Principal URLs

IETF Internet Drafts

See also the list of individual IDs.

The Atom Syndication Format. IETF Network Working Group, Request for Comments #4287. Category: Standards Track. December, 2005. 43 pages. Atom Syndication Format namespace: http://www.w3.org/2005/Atom. See the announcement. HTML format. See also the XML format version, the Windows Help format, Adobe PDF, and RFC dependencies. [source]

The Atom Publishing Protocol. IETF Network Working Group, Request for Comments #5023. Category: Standards Track. October 2007. 53 pages. Atom Publishing Protocol namespace: http://www.w3.org/2007/app. HTML format from Julian Reschke, or HTML format from IETF. Also, from Julian Reschke: XML format, text in Windows Help format, Adobe PDF, and RFC dependencies. [source]

"The Atom Syndication Format." Approved by the IESG as an IETF Proposed Standard. Awaiting an RFC number. Edited by Mark Nottingham [WWW] and Robert Sayre [WWW]. Preliminary draft contributions from Tim Bray, Mark Pilgrim, and Sam Ruby; Norman Walsh provided the Relax NG schema. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-11'. August 15, 2005, expires February 16, 2006. 56 pages. See the IESG announcement: "Protocol Quality: Scott Hollenbeck and the XML Directorate have reviewed the specification for the IESG. Test implementations have confirmed basic protocol soundness." See HTML and the RELAX NG RNC grammar.

  • [December 18, 2007] "FIQL: The Feed Item Query Language." By Mark Nottingham [Blog]. January 12, 2007. Expires June 14, 2008. 16 pages. Reference: 'draft-nottingham-atompub-fiql-00'. An initial public draft of "FIQL: The Feed Item Query Language" has been released. The Feed Item Query Language (FIQL, pronounced "fickle") is a simple but flexible, URI-friendly syntax for expressing filters across the entries in a syndicated feed. For example, a query "title==foo*;(updated=lt=-P1D,title==*bar)" would return all entries in a feed that meet the following criteria; (1) have a title beginning with "foo", AND (2) have been updated in the last day OR have a title ending with "bar". The specification defines an extensible syntax for FIQL queries, explains their use in HTTP, and defines feed extensions for discovering and describing query interfaces. On the Atom syntax list, the author responded to a question "Why not XPath or XQuery or SPARQL (with an Atom/RDF mapping), or CSS selectors or some subset of one of those?" Mark says: "In a nutshell, there are two reasons; [i] Those query languages are optimised for data models that aren't feeds; respectively, XML Infosets, Infosets again, RDF graphs and CSS cascades. While it's possible to contort them to fit feeds, they don't really lend themselves to it. XQuery and SPARQL also present a fairly high barrier to adoption (if you're not a big XML vendor or a SW-head, respectively ;) Contorting them so that they're easy to fit into a URL isn't too attractive, either. [ii] When you expose a query interface, you're allowing people to consume compute power on your servers. An arbitrary query language allows arbitrary queries, which is unacceptable when you're working across administrative domains. FIQL gives you tools to constrain how queries are shaped. I've been asked this many times, and should probably add it as a FAQ in an appendix. Certainly there are use cases for using XQuery, etc. against feeds, but it's also become apparent that there's a place for something simple, reasonably flexible, and Web-friendly."

  • [July 11, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra. July 09, 2007, expires January 10, 2008. IETF Network Working Group, Internet Draft 'draft-ietf-atompub-protocol-17.txt'. Status: IETF Proposed Standard. HTML format; XML. I-D Tracker, DataTracker Detail Info. diff 17-vs-16 [alt]. From the announcement: "The IESG has approved the The Atom Publishing Protocol ('draft-ietf-atompub-protocol-17.txt') as a Proposed Standard. This document is the product of the IETF Atom Publishing Format and Protocol Working Group. The IESG contact persons are Lisa Dusseault and Chris Newman. Technical Summary: The Atom Publishing Protocol HTTP-based protocol for publishing and editing web resources, and is particularly useful for (but not limited to) blogs. It supports ideas such as collections of multimedia items and categorization of items. It uses the Atom Format (RFC 4287) for its messages. Working Group Summary: The document went through many revisions and was discussed actively. Protocol Quality: There are already many implementations of the spec from a wide variety of vendors, and many of those have been shown to interoperate. Lisa Dusseault reviewed this for the IESG. Mimimal changes from -v16: (1) Section 12: 'an optional "type" parameter' -->> 'a "type" parameter'; (2) Section 14 deleted [duplicate] text: "At a minimum, client and server implementations MUST be capable of being configured to use HTTP Basic Authentication [RFC 2617] in conjunction with a TLS 1.0 [RFC 2246] or a subsequent standards-track version of TLS, supporting the conventions for using HTTP over TLS described in [RFC2818]." See v -16 and the diff.

  • [July 05, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra. June 27, 2007, expires December 29, 2007. IETF Network Working Group, Internet Draft 'draft-ietf-atompub-protocol-16.txt'. 67 pages. Atompub Status: IESG Processing, IESG Evaluation — AD Followup (New version available, Sub state has been changed to AD Follow up from New ID Needed). Intended Status: Standards Track. Announced ("I-D ACTION:draft-ietf-atompub-protocol-16.txt"); source .TXT; I-D Tracker. With -16 vs. -15 diff version format. "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 documented in the Atom Syndication Format." Changes: (1) Note change to NS URI http://www.w3.org/2007/app in 6.1 and passim, also reflected in the RELAX NG Compact Syntax Grammar for the Atom Protocol: "A Category Document (Section 7) contains lists of categories specified using the 'atom:category' element from the Atom Syndication Format... A Service Document (Section 8) groups available Collections into Workspaces. The namespace name for either kind of document is: http://www.w3.org/2007/app. The namespace document at new NS URI reports: The namespace name http://www.w3.org/2007/app is intended for use as per The Atom Publishing Protocol, work in progress by the IETF atompub Working Group, issued 8-Jun-2007 by Dan Connolly, W3C/IETF liaison on behalf of the W3C Director to Tim Bray and Paul Hoffman, atompub WG chairs. (2) added inplementation note in Section 9.7.1 (Slug: Header syntax); (3) added text in Section 15 (Security Considerations): "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." (4) added clarification in Section 15.5 (Digital Signatures and Encryption): "Neither servers nor clients are under any obligation to support encryption and digital signature of entries or feeds... A server is allowed to strip client-applied signatures..."

  • [June 05, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). May 22, 2007, expires November 23, 2007. IETF Network Working Group, Internet Draft 'draft-ietf-atompub-protocol-15.txt'. 68 pages. Status: IESG Evaluation. Intended Status: Standards Track. Announced ("I-D ACTION:draft-ietf-atompub-protocol-15.txt"); source .TXT; I-D Tracker. Also HTML, XML, with -15 vs. -14 diff version format. "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 as documented in the Atom Syndication Format RFC. The protocol supports the creation of Web Resources and provides facilities for: (1) Collections: Sets of Resources, which can be retrieved in whole or in part; (2) Services: Discovery and description of Collections; (3) Editing: Creating, editing, and deleting Resources. The Atom Publishing Protocol is different from many contemporary protocols in that the server is given wide latitude in processing requests from clients..."

  • [March 04, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). March 04, 2007, expires September 05, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-14.txt'. 64 pages. Other: HTML version, XML version. Also: the -14 vs. -13 diff version format and the ATOMPUB Status Pages. Revision History notes: 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 Resource and Media Resource terms defs; 6.1 para split; 10.1 collection paging, rewrote for clarity; 13.1.1 app:edited rewrote for clarity/conflict; text for GETting entries and cache handling; 4: Typo: "And Media Resources IRIs", s/Resources/Resource/; consensus call: 'application/atomsvc+xml', extension is .atomsvc; DRY app: categories; make it clear the app:draft support is optional whether or not the value is sent; 9.2: put related ideas together into paragraphs.; 10: partial list editing; security: use elharos text; app:edited: tweak text suplied by ari; create a section for workspaces and move the descriptive text there; Moved rfc2818 to non-normative references. Added the W3C note on lost updates as a reference. I-D Tracker. Status is Last Call; see the IESG discussion.

  • [February 26, 2007] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). February 9, 2007, expires August 9, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-13.txt'. 59 pages. Other: HTML version, XML version. Also: the -13 vs. -12 diff version format and the ATOMPUB Status Pages. Revision History notes: "Added Lisa's verbiage. Folded in James' Atom Format media type 'type' parameter spec. Updated document references to be more consistent, added URLs to some, and shortened up their anchors. Debugged rnc."

  • [December 27, 2006] The Atom Publishing Protocol. Edited by Joe Gregorio (IBM) and Bill de hOra (Propylon Ltd). December 10, 2006, expires June 13, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-12.txt'. 57 pages. ID Tracker. Other: HTML version, XML version. Also: the -12 vs. -11 diff version format and the ATOMPUB Status Pages.

  • [September 12, 2006] Last Call I-D. The Atom Publishing Protocol. Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). September 05, 2006, expires March 9, 2007. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-10.txt'. 51 pages. ID Tracker. Other: HTML version, XML version. See also the diff with v-09 and ATOMPUB Status Pages. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (RFC 4287). The protocol supports the creation of arbitrary web resources and provides facilities for: (1) Collections: Sets of resources, which can be retrieved in whole or in part; (2) Service: Discovering and describing Collections; (3) Editing: Creating, updating and deleting resources. The Atom Publishing Protocol uses HTTP methods to edit and author Member Resources as follows: [a] GET is used to retrieve a representation of a known resource; [b] POST is used to create a new, dynamically-named, resource; [c] PUT is used to update a known resource; [d] DELETE is used to remove a known resource. Along with operations on Member Resources the Atom Protocol defines Collection resources for managing and organizing Member Resources. Collections are represented by Atom Feed documents and contain the IRIs of, and metadata about, their Member Resources. There are two kinds of Member Resources - Member Entry Resources and Media Resources. Member Entry Resources are represented as Atom Entries. Media Resources MAY have representations in any media type. A Media Link Entry is a Member Entry that contains metadata about a Media Resource. Collections, represented by Atom feeds, contain entries. Those entries contain the Member Entry and Media Resources IRIs of the Collection. A Collection can contain any number of entries of either kind. In the diagram of a Collection below there are two entries. The first contains the IRI of a Member Entry Resource. The second contains the IRIs of both a Media Resource and a Media Link Entry Resource, which contains the metadata for that Media Resource..." From Appendix C (Revision History): V10 incorporates "PaceRemoveTitleHeader2, PaceSlugHeader4, PaceOnlyMemberURI,PaceOneAppNamespaceOnly, PaceAppCategories, PaceExtendIntrospection, UseElementsForAppCollectionTitles3, renamed Introspection to Service, lots of good editorial suggestions, updated media example with slug, moved xml conventions to convention sections, renamed XML related Conventions to Atom Publishing Protocol Documents, added auth header to examples, consolidated definition of all resource types into the model section, added IANA registration information for application/atomcat+xml."

  • [June 23, 2006] "Atom Threading Extensions." Edited by James M. Snell (IBM WebAhead Development Lab). IETF Internet Draft. Announcement. Reference: 'draft-snell-atompub-feed-thread-12.txt'. May 25, 2006, expires November 26, 2006. 13 pages. See the I-D Tracker for versions. James Snell, a member of IBM's WebAhead development lab, reported that the Internet Engineering Steering Group (IESG) has approved the "Atom Threading Extension" specification as a Proposed Standard. It's now in the RFC Editor queue awaiting final edits and its very own RFC number. The "Atom Threading Extensions" document describes a mechanism that allows feeds publishers to express threaded discussions within the Atom Syndication Format (RFC 4287). The specification defines an 'in-reply-to' extension element, used to indicate that an entry is a response to another resource. The element MUST contain a "ref" attribute identifying the resource that is being responded to. The element is not unlike the references and in-reply-to email message headers defined by RFC 2822. However, unlike the in-reply-to header, the "in-reply-to" element is required to identify the unique identifier of only a single parent resource. If the entry is a response to multiple resources, additional "in-reply-to" elements MAY be used. A new 'replies' link relation is also defined: an Atom link element with a rel attribute value of "replies" may be used to reference a resource where responses to an entry may be found. If the type attribute of the atom:link is omitted, its value is assumed to be "application/atom+xml". A "replies" link appearing as a child of the Atom feed or source element indicates that the referenced resource likely contains responses to any of that feed's entries..."

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). February 01, 2006, expires August 05, 2006. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-08.txt'. 41 pages. See the announcement and ID Tracker. Other: HTML version, XML version, -08 vs -07 diff. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format (RFC4287)." From Appendix C, 'Revision History': added infoset ref; added wording re IRI/URI; fixed URI/IRI; next/previous fixed as per Atom LinkRelations Attribute; incorporated: PaceEditLinkMustToMay; PaceMissingDraftHasNoMeaning, PaceRemoveMemberTypeMust, PaceRemoveMemberTypePostMust, PaceTitleHeaderOnlyInMediaCollections, PacePreserveForeignMarkup, PaceClarifyTitleHeader, PaceClarifyMediaResourceLinks, PaceTwoPrimaryCollections.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). January 01, 2006, expires July 5, 2006. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-07.txt'. 40 pages. ID Tracker. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format specification (IETF RFC #4287)." From Appendix C, 'Revision History': updated Atom refs to RFC 4287; incorporated PaceBetterHttpResponseCode; PaceClarifyCollectionAndDeleteMethodByWritingLessInsteadOfMore; PaceRemoveAcceptPostText; PaceRemoveListTemplate2; PaceRemoveRegistry; PaceRemoveWhoWritesWhat; PaceSimplifyClarifyBetterfyRemoveBogusValidityText; PaceCollectionOrderSignificance; PaceFixLostIntrospectionText; PaceListPaging; PaceCollectionControl; element typo in Listing collections para3 (was app:member-type, not app:list-template); changed post atom entry example to be valid. Dropped inline use of 'APP'. Removed nested diagram from section 4. Added ed notes in the security section.

  • "APP Service Description Format." By Robert Sayre October 25, 2005, expires April 28, 2006. IETF Network Working Group. Internet Draft 'draft-sayre-atompub-protocol-outline-01.txt'. 9 pages. "This memo presents an XML format used to describe Atom Publishing Protocol services. These services typically expose one or more groupings of resources. On a blogging service, for example, each grouping might represent a distinct blog and associated resources. Many Atom Publishing Protocol applications require a basic resource layout in order to ease configuration requirements. XML documents are organized hierarchically, but XML does not differentiate between elements serving as structural divisions and elements serving as structural properties. This specification defines two elements which outline the structure of APP services, and defines minimal user agent conformance rules. The specification includes a normative RELAX NG Compact schema."

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). October 27, 2005, expires April 30, 2006. IETF Network Working Group. Internet Draft 'draft-ietf-atompub-protocol-06.txt'. 41 pages. "The Atom Publishing Protocol (APP) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transport of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format." Version -06: Added in PaceCollectionControl. Fixed all the {daterange} verbage and examples so they all use a dash. Added full rnc schema. Collapsed Introspection and Collection documents into a single document. Removed {dateRange} queries. Renamed search to list. Moved discussion of media and entry collection until later in the document...

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Bill de hOra (Propylon Ltd). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-05.txt'. October 11, 2005, expires April 14, 2006. Updates the previous draft of May 09, 2005. 42 pages. See the diff against version -04. Versions: see the I-D Tracker. See also HTML and XML. Version -05: "Added diagrams and description to model section. Incorporates PaceAppDocuments, PaceAppDocuments2, PaceSimplifyCollections2 (large-sized chunks of it anyhow: the notions of Entry and Generic resources, the section 4 language on the Protocol Model, 4.1 through 4.5.2, the notion of a Collection document, as in Section 5 through 5.3, Section 7 'Collection resources', Selection resources (modified from pace which talked about search); results in major mods to Collection Documents, Section 9.2 'Title: Header' and brokeout para to section 9.1 Editing Generic Resources). Added XML namespace and language section. Some cleanup of front matter. Added Language Sensitivity to some attributes. Removed resource descriptions from terminology. Some juggling of sections." Unofficial draft-ietf-atompub-protocol-06 (Section 9 uses atom:updated for the ordering of collections).

  • [September 09, 2005] "Atom Link No Follow." By James M. Snell [WWW]. IETF Network Working Group. Internet-Draft. Reference: 'draft-snell-atompub-feed-nofollow-00.txt'. August 2005, expires February 2, 2006. 7 pages. HTTP scheme URI namespace name: http://purl.org/atompub/nofollow/1.0. An initial individual IETF Internet Draft has been published for "Atom Link No Follow," presenting a mechanism that allows Atom feed publishers to express preferences for how an Atom consumer should processe Atom links and Content-By-Reference. It thus conveys information to applications consuming Atom documents how they should handle links and referenced content contained within the feed. For example, a publisher may include an enclosure link within a feed but may not wish for applications to automatically download the enclosed file when it processes the feed; or, the publisher may not wish to allow applications to archive or index the enclosure in any way. The follow, index and archive attributes introduced herein provide the means for publishers to express these preferences. The x:follow attribute indicates whether applications should automatically attempt to follow links and referenced content (e.g., boolean, whether or not enclosure links should be automatically downloaded, etc). A value of 'no' indicates that applications should not attempt to automatically resolve the referenced resource — rather, the application should wait until a user explicitly requests the resource to be resolved. The x:index attribute indicates whether applications should index links and referenced content. The x:archive attribute indicates whether applications should archive the targets of links and content references..."

  • [September 09, 2005] "Atom Entry Expiration: Specifying Expiration Timestamps for Atom Entry Metadata." By James M. Snell [WWW]. IETF Network Working Group. Internet-Draft. Reference: 'draft-snell-atompub-feed-expires-01.txt'. August 2005, expires February 2, 2006. 8 pages. This document specifies a mechanism that allows the expression of expiration timestamps and maximum age properties for information content within the Atom Syndication Format. The mechanism defines two mutually exclusive extension elements that may be used to specify either an exact instant that the information content of an atom:entry expires, or a maximum age from the moment specified by an entries atom:updated element. When an atom:feed, atom:entry or atom:source contains an 'expires' or 'max-age' extension element, the information content of the contained element is considered to be 'time constrained'. Time constrainted information content is considered to be either 'active' or 'expired'. The default state is 'active'. When the age (calculated in milliseconds from the moment specified by the atom:updated element) exceeds the value specified by the 'max-age' extension, or when the moment specified by the 'expires' extension elements passes, the state of the time constrained information content MUST be considered to be 'expired' and no longer valid. It is strongly recommended that implementations either discard 'expired' information content or otherwise warn users that the information content has expired. The mechanism defined herein MUST NOT be used to support the caching of Atom documents and MUST NOT be used to schedule when a client should revisit/refresh local copies of Atom documents. Specifically, the 'expires' and 'max-age' extension elements are relevant only to the informational content within an atom:entry and are not relevant to the Atom Feed and Entry Documents in which they happen to appear..."

  • "Feed History: Enabling Incremental Syndication." By Mark Nottingham (BEA Systems) [WWW]. IETF Network Working Group. Internet-Draft: 'draft-nottingham-atompub-feed-history-04'. September 1, 2005, expires March 5, 2006. Changes in version -04: [1] fh:stateful -> fh:incremental, with appropriate changes in text; [2] more explicit cardinality information; [3] implications of fh:prev being an Absolute URI spelled out; [4] more explicit white space handling; [5] added Acknowledgements section. "Syndication documents (e.g., those in formats such as Atom and RSS usually only contain the last several entries in a larger channel (or 'feed') of information. Often, consuming software keeps copies of all entries that have been previously seen, effectively keeping a history of the feed's contents. However, not all feeds benefit from this practice; in some, previous entries are not relevant to the current contents of the feed. For example, it's not desireable to keep history in this manner with a 'top ten' feed; showing old entries would imply that the previous number one is now number eleven, and so forth... This document specifies a mechanism that allows feed publishers to give hints as to the completeness of a feed, and a means of retrieving 'missed' entries from a partial, or incremental, feed. Although it refers to Atom normatively, the mechanism described herein can be used with similar syndication formats, such as the various flavours of RSS." Later versions: see Datatracker.

  • "XHTML Microformats for the Atom Publishing Protocol." By Robert Sayre [WWW]. IETF Network Working Group. Internet-Draft: 'draft-sayre-atompub-xhtml-micro-00.txt'. September 3, 2005, expires March 7, 2006. 32 pages. "Atom Publishing Protocol [APP] client implementations require a fair amount of ancillary server-provided data in order to provide a smooth user experience. Rather than invent a plethora of new XML formats, this specification chooses to present a number of XHTML profiles, colloquially known as 'microformats'... hCat is an XHTML profile for encoding the three standard attributes of Atom category elements. By providing a definition list containing encoded category information, servers can present clients with a list of known categories in an XHTML definition list. hCat also allows description of endpoints for category editing through a simple HTTP-based protocol... HTTP provides response codes which indicate the success or failure of a given request, but does not go into great detail on textual diagnostics for the end-user. hError is an XHTML profile that encodes error information intended for the end-user..." See also: Microformats. Later versions: IETF datatracker lookup.

  • Cooked! The Atom Syndication Format. Edited by Mark Nottingham [WWW] and Robert Sayre [WWW]. Preliminary draft contributions from Tim Bray, Mark Pilgrim, and Sam Ruby; Norman Walsh provided the Relax NG schema. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-10'. July 11, 2005, expires January 12, 2006. 56 pages. XHTML and HTML, both usefully hyperlinked. Appendix C 'Change Log' identifies these changes in version -10: (1) capitalize "Atom Document" consistently; (2) fix atom:feed/atom:logo; (3) fix link hreflang/alternate in atom:feed; (4) add more acknowledgements; (5) expand security section; (6) clarify IRI processing.

  • "Feed License Link Relation." Edited by James M. Snell [alt jasnell@gmail.com]. IETF Network Working Group, Internet Draft. Reference: 'draft-snell-atompub-feed-license-00.txt'. July 02, 2005, expires January 02, 2006. 6 pages. "This document specifies a mechanism that allows the feed publishers the ability to associate copyright licenses with feeds and entries. Licenses associated with feeds and entries using these mechanisms MAY or MAY not be machine readable and are intended to communicate the various rights and obligations others may have with regards to given resource. specification defines one new Atom link relation type to be registered in the IANA Registry of Link Relations as defined by Atompub version -10." According to the August 09, 2005 posting: "As a reminder, the license extension provides a link relation for associating a copyright license with a feed or entry. The most common use case will be to associate creative commons licenses with feeds." See also relLicense microformat.

  • "Feed Index: Enabling Ordered Entries in Atom." By James M. Snell [WWW]. IETF Network Working Group. Internet Draft: 'draft-snell-atompub-feed-index-00.txt'. July 19, 2005, expires January 20, 2006. "This memo presents a mechanism that allows feed publishers to establish a numeric sorting index for the entries contained within a feed."

  • The Atom Syndication Format. Edited by Mark Nottingham [WWW] and Robert Sayre [WWW]. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-09. June 07, 2005, expires December 9, 2005. 53 pages. ID tracker. See Atom Specification Sent to IESG for Final Review, a communication between Paul Hoffman and Scott Hollenbeck on submission of the Atom version -09 draft to the IESG for final review, following changes made during and after the IETF Last Call. Note from Tim Bray to 'atom-syntax@imc.org' list June 08, 2005, speaking in "co-chair-mode": "This is what we consider our final product, and what we'll be taking forward through the IETF process; stand by for further news on that. Perhaps more important, this means that it's time to focus 100% of our time on the protocol work." Note the Timing Guide for Atom Implementers.

  • Atom Feed Autodiscovery. Edited by Mark Pilgrim (IBM) and Phil Ringnalda. IETF ATOMPUB Working Group. Reference: Internet Draft 'draft-ietf-atompub-autodiscovery-01.txt'. May 10, 2005, expires November 11, 2005. 14 pages. This document specifies a machine-readable method of linking to an Atom feed from a HyperText Markup Language (HTML) or Extensible HyperText Markup Language (XHTML) document, using the <link> element. See also the HTML and -01/-00 diff. See also pre-draft version -02.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Robert Sayre (Boswijck Memex Consulting). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-04.txt'. May 09, 2005, expires November 10, 2005. Updates the previous draft of March 18, 2005. 36 pages. See also HTML and XML. Version -04 is reorganized, adding ladder diagrams and SOAP interactions.

  • The Atom Syndication Format. Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Status: Last Call draft requested for approval as an IETF Proposed Standard. Reference: 'draft-ietf-atompub-format-08. April 18, 2005, expires October 20, 2005. 51 pages. See the diff against version -07. See the news story "IESG Issues Last Call Review for Atom Syndication Format as a Proposed Standard."

  • The Atom Syndication Format. Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-07. March 31, 2005, expires October 2, 2005. 49 pages. See the diff against version -06.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Robert Sayre (Boswijck Memex Consulting). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-03.txt'. March 18, 2005, expires September 19, 2005. Updates the previous draft of September 21, 2004. 20 pages. See also the color-coded diff version comparing version -03 to version -02. This version incorporates two Pace documents: (1) PaceSliceAndDice3: "Large Atom collections need to be accessible in small chunks. This proposal gives servers a way to slice the collection into subcollections, and it gives clients a way to dice those slices for their own needs. This method efficiently supports clients with or without persistent state."; (2) PaceIntrospection: Older versions of the AtomAPI had a file called the Introspection file; this file listed all of the different facets that a site supported. Real world experience has shown that this is a needed part of the API and this Pace reintroduces the concept with some minor changes."

  • The Atom Syndication Format.. Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-06. March 12, 2005, expires September 13, 2005. 48 pages. Updates the version -05 draft of January 26, 2005. Change log has 35 entries. See the HTML and diff against version -05. See also the End-game progress note from Tim Bray.

  • "The Atom Syndication Format." Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-05. January 26, 2005, expires July 27, 2005. This Internet Draft version -05 contains clarifications on "Securing Atom Documents" (use of the W3C Digital Signatures and Encryption specifications). It also provides a new informative Appendix B 'Collected RELAX NG Compact Schema' (RNC) prepared by Norman Walsh.

  • "The Atom Syndication Format." Edited by Mark Nottingham and Robert Sayre. IETF Network Working Group. Internet Draft. Reference: 'draft-ietf-atompub-format-04'. January 10, 2005, expires July 11, 2005. "Atom is an XML-based document format intended to allow lists of related information, known as 'feeds'. Feeds are composed of a number of items, known as 'entries', each with an extensible set of attached metadata. For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as Weblogs and news headlines to Web sites as well as directly to user agents. However, nothing precludes it from being used for other purposes and kinds of content. Details of communication protocols between software agents using Atom can be found in the Atom Protocol specification..." From IETF (ephemeral URL) http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-04.txt. See also the diff file relative to 'draft-ietf-atompub-format-04.txt'.

  • The Atom Syndication Format. Edited by Mark Nottingham (WWW). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-format-02'. September 5, 2004, expires March 06, 2005. 29 pages. "Atom is an XML-based document format intended to allow lists of related information, known as 'feeds', to be synchronised between publishers and consumers. Feeds are composed of a number of items, known as 'entries', each with an extensible set of attached metadata. For example, each entry has a title. The primary use case that Atom addresses is the syndication of Web content such as Weblogs and news headlines to Web sites as well as directly to user agents. However, nothing precludes it from being used for other purposes and kinds of content. Details of comunication protocols between software agents using Atom can be found in the Atom Protocol specification. This version -02 I-D adds a new section on Securing Atom Documents, with reference to the W3C/IETF specifications for 'XML-Signature and Syntax Processing' and 'XML Encryption Syntax and Processing.' It also adds a section on Identity Constructs: 'An Identity construct is an element whose content conveys a permanent, universally unique identifier for the construct's parent. Its content must be an absolute URI that is universally unique; i.e., it must not change over time, even if the parent feed or entry element is relocated, migrated, syndicated, republished, exported or imported'..."

  • The Atom Syndication Format. Edited by Mark Nottingham (WWW). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-format-01'. July 17, 2004, expires January 15, 2005. 27 pages.

  • "The Atom Publishing Protocol." Edited by Joe Gregorio (BitWorking, Inc) and Robert Sayre (Boswijck Memex Consulting). IETF Network Working Group, Internet Draft. Reference: 'draft-ietf-atompub-protocol-02.txt'. September 21, 2004, expires March 22, 2005. 22 pages. See also the color-coded diff version comparing version -02 to version -01. "This memo presents a protocol for using XML (Extensible Markup Language) and HTTP (HyperText Transport Protocol) to edit content. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources belonging to periodically updated websites. The protocol at its core is the HTTP transport of Atom-formatted representations. The Atom Publishing Protocol is an application-level protocol for publishing and editing Web resources. Using the common HTTP verbs provides a pattern for working with all such Web resources: (1) GET is used to retrieve a representation of a resource or perform a read-only query; (2) PUT is used to update a known resource; (3) POST is used to create a new dynamically-named resource; (4) DELETE is used to remove a resource. The Atom format is documented in the Atom Syndication Format Internet Draft.

  • The Atom Publishing Protocol. Edited by Joe Gregorio (BitWorking, Inc, WWW) and Robert Sayre (Boswijck Memex Consulting, WWW). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-protocol-01.txt'. July 1, 2004, expires December 30, 2004. 20 pages.

  • Atom Feed Autodiscovery. Edited by Mark Pilgrim (International Business Machines Corporation). IETF Network Working Group. Internet Draft: 'draft-ietf-atompub-autodiscovery-00.txt'. August 17, 2004, expires February 15, 2005. 14 pages.

Articles, Papers, News, Technical Reports, Proposals

  • [December 27, 2007] "ORE User Guide: Resource Map Implementation in Atom." Edited by Carl Lagoze (Cornell University Information Science) and Herbert Van de Sompel (Los Alamos National Laboratory). Produced by members of the Open Archives Initiative, Object Reuse and Exchange (ORE). 10-December-2007. "Open Archives Initiative Object Reuse and Exchange (OAI-ORE) defines standards for the description and exchange of aggregations of Web resources. OAI-ORE introduces the notion of a Resource Map, which is a specialization of a named graph that asserts a finite set of resources (the Aggregated Resources), their types, intra-relationships, and relationships with resources external to this finite set (the external resources). A Resource Map Document is a machine-readable representation of a Resource Map. Although multiple serializations of Resource Maps are possible, the initial serialization is done using the Atom Syndication Format (RFC 4287. A detailed examination of the mapping of ORE Data Model concepts to the Atom Syndication Format is known as the Resource Map Profile of Atom. The purpose of this document is to provide guidance to application developers on how to implement and interpret the Resource Map Profile of Atom. We anticipate that the contents and guidance given in this document to evolve over time to reflect the best practices of the community.

  • [August 06, 2007] "django-atompub: Implementation of Atom Format and Protocol for Django." By James Tauber. Software Announcement, posted to the 'atom-syntax' list. The Google Code django-atompub Project intends to be a full implementation of the Atom Syndication Format (IETF RFC 4287) and Atom Publishing Protocol for the Django web framework. The full set of RFC 4287 elements is now supported. The "User Guide to django-atompub" provides instructions for use. As of Revision 15, 'atom.py has' no dependency on Django itself, so it can actually be used outside of Django as a general Python library for generating Atom feeds. To generate an atom feed with django-atompub, firstly download 'atom.py' and put it somewhere in your python path. Then, create bridge class that will tie your models to the atom data model. This class should extend Feed in the above atom module and then implement a variety of methods to provide data to the feed generator. Aas to feed validation, RFC 4287 places certain constraints on combinations of elements and their contents. For example, [i] if a feed has no author, each of the entries must have an author — possibly in the source element; [ii] if no there is content, an entry must have alternate link; [iii] external content — i.e., content with a src attribute) requires the entry has a summary. By default, feeds are validated against these and many other constraints described in RFC 4287. This check greatly reduces the chance of producing an invalid atom feed. If a feed violates a constraint, an 'atom.ValidationError' will be thrown. In django-atompub, the Text, Person, Link, Category, Source, and Content Constructs are supported. The main Django project is also tracking this Google Code work. Note from the author (James Tauber): "Although the Django web framework has had Atom support for a while, it is incomplete and, for the most part, covers only those fields that Atom and RSS have in common. So I offered to implement full support for RFC 4287 in Django. The result is available at django-atompub on Google Code. The 'atom.py' module is actually independent of Django and so can be used as a general Python library for Atom feed generation. Support for the Atom Publishing Protocol — which is the main project delviverable is next..."

  • [July 24, 2007] Atom is Done: That's All, Then. By Tim Bray. From Ongoing [Blog] (July 24, 2007). The IESG has approved the "The Atom Publishing Protocol" specification as a Proposed Standard. Tim Bray, Co-Chair of the IETF Atompub Working Group, writes in his blog: "Atom is done. Now the editorial processes grind away and eventually the official specification of the Atom Publishing Protocol will be an RFC substantially identical to 'draft-ietf-atompub-protocol-17'. It will join RFC 4287 (The Atom Syndication Format) as the official products of the IETF Atompub Working Group. What's Next? Now we'll find out who's interested. The Atom feed format is a success; RSS isn't going away, but a steadily-increasing proportion of the world's new feeds are Atom 1.0. I personally think the protocol's going to be a big deal... [but] What Do We Call It? The term 'Atom' is hopelessly vague, and most people use it to refer the feed format, which is fine. We could say 'Atom Protocol' or 'APP' or 'Atompub'; let's see what shakes out..." Note from the IESG announcement: "The Atom Publishing Protocol HTTP-based protocol for publishing and editing web resources, and is particularly useful for (but not limited to) blogs. It supports ideas such as collections of multimedia items and categorization of items. It uses the Atom Format (RFC 4287) for its messages. The document went through many revisions and was discussed actively. There are already many implementations of the spec from a wide variety of vendors, and many of those have been shown to interoperate."

  • [July 03, 2007] Apache Module in C for the Atom Publishing Protocol. Tim Bray, Ongoing Blog "mod_atom". June 25, 2007. As summarized by Kurt Cagle: "Tim Bray recently announced his publication of a new Apache module, mod_atom, which will make it possible to use the Atom Publishing Protocol (APP) directly with the Apache HTTPD server. This is a pivotal achievement, and one that will rocket APP into daily use. APP uses Atom feed content and HTTP headers to build a publishing 'blog' system, though its uses extend considerably beyond the normal scope for blogging and could very well be a staple of most data publishing systems within the next few years." From the Ongoing Blog description: "An Apache Module provides code that gets linked into httpd, the Web server binary. There are hundreds [of modules]; a few are included with the server distro, but most aren't. Code in a module doesn't have to do anything like CGI, you're just a C subroutine that gets called with a package of details about the request and the current server state. Which can save some cycles... I think that the Atom Publishing Protocol is going to be a big enough part of the Web ecosystem that Apache, as perhaps the world's single most important piece of Web infrastructure, really ought to support it. Think of it as giving PUT something useful to do. What Does it Do? It implements all of the Atom Protocol, near as I can tell. There's no database: everything is persisted in files; entry paths look like /blogs/tim/atom/e/entries/2007/06/23/cat-pix. Since it blasts Atom Entries straight into files, it can easily (unlike most Atom protocol implementations) preserve foreign markup. It should run fine under any MPM, without concurrency issues. All the 'atom:id' values begin 'urn:uuid', so you could in principle move a whole publication from one server and directory to another. Those who have memories of me arguing bitterly against URNs in general and atom:id in particular can please restrain your snickering while I'm around. For the moment, mod_atom is just an Atom server, not a blog engine. Which is to say that it accepts and stores and updates and deletes the Atom Entries and generates feeds appropriately, but doesn't actually generate any HTML versions..."

  • [June 05, 2007] "Adding Resources to an Atom API Server: Use of the Atom Slug Header." By Nicholas Chase. From IBM developerWorks (June 05, 2007). "One advantage of the Atom Publishing Protocol is the ability to not only retrieve information, but also to add or edit information. The Atom Publishing Protocol works on the principle that you can accomplish everything you want to do through simple HTTP operations. You can read an item using the GET method, or add one to the system using the POST method. When you do, the response includes the URL for the new entry. In this tip, you learn to use Atom's Slug header to influence the final URL for this information. The example uses the Blogapps server, which supports draft 10 of the Atom Publishing Protocol 1.0 specification, but is applicable to any APP 1.0 compliant server. This can be handy for servers that do not automatically use the title for the URL, or in any situation in which you want more control over the URL that the server chooses. What if you wanted to control (or at least influence) the URL your server selects? The Atom API provides a specific header, Slug, that enables you to do that. The Slug header is named after the publishing industry's slug, or short name used to refer to articles. A server is not required to honor the Slug header, but if yours does, you can use it to control at least part of the URL provided to a new resource. [Note: As an application-level protocol for publishing and editing Web Resources using HTTP, APP supports creating, editing, and deleting of Entry and Media Resources: (1) GET is used to retrieve a representation of a known Resource. (2) POST is used to create a new, dynamically-named, Resource. When the client submits non-Atom-Entry representations to a Collection for creation, two Resources are always created — a Media Entry for the requested Resource, and a Media Link Entry for metadata about the Resource that will appear in the Collection. (3) PUT is used to edit a known Resource; it is not used for Resource creation. (4) DELETE is used to remove a known Resource.]

  • [May 22, 2007] "Signing, Encrypting, and Decrypting Atom: Abdera Meets Java Cryptography." By Nicholas Chase. From IBM developerWorks (May 22, 2007). "Atom is a great format for relaying information, but what about security concerns? XML Digital Signatures can ensure that data comes from a trusted party and that it in unaltered, and XML Encryption can obscure sensitive information from prying eyes. But how can you use these technologies without destroying Atom structures? This article shows you how digital signatures and encryption can easily mesh with Atom data using the Apache Abdera API. The article assumes that you are familiar with the concepts behind the Atom syndication format. You should also have at least a passing familiarity with the concepts behind XML security, though this isn't strictly necessary. We use fairly simple examples of using Atom data with both digital signatures, which verify both the sender and the integrity of the information, and encryption, which prevents unauthorized parties from obtaining sensitive information. To accomplish these tasks, we use the Apache Abdera project, which enables one to easily manipulate Atom data. Abdera also includes objects that make it possible to integrate easily with client side certificates, to automatically encrypt Atom data at the servlet level, and more..."

  • [May 07, 2007] "Simple Sharing Extensions for Atom and RSS." By Steven Lees. Atom Syntax Posting and Microsoft XML Developer Center Article. Steven Lees (CSA Concept Development Team, Microsoft) wrote on the Atom Syntax list: "I'm seeking feedback on a specification that works in conjunction with Atom. I'm part of the team at Microsoft that is developing Simple Sharing Extensions (SSE). Adding SSE information to a feed enables loosely coupled data synchronization between multiple endpoints that are sharing the feed. The original version of SSE supported RSS as a feed format, and I've just posted to the web the latest version of the spec, which adds a binding for Atom feeds. The SSE spec is designed so that an SSE-annotated Atom feed is valid and can be consumed by any feed reader, even if that reader doesn't participate in sync. The ability to sync data across endpoints in a loosely coupled way enables some interesting end user scenarios. Simplicity is one of the main design points for SSE, which means that the spec is suitable for implementation on relatively small devices as well as larger ones. The spec is released under a Creative Commons license, and our goal is to encourage a range of implementations of the spec for a wide variety of computing environments." Simple Sharing Extensions for Atom and RSS 0.93 overview: "The scope of Simple Sharing Extensions (SSE) is to define the minimum extensions necessary to enable loosely-cooperating applications to use XML-based container formats such as Atom and RSS as the basis for item sharing — that is, the bi-directional, asynchronous synchronization of new and changed items amongst two or more cross-subscribed feeds." See also the FAQ document.

  • [April 26, 2007] "Atom Will Change the World." By Charles F. I. Savage. Charlie Savage's Blog (April 26, 2007). "Its a rare day that a truly good standard comes along. Its an even rarer day that the standard get widely adopted. So the developers of Atom should stand up and take a bow: not only did they hit a home run with the Atom syndication format, they've done it again with the Atom publishing protocol... What is news is the surprisingly deep and capable technology platform Atom offers, making it suitable for a large range of applications well beyond blogging software. In fact I believe we're witnessing the birth of the next great technology standard, with Atom taking its place alongside HTML, HTTP and the underlying protocols that support the Internet... Atom is so useful because of the emergent properties that arise from its unique combination of: (1) A simple data model of collections that contain entries; (2) Careful selection of the most important metadata - author, update time, etc.; (3) Support of attached pictures, songs and video to entries; (4) Extensibility through XML namespaces; (5) A standard REST API that fully leverages HTTP; (6) Easy to read, short specifications that can be implemented in a good days worth of hacking. Starting with the data model, it turns out that modeling the world as collections that contain entries is awfully useful. Clearly this model works well for blogs, which are a collection of articles. But it also works across a vast range of domains, such as modeling records in tables, songs in collections, features on a map, items in a shopping cart, books in a library, etc. Then for each entry, Atom defines a small set of the most useful attributes... right off the bat Atom provides a universal way that computers can share a base level of information about whatever things they model. Atom then takes this a step farther by allowing custom information to be embedded via the use of XML namespaces. Thus you can use XHTML to embed a story, GeoRSS to embed coordinate information, rank extensions to embed rating information, threading extensions to embed comments, etc. Both the Atom syndication format and publishing protocol are simple to implement since they build off the strong foundation of provided by XML and HTTP. For the work I've done with MapBuzz, I had an Atom feed up in running in a couple hours and full support for the Atom publishing protocol in a day..."

  • [April 24, 2007] "Manage a Media Collection with the Atom Publishing Protocol." By Nicholas Chase. From IBM developerWorks (April 24, 2007). "You might know the Atom syndication format as a way to provide blog entry information, but did you know that in conjunction with the Atom Publishing Protocol, you can use it to manage media files? This article shows you how to create a Web-based media repository with Atom. The article assumes that you are at least marginally familiar with the Atom syndication format, and with HTML concepts such as forms. To follow the example, you'll need an application server that supports the Atom Publishing Protocol (APP). Roller is great, and even runs the blogs here at developerWorks, but the installation manual is 27 pages long; fortunately, Dave Johnson has put all the pieces together in the Blogapps server. To run the example application, you'll need a servlet- capable server. Blogapps includes Tomcat, so you can use that. If you choose to use a separate instance, you'll need to alter the 'server.xml' file to prevent port conflicts. The last step is to install the Apache Abdera package, selected to make the APP easier to use. You will create a servlet that uses the Atom Publishing Protocol to add media resources to an Atom collection, which is part of a workspace. To add each resource, you'll use a POST request that sends the file to a URI designated for that collection. When you do that, the server creates a corresponding media-link entry that refers to it. You can then extract the information about all of those items in an Atom feed, which you can then use to display the information on a Web page. The Atom protocol also makes use of the other HTTP methods. You'll use GET to query information, DELETE to delete it (of course) and PUT to edit existing information (if possible). The Atom Syndication Format, combined with the power of the Atom Publishing Protocol, offers a good way to manage your resources, the images, audio, or even text or xhtml..."

  • [April 20, 2007] "Recapping the Atom Publishing Protocol Interoperability Meetup." By DeWitt Clinton (Google Developer Programs). Blog (April 20, 2007). "Google had the privilege and pleasure of hosting the first-ever Atom Publishing Protocol interoperability meetup earlier this week in Mountain View, CA. The Atom Publishing Protocol is a specification that helps define the interactions between clients and servers that wish to read and write collections of documents via the web. Building upon the popular Atom Syndication Format, the Atom Publishing Protocol formalizes many of the mechanisms required for the exchange of rich and meaningful content via a process known as Representational State Transfer, known familiarly as REST. Nearing completion as an Internet Engineering Task Force (IETF) standard, the protocol is already seeing wide adoption, and the working group felt it was time to bring people together to see how the various existing implementations interacted with each other. Over twenty (20) representatives from organizations and companies far and wide (some hailing from all the way across the Pacific) made the trip to Mountain View for two days of interoperability testing. The meetup was open to anyone who has built client or server software that uses the protocol, and it was extensively blogged about and 'simulcast' over the Atom IRC channel for those who could not attend in person. Striking was the diversity of both the organizations in attendance (AOL, IBM, Google, Microsoft, Oracle, O'Reilly, Six Apart — to name just a few) and the wide variety in types of applications being built. And a special thanks to Tim Bray, co-chair of the Atom Publishing Protocol working group, for his tireless devotion to the standards process and for leading the group in making the most of our time together. And for the curious: how did Google's many implementations of the protocol do at interoperability? Well, authentication was a hurdle for most clients (the specification itself considers authentication to be an orthogonal concern), but beyond that our servers are relatively compliant and some of our client code is well along the way to full support for the protocol. Perhaps more importantly, Google is committed to continued support of the working group, and we intend to keep pace with the draft specifications as they are finalized..."

  • [April 19, 2007] "Atompub Interop Lessons." By Tim Bray. From Ongoing Blog (April 17, 2007). "The [Atompub Interop] results are summarized on the Wiki; what do they mean? Obviously, good news: The fact that people from this many places, most of whom had never met before, got together and were able to put that many check-marks on the grid, based on a protocol whose design is not quite frozen, verges on the miraculous... It's become pretty obvious that a pretty broad range of pieces of software can fairly claim to to be Atompub implementations. This is more obvious on the server than on the client side, partly because the implementations are more numerous and mature at this point. Some are clearly not general-purpose; for example, the O'Reilly people at the Interop event had what appeared to be a perfectly legal implementation; but you could only post DocBook XML to it. Which I can see being useful for them, but a vanilla blogging client probably won't work that well with it, out of the box... Technologies represented: Perl, Python, PHP, Ruby, Java, C#; DB2, Oracle, MySQL, Derby, flat files; Linux, Windows, OS X, Solaris. Spot the pattern? Sun and IBM and Oracle have working database-backed Atom stores. Microsoft and IBM, that we know of, have in-progress clients. Judging by my email, there are a bunch of startups hacking together one side or another of the protocol. Draw your own conclusions, but I think it's obvious..." See: (1) APP Client/Server Interop Grid; (2) APP Interop Event April 16-17, 2007.

  • [April 19, 2007] "Atom Publishing Protocol Interop a Success." By Keith Fahlgren. From O'Reilly News (April 17, 2007)."The first interoperability session for Atom Publishing Protocol implementations (both clients and servers) was a success. The best news was that many of the clients and servers were able to interoperate with little to no tweaking despite never having met before. Check out the (evolving) grid of success and failures for details. More than 20 implementors attended the event, held yesterday and today at Google, as well as Lisa Dusseault, the IETF Area Director for APP. The other positive news is that big industry players like AOL, Google, IBM, Microsoft, Oracle, and Sun are working on APP clients and servers and sent people to the interop event with interesting code. Google and IBM in particular sent a lot of folks. Some quick notes [excerpted]: (1) Two days of intense work didn't uncover big holes in the spec, which is nice. (2) Many of the servers are currently quite permissive because of differing conformance levels of clients in the wild today. This will hopefully change when the spec gets finalized and clients are updated. (3) Adding a second or third namespace — probably 'app:' and 'xhtml:', potentially 'rdf:' and others — to your Atom entries starts making your decisions on default namespaces more important for both clients and servers. (4) The clients and servers were implemented in a wide range of languages, showing that the spec is quite implementable (even by inexperienced mediocre programmers like myself) and that XML technologies are finally now accessible in all the modern languages, a relatively recent change XMLers sometimes forget. I remember seeing code Python, C#, Ruby, Java, XQuery, PHP, and Perl, but I may be leaving some out. (5) DeWitt Clinton of Google hinted that they've been quite successful at handling giant loads with their APP services. (6) From a more personal perspective, O'Reilly's own internal APP repository now has hundreds of books, thousands of articles, and hundreds of thousands of images, and is already driving some site improvements, like these dynamic Table of Contents pages. (7) Tim Bray posted some pictures on his blog "Interop Impressions and Pix"; see details in "Atompub Interop Lessons"...

  • [April 10, 2007] "Create a Multi-Section Atom Collection or Feed." By Nicholas Chase. From IBM developerWorks (April 10, 2007). "The Syfy Portal newsfeed has the potential to contain over 3000 archived news stories. Virtually nobody wants their feed reader to download all of these messages, especially since many of them are several years old. To solve that problem, the Atom specification allows for the necessity to send only a portion of the available information. It takes into account the fact that you don't always want to send all of your data to a requester, and provides a way to make this capability feasible. As feeds move beyond merely announcing new content on somebody's blog and into organizing data, you can easily find situations where you don't want your feed to include all of the available data. This tip shows you how to create an Atom feed that lets users page through it using "next" and "previous" links or buttons. It shows you how to implement this functionality using PHP, but the concepts are the same for any programming language..."

  • [December 27, 2006] "amplee: A Python Library Implementing the Atom Publishing Protocol." By Sylvain Hellegouarch. IETF atom-protocol List Announcement (December 11, 2006) An announcement was posted for the release of amplee 0.3.6 — called 'alpha', but "... you can be safe and use it already as it stands; it should soon move to beta." amplee is a Python implementation of the Atom Publishing Protocol (APP), as specified in draft 11 or later. amplee's aim is to provide an API close to the APP specification which can be used in any Python code, and HTTP handlers to make it easy to integrate an APP store into a web application. amplee has different levels and can be used in a number of ways: (1) At a minimum it's just a pure Python library implementing the Atom Publishing protocol. In that case the API model is almost a 1-to-1 mapping of the APP spec. Modules in the amplee.atompub package include [a] store: APP does not define the meaning of store. We use that concept to describe the outter envelop that carries related APP entities. A store is the layer between the underlying storage (database, filesystem, etc.) with APP entities; [b] service: amplee attaches a service entity to a store. A service also has a list of workspaces it handles; [c] workspace: a workspace belongs to one service and has a list of collections; [d] collection: amplee collection module allows CRUD operations to be made on members. (2) It has built-in members for common data type such as XHTML, audio formats (MP3, Ogg, Flac, WavPack) or Open Document Text format. (3) You can also use built-in storages to persist members of a collection. Currently supported: filesystem, subversion, zodb, and database backend via dejavu. amplee is distributed under the Creative Commons Attribution-ShareAlike2.5 License... See also the Atom Protocol Python Group.

  • [December 27, 2006] "Managing Content with the Atom Publishing Protocol." By Andrew Savikas (Director, Digital Content & Publishing Services, O'Reilly Media, Inc). Presented at XML 2006 (December 4-7, 2006, Boston, MA, USA). "While the Atom Publishing Protocol is gaining acceptance in online publishing, especially around blogging, it's also flexible enough to serve as a general-purpose 'content API' for O'Reilly Media's next-generation content architecture. At O'Reilly, we've used Atom to balance the need to be flexible in what content types are accepted (XML, HTML, PDF, Word, OpenOffice.org) with the equally important need to be predictable about how that content is made available to a variety of applications (Safari, SafariU, oreilly.com, print-on-demand). Content creators need not worry about the downstream needs of ever-changing applications, they just focus on creating DocBook XML, XHTML, or PDFs (along with associated images). In turn, those downstream applications needn't worry about the quality of the content available to them — it's guaranteed valid, with all referenced images present and accounted for. O'Reilly is using the Atom Publishing Protocol to implement a powerful abstraction layer separating content creation from content consumption, simplifying the workflow on both ends, and solidifying XML's role at the core of our content management and delivery strategy."

  • [December 12, 2006] "Getting to Know the Atom Publishing Protocol, Part 3: Introducing the Apache Abdera Project." By James Snelljasnell@us.ibm.com (Software Engineer, IBM). From IBM developerWorks (December 12, 2006). "Earlier articles in this series provided an overview of the Atom Publishing Protocol and described the various ways it is being utilized in real world applications. This article begins to demonstrate how you can start to implement Atom-enabled applications using a new open-source project, called Abdera, currently under incubation at the Apache Software Foundation. It covers the Feed Object Model, XPath and XSLT support, extension handling and incremental parsing model. The discussion assumes that you have read the Atom Format specification and that you are familiar with syndication in general. All of the examples are provided in Java code and a sample Eclipse project containing all of the code samples is provided for download... The Abdera project consists of a collection of individual modules. The core module defines what Abdera calls the "Feed Object Model", a set of interfaces used for parsing, creating and manipulating Atom documents that is modeled after the Atom Syndication Format specification. The two primary functions of Abdera's Feed Object Model are to make it easy to both produce and consume Atom Feed and Entry documents. Abdera's Feed Object Model interfaces follow the Atom Syndication Format schema very closely, making it natural for developers who are familiar with the RFC 4287 specification to produce valid Atom documents. However, it is important to point out that the implementation does not perform any validation of the input. For instance, RFC 4287 requires that all atom:entry and atom:feed elements contain exactly one atom:id element whose value is a normalized IRI. Abdera, however, does not throw an exception if a developer tries to create and serialize an entry or feed that does not contain an atom:id or that contains multiple atom:ids. Developers are responsible for ensuring that the documents they produce are valid. With the FeedValidator, you can check the validity of Atom documents. When the Abdera project was launched, the stated goal of the project was to provide functionally complete implementations of both the Atom Syndication Format and the Atom Publishing Protocol. Thus far, this series has provided a fair amount of coverage of the support for the Syndication Format and has illustrated how to produce and consume feeds. The next installment will cover the Atom Publishing Protocol client and server support that is still currently being implemented..."

  • [November 21, 2006] "Atom Bidirectional Attribute." By Jamed Snell. IETF Network Working Group, Internet Draft 'draft-snell-atompub-bidi-01' Said to be 'September 2006'. Tracker. Announced November 20, 2006. Note: Version -02 draft [December 06, 2006] has two significant changes: (1) drops the rlo and lro values; (2) specifies that UA's MAY right-align RTL text using the same rules defined for HTML. ['This I-D adds a dir attribute to Atom Common Attributes that is used to specify the base direction of text in Atom documents.'] IETF has released a level -01 Internet Draft for the 'Atom Bidirectional Attribute' specification. This draft updates the Atom Syndication Format by adding a new attribute that may be used to indicate the base directionality of directionally-neutral characters. The 'dir' attribute specifies the base direction of directionally- neutral text, as defined in the Unicode standard. Possible values for the attribute are 'ltr' and 'rtl' indicating 'left-to-right' and 'right-to-left' respectively, 'lro' and 'rlo' indicating explicit 'left-to-right' and 'right-to-left' overrides, or an empty string indicating that no base-direction is specified. If the 'dir' attribute is not specified, the value is assumed to be an empty string. The attribute can appear anywhere in an Atom document, except where it is explicitly forbidden. The direction specified by 'dir' applies to elements and attributes whose values are specified as being 'Language-Sensitive' as defined by Section 2 of RFC 4287. The attribute is inherited by descendent elements and may be overridden. The Unicode bidirectional control characters may also be used within attributes and element values to indicate the directionality of text. Implementers are reminded that unexpected results could occur when using both the 'dir' attribute and the Unicode control characters within a single document..."

  • [November 10, 2006] "Getting to Know the Atom Publishing Protocol, Part 2: Put the Atom Publishing Protocol (APP) to Work. Interact with Deployed Applications like Weblogs or Calendars." By James Snell. From IBM developerWorks (November 07, 2006). The previous installment in this series presented a brief walk-through of the Atom Publishing Protocol (APP). In accordance with the charter of the IETF's Atom Publishing Format and Protocol Working Group, the Atom Publishing Protocol is designed for the primary use case of publishing and management of weblog entries. It should come as no surprise, then, that many blogging software providers such as Google, SixApart, and Roller have already started to roll out preliminary support for the protocol. In early August of 2006, Google announced a long-awaited update to its ho