idnits 2.17.1 draft-ietf-eai-downgraded-display-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 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 (December 1, 2009) is 5259 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 4952 (Obsoleted by RFC 6530) ** Obsolete normative reference: RFC 5335 (Obsoleted by RFC 6532) ** Obsolete normative reference: RFC 5504 (Obsoleted by RFC 6530) -- Obsolete informational reference (is this intentional?): RFC 5336 (Obsoleted by RFC 6531) -- Obsolete informational reference (is this intentional?): RFC 5337 (Obsoleted by RFC 6533) Summary: 4 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Email Address Internationalization K. Fujiwara 3 (EAI) JPRS 4 Internet-Draft B. Leiba 5 Intended status: Experimental Huawei Technologies 6 Expires: June 4, 2010 December 1, 2009 8 Displaying Downgraded Messages for Email Address Internationalization 9 draft-ietf-eai-downgraded-display-03.txt 11 Abstract 13 This document describes a method for displaying downgraded messages 14 which originally contained internationalized E-mail addresses or 15 internationalized header fields. 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on June 4, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Converting downgraded message headers for display . . . . . . 3 60 3.1. Considerations . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. The process . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.2.1. No reconstruction of the Envelope Information 63 Preservation Header Fields . . . . . . . . . . . . . . 4 64 3.2.2. Reconstructing the Address Header Fields' 65 Preservation Header Fields . . . . . . . . . . . . . . 4 66 3.2.3. The Unknown Header Fields' Preservation Header 67 Fields . . . . . . . . . . . . . . . . . . . . . . . . 5 68 4. Security considerations . . . . . . . . . . . . . . . . . . . 6 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 71 7. Change History . . . . . . . . . . . . . . . . . . . . . . . . 6 72 7.1. draft-fujiwara-eai-downgraded-display: Version 00 . . . . 7 73 7.2. draft-ietf-eai-downgraded-display: Version 00 . . . . . . 7 74 7.3. draft-ietf-eai-downgraded-display: Version 01 . . . . . . 7 75 7.4. draft-ietf-eai-downgraded-display: Version 02 . . . . . . 7 76 7.5. draft-ietf-eai-downgraded-display: Version 03 . . . . . . 7 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 80 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 8 81 A.1. Displaying example . . . . . . . . . . . . . . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 The Email Address Internationalization (UTF8SMTP) extension document 87 set [RFC4952] [RFC5336] [RFC5335] [RFC5337] expands Email address 88 structure, syntax and Email header format. To avoid rejection of 89 internationalized Email messages, the downgrading mechanism [RFC5504] 90 converts an internationalized message to a traditional Email message 91 when a server in the delivery path does not support the UTF8SMTP 92 extension. The downgraded message is a traditional Email message, 93 except the message has "Downgraded-" header fields. 95 A perfect reverse-function of the downgrading does not exist because 96 the encoding defined in [RFC2047] is not exactly reversible and 97 Received header field downgrading may remove FOR clause information. 98 The restoration of the downgrading should be done once at the final 99 destination of the downgraded message such as MUAs or IMAP servers. 100 This document describes the restoration methods for displaying 101 downgraded messages in MUAs. 103 2. Terminology 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in RFC 2119 [RFC2119]. 109 Specialized terms used in this specification are defined in the EAI 110 overview [RFC4952] or in [RFC5321][RFC5322], MIME documents [RFC2045] 111 [RFC2047] [RFC2183] [RFC2231]. 113 This document depends on [RFC5335] and [RFC5504]. Key words used in 114 these document are used in this document, too. 116 The term "MIME decode" is used for both "encoded-word" decoding 117 defined by [RFC2047] and MIME parameter value decoding defined by 118 [RFC2231]. 120 3. Converting downgraded message headers for display 122 3.1. Considerations 124 The order of some header fields (such as "Resent-*" fields) is 125 significant. The process of regenerating the original fields from 126 the downgraded ones MUST NOT reorder the fields. 128 In order to regenerate a field from a specific downgraded header 129 field, it's necessary to find the corresponding replacement in the 130 current message. If the corresponding field can not be found, the 131 downgraded header field in question can not be regenerated and used. 133 3.2. The process 135 A MUA MAY decode and re-generate the original header fields of the 136 message (MTAs and MDAs SHOULD NOT attempt to do this; it SHOULD be 137 left to the MUA). This procedure can be used to approximately 138 reverse the Downgrade process, but it will not always construct the 139 original header fields exactly. 141 Three types of Downgraded header fields are described in section 3 of 142 [RFC5504]: 143 1. "Envelope Information Preservation Header Fields", described in 144 RFC5504 section 3.1 and in Section 3.2.1, below. 145 2. "Address Header Fields' Preservation Header Fields", described in 146 RFC5504 section 3.2 and in Section 3.2.2, below. 147 3. "Unknown Header Fields' Preservation Header Fields", described in 148 RFC5504 section 3.3 and in Section 3.2.3, below. 150 After processing Downgraded header fields, decode all header fields, 151 as described in [RFC2047] and [RFC2231]. 153 3.2.1. No reconstruction of the Envelope Information Preservation 154 Header Fields 156 Envelope Information Preservation Header Fields are new fields that 157 might have been added by the downgrade process. Because they do not 158 represent fields that appeared in the original message, this process 159 is not applicable to them. 161 3.2.2. Reconstructing the Address Header Fields' Preservation Header 162 Fields 164 Reconstructing Address Header Fields' Preservation Header Fields is 165 OPTIONAL, and a decision MAY be made on each field, individually. In 166 particular, it might be less important to process the Resent-* header 167 fields, so an implementation MAY choose to skip those. 169 To construct a displayable copy of a header field from one of these 170 downgraded header fields, follow this procedure: 171 1. In an edit buffer, create a new header field:" 172 1a. For the field name, remove the "Downgraded-" prefix from the 173 downgraded field name. For example, "Downgraded-From" becomes 174 "From", and "Downgraded-Resent-To" becomes "Resent-To". 176 1b. For the field value, decode the MIME-encoded value of the 177 downgraded field according to [RFC2047]. 178 2. If the header field is one that can only appear once, according 179 to the table in [RFC5322] section 3.6 ("From", "Sender", "To", 180 "CC", "BCC", "Reply-To"), locate the corresponding field in the 181 message's headers, and skip to step 9. Otherwise, continue with 182 step 3. 183 3. Apply "Email Header Fields Downgrading", defined in section 5 of 184 [RFC5504], to the field in the edit buffer, but do not prepend the 185 "Downgraded-" prefix. Put the result into comparison buffer 1. 186 4. Canonicalize the header fields in the comparison buffer: 187 1. Unfold all header field continuation lines as described in 188 [RFC5322]. 189 2. Ensure that there is one space character before and one after 190 the separator ",". If a space character is 191 missing, insert one. 192 3. Ensure that there is one space character before and one after 193 each . If a space character is missing, insert one. 194 4. Decode each whose charset is "UTF-8". 195 5. Convert all sequences of one or more WSP characters to a 196 single space character. WSP characters here include those 197 before and after a line-folding boundary. 198 6. Delete all WSP characters at the end of each unfolded header 199 field value. 200 7. Delete any WSP characters remaining before and after the colon 201 separating the header field name from the header field value, 202 retaining the colon separator. 203 5. Locate the first instance of the corresponding field in the 204 message's headers. 205 6. Canonicalize the located field as in step 4, and put the result 206 into comparison buffer 2. 207 7. Compare the header field in comparison buffer 1 with the header 208 field in comparison buffer 2. If they match, go to step 9. 209 8. Locate the next instance of the corresponding field in the 210 message's headers. If one is found, go to step 6. If none is 211 found, stop: you can not use this downgraded field because you 212 can't find its replacement in the message. 213 9. Replace the located header field with the one in the edit 214 buffer. You MUST NOT reorder the header fields when you do this; 215 it's important to replace the field in place. 217 3.2.3. The Unknown Header Fields' Preservation Header Fields 219 The Unknown Header Fields' Preservation Header Fields SHOULD be left 220 as they are unless the MUA has special knowledge of a particular 221 field. An MUA with such knowledge MAY use the procedure in 222 Section 3.2.2, above, for those fields that it knows about. 224 4. Security considerations 226 While information in any email header should usually be treated with 227 some suspicion, current email systems commonly employ various 228 mechanisms and protocols to make the information more trustworthy. 229 For example, an organization's boundary MTA can modify "From:" lines 230 so that messages arriving from outside the organization are easily 231 distinguishable from internal emails. As a result of that rewriting, 232 it might not be possible to reconstruct the "Downgraded-From" header 233 field. 235 A MUA MAY emphasize bogus or broken Address Header Fields' 236 Preservation Header Fields found in step 8 of Section 3.2.2. 238 Hiding the information from the actual header fields when using the 239 "Downgraded-" header fields does not cause loss of information if 240 generating MIME decoded header fields in step 1 of Section 3.2.2 and 241 the comparison done in step 8 are successful. To ensure that no 242 information is lost, a MUA SHOULD have a function that uses the 243 actual message that was received (with/without MIME decoding) to 244 render the message. 246 See "Security considerations" section in [RFC5504] and [RFC4952] for 247 more discussion. 249 5. IANA Considerations 251 This document makes no requests for IANA action. This section can be 252 removed by the RFC Editor before publication. 254 6. Acknowledgements 256 This document was separated from [RFC5504]. Both documents were 257 developed in the EAI WG. Significant comments and suggestions were 258 received from John Klensin, Harald Alvestrand, Chris Newman, Randall 259 Gellens, Charles Lindsey, Marcos Sanz, Alexey Melnikov, Pasi Eronen, 260 Frank Ellermann, Edward Lewis, S. Moonesamy and JET members. 262 7. Change History 264 This section is used for tracking the update of this document. Will 265 be removed after finalize. 267 7.1. draft-fujiwara-eai-downgraded-display: Version 00 269 o Initial version 270 o It is separated from Appendix A of draft-ietf-eai-downgrade-05.txt 272 7.2. draft-ietf-eai-downgraded-display: Version 00 274 o Submitted as a working group draft 276 7.3. draft-ietf-eai-downgraded-display: Version 01 278 o Prohibited and removed Displaying Technique 1 279 o Added new texts to Security Considerations 281 7.4. draft-ietf-eai-downgraded-display: Version 02 283 o updated by comments from Chair's review and AD's review 284 o Fixed references 285 o Rewrote section 4 to be more comprehensible 286 o Added bogus or broken "Downgraded-" header fields 287 o Added sentences in Security considerations 289 7.5. draft-ietf-eai-downgraded-display: Version 03 291 o Section 3 (formerly 3 and 4) was rewritten by Barry Leiba. 293 8. References 295 8.1. Normative References 297 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 298 Extensions (MIME) Part One: Format of Internet Message 299 Bodies", RFC 2045, November 1996. 301 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 302 Part Three: Message Header Extensions for Non-ASCII Text", 303 RFC 2047, November 1996. 305 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 306 Requirement Levels", BCP 14, RFC 2119, March 1997. 308 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating 309 Presentation Information in Internet Messages: The 310 Content-Disposition Header Field", RFC 2183, August 1997. 312 [RFC2231] Freed, N. and K. Moore, "MIME Parameter Value and Encoded 313 Word Extensions: 315 Character Sets, Languages, and Continuations", RFC 2231, 316 November 1997. 318 [RFC4952] Klensin, J. and Y. Ko, "Overview and Framework for 319 Internationalized Email", RFC 4952, July 2007. 321 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, 322 October 2008. 324 [RFC5335] Abel, Y., "Internationalized Email Headers", RFC 5335, 325 September 2008. 327 [RFC5504] Fujiwara, K. and Y. Yoneya, "Downgrading Mechanism for 328 Email Address Internationalization", RFC 5504, March 2009. 330 8.2. Informative References 332 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 333 October 2008. 335 [RFC5336] Yao, J. and W. Mao, "SMTP Extension for Internationalized 336 Email Addresses", RFC 5336, September 2008. 338 [RFC5337] Newman, C. and A. Melnikov, "Internationalized Delivery 339 Status and Disposition Notifications", RFC 5337, 340 September 2008. 342 Appendix A. Examples 344 This section shows a example of displaying a downgraded message. 345 First, an example of the original UTF8SMTP message and its downgraded 346 message are shown. The example comes from "Example 1" of [RFC5504] 347 and three header fields, "Unknown-Field", "Resent-From", and 348 "Resent-To", are added. The example UTF8SMTP message is shown in 349 Figure 1. 351 Message-Id: MESSAGE_ID 352 Mime-Version: 1.0 353 Content-Type: text/plain; charset="UTF-8" 354 Content-Transfer-Encoding: 8bit 355 Subject: NON-ASCII-SUBJECT 356 Unknown-Field: NON-ASCII-Unknown 357 From: DISPLAY-local > 359 To: DISPLAY-remote1 > 361 Cc: DISPLAY-remote2 362 Resent-From: DISPLAY-remote1 > 364 Resent-To: DISPLAY-reto > 366 Date: DATE 368 MAIL_BODY 370 Figure 1: Original message 372 Delivered downgraded message is shown in Figure 2. Return-Path 373 header will be added by the final destination MTA. Some of Received: 374 header fields may be added. 376 Return-Path: 377 Received: ... 378 Downgraded-Mail-From: =?UTF-8?Q?>?= 380 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 382 Message-Id: MESSAGE_ID 383 Mime-Version: 1.0 384 Content-Type: text/plain; charset="UTF-8" 385 Content-Transfer-Encoding: 8bit 386 Subject: =?UTF-8?Q?NON-ASCII-SUBJECT?= 387 Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?= 388 From: =?UTF-8?Q?DISPLAY-local?= 389 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 391 To: =?UTF-8?Q?DISPLAY-remote1?= 392 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 393 =?UTF-8?Q?>?= 394 Cc: =?UTF-8?Q?DISPLAY-remote2?= Internationalized address 395 =?UTF-8?Q?NON-ASCII-remote2@example.org?= removed:; 396 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 397 =?UTF-8?Q??= 398 Resent-From: =?UTF-8?Q?DISPLAY-remote1?= 399 Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?= 400 =?UTF-8?Q?>?= 401 Resent-To: =?UTF-8?Q?DISPLAY-reto?= 402 Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?= 403 =?UTF-8?Q?>?= 404 Date: DATE 406 MAIL_BODY 408 Figure 2: Downgraded message 410 Figure 3 shows MIME decoded message of Figure 2. The recipient can 411 read the original From, To, Cc and Unknown-Field header fields as 412 Downgraded-From, Downgraded-To, Downgraded-Cc and Downgraded-Unknown- 413 Field header fields. 415 Return-Path: 416 Received: ... 417 Downgraded-Mail-From: > 419 Downgraded-Rcpt-To: > 421 Message-Id: MESSAGE_ID 422 Mime-Version: 1.0 423 Content-Type: text/plain; charset="UTF-8" 424 Content-Transfer-Encoding: 8bit 425 Subject: NON-ASCII-SUBJECT 426 Downgraded-Unknown-Field: NON-ASCII-Unknown 427 From: DISPLAY-local 428 Downgraded-From: DISPLAY-local > 430 To: DISPLAY-remote1 431 Downgraded-To: DISPLAY-remote1 > 433 Cc: DISPLAY-remote2 Internationalized address 434 NON-ASCII-remote2@example.org removed:; 435 Downgraded-Cc: DISPLAY-remote2 436 Resent-From: DISPLAY-remote1 437 Downgraded-Resent-From: DISPLAY-remote1 438 > 439 Resent-To: DISPLAY-reto 440 Downgraded-Resent-To: DISPLAY-reto 441 > 442 Date: DATE 444 MAIL_BODY 446 Figure 3: MIME decoded message 448 A.1. Displaying example 450 This example shows how to display the message in Figure 2, above, 451 using the process defined in Section 3. For simplicity, we will show 452 the reconstruction of all the applicable fields at once. 454 Selecting all Downgraded-* fields gives this: 456 Downgraded-Mail-From: =?UTF-8?Q?>?= 458 Downgraded-Rcpt-To: =?UTF-8?Q?>?= 460 Downgraded-Unknown-Field: =?UTF-8?Q?NON-ASCII-Unknown?= 461 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 463 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 464 =?UTF-8?Q?>?= 465 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 466 =?UTF-8?Q??= 467 Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?= 468 =?UTF-8?Q?>?= 469 Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?= 470 =?UTF-8?Q?>?= 472 Figure 4: Downgraded header fields 474 Two of the fields, Downgraded-Mail-From and Downgraded-Rcpt-To, are 475 Envelope Information Preservation Header Fields, and will not be 476 reconstructed. One field, Downgraded-Unknown-Field, is an Unknown 477 Header Fields' Preservation Header Field, and will also not be 478 reconstructed. That leaves these to be reconstructed, the Address 479 Header Fields' Preservation Header Fields: 481 Downgraded-From: =?UTF-8?Q?DISPLAY-local_>?= 483 Downgraded-To: =?UTF-8?Q?DISPLAY-remote1_?= 484 =?UTF-8?Q?>?= 485 Downgraded-Cc: =?UTF-8?Q?DISPLAY-remote2_?= 486 =?UTF-8?Q??= 487 Downgraded-Resent-From: =?UTF-8?Q?DISPLAY-remote1_?= 488 =?UTF-8?Q?>?= 489 Downgraded-Resent-To: =?UTF-8?Q?DISPLAY-reto_?= 490 =?UTF-8?Q?>?= 491 Figure 5: Header fields for the reconstruction 493 Now, perform Step 1, creating temporary fields. 495 From: DISPLAY-local > 497 To: DISPLAY-remote1 > 499 Cc: DISPLAY-remote2 500 Resent-From: DISPLAY-remote1 501 > 502 Resent-To: DISPLAY-reto 503 > 505 Figure 6: Output of Step 1 507 In step 2, we set aside the "From", "To", and "Cc" fields, and 508 continue to step 3 with just "Resent-From" and "Resent-To" (the 509 fields that may appear more than once). The fields we set aside will 510 be picked up again later, in step 9. 512 Perform Steps 3 and 4. The edit buffer contains re-generated ASCII 513 header fields, canonicalized. 515 Resent-From: =?UTF-8?Q?DISPLAY-remote1?= 516 Resent-To: =?UTF-8?Q?DISPLAY-reto?= 518 Figure 7: The edit buffer (output of Step 4) 520 Perform Steps 5 to 7, comparison, for each header field. Both the 521 Resent-From and Resent-To fields will match, and we will proceed to 522 step 9. (Step 8, iteration, does not apply in this example. 524 Perform step 9, replacing all applicable fields, without changing the 525 order. Then do MIME decoding on everything, for display. 527 Return-Path: 528 Received: ... 529 Downgraded-Mail-From: > 531 Downgraded-Rcpt-To: 532 533 Message-Id: MESSAGE_ID 534 Mime-Version: 1.0 535 Content-Type: text/plain; charset="UTF-8" 536 Content-Transfer-Encoding: 8bit 537 Subject: NON-ASCII-SUBJECT 538 Downgraded-Unknown-Field: NON-ASCII-Unknown 539 From: DISPLAY-local > 541 To: DISPLAY-remote1 > 543 Cc: DISPLAY-remote2 544 Resent-From: DISPLAY-remote1 > 546 Resent-To: DISPLAY-reto > 548 Date: DATE 550 Figure 8: The final result 552 As a result, in this simple example, some original header fields are 553 now displayed in their original form. Differences between Figure 1 554 and Figure 8 are Return-Path, Downgraded-Mail-From, 555 Downgraded-Rcpt-To, and Downgraded-Unknown-Field. 557 Authors' Addresses 559 Kazunori Fujiwara 560 Japan Registry Services Co., Ltd. 561 Chiyoda First Bldg. East 13F, 3-8-1 Nishi-Kanda 562 Chiyoda-ku, Tokyo 101-0065 563 Japan 565 Phone: +81-3-5215-8451 566 Email: fujiwara@jprs.co.jp 567 Barry Leiba 568 Huawei Technologies 570 Phone: +1 646 827 0648 571 Email: barryleiba@computer.org 572 URI: http://internetmessagingtechnology.org/