idnits 2.17.1 draft-ietf-appsawg-mime-default-charset-00.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 (February 1, 2012) is 4461 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: August 4, 2012 February 1, 2012 8 Update to MIME regarding Charset Parameter Handling in 9 Textual Media Types 10 draft-ietf-appsawg-mime-default-charset-00 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 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 4, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction and Overview . . . . . . . . . . . . . . . 3 53 2. Conventions Used in This Document . . . . . . . . . . . 3 54 3. New rules for default charset parameter values for 55 text/* media types . . . . . . . . . . . . . . . . . . 3 56 4. Default charset parameter value for text/plain 57 media type . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Security Considerations . . . . . . . . . . . . . . . . 4 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . 4 60 7. References . . . . . . . . . . . . . . . . . . . . . . 4 61 7.1. Normative References . . . . . . . . . . . . . . . . . 4 62 7.2. Informative References . . . . . . . . . . . . . . . . 5 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . . 5 64 Authors' Addresses . . . . . . . . . . . . . . . . . . 5 66 1. Introduction and Overview 68 [RFC2046] specified that the default charset parameter (i.e. the 69 value used when it is not specified) is "US-ASCII". [RFC2616] 70 changed the default for use by HTTP to be "ISO-8859-1". This 71 encoding is not very common for new text/* media types and a special 72 rule in HTTP adds confusion about which specification ([RFC2046] or 73 [RFC2616]) is authoritative in regards to the default charset for 74 text/* media types. [[anchor2: At the time of writing of this 75 document the IETF HTTPBIS WG is working on an update to RFC 2616 76 which removes the default charset of "ISO-8859-1" for "text/*" media 77 types. It is expected that the set of HTTPBIs documents will 78 reference this document in order to use the updated rules of default 79 charset in "text/*" media types.]] 81 Many complex text subtypes such as text/html [RFC2854] and text/xml 82 [RFC3023] have internal (to their format) means of describing the 83 charset. Many existing User Agents ignore the default of "US-ASCII" 84 rule for at least text/html and text/xml. 86 This document changes RFC 2046 rules regarding default charset 87 parameter values for text/* media types to better align with common 88 usage by existing clients and servers. 90 2. Conventions Used in This Document 92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 94 document are to be interpreted as described in [RFC2119]. 96 3. New rules for default charset parameter values for text/* media 97 types 99 Section 4.1.2 of [RFC2046] says: 101 The default character set, which must be assumed in the absence of 102 a charset parameter, is US-ASCII. 104 As explained in the Introduction section this rule is considered to 105 be outdated, so this document replaces it with the following set of 106 rules: 108 Each subtype of the "text" media type which uses the "charset" 109 parameter can define its own default value for the "charset" 110 parameter, including absence of any default. 112 In order to improve interoperability with deployed agents, "text/*" 113 media type definitions SHOULD either a) specify that the "charset" 114 parameter is not used for the defined subtype, because the charset 115 information is transported inside the payload (as in "text/xml") or 116 b) require explicit unconditional inclusion of the "charset" 117 parameter eliminating the need for a default value. In accordance 118 with option (a), above, "text/*" media types that can transport 119 charset information inside the corresponding payloads, specifically 120 including "text/html" and "text/xml", SHOULD NOT specify the use of a 121 "charset" parameter, nor any default value, in order to avoid 122 conflicting interpretations should the charset parameter value and 123 the value specified in the payload disagree. 125 New subtypes of the "text" media type, thus, SHOULD NOT define a 126 default "charset" value. If there is a strong reason to do so 127 despite this advice, they SHOULD use the "UTF-8" [RFC3629] charset as 128 the default. 130 Specifications of how to specify the "charset" parameter, and what 131 default value, if any, is used, are subtype-specific, NOT protocol- 132 specific. Protocols that use MIME, therefore, MUST NOT override 133 default charset values for "text/*" media types to be different for 134 their specific protocol. The protocol definitions MUST leave that to 135 the subtype definitions. 137 4. Default charset parameter value for text/plain media type 139 The default charset parameter value for text/plain is unchanged from 140 [RFC2046] and remains as "US-ASCII". 142 5. Security Considerations 144 TBD. Guessing of default charset is a security problem. Conflicting 145 information in-band vs out-of-band is also a security problem. 147 6. IANA Considerations 149 This document asks IANA to update the "text" subregistry of the Media 150 Types registry to additionally point to this document. 152 7. References 154 7.1. Normative References 156 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 157 Extensions (MIME) Part Two: Media Types", RFC 2046, 158 November 1996. 160 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 161 Requirement Levels", BCP 14, RFC 2119, March 1997. 163 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 164 10646", STD 63, RFC 3629, November 2003. 166 7.2. Informative References 168 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 169 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 170 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 172 [RFC2854] Connolly, D. and L. Masinter, "The 'text/html' Media 173 Type", RFC 2854, June 2000. 175 [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media 176 Types", RFC 3023, January 2001. 178 Appendix A. Acknowledgements 180 Many thanks to Ned Freed and John Klensin for comments and ideas that 181 motivated creation of this document, and to Barry Leiba for suggested 182 text. 184 Authors' Addresses 186 Alexey Melnikov 187 Isode Limited 188 5 Castle Business Village 189 36 Station Road 190 Hampton, Middlesex TW12 2BX 191 UK 193 Email: Alexey.Melnikov@isode.com 195 Julian F. Reschke 196 greenbytes GmbH 197 Hafenweg 16 198 Muenster, NW 48155 199 Germany 200 Email: julian.reschke@greenbytes.de 201 URI: http://greenbytes.de/tech/webdav/