RFC 1501 published a straw poll, not a constituency

Summary

RFC 1501 used the RFC archive to solicit reactions to a proposed national group for individual OS/2 users; it explicitly specified no Internet standard.
The Phoenix Group offered two response addresses, named ten organisers and said it would compile a database of respondents. Those acts made the proposal attributable and measurable, but did not turn respondents into members or organisers into representatives of all users.
Its own conditional sequence preserved the missing receipts: strong response first, an approach to IBM later, then the work of formulating an organisation. The retained sources do not establish that any of those later outcomes occurred.

Two addresses and a large institutional gap

At the bottom of RFC 1501, an interested reader found two destinations. One was an address in IBMMAIL's PROFS-shaped world; the other belonged to Eastern New Mexico University on the Internet. The reader was asked to send a name and address. The organisers promised to compile a database of respondents and keep them informed electronically.

This looks almost trivial now: a sign-up form without the form. In August 1993, however, the two addresses joined electronic communities that did not share one obvious organisational home. The document said The Phoenix Group was polling several electronic fora to discover whether individual OS/2 users wanted a national user group. The mailboxes were therefore not merely contact details. They were the collection points for a proposed constituent record.

Yet the record did not already exist. The people who might write had not necessarily received the RFC. Those who received it might not answer. A response could express curiosity, support, a request for information or willingness to join; the two-page memo did not define the difference. Nor did it specify duplicate handling, eligibility, membership dues, voting, term limits, issue scope or the threshold that would make a response “strong”.

The historical fact is not that these omissions made the proposal illegitimate. It is that RFC 1501 preserved the proposal before the organisation. It lets us watch representation being requested rather than assume it had already been achieved.

The RFC number did not make a standard

RFC 1501 called itself an information memo and said directly that it specified no IAB standard. The current RFC Editor record keeps its Informational classification. The current Datatracker record labels it Legacy and warns that it has no formal standing in the IETF standards process and is not endorsed by the IETF.

That warning matters because the title “Request for Comments” can make every numbered document look like one species of technical rule. It was not. The contemporaneous RFC 1500, an official protocol-status inventory published in the same month, listed RFC 1501 as a new information document that specified no standard level. The later RFC 1599 summary still described it as a memo soliciting reactions to a proposal.

The RFC Series had room for more than standards. RFC 8729, written much later, describes the Series as an archive for general contributions from the Internet research and engineering community as well as standards documents. That later framework should not be projected backward as though its stream machinery governed 1993. It does help a present reader interpret the durable object: publication meant that the solicitation became stable, citable and broadly retrievable. It did not certify the proposal, enroll readers or order IBM to listen.

This distinction gives RFC 1501 its peculiar historical importance. The archive did not only preserve finished mechanisms. It could preserve an attempt to assemble people around a product problem.

What The Phoenix Group actually proposed

Eric Brunsen, writing from Eastern New Mexico University, named The Phoenix Group and ten members of a founding council. They were long-time OS/2 users, the memo said, and believed such an organisation was necessary. The target was deliberately the individual user rather than the corporate information-technology constituency.

The text compared its ambition with SHARE, GUIDE and COMMON in the IBM world and DECIUS in the Digital Equipment world. Those organisations served as focal points and combined voices through which users could influence hardware and software vendors. The Phoenix Group's diagnosis was that the OS/2 end user lacked an equivalent voice with IBM.

That comparison specified a desired function, not an inherited mandate. A list of ten founders answered one question: who was making the proposal? It did not answer another: who had authorized them to speak for all individual OS/2 users? The first question is attribution. The second is representation.

RFC 1501 did not blur the two completely. Its verbs were prospective. The group was “determining the need”. It was taking a straw poll. It wanted to gauge membership potential. If the response was strong, it was prepared to approach IBM Personal Systems Products senior management. It would then work with IBM to formulate an organisation serving both parties' interests.

The grammar carried the governance boundary. Interest came before approach; approach came before formulation. The RFC did not announce a membership roll, a charter, an election, a recognized vendor channel or a product victory.

A database could count interest without creating members

The proposed respondent database was the operational centre of the memo. Without it, “many users want a voice” would remain an impression gathered from scattered forums. With it, organisers could at least count submitted expressions of interest and contact the people who made them.

But a row in that database would have described a response. It would not automatically have constituted membership. A person might ask for updates without authorizing a council to take positions. One name might belong to a corporate employee speaking personally, another to a reseller, developer or hobbyist. A single person might appear through more than one forum. An email address could become unreachable. The RFC did not promise an authenticated, deduplicated or public roll.

This is not a complaint that a 1993 straw poll should have carried modern identity infrastructure. It is a method for reading the evidence at its proper layer. The database, if built, could answer “who responded under the organisers' rules?” It could not by itself answer “who are the OS/2 users?”, “what did each authorize?”, or “which position represents them?”

A useful organisation could have supplied those missing relations later. Membership terms could turn an expression of interest into an explicit act. Operating rules could define who decides, how dissent is recorded, which requests are in scope and when a representative's term ends. A vendor-facing requirements process could preserve the request IBM actually received and its disposition.

The comparison with SHARE makes that machinery visible. SHARE's own institutional history describes a user group with members, programmes and a Requirements system through which members seek to influence IBM products and services. Its 65-year retrospective says that after an initial 1955 meeting the body developed formal membership requirements and operating procedures. Those sources are not evidence that The Phoenix Group followed the same path. They show why the word “voice” conceals work: a durable collective voice is built from rules, records and repeated acts, not granted by analogy.

The Internet connection was distribution, not product authority

The proposal sat at an intersection between Internet publication and a proprietary computing ecosystem. IBM's later history of NSFNET places OS/2 Warp among the company's Internet-related products, with TCP/IP connectivity, email, IBM Global Network access and a browser. That later product context helps explain why OS/2 users and Internet researchers could share an audience. It does not show that RFC 1501 caused those features or that its organisers influenced them.

The distribution channel and the product decision surface remained different. The RFC Editor could publish and preserve the invitation. Electronic fora could spread it. Individuals could reply. Organisers could count. A member body could make a request. IBM could receive, reject, modify or accept it. Engineers could implement a decision. Users could adopt or ignore the result.

Each verb had a different actor. No prestigious document identifier could collapse them.

That layered reading follows a central claim in Heng Lu's Multi-Stakeholder Mirage: participation can provide evidence, expertise, warning and objection without becoming authority over absent parties. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption supplies the corresponding design discipline: keep the shared layer narrow, and leave later choices to the actors who must make and operate them. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile explains why the separation matters. A public symbol may be real and useful without being the operational event it describes.

RFC 1501 is almost a laboratory specimen for those distinctions. The RFC number was real. The named organisers were real. The invitation and addresses were real. The proposed next steps were real as intentions. The packet retained for this Article does not establish response volume, a preserved database, a formed national organisation, authorized membership, IBM recognition, a product requirement, shipped code or user outcome.

Absence from this packet is not proof that nothing happened. It is the boundary of what this Article can claim.

The chain the archive leaves unfinished

Read as an evidence chain, the document begins with a stable publication. It then points toward delivery to a reader, an individual response, a respondent record, a membership act, operating rules, representative authorization, a bounded request to IBM, IBM's receipt and decision, implementation, adoption and independently observed outcome.

RFC 1501 establishes the publication and specifies channels for response. It declares an intention to compile the record. It makes the vendor approach conditional. The later documents in this source packet continue to describe the RFC as a solicitation rather than report the remaining links.

That incompleteness is not a reason to dismiss the memo. The solicitation mattered precisely because a dispersed set of individual users first needed a discoverable way to find one another. Publication lowered the cost of coordination. It created a common reference and two explicit return paths. Those are concrete achievements at the distribution layer.

The discipline is to stop there until another receipt appears. A public invitation can open a room. It cannot fill the seats, approve the rules, elect the speaker or make the vendor act.

The RFC Published a Straw Poll. It Did Not Create a Constituency: RFC 1501

Summary

Two addresses and a large institutional gap

The RFC number did not make a standard

What The Phoenix Group actually proposed

A database could count interest without creating members

The Internet connection was distribution, not product authority

The chain the archive leaves unfinished

Sources

Deeper Profile Context

Strategic Circle

Leadership Alliance

Strategic Circle Briefing

Leadership Alliance Briefing