Summary

  • RFC 1874 separated text/sgml from application/sgml according to whether a human could obtain the general meaning without SGML-aware software. That was a fallback rule, not proof of harmless content.
  • The media type, charset, SGML-bctf transformation and separately referenced SGML-boot part answered different questions. Recognition of one did not prove correct decoding or parsing of the others.
  • The RFC warned that SGML processing could permit system-level commands. Later XML media types showed why a shared syntax family could guide dispatch without making processors, entity roles or security policy interchangeable.

The page had two possible readers

An SGML entity could arrive at a mail client as a sequence of ordinary-looking lines. One reader was a person whose software knew only MIME text. The other was an SGML system prepared to interpret declarations, entities and processing instructions. They received the same octets but did not perform the same act.

RFC 1874, published as Experimental in December 1995, placed entities that remained meaningful to a human under text/sgml. Everything else belonged under application/sgml. For the text form, each SGML record bounded by record-start and record-end characters had to correspond to one line in the MIME body.

That requirement preserved a low-capability path. A client without SGML support could treat the body as text and still expose its general sense. The sender was not promising that every tag would disappear elegantly, every entity reference would resolve, or every application-level meaning would survive. “Readable” described what remained available after specialized interpretation was withheld.

The distinction followed MIME's general architecture. RFC 2046 explained that a top-level type guides an application even when it does not know the subtype. Unknown text can often be shown as raw data; unknown image or audio normally cannot. A text subtype should therefore give the reader a general idea without the specialized program.

This was a controlled compatibility promise. It was not a declaration that processing the richer structure was safe.

One Content-Type carried several independent questions

The two SGML subtypes shared parameters, but the parameters did not collapse into one verdict. For text/sgml, charset helped a non-SGML recipient present a reasonable text fallback. An SGML-capable system was expected to use SGML-bctf, the bit-combination transformation format, for a different purpose: translating SGML's logical character numbers into the transmitted octet stream.

RFC 1874 listed identity and several fixed or variable transformations. A receiver could recognize the subtype and still lack the named transformation. It could decode transport bytes but choose the wrong SGML character mapping. The presence of a parameter recorded the sender's instruction; it did not record the receiver's implementation or result.

The third layer was stranger. SGML-boot did not contain the boot information. It contained the Content-ID of another MIME body part, an application/octet-stream object holding integer triplets that mapped character numbers for the SGML declaration. The boot part was relevant only to document entities.

A reference therefore preceded possession. The surrounding message still had to contain the intended part. The recipient had to find the right Content-ID, retain its bytes, interpret the triplets and use them to read the declaration. A well-formed parameter could coexist with a missing part, a duplicate identifier, an unsupported mapping or a declaration that still failed.

RFC 1590 gave the Internet a public procedure for registering media types. Registration made names and handling requirements discoverable. It did not examine each transmitted object or certify a receiving program. The registry answered what the label was specified to mean, not what happened after a particular label arrived.

A text label did not remove active authority

RFC 1874 put its sharpest boundary in the security section. SGML entities were not merely displayed; they were parsed and processed. Some systems could permit explicit system-level commands. Processing instructions for presentation or composition could carry risks similar to PostScript.

The warning matters because text/sgml can sound like a safety classification. It was not. The top-level type described fallback intelligibility. Once the recipient invoked an SGML processor, different authority became relevant: whether the program could access files, start commands, follow external references or alter a presentation environment.

A user might safely read the uninterpreted lines and unsafely process the structure. Another user might block every active instruction yet correctly parse the document tree. A third might fail before parsing because it could not reconstruct the character mapping. Those outcomes cannot be summarized by the same receipt.

MIME also required implementations to ignore unrecognized parameters. That rule protected extensibility, but it created another branch. Ignoring SGML-boot could be correct behaviour for generic MIME software and insufficient behaviour for an SGML document that depended on the boot map. Compatibility at the envelope did not prove fidelity at the application.

XML demonstrated the limits of family resemblance

Three years later, RFC 2376 registered text/xml and application/xml. XML was an SGML subset, yet the RFC rejected reuse of the SGML labels. Many XML programs could not process SGML's larger feature set. SGML programs could not always process XML because XML used later SGML corrections. The SGML transformation and boot parameters were irrelevant to XML and would introduce ambiguity.

This was running evidence against inheritance by name. “Subset” described a language relationship. It did not prove that installed processors accepted both languages or that parameters from the parent family retained meaning.

RFC 3023 extended the XML work and established the +xml suffix for application-specific formats. The suffix gave generic tools a syntax clue while allowing the complete media type to carry domain meaning. RFC 6838 later formalized registration of structured syntax suffixes, including their encoding, interoperability, fragment and security considerations.

That design localized authority. A suffix can justify trying a generic parser. It cannot authorize every generic transformation or erase the specific media type's rules.

RFC 7303 made the separation explicit. Software could notice +xml, verify the XML assumption by invoking a processor, and then continue according to the specific type. The RFC also allowed designers to omit the suffix when generic XML processing would be inappropriate. Even a syntax signal came with an escape from automatic dispatch.

RFC 7303 also distinguished document entities, external DTD subsets, external parsed entities and external parameter entities. They shared XML syntax but were not freely interchangeable. The label had to preserve the entity's role, not merely its ancestry.

The historical receipt had to stay narrow

The honest record for an RFC 1874 object is a chain. The sender chose a type. A registry defined it. A recipient received the bytes. MIME software parsed the header. A fallback path showed lines, or an SGML path applied a transformation. A boot reference was resolved. The declaration parsed. Active instructions were allowed or blocked. An application produced an output.

Each statement can be true while the next is false. A screenshot proves what one display showed, not which BCTF was applied. A parse tree proves syntax, not safe command policy. A registered type proves publication, not support. A Content-ID proves a reference was written, not that its target accompanied the message.

The lasting contribution of RFC 1874 was not that its two media types became the final answer for structured text. The later XML split shows they did not. Its value lies in the boundary it exposed: human-readable fallback and machine-processing authority occupy different layers, even when they begin with the same document.

Sources and limits

RFCs 1590, 1874 and 2046 establish the registration, SGML parameters, fallback and MIME type rules. RFCs 2376, 3023, 6838 and 7303 establish the later XML separation and structured-suffix model. These sources prove published specifications and stated risks. They do not prove adoption, named product behaviour, successful parsing, a real command execution, an exploit, user harm or present-day deployment.