Standards
Agreeing the interface before contact
Two independent systems can only exchange anything once a published, dated document fixes the coupling, the sequence and the rendezvous in advance.
Two systems that share no management, no vendor and no schedule can still exchange something, but only if the interface was written down first. The coupling, the sequence and the rendezvous have to be agreed before anyone is in motion, because at the moment of contact there is no time left to negotiate. The same rule governs a hose and drogue meeting a probe and a stanza meeting a server. Aerial refueling procedures are the clearest published case of that rule, and the journal aerial refueling procedures documents how tanker crews and receiver crews work from a common, dated text rather than from improvisation.
Two hardware families, one job
A tanker can pass fuel in one of two ways, and the difference is mechanical before it is procedural. A flying boom is a rigid, telescoping tube operated by a boom operator aboard the tanker; it is flown into a receptacle on the receiver's upper fuselage, and the receiver holds a steady position while the tanker does the steering. A probe-and-drogue system is the other family: the tanker trails a hose ending in a basket, and the receiver's pilot flies a rigid probe into that basket. The boom moves more fuel per minute and needs a dedicated operator; the hose and drogue is lighter, fits pods on aircraft that were not built as tankers, and puts the closing manoeuvre in the receiver's hands. Both do the same job, and neither is interchangeable with the other without an adapter. That is the first thing that has to be written down: which of the two a given receiver can accept, and which the tanker will offer.
What has to be agreed before two aircraft meet?
Before a rendezvous, the two crews have to settle a list that is longer than it looks. Which system will be used, and at what altitude and speed the transfer will take place. Which side the receiver will approach from, and what the tanker's turning pattern will be. What the fuel offload will be, in what order the receivers will be served, and what happens if one of them cannot take fuel. What radio frequencies and what visual signals will be used, and what the fallback is if radio fails. None of this can be invented in the air. It is agreed on the ground, written into a mission folder, and flown as written. The rendezvous itself is geometry: two aircraft converging on a point at a time, at a speed and an altitude, with a closure rate that both crews have already accepted.
Why does aerial refueling depend on a published procedure?
Because the two aircraft usually belong to different organisations. A tanker from one air force may refuel receivers from another, and neither crew reports to the same commander, trains to the same syllabus or flies the same schedule. What holds them together is a document that is published, numbered and versioned, so that both sides can point to the same paragraph and mean the same thing. NATO's ATP-56 is the standard in that role for air-to-air refuelling, and it exists precisely because verbal agreements between two units do not scale to a coalition. A published procedure also fixes the sequence: who calls what, when the receiver is cleared to close, when the boom or the probe is engaged, what is said if the transfer has to be broken off. The sequence is not a formality. It is what lets two crews who have never met fly a transfer without talking it through from first principles.
The same argument in this guide's world
XMPP works on exactly this principle. Two servers that share no management, no vendor and no release schedule can still exchange stanzas because the interface between them is a published, numbered and versioned document. RFC 6120 defines the core, RFC 6121 the instant messaging and presence layer, and XEPs extend both. A server implementer in one country and a client implementer in another can read the same text, implement to it, and interoperate without ever speaking. The cost of skipping that step is paid at the moment of contact: when a client connects and the two sides disagree about a namespace, a stream feature or a stanza type, there is no time left to negotiate, and the connection simply fails. The published document is what makes the failure avoidable, and it is the same thing a tanker crew carries in its mission folder.
A standard is dated, not remembered
The value of a published procedure is that it can be cited, checked and revised. A verbal agreement between two units is invisible to the next unit, and it dies with the people who made it. A numbered document survives: it can be amended, and the amendment can be dated, so that a crew can tell whether the text in front of it is current. This is why standardisation bodies matter more than any single platform. The aircraft change, the fleets change, the fuel systems change, and the document is what stays constant long enough for two independent operators to keep meeting. The same is true of a protocol. The extension process that produces a versioned specification is not bureaucracy; it is the mechanism that lets two organisations that share nothing else still exchange something, on the day, without a conversation.
What breaks when the interface is assumed
An interface that was never written down does not fail gracefully. It fails at the point of contact, and the failure is usually attributed to the other side. In refuelling, a receiver that arrives expecting a boom and finds a drogue has no way to take fuel, and the mission is lost. In messaging, a client that assumes a feature the server never advertised is disconnected, and the user sees only that it did not work. Both failures have the same shape: two systems that could have interoperated, and a missing document that would have told them how. The remedy is unglamorous and it is the same in both worlds. Write the interface down, number it, date it, publish it, and agree to it before anyone is in the air or on the wire.