Summary
- RFC 1911 reused MIME and ESMTP to replace analog inter-machine voice exchange with a minimum digital profile for systems that were not full Internet mail hosts.
- An advertised capability or completed SMTP transaction did not prove that a mailbox preserved recipients, trace fields and message identity, decoded the audio, produced a useful report or reached the intended listener.
- Demonstrations in 1996 and 1997 led RFC 2421 to change the profile significantly, showing that interoperability tests revise a specification rather than merely certify it.
The sound survived more easily than its history
The target machine in 1996 was not a desktop mail client with a microphone attached. It was usually a special-purpose computer connected to a telephone switch. It answered calls, kept voice messages and presented them through a keypad and handset. When such systems exchanged messages across organisational boundaries, the older method could be strikingly literal: dial signalling selected the destination and analog playback sent the voice.
RFC 1911 was published in February 1996 as Experimental, not as an Internet Standard. Its authority was therefore a documented trial of a minimum common profile, not certification that voice-mail machines had become complete general-purpose mail systems.
RFC 1911 proposed a different route. It profiled Internet mail rather than inventing a complete voice network. MIME would describe the content. ESMTP would move it. DNS would help locate a system. Structured notifications would return failures. That reuse gave the design mature components, but it did not erase the receiving machine’s constraints.
The document listed those constraints plainly. Many voice platforms could not display text. They often combined the Message Transfer Agent and User Agent in one box, performed final delivery and did not relay messages. Their stores might not preserve all recipients, Received trace fields or Message-ID. Mailing lists were local aliases, not general Internet lists. Mailbox names were commonly short numeric strings because the terminal was a telephone keypad. There might be no human operator to read an error report.
Those were not cosmetic omissions. A recording without its complete trace is still audible, but an investigation can no longer reconstruct the same route. A message without a durable identifier is harder to correlate with a failure report. A lost recipient list makes reply-all impossible. The profile could require correct fields on the wire while a local store remained unable to retain their full meaning.
A minimum profile was a boundary, not a product label
RFC 1911 sought a minimum common set. Conforming systems could support more, but they were not supposed to send enhanced formats to a destination without explicit knowledge that it could accept them. The document suggested a directory of remote capabilities and left its construction, maintenance and authority to local administration.
That local list carried real operational weight. It could decide whether a sender used the common audio format, an alternative codec or facsimile. Yet a row in the list was not a live negotiation receipt. It could be stale, associated with the wrong destination or more optimistic than the running software. The sender therefore needed to retain both the configured belief and the capability actually advertised by the SMTP peer.
The distinction also limited the meaning of conformance. “VPIM-capable” could refer to the baseline profile, optional functions, a later version, a gateway or only a configured route. It could not stand in for an exact MIME tree, codec, message size, server response, stored result and playback observation.
Ten keypad digits still needed a domain
Internet mail addresses separated a local mailbox from a domain. Voice systems often presented only a numeric mailbox to the caller. The machine had to convert that dialled value into a fully qualified destination, but RFC 1911 left the mapping mechanism implementation-specific.
That made the keypad number an input, not a globally self-sufficient identity. Two companies could use the same extension. A corporate numbering plan could change. A local mapping could direct an otherwise valid message to the wrong domain. DNS could resolve the chosen domain correctly and still say nothing about whether the earlier numeric-to-domain choice was right.
The required postmaster address gave administrators a conventional diagnostic destination. The first profile also proposed a loopback mailbox that returned a new message from postmaster. It tried to prevent a mail loop by changing the origin, but the later profile deprecated the special address for security reasons. A useful test mechanism had become a risk worth removing. Registration in a profile had not made the behaviour permanently safe.
SIZE counted bytes, not speaking time
Voice users experienced duration. ESMTP’s SIZE extension counted bytes, including the MIME wrapper. The conversion between the two depended on the audio encoding. A two-minute message could occupy very different transport sizes under different codecs and transfer encodings.
RFC 1911 selected Audio/32KADPCM as the mandatory common audio format. Other standard or proprietary formats were possible, but sending them without destination knowledge reduced interoperability. The common codec created a dependable floor; it did not prove sound quality on a particular device, successful decoding or an intelligible recording.
Transport encoding was another layer. If the path supported binary transport, audio bytes could travel without Base64 expansion. On a more restrictive path the same audio needed an ASCII-safe representation, making it larger. An advertised 8BITMIME, binary or chunking capability described what one SMTP hop said it would receive. It did not certify the final store, codec support or the listener’s result.
This is why an apparently simple metric could mislead. A sender might know that the spoken message fit a three-minute mailbox policy but discover that Base64 plus MIME overhead exceeded the receiver’s byte ceiling. A server could accept the envelope and reject the content later. A completed SMTP response could record transfer without proving that the special-purpose system preserved or played the message.
The error had to speak to a caller
With no operator and no screen, a prose bounce was not enough. The profile depended on machine-parsable delivery-status information that the voice system could convert into useful telephone feedback. That requirement made failure handling part of interoperability rather than an administrative afterthought.
But a structured notification still had a narrow meaning. It could report the status known to the reporting system. It did not prove that every previous hop retained the same message identity, that a successful final-delivery code meant successful decoding, or that the caller later heard the notice. The original envelope, Message-ID, notification correlation, mailbox action and user presentation needed separate records.
The demonstrations changed the object under test
RFC 2421 says its successor profile drew on a proof-of-concept demonstration at EMA’96 and product demonstrations at EMA’97. It describes the new version as significantly different from RFC 1911. The changes were not limited to editorial polish.
The new profile separated several definitions into their own documents. It removed positional dependence from multipart/voice-message while narrowing the contents permitted inside it. It specified forwarding and reply behaviour more clearly, added facsimile and directory-card support, expanded notification detail, deprecated the loopback address and enlarged the security discussion.
This is stronger history than a generic claim that “interoperability was demonstrated.” The tests produced evidence against assumptions embedded in the first profile. A package whose meaning depended on body-part position was made less fragile. A convenient diagnostic address was reconsidered. Reply, forwarding and security boundaries needed more exact language. The demonstrations did not grant RFC 1911 permanent operational authority; they helped replace it.
RFC 3801 later formally obsoleted RFC 2421, restated VPIM version 2 with greater precision and said it made no protocol change from that earlier document. That step preserved another distinction. Some revisions change the wire contract. Others improve the record by reducing ambiguity about the contract already intended. Both matter, but they are different receipts.
The profile worked by keeping its limits visible
The first Voice Profile for Internet Mail is easy to misread as a story of email absorbing voice mail. Its more useful lesson is smaller. A general infrastructure can host a constrained interoperability corridor if the profile names what the endpoints cannot do, chooses a true common floor and refuses to treat local assumptions as universal capabilities.
The final proof chain therefore runs beyond standards conformance. Resolve the intended domain. Record the peer and its current capabilities. Preserve the exact envelope and MIME structure. Correlate message identity and trace fields. Observe final delivery, stored semantics, decoding and playback. Link any delivery report to the same transaction. Only then ask whether the intended user heard the intended message.
A mailbox that accepted the sound had done something real. It had not necessarily preserved the message.
Sources
- RFC Editor record for RFC 1911
- RFC 1911 — Voice Profile for Internet Mail
- RFC 2421 — Voice Profile for Internet Mail, version 2
- RFC 3801 — Voice Profile for Internet Mail, version 2
- RFC 822 — Standard for ARPA Internet Text Messages
- RFC 1521 — MIME Part One
- RFC 1651 — SMTP Service Extensions
- RFC 1652 — 8BITMIME
- RFC 1653 — Message Size Declaration
- RFC 1891 — SMTP Delivery Status Notification Extension
- RFC 1894 — Delivery Status Notification Format
Member Briefing
Deeper Profile Context
Sign in with the right membership level to unlock the full briefing and source notes.
Only for Strategic Circle
Strategic Circle
Open to all readers. Unlock profile briefings after joining and signing in.
Join Strategic CircleOnly for Leadership Alliance
Leadership Alliance
For qualified IP-asset owners and management; sign in to unlock alliance briefings.
Join Leadership Alliance
