Summary

  • RFC 3939 created Caller-ID and Caller-Name headers to preserve what the telephone system presented for a stored voice-mail message, without making those values authenticated identity.
  • Its own failure cases showed why transport was not portability: a local extension could become useless and revealing after forwarding, while a truncated international number could produce a plausible callback to the wrong person.

A number needed somewhere to live

A call arrives, nobody answers, and the caller leaves a voice message. The telephone network knows a number and perhaps a display name. The Internet mail store that will hold the recording knows how to address mailboxes, but it may know no email address for the speaker. That mismatch was the problem addressed by RFC 3939, published on the Standards Track in December 2004.

The existing choices all distorted the ordinary From field. A system could put a telephone number in a display name, manufacture an address around the digits, or say that the originator was unknown. RFC 3801, the Voice Profile for Internet Mail, already recognized the special non-mail-user originator for a telephone-answering message that could not receive an Internet-mail reply. RFC 3939 therefore gave the telephone presentation data its own place: Caller-ID for the number and Caller-Name for the name.

That separation was useful because provenance mattered. The mail From field described a message originator in the Internet-mail system. The new fields recorded what the telephone system had supplied to the called party. They did not reconcile those two identities, and they did not turn the telephone display into proof.

The header preserved digits, not a route

The Caller-ID grammar was deliberately spare: one or more digits, optionally followed by a NumberingPlan parameter. Hyphens, spaces and even the leading + used in many international representations were excluded. For an internal call, an enterprise might record only an extension. For an international call, the RFC called for the full E.164 sequence—country code, national destination code and subscriber number—up to 15 digits.

The crucial qualifier was optional. Without NumberingPlan, the default meaning was unknown. local meant that the number belonged to a plan understood inside the domain of the voice-mail system that stored the message. e164 declared the international structure. The same digits could therefore carry very different operational value depending on a small piece of surrounding metadata.

RFC 3939 was explicit about its boundary. It intended to store a number received from the telephone system without alteration or interpretation. It did not define an addressable or dialable phone number. Other specifications did that work. RFC 2806 required a context for local telephone URLs because identical local digits can mean different things in different areas. RFC 3191 encoded a global E.164-style number in an Internet-mail address and reserved a leading + for that form. Those richer formats demonstrate what a bare captured string did not contain.

The design thus preserved an observation: these were the digits presented when the message was stored. It did not preserve every fact needed for a future action. A callback also needs a dialing context, current routing, authority to place the call and an outcome. None follows from the header alone.

Forwarding broke the invisible boundary

The most revealing case was not malformed syntax. It was a valid local extension leaving the place where it was valid. Inside a company, 4087 might be sufficient. If the call-answer message was forwarded to an outside recipient, those four digits could no longer identify a reachable destination. Worse, the forwarded header could reveal part of the company's private dialing plan.

The value had survived perfectly. Its meaning had not. This is a recurring Internet failure mode: systems celebrate lossless carriage while overlooking the administrative boundary that supplied interpretation. The message envelope could cross domains more easily than the private numbering plan could.

The international case was more dangerous because it could look correct. RFC 3939 warned that some systems truncated numbers to ten digits. Its example began with an Irish number; after leading digits were removed, the remainder resembled a North American number. A recipient might not see an obvious error. The interface could offer a callback that reached an unrelated and understandably annoyed person.

This was not merely missing data. Truncation converted one meaning into another plausible meaning. A validation rule that checked only “ten digits present” would reward the corruption.

A name was display data too

Caller-Name had its own portability problem. Telephone signaling could supply several character sets. RFC 3939 used ASCII as the base representation and allowed RFC 2047 encoding for a native character set when seven-bit ASCII was insufficient. A receiving system without the same coding options could display an incorrect name. Providers could also shorten what they delivered, in some cases to 15 characters even though the header allowed 50.

Nothing in that machinery authenticated a human. A caller name was information presented by the telephone network, bounded by its signaling, provider policy and display limits. The RFC's security section treated restricted information accordingly: the headers should contain what the called party would have seen, such as Private Name, rather than hidden inter-provider details.

But the move into email created a second privacy surface. A phone number could now sit in message headers, travel with forwarding and remain invisible unless the mail client chose to show it. The called party may have been permitted to see a number on a telephone screen; that did not mean every later recipient understood the value's provenance or sensitivity.

Even time was not singular. If the telephone system supplied a date and time, an implementation could put it in the ordinary Date header—or use the local system time instead. The stored timestamp therefore needed provenance before it could be treated as the exact time of the call.

RFC 3939's historical importance lies in this modest design. It solved where to store telephone presentation data without pretending that a new header could make networks agree on identity, context or action. The number crossed into Internet mail. The private plan, character repertoire, disclosure expectations and evidence needed to prove a successful callback did not automatically cross with it.