FAILURE MAP
← Case archive

FA-76362 / Email MIME structure / Member archive

Assign IMAP-style section numbers to body parts: encapsulated multipart · case 02

Parts of an attached multipart message get an extra ".1" level, so fetching them returns the wrong entity.

Member previewVariant 2 · 3 implementations · 6 checks per implementation

Case contract

Returns [section, type] for every non-multipart entity in depth-first order. A single-part message body is section "1". Children of a multipart are numbered 1..n under the parent's number (nested multiparts get their own number). A message/rfc822 part is listed itself; if its encapsulated body is multipart, that body's children are numbered directly under the message part (P.1, P.2...); a single-part encapsulated body is P.1.

Why this case matters

Section numbers are how clients fetch individual parts; off-by-one numbering downloads the wrong attachment.

One recorded failure

Sample boundary fixture

This sample comes from the broken implementation of a controlled reproducer.

Boundary fixtureActualExpectedOutcome
attached multipart message[["1", "text/plain"], ["2", "message/rfc822"], ["2.1.1", "text/plain"], ["2.1.2", "image/jpeg"]][["1", "text/plain"], ["2", "message/rfc822"], ["2.1", "text/plain"], ["2.2", "image/jpeg"]]Failed

MEMBER ARCHIVE

The complete case is available to members.

This record includes three runnable implementations, regression fixtures, execution results, and source hashes.

Member access is invitation-based. Sign in with your invited account to inspect the sources.

Sign in to the archive ↗