Summary

  • RFC 2378 treated a directory response as a projection: stored fields, visible fields, searchable fields and default-return fields were not the same set.
  • A single field could carry independent rules for public access, local-only access, owner changes, owner suppression, administrative override, indexing and uniqueness.
  • The operational lesson is durable: “not returned” is evidence about a session and a policy path, not proof that the underlying data does not exist.

Imagine a university phone book in 1998. A student looks up a colleague from a dormitory terminal. An off-campus visitor performs the same query. The person named in the record logs in. A departmental operator checks the entry through delegated authority. A database administrator opens the local console.

They are all looking at one database. They need not see the same directory.

That is the mechanism buried inside RFC 2378, the September 1998 description of the CCSO Nameserver, usually called Ph. At first glance, Ph looks modest: a server on TCP port 105, a compact command language and records made of named fields. Its examples concern names, aliases, telephone numbers, offices and electronic mail. Yet the field descriptor turns this small directory into a serious lesson about evidence.

Every field had more than a name. Its descriptor carried a maximum length, explanatory text and a set of behavioral keywords. Those keywords did not collapse into one access-control flag. They governed different questions.

Public answered who could view a field. Lookup answered whether a client could use it to select records. Indexed made it eligible for efficient lookup, and every query had to include at least one indexed field. Default governed what appeared when the client did not request a return list. Always could force a field into the response. Change allowed the owner to edit it. Unique rejected a change that would duplicate the same field in another entry. NoMeta disabled wildcard matching. Encrypt changed how a value had to travel.

These are independent control surfaces. A field can be visible but not searchable. It can be searchable but absent from the default response. It can be shown to an owner but not changed by that owner. It can be mutable locally while protected from network changes. A client that reduces all of this to visible = true destroys the architecture's meaning.

The asterisk was policy, not punctuation

The sharpest example is Turn. RFC 2378's sample home_phone field is marked Lookup Public Change Turn. Ordinarily it is public, searchable and owner-editable. But the owner can prefix the stored text with an asterisk and turn off visibility for everyone except the owner and privileged operators known as Heros.

Nothing has been deleted. The field still exists. Its descriptor still exists. The owner can still see it. A Hero can still see it. The ordinary response has changed because the same stored value now carries a suppression signal.

That design is historically peculiar, but its epistemic consequence is modern. A negative result is not a database census. It records what one observer was allowed to receive after identity, descriptor policy and content-level suppression were evaluated. Removing the leading character in a client, an export or a migration before policy evaluation would not be harmless cleanup; it would erase the user's visibility decision.

ForcePub shows the opposite direction. A field with that keyword remained viewable and searchable regardless of an entry's general suppress field. Publicness and suppression were not a single hierarchy. The architecture allowed a field-specific rule to override a record-level choice.

Locality changed the schema itself

LocalPub went further. A locally public field could be seen by anyone inside the server's configured local domain or address space. Outside that boundary it was completely invisible. An external client could not request it in a query or a return clause. The fields command would not even reveal its descriptor.

This means two clients could receive different schemas before they asked for any person. The external observer did not merely receive a redacted value. The field ceased to be part of the observable vocabulary.

RFC 2378 also exposed an external session option that made locally public fields invisible. But the document did not establish one global, cryptographically verified definition of “local.” Locality was an operational classification made by the server environment. Its effect was concrete; its authority depended on separate evidence.

That boundary matters because a location test can silently become an entitlement system. Source address, reverse naming, authenticated affiliation and physical presence are different facts. If an implementation treats any one of them as sufficient proof of local status, it has made a policy decision. The protocol response alone does not disclose whether that decision was sound.

The privileged path had its own geography

Ph called its administrative role a Hero. Full Heros could view and change any field in any entry. Yet privilege could also be delegated narrowly—even to one field in one other entry—through an ACL field. The label “administrator” therefore did not describe one uniform power.

Sacred added another boundary. A sacred field could not be changed through a network invocation, but it could be changed through a terminal, file or pipe attached to the server. The rule did not make the value immutable. It relocated the accepted control path.

That distinction is easy to lose in an audit. A network test may prove that an update was refused, while a local maintenance process can still alter the same field. “Cannot be changed” is too broad. The faithful claim is “cannot be changed through this interface under this policy.”

The same discipline applies to authentication. RFC 2378 listed mechanisms ranging from clear-text passwords and a weak email-based method to Kerberos and GSS-API. It explicitly warned that, without mutual authentication, a client could not prove the server's identity. Nor could it prove that a server was authoritative for a set of information. The existence of an authenticated session did not automatically settle server authority, transport confidentiality or field entitlement.

A response is a receipt for one path

The directory's return all option returned all viewable fields. It did not mean all fields in storage. The fields command described only the schema visible to that session. A query needed an indexed field, but indexing did not itself make a field public. Login could expose sensitive owner fields, while Hero scope could expose a different set again.

The correct evidence model is therefore layered:

  1. The database stores a record and its fields.
  2. Field descriptors define search, return, change and visibility behavior.
  3. Record content may activate suppression or override behavior.
  4. The server classifies the connection as local or external.
  5. Authentication links the session to an entry or operator role.
  6. ACL scope determines exceptional authority.
  7. The query and return clause request a subset.
  8. Transport and server authentication determine how much trust the client can place in the response.

The final answer is not the database. It is a receipt produced by that chain.

RFC 2378 did not solve every problem in that chain. It allowed weak authentication, did not negotiate transport encryption, and left “local” to deployment policy. Its value lies elsewhere: it refused to pretend that a field had only one state. More than a quarter-century later, that modest honesty remains a better foundation than an API that returns a blank value and calls the matter settled.