Summary

  • RFC 1277 encoded the information needed to try an OSI connection over TCP/IP or certain X.25 networks when no OSI network service was available.
  • Its globally unique address format could identify a network and carry transport-specific parameters; allocation did not, by itself, guarantee that the address routed or that a service responded.

OSI's directory could return a Presentation Address, but the address model assumed network-layer addresses from an OSI service. The assumption did not fit every pilot. OSI applications were running over the Internet, private or public X.25, and isolated networks. Requiring every experiment to wait for one global OSI network would have made the directory unusable in the environments where people were trying it.

RFC 1277 addressed one narrow step in the connection chain. An application looked up a Presentation Address; a client then had to extract each network address, decide whether it could use it and how, order its preferences, and attempt a connection. The memo concentrated on that extraction step. It defined address encodings from which a client could infer the lower-layer information that the directory did not supply separately. It did not define the whole connection procedure, route discovery, or a successful application exchange.

The distinction was important because an address carried several jobs. For international X.25, an X.121-form address could identify a DTE and, in the appropriate case, support a route across the public X.25 network. But an allocation identifier was not inherently topological: an end system could not assume that every globally allocated part of an address described a path. RFC 1277 says the IDP was primarily an allocation mechanism and that users could not in principle infer routing from it.

The memo's recommendation to interpret certain X.121 forms as routes was qualified by the service and format in use, and private means might reveal preferable alternatives.

For TCP/IP networks carrying the OSI transport service defined by RFC 1006, RFC 1277 used a different encoding. Its network-specific part placed a 12-digit IPv4 address first, followed optionally by a five-digit port and a five-digit transport-set value. The latter was a 16-bit flag word: bit values represented TCP and UDP, while an absent or zero value meant the default, TCP. The RFC's worked example encoded 10.0.0.6, port 9, and UDP. That is a parsing recipe for a connection attempt—not proof that the address was current, reachable, listening, or authorized.

The new format also had to be distinguishable from an address used by a genuine OSI network service. RFC 1277 selected the Telex AFI for its format because it left a larger domain-specific part and was less likely to be confused with those other uses. A short prefix separated subnetworks and the remainder carried network-specific data. The design traded a compact, self-describing structure for a long decimal representation; the memo notes that a binary ASN.1 form would have been attractive but did not fit the available address space.

That trade-off belonged to a transitional engineering environment, not a timeless address law. The memo's historical note says the approach had been implemented and its viability demonstrated in the THORN and ISODE/QUIPU projects. That is evidence of a working proposal in those projects, not proof of broad deployment. RFC 1278 later described a human-readable string for Presentation Addresses, expressly for display rather than internal storage; that is a different layer from RFC 1277's allocation and lower-layer encoding.

And RFC 1237's NSAP guidance addresses OSI connectionless network service, not the non-OSI case RFC 1277 was trying to accommodate.

RFC 1277's lasting lesson is narrower than “an address tells you how to connect.” A directory record can carry enough structure for a client to choose a lower-layer interpretation. The client still needs a live route, a compatible listener, a successful transport exchange, and an application response. Treating the encoded value as all four would collapse allocation, interpretation, reachability, and service into one claim the memo never made.

Sources: RFC 1277; RFC 1006; RFC 1278; RFC 1237.