]>

me@gsnedders.com http://gsnedders.com/

This document specifies a method of using the Atom Syndication Format as an export format.

This section is yet to be written.

This specification is defined in terms of the US-ASCII character set as defined in . Except where explicitly specified, all strings are case-sensitive.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . This document places certain restrictions depending on the purpose of the software implementing it. These groups are: importers, which process an Atom Export document and make a copy of it within their own data store; and, exporters, which create an Atom Export document from the contents of their own data store. Occasionally, an implementation is required to raise a fatal error. When an importer is required to raise a fatal error, it MUST abort processing of the Atom Export Document and MUST NOT continue processing of any sort. When an exporter is required to raise a fatal error, it MUST abort creating of an Atom Export Document, and MUST discard what it has thus far produced.

An Atom Export Document is an archive file containing one or more Atom Feed Documents . (The archive can, however, contain arbitrary files of any format.) Implementations MUST support ustar archives, and SHOULD support GZIP compressed ustar archives. Exporters SHOULD create GZIP compressed ustar archives. The root of the archive, for the purposes of this document, MUST be found using the following algorithm: Let "current directory" be the upper-most directory of the archive. If "current directory" contains, case-sensitively, a file called "index.xml", then "current directory" is the root. Terminate the algorithm. If "current directory" contains no files and one directory, then let "current directory" be that directory. Jump to step 2 of this algorithm. Otherwise, this algorithm has failed. Raise a fatal error. When creating an Atom Export document, the exporter SHOULD create a single outer directory containing the "index.xml" file. When importing an Atom Export Document, processing MUST begin at the "index.xml" file located at the root of the archive. Importers MUST support Feed Paging and Archiving , and SHOULD support Atom Threading Extensions . When used as a link relation of an atom:link element which is a child of the root element in an Atom Feed Document, the link relations defined by Feed Paging and Archiving MUST only be created by exporters when their "href" attribute's value matches the "path-noscheme" production in and points to another Atom Feed Document in the Atom Export Document. Upon encountering a atom:link element that does not meet the above requirement, an importer SHOULD NOT follow the link if it is an absolute IRI, and MUST raise a fatal error if upon attempting to access the the document linked to by the "href" it is found not to exist (e.g., it is a relative URI and the file does not exist within the Atom Export Document, it is a HTTP URI and the status-code returned is 404 or 410). Any file linked (either via atom:link or another linking method, such as within an Atom Text Construct or atom:content element) via a relative IRI that exists within the Atom Export Document SHOULD be copied by an importer to a location at which it will be accessible once imported, updating the IRI reference if needed. Equally, the importer SHOULD keep track of all alternate links (in the atom:link sense of the word link) for all entries and update IRI references that point to alternate representations within the Atom Export Document so that they are accessible in the imported copy.

The "index.xml" file, located at the root of the archive, MUST be an Atom Feed Document . The "index.xml" file represents the main stream of entries of the export. If "index.xml" makes use of Feed Paging and Archiving , the exporter MUST create "index.xml" as the first page if it uses paging, and as the current page if it uses archiving. Importers MUST make no assumption about the feed ordering, and MUST therefore handle cases where "index.xml" is not the first/current page identically to as if it had been.

As this specification primarily relies upon other specifications to define the formats used within this specification, it is subject to the same security considerations as they are. Please obtain the documents listed under "Normative References" for their security considerations. If an implementation expands the Atom Export Document into a larger filesystem for processing, it must beware of relative IRIs that would cause the implementation to operate on files outside of the expanded archive. Arbitrary files can be contained with the Atom Export Document: any implementation must ensure that due care is taken so that these do not pose a risk. These can especially become a risk if they are copied (due to being linked) to somewhere publicly accessible, or somewhere where they could be executed (such as a CGI script on a web-server).

This section is yet to be written, primarily because it is pending a decision about archive formats (this has repercussions on detecting what archive format is used, and thus on this section).

&ASCII; &RFC1952; &RFC2119; &RFC3986; &RFC4297; &RFC4685; &RFC5005; &RFC5023; &POSIX;

This section is yet to be written.

Remove this section upon publication. Need to register MIME type. Need to decide about archive formats (this has an effect on MIME type registration). Need to review the document v. I-D requirements. Need to define processing when parsing enclosed file fails. Resolving IRIs (defining / to be the root of the archive). Security considerations will have to say more. Work out why RFC5023 is referenced, or delete reference.