Processing an RSMF file

Relativity Processing is the only viable method of importing RSMF files into Relativity. This is because Simple File Upload doesn't recognize RSMF files, and the Relativity Desktop doesn't properly extract attachments and then it requires you to manually map attachments to the appropriate messages.

If you are using a non-Relativity tool, attachments need to be manually tied to the appropriate messages. RSMF is wrapped in an EML so other processing tools should be able to process the other aspects of the RSMF file.

To prepare your RSMF files to be processed into RelativityOne, use Staging Explorer to get the data ready. To learn more, visit RelativityOne Staging Explorer.

This page contains the following sections:

Checklist for processing an RSMF file

Processing largely handles RSMF files like any other Internet Message Format such as EML. Standard fields such as To and CC are processed as usual. If you include information in the Body field, it will display in Extracted Text mode of the Short Message Viewer.

We recommend preparing the following before you process an RSMF file:

Feature Steps needed to prepare
Processing profiles
  • Default processing profile will handle RSMF and subsequent mapping.

  • Ensure Extract children is set to Yes, otherwise this results in missing attachments.
  • The Processing application comes with one field that is custom to RSMF. The Relativity Attachment ID is the only system-mapped field and cannot be changed.
  • Ensure there is a field that is called Group Identifier whose Source is Group Identifier. See screenshots below for an example. Setting up Group Identifier in this manner will ensure that attachments appear in the Short Message Viewer and are tied to the correct parent messages.
    (Click to expand either image)
RSMF Header fields The fields marked as required must be included in the RSMF Header. Fields that will be populated in the document list are the email fields, and beg/end, and message count.

Note: RMSF files greater than 200MB may error and be unable to process. Relativity recommends creating and processing RSMF files no greater than 200MB.

Note: We recommend that an RSMF file should have no more than 10,000 events to ensure high performance in Relativity.

How parts of RSMF files are processed

The following subsections describe how different parts of RSMF are handled during processing.

RSMF Header

The optional headers that begin with X-RSMF are extracted to the following mappable fields:

  • X-RSMF-BeginDate → Rsmf/BeginDate

  • X-RSMF-EndDate → Rsmf/EndDate

  • X-RSMF-EventCount → Rsmf/MessageCount

If the RSMF file doesn't include a Sent Date, and the X-RSMF-BeginDate header exists, that header will be mapped to the Sent Date field.

If Sent Date is included, then the value in X-RSMF-BeginDate will map to a new field called Rsmf/BeginDate.

If the RSMF file does not include Last Modified, then X-RSMF-EndDate will map to Last Modified.

If the RSMF file includes Last Modified, then X-RSMF-EndDate will map to Rsmf/EndDate.

The Message Header field should exist prior to Processing an RSMF file. This field will be populated with all of the metadata stored in the EML header of the RSMF file. The Message Header field is a non-relational, ‘Long Text’ field.

Header Required in RSMF 1.0 Required in RSMF 2.0 Description
X-RSMF-Version Yes Yes The version of the RSMF specification that the file adheres to.
X-RSMF-Generator No No Identifies the author of the RSMF file.
X-RSMF-BeginDate No No The timestamp (ISO8601) of the earliest short message event within the file.
X-RSMF-EndDate No No The timestamp (ISO8601) of the latest short message event within the file.
X-RSMF-EventCount No No The number of short message events captured within the file.
X-RSMF-Application Unavailable in RSMF 1.0 No

This is used to identify source of the data, which is intended to be ambiguous. For example, it could be the platform/app of the data contained in the RSMF file.

The intent with this field is to allow for better sorting of messages in the document list via a long text field.

X-RSMF-Custodian Unavailable in RSMF 1.0 No

This field is used to identify from whom the data was collected from.

The intent with this field is to allow for better sorting of messages in the document list via a long text field.

X-RSMF-Participants Unavailable in RSMF 1.0 No

This field can be used to identify a string of names that are present in the conversation in the RSMF file.

The intent with this field is to allow for better sorting of messages in the document list via a long text field.

X-RSMF-AttachmentCount Unavailable in RSMF 1.0 No

This field should be a number that is a sum of all of the attachments present in the RSMF.

The intent with this field is to allow for better sorting of messages in the document list via a long text field.

X-RSMF-EventCollectionID Unavailable in RSMF 1.0 No

This field should be a unique ID that is to be used to help keep many RSMFs from a single conversation together.

The intent with this field is to allow for better sorting of RSMFs in a document list to group parent RSMFs to the same conversation, if conversations/RSMFs are broken up for review purposes prior to being put into Relativity.

Note: The Message Header field should exist prior to processing an RSMF file. This field will be populated with all of the metadata stored in the EML header of the RSMF file. The Message Header field is a non-relational, ‘Long Text’ field.

RSMF.ZIP

The rsmf_manifest.json file is not discovered as a publishable file.

For any other file within the rsmf.zip, the following rules apply:

  • If the file is referenced within the rsmf_manifest.json:
    • The virtual path will exclude the rsmf.zip portion in order to avoid the creation of an rsmf.zip folder in Relativity once the file is published.
    • When published, a field called Relativity Attachment ID will be populated with additional metadata. If the file is an attachment, the metadata will be the id of the attachment as specified within the rsmf_manifest.json. If the file is an avatar, the metadata will be the name of the file. The Relativity Attachment ID is a system field that the Short Message Viewer uses to provide enhanced support for attachments and avatars.
  • If the file is not referenced within the rsmf_manifest.json, it is processed as any other file contained within a zip within an EML. So, when published, it will create a folder called rmsf.zip and the file will be placed within there.
  • All discovered files, whether referenced within the rmsf_manifest.json or not, will be fully processed and given the same Group Identifier.

Results after successful processing

Once processing has been successfully completed, the method in which the attachments\embedded images display in the Document list is as follows:

  • The top-level document, the parent, will contain the entire thread of the conversation. Each of the child IMG files are images that occur within that conversation. These will appear separately, as children of the conversation in much the same way an embedded image in an EML file would occur as a child of the email.

Short Message Viewer

Relativity's review interface has been updated with a new viewer that will automatically be displayed when using the Viewer radio button for any document identified as Relativity Short Message Format. The new viewer provides features to make it easy to review all aspects of RMSF files including conversations, participants, messages, and attachments. To learn more, visit the Short Message Viewer.

(Click to expand)

Troubleshooting steps

If the Short Message Viewer shows an error on the attachments, troubleshoot issues with the following tips:

  • Check if the “Extract children” setting on the processing profile is enabled. If disabled, enable this setting and re-process the data.
  • Check that the Family (Group) Identifier field is mapped. This is a relational field which indicates the family relationship between the parent RSMF and the children attachments. If this field is not mapped, the Viewer will not know which RSMF file the attachments belong to.
  • Consider running the RSMF file through the RSMF validator if attachments are missing.

If you are missing attachments and see errors in the RSMF file where the attachments should be, do the following:

  • Check if the Extract children setting on the processing profile is enabled. If disabled, enable this setting and re-process the data.

If the attachments are not linked to the RSMF file(s), do the following:

  • Check that the Family (Group) Identifier field is mapped. This is a relational field which indicates the family relationship between the parent RSMF and the children attachments.
  • Consider running the RSMF file through the RSMF validator if attachments are missing.

If you would like to adjust the fields that RSMF maps to, you can do the following:

  • If you want to map your own custom headers, you have to change the spec for the RSMF (custom metadata for RSMF is not currently supported).

If it appears that Processing is ignoring the Sent Date field or Last Modified field, you can do the following:

  • If the RSMF file doesn't include a Sent Date, and the X-RSMF-BeginDate header exists, that header will be mapped to the Sent Date field. The latter takes precedent to the former if both are present.
  • The same goes for the ‘Last Modified’ field and X-RSMF-EndDate with taking precedent if both are present.

If all of your data is populated accurately in the Group Identifier field, but your attachments are still not showing up, then verify that the Group Identifier field has the correct GUID. If you have SQL access, query for where the GUID is 1F036749-A691-4AA8-8CF7-5EEB80C36CAF. Otherwise, please contact Relativity Support for assistance.