idnits 2.17.1 draft-sullivan-rfc2277-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 date (February 14, 2014) is 3718 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: 'RFC1033' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'RFC2026' is defined on line 472, but no explicit reference was found in the text == Unused Reference: 'RFC2181' is defined on line 483, but no explicit reference was found in the text == Unused Reference: 'RFC3629' is defined on line 489, but no explicit reference was found in the text == Unused Reference: 'RFC5891' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC5892' is defined on line 508, but no explicit reference was found in the text == Unused Reference: 'RFC5893' is defined on line 512, but no explicit reference was found in the text == Unused Reference: 'RFC5894' is defined on line 516, but no explicit reference was found in the text == Unused Reference: 'RFC5895' is defined on line 520, but no explicit reference was found in the text == Unused Reference: 'RFC6762' is defined on line 532, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Sullivan 3 Internet-Draft Dyn 4 Intended status: Best Current Practice D. Thaler 5 Expires: August 18, 2014 Microsoft 6 J. Klensin 8 February 14, 2014 10 IETF Policy on Character Sets and Languages 11 draft-sullivan-rfc2277-bis-00 13 Abstract 15 This is a proposed new policy for the IETF on Character Sets and 16 Languages. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 18, 2014. 35 Copyright Notice 37 Copyright (c) 2014 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Where to do internationalization . . . . . . . . . . . . . . 3 55 2.1. Domain names . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Non-DNS, "invisible" protocol elements . . . . . . . . . 4 57 2.3. Non-DNS, "visible" protocol elements . . . . . . . . . . 5 58 2.4. Protocol data . . . . . . . . . . . . . . . . . . . . . . 6 59 3. General charset policy . . . . . . . . . . . . . . . . . . . 6 60 4. Languages . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. The need for language information . . . . . . . . . . . . 7 62 4.2. Requirement for language tagging . . . . . . . . . . . . 7 63 4.3. How to identify a language . . . . . . . . . . . . . . . 8 64 4.4. Considerations for language negotiation . . . . . . . . . 8 65 4.5. Default language . . . . . . . . . . . . . . . . . . . . 9 66 5. Locale . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6. Documenting Internationalization Decisions . . . . . . . . . 9 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 71 10. Informative References . . . . . . . . . . . . . . . . . . . 10 72 Appendix A. Version History . . . . . . . . . . . . . . . . . . 12 73 A.1. 00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 76 1. Introduction 78 The Internet is international. 80 With the international Internet follows an absolute requirement to 81 interchange data in a multiplicity of languages, which in turn 82 utilize a bewildering number of characters. 84 The document is very much based upon RFC 2277 [RFC2277] which is the 85 current policy being applied by the Internet Engineering Steering 86 Group (IESG) towards the standardization efforts in the Internet 87 Engineering Task Force (IETF) in order to help Internet protocols 88 fulfill these requirements. 90 RFC 2277 in turn was based on the recommendations of the IAB 91 Character Set Workshop of February 29-March 1, 1996, which is 92 documented in RFC 2130 [RFC2130]. This document is a proposed 93 replacement for RFC 2277 and attempts to be explicit and clear, and 94 as concise as possible without leaving out necessary detail.[[CREF1: 95 What other references do we want to add? --ajs@anvilwalrusden.com]] 97 1.1. Terminology 99 This document uses the terms "character", "charset", "coded character 100 set", "language", "locale", and "protocol elements" as defined in RFC 101 6365 [RFC6365]. IDNA terminology is defined in RFC 5890 [RFC5890]. 102 Any of those definitions may be used below, and the reader is 103 expected to be familiar with them. [[CREF2: That last sentence makes 104 this document much less accessible. I think at a minimum we need to 105 list which terms used in this document are defined in each other RFC. 106 I've now added a list above for 6365, but it may be missing some and 107 the list of terms used from 5890 is needed. 108 --dthaler@microsoft.com]][[CREF3: This is fair. I suggest we leave 109 this as is and do an exhaustive pass for terminology later and 110 updates these lists. --ajs@anvilwalrusden.com]] 112 This document uses the terms 'MUST', 'SHOULD' and 'MAY', and their 113 negatives, in the way described in RFC 2119 [RFC2119]. In this case, 114 'the specification' as used by RFC 2119 refers to the processing of 115 protocols being submitted to the IETF standards process. 117 2. Where to do internationalization 119 Internationalization is necessary because of the way natural language 120 is written. It enables localization, which is for humans. This 121 means that protocols are not subject to internationalization; text 122 strings are. Where protocol elements look like text tokens, such as 123 in many IETF application layer protocols, protocols MUST specify 124 which parts are protocol and which are text (see Section 2.2.1.1 of 125 [RFC2130]). 127 It is helpful to distinguish among four different types of strings 128 for these purposes: domain names whether in the DNS or not, other 129 protocol elements that are not normally visible to users, other 130 protocol elements that are (even sometimes) normally visible to 131 users, and data (in most cases, the protocol payload). 133 2.1. Domain names 135 Domain names (or strings of domain-name-like things) are used in a 136 number of protocols, and not all of those names are intended to be 137 looked up in the DNS. This raises a number of issues explored at 138 length in [RFC6055]. 140 Given this state of affairs, it is possible to recommend the 141 following. These recommendations are consistent with RFC 6055: 143 o At resolution time, names that are to be looked up in the global 144 DNS SHOULD be transmitted as A-labels. 146 o At resolution time, names that are not to be looked up in the 147 global DNS ought to be transmitted in the form appropriate to the 148 name resolution protocol. This is often UTF-8. 150 o Storage of internationalized domain names ought generally to be in 151 the form of U-labels. 153 o Any protocol that needs to use domain names ought to use U-labels 154 or A-labels consistently, and ought to prefer U-labels. 156 o Storage of U-labels (or putative U-labels) should be in the 157 encoding form appropriate to the context. For instance, on a 158 system that normally encodes UTF-8 using NFD, that is how the 159 strings should be stored; similarly, a system that uses UTF-16 160 should store the strings in that form. 162 [[CREF4: This in the end will need to be checked carefully for its 163 consistency with 6055. --ajs@anvilwalrusden.com]] 165 2.2. Non-DNS, "invisible" protocol elements 167 Many protocols include elements that are either words or word-like in 168 some natural language (usually English), but that are never exposed 169 to users under normal circumstances. Users might encounter these 170 protocol elements in log messages and so on, and system 171 administrators might regularly encounter them as part of the ordinary 172 support burden. But these elements are no more candidates for 173 internationalization than are hexadecimal protocol parameters. 174 Because they are not intended for user consumption, they should not 175 be treated as any part of a user interface. Internationalization 176 considerations do not apply to them. 178 It is important to recognize that some of this class of protocol 179 element sometimes appears to be exposed to users -- for instance, 180 many user agents for mail display headers. In these cases, it is 181 important to distinguish between the protocol element itself, and the 182 user cues it may provide. The protocol element does not need to be 183 internationalized. The user interface might. In general, it is best 184 to internationalize (or localize) strings that are encountered by the 185 user and to keep those that are passed between computer systems and 186 interpreted by them as simple and unambiguous as possible. Even for 187 names or strings that provide the underpinnings for the strings that 188 users type or with which they interact, it is important to keep their 189 forms as simple as possible. Examples of such strings include the 190 results of a search or material that must be translated into several 191 different languages. 193 2.3. Non-DNS, "visible" protocol elements 195 Sometimes, protocol elements are expected to be visible or, as 196 likely, manipulable by users. [[CREF5: Sorry, the following bit 197 needs some more references, which I've failed to get right in the 198 interests of expediency. This is here to remind me. 199 --ajs@anvilwalrusden.com]] For instance, many values of SMTP 200 [RFC5321] commands are parts of mail addresses that users are 201 expected to type. In the presence of EAI, those addresses may well 202 be internationalized. 204 In general, there are two ways to handle these sorts of strings. One 205 is to use an ASCII-compatible encoding in the way that IDNA does. 206 Another is to internationalize the protocol. If an internationalized 207 protocol is to be undertaken, agility among coded character sets 208 appears to cause more problems than it solves. Therefore, for the 209 purposes of transmission, it is best to transmit protocol elements as 210 UTF-8 strings in "Net-Unicode" [RFC5198] form, with an appropriate 211 profile. All ASCII-only strings meet this criterion. [[CREF6: Maybe 212 the profile stuff needs to refer to PRECIS anyway. 213 --ajs@anvilwalrusden]] 215 Merely requiring Net-Unicode is not enough. The PRECIS working group 216 documents outline a number of considerations for how protocol 217 elements and data need to be handled in the face of 218 internationalization concerns. These kinds of considerations are 219 especially important for protocol elements that may be influenced by 220 user action. For instance, if comparisons are to be used, good 221 PRECIS profiles for those elements are critical. 223 In the design of protocols for use on the Internet (or in other 224 communications systems) that use textual keywords, there is a 225 tradeoff between strings that have high mnemonic value (i.e., the 226 identifiers are easily remembered by those who will use them) in 227 local environments and those that are easily recognized and used 228 internationally. Most cases are (and should be) resolved in favor of 229 the latter, because these are strings used in protocols, a single set 230 can easily be translated, and because it is possible to choose a 231 single well-known script with good properties for those strings. But 232 there are cases when other considerations are more important and each 233 case and protocol should be carefully and separately considered. 234 [[CREF7: I think I'd remove the last of those sentences unless we 235 want to say when. --ajs@anvilwalrusden.com]] 237 2.4. Protocol data 239 Protocol data is very frequently user visible, and to the extent 240 there are highly variable internationalization principles, they 241 appear more commonly here. 243 In general, protocol data needs to carry an indicator of its coded 244 character set. A protocol MUST identify, for all character data, 245 which coded character set is in use. Protocols MUST be able to use 246 UTF-8. New protocols SHOULD use UTF-8, and UTF-8 only, unless strong 247 motivation is given for exceptions. The identification methods 248 discussed in this section are for use with legacy protocols and 249 situations. 251 NOTE: In the protocol stack for any given application, there is 252 usually one or a few layers that need to address these problems. 254 It would, for instance, not be appropriate to define language tags 255 for Ethernet frames. It is the responsibility of protocol designers 256 to ensure that whenever responsibility for internationalization is 257 left to "another layer", those responsible for that layer are in fact 258 aware that they have that responsibility. The precis framework 259 provides more guidance. [[CREF8: Surely this is too hand-wavy? 260 Should we refer to particular bits? --ajs]] 262 3. General charset policy 264 The general policy of the IETF is that all data should be transmitted 265 on the wire as UTF-8. Any protocol that does not conform to this 266 policy but that is intended for the IETF standards track MUST justify 267 it to the IETF. 269 When the protocol allows a choice of multiple charsets, someone must 270 make a decision on which charset to use. 272 In some cases, like HTTP, there is direct or semi-direct 273 communication between the producer and the consumer of data 274 containing text. In such cases, it may make sense to negotiate a 275 charset before sending data. 277 In other cases, like E-mail or stored data, there is no such 278 communication, and the best one can do is to make sure the charset is 279 clearly identified with the stored data, and choosing a charset that 280 is as widely known as possible. 282 Note that a charset is an absolute; text that is encoded in a charset 283 cannot be rendered comprehensibly without supporting that charset. 285 This also applies to English texts; charsets like EBCDIC do NOT have 286 ASCII as a proper subset. 288 Negotiating a charset may be regarded as an interim mechanism that is 289 to be supported until support for interchange of UTF-8 is prevalent. 290 Despite the wide adoption of Unicode and UTF-8, the timeframe of 291 "interim" may remain long, though perhaps not permanent. 293 4. Languages 295 4.1. The need for language information 297 All human-readable text has a language. 299 Many operations, including high quality formatting, text-to-speech 300 synthesis, searching, hyphenation, spellchecking and so on benefit 301 greatly from, or are all but impossible without, access to 302 information about the language of a piece of text (Section 3.1.1.4 of 303 [RFC2130]). 305 Humans have some tolerance for foreign languages, but are generally 306 very unhappy with being presented text in a language they do not 307 understand; this is why negotiation, or at least negotiation, of 308 language is needed. 310 In most cases, machines will not be able to deduce the language of a 311 transmitted text by themselves; the protocol must specify how to 312 transfer the language information if it is to be available at all. 313 It is sometimes possible to guess the langage of a block of text, but 314 such guessing is usually unreliable and becomes dramatically less 315 reliable the shorter the block of text. 317 4.2. Requirement for language tagging 319 Protocols that transfer text MUST provide for carrying information 320 about the language of that text. 322 Protocols SHOULD also provide for carrying language information about 323 visible protocol elements (especially if they are names), where 324 appropriate. 326 Note that this does not mean that such information must always be 327 present; the requirement is that if the sender of information wishes 328 to send information about the language of a text, the protocol 329 provides a well-defined way to carry this information. Nevertheless, 330 if the data originator does not supply that information, it is 331 generally impossible to make it up later. 333 4.3. How to identify a language 335 The language tag [RFC5646] is at the moment the most flexible tool 336 available for identifying a language; protocols SHOULD use this, or 337 provide clear and solid justification for doing otherwise in the 338 document. Language tags are in general not useful without profiling 339 appropriate to the case, and there is significant danger of over- 340 specification with tags. See Section 4.1 of RFC 5646. 342 Note also that a language is distinct from a POSIX locale (see 343 Section 5); a POSIX locale identifies a set of cultural conventions, 344 which may imply a language (the "POSIX" and "C" locales of course do 345 not), while a language tag identifies only a language. 347 4.4. Considerations for language negotiation 349 Protocols where users have text presented to them in response to user 350 actions MUST provide for support of multiple languages. 352 How this is done will vary between protocols; for instance, in some 353 cases, a negotiation where the client proposes a set of languages and 354 the server replies with one is appropriate; in other cases, a server 355 may choose to send multiple variants of a text and let the client 356 pick which one to display. 358 Negotiation is useful in the case where one side of the protocol 359 exchange is able to present text in multiple languages to the other 360 side, and the other side has a preference for one of these; the most 361 common example is the text part of error responses, or Web pages that 362 are available in multiple languages. 364 Users do not, of course, actually use protocols, but instead user 365 interfaces that in turn use the protocols. Therefore, what is 366 necessary to support is not the full internationalization of 367 everything in the protocol, but enough that the user-visible 368 components can be localized appropriately. See Section 2.3. 370 Negotiating a language should be regarded as a permanent requirement 371 of the protocol that will not go away at any time in the future. 373 In many cases, it should be possible to include it as part of the 374 connection establishment, together with authentication and other 375 preferences negotiation. 377 4.5. Default language 379 For the purposes of display, it may be necessary to pick a default 380 language to use when it is not possible to determine the language. 381 It is evident that picking a default may lead to user dissatisfaction 382 or confusion, but when language cannot be determined such fallbacks 383 may be necessary. 385 Section 4.1 of [RFC5646], numbers 5 and 7, outline the considerations 386 for language identification when the language cannot be determined. 388 5. Locale 390 The POSIX standard [ISO.9945-2.1993] defines a concept called a 391 "locale", which includes a lot of information about collating order 392 for sorting, date format, currency format and so on. 394 In some cases, and especially with text where the user is expected to 395 do processing on the text, locale information may be usefully 396 attached to the text; this would identify the sender's opinion about 397 appropriate rules to follow when processing the document, which the 398 recipient may choose to agree with or ignore. 400 This document does not require the communication of locale 401 information on all text, but encourages its inclusion when 402 appropriate. 404 Note that language and character set information will often be 405 present as parts of a locale tag (such as no_NO.iso-8859-1; the 406 language is before the underscore and the character set is after the 407 dot); care must be taken to define precisely which specification of 408 character set and language applies to any one text item. 410 The default locale is the "POSIX" locale. 412 6. Documenting Internationalization Decisions 414 In documents that deal with internationalization issues at all, a 415 synopsis of the approaches chosen for internationalization SHOULD be 416 collected into a section called "Internationalization 417 considerations". This practice has historically not been followed 418 regularly, but it remains a good idea. The goal is to provide an 419 easy reference for those who are looking for advice on these issues 420 when implementing the protocol. 422 7. Security Considerations 424 Security warnings in a foreign language may cause inappropriate 425 behaviour (such as ignoring the warning entirely) from the user. In 426 addition, the issues raised in [RFC6943], especially in its section 427 4.2 and section 5, are of particular relevance to 428 internationalization. 430 8. Acknowledgements 432 Much of the text comes from [RFC2277]. Harald Alvestrand was the 433 primary author of that RFC. 435 Most of the discussion above was initiated as part of the IAB's 436 internationalization program. At the time of writing, the program 437 members were (in alphabetical order) Marc Blanchet, Stuart Cheshire, 438 Leslie Daigle, Patrik Faltstrom, Heather Flanagan, John Klensin, Olaf 439 Kolkman, Barry Leiba, Xing Li, Pete Resnick, Peter Saint-Andre, 440 Andrew Sullivan, and Dave Thaler. 442 Significant text in Section 2.2 and Section 2.3 was derived from a 443 forthcoming Internet Society education module for next-generation 444 Internet leaders and future influencers and used with permission. 445 The contributions and support for that work of Toral Cowleson and 446 Niel Harper of the Internet Society are gratefully acknowledged. 448 9. IANA Considerations 450 This document makes no requests of IANA. 452 10. Informative References 454 [ISO.10646-1.1993] 455 International Organization for Standardization, 456 "Information Technology - Universal Multiple-octet coded 457 Character Set (UCS) - Part 1: Architecture and Basic 458 Multilingual Plane", ISO Standard 10646-1, May 1993. 460 [ISO.9945-2.1993] 461 International Organization for Standardization, "ISO/IEC 462 9945-2:1993 Information Technology -- Portable Operating 463 System Interface (POSIX) -- Part 2: Shell and Utilities", 464 ISO Standard 9945-2, 1993. 466 [RFC1033] Lottor, M., "Domain administrators operations guide", RFC 467 1033, November 1987. 469 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 470 STD 13, RFC 1034, November 1987. 472 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 473 3", BCP 9, RFC 2026, October 1996. 475 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 476 Requirement Levels", BCP 14, RFC 2119, March 1997. 478 [RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., 479 Atkinson, R., Crispin, M., and P. Svanberg, "The Report of 480 the IAB Character Set Workshop held 29 February - 1 March, 481 1996", RFC 2130, April 1997. 483 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 484 Specification", RFC 2181, July 1997. 486 [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and 487 Languages", BCP 18, RFC 2277, January 1998. 489 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 490 10646", STD 63, RFC 3629, November 2003. 492 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 493 Interchange", RFC 5198, March 2008. 495 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 496 October 2008. 498 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 499 Languages", BCP 47, RFC 5646, September 2009. 501 [RFC5890] Klensin, J., "Internationalized Domain Names for 502 Applications (IDNA): Definitions and Document Framework", 503 RFC 5890, August 2010. 505 [RFC5891] Klensin, J., "Internationalized Domain Names in 506 Applications (IDNA): Protocol", RFC 5891, August 2010. 508 [RFC5892] Faltstrom, P., "The Unicode Code Points and 509 Internationalized Domain Names for Applications (IDNA)", 510 RFC 5892, August 2010. 512 [RFC5893] Alvestrand, H. and C. Karp, "Right-to-Left Scripts for 513 Internationalized Domain Names for Applications (IDNA)", 514 RFC 5893, August 2010. 516 [RFC5894] Klensin, J., "Internationalized Domain Names for 517 Applications (IDNA): Background, Explanation, and 518 Rationale", RFC 5894, August 2010. 520 [RFC5895] Resnick, P. and P. Hoffman, "Mapping Characters for 521 Internationalized Domain Names in Applications (IDNA) 522 2008", RFC 5895, September 2010. 524 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 525 Encodings for Internationalized Domain Names", RFC 6055, 526 February 2011. 528 [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in 529 Internationalization in the IETF", BCP 166, RFC 6365, 530 September 2011. 532 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 533 February 2013. 535 [RFC6943] Thaler, D., "Issues in Identifier Comparison for Security 536 Purposes", RFC 6943, May 2013. 538 Appendix A. Version History 540 A.1. 00 542 Initial version. Contains a number of xml2rfc warnings. 544 Authors' Addresses 546 Andrew Sullivan 547 Dyn 548 150 Dow St. 549 Manchester, NH 03101 550 U.S.A. 552 Email: asullivan@dyn.com 554 Dave Thaler 555 Microsoft Corporation 556 One Microsoft Way 557 Redmonad, WA 98052 558 USA 560 Phone: +1 425 703 8835 561 Email: dthaler@microsoft.com 562 John C Klensin 563 1770 Massachusetts Ave, Ste 322 564 Cambridge, MA 02140 565 USA 567 Phone: +1 617 245 1457 568 Email: john-ietf@jck.com