idnits 2.17.1 draft-alvestrand-lang-tag-v2-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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. ** 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. == There are 3 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC1766, but the abstract doesn't seem to mention this, which it should. 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 (September 2000) is 8622 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) == Unused Reference: 'ISO 639-2' is defined on line 404, but no explicit reference was found in the text == Unused Reference: 'RFC 1327' is defined on line 414, but no explicit reference was found in the text == Unused Reference: 'RFC 1521' is defined on line 417, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 639' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 639-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO 3166' ** Obsolete normative reference: RFC 1327 (Obsoleted by RFC 2156) ** Obsolete normative reference: RFC 1521 (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 11 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft H. Alvestrand 2 draft-alvestrand-lang-tag-v2-04.txt 3 Cisco Systems 4 Target Category: Best Current Practice 5 September 2000 6 Obsoletes: RFC 1766 Expires: March 2001 8 Tags for the Identification of Languages 10 Status of this Memo 11 The file name of this memo is draft-alvestrand-lang-tag-v2-04.txt 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 27 Comments on this draft should be sent to the mailing list for this 28 document. 29 The mailing list is 31 Abstract 32 This document describes a language tag for use in cases where it is 33 desired to indicate the language used in an information object, how to 34 register values for use in this language tag, and a construct for 35 Tags for the names of languages Harald Alvestrand 36 1. Introduction 38 Human beings on our planet have, past and present, used a number of 39 languages. A great number of these people would prefer to have 40 information presented in a language that they understand. 41 In some contexts, it is possible to have information available in more 42 than one language, or it might be possible to provide tools (such as 43 dictionaries) to assist in the understanding of a language. 44 Also, many types of information processing require knowledge of the 45 language in which information is expressed in order for that process to 46 be performed on the information; for example spell-checking, computer- 47 synthesized speech, Braille, or high-quality print renderings. 48 One means of making this information available is a means of labeling 49 the information content with an identifier for the language that is 50 used in this information content. 51 This document specifies an identifier mechanism, a registration 52 function for values to be used with that identifier mechanism, and a 53 construct for matching against those values. 55 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 57 document are to be interpreted as described in [RFC 2119]. 59 2. The Language tag 61 2.1 Language tag syntax 62 The language tag is composed of one or more parts: A primary language 63 tag and a (possibly empty) series of subtags. 65 The syntax of this tag in ABNF [RFC 2234] is: 66 Language-Tag = Primary-tag *( "-" Subtag ) 67 Primary-tag = 1*8ALPHA 68 Subtag = 1*8(ALPHA / DIGIT) 70 The productions ALPHA and DIGIT are imported from RFC 2234; they denote 71 respectively the characters A to Z in upper or lower case and the 72 digits from 0 to 9. 73 The character "-" is HYPHEN-MINUS (ABNF: %x2D). 74 All tags are to be treated as case insensitive; there exist conventions 75 for capitalization of some of them, but these should not be taken to 76 carry meaning. For instance, [ISO 3166] recommends that country codes 77 are capitalized (MN Mongolia), while [ISO 639] recommends that language 78 codes are written in lower case (mn Mongolian). 80 Tags for the names of languages Harald Alvestrand 81 2.2 Language tag sources 83 The namespace of language tags is administered by the IANA according to 84 the rules in section 3 of this document. 85 The following rules apply to the primary language tag: 86 - All 2-letter tags are interpreted according to assignments found in 87 ISO standard 639, "Code for the representation of names of languages" 88 [ISO 639], or assignments subsequently made by the ISO 639 part 1 89 maintenance agency or governing standardization bodies. 90 (Note: A revision is underway, and is expected to be released as ISO 91 639-1:2000) 92 - All 3-letter tags are interpreted according to assignments found in 93 ISO 639 part 2, "Codes for the representation of names of languages - 94 - Part 2: Alpha-3 code [ISO 639-2]", or assignments subsequently made 95 by the ISO 639 part 2 maintenance agency or governing standardization 96 bodies. 98 - The value "i" is reserved for IANA-defined registrations 99 - The value "x" is reserved for private use. Subtags of "x" shall not 100 be registered by the IANA. 101 - Other values shall not be assigned except by revision of this 102 standard. 103 The reason for reserving all other tags is to be open towards new 104 revisions of ISO 639; the use of "i" and "x" is the minimum we can do 105 here to be able to extend the mechanism to meet our immediate 106 requirements. 107 The following rules apply to the first subtag: 108 - All 2-letter codes are interpreted as ISO 3166 alpha-2 country codes 109 from [ISO 3166], or subsequently assigned by the ISO 3166 maintenance 110 agency or governing standardization bodies, denoting the area to 111 which this language variant relates. 112 - Codes of 3 to 8 letters may be registered with IANA, according to the 113 rules in chapter 5 of this document. 114 - 1-letter codes may not be assigned except after revision of this 115 standard. 116 There are no rules apart from the syntactic ones for the second and 117 subsequent subtags. 118 The information in a subtag may for instance be: 119 - Country identification, such as en-US (this usage is described in ISO 120 639) 121 - Dialect or variant information, such as en-scouse 122 Tags for the names of languages Harald Alvestrand 123 - Languages not listed in ISO 639 that are not variants of any listed 124 language, which can be registered with the i-prefix, such as i- 125 tsolyani 126 - Region identification, such as sgn-US-MA (Martha's Vineyard Sign 127 Language, which is found in the state of Massachusetts, US) 129 This document leaves the decision on what tags are appropriate or not 130 to the registration process described in section 3. 131 ISO 639 defines a maintenance agency for additions to and changes in 132 the list of languages in ISO 639. This agency is: 133 International Information Centre for Terminology (Infoterm) 134 P.O. Box 130 135 A-1021 Wien 136 Austria 137 Phone: +43 1 26 75 35 Ext. 312 138 Fax: +43 1 216 32 72 140 ISO 639-2 defines a maintenance agency for additions to and changes in 141 the list of languages in ISO 639-2. This agency is: 142 Library of Congress 143 Network Development and MARC Standards Office 144 Washington, D.C. 20540 145 USA 146 Phone: +1 202 707 6237 147 Fax: +1 202 707 0115 148 URL: http://www.loc.gov/standards/iso639 150 The maintenance agency for ISO 3166 (country codes) is: 151 ISO 3166 Maintenance Agency Secretariat 152 c/o DIN Deutsches Institut fuer Normung 153 Burggrafenstrasse 6 154 Postfach 1107 155 D-10787 Berlin 156 Germany 157 Phone: +49 30 26 01 320 158 Fax: +49 30 26 01 231 159 URL: http://www.din.de/gremien/nas/nabd/iso3166ma/ 161 ISO 3166 reserves the country codes AA, QM-QZ, XA-XZ and ZZ as user- 162 assigned codes. 163 2.3 Choice of language tag 164 One may occasionally be faced with several possible tags for the same 165 body of text. 167 Tags for the names of languages Harald Alvestrand 168 Interoperability is best served if all users send the same tag, and use 169 the same tag for the same language for all documents. If an application 170 has requirements that make the rules here inapplicable, the application 171 protocol specification MUST specify how the procedure varies from the 172 one given here. 173 The text below is based on the set of tags known to the tagging entity. 174 1. Use the most precise tagging known to the sender that can be 175 ascertained and is useful within the application context. 176 2. When a language has both an ISO 639-1 2-character tag and an ISO 639- 177 2 3-character tag, you MUST use the ISO 639-1 2-character tag. 178 3. When a language has no ISO 639-1 2-character tag, and the ISO 639-2/T 179 (Terminology) tag and the ISO 639-2/B (Bibliographic) tag differ, you 180 MUST use the Terminology tag. 181 NOTE: At present, all languages for which there is a difference have 182 2-character tags, and the displeasure of developers about the 183 existence of 2 tag sets has been adequately communicated to ISO. So 184 this situation will hopefully not arise. 185 4. When a language has both an IANA-registered tag (i-something) and an 186 ISO registered tag, you MUST use the ISO tag. 187 NOTE: When such a situation is discovered, the IANA-registered tag 188 SHOULD be deprecated as soon as possible. 189 5. You SHOULD NOT use the UND (Undetermined) tag unless the protocol in 190 use forces you to give a value for the language tag, even if the 191 language is unknown. Omitting the tag is preferred. 192 6. You SHOULD NOT use the MUL (Multiple) tag if the protocol allows you 193 to use multiple languages, as is the case for the Content-Language: 194 header. 195 NOTE: In order to avoid versioning difficulties in applications such as 196 that of RFC 1766, the ISO 639 Registration Authority Joint Advisory 197 Committee (RA-JAC) has agreed on the following policy statement: 199 "After the publication of ISO/DIS 639-1 as an International Standard, 200 no new 2-letter code shall be added to ISO 639-1 unless a 3-letter 201 code is also added at the same time to ISO 639-2. In addition, no 202 language with a 3-letter code available at the time of publication of 203 ISO 639-1 which at that time had no 2-letter code shall be 204 subsequently given a 2-letter code." 206 This will ensure that, for example, a user who implements "hwi" 207 (Hawaiian), which currently has no 2-letter code, will not find his or 208 her data invalidated by eventual addition of a 2-letter code for that 209 language." 211 2.4 Meaning of the language tag 212 Tags for the names of languages Harald Alvestrand 213 The language tag always defines a language as spoken (or written, 214 signed or otherwise signaled) by human beings for communication of 215 information to other human beings. 216 Computer languages such as programming languages are explicitly 217 excluded. 218 There is no guaranteed relationship between languages whose tags begin 219 with the same series of subtags; specifically, they are NOT guaranteed 220 to be mutually intelligible, although it will sometimes be the case 221 that they are. 222 The relationship between the tag and the information it relates to is 223 defined by the standard describing the context in which it appears. 224 Accordingly, this section can only give possible examples of its usage. 225 - For a single information object, it could be taken as the set of 226 languages that is required for a complete comprehension of the 227 complete object. 228 Example: Plain text documents. 229 - For an aggregation of information objects, it should be taken as the 230 set of languages used inside components of that aggregation. 231 Examples: Document stores and libraries. 232 - For information objects whose purpose is to provide alternatives, it 233 should be regarded as a hint that the material inside is provided in 234 several languages, and that one has to inspect each of the 235 alternatives in order to find its language or languages. In this 236 case, a tag with multiple languages does not mean that one needs to 237 be multilingual to get complete understanding of the document. 238 Example: MIME multipart/alternative. 239 - In markup languages, such as HTML and XML, language information can 240 be added to each part of the document identified by the markup 241 structure (including the whole document itself). For example, one 242 could write C'est la vie. inside a Norwegian 243 document; the Norwegian-speaking user could then access a French- 244 Norwegian dictionary to find out what the marked section meant. 245 If the user were listening to that document through a speech 246 synthesis interface, this formation could be used to signal the 247 synthesizer to appropriately apply French text-to-speech 248 pronunciation rules to that span of text, instead of misapplying the 249 Norwegian rules. 251 2.5 Language-range 252 Since the publication of RFC 1766, it has become apparent that there is 253 a need to define a term for a set of languages whose tags all begin 254 with the same sequence of subtags. 255 The following definition of language-range is derived from HTTP/1.1 256 [RFC 2616]. 257 language-range = language-tag / "*" 258 Tags for the names of languages Harald Alvestrand 259 That is, a language-range has the same syntax as a language-tag, or is 260 the single character "*". 261 A language-range matches a language-tag if it exactly equals the tag, 262 or if it exactly equals a prefix of the tag such that the first tag 263 character following the prefix is "-". 264 The special range "*" matches any tag. A protocol which uses language 265 ranges may specify additional rules about the semantics of "*"; for 266 instance, HTTP/1.1 specifies that the range "*" matches only languages 267 not matched by any other range within an "Accept-Language:" header. 268 NOTE: This use of a prefix matching rule does not imply that language 269 tags are assigned to languages in such a way that it is always true 270 that if a user understands a language with a certain tag, then this 271 user will also understand all languages with tags for which this tag is 272 a prefix. The prefix rule simply allows the use of prefix tags if this 273 is the case. 275 3. IANA registration procedure for language tags 276 The procedure given here MUST be used by anyone who wants to use a 277 language tag not defined by this document or previously registered with 278 IANA. 280 This procedure MAY also be used to register information with the IANA 281 about a tag defined by this document, for instance if one wishes to 282 make publicly available a reference to the definition for a language 283 such as sgn-US (American Sign Language). 285 Any language tag shall begin with an existing tag, and extend it. 287 ---------------------------------------------------------------------- 288 LANGUAGE TAG REGISTRATION FORM 290 Name of requester : 291 E-mail address of requester: 292 Tag to be registered : 294 English name of language : 296 Native name of language (transcribed into ASCII): 298 Reference to published description of the language (book or article): 300 Any other relevant information: 302 ---------------------------------------------------------------------- 303 The language form must be sent to for a 2- 304 week review period before it can be submitted to IANA. (This is an 305 open list. Requests to be added should be sent to .) 307 Tags for the names of languages Harald Alvestrand 308 When the two week period has passed, the language tag reviewer, who is 309 appointed by the IETF Applications Area Director, either forwards the 310 request to IANA@ISI.EDU, or rejects it because of significant 311 objections raised on the list. Note that the reviewer can raise 312 objections on the list himself, if he so desires. The important thing 313 is that the objection must be made publicly. 314 The applicant is free to modify a rejected application with additional 315 information and submit it again; this restarts the 2-week comment 316 period. 317 Decisions made by the reviewer may be appealed to the IESG. 318 All registered forms are available online in the directory 319 ftp://ftp.isi.edu/in-notes/iana/assignments/languages/ 320 Updates of registrations follow the same procedure as registrations. 321 The language tag reviewer decides whether to allow a new registrant to 322 update a registration made by someone else; in the normal case, 323 objections by the original registrant would carry extra weight in such 324 a decision. 325 There is no deletion of registrations; when some registered tag should 326 not be used any more, for instance because a corresponding ISO 639 code 327 has been registered, the registration should be amended by adding a 328 remark like "DEPRECATED: use instead" to the "other relevant 329 information" section. 330 Note: The purpose of the "published description" is intended as an aid 331 to people trying to verify whether a language is registered, or what 332 language a particular tag refers to. In most cases, reference to an 333 authoritative grammar or dictionary of the language will be useful; in 334 cases where no such work exists, other well known works describing that 335 language or in that language may be appropriate. The language tag 336 reviewer decides what constitutes a "good enough" reference material. 338 4. Security Considerations 339 The only security issue that has been raised with language tags since 340 the publication of RFC 1766, which stated that "Security issues are 341 believed to be irrelevant to this memo", is a concern with language 342 ranges used in content negotiation - that they may be used to infer the 343 nationality of the sender, and thus identify potential targets for 344 surveillance. 345 This is a special case of the general problem that anything you send is 346 visible to the receiving party; it is useful to be aware that such 347 concerns can exist in some cases. 348 The evaluation of the exact magnitude of the threat, and any possible 349 countermeasures, is left to each application protocol. 351 5. Character set considerations 352 Codes may always be expressed using the characters A-Z, a-z, 0-9 and 353 HYPHEN-MINUS, which are present in most character sets. 355 Tags for the names of languages Harald Alvestrand 356 The issue of deciding upon the rendering of a character set based on 357 the language tag is not addressed in this memo; however, it is thought 358 impossible to make such a decision correctly for all cases unless means 359 of switching language in the middle of a text are defined (for example, 360 a rendering engine that decides font based on Japanese or Chinese 361 language may produce suboptimal output when a mixed Japanese-Chinese 362 text is encountered) 364 6. Acknowledgements 365 This document has benefited from many rounds of review and comments in 366 various fora of the IETF and the Internet working groups. 367 Any list of contributors is bound to be incomplete; please regard the 368 following as only a selection from the group of people who have 369 contributed to make this document what it is today. 370 In alphabetical order: 371 Glenn Adams, Tim Berners-Lee, Marc Blanchet, Nathaniel Borenstein, Eric 372 Brunner, Sean M. Burke, John Clews, Jim Conklin, Peter Constable, John 373 Cowan, Mark Crispin, Dave Crocker, Mark Davis, Martin Duerst, Michael 374 Everson, Ned Freed, Tim Goodwin, Dirk-Willem van Gulik, Marion Gunn, 375 Paul Hoffman, Olle Jarnefors, Kent Karlsson, John Klensin, Alain 376 LaBonte, Chris Newman, Keith Moore, Masataka Ohta, Keld Jorn Simonsen, 377 Otto Stolz, Rhys Weatherley, Misha Wolf, Francois Yergeau and many, 378 many others. 380 Special thanks must go to Michael Everson, who has served as language 381 tag reviewer for almost the complete period since the publication of 382 RFC 1766, and has provided a great deal of input to this revision. 384 7. Author's Address 385 Harald Tveit Alvestrand 386 Cisco Systems 387 Weidemanns vei 27 388 7043 Trondheim 389 NORWAY 390 EMail: Harald@Alvestrand.no 391 Phone: +47 73 50 33 52 393 8. References 395 [ISO 639] 396 ISO 639:1988 (E/F) - Code for the representation of names of 397 languages - The International Organization for Standardization, 398 1st edition, 1988-04-01 Prepared by ISO/TC 37 - Terminology 399 (principles and coordination). 401 Tags for the names of languages Harald Alvestrand 402 Note that a new version (ISO 639-1:2000) is in preparation at the 403 time of this writing. 404 [ISO 639-2] 405 ISO 639-2:1998 - Codes for the representation of names of 406 languages -- Part 2: Alpha-3 code - edition 1, 1998-11-01, 66 407 pages, prepared by a Joint Working Group of ISO TC46/SC4 and ISO 408 TC37/SC2. 410 [ISO 3166] 411 ISO 3166:1988 (E/F) - Codes for the representation of names of 412 countries - The International Organization for Standardization, 413 3rd edition, 1988-08-15. 414 [RFC 1327] 415 Kille, S., "Mapping between X.400 (1988) / ISO 10021 and RFC 822", 416 RFC 1327, University College London, May 1992. 417 [RFC 1521] 418 Borenstein, N., and N. Freed, "MIME Part One: Mechanisms for 419 Specifying and Describing the Format of Internet Message Bodies", 420 RFC 1521, Bellcore, Innosoft, September 1993. 421 [RFC 2119] 422 Key words for use in RFCs to Indicate Requirement Levels. S. 423 Bradner. March 1997. 424 [RFC 2234] 425 Augmented BNF for Syntax Specifications: ABNF. D. Crocker, Ed., P. 426 Overell, November 1997. 427 [RFC 2616] 428 Hypertext Transfer Protocol -- HTTP/1.1. R. Fielding, J. Gettys, 429 J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 430 1999. 432 Appendix A: Language Tag Reference Material 433 The Library of Congress, maintainers of ISO 639-2, has made the list of 434 languages registered available on the Internet. 435 At the time of this writing, it can be found at 436 http://www.loc.gov/standards/iso639-2/langhome.html 438 The IANA registration forms for registered language codes can be found 439 at 440 http://www.isi.edu/in-notes/iana/assignments/languages/ 442 The ISO 3166 Maintenance Agency has published Web pages at 443 http://www.din.de/gremien/nas/nabd/iso3166ma/ 444 Tags for the names of languages Harald Alvestrand 445 Appendix B: Changes from RFC 1766 446 . Email list address changed from ietf-types@uninett.no to ietf- 447 languages@iana.org 448 . Updated author's address 449 . Added language-range construct from HTTP/1.1 450 . Added use of ISO 639-2 language codes 451 . Added reference to Library of Congress lists of language codes 452 . Changed examples to use registered tags 453 . Added "Any other information" to registration form 454 . Added description of procedure for updating registrations 455 . Changed target category for document from standards track to BCP 456 . Moved the content-language header definition into another document 457 . Added numbers to the permitted characters in language tags 459 Appendix X: Changes between drafts 460 This appendix is to be deleted by the RFC Editor before publication as 461 RFC. 463 Changes from draft �00 to -01 464 Changes from draft-00: 465 - Fixed up the language tag table 466 - Moved multipart/alternative stuff to appendix 467 - Changed examples to use registered tags 468 - Added * in language tag table to indicate B/T conflicts 469 - Considered, but did not adopt, changing from recommending T codes to 470 recommending B codes. At the moment, the only argument that appeals 471 to the author is that the T codes look more like the 639-1 codes than 472 the B codes do. 473 - Added procedures for updating a registration 475 Changes from draft -01 to -02 476 This appendix is to be deleted by the RFC Editor before publication as 477 RFC. 478 - Minor updates 479 - Added reference to Library of Congress code lists instead of 480 including code values 481 - Changed grammars to use RFC 2234 ABNF 482 Tags for the names of languages Harald Alvestrand 483 - Used MUST and SHOULD in label choice algorithm 485 Changes from draft �02 to �03 486 . Minor updates 487 . Content-language: header moved to another draft 488 . Added URL for ISO 3166 maintenance agency web pages 489 . Added text to clarify purpose of the literature reference on the 490 registration form 492 Changes from draft �03 to �04 493 . Minor updates 494 . Allowed numbers in labels 495 . Deleted reference to script as a valid subtag. Note: It is not 496 forbidden either! 497 . Changed ISO "registration authority" to "maintenance agency". 498 . Added example of SGN-US-MA for region-indicating subtag. Note: ISO 499 3166 part 2 is not explicitly mentioned. 500 . Added the possibility to register with IANA description of predefined 501 tags.