| < draft-resnick-2822upd-05.txt | draft-resnick-2822upd-06.txt > | |||
|---|---|---|---|---|
| Network Working Group P. Resnick, Ed. | Network Working Group P. Resnick, Ed. | |||
| Internet-Draft Qualcomm Incorporated | Internet-Draft Qualcomm Incorporated | |||
| Obsoletes: 2822 (if approved) January 28, 2008 | Obsoletes: 2822 (if approved) February 7, 2008 | |||
| Updates: 4021 (if approved) | Updates: 4021 (if approved) | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: July 31, 2008 | Expires: August 10, 2008 | |||
| Internet Message Format | Internet Message Format | |||
| draft-resnick-2822upd-05 | draft-resnick-2822upd-06 | |||
| Status of This Memo | Status of This Memo | |||
| By submitting this Internet-Draft, each author represents that any | By submitting this Internet-Draft, each author represents that any | |||
| applicable patent or other IPR claims of which he or she is aware | applicable patent or other IPR claims of which he or she is aware | |||
| have been or will be disclosed, and any of which he or she becomes | have been or will be disclosed, and any of which he or she becomes | |||
| aware will be disclosed, in accordance with Section 6 of BCP 79. | aware will be disclosed, in accordance with Section 6 of BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF), its areas, and its working groups. Note that | Task Force (IETF), its areas, and its working groups. Note that | |||
| skipping to change at page 1, line 36 ¶ | skipping to change at page 1, line 36 ¶ | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at | |||
| http://www.ietf.org/ietf/1id-abstracts.txt. | http://www.ietf.org/ietf/1id-abstracts.txt. | |||
| The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
| http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
| This Internet-Draft will expire on July 31, 2008. | This Internet-Draft will expire on August 10, 2008. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (C) The IETF Trust (2008). | Copyright (C) The IETF Trust (2008). | |||
| Abstract | Abstract | |||
| This document specifies the Internet Message Format (IMF), a syntax | This document specifies the Internet Message Format (IMF), a syntax | |||
| for text messages that are sent between computer users, within the | for text messages that are sent between computer users, within the | |||
| framework of "electronic mail" messages. This specification is a | framework of "electronic mail" messages. This specification is a | |||
| skipping to change at page 2, line 47 ¶ | skipping to change at page 2, line 47 ¶ | |||
| 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16 | 3.4. Address Specification . . . . . . . . . . . . . . . . . . 16 | |||
| 3.4.1. Addr-spec specification . . . . . . . . . . . . . . . 17 | 3.4.1. Addr-spec specification . . . . . . . . . . . . . . . 17 | |||
| 3.5. Overall message syntax . . . . . . . . . . . . . . . . . . 18 | 3.5. Overall message syntax . . . . . . . . . . . . . . . . . . 18 | |||
| 3.6. Field definitions . . . . . . . . . . . . . . . . . . . . 19 | 3.6. Field definitions . . . . . . . . . . . . . . . . . . . . 19 | |||
| 3.6.1. The origination date field . . . . . . . . . . . . . . 22 | 3.6.1. The origination date field . . . . . . . . . . . . . . 22 | |||
| 3.6.2. Originator fields . . . . . . . . . . . . . . . . . . 22 | 3.6.2. Originator fields . . . . . . . . . . . . . . . . . . 22 | |||
| 3.6.3. Destination address fields . . . . . . . . . . . . . . 23 | 3.6.3. Destination address fields . . . . . . . . . . . . . . 23 | |||
| 3.6.4. Identification fields . . . . . . . . . . . . . . . . 24 | 3.6.4. Identification fields . . . . . . . . . . . . . . . . 24 | |||
| 3.6.5. Informational fields . . . . . . . . . . . . . . . . . 27 | 3.6.5. Informational fields . . . . . . . . . . . . . . . . . 27 | |||
| 3.6.6. Resent fields . . . . . . . . . . . . . . . . . . . . 28 | 3.6.6. Resent fields . . . . . . . . . . . . . . . . . . . . 28 | |||
| 3.6.7. Trace fields . . . . . . . . . . . . . . . . . . . . . 30 | 3.6.7. Trace fields . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 3.6.8. Optional fields . . . . . . . . . . . . . . . . . . . 30 | 3.6.8. Optional fields . . . . . . . . . . . . . . . . . . . 30 | |||
| 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 31 | 4. Obsolete Syntax . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 4.1. Miscellaneous obsolete tokens . . . . . . . . . . . . . . 32 | 4.1. Miscellaneous obsolete tokens . . . . . . . . . . . . . . 31 | |||
| 4.2. Obsolete folding white space . . . . . . . . . . . . . . . 33 | 4.2. Obsolete folding white space . . . . . . . . . . . . . . . 32 | |||
| 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33 | 4.3. Obsolete Date and Time . . . . . . . . . . . . . . . . . . 33 | |||
| 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 34 | 4.4. Obsolete Addressing . . . . . . . . . . . . . . . . . . . 34 | |||
| 4.5. Obsolete header fields . . . . . . . . . . . . . . . . . . 35 | 4.5. Obsolete header fields . . . . . . . . . . . . . . . . . . 35 | |||
| 4.5.1. Obsolete origination date field . . . . . . . . . . . 36 | 4.5.1. Obsolete origination date field . . . . . . . . . . . 36 | |||
| 4.5.2. Obsolete originator fields . . . . . . . . . . . . . . 36 | 4.5.2. Obsolete originator fields . . . . . . . . . . . . . . 36 | |||
| 4.5.3. Obsolete destination address fields . . . . . . . . . 37 | 4.5.3. Obsolete destination address fields . . . . . . . . . 37 | |||
| 4.5.4. Obsolete identification fields . . . . . . . . . . . . 37 | 4.5.4. Obsolete identification fields . . . . . . . . . . . . 37 | |||
| 4.5.5. Obsolete informational fields . . . . . . . . . . . . 37 | 4.5.5. Obsolete informational fields . . . . . . . . . . . . 37 | |||
| 4.5.6. Obsolete resent fields . . . . . . . . . . . . . . . . 38 | 4.5.6. Obsolete resent fields . . . . . . . . . . . . . . . . 37 | |||
| 4.5.7. Obsolete trace fields . . . . . . . . . . . . . . . . 38 | 4.5.7. Obsolete trace fields . . . . . . . . . . . . . . . . 38 | |||
| 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38 | 4.5.8. Obsolete optional fields . . . . . . . . . . . . . . . 38 | |||
| 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 38 | |||
| 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 | |||
| Appendix A. Example messages . . . . . . . . . . . . . . . . . 43 | Appendix A. Example messages . . . . . . . . . . . . . . . . . 42 | |||
| Appendix A.1. Addressing examples . . . . . . . . . . . . . . . 43 | Appendix A.1. Addressing examples . . . . . . . . . . . . . . . 43 | |||
| Appendix A.1.1. A message from one person to another with | Appendix A.1.1. A message from one person to another with | |||
| simple addressing . . . . . . . . . . . . . . . . 43 | simple addressing . . . . . . . . . . . . . . . . 43 | |||
| Appendix A.1.2. Different types of mailboxes . . . . . . . . . . . 44 | Appendix A.1.2. Different types of mailboxes . . . . . . . . . . . 44 | |||
| Appendix A.1.3. Group addresses . . . . . . . . . . . . . . . . . 45 | Appendix A.1.3. Group addresses . . . . . . . . . . . . . . . . . 44 | |||
| Appendix A.2. Reply messages . . . . . . . . . . . . . . . . . . 45 | Appendix A.2. Reply messages . . . . . . . . . . . . . . . . . . 44 | |||
| Appendix A.3. Resent messages . . . . . . . . . . . . . . . . . 46 | Appendix A.3. Resent messages . . . . . . . . . . . . . . . . . 45 | |||
| Appendix A.4. Messages with trace fields . . . . . . . . . . . . 48 | Appendix A.4. Messages with trace fields . . . . . . . . . . . . 46 | |||
| Appendix A.5. White space, comments, and other oddities . . . . 49 | Appendix A.5. White space, comments, and other oddities . . . . 47 | |||
| Appendix A.6. Obsoleted forms . . . . . . . . . . . . . . . . . 49 | Appendix A.6. Obsoleted forms . . . . . . . . . . . . . . . . . 47 | |||
| Appendix A.6.1. Obsolete addressing . . . . . . . . . . . . . . . 50 | Appendix A.6.1. Obsolete addressing . . . . . . . . . . . . . . . 48 | |||
| Appendix A.6.2. Obsolete dates . . . . . . . . . . . . . . . . . . 50 | Appendix A.6.2. Obsolete dates . . . . . . . . . . . . . . . . . . 48 | |||
| Appendix A.6.3. Obsolete white space and comments . . . . . . . . 51 | Appendix A.6.3. Obsolete white space and comments . . . . . . . . 48 | |||
| Appendix B. Differences from earlier specifications . . . . . 51 | Appendix B. Differences from earlier specifications . . . . . 49 | |||
| Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 53 | Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . 50 | |||
| 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54 | 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 | |||
| 7.1. Normative References . . . . . . . . . . . . . . . . . . . 54 | 7.1. Normative References . . . . . . . . . . . . . . . . . . . 52 | |||
| 7.2. Informative References . . . . . . . . . . . . . . . . . . 55 | 7.2. Informative References . . . . . . . . . . . . . . . . . . 52 | |||
| 1. Introduction | 1. Introduction | |||
| 1.1. Scope | 1.1. Scope | |||
| This document specifies the Internet Message Format (IMF), a syntax | This document specifies the Internet Message Format (IMF), a syntax | |||
| for text messages that are sent between computer users, within the | for text messages that are sent between computer users, within the | |||
| framework of "electronic mail" messages. This specification is an | framework of "electronic mail" messages. This specification is an | |||
| update to [RFC2822], which itself superseded [RFC0822], updating it | update to [RFC2822], which itself superseded [RFC0822], updating it | |||
| to reflect current practice and incorporating incremental changes | to reflect current practice and incorporating incremental changes | |||
| skipping to change at page 5, line 19 ¶ | skipping to change at page 5, line 19 ¶ | |||
| This document occasionally uses terms that appear in capital letters. | This document occasionally uses terms that appear in capital letters. | |||
| When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD | When the terms "MUST", "SHOULD", "RECOMMENDED", "MUST NOT", "SHOULD | |||
| NOT", and "MAY" appear capitalized, they are being used to indicate | NOT", and "MAY" appear capitalized, they are being used to indicate | |||
| particular requirements of this specification. A discussion of the | particular requirements of this specification. A discussion of the | |||
| meanings of these terms appears in [RFC2119]. | meanings of these terms appears in [RFC2119]. | |||
| 1.2.2. Syntactic notation | 1.2.2. Syntactic notation | |||
| This specification uses the Augmented Backus-Naur Form (ABNF) | This specification uses the Augmented Backus-Naur Form (ABNF) | |||
| [I-D.crocker-rfc4234bis] notation for the formal definitions of the | [RFC5234] notation for the formal definitions of the syntax of | |||
| syntax of messages. Characters will be specified either by a decimal | messages. Characters will be specified either by a decimal value | |||
| value (e.g., the value %d65 for uppercase A and %d97 for lowercase A) | (e.g., the value %d65 for uppercase A and %d97 for lowercase A) or by | |||
| or by a case-insensitive literal value enclosed in quotation marks | a case-insensitive literal value enclosed in quotation marks (e.g., | |||
| (e.g., "A" for either uppercase or lowercase A). | "A" for either uppercase or lowercase A). | |||
| 1.2.3. Structure of this document | 1.2.3. Structure of this document | |||
| This document is divided into several sections. | This document is divided into several sections. | |||
| This section, section 1, is a short introduction to the document. | This section, section 1, is a short introduction to the document. | |||
| Section 2 lays out the general description of a message and its | Section 2 lays out the general description of a message and its | |||
| constituent parts. This is an overview to help the reader understand | constituent parts. This is an overview to help the reader understand | |||
| some of the general principles used in the later portions of this | some of the general principles used in the later portions of this | |||
| skipping to change at page 10, line 11 ¶ | skipping to change at page 10, line 11 ¶ | |||
| The syntax as given in this section defines the legal syntax of | The syntax as given in this section defines the legal syntax of | |||
| Internet messages. Messages that are conformant to this | Internet messages. Messages that are conformant to this | |||
| specification MUST conform to the syntax in this section. If there | specification MUST conform to the syntax in this section. If there | |||
| are options in this section where one option SHOULD be generated, | are options in this section where one option SHOULD be generated, | |||
| that is indicated either in the prose or in a comment next to the | that is indicated either in the prose or in a comment next to the | |||
| syntax. | syntax. | |||
| For the defined expressions, a short description of the syntax and | For the defined expressions, a short description of the syntax and | |||
| use is given, followed by the syntax in ABNF, followed by a semantic | use is given, followed by the syntax in ABNF, followed by a semantic | |||
| analysis. Primitive tokens that are used but otherwise unspecified | analysis. The following primitive tokens that are used but otherwise | |||
| are taken from the "Core Rules" of [I-D.crocker-rfc4234bis], Appendix | unspecified are taken from the "Core Rules" of [RFC5234], Appendix | |||
| B.1. | B.1: CR, LF, CRLF, HTAB, SP, WSP, DQUOTE, DIGIT, ALPHA, and VCHAR. | |||
| In some of the definitions, there will be non-terminals whose names | In some of the definitions, there will be non-terminals whose names | |||
| start with "obs-". These "obs-" elements refer to tokens defined in | start with "obs-". These "obs-" elements refer to tokens defined in | |||
| the obsolete syntax in section 4. In all cases, these productions | the obsolete syntax in section 4. In all cases, these productions | |||
| are to be ignored for the purposes of generating legal Internet | are to be ignored for the purposes of generating legal Internet | |||
| messages and MUST NOT be used as part of such a message. However, | messages and MUST NOT be used as part of such a message. However, | |||
| when interpreting messages, these tokens MUST be honored as part of | when interpreting messages, these tokens MUST be honored as part of | |||
| the legal syntax. In this sense, section 3 defines a grammar for the | the legal syntax. In this sense, section 3 defines a grammar for the | |||
| generation of messages, with "obs-" elements that are to be ignored, | generation of messages, with "obs-" elements that are to be ignored, | |||
| while section 4 adds grammar for the interpretation of messages. | while section 4 adds grammar for the interpretation of messages. | |||
| skipping to change at page 11, line 52 ¶ | skipping to change at page 11, line 52 ¶ | |||
| CFWS = (1*([FWS] comment) [FWS]) / FWS | CFWS = (1*([FWS] comment) [FWS]) / FWS | |||
| Throughout this specification, where FWS (the folding white space | Throughout this specification, where FWS (the folding white space | |||
| token) appears, it indicates a place where folding, as discussed in | token) appears, it indicates a place where folding, as discussed in | |||
| section 2.2.3, may take place. Wherever folding appears in a message | section 2.2.3, may take place. Wherever folding appears in a message | |||
| (that is, a header field body containing a CRLF followed by any WSP), | (that is, a header field body containing a CRLF followed by any WSP), | |||
| unfolding (removal of the CRLF) is performed before any further | unfolding (removal of the CRLF) is performed before any further | |||
| semantic analysis is performed on that header field according to this | semantic analysis is performed on that header field according to this | |||
| specification. That is to say, any CRLF that appears in FWS is | specification. That is to say, any CRLF that appears in FWS is | |||
| semantically "invisible." | semantically "invisible". | |||
| A comment is normally used in a structured field body to provide some | A comment is normally used in a structured field body to provide some | |||
| human readable informational text. Since a comment is allowed to | human readable informational text. Since a comment is allowed to | |||
| contain FWS, folding is permitted within the comment. Also note that | contain FWS, folding is permitted within the comment. Also note that | |||
| since quoted-pair is allowed in a comment, the parentheses and | since quoted-pair is allowed in a comment, the parentheses and | |||
| backslash characters may appear in a comment so long as they appear | backslash characters may appear in a comment so long as they appear | |||
| as a quoted-pair. Semantically, the enclosing parentheses are not | as a quoted-pair. Semantically, the enclosing parentheses are not | |||
| part of the comment; the comment is what is contained between the two | part of the comment; the comment is what is contained between the two | |||
| parentheses. As stated earlier, the "\" in any quoted-pair and the | parentheses. As stated earlier, the "\" in any quoted-pair and the | |||
| CRLF in any FWS that appears within the comment are semantically | CRLF in any FWS that appears within the comment are semantically | |||
| "invisible" and therefore not part of the comment either. | "invisible" and therefore not part of the comment either. | |||
| skipping to change at page 16, line 13 ¶ | skipping to change at page 16, line 13 ¶ | |||
| used to indicate that the time was generated on a system that may be | used to indicate that the time was generated on a system that may be | |||
| in a local time zone other than Universal Time and that the date-time | in a local time zone other than Universal Time and that the date-time | |||
| contains no information about the local time zone. | contains no information about the local time zone. | |||
| A date-time specification MUST be semantically valid. That is, the | A date-time specification MUST be semantically valid. That is, the | |||
| day-of-week (if included) MUST be the day implied by the date, the | day-of-week (if included) MUST be the day implied by the date, the | |||
| numeric day-of-month MUST be between 1 and the number of days allowed | numeric day-of-month MUST be between 1 and the number of days allowed | |||
| for the specified month (in the specified year), the time-of-day MUST | for the specified month (in the specified year), the time-of-day MUST | |||
| be in the range 00:00:00 through 23:59:60 (the number of seconds | be in the range 00:00:00 through 23:59:60 (the number of seconds | |||
| allowing for a leap second; see [RFC1305]), and the last two digits | allowing for a leap second; see [RFC1305]), and the last two digits | |||
| of zone MUST be within the range 00 through 59. | of the zone MUST be within the range 00 through 59. | |||
| 3.4. Address Specification | 3.4. Address Specification | |||
| Addresses occur in several message header fields to indicate senders | Addresses occur in several message header fields to indicate senders | |||
| and recipients of messages. An address may either be an individual | and recipients of messages. An address may either be an individual | |||
| mailbox, or a group of mailboxes. | mailbox, or a group of mailboxes. | |||
| address = mailbox / group | address = mailbox / group | |||
| mailbox = name-addr / addr-spec | mailbox = name-addr / addr-spec | |||
| skipping to change at page 21, line 52 ¶ | skipping to change at page 22, line 5 ¶ | |||
| | | | | replies - see 3.6.4 | | | | | | replies - see 3.6.4 | | |||
| | subject | 0 | 1 | | | | subject | 0 | 1 | | | |||
| | comments | 0 | unlimited | | | | comments | 0 | unlimited | | | |||
| | keywords | 0 | unlimited | | | | keywords | 0 | unlimited | | | |||
| | optional-field | 0 | unlimited | | | | optional-field | 0 | unlimited | | | |||
| +----------------+--------+------------+----------------------------+ | +----------------+--------+------------+----------------------------+ | |||
| The exact interpretation of each field is described in subsequent | The exact interpretation of each field is described in subsequent | |||
| sections. | sections. | |||
| Table 1 | ||||
| 3.6.1. The origination date field | 3.6.1. The origination date field | |||
| The origination date field consists of the field name "Date" followed | The origination date field consists of the field name "Date" followed | |||
| by a date-time specification. | by a date-time specification. | |||
| orig-date = "Date:" date-time CRLF | orig-date = "Date:" date-time CRLF | |||
| The origination date specifies the date and time at which the creator | The origination date specifies the date and time at which the creator | |||
| of the message indicated that the message was complete and ready to | of the message indicated that the message was complete and ready to | |||
| enter the mail delivery system. For instance, this might be the time | enter the mail delivery system. For instance, this might be the time | |||
| skipping to change at page 24, line 50 ¶ | skipping to change at page 24, line 50 ¶ | |||
| Note: Some mail applications have automatic reply commands that | Note: Some mail applications have automatic reply commands that | |||
| include the destination addresses of the original message in the | include the destination addresses of the original message in the | |||
| destination addresses of the reply. How those reply commands | destination addresses of the reply. How those reply commands | |||
| behave is implementation dependent and is beyond the scope of this | behave is implementation dependent and is beyond the scope of this | |||
| document. In particular, whether or not to include the original | document. In particular, whether or not to include the original | |||
| destination addresses when the original message had a "Reply-To:" | destination addresses when the original message had a "Reply-To:" | |||
| field is not addressed here. | field is not addressed here. | |||
| 3.6.4. Identification fields | 3.6.4. Identification fields | |||
| Though listed as optional in the table (Table 1) in section 3.6, | Though listed as optional in the table in section 3.6, every message | |||
| every message SHOULD have a "Message-ID:" field. Furthermore, reply | SHOULD have a "Message-ID:" field. Furthermore, reply messages | |||
| messages SHOULD have "In-Reply-To:" and "References:" fields as | SHOULD have "In-Reply-To:" and "References:" fields as appropriate | |||
| appropriate and as described below. | and as described below. | |||
| The "Message-ID:" field contains a single unique message identifier. | The "Message-ID:" field contains a single unique message identifier. | |||
| The "References:" and "In-Reply-To:" field each contain one or more | The "References:" and "In-Reply-To:" field each contain one or more | |||
| unique message identifiers, optionally separated by CFWS. | unique message identifiers, optionally separated by CFWS. | |||
| The message identifier (msg-id) syntax is a limited version of the | The message identifier (msg-id) syntax is a limited version of the | |||
| addr-spec construct enclosed in the angle bracket characters, "<" and | addr-spec construct enclosed in the angle bracket characters, "<" and | |||
| ">". Unlike addr-spec, this syntax only permits the dot-atom-text | ">". Unlike addr-spec, this syntax only permits the dot-atom-text | |||
| form on the left hand side of the "@" and does not have internal CFWS | form on the left hand side of the "@" and does not have internal CFWS | |||
| anywhere in the message identifier. | anywhere in the message identifier. | |||
| skipping to change at page 30, line 50 ¶ | skipping to change at page 30, line 50 ¶ | |||
| conforms to unstructured. | conforms to unstructured. | |||
| The field names of any optional-field MUST NOT be identical to any | The field names of any optional-field MUST NOT be identical to any | |||
| field name specified elsewhere in this document. | field name specified elsewhere in this document. | |||
| optional-field = field-name ":" unstructured CRLF | optional-field = field-name ":" unstructured CRLF | |||
| field-name = 1*ftext | field-name = 1*ftext | |||
| ftext = %d33-57 / ; Printable US-ASCII | ftext = %d33-57 / ; Printable US-ASCII | |||
| %d59-126 / ; characters not including | %d59-126 ; characters not including | |||
| ; ":". | ; ":". | |||
| For the purposes of this specification, any optional field is | For the purposes of this specification, any optional field is | |||
| uninterpreted. | uninterpreted. | |||
| 4. Obsolete Syntax | 4. Obsolete Syntax | |||
| Earlier versions of this specification allowed for different (usually | Earlier versions of this specification allowed for different (usually | |||
| more liberal) syntax than is allowed in this version. Also, there | more liberal) syntax than is allowed in this version. Also, there | |||
| have been syntactic elements used in messages on the Internet whose | have been syntactic elements used in messages on the Internet whose | |||
| skipping to change at page 32, line 11 ¶ | skipping to change at page 32, line 11 ¶ | |||
| Other differences in syntax and semantics are noted in the following | Other differences in syntax and semantics are noted in the following | |||
| sections. | sections. | |||
| 4.1. Miscellaneous obsolete tokens | 4.1. Miscellaneous obsolete tokens | |||
| These syntactic elements are used elsewhere in the obsolete syntax or | These syntactic elements are used elsewhere in the obsolete syntax or | |||
| in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp, | in the main syntax. Bare CR, bare LF, and NUL are added to obs-qp, | |||
| obs-body and obs-unstruct. US-ASCII control characters are added to | obs-body and obs-unstruct. US-ASCII control characters are added to | |||
| obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character | obs-qp, obs-unstruct, obs-ctext, and obs-qtext. The period character | |||
| is added to obs-phrase. The obs-commas construct is added to provide | is added to obs-phrase. The obs-phrase-list provides for a | |||
| for "empty" elements in a comma-separated list, such as in obs- | (potentially empty) comma-separated list of phrases which may include | |||
| phrase-list and addressing lists in section 4.4. | "null" elements. That is, there could be two or more commas in such | |||
| a list with nothing in between them, or commas at the beginning or | ||||
| end of the list. | ||||
| Note: The "period" (or "full stop") character (".") in obs-phrase | Note: The "period" (or "full stop") character (".") in obs-phrase | |||
| is not a form that was allowed in earlier versions of this or any | is not a form that was allowed in earlier versions of this or any | |||
| other specification. Period (nor any other character from | other specification. Period (nor any other character from | |||
| specials) was not allowed in phrase because it introduced a | specials) was not allowed in phrase because it introduced a | |||
| parsing difficulty distinguishing between phrases and portions of | parsing difficulty distinguishing between phrases and portions of | |||
| an addr-spec (see section 4.4). It appears here because the | an addr-spec (see section 4.4). It appears here because the | |||
| period character is currently used in many messages in the | period character is currently used in many messages in the | |||
| display-name portion of addresses, especially for initials in | display-name portion of addresses, especially for initials in | |||
| names, and therefore must be interpreted properly. | names, and therefore must be interpreted properly. | |||
| skipping to change at page 32, line 45 ¶ | skipping to change at page 32, line 47 ¶ | |||
| obs-utext = %d0 / obs-NO-WS-CTL / VCHAR | obs-utext = %d0 / obs-NO-WS-CTL / VCHAR | |||
| obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR) | obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR) | |||
| obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF) | obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF) | |||
| obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS) | obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS) | |||
| obs-phrase = word *(word / "." / CFWS) | obs-phrase = word *(word / "." / CFWS) | |||
| obs-commas = [CFWS] "," *([CFWS] ",") [CFWS] | obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS]) | |||
| obs-phrase-list = [phrase / CFWS] *(obs-commas phrase) [obs-commas] | ||||
| Bare CR and bare LF appear in messages with two different meanings. | Bare CR and bare LF appear in messages with two different meanings. | |||
| In many cases, bare CR or bare LF are used improperly instead of CRLF | In many cases, bare CR or bare LF are used improperly instead of CRLF | |||
| to indicate line separators. In other cases, bare CR and bare LF are | to indicate line separators. In other cases, bare CR and bare LF are | |||
| used simply as US-ASCII control characters with their traditional | used simply as US-ASCII control characters with their traditional | |||
| ASCII meanings. | ASCII meanings. | |||
| 4.2. Obsolete folding white space | 4.2. Obsolete folding white space | |||
| In the obsolete syntax, any amount of folding white space MAY be | In the obsolete syntax, any amount of folding white space MAY be | |||
| skipping to change at page 35, line 4 ¶ | skipping to change at page 35, line 4 ¶ | |||
| There are four primary differences in addressing. First, mailbox | There are four primary differences in addressing. First, mailbox | |||
| addresses were allowed to have a route portion before the addr-spec | addresses were allowed to have a route portion before the addr-spec | |||
| when enclosed in "<" and ">". The route is simply a comma-separated | when enclosed in "<" and ">". The route is simply a comma-separated | |||
| list of domain names, each preceded by "@", and the list terminated | list of domain names, each preceded by "@", and the list terminated | |||
| by a colon. Second, CFWS were allowed between the period-separated | by a colon. Second, CFWS were allowed between the period-separated | |||
| elements of local-part and domain (i.e., dot-atom was not used). In | elements of local-part and domain (i.e., dot-atom was not used). In | |||
| addition, local-part is allowed to contain quoted-string in addition | addition, local-part is allowed to contain quoted-string in addition | |||
| to just atom. Third, mailbox-list and address-list were allowed to | to just atom. Third, mailbox-list and address-list were allowed to | |||
| have "null" members. That is, there could be two or more commas in | have "null" members. That is, there could be two or more commas in | |||
| such a list with nothing in between them. Finally, US-ASCII control | such a list with nothing in between them, or commas at the beginning | |||
| characters and quoted-pairs were allowed in domain literals and are | or end of the list. Finally, US-ASCII control characters and quoted- | |||
| added here. | pairs were allowed in domain literals and are added here. | |||
| obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS] | obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS] | |||
| obs-route = obs-domain-list ":" | obs-route = obs-domain-list ":" | |||
| obs-domain-list = [obs-commas] | obs-domain-list = *(CFWS / ",") "@" domain | |||
| [CFWS] "@" domain *(obs-commas "@" domain) | *("," [CFWS] ["@" domain]) | |||
| [obs-commas] | ||||
| obs-mbox-list = [obs-commas] | obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS]) | |||
| mailbox *(obs-commas mailbox) | ||||
| [obs-commas] | ||||
| obs-addr-list = [obs-commas] | obs-addr-list = *([CFWS] ",") address *("," [address / CFWS]) | |||
| address *(obs-commas address) | ||||
| [obs-commas] | ||||
| obs-group-list = obs-commas | obs-group-list = 1*([CFWS] ",") [CFWS] | |||
| obs-local-part = word *("." word) | obs-local-part = word *("." word) | |||
| obs-domain = atom *("." atom) | obs-domain = atom *("." atom) | |||
| obs-dtext = obs-NO-WS-CTL / quoted-pair | obs-dtext = obs-NO-WS-CTL / quoted-pair | |||
| When interpreting addresses, the route portion SHOULD be ignored. | When interpreting addresses, the route portion SHOULD be ignored. | |||
| 4.5. Obsolete header fields | 4.5. Obsolete header fields | |||
| skipping to change at page 37, line 12 ¶ | skipping to change at page 37, line 12 ¶ | |||
| obs-reply-to = "Reply-To" *WSP ":" address-list CRLF | obs-reply-to = "Reply-To" *WSP ":" address-list CRLF | |||
| 4.5.3. Obsolete destination address fields | 4.5.3. Obsolete destination address fields | |||
| obs-to = "To" *WSP ":" address-list CRLF | obs-to = "To" *WSP ":" address-list CRLF | |||
| obs-cc = "Cc" *WSP ":" address-list CRLF | obs-cc = "Cc" *WSP ":" address-list CRLF | |||
| obs-bcc = "Bcc" *WSP ":" | obs-bcc = "Bcc" *WSP ":" | |||
| [address-list / CFWS / obs-commas] CRLF | address-list / (*([CFWS] ",") [CFWS]) CRLF | |||
| When multiple occurrences of destination address fields occur in a | When multiple occurrences of destination address fields occur in a | |||
| message, they SHOULD be treated as if the address-list in the first | message, they SHOULD be treated as if the address-list in the first | |||
| occurrence of the field is combined with the address lists of the | occurrence of the field is combined with the address lists of the | |||
| subsequent occurrences by adding a comma and concatenating. | subsequent occurrences by adding a comma and concatenating. | |||
| 4.5.4. Obsolete identification fields | 4.5.4. Obsolete identification fields | |||
| The obsolete "In-Reply-To:" and "References:" fields differ from the | The obsolete "In-Reply-To:" and "References:" fields differ from the | |||
| current syntax in that they allow phrase (words or quoted strings) to | current syntax in that they allow phrase (words or quoted strings) to | |||
| skipping to change at page 38, line 22 ¶ | skipping to change at page 38, line 22 ¶ | |||
| obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF | obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF | |||
| obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF | obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF | |||
| obs-resent-to = "Resent-To" *WSP ":" address-list CRLF | obs-resent-to = "Resent-To" *WSP ":" address-list CRLF | |||
| obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF | obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF | |||
| obs-resent-bcc = "Resent-Bcc" *WSP ":" | obs-resent-bcc = "Resent-Bcc" *WSP ":" | |||
| [address-list / CFWS / obs-commas] CRLF | address-list / (*([CFWS] ",") [CFWS]) CRLF | |||
| obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF | obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF | |||
| obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF | obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF | |||
| As with other resent fields, the "Resent-Reply-To:" field is to be | As with other resent fields, the "Resent-Reply-To:" field is to be | |||
| treated as trace information only. | treated as trace information only. | |||
| 4.5.7. Obsolete trace fields | 4.5.7. Obsolete trace fields | |||
| skipping to change at page 43, line 21 ¶ | skipping to change at page 43, line 21 ¶ | |||
| Appendix A. Example messages | Appendix A. Example messages | |||
| This section presents a selection of messages. These are intended to | This section presents a selection of messages. These are intended to | |||
| assist in the implementation of this specification, but should not be | assist in the implementation of this specification, but should not be | |||
| taken as normative; that is to say, although the examples in this | taken as normative; that is to say, although the examples in this | |||
| section were carefully reviewed, if there happens to be a conflict | section were carefully reviewed, if there happens to be a conflict | |||
| between these examples and the syntax described in sections 3 and 4 | between these examples and the syntax described in sections 3 and 4 | |||
| of this document, the syntax in those sections is to be taken as | of this document, the syntax in those sections is to be taken as | |||
| correct. | correct. | |||
| Messages are delimited in this section between lines of "----" in the | In the text version of this document, messages in this section are | |||
| text version of this document. The "----" lines are not part of the | delimited between lines of "----". The "----" lines are not part of | |||
| message itself. | the message itself. | |||
| Appendix A.1. Addressing examples | Appendix A.1. Addressing examples | |||
| The following are examples of messages that might be sent between two | The following are examples of messages that might be sent between two | |||
| individuals. | individuals. | |||
| Appendix A.1.1. A message from one person to another with simple | Appendix A.1.1. A message from one person to another with simple | |||
| addressing | addressing | |||
| This could be called a canonical message. It has a single author, | This could be called a canonical message. It has a single author, | |||
| skipping to change at page 51, line 43 ¶ | skipping to change at page 50, line 43 ¶ | |||
| This appendix contains a list of changes that have been made in the | This appendix contains a list of changes that have been made in the | |||
| Internet Message Format from earlier specifications, specifically | Internet Message Format from earlier specifications, specifically | |||
| [RFC0822], [RFC1123], and [RFC2822]. Items marked with an asterisk | [RFC0822], [RFC1123], and [RFC2822]. Items marked with an asterisk | |||
| (*) below are items which appear in section 4 of this document and | (*) below are items which appear in section 4 of this document and | |||
| therefore can no longer be generated. | therefore can no longer be generated. | |||
| The following are the changes made from [RFC0822] and [RFC1123] to | The following are the changes made from [RFC0822] and [RFC1123] to | |||
| [RFC2822] that remain in this document: | [RFC2822] that remain in this document: | |||
| 1. Period allowed in obsolete form of phrase. | 1. Period allowed in obsolete form of phrase. | |||
| 2. ABNF moved out of document, now in [I-D.crocker-rfc4234bis]. | 2. ABNF moved out of document, now in [RFC5234]. | |||
| 3. Four or more digits allowed for year. | 3. Four or more digits allowed for year. | |||
| 4. Header field ordering (and lack thereof) made explicit. | 4. Header field ordering (and lack thereof) made explicit. | |||
| 5. Encrypted header field removed. | 5. Encrypted header field removed. | |||
| 6. Specifically allow and give meaning to "-0000" time zone. | 6. Specifically allow and give meaning to "-0000" time zone. | |||
| 7. Folding white space is not allowed between every token. | 7. Folding white space is not allowed between every token. | |||
| 8. Requirement for destinations removed. | 8. Requirement for destinations removed. | |||
| 9. Forwarding and resending redefined. | 9. Forwarding and resending redefined. | |||
| 10. Extension header fields no longer specifically called out. | 10. Extension header fields no longer specifically called out. | |||
| 11. ASCII 0 (null) removed.* | 11. ASCII 0 (null) removed.* | |||
| skipping to change at page 52, line 31 ¶ | skipping to change at page 51, line 31 ¶ | |||
| 26. No multiple occurrences of fields (except resent and received).* | 26. No multiple occurrences of fields (except resent and received).* | |||
| 27. Free CR and LF not allowed.* | 27. Free CR and LF not allowed.* | |||
| 28. Line length limits specified. | 28. Line length limits specified. | |||
| 29. Bcc more clearly specified. | 29. Bcc more clearly specified. | |||
| The following are changes from [RFC2822]. | The following are changes from [RFC2822]. | |||
| 1. Assorted typographical/grammatical errors fixed and | 1. Assorted typographical/grammatical errors fixed and | |||
| clarifications made. | clarifications made. | |||
| 2. Changed "standard" to "document" or "specification" throughout. | 2. Changed "standard" to "document" or "specification" throughout. | |||
| 3. Made distinction between "header field" and "header section". | 3. Made distinction between "header field" and "header section". | |||
| 4. Removed NO-WS-CTL from ctext, qtext, domain literals, and | 4. Removed NO-WS-CTL from ctext, qtext, dtext, and unstructured.* | |||
| unstructured.* | ||||
| 5. Moved discussion of specials to the "Atom" section. Moved text | 5. Moved discussion of specials to the "Atom" section. Moved text | |||
| to "Overall message syntax" section. | to "Overall message syntax" section. | |||
| 6. Simplified CFWS syntax. | 6. Simplified CFWS syntax. | |||
| 7. Fixed unstructured syntax. | 7. Fixed unstructured syntax. | |||
| 8. Changed date and time syntax to deal with white space in | 8. Changed date and time syntax to deal with white space in | |||
| obsolete date syntax. | obsolete date syntax. | |||
| 9. Added group-list. | 9. Removed quoted-pair from domain literals.* | |||
| 10. Removed quoted-pair from domain literals.* | 10. Clarified that other specifications limit domain syntax. | |||
| 11. Clarified that other specifications limit domain syntax. | 11. Simplified "Bcc:" and "Resent-Bcc:" syntax. | |||
| 12. Simplified "Bcc:" and "Resent-Bcc:" syntax. | 12. Allowed optional-field to appear within trace information. | |||
| 13. Allowed optional-field to appear within trace information. | 13. Removed no-fold-quote from msg-id. Clarified syntax | |||
| 14. Removed no-fold-quote from msg-id. Clarified syntax | ||||
| limitations. | limitations. | |||
| 15. Generalized "Received:" syntax to fix bugs and move definition | 14. Generalized "Received:" syntax to fix bugs and move definition | |||
| out of this document. | out of this document. | |||
| 16. Simplified obs-qp. Fixed and simplified obs-utext (which now | 15. Simplified obs-qp. Fixed and simplified obs-utext (which now | |||
| only appears in the obsolete syntax). Removed obs-text and obs- | only appears in the obsolete syntax). Removed obs-text and obs- | |||
| char, adding obs-body. | char, adding obs-body. | |||
| 16. Fixed obsolete date syntax to allow for more (or less) comments | ||||
| 17. Fixed obsolete date syntax to allow for more (or less) comments | ||||
| and white space. | and white space. | |||
| 18. Fixed all obsolete list syntax (obs-phrase-list, obs-domain- | ||||
| list, obs-mbox-list, obs-addr-list, and adding obs-group-list). | 17. Fixed all obsolete list syntax (obs-domain-list, obs-mbox-list, | |||
| 19. Fixed obs-reply-to syntax. | obs-addr-list, obs-phrase-list, and the newly added obs-group- | |||
| 20. Fixed obs-bcc and obs-resent-bcc to allow empty lists. | list). | |||
| 21. Removed obs-path. | 18. Fixed obs-reply-to syntax. | |||
| 19. Fixed obs-bcc and obs-resent-bcc to allow empty lists. | ||||
| 20. Removed obs-path. | ||||
| Appendix C. Acknowledgements | Appendix C. Acknowledgements | |||
| Many people contributed to this document. They included folks who | Many people contributed to this document. They included folks who | |||
| participated in the Detailed Revision and Update of Messaging | participated in the Detailed Revision and Update of Messaging | |||
| Standards (DRUMS) Working Group of the Internet Engineering Task | Standards (DRUMS) Working Group of the Internet Engineering Task | |||
| Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and | Force (IETF), the chair of DRUMS, the Area Directors of the IETF, and | |||
| people who simply sent their comments in via e-mail. The editor is | people who simply sent their comments in via e-mail. The editor is | |||
| deeply indebted to them all and thanks them sincerely. The below | deeply indebted to them all and thanks them sincerely. The below | |||
| list includes everyone who sent e-mail concerning both this document | list includes everyone who sent e-mail concerning both this document | |||
| skipping to change at page 55, line 5 ¶ | skipping to change at page 54, line 5 ¶ | |||
| RFC 1035, November 1987. | RFC 1035, November 1987. | |||
| [RFC1123] Braden, R., "Requirements for Internet | [RFC1123] Braden, R., "Requirements for Internet | |||
| Hosts - Application and Support", STD 3, | Hosts - Application and Support", STD 3, | |||
| RFC 1123, October 1989. | RFC 1123, October 1989. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to | [RFC2119] Bradner, S., "Key words for use in RFCs to | |||
| Indicate Requirement Levels", BCP 14, | Indicate Requirement Levels", BCP 14, | |||
| RFC 2119, March 1997. | RFC 2119, March 1997. | |||
| [I-D.crocker-rfc4234bis] Crocker, D. and P. Overell, "Augmented BNF | [RFC5234] Crocker, D. and P. Overell, "Augmented BNF | |||
| for Syntax Specifications: ABNF", | for Syntax Specifications: ABNF", STD 68, | |||
| draft-crocker-rfc4234bis-01 (work in | RFC 5234, January 2008. | |||
| progress), October 2007. | ||||
| 7.2. Informative References | 7.2. Informative References | |||
| [RFC0822] Crocker, D., "Standard for the format of | [RFC0822] Crocker, D., "Standard for the format of | |||
| ARPA Internet text messages", STD 11, | ARPA Internet text messages", STD 11, | |||
| RFC 822, August 1982. | RFC 822, August 1982. | |||
| [RFC1305] Mills, D., "Network Time Protocol (Version | [RFC1305] Mills, D., "Network Time Protocol (Version | |||
| 3) Specification, Implementation", | 3) Specification, Implementation", | |||
| RFC 1305, March 1992. | RFC 1305, March 1992. | |||
| skipping to change at page 57, line 49 ¶ | skipping to change at page 56, line 49 ¶ | |||
| The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
| copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
| rights that may cover technology that may be required to implement | rights that may cover technology that may be required to implement | |||
| this standard. Please address the information to the IETF at | this standard. Please address the information to the IETF at | |||
| ietf-ipr@ietf.org. | ietf-ipr@ietf.org. | |||
| Acknowledgements | Acknowledgements | |||
| Funding for the RFC Editor function is provided by the IETF | Funding for the RFC Editor function is provided by the IETF | |||
| Administrative Support Activity (IASA). This document was produced | Administrative Support Activity (IASA). This document was produced | |||
| using xml2rfc v1.33pre3+wcf (of http://xml.resource.org/) from a | using xml2rfc v1.33pre5 (of http://xml.resource.org/) from a source | |||
| source in RFC-2629 XML format. | in RFC-2629 XML format. | |||
| End of changes. 35 change blocks. | ||||
| 87 lines changed or deleted | 79 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||