idnits 2.17.1 draft-ietf-appsawg-mime-default-charset-01.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 (March 30, 2012) is 4410 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 1, 2012 March 30, 2012 8 Update to MIME regarding Charset Parameter Handling in 9 Textual Media Types 10 draft-ietf-appsawg-mime-default-charset-01 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 1, 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 . . . . . . . . . . . . . . . . . . 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. [[anchor2: At the time of writing of this 81 document the IETF HTTPBIS WG is working on an update to RFC 2616 82 which removes the default charset of "ISO-8859-1" for "text/*" media 83 types. It is expected that the set of HTTPBIs documents will 84 reference this document in order to use the updated rules of default 85 charset in "text/*" media types.]] 87 Many complex text subtypes such as text/html [RFC2854] and text/xml 88 [RFC3023] have internal (to their format) means of describing the 89 charset. Many existing User Agents ignore the default of "US-ASCII" 90 rule for at least text/html and text/xml. 92 This document changes RFC 2046 rules regarding default charset 93 parameter values for text/* media types to better align with common 94 usage by existing clients and servers. It does not change the 95 defaults for any currently registered media type. 97 2. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. New rules for default charset parameter values for text/* media 104 types 106 Section 4.1.2 of [RFC2046] says: 108 The default character set, which must be assumed in the absence of 109 a charset parameter, is US-ASCII. 111 As explained in the Introduction section this rule is considered to 112 be outdated, so this document replaces it with the following set of 113 rules: 115 Each subtype of the "text" media type which uses the "charset" 116 parameter can define its own default value for the "charset" 117 parameter, including absence of any default. 119 In order to improve interoperability with deployed agents, "text/*" 120 media type registrations SHOULD either 122 a. specify that the "charset" parameter is not used for the defined 123 subtype, because the charset information is transported inside 124 the payload (such as in "text/xml"), or 125 b. require explicit unconditional inclusion of the "charset" 126 parameter eliminating the need for a default value. 128 In accordance with option (a), above, registrations for "text/*" 129 media types that can transport charset information inside the 130 corresponding payloads (such as "text/html" and "text/xml") SHOULD 131 NOT specify the use of a "charset" parameter, nor any default value, 132 in order to avoid conflicting interpretations should the charset 133 parameter value and the value specified in the payload disagree. 135 New subtypes of the "text" media type, thus, SHOULD NOT define a 136 default "charset" value. If there is a strong reason to do so 137 despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as 138 the default. 140 Specifications of how to specify the "charset" parameter, and what 141 default value, if any, is used, are subtype-specific, NOT protocol- 142 specific. Protocols that use MIME, therefore, MUST NOT override 143 default charset values for "text/*" media types to be different for 144 their specific protocol. The protocol definitions MUST leave that to 145 the subtype definitions. 147 4. Default charset parameter value for text/plain media type 149 The default charset parameter value for text/plain is unchanged from 150 [RFC2046] and remains as "US-ASCII". 152 5. Security Considerations 154 Guessing of the charset parameter can lead to security issues such as 155 content buffer overflows, denial of services or bypass of filtering 156 mechanisms. However, this document does not promote guessing, but 157 encourages use of charset information that is specified by the 158 sender. 160 Conflicting information in-band vs out-of-band can also lead to 161 similar security problems, and this document recommends the use of 162 charset information which is more likely to be correct (for example, 163 in-band over out-of-band). 165 6. IANA Considerations 167 This document asks IANA to update the "text" subregistry of the Media 168 Types registry to additionally point to this document. 170 7. References 172 7.1. Normative References 174 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 175 Extensions (MIME) Part Two: Media Types", RFC 2046, 176 November 1996. 178 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 179 Requirement Levels", BCP 14, RFC 2119, March 1997. 181 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 182 10646", STD 63, RFC 3629, November 2003. 184 7.2. Informative References 186 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 187 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 188 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 190 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 191 Type", RFC 2854, June 2000. 193 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 194 Types", RFC 3023, January 2001. 196 Appendix A. Acknowledgements 198 Many thanks to Ned Freed and John Klensin for comments and ideas that 199 motivated creation of this document, and to Barry Leiba for suggested 200 text. 202 Authors' Addresses 204 Alexey Melnikov 205 Isode Limited 206 5 Castle Business Village 207 36 Station Road 208 Hampton, Middlesex TW12 2BX 209 UK 210 Email: Alexey.Melnikov@isode.com 212 Julian F. Reschke 213 greenbytes GmbH 214 Hafenweg 16 215 Muenster, NW 48155 216 Germany 218 Email: julian.reschke@greenbytes.de 219 URI: http://greenbytes.de/tech/webdav/