TCP/IP Electronic Mail RFC 822 Standard Message Format Overview, Structure and General Formatting Rules
(Page 2 of 3)
Overview of RFC 822 Messages
Where RFC 822 differs from the field formats of other protocols is in expression. Most TCP/IP protocols encode header information into a compact set of bytes that are read and understood based on their location in the message and the semantic meaning assigned to them. Consider the Internet Protocol, for example. The 9th byte of every IP datagram is the Time To Live (TTL) field, which is encoded as a value from 0 to 255. A device reading an IP datagram simply knows that byte number 9 contains the TTL value. If it sees the binary value 00010011 there, it knows the TTL value for this datagram is the decimal value 19.
In contrast, RFC 822 messages do not use a binary format. They are entirely comprised of lines of regular ASCII text (as used in the United States, called US-ASCII by the standard), even the headers. Each line ends with an ASCII carriage return (CR) character, followed by a line feed (LF) character; the combination is collectively termed CRLF. Each line of text should be 78 characters or less (not including the terminating CRLF) and must not be more than 998 characters (again, excluding the CRLF). Also, the characters CR and LF must not appear by themselves within the text.
The RFC 822 message begins with a set of lines of text that collectively comprise the message header. Each header field is expressed in the following form, in text:
<header name>: <header value>
So, for example, if there were a Time To Live field in RFC 822 messages (there isn't, of course, as that concept has no meaning to e-mail) and a value of 19 needed to be expressed, the header field would appear like this:
Time To Live: 19
This expressing of all fields as simple text means each header takes up more space in each message; the string Time To Live: 19 takes up 18 bytes including the terminating CRLF, where the binary-encoded Time To Live field in the IP header takes only a single byte. What we gain from this are two important benefits. First, any user can easily check the headers and immediately understand what headers are present and what their values are, which makes RFC 822 messages very readable. Second, since each header is explicitly labeled, RFC 822 messages can vary in terms of the number of headers they contain, and even in what order they appear, making them flexible.
Home - Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.