Atom format and publishing protocol compliance

CICS® supports the Atom format and Atom publishing protocol described in RFC 4287 and RFC 5023.

The Atom Syndication Format and Atom Publishing Protocol are described in the following Internet Society and IETF (Internet Engineering Task Force) Request for Comments documents (RFCs):
RFC 4287, The Atom Syndication Format
The specification for the structure of Atom feed and entry documents, available at https://www.rfc-editor.org/rfc/rfc4287.txt.
RFC 5023, The Atom Publishing Protocol
The protocol for publishing and editing resources in the Atom document format over HTTP, including descriptions of the structure of Atom service and category documents, available at https://www.rfc-editor.org/rfc/rfc5023.txt.

CICS behavior in compliance with the Atom format and protocol

CICS handles a number of tasks required for compliance with the Atom format and protocol.
  • CICS validates the format of your Atom configuration files for Atom feed documents, Atom entry documents, and collections to ensure that they comply with the requirements in RFC 4287. Wherever it is viable to do so, CICS checks that you have supplied required elements, and applies defaults where necessary. The CICS documentation for setting up Atom feeds has information about the situations in which CICS is not able to validate your data, where you are responsible for providing correct data.
  • CICS handles Atom service documents and Atom category documents that you create, and delivers these to clients. However, CICS does not validate the format of these documents, whether they are in Atom configuration files or delivered as static documents. You are responsible for compliance with the requirements detailed in RFC 5023 for the format of these Atom document types.
  • CICS provides EXEC CICS API commands that create timestamps in the correct format for Date constructs in Atom documents. If you choose not to use the EXEC CICS API commands to produce your timestamps, you are responsible for compliance with the requirements detailed in RFC 4287 for the content of Date constructs.
  • CICS handles the mapping and comparison tasks for IRIs, which are used in <atom:id> elements and <atom:link> elements.
  • CICS supplies the <atom:generator> element for Atom feed documents, which gives the name of the generating agent, with a URI and version number.
  • CICS can generate an Atom ID for each entry when it serves the Atom feed, in a format that meets the specification in RFC 4287. Under the conditions described in Atom IDs for Atom entries, the Atom ID is unique and remains the same for the lifetime of each Atom entry.
  • CICS carries out the actions required of a server for processing client requests to manipulate ordinary Atom entries in collections, as specified in RFC 5023, except where noted in Atom features not supported by CICS. In particular, CICS does not support media resources and media link entries in collections.
  • CICS enables you to implement security for Atom feeds and resources containing data for Atom feeds, through CICS resource security and CICS web support security. You are responsible for choosing and setting up appropriate security features to protect your Atom feeds. RFC 5023 recommends that you use authentication mechanisms, and discusses a number of threat scenarios.

Atom features not supported by CICS

Some of the requirements for the Atom format and protocol are not relevant to CICS or not supported by CICS.
  • The requirements in RFC 4287 and RFC 5023 for "Atom Processors" are not relevant to CICS. CICS does not receive Atom feed documents for processing, so it does not act as an Atom Processor.
  • CICS does not provide support for digital signatures and encryption of Atom documents, but, in compliance with RFC 4287, CICS does not reject an Atom document that contains a signature.
  • CICS does not support HTML or XHTML content in a Text construct (such as the <atom:title> element). You must supply plain text content with no child elements.
  • CICS permits HTML, XHTML, and other text media types (such as XML) as content in the <atom:content> element. However, you must validate the content yourself. CICS does not attempt to parse the content to check that its markup is valid, but supplies it to the client as you provided it.
  • It is possible to use the <atom:content> element to supply content with a non-text media type if the content is in a valid Base64 encoding. CICS does not disallow this, but provides no support for non-text content, and does not check for the presence of an <atom:summary> element, which is required for content encoded in Base64.
  • CICS does not support media resources and media link entries in collections. Media resources are specified by the Atom Publishing Protocol (RFC 5023) primarily as a means of organizing nontext content in a collection. When a client attempts to create an entry in a collection, CICS rejects with a 415 status code any client request that is not an Atom entry (with the media type application/atom+xml, with or without the type=entry parameter). Do not specify any additional media types in <app:accept> elements in a service document for CICS.
  • The support for Atom feeds in CICS is intended for supplying feeds of data to clients. CICS does not support the delivery of Atom entries that contain no data, such as entries that use the "src" attribute to reference remote content.
  • CICS does not support the optional <atom:source> element for an entry. The <atom:source> element is used to preserve metadata if an Atom entry is copied from one feed into another.
  • CICS only supports the link elements <atom:link rel="self"> and <atom:link rel="edit">. Other link elements, such as related, enclosure, or via links, and links to alternate formats, are not supported. CICS does not support title or length attributes for link elements.
  • CICS does not reject Atom entries for a collection on the basis of categories. You can use the <app:categories> element in a service document or category document to specify acceptable categories for entries in a collection, but CICS does not police whether clients adhere to these categories.
  • CICS ignores Slug headers and supplies its own URIs for Atom entries.
  • For reasons of performance, CICS does not automatically return Atom entries in a collection in the order in which they were most recently edited (as shown by the <app:edited> element in the entry). This function is a SHOULD requirement in RFC 5023 for a full list of entries, but a MUST requirement for a partial list of entries. CICS deviates from this requirement to maintain acceptable response times while still providing the useful function of partial lists. If you are using a service routine to supply the entries to CICS, you can make the collection compliant by supplying the entries in the order in which they were last edited, if your resource is able to store this information.
  • CICS does not support <app:control> and <app:draft> elements in Atom entries, and ignores them.
  • Some resources that provide Atom entry data for CICS cannot follow the recommendation in RFC 4287 to store Atom IDs with Atom entries. However, CICS has the capability to generate the same Atom ID for an Atom entry each time the entry is served, under the conditions described in Atom IDs for Atom entries.
  • RFC 4287 requires that the Atom ID remain with the Atom entry if the entry is reused or moved to another location. If you store Atom IDs with your Atom entries, you can move the Atom entries to another location and still comply with this requirement. If you do not store Atom IDs with your Atom entries, do not move the Atom entry to another location.