Summary

  • RFC 5255 separates human-readable response language and translated namespace presentation from canonical mailbox identity; a localized label is not a rename.
  • It also makes the active comparator part of SEARCH, SORT and THREAD semantics, so query results need decoding, conversion, comparator and fallback provenance rather than a bare list of message identifiers.

Internationalization contains more than one kind of power

The word “language” looks harmless in an operations console. It appears to concern labels, help text and user preference. In an IMAP session, however, changing the language of an explanation and changing the rules by which text matches are two very different acts. RFC 5255 specifies both, and it keeps them separately advertisable for a reason.

The LANGUAGE extension lets a client ask for human-readable server responses in a supported language. In combination with NAMESPACE, it can also return translated presentations of namespace prefixes. The I18NLEVEL extensions govern how SEARCH, SORT and THREAD compare human-readable strings. One choice changes what the interface says; the other can change which messages appear and in what order.

Neither operation changes the stored mailbox or message. Yet a system that records only “internationalization enabled” loses the exact distinction that makes later results explainable. It cannot say whether a different display came from a language choice, whether a different search came from a comparator, or whether a fallback path silently substituted octet comparison for a linguistic rule.

A translated prefix is a presentation, not a new namespace

RFC 5255 is unusually clear about the narrow authority of LANGUAGE. It alters fixed server strings such as response text and NAMESPACE folder names. Assigning localized aliases to shared mailboxes belongs to another mechanism. That exclusion stops presentation from becoming identity by accident.

The NAMESPACE TRANSLATION value is a rendered counterpart to a canonical prefix. The client is responsible for converting between the prefix and its translated representation when it presents mailbox names. The mapping must therefore remain reversible. If a client stores only the translated string, a change of language can look like a mailbox rename or create two apparent folders for one canonical location.

That is not merely a user-interface inconvenience. Caches, bookmarks, access-control displays, migration tools and audit records may all consume the visible name. A reliable client binds every presentation string to the canonical namespace prefix, language tag, server identity and session generation that produced it. It does not let translated text become an identifier in downstream automation.

A successful LANGUAGE command selects the first supported match and takes effect immediately after the server's LANGUAGE response. A response containing one tag announces the active choice. A response containing several tags enumerates what is available and changes nothing. A failed request also leaves the old language in place. Those are three different transitions, even if a UI reduces each to a language menu.

The special request default is another warning against overinterpretation. It asks for a language preferred by the server administrator, and that preference may depend on the current user. “Default” is policy output, not a universal locale, mailbox property or durable statement about the person.

Security creates a new language generation

LANGUAGE is valid before authentication because pre-authentication responses can contain information a user needs to understand, including expired-password or failed-security messages. That usefulness places negotiation on an unprotected surface.

RFC 5255 identifies the consequence. An active attacker can suppress or modify a LANGUAGE exchange before SASL or TLS becomes active, making subsequent security and authentication errors harder to interpret. Once a security layer is established, the client must issue LANGUAGE again so the earlier manipulation cannot govern later protocol operations.

The second command is not a cosmetic repeat. It begins a new authority generation. A record of the selected language should say whether it came before or after the security transition, which transport or SASL layer was active, what the server returned and when the choice took effect. Otherwise an application can carry a pre-security preference across the very boundary intended to make the session trustworthy.

Reissuing LANGUAGE does not authenticate the prose itself, make credentials valid or change an IMAP result code. It simply ensures that the language choice governing later explanations was negotiated inside the protected generation. Machine-readable status, human-readable explanation and authenticated channel remain separate receipts.

The comparator is executable query policy

RFC 5255 uses “default comparator” for the rule applied when no negotiated choice exists, and “active comparator” for the rule currently used in a session. I18NLEVEL=1 requires i;unicode-casemap. I18NLEVEL=2 adds the ability to inspect and select comparators through COMPARATOR.

That selection is not metadata beside a query. It is part of the query's meaning. The active comparator applies to defined SEARCH keys such as subject, body, sender and header fields. It also governs relevant SORT keys and subject comparisons used by THREAD. A request for the same visible word can therefore return different membership or order under different comparators without any message changing.

Once the connection is authenticated, the server's default comparator must remain static for that connection. This gives the implicit baseline a stable generation. A client can still change the active comparator explicitly, and that transition needs its own request and response record. “Default” and “active” cannot be collapsed if the operator wants to reproduce a result.

The supported operation matters as well. SEARCH needs substring comparison. SORT needs ordering, which in turn depends on equality. A comparator that cannot provide the required operation cannot simply approximate it; the command must fail. A successful comparator selection is thus not proof that every later command can use it.

The result begins before comparison

The comparator receives text only after a pipeline has already acted. MIME encodings in headers and bodies must be removed. The decoded text is then converted to the charset expected by the comparator. Only after those steps does the selected comparison rule evaluate it.

Each stage can change the evidentiary meaning of a result. RFC 5255 leaves some MIME-decoding failures implementation-dependent. Charset conversion can fail. The active comparator can declare input invalid or return an undefined result. The protocol therefore defines fallback behaviour instead of pretending every string shares one clean representation.

For substring operations, conversion failure causes the original decoded text to be compared with i;octet; an undefined result can also trigger i;octet. For ordering, successfully converted and valid strings are collated with the active comparator. Failed or invalid strings form a separate group, are ordered with i;octet, and are appended after the valid group.

A user may see a coherent list while part of that list was ordered under a different rule. A search can succeed because octets matched after linguistic comparison became unavailable. The visible result does not reveal this provenance. A defensible receipt keeps the message or field generation, MIME-decoding outcome, declared charset, conversion outcome, requested comparator, selected comparator, fallback comparator and exact result membership or order.

Same content does not guarantee the same answer

Two conforming systems can store equivalent messages yet differ in supported charsets, installed comparators or error handling where the specification leaves behaviour implementation-dependent. Even one server can return a different answer after an upgrade changes its decoder or comparator library.

That does not make the protocol arbitrary. It means reproducibility depends on more than the query string. The relevant state includes server software and policy generation, capabilities, session security generation, active comparator, decoding path and corpus generation. Without those joins, an incident record that says “SEARCH returned nothing” cannot distinguish an absent message from a comparison path that did not understand its text.

The IANA IMAP Capabilities registry still records LANGUAGE, I18NLEVEL=1 and I18NLEVEL=2 under RFC 5255. The registry establishes names and references. It does not prove that a particular deployment advertises them, implements every required operation correctly or uses the same comparator version as another server.

Later UTF-8 support did not erase the boundary

RFC 5255 does not claim to make every IMAP identifier international. Its security discussion notes that these extensions use UTF-8 but not for identifiers. Later work such as RFC 6855 added UTF-8 support for user names, mail addresses, message headers and mailbox-name handling. RFC 9051 then replaced IMAP4rev1 as the base protocol.

Those later changes make the original boundary easier to see. A localized response string, a translated display prefix, a UTF-8 mailbox name and a comparator-normalized search term may all contain the same script while exercising different authority. Script equality is not identity equality.

Operations should therefore avoid a single “locale” field that controls presentation, canonical addressing, search semantics and security state. Each decision needs a scoped value, an issuer and a generation. The joins between them should be explicit enough to replay what a user saw without turning the user's view into the canonical record.

Lu Heng's reality-layer discipline supplies the leadership rule. The localized interface is real at the presentation layer. The mailbox is real at the namespace layer. The query result is real for one comparator and decoding generation. Authentication is real for one security channel. Confusion begins when one layer is allowed to certify another. Clarity comes from preserving the boundary and the reversible mapping.

Sources