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