idnits 2.17.1 draft-ietf-appsawg-mime-default-charset-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC2046, but the abstract doesn't seem to directly say this. It does mention RFC2046 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC2046, updated by this document, for RFC5378 checks: 1995-04-14) -- 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 (April 22, 2012) is 4381 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3023 (Obsoleted by RFC 7303) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Applications Area Working Group A. Melnikov 3 Internet-Draft Isode Limited 4 Updates: 2046 (if approved) J. Reschke 5 Intended status: Standards Track greenbytes 6 Expires: October 24, 2012 April 22, 2012 8 Update to MIME regarding Charset Parameter Handling in 9 Textual Media Types 10 draft-ietf-appsawg-mime-default-charset-03 12 Abstract 14 This document changes RFC 2046 rules regarding default charset 15 parameter values for text/* media types to better align with common 16 usage by existing clients and servers. 18 Editorial Note (To be removed by RFC Editor) 20 Discussion of this draft should take place on the Apps Area Working 21 Group mailing list (apps-discuss@ietf.org), which is archived at 22 . 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 24, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction and Overview . . . . . . . . . . . . . . . 3 59 2. Conventions Used in This Document . . . . . . . . . . . 3 60 3. New rules for default charset parameter values for 61 text/* media types . . . . . . . . . . . . . . . . . . 3 62 4. Default charset parameter value for text/plain 63 media type . . . . . . . . . . . . . . . . . . . . . . 4 64 5. Security Considerations . . . . . . . . . . . . . . . . 4 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . 4 66 7. References . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Normative References . . . . . . . . . . . . . . . . . 5 68 7.2. Informative References . . . . . . . . . . . . . . . . 5 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . 5 72 1. Introduction and Overview 74 [RFC2046] specified that the default charset parameter (i.e. the 75 value used when it is not specified) is "US-ASCII". [RFC2616] 76 changed the default for use by HTTP to be "ISO-8859-1". This 77 encoding is not very common for new text/* media types and a special 78 rule in HTTP adds confusion about which specification ([RFC2046] or 79 [RFC2616]) is authoritative in regards to the default charset for 80 text/* media types. 82 Many complex text subtypes such as text/html [RFC2854] and text/xml 83 [RFC3023] have internal (to their format) means of describing the 84 charset. Many existing User Agents ignore the default of "US-ASCII" 85 rule for at least text/html and text/xml. 87 This document changes RFC 2046 rules regarding default charset 88 parameter values for text/* media types to better align with common 89 usage by existing clients and servers. It does not change the 90 defaults for any currently registered media type. 92 2. Conventions Used in This Document 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 3. New rules for default charset parameter values for text/* media 99 types 101 Section 4.1.2 of [RFC2046] says: 103 The default character set, which must be assumed in the absence of 104 a charset parameter, is US-ASCII. 106 As explained in the Introduction section this rule is considered to 107 be outdated, so this document replaces it with the following set of 108 rules: 110 Each subtype of the "text" media type which uses the "charset" 111 parameter can define its own default value for the "charset" 112 parameter, including the absence of any default. 114 In order to improve interoperability with deployed agents, "text/*" 115 media type registrations SHOULD either 117 a. specify that the "charset" parameter is not used for the defined 118 subtype, because the charset information is transported inside 119 the payload (such as in "text/xml"), or 120 b. require explicit unconditional inclusion of the "charset" 121 parameter eliminating the need for a default value. 123 In accordance with option (a), above, registrations for "text/*" 124 media types that can transport charset information inside the 125 corresponding payloads (such as "text/html" and "text/xml") SHOULD 126 NOT specify the use of a "charset" parameter, nor any default value, 127 in order to avoid conflicting interpretations should the charset 128 parameter value and the value specified in the payload disagree. 130 New subtypes of the "text" media type, thus, SHOULD NOT define a 131 default "charset" value. If there is a strong reason to do so 132 despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as 133 the default. 135 Specifications covering the "charset" parameter, and what default 136 value, if any, is used, are subtype-specific, NOT protocol-specific. 137 Protocols that use MIME, therefore, MUST NOT override default charset 138 values for "text/*" media types to be different for their specific 139 protocol. The protocol definitions MUST leave that to the subtype 140 definitions. 142 4. Default charset parameter value for text/plain media type 144 The default charset parameter value for text/plain is unchanged from 145 [RFC2046] and remains as "US-ASCII". 147 5. Security Considerations 149 Guessing of the charset parameter can lead to security issues such as 150 content buffer overflows, denial of services or bypass of filtering 151 mechanisms. However, this document does not promote guessing, but 152 encourages use of charset information that is specified by the 153 sender. 155 Conflicting information in-band vs out-of-band can also lead to 156 similar security problems, and this document recommends the use of 157 charset information which is more likely to be correct (for example, 158 in-band over out-of-band). 160 6. IANA Considerations 162 This document asks IANA to update the "text" subregistry of the Media 163 Types registry (), 164 to add the following preamble: "See [this RFC] for information about 165 'charset' parameter handling for text media types." 167 IANA is also asked to add this RFC to the list of references at the 168 beginning of the Application for Media Type 169 (). 171 7. References 173 7.1. Normative References 175 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 176 Extensions (MIME) Part Two: Media Types", RFC 2046, 177 November 1996. 179 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 180 Requirement Levels", BCP 14, RFC 2119, March 1997. 182 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 183 10646", STD 63, RFC 3629, November 2003. 185 7.2. Informative References 187 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 188 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 189 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 191 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 192 Type", RFC 2854, June 2000. 194 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 195 Types", RFC 3023, January 2001. 197 Appendix A. Acknowledgements 199 Many thanks to Ned Freed and John Klensin for comments and ideas that 200 motivated creation of this document, and to Carsten Bormann, Murray 201 S. Kucherawy, Barry Leiba, and Henri Sivonen for feedback and text 202 suggestions. 204 Authors' Addresses 206 Alexey Melnikov 207 Isode Limited 208 5 Castle Business Village 209 36 Station Road 210 Hampton, Middlesex TW12 2BX 211 UK 213 Email: Alexey.Melnikov@isode.com 215 Julian F. Reschke 216 greenbytes GmbH 217 Hafenweg 16 218 Muenster, NW 48155 219 Germany 221 Email: julian.reschke@greenbytes.de 222 URI: http://greenbytes.de/tech/webdav/