Summary

  • RFC 1295 was a January 1992 Informational NADF document, not an Internet Standard. For entries in the Public Directory it named seven rights: not to be listed; notice when an entry is created; examination; correction; removal of specific information; compliance with US or Canadian privacy/access law; and timely fulfillment.
  • The document distinguished a public directory from private portions and let a user or agent choose public, private or combined listing. It did not define a deletion protocol, prove any individual outcome, or provide a security mechanism merely by naming rights.

The durable historical question in RFC 1295 — User Bill of Rights for entries and listings in the Public Directory was not whether X.500-style directories could hold attributes. They could. It was whether a cooperative public directory could treat the presence of an attribute as the same thing as permission to expose it. The North American Directory Forum answered with a boundary that still reads cleanly: an entry's subject must have a standing to refuse listing before the directory's visibility becomes a fact about that subject.

That order matters because public discoverability changes the consequences of a record. A telephone number, electronic-mail address or organizational association may be ordinary information in one context and a public index in another. RFC 1295 says that a user or the user's agent may elect to list information in the Public Directory, a private directory, or some combination. The document's example is deliberately modest: a telephone number or mail address might be public while other information is reserved for specific private use. The point is not that one field is intrinsically safe.

The point is that the audience boundary belongs to the choice of listing.

Refusal came before remedy

The first right — not to be listed — is easily flattened into a later deletion request. It is stronger and earlier than that. A deletion request begins after an entry exists. Non-listing asks whether the public record should be created at all. The difference is an operating boundary: one concerns admission to a public namespace, the other concerns a change to an admitted record.

RFC 1295 then adds notice when an entry is created. Notice is not consent, and it is not proof that the person read or understood a message. It changes a silent creation into an event that can be examined. Without it, a subject may encounter a public listing only after another party has found it. With it, the next rights — examination, correction, and removal of specific information — at least have an identifiable object and a plausible time at which to be exercised.

The sequence therefore should not be reported as one generic privacy promise. It is a chain of separate claims. A provider can record an instruction not to list. A provider can create a public entry. A provider can send a notice. A user can inspect the stored attributes. A user can request a correction or the removal of one attribute. A provider can change its authoritative copy. Each statement needs its own timestamp, actor and evidence. One does not silently prove the next.

A public namespace was not the whole directory

RFC 1295 frames the question within a planned cooperative North American directory service using CCITT X.500 standards. It calls the Directory a collection of electronic directories run by service providers and private operators. Information in an entry can be accessed unless security and privacy controls restrict it; a portion intended for public dissemination is the Public Directory, while other portions may not be intended for public access.

The technical vocabulary can make the policy sound inevitable. It was not. A directory hierarchy, a naming rule, a replication relationship or a client lookup says something about how a record may be reached. It does not decide whether a person selected that audience, whether a record is accurate, whether a provider received a request, or whether a request was fulfilled in time.

This distinction became more explicit in RFC 1417 — NADF Standing Documents: A Brief Overview, published in 1993 and obsoleting RFC 1295. Its description of the NADF is not a story of one owner operating one book. It describes competing providers attempting a cooperative Public Directory Service, a public name-space alongside separately managed private name-spaces, and a design in which registration occurs outside the Directory. An entity may opt to list where others are likely to search. That phrase makes choice operational rather than decorative.

RFC 1417 also says that X.500(88) lacked knowledge-maintenance procedures and that competing providers made exclusive management of the public name-space impossible. NADF's described response was cooperative linkage from public to private name-spaces, with little payload in those links. This is not evidence that every implementation behaved that way, nor proof that replication ceased at a chosen boundary. It is evidence that a shared public map needed governance precisely because no single provider could honestly own all of the underlying private records.

Correction, removal and fulfillment named different work

The right to examine an entry establishes a view of the record; it does not by itself change that record. The right to correct inaccurate information concerns a claim about accuracy. The right to remove specific information is narrower again: a subject may seek to withhold one attribute without necessarily erasing every relationship, service or identity surrounding an entry. Treating all three as a single “edit” button would lose the historical precision of the document.

The sixth and seventh rights attach the directory to a provider duty. RFC 1295 says a listing should comply with US or Canadian law regulating privacy or access information, and it says users may expect timely fulfillment of the rights. These sentences do not supply a current legal test, settle another jurisdiction's law, or specify a deadline. They do prevent a directory operator from describing its job as mere storage. A public record has a service relationship around it: requests must be handled, and the provider's policy must face a legal environment.

That is why an access result is weak evidence for a stronger conclusion. Seeing a record publicly does not prove legal compliance. Failing to find one does not prove it was never listed, that no replica exists, or that a removal was fulfilled everywhere. A request ticket does not prove a correction. A provider's updated source record does not prove an old copy vanished from another system. The document supplies the rights vocabulary; it does not collapse the remaining evidence chain.

The memo was a boundary, not an enforcement engine

RFC 1295 is clear about its status: it provides information and does not specify an Internet Standard. It says it is a near-verbatim copy of NADF-265. Its security considerations say that security issues are not discussed. These limits matter as much as the rights list. The memo should not be converted into a claim that a 1992 directory had encrypted every request, authenticated every agent, prevented copying, guaranteed deletion, or imposed a globally binding rule.

Its narrower achievement is still substantial. It made a public-directory entry legible as a governed relationship between a person, an agent, a service provider and a public audience. It asked a system designed for discovery to state the point at which discovery becomes exposure — and to leave that point under contestable human control.

Sources and evidence limits

The sources are RFC 1295 and RFC 1417. Together they support the January 1992 Informational status; NADF's X.500-oriented cooperative-directory context; the seven stated rights; the Public/Private Directory distinction; the later standing-document context; competing providers; public and private name-spaces; and the limits described above. They do not prove a current directory, a particular user's request, a notice receipt, a correction, a deletion, a replication state, legal compliance, access-control outcome or security guarantee.