idnits 2.17.00 (12 Aug 2021) /tmp/idnits21285/draft-iana-charset-reg-procedure-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 document seems to lack an Introduction section. ** The abstract seems to contain references ([RFC2978]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. -- The draft header indicates that this document obsoletes RFC2978, but the abstract doesn't seem to directly say this. It does mention RFC2978 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 -- The document date (April 24, 2015) is 2577 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 1759 (Obsoleted by RFC 3805) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Mcfadden 3 Internet-Draft IANA 4 Obsoletes: 2978 (if approved) A. Melnikov, Ed. 5 Intended status: Best Current Practice Isode Ltd 6 Expires: October 26, 2015 April 24, 2015 8 IANA Charset Registration Procedures 9 draft-iana-charset-reg-procedure-01 11 Abstract 13 Multipurpose Internet Mail Extensions (MIME) (RFC-2045, RFC-2046, 14 RFC-2047, RFC-2231) and various other Internet protocols are capable 15 of using many different charsets. This in turn means that the 16 ability to label different charsets is essential. 18 This document obsoletes the IANA Charset Registration Procedures 19 originally defined in [RFC2978]. Specifically, this document 20 completely revises the registration procedures and the charset 21 registries. The charset registry is now divided into three parts 22 with separate registration procedures for each. 24 Note: The charset registration procedure exists solely to associate a 25 specific name or names with a given charset and to give an indication 26 of whether or not a given charset can be used in MIME text objects. 27 In particular, the general applicability and appropriateness of a 28 given registered charset to a particular application is a protocol 29 issue, not a registration issue, and is not dealt with by this 30 registration procedure. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on October 26, 2015. 49 Copyright Notice 51 Copyright (c) 2015 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Definitions and Notation . . . . . . . . . . . . . . . . . . 3 67 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3 68 1.2. Character . . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.3. Charset . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 1.4. Coded Character Set . . . . . . . . . . . . . . . . . . . 4 71 1.5. Character Encoding Scheme . . . . . . . . . . . . . . . . 4 72 2. Charset Registration Requirements . . . . . . . . . . . . . . 4 73 2.1. Required Characteristics . . . . . . . . . . . . . . . . 4 74 2.2. New Charsets . . . . . . . . . . . . . . . . . . . . . . 4 75 2.3. Naming Requirements . . . . . . . . . . . . . . . . . . . 5 76 2.4. Functionality Requirement . . . . . . . . . . . . . . . . 6 77 2.5. Usage and Implementation Requirements . . . . . . . . . . 6 78 2.6. Publication Requirements . . . . . . . . . . . . . . . . 6 79 2.7. MIBenum Requirements . . . . . . . . . . . . . . . . . . 6 80 3. The Charset Registry . . . . . . . . . . . . . . . . . . . . 7 81 3.1. The Recommended charset registry . . . . . . . . . . . . 7 82 3.2. The Widely-used Open Standard charset registry . . . . . 7 83 3.2.1. Submitting "Widely-used Open Standard" charset 84 Proposals to the IETF Community . . . . . . . . . . . 8 85 3.2.2. IANA Charset Registration Template . . . . . . . . . 8 86 3.2.3. Charset Reviewer . . . . . . . . . . . . . . . . . . 9 87 3.2.4. IANA Registration of "Widely-used Open Standard" 88 charsets . . . . . . . . . . . . . . . . . . . . . . 9 89 3.3. The Other charset subregistry . . . . . . . . . . . . . . 9 90 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 91 4.1. Publication of Registered Charset List . . . . . . . . . 10 92 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 93 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 94 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 95 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 96 7.2. Informative References . . . . . . . . . . . . . . . . . 12 98 Appendix A. Changes Since RFC 2978 . . . . . . . . . . . . . . . 13 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 101 1. Definitions and Notation 103 The following sections define terms used in this document. 105 1.1. Requirements Notation 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 1.2. Character 113 A member of a set of elements used for the organization, control, or 114 representation of data. 116 1.3. Charset 118 The term "charset" (referred to as a "character set" in previous 119 versions of this document) is used here to refer to a method of 120 converting a sequence of octets into a sequence of characters. This 121 conversion may also optionally produce additional control information 122 such as directionality indicators. 124 Note that unconditional and unambiguous conversion in the other 125 direction is not required, in that not all characters may be 126 representable by a given charset and a charset may provide more than 127 one sequence of octets to represent a particular sequence of 128 characters. 130 This definition is intended to allow charsets to be defined in a 131 variety of different ways, from simple single-table mappings such as 132 US-ASCII [RFC0020] to complex table switching methods such as those 133 that use ISO 2022's [ISO-2022] techniques. However, the definition 134 associated with a charset name must fully specify the mapping to be 135 performed. In particular, use of external profiling information to 136 determine the exact mapping is not permitted. 138 HISTORICAL NOTE: The term "character set" was originally used in MIME 139 to describe such straightforward schemes as US-ASCII and ISO-8859-1 140 [ISO-8859] which consist of a small set of characters and a simple 141 one-to-one mapping from single octets to single characters. Multi- 142 octet character encoding schemes and switching techniques make the 143 situation much more complex. As such, the definition of this term 144 was revised to emphasize both the conversion aspect of the process, 145 and the term itself has been changed to "charset" to emphasize that 146 it is not, after all, just a set of characters. A discussion of 147 these issues as well as specification of standard terminology for use 148 in the IETF appears in [RFC2130]. 150 1.4. Coded Character Set 152 A Coded Character Set (CCS) is a one-to-one mapping from a set of 153 abstract characters to a set of integers. Examples of coded 154 character sets are ISO 10646 [ISO-10646], US-ASCII [RFC0020], and the 155 ISO-8859 series [ISO-8859]. 157 1.5. Character Encoding Scheme 159 A Character Encoding Scheme (CES) is a mapping from a Coded Character 160 Set or several coded character sets to a set of octet sequences. A 161 given CES is sometimes associated with a single CCS; for example, 162 UTF-8 [RFC3629] applies only to ISO 10646. 164 2. Charset Registration Requirements 166 Registered charsets are expected to conform to a number of 167 requirements as described below. 169 2.1. Required Characteristics 171 Registered charsets MUST conform to the definition of a "charset" 172 given above. In addition, charsets intended for use in MIME content 173 types under the "text" top-level media type MUST conform to the 174 restrictions on that type described in [RFC2045]. All registered 175 charsets MUST note whether or not they are suitable for use in MIME 176 text. 178 All charsets which are constructed as a composition of one or more 179 CCS's and a CES MUST either include the CCS's and CES they are based 180 on in their registration or else cite a definition of their CCS's and 181 CES that appears elsewhere. 183 All registered charsets MUST be specified in a stable, openly 184 available specification. Registration of charsets whose 185 specifications aren't stable and openly available is forbidden. 187 2.2. New Charsets 189 This registration mechanism is not intended to be a vehicle for the 190 design and definition of entirely new charsets. This is due to the 191 fact that the registration process does NOT contain adequate review 192 mechanisms for such undertakings. 194 As such, only charsets defined by other processes and standards 195 bodies, or specific profiles or combinations of such charsets, are 196 eligible for registration. 198 2.3. Naming Requirements 200 One or more names MUST be assigned to all registered charsets. 201 Multiple names for the same charset are permitted, but if multiple 202 names are assigned a single primary name for the charset MUST be 203 identified. All other names are considered to be aliases for the 204 primary name and use of the primary name is preferred over use of any 205 of the aliases. 207 Each assigned name MUST uniquely identify a single charset. All 208 charset names MUST be suitable for use as the value of a MIME content 209 type charset parameter and hence MUST conform to MIME parameter value 210 syntax (see Section 5.1 of RFC 2045). This applies even if the 211 specific charset being registered is not suitable for use with the 212 "text" media type. All charsets MUST be assigned a name that 213 provides a display string for the associated "MIBenum" value defined 214 below. These "MIBenum" values are defined by and used in the Printer 215 MIB [RFC1759]. [[RFC 1759 got obsoleted by RFC 3805 and MIBEnum is 216 no longer there. Should we point to http://www.iana.org/assignments/ 217 ianacharset-mib instead?]] Such names MUST begin with the letters 218 "cs" and MUST contain no more than 40 characters (including the "cs" 219 prefix) chosen from from the printable subset of US-ASCII. Only one 220 name beginning with "cs" may be assigned to a single charset. If no 221 name of this form is explicitly defined IANA will assign an alias 222 consisting of "cs" prepended to the primary charset name. 224 Finally, charsets being registered for use with the "text" media type 225 MUST have a primary name that conforms to the more restrictive syntax 226 of the charset field in MIME encoded-words [RFC2047] [RFC2231] and 227 MIME extended parameter values [RFC2231]. A combined ABNF [RFC5234] 228 definition for such names is as follows:" 230 mime-charset = 1*mime-charset-chars 231 mime-charset-chars = ALPHA / DIGIT / 232 "!" / "#" / "$" / "%" / "&" / 233 "+" / "-" / "^" / "_" / "`" / 234 "{" / "}" / "~" 235 ALPHA = "A".."Z" ; Case insensitive ASCII Letter 236 DIGIT = "0".."9" ; Numeric digit 238 2.4. Functionality Requirement 240 Charsets MUST function as actual charsets: Registration of things 241 that are better thought of as a transfer encoding, as a media type 242 [RFC2046], or as a collection of separate entities of another type, 243 is not allowed. For example, although HTML could theoretically be 244 thought of as a charset, it is really better thought of as a media 245 type and as such it cannot be registered as a charset. 247 2.5. Usage and Implementation Requirements 249 Use of a large number of charsets in a given protocol may hamper 250 interoperability. However, the use of a large number of undocumented 251 and/or unlabeled charsets hampers interoperability even more. 253 A charset should therefore be registered ONLY if it adds significant 254 functionality that is valuable to a large community, OR if it 255 documents existing practice in a large community. Note that charsets 256 registered for the second reason should be explicitly marked as being 257 of limited or specialized use and should only be used in Internet 258 messages with prior bilateral agreement. 260 2.6. Publication Requirements 262 Charset registrations MAY be published in RFCs, however, RFC 263 publication is not required to register a new charset. 265 The registration of a charset does not imply endorsement, approval, 266 or recommendation by the IANA, IESG, or IETF, or even certification 267 that the specification is adequate. It is expected that 268 applicability statements for particular applications will be 269 published from time to time that recommend implementation of, and 270 support for, charsets that have proven particularly useful in those 271 contexts. 273 Charset registrations SHOULD include a specification of mapping from 274 the charset into ISO 10646 (Unicode) [Unicode7.0] if specification of 275 such a mapping is feasible. 277 2.7. MIBenum Requirements 279 Each registered charset MUST also be assigned a unique enumerated 280 integer value. These "MIBenum" values are defined by and used in the 281 Printer MIB [RFC1759]." 283 A MIBenum value for each charset will be assigned by IANA at the time 284 of registration. MIBenum values are not assigned by the person 285 registering the charset. 287 3. The Charset Registry 289 The following procedure has been implemented by the IANA for review 290 and approval of new charsets. In [RFC2978] an Expert Review process 291 was used to add new charsets into the registry. This document 292 changes that model by creating a new charset registry with three new 293 subregistries. For each of the new registries, the registration 294 procedures and initial registrations are provided. 296 3.1. The Recommended charset registry 298 The first sub-registry of the full charset registry is the 299 "recommended" charset registry. 301 New registrations in the "recommended" charset registry require 302 "Standards Action" as defined by [RFC5226]. Specifically, the 303 charset MUST have a standards track RFC that defines the charset 304 itself and MUST ALSO have a standards track RFC recommending its use. 306 In the RFC that defines the charset, the document MUST have a single 307 recommended MIME charset label following the "mime-charset" syntax 308 defined in Section 2.3. It MUST also state whether it is suitable 309 for MIME text and have a reference to a formal specification or 310 translation table to Unicode [Unicode7.0]. 312 There is one, initial entry in the Recommended charset registry: 313 UTF-8 [RFC3629]. 315 3.2. The Widely-used Open Standard charset registry 317 The second sub-registry of the full charset registry is the "Widely- 318 used Open Standard" charset registry. 320 New registrations in the "Widely-used Open Standard" charset registry 321 require "Expert Review" as defined by [RFC5226]. In Section 3.2.2 of 322 this document a template is provided that allows proposals for new 323 charsets in this subregistry. 325 In the template that describes the charset, the template MUST provide 326 a single recommended MIME charset label following the "mime-charset" 327 syntax defined in Section 2.3. It MUST ALSO state whether it is 328 suitable for MIME text and have a reference to a formal specification 329 or translation table to Unicode. 331 The following charsets are to be moved from the historic charset 332 registry into the new "Widely-used Open Standard" subregistry: INSERT 333 A LIST OF CHARSET NAMES HERE. [[GUIDANCE IS REQUIRED FOR THIS 334 ENTRY]] 336 3.2.1. Submitting "Widely-used Open Standard" charset Proposals to the 337 IETF Community 339 Send the proposed "Widely-used Open Standard" charset proposal to the 340 "ietf-charsets@iana.org" mailing list. (Information about joining 341 this list is available on the IANA Website, http://www.iana.org.) 342 This mailing list has been established for the sole purpose of 343 reviewing proposed charset registrations. Proposed charsets are not 344 formally registered and must not be used; the "x-" prefix specified 345 in [RFC2045] can be used until registration is complete. 347 The posting of a charset to the list initiates a two week public 348 review process. 350 The intent of the public posting is to solicit comments and feedback 351 on the definition of the charset and the name chosen for it. 353 3.2.2. IANA Charset Registration Template 355 To: ietf-charsets@iana.org 357 Subject: Registration of new charset [names] 359 Charset name: 361 (All names must be suitable for use as the value of a MIME Content- 362 Type parameter, see Section 5.1 of RFC 2045.) 364 Charset aliases: 366 (All aliases must also be suitable for use as the value of a MIME 367 content-type parameter.) 369 Suitability for use in MIME text: 371 Published specification(s): 373 (A specification for the charset MUST be openly available that 374 accurately describes what is being registered. If a charset is 375 defined as a composition of one or more CCS's and a CES then these 376 definitions MUST either be included or referenced.) 378 ISO 10646 equivalency table: 380 (A URI to a specification of how to translate from this charset to 381 ISO 10646 and vice versa SHOULD be provided.) 383 Additional information: 385 Person & email address to contact for further information: 387 Intended usage: 389 (One of COMMON, LIMITED USE or OBSOLETE) 391 3.2.3. Charset Reviewer 393 When the two week period has passed and the registration proposer is 394 convinced that consensus has been achieved, the registration 395 application should be submitted to IANA and the charset reviewer. 396 The charset reviewer, who is appointed by the IETF Applications Area 397 Director(s), either approves the request for registration or rejects 398 it. Rejection may occur because of significant objections raised on 399 the list or objections raised externally. If the charset reviewer 400 considers the registration sufficiently important and controversial, 401 a last call for comments may be issued to the full IETF. The charset 402 reviewer may also recommend standards track processing (before or 403 after registration) when that appears appropriate and the level of 404 specification of the charset is adequate. 406 The charset reviewer must reach a decision and post it to the ietf- 407 charsets mailing list within two weeks. Decisions made by the 408 reviewer may be appealed to the IESG. 410 3.2.4. IANA Registration of "Widely-used Open Standard" charsets 412 Provided that the charset registration has either passed review or 413 has been successfully appealed to the IESG, the IANA will register 414 the charset, assign a MIBenum value and make its registration 415 available to the community. 417 3.3. The Other charset subregistry 419 The third subregistry is for all other charsets. Registration of 420 charsets in the "other" charset subregistry is done on a "First Come, 421 First Served" basis as defined by [RFC5226]. 423 4. IANA Considerations 425 This document requests that IANA completely revise the existing 426 charset registry. The new registry shold be divided into three 427 subregistries. These subregistries are: "Recommended charsets", 428 "Widely-used Open Standard charsets" and "Other charsets". 430 The registration procedure for the "Recommended charset" subregistry 431 is Standards Action required. IANA is directed to move the following 432 entries from the [RFC2978] legacy registry to this subregistry: UTF-8 433 [RFC3629]. 435 The registration procedure for the "Widely-used Open Standard 436 charset" subregistry is Expert Review. IANA is directed to move the 437 following entries from the [RFC2978] legacy registry to this 438 subregistry: INSERT A LIST OF CHARSET NAMES HERE. [[GUIDANCE IS 439 REQUIRED FOR THIS ENTRY]] 441 The registration procedure for the "Other charset" subregistry is 442 First Come First Served. IANA is directed to move the following 443 entries from the [RFC2978] legacy registry to this subregistry: 444 INSERT A LIST OF CHARSET NAMES HERE. [[GUIDANCE IS REQUIRED FOR THIS 445 ENTRY]] 447 In all cases the registration template specified in Section 3.2.2 448 must be used. 450 4.1. Publication of Registered Charset List 452 This document directs IANA to create a new XML-based registry for 453 charset registrations. This registry will be divided into three 454 subregistries as specified in Section 3 of this document." 456 New charset registrations will be published in the new, XML-based 457 registry. The proposed charset will use the approval process 458 appropriate for the indended, designated subregistry. 460 Legacy charset registrations will be converted to the new XML 461 registry. The instructions for converting the legacy registrations 462 into entries in the new subregistries are documented in Section 4 of 463 this document. 465 HISTORICAL NOTE: Previously, charset registrations were posted in the 466 anonymous FTP file "ftp://ftp.isi.edu/in-notes/iana/assignments/ 467 character-sets" and all registered charsets were listed in the 468 periodically issued "Assigned Numbers" RFC. 470 5. Security Considerations 472 The conversion of this IANA registry - and the changes made to the 473 registration procedures for the new subregistries - introduces no 474 known security considerations. Security issues that relate to 475 charsets are dealt with in the RFCs that describe the protocols that 476 use those charsets. 478 6. Acknowledgements 480 This document is a revision of RFC 2978 by Ned Freed and Jon Postel 481 and is largely based on their original text. 483 7. References 485 7.1. Normative References 487 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 488 October 1969. 490 [RFC1759] Smith, R., Wright, F., Hastings, T., Zilles, S., and J. 491 Gyllenskog, "Printer MIB", RFC 1759, March 1995. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 497 Extensions (MIME) Part One: Format of Internet Message 498 Bodies", RFC 2045, November 1996. 500 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 501 Extensions (MIME) Part Two: Media Types", RFC 2046, 502 November 1996. 504 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 505 Part Three: Message Header Extensions for Non-ASCII Text", 506 RFC 2047, November 1996. 508 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 509 Word Extensions: 510 Character Sets, Languages, and Continuations", RFC 2231, 511 November 1997. 513 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 514 10646", STD 63, RFC 3629, November 2003. 516 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 517 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 518 May 2008. 520 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 521 Specifications: ABNF", STD 68, RFC 5234, January 2008. 523 [Unicode7.0] 524 The Unicode Consortium, "The Unicode Standard, Version 525 7.0.0", 2014, 526 . 528 7.2. Informative References 530 [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration 531 Procedures", BCP 19, RFC 2978, October 2000. 533 [RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., 534 Atkinson, R., Crispin, M., and P. Svanberg, "The Report of 535 the IAB Character Set Workshop held 29 February - 1 March, 536 1996", RFC 2130, April 1997. 538 [ISO-2022] 539 International Organization for Standardization, 540 "Information technology - Character code structure and 541 extension techniques", ISO Standard 2022, 1994. 543 [ISO-10646] 544 International Organization for Standardization, 545 "Information Technology - Universal Multiple-octet coded 546 Character Set (UCS) - Part 1: Architecture and Basic 547 Multilingual Plane", ISO Standard 10646-1, May 1993. 549 [ISO-8859] 550 International Organization for Standardization, 551 "Information processing - 8-bit single-byte coded graphic 552 character sets - Part 1: Latin alphabet No. 1 (1987) - 553 Part 2: Latin alphabet No. 2 (1987) - Part 3: Latin 554 alphabet No. 3 (1988) - Part 4: Latin alphabet No. 4 555 (1988) - Part 5: Latin/Cyrillic alphabet (1988) - Part 6: 556 Latin/Arabic alphabet (1987) - Part 7: Latin/Greek 557 alphabet (1987) - Part 8: Latin/Hebrew alphabet (1988) - 558 Part 9: Latin alphabet No. 5 (1989) - Part 10: Latin 559 alphabet No. 6 (1992)", ISO Standard 8859, 1992. 561 Appendix A. Changes Since RFC 2978 563 Created 3 new subregistries with different IANA registration 564 procedures instead of a single existing one. 566 Updated references, split them into Normative and Informative. 567 Erratum 357. 569 Disallow single quotes in charset names (as per RFC 2231). Erratum 570 1912. Note that vertical bar and backslash characters were 571 prohibited in RFC 2978 (a change from RFC 2278), but the change was 572 never noted in RFC 2978. 574 Authors' Addresses 576 Mark Mcfadden 577 IANA 579 EMail: mark.mcfadden@icann.org 581 Alexey Melnikov (editor) 582 Isode Ltd 583 14 Castle Mews 584 Hampton, Middlesex TW12 2NP 585 UK 587 EMail: Alexey.Melnikov@isode.com