idnits 2.17.1 draft-ietf-appsawg-mime-default-charset-04.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 (May 9, 2012) is 4368 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: November 10, 2012 May 9, 2012 8 Update to MIME regarding Charset Parameter Handling in 9 Textual Media Types 10 draft-ietf-appsawg-mime-default-charset-04 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 November 10, 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 . . . . . . . . . . . . . . . . . . 5 66 7. References . . . . . . . . . . . . . . . . . . . . . . 5 67 7.1. Normative References . . . . . . . . . . . . . . . . . 5 68 7.2. Informative References . . . . . . . . . . . . . . . . 5 69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 70 Authors' Addresses . . . . . . . . . . . . . . . . . . 6 72 1. Introduction and Overview 74 RFC 2046 specified that the default charset parameter (i.e. the value 75 used when the parameter is not specified) is "US-ASCII" (Section 76 4.1.2 of [RFC2046]). RFC 2616 changed the default for use by HTTP 77 (Hypertext Transfer Protocol) to be "ISO-8859-1" (Section 3.7.1 of 78 [RFC2616]). This encoding is not very common for new text/* media 79 types and a special rule in the HTTP specification adds confusion 80 about which specification ([RFC2046] or [RFC2616]) is authoritative 81 in regards to the default charset for text/* media types. 83 Many complex text subtypes such as text/html [RFC2854] and text/xml 84 [RFC3023] have internal (to their format) means of describing the 85 charset. Many existing User Agents ignore the default of "US-ASCII" 86 rule for at least text/html and text/xml. 88 This document changes RFC 2046 rules regarding default charset 89 parameter values for text/* media types to better align with common 90 usage by existing clients and servers. It does not change the 91 defaults for any currently registered media type. 93 2. Conventions Used in This Document 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. New rules for default charset parameter values for text/* media 100 types 102 Section 4.1.2 of [RFC2046] says: 104 The default character set, which must be assumed in the absence of 105 a charset parameter, is US-ASCII. 107 As explained in the Introduction section this rule is considered to 108 be outdated, so this document replaces it with the following set of 109 rules: 111 Each subtype of the "text" media type which uses the "charset" 112 parameter can define its own default value for the "charset" 113 parameter, including the absence of any default. 115 In order to improve interoperability with deployed agents, "text/*" 116 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 Regardless of what approach is chosen, all new text/* registrations 136 MUST clearly specify how the charset is determined; relying on the 137 default defined in Section 4.1.2 of [RFC2046] is no longer permitted. 138 However, existing text/* registrations that fail to specify how the 139 charset is determined still default to US-ASCII. 141 Specifications covering the "charset" parameter, and what default 142 value, if any, is used, are subtype-specific, NOT protocol-specific. 143 Protocols that use MIME, therefore, MUST NOT override default charset 144 values for "text/*" media types to be different for their specific 145 protocol. The protocol definitions MUST leave that to the subtype 146 definitions. 148 4. Default charset parameter value for text/plain media type 150 The default charset parameter value for text/plain is unchanged from 151 [RFC2046] and remains as "US-ASCII". 153 5. Security Considerations 155 Guessing of the charset parameter can lead to security issues such as 156 content buffer overflows, denial of services or bypass of filtering 157 mechanisms. However, this document does not promote guessing, but 158 encourages use of charset information that is specified by the 159 sender. 161 Conflicting information in-band vs out-of-band can also lead to 162 similar security problems, and this document recommends the use of 163 charset information which is more likely to be correct (for example, 164 in-band over out-of-band). 166 6. IANA Considerations 168 This document asks IANA to update the "text" subregistry of the Media 169 Types registry (), 170 to add the following preamble: "See [this RFC] for information about 171 'charset' parameter handling for text media types." 173 IANA is also asked to add this RFC to the list of references at the 174 beginning of the Application for Media Type 175 (). 177 7. References 179 7.1. Normative References 181 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 182 Extensions (MIME) Part Two: Media Types", RFC 2046, 183 November 1996. 185 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 186 Requirement Levels", BCP 14, RFC 2119, March 1997. 188 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 189 10646", STD 63, RFC 3629, November 2003. 191 7.2. Informative References 193 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 194 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 195 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 197 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 198 Type", RFC 2854, June 2000. 200 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 201 Types", RFC 3023, January 2001. 203 Appendix A. Acknowledgements 205 Many thanks to Ned Freed and John Klensin for comments and ideas that 206 motivated creation of this document, and to Carsten Bormann, Murray 207 S. Kucherawy, Barry Leiba, and Henri Sivonen for feedback and text 208 suggestions. 210 Authors' Addresses 212 Alexey Melnikov 213 Isode Limited 214 5 Castle Business Village 215 36 Station Road 216 Hampton, Middlesex TW12 2BX 217 UK 219 Email: Alexey.Melnikov@isode.com 221 Julian F. Reschke 222 greenbytes GmbH 223 Hafenweg 16 224 Muenster, NW 48155 225 Germany 227 Email: julian.reschke@greenbytes.de 228 URI: http://greenbytes.de/tech/webdav/