RSMF Files That Will Not Open, and What the Findings Mean

An RSMF export is checked in two stages: whether the file can be read at all, and whether what it declares agrees with itself. The first stage refuses the file with a message beside it in Upload review; the second renders it and lists findings on the panel and on each transcript's first page.

Files that are refused

• Not an RSMF export. No X-RSMF-Version header and not an rsmf.zip. Export the conversation again from the tool that produced it (Relativity, Reveal, Message Crawler, Hearsay, iMazing, ChatExport) and add that file.
• An ordinary email. A .eml with no RSMF headers is an email message, not a message export. Save it as a PDF from your mail client and add that.
• Not exactly one rsmf.zip attachment. The specification requires one zip part named rsmf.zip; a wrapper with none or several is refused. A zip part with another name is accepted with a warning.
• The zip part is not base64. A quoted-printable or otherwise undecodable archive part. Re-export.
• The archive cannot be read. Truncated, ZIP64, split across disks, or more than 512 members. Re-export, or split the export in the producing tool.
• No rsmf_manifest.json, or one larger than 24 MB, or more than 20,000 events. Split the export by conversation or date range in the producing tool (Relativity recommends 10,000 events or fewer per file).
• A required field of the wrong shape. The message names the path (for example events[12].type is required). Run the file through Relativity's RSMF validator or re-export.
• Over 50 MB, or reading took longer than 5 minutes. Split the export.
• The transcript fonts could not be loaded. The fonts are fetched from this site when a transcript renders; check the connection, reload and add the file again.

Findings on a file that renders

Errors (the validator would fail the file):

• An attachment referenced by the manifest is not in rsmf.zip. Attachment ids are case-sensitive filenames; the transcript lists the attachment as NOT IN rsmf.zip. Re-export if the attachment matters.
• A participant or conversation id is declared more than once. The first declaration is used.

Warnings (rendering may differ from the producer's intent):

• A participant, conversation or event is missing a field RSMF 1.0 requires — a display name, a conversation type, a timestamp. The transcript shows "Participant #id" for an unnamed sender and places undated events first.
• A timestamp is not ISO 8601. It is printed exactly as written and ordered as if undated.
• An event names a conversation id the manifest does not declare. Those events are shown under a reconstructed conversation, as Relativity shows them.
• An event, reaction, edit or receipt names an undeclared participant id. Shown as "Participant #id".
• X-RSMF-EventCount, X-RSMF-AttachmentCount, X-RSMF-Participants or X-RSMF-Version disagree with the manifest. The manifest is rendered; the header values are printed on page 1 so the disagreement is visible.
• More than 10,000 events. Use the date range to render in slices.

Notes (facts worth printing):

• A timestamp carried no time zone. UTC was assumed and the value is marked with an asterisk.
• A reply's parent event is not in this file. Marked "parent not in this file".
• An attachment is not PNG, JPG or GIF. Listed by name, size and SHA-256, not shown inline.
• A file in rsmf.zip is referenced by nothing. It is not rendered; open the source file to see it.
• A bare rsmf.zip without its wrapper. No X-RSMF headers were available to record.

Every finding is also printed on the transcript's first page, so the reader of the exhibit sees what the preparer saw. See Preparing text-message exhibits for what the panel asks and what the transcript carries.