Schema to define an XML document which can store the information found in a single e-mail account.
Authored jointly by the North Carolina State Archives and Smithsonian Institution Archives.
Contact:
Kelly Eubank [kelly.eubank@ncdcr.gov] (NC State Archives Electronic Records Archivist);
Riccardo Ferrante [FerranteR@si.edu] (IT Archivist & Electronic Records Program Director Smithsonian Institution Archives);
David R. Minor [david.minor@ncdcr.gov] (NC State Archives technical contact);
Steve Burbeck [sburbeck@mindspring.com] (technical contact)
Globally unique, permanent, absolute URI with no fragment conforming to the canonical form specified in RFC2396 as amended by RFC2732. This value once assigned must never be changed.
Handles from the Handle System could be used but they must not contain the # character.
Handles should be expressed as an URI with the syntax hdl:<handle> or urn:<handle>. This form simply specifies the raw handle and does not make any reference to a handle resolver.
All messages and their child messages contained in this account can be identified globally using this GlobalId and appending the LocalId as a fragment(GlobalId#LocalId).
This should be identical to the GlobalId of the XML file for the target account.
The target contains previously archived messages from the same logical account as messages found here."
The target contains messages subsequently archived from the same logical account as messages found here.
The target contains messages that should be logically included with the messages found here.
The target contains messages from some other account that may be of interest.
Content found here is superseded entirely by the messages found in the target.
All of the messages in the archive that belong to this folder of this account are
stored in an mbox file. This mbox file must use the mboxrd format and must use
the end-of-line markers specified in the Eol child element of this Mbox element.
Each message contained here must be use the RFC 2822 format as it would exist as
it was sent over the wire.
Individual messages may be retrieved from an mbox file
by searching for the desired message using the message-id. For messages
that do not have a message-id, the referrer must create an index to the mbox file by
creating a hash for each message. Once this index has been created, the
hash stored along with the message in this file can be used to locate the
original message.
This serves to define a single RFC2822 Message.
URI component that when added to the path from which this XML document was accessed gives the URI for the root folder for which external body parts may be accessed. If not given "." is assumed.
If not present then it is assumed that this message did not use any mime extensions.
All header values found in the message should be placed here.
Even those used to populate the contents of the standard messages headers.
The minimum amount of transformation should be preformed on the original values.
Any encoded words (as per RFC 2047) should be left as-is and not converted to Unicode.
This is the result of calculating the hash on the text string
that begins with the F of the From_ line and includes the
last eol character of the message. All messages end with a
single eol marker. Before creating the hash, if the message
ends with two or more eol markers, all but the first must
be removed. If the message does not end with an eol marker,
one must be added.
The CharSet, ContentName, ContentTypeComments, and ContentTypeParams are all part of the Content-Type header, and none should be present if the Content-Type header is not present.
This is just the MIME type / MIME sub type. If not present then text/plain is assumed.
If not present, then US-ASCII is assumed.
This is the character set originally used to encode the content of this multi-part body.
Any other parameter found in the Content-Type header field except for id and name.
If not present, "7-bit" is assumed.
Any other parameter found in the Content-Disposition header field except for filename.
This is textual or binary data that is stored in-line in this XML document
that makes up the body of this entity.
Along with the character set and transfer encoding used.
This is a pointer to a file that contains the text or binary data
that makes up the body of this entity.
Along with the character set and transfer encoding used.
Used for Content-Type message/external-body. US-ASCII character set is assumed.
The Charset, ContentName, ContentTypeComments, and ContentTypeParams are all part of the Content-Type header, and none should be present if the Content-Type header is not present.
This is just the MIME type / MIME sub type. If not present then text/plain is assumed.
If not present, then US-ASCII is assumed.
This is the character set originally used to encode the content of this multi-part body.
Any other parameter found in the Content-Type header field except for id, name, and boundary string.
If not present, "7-bit" is assumed.
Any other parameters found in the Content-Disposition header field except for filename.
If not present then it is assumed that this message did not use any mime extensions.
Content here is either wrapped in a CDATA section where all occurrences of ]]> have been escaped as "]]>
or without being wrapped in a CDATA section where all occurrences of < and & have been escaped as < and &
respectively as well as all occurrences of ]]> have been escaped as "]]>.
The character encoding that was used when preparing
the contents of this internal body part.
If not present then the character encoding
specified by the "encoding" element in the prologue of this XML document is assumed.
If not present, then it is assumed that this is not necessary
since it is implied by the "encoding" element in the prologue of this XML document.
Path component that when added to the result obtained from adding the RelPath
for this message to the absolute path from which this XML file was accessed
gives the path to the externally stored body part.
The character encoding that was used when preparing
the contents of this external body part.
If not present then the original character encoding
specified by the "Charset" element of the containing SingleBody
element is assumed.
The transfer encoding that was used when preparing
the contents of this external body part.
If not present then the original character encoding
specified by the "TransferEncoding" element of the containing SingleBody
element is assumed.
If this externally stored body part is wrapped in an XML envelope then this element must be present and have a value of true.
If the externally stored body part is stored as a "native" file without any XML wrapper then either this element will
not be present or will be present and have a value of false.
The results of some hash function computed on the entire contents of the
external file.
These are the headers that can be used for a top-level message or for a child message.
Top-level messages should have the "From", "Date", and at least one destination header ("To" "Cc", or "Bcc");
child messages should have at least one of "From", "Subject", or "Date".
HeaderType is used to contain the contents of a single header
the child element name stores the name of the header, while
the child element value stores the contents of the header.
URI component that when added to the path from which this XML file
was accessed will give the URI from which the mbox full of original messages may be retrieved.
Values of hash-type must be computed by the hash algorithm specified. Please use the canonical form: only upper case letters should be used.)
As defined by RFC 1321
As adopted by ISO/IEC 10118-3:2004
As defined by NIST FIPS PUB 180-2
As defined by NIST FIPS PUB 180-2
As defined by NIST FIPS PUB 180-2
As defined by NIST FIPS PUB 180-2
As defined by NIST FIPS PUB 180-2
As defined by ISO/IEC 10118-3:2003