The DIMG (Dual-Image) File Format Specification

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 3 December 2025.¶

Copyright Notice

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

The proliferation of digital documentation requiring paired image submissions (e.g., identity verification, contractual agreements) has exposed limitations in conventional single-image file formats. DIMG solves this by introducing:¶

• Dual independent image blocks within a unified container¶

• Native support for front/back documentation paradigms¶

• Streamlined upload/review workflows¶

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

Security considerations are discussed in Appendix A.¶

2. Architecture

DIMG employs a segmented structure with three primary components:¶

+-------------------+
| File Header       |
| (Magic: 0xD1MG)   |
| Format Version    |
| Metadata Pointer  |
+-------------------+
| Block 1 Header    |
| Compression Type  |
| Dimensions        |
| Data Offset       |
+-------------------+
| Block 2 Header    |
| Compression Type  |
| Dimensions        |
| Data Offset       |
+-------------------+
| Metadata Section  |
| (JSON/XML)        |
+-------------------+
| Image Data 1      |
| (Variable Size)   |
+-------------------+
| Image Data 2      |
| (Variable Size)   |
+-------------------+

Key structural attributes:¶

1. File Header: 16-byte identifier with format versioning¶

2. Block Headers: Independent compression/dimension parameters¶

3. Metadata Section: Contains relationship descriptors (e.g., "front", "back")¶

3. Operational Workflow

DIMG supports two population methods:¶

INSERT INTO Block1: photo_front.jpg
INSERT INTO Block2: photo_back.jpg
SAVE AS document.dimg

LOAD multipage.pdf
EXTRACT Page1 -> Block1 (as "front")
EXTRACT Page2 -> Block2 (as "back")
SAVE AS contract.dimg

4. Use Cases

Primary application scenarios include:¶

• Government ID verification (passports, driver licenses)¶

• Financial instrument processing (checks, payment cards)¶

• Legal document management (signed contract pairs)¶

• Product catalog imagery (front/back views)¶

5. Advantages

Comparative benefits over conventional approaches:¶

*Per industry usability studies ([FinTech2024])¶

See Appendix A for security implications of metadata handling.¶

Appendix A. Security Considerations

Implementations MUST address the following security concerns:¶

1. Validate block headers to prevent buffer overflow attacks¶

2. Sanitize metadata sections against XML/JSON injection vulnerabilities¶

3. Restrict maximum block size (RECOMMENDED: 20MB per block)¶

4. Implement content verification for extracted image data¶

Additional recommendations:¶

• Use cryptographic signatures for tamper detection¶

• Employ encryption for sensitive document types¶

• Validate MIME types in image blocks¶

Appendix B. IANA Considerations

The following registrations are requested:¶

• Media type: application/dimg¶

• File extension: .dimg¶

• Magic Number: 0xD1 0x4D 0x47 0x1A¶

Author's Address