Processing an RSMF file
Relativity Processing is the only viable method of importing Relativity's short message format (RSMF) files into Relativity. To process an RSMF successfully, point Processing to the RSMF container. 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
This page contains the following sections:
- Checklist for processing an RSMF file
- How parts of RSMF files are processed
- Results after successful processing
- Short Message Viewer
- Troubleshooting steps
Checklist for processing an RSMF file
Processing largely handles RSMF files like any other Internet Message Format such as EML. Within an RSMF file, there is an EML with a ZIP as an attachment, and within the ZIP is the JSON along with any attachments. Note that to successfully process an RSMF file, only the RSMF file needs to be processed by Relativity Processing. 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 |
|
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: RSMF 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 automatically extracted during processing to the following mappable fields:
RSMF header | Metadata field | Field type |
---|---|---|
X-RSMF-BeginDate | Rsmf/BeginDate | Date |
X-RSMF-EndDate | Rsmf/EndDate | Date |
X-RSMF-EventCount | Rsmf/MessageCount | Whole Niumber |
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 can be 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 i ntent 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 uses a string 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 rsmf.zip and the file will be placed within there.
- All discovered files, whether referenced within the rsmf_manifest.json or not, will be fully processed and given the same Group Identifier.
Attachments in RSMF files
There are four things you need to make sure RSMF files display correctly:
-
The Family (Group) Identifier field is mapped.
-
All documents are contained in the Family (Group) Identifier relational family.
-
The Relativity AttachmentID field is mapped.
-
Ensure the Extract children field on the processing profile is enabled. If this option is disabled, enable it and re-process the data.
The Short Message Viewer looks for attachment files in the Family (Group) Identifier's relational group that have the Relativity AttachmentID field set to the ID associated to that file in the RSMF's manfiest.json. If either the Relativity AttachmentID or Family (Group) Identifier field is not set, the Viewer cannot find the relevant image to display, and instead displays an error.
Troubleshooting attachments
If the Short Message Viewer shows an error on the attachments, you can troubleshoot by doing the following:
-
Verify that the Extract children field on the processing profile is enabled. If the setting is disabled, enable it and re-process the data.
-
Verify 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. To use the validator, visit RSMF validator.
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's short message format. The new viewer provides features to make it easy to review all aspects of RSMF 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.