idnits 2.17.1 draft-newman-mime-textpara-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1998) is 9565 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) -- Duplicate reference: RFC2046, mentioned in 'MIME-CONF', was also mentioned in 'MIME-IMT'. ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Newman 3 Internet Draft: The Text/Paragraph Media Type N. Freed 4 Document: draft-newman-mime-textpara-00.txt Innosoft 5 February 1998 7 The Text/Paragraph Media Type 9 Status of this memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six 17 months and may be updated, replaced, or obsoleted by other 18 documents at any time. It is inappropriate to use Internet-Drafts 19 as reference material or to cite them other than as "work in 20 progress." 22 To view the entire list of current Internet-Drafts, please check 23 the "1id-abstracts.txt" listing contained in the Internet-Drafts 24 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 25 (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East 26 Coast), or ftp.isi.edu (US West Coast). 28 Introduction 30 The text/plain media type is defined to represent plain text where 31 the CRLF sequence represents a line break [MIME-IMT]. Many modern 32 computer systems have a different concept of ``plain text'' from 33 the systems where the text/plain media type originated. These 34 modern systems usually use a proportional-spaced font and use CRLF 35 to represent paragraph breaks. Numerous software products have 36 erroneously labelled this media type as text/plain. In order to 37 correct this interoperability problem, the text/paragraph media 38 type is defined. 40 [NOTE: This proposal may be discussed publicly on the ietf- 41 822@imc.org mailing list. The subscription address is ietf-822- 42 request@imc.org.] 44 1. Conventions Used in this Document 45 The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD 46 NOT", and "MAY" in this document are to be interpreted as described 47 in "Key words for use in RFCs to Indicate Requirement Levels" 48 [KEYWORDS]. 50 2. The text/paragraph Media Type 52 MIME media type name: text 54 MIME subtype name: paragraph 56 Required parameters: none 58 Optional parameters: charset 60 Encoding considerations: 62 The text/paragraph media type is likely to include paragraphs 63 longer than 1000 characters (including the terminating CRLF 64 characters). Therefore the quoted-printable content transfer 65 encoding is usually necessary for transport over systems with line 66 length limits such as SMTP [SMTP]. If all paragraphs fit within 67 the line length limits of the underlying transport, then the 7-bit 68 or 8-bit content transfer encoding may be used if appropriate for 69 the specified charset. 71 Security considerations: 73 This media type has the same security considerations as text/plain. 75 Interoperability considerations: 77 An agent which receives text/paragraph and doesn't understand it is 78 REQUIRED to display it as text/plain by MIME [MIME-CONF] -- this 79 could result in paragraphs being displayed as long lines which 80 extend outside the visible display area, but many clients offer the 81 ability to wrap such lines. This is an improvement over the 82 current practice where the text/paragraph media type is mislabelled 83 as text/plain and therefore the user agent has a choice between 84 risking the previous problem or damaging text/plain content by word 85 wrapping it. 87 It is simple to convert text/paragraph to text/plain (by word 88 wrapping near the 72nd character column), but there is no 89 algorithmic method to reliably create a text/paragraph media type 90 from a text/plain media type. There is also no algorithmic way to 91 distinguish text/plain from text/paragraph when they are 92 unlabelled. Heuristics can often produce satifactory results in 93 these cases, but when the heuristics fail, the results can be 94 unpleasant. 96 Published specification: 98 The text/paragraph media follows the definition of the text/plain 99 media type as specified in [MIME-IMT] except that a CRLF represents 100 the end of a paragraph rather than the end of a line. 102 Additional information: 104 Magic Number(s): none 106 File extension(s): 107 No clear distinction is made between text/plain and text/paragraph 108 for file extensions. The ".txt" extension is used for both (this 109 internet draft is text/plain). The ".asc" or ".ascii" extension is 110 traditionally used for text/plain with the US-ASCII character set. 112 Macintosh File Type Code(s): TEXT 113 NOTE: the TEXT file type on MacOS is used for both text/paragraph 114 and text/plain. The system application "SimpleText" generates 115 a text/paragraph file with type TEXT (which also may contain 116 MacOS-specific out-of-band markup in the resource fork). Text 117 editors such as those which come with compilers use text/plain. 119 Intended usage: COMMON 121 3. User-Visible Differences between text/plain and text/paragraph 123 The text/plain media type is not intended to be word wrapped. In 124 fact, word wrapping text/plain can make the text difficult to read, 125 as it results in situations like the following: 127 The text/plain media type is not intended to be word wrapped. 128 In 129 fact, word wrapping text/plain can make the text difficult to 130 read, 131 as it results in situations like the following: 133 The text/plain media type is not intended to be 134 word wrapped. 135 In 136 fact, word wrapping text/plain can make the text difficult 137 to 138 read, 139 as it results in situations like the following: 141 ... 143 The text/paragraph media type, on the other hand, is intended to be 144 word wrapped for display and will not cause this problem. 146 There is an unwritten convention that text/plain is displayed in a 147 fixed-width font, thus permitting the use of ASCII-art to represent 148 graphics and tables. The text/paragraph media type is suitable for 149 display in a proportional width font and for line-wrapping, and 150 thus it is not suitable for ASCII-art (such as is commonly used in 151 message signatures). 153 A common convention in Internet messages with the text/plain media 154 type is to use the ">" character at the beginning of a line to 155 quote text from a previous text/plain message when generating a 156 reply. Agents receiving text/paragraph in a message MAY wish to 157 consider this convention when displaying it. 159 It is important to note that the conversion from text/paragraph to 160 text/plain is algorithmicly a one-way process and thus is not to be 161 done when unnecessary. 163 4. Requirements 165 User agents MUST offer an option to display text/plain without line 166 wrapping and SHOULD display it in a fixed-width font. User agents 167 MAY offer an option to word wrap text/plain to deal with the 168 unfortunately common practice of mislabelling text/paragraph as 169 text/plain. 171 User agents SHOULD word wrap text/paragraph on display and MAY 172 display it in either a proportional or fixed-width font. Because 173 the algorithm for quality word wrapping can vary by language, 174 generating agents SHOULD include a Content-Language header [LANG]. 176 Non-Internet mail systems often use paragraph-based text formats. 177 A gateway from such a system MUST NOT label paragraph-based text as 178 text/plain. Instead, it MAY label such paragraph-based text as 179 text/paragraph (or a suitable markup format) or convert to 180 text/plain by word wrapping near the 72nd column. 182 5. Security Considerations 184 This media type introduces no security considerations beyond those 185 which apply to text/plain. Considerations that apply to both 186 follow. 188 Some text display processors will scan text media types for 189 recognizable sequences such as URLs or even nonstandard embedded 190 commands. Embedded commands can have the same sorts of security 191 issues as PostScript. (The discussion of the 192 "application/PostScript" media type [MIME-IMT] considers these 193 risks in detail.) In general, it may be possible to specify 194 commands that perform unauthorized file operations or, make changes 195 to the display processor's environment that affect subsequent 196 operations. Such nonstandard commands are often added for 197 debugging purposes. However, implementors should never assume that 198 existance of such command can be kept secret and as such should 199 make sure that any nonstandard commands with the potential to cause 200 harm are disabled by default. 202 Plain text (or other subtypes of text displayed as plain text) can 203 contain embedded control characters and escape sequences which also 204 have the potential to change the display processor environment in 205 ways that adversely affect subsequent operations. Possible effects 206 include, but are not limited to, locking the keyboard, changing 207 display parameters so subsequent displayed text is unreadable, or 208 even changing display parameters to deliberately obscure or distort 209 subsequent displayed material so that its meaning is lost or 210 altered. Display processors should either filter such material 211 from displayed text or else make sure to reset all important 212 settings after a given display operation is complete. 214 Some terminal devices have keys whose output when pressed can be 215 changed by sending the display processor a character sequence. If 216 this is possible the display of a text object containing such 217 character sequences could reprogram keys to perform some illicit or 218 dangerous action when the key is subsequently pressed by the user. 219 In some cases not only can keys be programmed, they can be 220 triggered remotely, making it possible for a text display operation 221 to directly perform some unwanted action. As such, the ability to 222 program keys should be blocked either by filtering or by disabling 223 the ability to program keys entirely. 225 6. References 227 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 228 Requirement Levels", RFC 2119, Harvard University, March 1997. 230 [LANG] Alvestrand, H., "Tags for the Identification of Languages", 231 RFC 1766, UNINETT, March 1995. 233 [MIME-IMT] Freed, Borenstein, "Multipurpose Internet Mail 234 Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft, First 235 Virtual, November 1996. 237 [MIME-CONF] Freed, Borenstein, "Multipurpose Internet Mail 238 Extensions (MIME) Part Five: Conformance Criteria and Examples", 239 RFC 2046, Innosoft, First Virtual, November 1996. 241 [SMTP] Postel, "Simple Mail Transfer Protocol", RFC 821, 242 Information Sciences Institute, August 1982. 244 7. Author's Address 246 Chris Newman 247 Innosoft International, Inc. 248 1050 Lakes Drive 249 West Covina, CA 91790 USA 251 Email: chris.newman@innosoft.com 253 Ned Freed 254 Innosoft International, Inc. 255 1050 Lakes Drive 256 West Covina, CA 91790 USA 258 Email: ned.freed@innosoft.com