Summary

  • RFC 1278 defined a human-facing string for a Presentation Address—selectors plus one or more network addresses—but explicitly said the form was not intended for internal storage.
  • A DNS name was allowed for convenient RFC 1006 input. If it produced several IP addresses, the result had to become several network addresses; when an encoded address was shown again, the IP form was required.
  • Recursive macros made long addresses readable, yet the memo said no macro should ever be relied on. Display, expansion dictionary, DNS answer, encoded address set, route preference and connection attempt remained different records.

A display surface, not a second database

RFC 1278 appeared in November 1991 as an Informational memo. Its task sounds modest: define a string encoding for an OSI Presentation Address. The modesty is important because the underlying object was not a single host label.

A presentation address logically contained a presentation selector, a session selector, a transport selector and a set of network addresses. The selectors were octet strings that might have convenient character forms. The network addresses could belong to several addressing families. One Application Entity might therefore be reached through more than one candidate route, with selectors naming the upper-layer rendezvous above them.

The canonical directory representation was ASN.1. RFC 1278’s string was for display to humans, usually system managers. It recommended the form when an address needed to be shown, but said directly that it was not intended for internal storage.

That sentence prevents a common architectural collapse. A display value can be copied, shortened, localised, reordered or rendered with a dictionary that is unavailable tomorrow. A stored representation has to preserve the thing needed for later interpretation. Making both look alike does not make their lifetimes or authority alike.

The memo’s requirements reveal the balancing act. The syntax had to express every legal value, remain clean when there were no selectors, support character, decimal, numeric and hexadecimal selector encodings, accommodate TCP/IP and X.25(80), allow extension and stay reasonably compact. Legibility was not achieved by discarding the inconvenient cases.

One line could contain an address set

The grammar placed optional presentation, session and transport selectors before a network-address list. Multiple network addresses were joined in the string; they were not silently reduced to one preferred path.

That detail matters because multiplicity is evidence. A set says that several candidates belong to the presentation address. It does not say that they are simultaneously reachable, equally preferred or bound to one endpoint at the moment of use.

RFC 1277, the adjacent address-encoding specification, makes the operational sequence explicit. First a system looks up an Application Entity in the OSI Directory and obtains a Presentation Address. Next it extracts each Network Address and determines whether and how it can be used. Then it orders the candidates. Only after those steps does it attempt one or more connections.

RFC 1278 supplied a way to show and enter the compound record. It did not perform the extraction, choose a route or record a successful session. A valid string was upstream evidence, not the outcome of the path it described.

The domain name was an input convenience

The RFC 1006 form could contain either a dotted IP address or a DNS domain name. RFC 1278 explained the asymmetry: the domain name existed mainly to make entry easier.

If that name mapped to several IP addresses, several network addresses should be generated. When software converted the encoded address back into the string form, it should always use the IP address form.

This is a small but exact provenance rule. The typed name is one record: what an operator supplied. The DNS response is another: what resolution returned at a time. The generated address set is a third: what the encoder formed from that observation. A later display of the stored value should not quietly rerun DNS and pretend that today’s answer was the address set accepted yesterday.

The rule also preserves cardinality. One convenient label can yield more than one route candidate. Storing only the label would move the meaning of the old record every time DNS changed. Storing only one arbitrarily selected IP would erase the set that resolution actually produced. RFC 1278’s direction was to expand the convenience into explicit network addresses.

It did not claim that every generated address would work. DNS output was not a connection receipt, and an IP literal was not authenticated endpoint identity. The normalisation only made the input transformation inspectable.

A macro could compress meaning without owning it

Long structured addresses are hostile to human eyes. RFC 1278 therefore allowed a leading token followed by = to stand for a common address prefix. Expansion could be recursive: a short local macro could contain a broader macro, and the combined result could produce the full address. When presenting an address to a human, software was to use the longest available substitution.

The display rule optimised recognition. A familiar short form could make an operational address easier to compare or enter. But compression created a dependency on a separate dictionary. If a macro changed, disappeared or resolved differently on another system, the same visible token could cease to reconstruct the same address.

RFC 1278 did not hide that risk behind the list of suggested standard macros. It stated that no macro should ever be relied on. Suggested names were conveniences at the interface, not a durable registry contract.

This is the article’s central boundary. A macro occurrence, macro definition, recursive expansion and expanded network address are four records. Persisting the first while assuming the other three will remain available converts presentation policy into hidden state. Expanding before durable storage keeps the dependency visible.

The mixed network was the reason for precision

RFC 1277 explains why the string needed this breadth. OSI applications were operating over international and private X.25 networks, isolated OSI networks, CLNP pilots, isolated TCP/IP LANs and the DARPA/NSF Internet through RFC 1006. Depending on a single ubiquitous OSI Network Service was not a practical precondition.

Its interim method encoded enough lower-layer information in a Network Address for software to identify the network and extract the information needed below transport. Directory lookup, interpretation, preference and attempted connection remained separate steps. The format helped heterogeneous systems meet at a common address surface without asserting that the networks underneath had become one.

RFC 1278 then gave operators a single readable grammar over that complexity. Its success condition was faithful representation, not universal reachability. The address could be syntactically legal and still unusable from a particular caller. A candidate could be usable yet less preferred. An attempted connection could still fail. None of those later states rewrote the original display record.

What the sources establish

This article uses RFC 1278 for the human-display purpose, selector and address-list grammar, RFC 1006 DNS input, multi-address expansion, IP output normalisation, recursive macros and explicit non-reliance warning. It uses RFC 1277 only for the adjacent lower-layer context and the sequence from directory lookup through extraction, preference and connection attempt.

Both memos say security considerations are not discussed. They do not establish that a presented address authenticates an endpoint, that a macro is trusted, that a DNS result is stable, that a route is authorised, or that a connection succeeded. They report specifications and some RFC 1277 implementation context, not a census of deployment or a present operating recommendation.

The historical achievement is disciplined translation between surfaces. RFC 1278 made a compound address readable, but required convenience to shed its disguise before it became durable. The macro could help a person. The stored address had to survive the macro.