| < draft-ietf-822ext-mime-imt-03.txt | draft-ietf-822ext-mime-imt-04.txt > | |||
|---|---|---|---|---|
| Network Working Group Nathaniel Borenstein | Network Working Group Nathaniel Borenstein | |||
| Internet Draft Ned Freed | Internet Draft Ned Freed | |||
| <draft-ietf-822ext-mime-imt-03.txt> | <draft-ietf-822ext-mime-imt-04.txt> | |||
| Multipurpose Internet Mail Extensions | Multipurpose Internet Mail Extensions | |||
| (MIME) Part Two: | (MIME) Part Two: | |||
| Media Types | Media Types | |||
| January 1996 | March 1996 | |||
| Status of this Memo | Status of this Memo | |||
| This document is an Internet-Draft. Internet-Drafts are | This document is an Internet-Draft. Internet-Drafts are | |||
| working documents of the Internet Engineering Task Force | working documents of the Internet Engineering Task Force | |||
| (IETF), its areas, and its working groups. Note that other | (IETF), its areas, and its working groups. Note that other | |||
| groups may also distribute working documents as Internet- | groups may also distribute working documents as Internet- | |||
| Drafts. | Drafts. | |||
| Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six | |||
| skipping to change at page 2, line ? ¶ | skipping to change at page 2, line ? ¶ | |||
| STD 11, RFC 822 defines a message representation protocol | STD 11, RFC 822 defines a message representation protocol | |||
| specifying considerable detail about US-ASCII message headers, | specifying considerable detail about US-ASCII message headers, | |||
| but which leaves the message content, or message body, as flat | but which leaves the message content, or message body, as flat | |||
| US-ASCII text. This set of documents, collectively called the | US-ASCII text. This set of documents, collectively called the | |||
| Multipurpose Internet Mail Extensions, or MIME, redefines the | Multipurpose Internet Mail Extensions, or MIME, redefines the | |||
| format of messages to allow for | format of messages to allow for | |||
| (1) textual message bodies in character sets other than | (1) textual message bodies in character sets other than | |||
| US-ASCII, | US-ASCII, | |||
| (2) non-textual message bodies, | (2) an extensible set of different formats for non-textual | |||
| message bodies, | ||||
| (3) multi-part message bodies, and | (3) multi-part message bodies, and | |||
| (4) textual header information in character sets other than | (4) textual header information in character sets other than | |||
| US-ASCII. | US-ASCII. | |||
| These documents are based on earlier work documented in RFC | These documents are based on earlier work documented in RFC | |||
| 934, STD 11, and RFC 1049, but extends and revises them. | 934, STD 11, and RFC 1049, but extends and revises them. | |||
| Because RFC 822 said so little about message bodies, these | Because RFC 822 said so little about message bodies, these | |||
| documents are largely orthogonal to (rather than a revision | documents are largely orthogonal to (rather than a revision | |||
| of) RFC 822. | of) RFC 822. | |||
| In particular, these documents are designed to provide | ||||
| facilities to include multiple parts in a single message, to | ||||
| represent body and header text in character sets other than | ||||
| US-ASCII, to represent formatted multi-font text messages, to | ||||
| represent non-textual material such as images and audio clips, | ||||
| and generally to facilitate later extensions defining new | ||||
| types of Internet mail for use by cooperating mail agents. | ||||
| The initial document in this set, RFC MIME-IMB, specifies the | The initial document in this set, RFC MIME-IMB, specifies the | |||
| various headers used to describe the structure of MIME | various headers used to describe the structure of MIME | |||
| messages. This second document defines the general structure | messages. This second document defines the general structure | |||
| of the MIME media typing system and defines an initial set of | of the MIME media typing system and defines an initial set of | |||
| media types. The third document, RFC MIME-HEADERS, describes | media types. The third document, RFC MIME-HEADERS, describes | |||
| extensions to RFC 822 to allow non-US-ASCII text data in | extensions to RFC 822 to allow non-US-ASCII text data in | |||
| Internet mail header fields. The fourth document, RFC MIME- | Internet mail header fields. The fourth document, RFC MIME- | |||
| REG, specifies various IANA registration procedures for MIME- | REG, specifies various IANA registration procedures for MIME- | |||
| related facilities. The fifth and final document, RFC MIME- | related facilities. The fifth and final document, RFC MIME- | |||
| CONF, describes MIME conformance criteria as well as providing | CONF, describes MIME conformance criteria as well as providing | |||
| skipping to change at page 3, line 23 ¶ | skipping to change at page 3, line 23 ¶ | |||
| 6.1 Text Media Type ..................................... 7 | 6.1 Text Media Type ..................................... 7 | |||
| 6.1.1 Representation of Line Breaks ..................... 8 | 6.1.1 Representation of Line Breaks ..................... 8 | |||
| 6.1.2 Charset Parameter ................................. 8 | 6.1.2 Charset Parameter ................................. 8 | |||
| 6.1.3 Plain Subtype ..................................... 12 | 6.1.3 Plain Subtype ..................................... 12 | |||
| 6.1.4 Unrecognized Subtypes ............................. 12 | 6.1.4 Unrecognized Subtypes ............................. 12 | |||
| 6.2 Image Media Type .................................... 12 | 6.2 Image Media Type .................................... 12 | |||
| 6.3 Audio Media Type .................................... 13 | 6.3 Audio Media Type .................................... 13 | |||
| 6.4 Video Media Type .................................... 13 | 6.4 Video Media Type .................................... 13 | |||
| 6.5 Application Media Type .............................. 14 | 6.5 Application Media Type .............................. 14 | |||
| 6.5.1 Octet-Stream Subtype .............................. 15 | 6.5.1 Octet-Stream Subtype .............................. 15 | |||
| 6.5.2 PostScript Subtype ................................ 15 | 6.5.2 PostScript Subtype ................................ 16 | |||
| 6.5.3 Other Application Subtypes ........................ 19 | 6.5.3 Other Application Subtypes ........................ 19 | |||
| 7 Composite Media Type Values ........................... 19 | 7 Composite Media Type Values ........................... 19 | |||
| 7.1 Multipart Media Type ................................ 19 | 7.1 Multipart Media Type ................................ 20 | |||
| 7.1.1 Common Syntax ..................................... 21 | 7.1.1 Common Syntax ..................................... 21 | |||
| 7.1.2 Handling Nested Messages and Multiparts ........... 27 | 7.1.2 Handling Nested Messages and Multiparts ........... 28 | |||
| 7.1.3 Mixed Subtype ..................................... 28 | 7.1.3 Mixed Subtype ..................................... 28 | |||
| 7.1.4 Alternative Subtype ............................... 28 | 7.1.4 Alternative Subtype ............................... 28 | |||
| 7.1.5 Digest Subtype .................................... 30 | 7.1.5 Digest Subtype .................................... 31 | |||
| 7.1.6 Parallel Subtype .................................. 32 | 7.1.6 Parallel Subtype .................................. 32 | |||
| 7.1.7 Other Multipart Subtypes .......................... 32 | 7.1.7 Other Multipart Subtypes .......................... 33 | |||
| 7.2 Message Media Type .................................. 32 | 7.2 Message Media Type .................................. 33 | |||
| 7.2.1 RFC822 Subtype .................................... 33 | 7.2.1 RFC822 Subtype .................................... 34 | |||
| 7.2.2 Partial Subtype ................................... 33 | 7.2.2 Partial Subtype ................................... 34 | |||
| 7.2.2.1 Message Fragmentation and Reassembly ............ 35 | 7.2.2.1 Message Fragmentation and Reassembly ............ 36 | |||
| 7.2.2.2 Fragmentation and Reassembly Example ............ 36 | 7.2.2.2 Fragmentation and Reassembly Example ............ 37 | |||
| 7.2.3 External-Body Subtype ............................. 38 | 7.2.3 External-Body Subtype ............................. 39 | |||
| 7.2.4 Other Message Subtypes ............................ 46 | 7.2.4 Other Message Subtypes ............................ 47 | |||
| 8 Experimental Media Type Values ........................ 46 | 8 Experimental Media Type Values ........................ 47 | |||
| 9 Summary ............................................... 47 | 9 Summary ............................................... 48 | |||
| 10 Security Considerations .............................. 47 | 10 Security Considerations .............................. 48 | |||
| 11 Authors' Addresses ................................... 48 | 11 Authors' Addresses ................................... 49 | |||
| A Collected Grammar ..................................... 49 | A Collected Grammar ..................................... 50 | |||
| 3. Introduction | 3. Introduction | |||
| The first document in this set, RFC MIME-IMB, defines a number | The first document in this set, RFC MIME-IMB, defines a number | |||
| of header fields, including Content-Type. The Content-Type | of header fields, including Content-Type. The Content-Type | |||
| field is used to specify the nature of the data in the body of | field is used to specify the nature of the data in the body of | |||
| a MIME entity, by giving media type and subtype identifiers, | a MIME entity, by giving media type and subtype identifiers, | |||
| and by providing auxiliary information that may be required | and by providing auxiliary information that may be required | |||
| for certain media types. After the type and subtype names, | for certain media types. After the type and subtype names, | |||
| the remainder of the header field is simply a set of | the remainder of the header field is simply a set of | |||
| parameters, specified in an attribute/value notation. The | parameters, specified in an attribute/value notation. The | |||
| skipping to change at page 4, line 45 ¶ | skipping to change at page 4, line 45 ¶ | |||
| specific subtype. However, a given top-level media type may | specific subtype. However, a given top-level media type may | |||
| define parameters which are applicable to any subtype of that | define parameters which are applicable to any subtype of that | |||
| type. Parameters may be required by their defining media type | type. Parameters may be required by their defining media type | |||
| or subtype or they may be optional. MIME implementations must | or subtype or they may be optional. MIME implementations must | |||
| also ignore any parameters whose names they do not recognize. | also ignore any parameters whose names they do not recognize. | |||
| MIME's Content-Type header field and media type mechanism has | MIME's Content-Type header field and media type mechanism has | |||
| been carefully designed to be extensible, and it is expected | been carefully designed to be extensible, and it is expected | |||
| that the set of media type/subtype pairs and their associated | that the set of media type/subtype pairs and their associated | |||
| parameters will grow significantly over time. Several other | parameters will grow significantly over time. Several other | |||
| MIME facilities, most notably the list of the name of | MIME facilities, such as transfer encodings and | |||
| character sets registered for MIME usage, are likely to have | message/external-body access types, are likely to have new | |||
| new values defined over time. In order to ensure that the set | values defined over time. In order to ensure that the set of | |||
| of such values is developed in an orderly, well-specified, and | such values is developed in an orderly, well-specified, and | |||
| public manner, MIME sets up a registration process which uses | public manner, MIME sets up a registration process which uses | |||
| the Internet Assigned Numbers Authority (IANA) as a central | the Internet Assigned Numbers Authority (IANA) as a central | |||
| registry for MIME's extension areas. The registration process | registry for MIME's various areas of extensibility. The | |||
| is described in a companion document, RFC MIME-REG. | registration process for these areas is described in a | |||
| companion document, RFC MIME-REG. | ||||
| The initial seven standard top-level media type are defined | The initial seven standard top-level media type are defined | |||
| and described in the remainder of this document. | and described in the remainder of this document. | |||
| 4. Definition of a Top-Level Media Type | 4. Definition of a Top-Level Media Type | |||
| The definition of a top-level media type consists of: | The definition of a top-level media type consists of: | |||
| (1) a name and a description of the type, including | (1) a name and a description of the type, including | |||
| criteria for whether a particular type would qualify | criteria for whether a particular type would qualify | |||
| skipping to change at page 5, line 38 ¶ | skipping to change at page 5, line 39 ¶ | |||
| top-level type, if any, and | top-level type, if any, and | |||
| (5) any restrictions on content-transfer-encodings for | (5) any restrictions on content-transfer-encodings for | |||
| entities of this top-level type. | entities of this top-level type. | |||
| 5. Overview Of The Initial Top-Level Media Types | 5. Overview Of The Initial Top-Level Media Types | |||
| The five discrete top-level media types are: | The five discrete top-level media types are: | |||
| (1) text -- textual information. The subtype "plain" in | (1) text -- textual information. The subtype "plain" in | |||
| particular indicates plain (unformatted) text. No | particular indicates plain text containing no | |||
| special software is required to get the full meaning of | formatting commands or directives of any sort. Plain | |||
| the text, aside from support for the indicated | text is intended to be displayed "as-is". No special | |||
| character set. Other subtypes are to be used for | software is required to get the full meaning of the | |||
| enriched text in forms where application software may | text, aside from support for the indicated character | |||
| enhance the appearance of the text, but such software | set. Other subtypes are to be used for enriched text in | |||
| must not be required in order to get the general idea | forms where application software may enhance the | |||
| of the content. Possible subtypes thus include any | appearance of the text, but such software must not be | |||
| required in order to get the general idea of the | ||||
| content. Possible subtypes of text thus include any | ||||
| word processor format that can be read without | word processor format that can be read without | |||
| resorting to software that understands the format. In | resorting to software that understands the format. In | |||
| particular, formats that employ embeddded binary | particular, formats that employ embeddded binary | |||
| formatting information are not considered directly | formatting information are not considered directly | |||
| readable. A very simple and portable subtype, | readable. A very simple and portable subtype, | |||
| "richtext", was defined in RFC 1341, with a further | "richtext", was defined in RFC 1341, with a further | |||
| revision in RFC 1563 under the name "enriched". | revision in RFC 1563 under the name "enriched". | |||
| (2) image -- image data. Image requires a display device | (2) image -- image data. Image requires a display device | |||
| (such as a graphical display, a graphics printer, or a | (such as a graphical display, a graphics printer, or a | |||
| FAX machine) to view the information. An initial | FAX machine) to view the information. An initial | |||
| subtype is defined for the widely-used image format | subtype is defined for the widely-used image format | |||
| JPEG. | JPEG. | |||
| (3) audio -- audio data. Audio requires an audio output | (3) audio -- audio data. Audio requires an audio output | |||
| skipping to change at page 7, line 40 ¶ | skipping to change at page 7, line 45 ¶ | |||
| Five of the seven initial media type values refer to discrete | Five of the seven initial media type values refer to discrete | |||
| bodies. The content of these types must be handled by non-MIME | bodies. The content of these types must be handled by non-MIME | |||
| mechanisms; they are opaque to MIME processors. | mechanisms; they are opaque to MIME processors. | |||
| 6.1. Text Media Type | 6.1. Text Media Type | |||
| The text media type is intended for sending material which is | The text media type is intended for sending material which is | |||
| principally textual in form. A "charset" parameter may be | principally textual in form. A "charset" parameter may be | |||
| used to indicate the character set of the body text for text | used to indicate the character set of the body text for text | |||
| subtypes, notably including the subtype "text/plain", which | subtypes, notably including the subtype "text/plain", which | |||
| indicates plain (unformatted) text. | indicates plain text that doesn't contain any formatting | |||
| commands or directives. | ||||
| Beyond plain text, there are many formats for representing | Beyond plain text, there are many formats for representing | |||
| what might be known as "extended text" -- text with embedded | what might be known as "extended text" -- text with embedded | |||
| formatting and presentation information. An interesting | formatting and presentation information. An interesting | |||
| characteristic of many such representations is that they are | characteristic of many such representations is that they are | |||
| to some extent readable even without the software that | to some extent readable even without the software that | |||
| interprets them. It is useful, then, to distinguish them, at | interprets them. It is useful, then, to distinguish them, at | |||
| the highest level, from such unreadable data as images, audio, | the highest level, from such unreadable data as images, audio, | |||
| or text represented in an unreadable form. In the absence of | or text represented in an unreadable form. In the absence of | |||
| appropriate interpretation software, it is reasonable to show | appropriate interpretation software, it is reasonable to show | |||
| skipping to change at page 8, line 31 ¶ | skipping to change at page 8, line 37 ¶ | |||
| of line break sequences is also forbidden. | of line break sequences is also forbidden. | |||
| This rule applies regardless of format or character set or | This rule applies regardless of format or character set or | |||
| sets involved. | sets involved. | |||
| NOTE: The proper interpretation of line breaks when a body is | NOTE: The proper interpretation of line breaks when a body is | |||
| displayed depends on the media type. In particular, while it | displayed depends on the media type. In particular, while it | |||
| is appropriate to treat a line break as a transition to a new | is appropriate to treat a line break as a transition to a new | |||
| line when displaying a text/plain body, this treatment is | line when displaying a text/plain body, this treatment is | |||
| actually incorrect for other subtypes of text like | actually incorrect for other subtypes of text like | |||
| text/enriched [RFC-1563]. | text/enriched [RFC-1563]. Similarly, whether or not line | |||
| breaks should be added during display operations is also a | ||||
| function of the media type. It should not be necessary to add | ||||
| any line breaks to display text/plain correctly, whereas | ||||
| proper display of text/enriched requires the appropriate | ||||
| addition of line breaks. | ||||
| 6.1.2. Charset Parameter | 6.1.2. Charset Parameter | |||
| A critical parameter that may be specified in the Content-Type | A critical parameter that may be specified in the Content-Type | |||
| field for text/plain data is the character set. This is | field for text/plain data is the character set. This is | |||
| specified with a "charset" parameter, as in: | specified with a "charset" parameter, as in: | |||
| Content-type: text/plain; charset=iso-8859-1 | Content-type: text/plain; charset=iso-8859-1 | |||
| Unlike some other parameter values, the values of the charset | Unlike some other parameter values, the values of the charset | |||
| skipping to change at page 9, line 24 ¶ | skipping to change at page 9, line 32 ¶ | |||
| This RFC specifies the definition of the charset parameter for | This RFC specifies the definition of the charset parameter for | |||
| the purposes of MIME to be the name of a character set, as | the purposes of MIME to be the name of a character set, as | |||
| "character set" as defined in MIME-IMB. The rules regarding | "character set" as defined in MIME-IMB. The rules regarding | |||
| line breaks detailed in the previous section must also be | line breaks detailed in the previous section must also be | |||
| observed -- a character set whose definition does not conform | observed -- a character set whose definition does not conform | |||
| to these rules cannot be used in a MIME text type. | to these rules cannot be used in a MIME text type. | |||
| An initial list of predefined character set names can be found | An initial list of predefined character set names can be found | |||
| at the end of this section. Additional character sets may be | at the end of this section. Additional character sets may be | |||
| registered with IANA as described in RFC MIME-REG. | registered with IANA. | |||
| Note that if the specified character set includes 8bit data, a | Note that if the specified character set includes 8bit data, a | |||
| Content-Transfer-Encoding header field and a corresponding | Content-Transfer-Encoding header field and a corresponding | |||
| encoding on the data are required in order to transmit the | encoding on the data are required in order to transmit the | |||
| body via some mail transfer protocols, such as SMTP [RFC-821]. | body via some mail transfer protocols, such as SMTP [RFC-821]. | |||
| The default character set, US-ASCII, has been the subject of | The default character set, US-ASCII, has been the subject of | |||
| some confusion and ambiguity in the past. Not only were there | some confusion and ambiguity in the past. Not only were there | |||
| some ambiguities in the definition, there have been wide | some ambiguities in the definition, there have been wide | |||
| variations in practice. In order to eliminate such ambiguity | variations in practice. In order to eliminate such ambiguity | |||
| skipping to change at page 12, line 11 ¶ | skipping to change at page 12, line 19 ¶ | |||
| like all the ISO-8859 family of character sets, is a superset | like all the ISO-8859 family of character sets, is a superset | |||
| of US-ASCII. More generally, if a widely-used character set | of US-ASCII. More generally, if a widely-used character set | |||
| is a subset of another character set, and a body contains only | is a subset of another character set, and a body contains only | |||
| characters in the widely-used subset, it should be labelled as | characters in the widely-used subset, it should be labelled as | |||
| being in that subset. This will increase the chances that the | being in that subset. This will increase the chances that the | |||
| recipient will be able to view the resulting entity correctly. | recipient will be able to view the resulting entity correctly. | |||
| 6.1.3. Plain Subtype | 6.1.3. Plain Subtype | |||
| The simplest and most important subtype of text is "plain". | The simplest and most important subtype of text is "plain". | |||
| This indicates plain (unformatted) text. The default media | This indicates plain text that does not contain any formatting | |||
| type of "text/plain; charset=us-ascii" for Internet mail | commands or directives. Plain text is intended to be displayed | |||
| describes existing Internet practice. That is, it is the type | "as-is", that is, no formatting operations of any sort other | |||
| of body defined by RFC 822. | than support for the indicated character set should be | |||
| necessary for proper display. The default media type of | ||||
| "text/plain; charset=us-ascii" for Internet mail describes | ||||
| existing Internet practice. That is, it is the type of body | ||||
| defined by RFC 822. | ||||
| No other text subtype is defined by this document. | No other text subtype is defined by this document. | |||
| 6.1.4. Unrecognized Subtypes | 6.1.4. Unrecognized Subtypes | |||
| Unrecognized subtypes of text should be treated as subtype | Unrecognized subtypes of text should be treated as subtype | |||
| "plain" as long as the MIME implementation knows how to handle | "plain" as long as the MIME implementation knows how to handle | |||
| the charset. Unrecognized subtypes which also specify an | the charset. Unrecognized subtypes which also specify an | |||
| unrecognized charset should be treated as "application/octet- | unrecognized charset should be treated as "application/octet- | |||
| stream". | stream". | |||
| skipping to change at page 14, line 43 ¶ | skipping to change at page 15, line 12 ¶ | |||
| a remote location and automatically run in the recipient's | a remote location and automatically run in the recipient's | |||
| environment. | environment. | |||
| Such applications may be defined as subtypes of the | Such applications may be defined as subtypes of the | |||
| "application" media type. This document defines two subtypes: | "application" media type. This document defines two subtypes: | |||
| octet-stream, and PostScript. | octet-stream, and PostScript. | |||
| The subtype of application will often be the name of the | The subtype of application will often be the name of the | |||
| application for which the data are intended. This does not | application for which the data are intended. This does not | |||
| mean, however, that any application program name may be used | mean, however, that any application program name may be used | |||
| freely as a subtype of application. Usage of any subtype | freely as a subtype of application. | |||
| (other than subtypes beginning with "x-") must be registered | ||||
| with IANA, as described in RFC MIME-REG. | ||||
| 6.5.1. Octet-Stream Subtype | 6.5.1. Octet-Stream Subtype | |||
| The "octet-stream" subtype is used to indicate that a body | The "octet-stream" subtype is used to indicate that a body | |||
| contains arbitrary binary data. The set of currently defined | contains arbitrary binary data. The set of currently defined | |||
| parameters is: | parameters is: | |||
| (1) TYPE -- the general type or category of binary data. | (1) TYPE -- the general type or category of binary data. | |||
| This is intended as information for the human recipient | This is intended as information for the human recipient | |||
| rather than for any automatic processing. | rather than for any automatic processing. | |||
| skipping to change at page 48, line 35 ¶ | skipping to change at page 49, line 35 ¶ | |||
| Email: ned@innosoft.com | Email: ned@innosoft.com | |||
| Phone: +1 818 919 3600 | Phone: +1 818 919 3600 | |||
| Fax: +1 818 919 3614 | Fax: +1 818 919 3614 | |||
| MIME is a result of the work of the Internet Engineering Task | MIME is a result of the work of the Internet Engineering Task | |||
| Force Working Group on Email Extensions. The chairman of that | Force Working Group on Email Extensions. The chairman of that | |||
| group, Greg Vaudreuil, may be reached at: | group, Greg Vaudreuil, may be reached at: | |||
| Gregory M. Vaudreuil | Gregory M. Vaudreuil | |||
| Tigon Corporation | Octel Network Services | |||
| 17060 Dallas Parkway | 17080 Dallas Parkway | |||
| Dallas Texas, 75248 | Dallas, TX 75248-1905 | |||
| USA | ||||
| Email: greg.vaudreuil@ons.octel.com | Email: Greg.Vaudreuil@Octel.Com | |||
| Phone: +1 214 733 2722 | ||||
| Appendix A -- Collected Grammar | Appendix A -- Collected Grammar | |||
| This appendix contains the complete BNF grammar for all the | This appendix contains the complete BNF grammar for all the | |||
| syntax specified by this document. | syntax specified by this document. | |||
| By itself, however, this grammar is incomplete. It refers by | By itself, however, this grammar is incomplete. It refers by | |||
| name to several syntax rules that are defined by RFC 822. | name to several syntax rules that are defined by RFC 822. | |||
| Rather than reproduce those definitions here, and risk | Rather than reproduce those definitions here, and risk | |||
| unintentional differences between the two, this document | unintentional differences between the two, this document | |||
| simply refers the reader to RFC 822 for the remaining | simply refers the reader to RFC 822 for the remaining | |||
| End of changes. 20 change blocks. | ||||
| 58 lines changed or deleted | 62 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/ | ||||