idnits 2.17.1 draft-freed-charset-reg-03.txt: ** The Abstract section seems to be numbered 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-23) 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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Introduction 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. ** The abstract seems to contain references (RFC-2047], [RFC-2045,RFC-2046,), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 52 has weird spacing: '...s. When the t...' == 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 (September 1997) is 9717 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) == Missing Reference: 'RFC-1543' is mentioned on line 274, but not defined ** Obsolete undefined reference: RFC 1543 (Obsoleted by RFC 2223) == Unused Reference: 'ISO-2022' is defined on line 305, but no explicit reference was found in the text == Unused Reference: 'RFC-1590' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC-1700' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC-2130' is defined on line 368, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-2022' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-8859' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO-10646' ** Obsolete normative reference: RFC 1590 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1759 (Obsoleted by RFC 3805) ** Downref: Normative reference to an Informational RFC: RFC 2130 -- Possible downref: Non-RFC (?) normative reference: ref. 'US-ASCII' Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Ned Freed, Innosoft 3 Internet Draft Jon Postel, ISI 4 6 IANA Charset 7 Registration Procedures 9 September 1997 11 Status of this Memo 13 This document is an Internet-Draft. Internet-Drafts are 14 working documents of the Internet Engineering Task Force 15 (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months. Internet-Drafts may be updated, replaced, or obsoleted 21 by other documents at any time. It is not appropriate to use 22 Internet-Drafts as reference material or to cite them other 23 than as a "working draft" or "work in progress". 25 To learn the current status of any Internet-Draft, please 26 check the 1id-abstracts.txt listing contained in the 27 Internet-Drafts Shadow Directories on ds.internic.net (US East 28 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), 29 or munnari.oz.au (Pacific Rim). 31 1. Abstract 33 MIME [RFC-2045, RFC-2046, RFC-2047] and various other modern 34 Internet protocols are capable of using many different 35 charsets. This in turn means that the ability to label 36 different charsets is essential. This registration procedure 37 exists solely to associate a specific name or names with a 38 given charset and to give an indication of whether or not a 39 given charset can be used in MIME text objects. In particular, 40 the general applicability and appropriateness of a given 41 registered charset is a protocol issue, not a registration 42 issue, and is not dealt with by this registration procedure. 44 2. Definitions and Notation 46 The following sections define various terms used in this 47 document. 49 2.1. Requirements Notation 51 This document occasionally uses terms that appear in capital 52 letters. When the terms "MUST", "SHOULD", "MUST NOT", "SHOULD 53 NOT", and "MAY" appear capitalized, they are being used to 54 indicate particular requirements of this specification. A 55 discussion of the meanings of these terms appears in [RFC- 56 2119]. 58 2.2. Character 60 A member of a set of elements used for the organisation, 61 control, or representation of data. 63 2.3. Charset 65 The term "charset" (referred to as a "character set" in 66 previous versions of this document) is used here to refer to a 67 method of converting a sequence of octets into a sequence of 68 characters. This conversion may also optionally produce 69 additional control information such as directionality 70 indicators. 72 Note that unconditional and unambiguous conversion in the 73 other direction is not required, in that not all characters 74 may be representable by a given charset and a charset may 75 provide more than one sequence of octets to represent a 76 particular sequence of characters. 78 This definition is intended to allow charsets to be defined in 79 a variety of different ways, from simple single-table mappings 80 such as US-ASCII to complex table switching methods such as 81 those that use ISO 2022's techniques, to be used as charsets. 82 However, the definition associated with a charset name must 83 fully specify the mapping to be performed. In particular, use 84 of external profiling information to determine the exact 85 mapping is not permitted. 87 HISTORICAL NOTE: The term "character set" was originally used 88 in MIME to describe such straightforward schemes as US-ASCII 89 and ISO-8859-1 which consist of a small set of characters and 90 a simple one-to-one mapping from single octets to single 91 characters. Multi-octet character encoding schemes and 92 switching techniques make the situation much more complex. As 93 such, the definition of this term was revised to emphasize 94 both the conversion aspect of the process, and the term itself 95 has been changed to "charset" to emphasize that it is not, 96 after all, just a set of characters. A discussion of these 97 issues as well as specification of standard terminology for 98 use in the IETF appears in RFC 2130. 100 2.4. Coded Character Set 102 A Coded Character Set (CCS) is a mapping from a set of 103 abstract characters to a set of integers. Examples of coded 104 character sets are ISO 10646 [ISO-10646], US-ASCII [US-ASCII], 105 and the ISO-8859 series [ISO-8859]. 107 2.5. Character Encoding Scheme 109 A Character Encoding Scheme (CES) is a mapping from a Coded 110 Character Set or several coded character sets to a set of 111 octets. A given CES is typically associated with a single CCS; 112 for example, UTF-8 applies only to ISO 10646. 114 3. Registration Requirements 116 Registered charsets are expected to conform to a number of 117 requirements as described below. 119 3.1. Required Characteristics 121 Registered charsets MUST conform to the definition of a 122 "charset" given above. In addition, charsets intended for use 123 in MIME content types under the "text" top-level type must 124 conform to the restrictions on that type described in RFC 125 2045. All registered charsets MUST note whether or not they 126 are suitable for use in MIME. 128 All charsets which are constructed as a composition of a CCS 129 and a CES MUST either include the CCS and CES they are based 130 on in their registration or else cite a definition of their 131 CCS and CES that appears elsewhere. 133 All registered charsets MUST be specified in a stable, openly 134 available specification. Registration of charsets whose 135 specifications aren't stable and openly available is 136 forbidden. 138 3.2. New Charsets 140 This registration mechanism is not intended to be a vehicle 141 for the definition of entirely new charsets. This is due to 142 the fact that the registration process does NOT contain 143 adequate review mechanisims for such undertakings. 145 As such, only charsets defined by other processes and 146 standards bodies, or specific profiles of such charsets, are 147 eligible for registration. 149 3.3. Naming Requirements 151 One or more names MUST be assigned to all registered charsets. 152 Multiple names for the same charset are permitted, but if 153 multiple names are assigned a single primary name for the 154 charset MUST be identified. All other names are considered to 155 be aliases for the primary name and use of the primary name is 156 preferred over use of any of the aliases. 158 Each assigned name MUST uniquely identify a single charset. 159 All charset names MUST be suitable for use as the value of a 160 MIME content type charset parameter and hence MUST conform to 161 MIME parameter value syntax. This applies even if the specific 162 charset being registered is not suitable for use with the 163 "text" media type. 165 Finally, charsets being registered for use with the "text" 166 media type MUST have a primary name that conforms to the more 167 restrictive syntax of the charset field in a MIME encoded-word 168 [RFC-2047]. 170 3.4. Functionality Requirement 172 Charsets must function as actual charsets: Registration of 173 things that are better thought of as a transfer encoding, as a 174 media type, or as a collection of separate entities of another 175 type, is not allowed. For example, although HTML could 176 theoretically be thought of as a charset, it is really better 177 thought of as a media type and as such it cannot be registered 178 as a charset. 180 3.5. Usage and Implementation Requirements 182 Use of a large number of charsets in a given protocol may 183 hamper interoperability. However, the use of a large number of 184 undocumented and/or unlabelled charsets hampers 185 interoperability even more. 187 A charset should therefore be registered ONLY if it adds 188 significant functionality that is valuable to a large 189 community, OR if it documents existing practice in a large 190 community. Note that charsets registered for the second reason 191 should be explicitly marked as being of limited or specialized 192 use and should only be used in Internet messages with prior 193 bilateral agreement. 195 3.6. Publication Requirements 197 Charset registrations can be published in RFCs, however, RFC 198 publication is not required to register a new charset. 200 The registration of a charset does not imply endorsement, 201 approval, or recommendation by the IANA, IESG, or IETF, or 202 even certification that the specification is adequate. It is 203 expected that applicability statements for particular 204 applications will be published from time to time that 205 recommend implementation of, and support for, charsets that 206 have proven particularly useful in those contexts. 208 3.7. MIBenum Requirements 210 Each registered charset MUST also be assigned a unique 211 enumerated integer value. These "MIBenum" values are defined 212 by and used in the Printer MIB [RFC-1759]. 214 A MIBenum value for each charset will be assigned by IANA at 215 the time of registration. 217 4. Registration Procedure 219 The following procedure has been implemented by the IANA for 220 review and approval of new charsets. This is not a formal 221 standards process, but rather an administrative procedure 222 intended to allow community comment and sanity checking 223 without excessive time delay. 225 4.1. Present the Charset to the Community 227 Send the proposed charset registration to the "ietf- 228 charsets@iana.org" mailing list. This mailing list has been 229 established for the sole purpose of reviewing proposed charset 230 registrations. Proposed charsets are not formally registered 231 and must not be used; the "x-" prefix specified in RFC 2045 232 can be used until registration is complete. 234 The intent of the public posting is to solicit comments and 235 feedback on the definition of the charset and the name chosen 236 for it over a two week period. 238 4.2. Charset Reviewer 240 When the two week period has passed and the registration 241 proposer is convinced that consensus has been achieved, the 242 registration application should be submitted to IANA and the 243 charset reviewer. The charset reviewer, who is appointed by 244 the IETF Applications Area Director(s), either approves the 245 request for registration or rejects it. Rejection may occur 246 because of significant objections raised on the list or 247 objections raised externally. If the charset reviewer 248 considers the registration sufficiently important and 249 controversial, a last call for comments may be issued to the 250 full IETF. The charset reviewer may also recommend standards 251 track processing (before or after registration) when that 252 appears appropriate and the level of specification of the 253 charset is adequate. 255 Decisions made by the reviewer must be posted to the ietf- 256 charsets mailing list within 14 days. Decisions made by the 257 reviewer may be appealed to the IESG. 259 4.3. IANA Registration 261 Provided that the charset registration has either passed 262 review or has been successfully appealed to the IESG, the IANA 263 will register the charset, assign a MIBenum value, and make 264 its registration available to the community. 266 5. Location of Registered Charset List 268 Charset registrations will be posted in the anonymous FTP file 269 "ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets" 270 and all registered charsets will be listed in the periodically 271 issued "Assigned Numbers" RFC [currently RFC-1700]. The 272 description of the charset may also be published as an 273 Informational RFC by sending it to "rfc-editor@isi.edu" 274 (please follow the instructions to RFC authors [RFC-1543]). 276 6. Registration Template 278 To: ietf-charsets@iana.org 279 Subject: Registration of new charset 281 Charset name(s): 283 (All names must be suitable for use as the value of a 284 MIME content-type parameter.) 286 Published specification(s): 288 (A specification for the charset must be 289 openly available that accurately describes what 290 is being registered. If a charset is defined as 291 a composition of a CCS and a CES then these defintions 292 must either be included or referenced.) 294 Person & email address to contact for further information: 296 7. Security Considerations 298 This registration procedure is not known to raise any sort of 299 security considerations that are appreciably different from 300 those already existing in the protocols that employ registered 301 charsets. 303 8. References 305 [ISO-2022] 306 International Standard -- Information Processing -- 307 Character Code Structure and Extension Techniques, 308 ISO/IEC 2022:1994, 4th ed. 310 [ISO-8859] 311 International Standard -- Information Processing -- 8-bit 312 Single-Byte Coded Graphic Character Sets 313 - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed. 314 - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed. 315 - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed. 316 - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed. 317 - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st 318 ed. 319 - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed. 320 - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed. 321 - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed. 322 - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st 323 ed. 324 International Standard -- Information Technology -- 8-bit 325 Single-Byte Coded Graphic Character Sets 326 - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992, 327 1st ed. 329 [ISO-10646] 330 ISO/IEC 10646-1:1993(E), "Information technology -- 331 Universal Multiple-Octet Coded Character Set (UCS) -- 332 Part 1: Architecture and Basic Multilingual Plane", 333 JTC1/SC2, 1993. 335 [RFC-1590] 336 Postel, J., "Media Type Registration Procedure", RFC 337 1590, USC/Information Sciences Institute, March 1994. 339 [RFC-1700] 340 Reynolds, J. and Postel, J., "Assigned Numbers", STD 2, 341 RFC 1700, USC/Information Sciences Institute, October 342 1994. 344 [RFC-1759] 345 Smith, R., Wright, F., Hastings, T., Zilles, S., 346 Gyllenskog, J., "Printer MIB", RFC 1759, March 1995. 348 [RFC-2045] 349 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 350 Extensions (MIME) Part One: Format of Internet Message 351 Bodies", RFC 2045, Bellcore, Innosoft, November 1996. 353 [RFC-2046] 354 Freed, N. and Borenstein, N., "Multipurpose Internet Mail 355 Extensions (MIME) Part Two: Media Types", RFC 2046, 356 Bellcore, Innosoft, November 1996. 358 [RFC-2047] 359 Moore, K., "Multipurpose Internet Mail Extensions (MIME) 360 Part Three: Representation of Non-Ascii Text in Internet 361 Message Headers", RFC 2047, University of Tennessee, 362 November 1996. 364 [RFC-2119] 365 Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", RFC 2119, March 1997. 368 [RFC-2130] 369 Weider, C., Preston, C., Simonsen, K., Alvestrand, H., 370 Atkinson, R., Crispin, M., Svanberg, P., "Report from the 371 IAB Character Set Workshop", RFC 2130, April 1997. 373 [US-ASCII] 374 Coded Character Set -- 7-Bit American Standard Code for 375 Information Interchange, ANSI X3.4-1986. 377 9. Authors' Addresses 379 Ned Freed 380 Innosoft International, Inc. 381 1050 Lakes Drive 382 West Covina, CA 91790 383 USA 384 tel: +1 626 919 3600 fax: +1 626 919 3614 385 email: ned.freed@innosoft.com 387 Jon Postel 388 USC/Information Sciences Institute 389 4676 Admiralty Way 390 Marina del Rey, CA 90292 391 USA 392 tel: +1 310 822 1511 fax: +1 310 823 6714 393 email: Postel@ISI.EDU 395 Appendix A -- IANA and RFC Editor To-Do List 397 VERY IMPORTANT NOTE: This appendix is intended to communicate 398 various editorial and procedural tasks the IANA and the RFC 399 Editor should undertake prior to publication of this document 400 as an RFC. This appendix should NOT appear in the actual RFC 401 version of this document! 403 This document refers to the character set mailing list ietf- 404 charsets@iana.org. This alias needs to be established and 405 should initially point to ietf-charsets@innosoft.com.