Here are some quick notes about the RSMF file format and how it's used in ediscovery.

The Relativity Short Message Format was created by Relativity in order to have a fairly generic way to organize chat messages into documents, both for cell phones and centralized messaging tools like Slack.

The Relativity viewer can then display the messages grouped into a document with some basic in-document filtering available. Some third party review platforms also support RSMF files, but with varying degrees of usefulness.

If you have an RSMF and need to quickly preview and validate it, take a look at our standalone RSMF Viewer.

From a technical perspective, the RSMF file format is pretty well defined. Relativity also provides a library for helping developers validate RSMF files they are constructing.

To be very literal, an RSMF file is an EML file with a specially structured RSMF.zip file attachment. The RSMF.zip contains an rsmf_manifest.json which is the structured message content. File attachments to the messages are included in the zip and referenced by the manifest.

From a reviewer's perspective, the content they see is determined by the manifest file. The viewer takes the structured content and renders it into a readable document. Images are rendered inline on the face of the document, while other attachments are linked to the corresponding document in Relativity (via the Relativity Attachment ID field).

From a processing and searching perspective, the EML part of the RSMF file is the more important part of the document. Standard email metadata is extractable and searchable, and the RSMF specific X-RSMF header fields are also in the email header.

The body text of the EML file (not the rsmf_manifest.json) is what gets indexed for text searches, so if you are receiving RSMF files from a third party it's important to validate both the manifest and the text body if you are planning to run searches.

Populating the Relativity Attachment ID is very important for the viewer to function--if it's not set correctly the face of the document will show an error message. This field can also be used to work around processing quirks with RSMF files, such as a zip attachment being excluded during processing (but referenced by the manifest) and for dealing with oversize files, especially videos, where embedding the file in the RSMF.zip creates excessively large natives, but where uploading the file as a native on a separate record is fine.

For producing out of Relativity, you have two basic options:

• Produce as-is, imaging the RSMF files in Relativity imaging.
• Use Relativity's RSMF Slicing

RSMF slicing lets you construct a new RSMF out of an existing RSMF, with a manual workflow for selecting which messages to copy into the new RSMF. The idea behind this is that it can be useful to cut out non-responsive clutter surrounding messages that need to be produced.

The downside is that it adds complexity to the most sensitive parts of ediscovery (productions and privilege). In particular the sliced documents aren't as transparent as a basic redaction when it comes to what was modified and why.

Additionally it is fairly standard practice for RSMF documents to be split per day in order to prevent overly large documents. The ideal 'clean' conversation might span multiple days, which slicing doesn't help with if the conversation is already split.

Ultimately there always needs to be some sort of arbitrary split when it comes to things like Slack and Teams messages. If that document split causes confusion or mistakes during review and production, it's a lot easier to explain "we decided to split documents per day to prevent excessively large documents" than "on this specific document a reviewer misclicked and removed a responsive message from the production document."

That said, anyone who has been involved in large productions filled with redactions knows that imaged productions aren't exactly the easiest and smoothest things to put together either, but in ediscovery complexity is the enemy, so standardizing workflows when possible between message documents and typical documents can be helpful.

Since an RSMF file is literally EML file, they are sometimes used as a way to preserve text messages in email compliance software. If you need to do this for FINRA/SEC compliance or similar, it's a reasonable workaround even if it's not the most technically optimal preservation method.

Much like processing for ediscovery, the email compliance tools are relying on the standard email structure for searching and retrieval, so you need to ensure that the RSMFs you are ingesting will actually be accessible down the road. The RSMF format is strict about the structure of the rsmf_manifest.json, but the EML portion is mostly up to each individual tool constructing the RSMF to determine, so don't make assumptions about what will be in there.

Hopefully that is a useful summary of RSMF files. If you have questions or need help with a specific matter, feel free to reach out.