RFC 2854

The 'text/html' Media Type

πŸ“… published June 2000, from ietf

RFC 2854: The 'text/html' Media Type πŸ¦‹

okay bestie, RFC 2854 is literally the spec that says what "text/html" is πŸ’… It was written by Dan Connolly of the World Wide Web Consortium (W3C) and Larry Masinter of AT&T, and it came out in June 2000. It's Informational, so it's giving "here's the history and the pointers" rather than a Standards Track rule πŸ“š It is also the doc that obsoletes RFCs 2070, 1980, 1942, 1867 and 1866 (so those older HTML docs are officially retired πŸ‘‘). It's filed under the Network Working Group stream 🌸


Status of This Memo πŸ“œ

This memo gives information to the Internet community 🫢 It does not specify an Internet standard of any kind. Distribution of this memo is unlimited ✨

Copyright (C) The Internet Society (2000). All Rights Reserved. πŸ”’

Abstract πŸŽ€

okay so this doc sums up how HTML got developed πŸ“ and it defines the "text/html" MIME type by pointing at the relevant W3C recommendations. It's meant to obsolete the older IETF docs that defined HTML, namely RFC 1866, RFC 1867, RFC 1980, RFC 1942 and RFC 2070, and to remove HTML from the IETF Standards Track 🧚

This document was prepared at the request of the W3C HTML working group. Send comments to www-html@w3.org, which is a public mailing list with its archive at <http://lists.w3.org/Archives/Public/www-html/> πŸ’œ


1. Introduction and background 🌈

HTML has been part of the World Wide Web since 1990, and it was described in a bunch of informal docs before anything official πŸ•ΈοΈ The text/html media type was first officially defined by the IETF HTML working group in 1995, in [HTML20]. Then extensions were proposed in [HTML30], [UPLOAD], [TABLES], [CLIMAPS], and [I18N] ✨

The IETF HTML working group closed in September 1996, and the work of defining HTML moved over to the World Wide Web Consortium (W3C) πŸ³οΈβ€πŸŒˆ Some of the proposed extensions landed in [HTML32], and a bigger chunk landed in [HTML40]. The definition of multipart/form-data from [UPLOAD] got described in [FORMDATA]. And there was also a reformulation of HTML 4.0 in XML 1.0 [XHTML1] 🀯

[HTML32] says, "This specification defines HTML version 3.2. HTML 3.2 aims to capture recommended practice as of early '96 and as such to be used as a replacement for HTML 2.0 (RFC 1866)." Later specs for HTML describe how each version differs from the last πŸ“–

Beyond the standards, there were tons of extra extensions, restrictions, and tweaks to HTML that got popular thanks to NCSA's Mosaic, and then Netscape Navigator and Microsoft Internet Explorer 🌟 They're written up in loads of books and online guides, and honestly it's a whole mood πŸ’€

2. Registration of MIME media type text/html πŸ’–

Here's the official registration info, bestie πŸŽ€

  • MIME media type name: text
  • MIME subtype name: html
  • Required parameters: none
  • Optional parameters:
    • charset: this optional parameter refers to the character encoding used to represent the HTML document as a sequence of bytes. Any registered IANA charset may be used, but UTF-8 is preferred. Even though it's optional, it is strongly recommended that it always be present. See Section 6 below for a discussion of charset default rules πŸ’…

Note that [HTML20] included an optional "level" parameter. In practice that parameter was never used, so it has been removed from this specification πŸ™ˆ [HTML30] also suggested a "version" parameter. In practice that one was never used either, and it has been removed from this specification too πŸ—‘οΈ

  • Encoding considerations: see Section 4 of this document πŸ”
  • Security considerations: see Section 7 of this document πŸ”
  • Interoperability considerations: HTML is designed to be interoperable across the widest possible range of platforms and devices with varying capabilities 🌍 However, there are contexts (platforms with limited display capability, for example) where not all of the capabilities of the full HTML definition are feasible. Ongoing work is aiming to develop both a modularization of HTML and a set of profiling capabilities to identify and negotiate restricted (and extended) capabilities 🧩

Because HTML has had such a long and distributed development, current practice on the Internet includes a wide variety of HTML variants πŸŒ€ Implementors of text/html interpreters must be prepared to be "bug-compatible" with popular browsers, in order to work with the many HTML documents available on the Internet πŸ™ƒ

Typically, you can tell different versions apart by the DOCTYPE declaration inside them, although the DOCTYPE declaration itself is sometimes omitted or incorrect 🫠

  • Published specification: the text/html media type is now defined by W3C Recommendations, and the latest published version is [HTML401]. On top of that, [XHTML1] defines a profile of XHTML use that is compatible with HTML 4.01 and that may also be labeled as text/html ✨
  • Applications which use this media type: the first and most common application of HTML is the World Wide Web πŸ•ΈοΈ Commonly, HTML documents contain URI references [URI] to other documents and media that get retrieved using the HTTP protocol [HTTP]. Plenty of gateway applications provide HTML-based interfaces to other complex underlying services. Lots of other applications now use HTML as a convenient platform-independent multimedia document representation too 🌸
  • Additional information:
    • Magic number: there is no single initial string that is always present for HTML files. However, Section 5 below gives some guidelines for recognizing HTML files πŸ”Ž
    • File extension: the file extensions html or htm are commonly used, but other extensions denoting file formats for preprocessing are also common πŸ“
    • Macintosh File Type code: TEXT 🍎
  • Person & email address to contact for further information: Dan Connolly <connolly@w3.org> and Larry Masinter <lmm@acm.org> πŸ“¬
  • Intended usage: COMMON 🌟
  • Author/Change controller: the HTML specification is a work product of the World Wide Web Consortium's HTML Working Group. The W3C has change control over the HTML specification πŸ‘‘
  • Further information: HTML can include additional resources by reference via URI, like images, video clips, or applets, within the base document πŸ–ΌοΈ To transfer a complete HTML object and its included resources in a single MIME object, the mechanisms of [MHTML] may be used πŸ§ƒ

3. Fragment Identifiers 🧚

okay so the URI specification [URI] says that the meaning of a fragment identifier (the part of a URI after a "#") is a property of the data that comes back from a retrieval action 🎯 It also says the format and interpretation of fragment identifiers depend on the media type of that retrieval result πŸ€“

For documents labeled as text/html, the fragment identifier points at the correspondingly named element. Any element can be named with the "id" attribute, and the A, APPLET, FRAME, IFRAME, IMG and MAP elements can also be named with a "name" attribute πŸ’– This is explained in detail in section 12 of [HTML40] ✨

4. Encoding considerations 🫧

Because HTML itself lets you use character entity references, documents with a wide repertoire of characters can still be represented using the US-ASCII charset and transported without encoding 🌈 However, transporting text/html with a charset other than US-ASCII may require base64 or quoted-printable encoding for 7-bit channels πŸ“‘

As with all MIME text subtypes, the canonical form of "text/html" must always represent a line break as a sequence of a CR byte value (0x0D) followed by an LF (0x0A) byte value. In the same way, any occurrence of such a CRLF sequence in "text/html" must represent a line break. Using CR byte values and LF byte values outside of line break sequences is also forbidden 🚫 This rule applies no matter which character encoding (charset) is involved πŸ”‘

Here's the plot twist, though: the HTTP protocol allows data to be transported in a non-canonical form, including with other end-of-line conventions. See [HTTP] section 3.7.1 for that. This exception is commonly used for HTML 🀫

HTML sent via email is still subject to the MIME restrictions, which are discussed fully in [MHTML] Section 10 πŸ“§

5. Recognizing HTML files πŸ”

Almost all HTML files have the string <html or <HTML near the beginning of the file πŸ’…

Documents conforming to HTML 2.0, HTML 3.2 and HTML 4.0 will start with a DOCTYPE declaration <!DOCTYPE HTML near the beginning, before the <html. These dialects are case insensitive. Files may start with white space, comments (introduced by <!--), or processing instructions (introduced by <?) before the DOCTYPE declaration πŸŽ€

XHTML documents (optionally) start with an XML declaration that begins with <?xml, and they are required to have a DOCTYPE declaration <!DOCTYPE html 🌸

6. Charset default rules πŸ’œ

It is strongly recommended to use an explicit charset parameter 🫢 [MIME] specifies, "The default character set, which must be assumed in the absence of a charset parameter, is US-ASCII." [HTTP] Section 3.7.1 says that "media subtypes of the 'text' type are defined to have a default charset value of 'ISO-8859-1'". Section 19.3 of [HTTP] gives additional guidelines. Using an explicit charset parameter will help avoid confusion πŸ™Œ

Using an explicit charset parameter also matters because the overwhelming majority of deployed browsers are set to use something other than 'ISO-8859-1' as the default. The actual default is either a corporate character encoding or character encodings widely deployed in a certain national or regional community 🌍 For further considerations, please also see Section 5.2 of [HTML40] πŸ’…


(part 1 of 2, Section 7 is up next 🫢)

9. References πŸ“šπŸŽ€

okay so the references section is where the RFC shows its receipts πŸ’… every doc it leans on gets listed here, with all the deets, and i'm keeping every single one exactly as written bestie 🫢

[CLIMAPS] Seidman, J., "A Proposed Extension to HTML: Client-Side Image Maps", RFC 1980, August 1996.

[FORMDATA] Masinter, L., "Returning Values from Forms: multipart/form-data", RFC 2388, August 1998.

[HTML20] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.

[HTML30] Raggett, D., "HyperText Markup Language Specification Version 3.0", September 1995. (Available at <http://www.w3.org/MarkUp/html3/CoverPage>).

[HTML32] Raggett, D., "HTML 3.2 Reference Specification", W3C Recomendation, January 1997. Available at <http://www.w3.org/TR/REC-html32>.

[HTML40] Raggett, D., et al., "HTML 4.0 Specification", W3C Recommendation, December 1997. Available at <http://www.w3.org/TR/1998/REC-html40- 19980424>

[HTML401] Raggett, D., et al., "HTML 4.01 Specification", W3C Recommendation, December 1999. Available at <http://www.w3.org/TR/html401>.

[HTTP] Gettys, J., Fielding, R., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

[I18N] Yergeau, F., Nicol, G. and M. Duerst, "Internationalization of the Hypertext Markup Language", RFC 2070, January 1997.

[MHTML] Palme, J., Hotmann, A. and N. Shelness, "MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2557, March 1999.

[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.

[TABLES] Raggett, D., "HTML Tables", RFC 1942, May 1996.

[UPLOAD] Nebel, E. and L. Masinter, "Form-based File Upload in HTML", RFC 1867, November 1995.

[URI] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

[XHTML1] "XHTML 1.0: The Extensible HyperText Markup Language: A Reformulation of HTML 4 in XML 1.0", W3C Recommendation, January 2000. Available at <http://www.w3.org/TR/xhtml1>.


Copyright (C) The Internet Society (2000). All Rights Reserved. πŸ’œ

okay this part is the legal bit and it's giving very serious energy πŸ™ˆ so here's the deal, copied word for word:

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫢

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

πŸ“¦ where this page comes from