Summary

  • RFC 1394 assembled names, telephone country codes, telex country codes, answerback letters and Internet domains into a single dated crosswalk. It described what corresponded, not what was live or authoritative.
  • The memo exposed uncertainty instead of filling it: it used different missing-value markers, warned that some codes might be wrong and invited corrections through three communication systems.
  • Its sharpest boundary was operational and political. A known code did not prove a permitted circuit, a registered DNS name, an authoritative delegation, message delivery or recognition of a country's status.

One row joined several systems

In January 1993, RFC 1394 tried to reduce a practical form of friction. Someone who knew how a place appeared in one communications system might not know its representation in another. The memo aligned an area or country name with a telephone dialing code, a telex country code, an answerback string and an Internet domain.

That was a useful act of compression. A reader could begin with one familiar value and discover candidates for the others. The table also included major public email systems and subnational entries such as US state domains. It therefore mixed several kinds of reference: geographic labels, numbering-plan values, network namespaces and provider-specific addresses.

The columns did not become interchangeable merely because they shared a row. A telephone prefix instructed a switching system. A telex country code and answerback belonged to another service. A country-code domain occupied a branch of the DNS naming tree. A commercial mail-system label could lead to a provider rather than a territory. The row expressed an asserted relationship among them; it was not a universal conversion algorithm.

Missing information remained visible

RFC 1394 defined two kinds of absence. A four-dash marker meant that no telephone code was known. A three-dash marker covered other missing or unknown information. That small distinction prevented a blank cell from silently acquiring a single meaning.

The table itself made incompleteness ordinary. Some places had a domain but no listed telex answerback. Some had several telex codes. Some names were historical, alternate or nested within another jurisdiction. Multiple rows could converge on one domain, while a single geographic label could carry several communication values.

The document did not claim that editorial care eliminated those conflicts. It said the information had come from several sources in several countries, that accuracy could not be guaranteed and that some codes might be wrong. Corrections were invited by post, email or telex. The list had a custodian and a repair path, but no mechanism that made every printed value current at the moment of use.

This is the difference between a published observation and a live authority. The observation can be careful, useful and revisable. It still needs a date, source and later confirmation when the cost of error is high.

A domain-shaped value was not a delegation

The country-domain column rested on a prior naming decision. RFC 920 had described country top-level names using the English two-letter alpha-2 codes from ISO 3166. It also said that administrators and agents would be listed as country domains were established. The code source, the permitted label and the act of establishing a domain were separate.

RFC 1034 later gave that separation operational form. DNS divides the namespace into zones. A server is authoritative only for a bounded part of the tree, and responses distinguish authoritative data from cached information about other zones. Delegation requires records at a namespace cut and the information needed to reach the child servers.

RFC 1394 did none of those acts by printing two letters in a column. Its row could tell a reader that a domain was believed to correspond to a place. It could not create the delegation, appoint its manager, publish its current name servers or prove that those servers answered.

The boundary also worked in reverse. A working DNS delegation did not certify that every telephone or telex code beside it remained current. Each system kept its own operator, update cycle and failure modes.

Some familiar suffixes were only gateway notation

The memo was especially clear about BITNET and UUCP. Names ending in .BITNET or .UUCP were used within those communities but were not registered DNS names. To reach them from the Internet, mail had to be transformed and sent through a gateway, using the percent-sign routing practice described in the notes.

That detail prevents a common historical mistake. A string could look like a domain and appear in an Internet-facing address without existing as a delegated DNS branch. The gateway, not DNS resolution of the apparent suffix, supplied the next step.

A gateway route was also not a delivery receipt. It showed that an intermediary knew a transformation and accepted a message for onward handling. The remote community, destination system, mailbox and human reader remained later states with their own evidence.

RFC 1394 described .ARPA differently: a historical part of the DNS namespace used for reverse lookups of hosts and networks. Similar punctuation therefore concealed different authorities. Syntax alone could not tell the reader whether a suffix was delegated DNS, community notation or a gateway convention.

The circuit could be absent or forbidden

The table's most important sentence sits before its many rows. Whether a user could reach a country depended on whether a connection existed and whether connections were permitted. The memo named political restrictions as a reason a call could fail.

This separated three records that a neat crosswalk might tempt readers to merge. The first was descriptive: a code was associated with a place. The second was operational: a carrier path existed from this origin at this time. The third was permissive: the parties and applicable authorities allowed that path to be used.

A failed contact did not identify which layer had failed. The code might be wrong or stale. The origin network might lack a route. A gateway or destination could be down. Policy could prohibit the connection. The destination might answer but reject the recipient. Silence was not a verdict on the place, the person or the validity of the code.

The opposite inference was equally unsafe. A successful connection proved that some path completed an exchange. It did not make the table authoritative for every other service, establish a legal right to future contact or show that the destination identity had been authenticated.

The catalog refused to decide countryhood

RFC 1394 also disclaimed any standing on the validity of a country's name or existence. It solicited old and alternate names because those labels helped people find a row; it did not treat editorial inclusion as diplomatic recognition.

That restraint mattered in a table containing former states, disputed names, territories, provider networks and country codes side by side. A catalog needs enough descriptive flexibility to guide users through messy history. If every row were read as a constitutional act, correction would become political adjudication and omission would resemble erasure.

RFC 1591 later described the administration of top-level domains and the duties of designated managers. It called those managers trustees for a delegated domain and required operational and contact responsibilities. It also stated that IANA was not in the business of deciding what was and was not a country; the ISO 3166 list supplied a separate procedure.

That later memo did not turn a code into sovereignty. It showed a chain of bounded responsibility: one body maintained a country-code source, another coordinated the root, a designated manager operated a domain, and networks chose whether and how to reach services under it. None acquired all the others' authority.

A useful table stayed thin

RFC 1394 did not discuss security. It offered no authentication for a row, no proof that a contact had consented, no guarantee that a gateway preserved authorship and no audit trail for delivery. Those absences are not reasons to dismiss the document. They define the job it could safely do.

Its durable achievement was modest and important. It let users translate uncertainty into the next question. Which code should be checked? Is this suffix actually registered? Which manager is authoritative? Does a route exist from here? Is the connection permitted? Did the destination accept the message?

The list became useful precisely because the answers were not collapsed. A correspondence could guide an inquiry without ruling a territory, operating a circuit or certifying an outcome. The Internet's common layer worked best when it made references portable and left execution to the actors who actually possessed it.