idnits 2.17.1 draft-ietf-fax-service-v2-01.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 101 has weird spacing: '...e using an In...' == Line 102 has weird spacing: '... device using...' == Line 542 has weird spacing: '... in a fil...' == Line 544 has weird spacing: '...int/fax the r...' == Line 545 has weird spacing: '... rather than ...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 821 (ref. '1') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 822 (ref. '2') (Obsoleted by RFC 2822) ** Downref: Normative reference to an Informational RFC: RFC 2306 (ref. '5') ** Obsolete normative reference: RFC 2301 (ref. '6') (Obsoleted by RFC 3949) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2060 (ref. '10') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2303 (ref. '11') (Obsoleted by RFC 3191) ** Obsolete normative reference: RFC 2304 (ref. '12') (Obsoleted by RFC 3192) ** Obsolete normative reference: RFC 2440 (ref. '13') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 1894 (ref. '14') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1891 (ref. '15') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 2401 (ref. '18') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2302 (ref. '19') (Obsoleted by RFC 3302) ** Obsolete normative reference: RFC 2487 (ref. '20') (Obsoleted by RFC 3207) ** Downref: Normative reference to an Historic RFC: RFC 2311 (ref. '21') Summary: 20 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Toyoda 2 Internet Draft H. Ohno 3 June 16, 1999 J. Murai 4 Expires December 1999 WIDE Project 5 draft-ietf-fax-service-v2-01.txt D. Wing 6 Cisco Systems 8 A Simple Mode of Facsimile Using Internet Mail 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 To view the entire list of current Internet-Drafts, please check 30 the "1id-abstracts.txt" listing contained in the Internet-Drafts 31 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net 32 (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au 33 (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu 34 (US West Coast). 36 This draft is a product of the IETF Internet Fax working group. To 37 subscribe to the mailing list, send a message to 38 ietf-fax-request@imc.org with the line "subscribe" in the body of the 39 message. Archives are available from . 41 Copyright Notice 43 Copyright (C) The Internet Society (1999). All Rights Reserved. 45 SUMMARY 47 This specification provides for "simple mode" carriage of facsimile 48 data over the Internet. Extensions to this document will follow. 49 The current specification employs standard protocols and file formats 50 such as TCP/IP, Internet mail protocols [1, 2, 3], MIME [4, 16, 17], 51 and TIFF for Facsimile [5,6,19]. It can send images not only to 52 other Internet-aware facsimile devices but also to Internet-native 53 systems, such as PCs with common email readers which can handle MIME 54 mail and TIFF for Facsimile data. The specification facilitates 55 communication among existing facsimile devices, Internet mail agents, 56 and the gateways which connect them. 58 The IETF has been notified of intellectual property rights claimed in 59 regard to some or all of the specification contained in this 60 document. For more information consult the online list of claimed 61 rights in . 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [7]. 67 1 SCOPE 69 This specification defines a message-based facsimile communication 70 over the Internet. It describes a minimum set of capabilities, 71 taking into account those of typical facsimile devices and PCs that 72 can generate facsimile data. 74 A G3Fax device has substantial restrictions due to specifications in 75 the standards, such as for timers. This specification defines a 76 profile for Internet mail, rather than creating a distinct "facsimile 77 over the Internet" service. The semantics resulting from the profile 78 are designed to be compatible with facsimile operation over the 79 general switched telephone network, so that gateways between 80 facsimile and Internet mail can operate with very high fidelity. 82 The reason for developing this capability as an email profile is to 83 permit interworking amongst facsimile and email users. For example 84 it is intended that existing email users be able to send normal 85 messages to lists of users, including facsimile-based recipients, and 86 that other email recipients shall be able to reply to the original 87 and continue to include facsimile recipients. Similarly it is 88 intended that existing email software work without modification and 89 not be required to process new, or different data structures, beyond 90 what is normal for Internet mail users. Existing email service 91 standards are used, rather than replicating mechanisms which are more 92 tailored to existing facsimile standards, to ensure this 93 compatibility with existing email service. 95 1.1 Services 97 A facsimile-capable device that uses T.4 [8] and the general switched 98 telephone network (GSTN) is called a "G3Fax device" in this 99 specification. An "IFax device" is an Internet- accessible device 100 capable of sending, receiving or forwarding Internet faxes. A 101 message can be sent to an IFax device using an Internet mail 102 address. A message can be sent to a G3Fax device using an Internet 103 mail address; the message MAY be forwarded via an IFax offramp 104 gateway. 106 1.2 Cases 108 This specification provides for communication between each of the 109 following combinations: 110 Internet mail => Network printer 111 Internet mail => Offramp gateway (forward to 112 G3Fax) 113 Network scanner => Network printer 114 Network scanner => Offramp gateway (forward to 115 G3Fax) 116 Network scanner => Internet mail 118 2 COMMUNICATION PROTOCOLS 120 The set of conventions necessary to achieve facsimile- compatible 121 service covers basic data transport, document data formats, message 122 (document) addressing, delivery confirmation, and message security. 123 In this section, the first 4 are covered. The remainder are covered 124 in following sections, along with additional details for addressing 125 and formats. 127 2.1 Transport 129 This section describes mechanisms involved in the transport between 130 IFAX devices. 132 2.1.1 Relay 134 Data transfer MAY be achieved using standard Internet mail transfer 135 mechanisms[1, 3]. The format of addresses MUST conform to the RFC 136 821 and RFC 822 Internet mail standards [1, 2, 137 3]. 139 2.1.2 Gateway 141 A gateway translates between dissimilar environments. For IFax, a 142 gateway connects between Internet mail and the T.4/GSTN facsimile. 143 Gateways can service multiple T.4/GSTN facsimile users or can service 144 only one. In the former case, they serve as a classic "mail transfer 145 agent" (MTA) and in the latter as a classic "mail user agent" (UA). 147 An onramp is a gateway which connects from T.4/GSTN facsimile to 148 Internet mail. An offramp is a gateway which connects from Internet 149 mail to T.4/GSTN facsimile. Behavior of onramps is out of scope for 150 this specification. 152 This specification describes the Internet mail service portion of 153 offramp addressing, confirmation and failure notification. Details 154 are provided in later sections. 156 2.1.3 Mailbox protocols 158 An offramp gateway that operate as an MTA serving multiple users 159 SHOULD use SMTP; a gateway that operates as a UA serving a single 160 mail recipient MAY use a mailbox access protocol such as POP or IMAP 161 [9, 10]. 163 NOTE: An offramp gateway that relays mail based on addressing 164 information needs to ensure that it uses addresses supplied in the 165 MTA envelope, rather than from elsewhere, such as addresses listed in 166 the message content headers. 168 2.2 Formats 170 2.2.1 Headers 172 IFax devices MUST be compliant with RFC 822 and RFC1123, which define 173 the format of mail headers. The header of an IFax message SHOULD 174 include Message-ID and MUST include all fields required by [2, 3], 175 such as DATE and FROM. 177 2.2.2 MIME 179 IFax devices MUST be compliant with MIME [4], except as noted in 180 Appendix A. 182 2.2.3 Content 184 The data format of the facsimile image is based on the minimum set of 185 TIFF for Facsimile[6], also known as the S profile. Such facsimile 186 data are included in a MIME object by use of the image/TIFF sub-type 187 [19]. Additional rules for the use of TIFF for Facsimile, for the 188 message-based Internet facsimile application, are defined later. 190 2.2.4 Multipart 192 A single multi-page document SHOULD be sent as a single multi- page 193 TIFF file, even though recipients MUST process multipart/mixed 194 containing multiple TIFF files. If multipart content is present and 195 processing of any part fails, then processing for the entire message 196 is treated as failing, per [Processing failure] below. 198 2.3 Error Handling 200 2.3.1 Delivery failure 202 This section describes existing requirements for Internet mail, 203 rather than indicating special requirements for IFax devices. 205 In the event of relay failure, the sending relay MUST generate a 206 failure message, which SHOULD be in the format of a DSN. [14,15] 208 NOTE: Internet mail transported via SMTP MUST contain a MAIL 209 FROM address appropriate for delivery of return notices [Also 210 see section 5.2.6]. 212 2.3.2 Processing failure 214 IFax devices with limited capabilities might be unable to process the 215 content of a message. If this occurs it is important to ensure that 216 the message is not lost without any notice. Notice MAY be provided in 217 any appropriate fashion, and the exact handling is a local matter. 218 (Also see Appendix A, second bullet.) 220 3 ADDRESSING 222 3.1 Classic Email Destinations 224 Messages being sent to normal Internet mail recipients will use 225 standard Internet mail addresses, without additional constraints. 227 3.2 G3Fax Devices 229 G3Fax devices are accessed via an IFAX offramp gateway, which 230 performs any authorized telephone dial-up. 232 3.3 Address Formats Used by Offramps 234 When a G3Fax device is identified by a telephone number, the entire 235 address used for the G3fax device, including the number and offramp 236 host reference MUST be contained within standard Internet mail 237 transport fields, such as RCPT TO and MAIL FROM [1, 3]. The address 238 MAY be contained within message content fields, such as 239 and [2, 3], as appropriate. 241 As for all Internet mail addresses, the left-hand-side (local- part) 242 of an address is not to be interpreted except by the MTA that is 243 named on the right-hand-side (domain). 245 The telephone number format SHOULD conform to [11, 12]. Other 246 formats MUST be syntactically distinct from [11, 12]. 248 4 IMAGE FILE FORMAT 250 Sending IFax devices MUST be able to write minimum set TIFF files, 251 per the rules for creating minimum set TIFF files defined in TIFF for 252 Facsimile (the S profile) [6], which is also compatible with the 253 specification for the minimum subset of TIFF-F in [5]. Receiving 254 IFax devices MUST be able to read minimum set TIFF files. 256 A sender SHOULD NOT use TIFF fields and values beyond the minimum 257 subset of TIFF for Facsimile unless the sender has prior knowledge of 258 other TIFF fields or values supported by the recipient. The 259 mechanism for determining capabilities of recipients is beyond the 260 scope of this document. 262 5 SECURITY CONSIDERATIONS 264 5.1 General Directive 266 This specification is based on use of existing Internet mail. To 267 maintain interoperability with Internet mail, any security to be 268 provided should be part of the of the Internet security 269 infrastructure, rather than a new mechanism or some other mechanism 270 outside of the Internet infrastructure. 272 5.2 Threats and Problems 274 Both Internet mail and G3Fax standards and operational services have 275 their own set of threats and countermeasures. This section attends 276 only to the set of additional threats which ensue from integrating 277 the two services. This section reviews relevant concerns about 278 Internet mail for IFax environments, as well as considering the 279 potential problems which can result of integrating the existing G3Fax 280 service with Internet mail. 282 5.2.1 Spoofed sender 284 The actual sender of the message might not be the same as that 285 specified in the Sender or From fields of the message content headers 286 or the MAIL FROM address from the SMTP envelope. 288 In a tightly constrained environment, sufficient physical and 289 software controls may be able to ensure prevention of this problem. 290 The usual solution is through encryption-based authentication, either 291 for the channel or associated with the object, as discussed below. 293 It should be recognized that SMTP implementations do not provide 294 inherent authentication of the senders of messages, nor are sites 295 under obligation to provide such authentication. End-to-end 296 approaches such as S/MIME and PGP/MIME are currently being developed 297 within the IETF. These technologies can provide such authentication. 299 5.2.2 Resources consumed by dialout 301 In addition to the resources normally consumed for email (CPU cycles 302 and disk), offramp facsimile causes an outdial which often imposes 303 significant resource consumption, such as financial cost. Techniques 305 for establishing authorization of the sender are essential to those 306 offramp facsimile services that need to manage such consumption. 308 Due to the consumption of these resources by dialout, unsolicited 309 bulk email which causes an outdial is undesirable. 311 Offramp gateways SHOULD provide the ability to authorize senders in 312 some manner to prevent unauthorized use of the offramp. There are no 313 standard techniques for authorization using Internet protocols. 315 Typical solutions use simple authentication of the originator to 316 establish and verify their identity and then check the identity 317 against a private authorization table. 319 Originator authentication entails the use of weak or strong 320 mechanisms, such as cleartext keywords or encryption-based data- 321 signing, respectively, to determine and validate the identify of the 322 sender and assess permissions accordingly. 324 Other control mechanisms which are common include source filtering 325 and originator authentication. Source filtering entails offramp 326 gateway verification of the host or network originating the message 327 and permitting or prohibiting relaying accordingly. 329 5.2.3 GSTN authorization information 331 Confidential information about the sender necessary to dial a G3Fax 332 recipient, such as sender's calling card authorization number, might 333 be disclosed to the G3Fax recipient (on the cover page), such as 334 through parameters encoded in the G3Fax recipients address in the To: 335 or CC: fields. 337 Senders SHOULD be provided with a method of preventing such 338 disclosure. As with mechanisms for handling unsolicited faxes, there 339 are not yet standard mechanisms for protecting such information. 340 Out-of-band communication of authorization information or use of 341 encrypted data in special fields are the available non-standard 342 techniques. 344 Typically authorization needs to be associated to specific senders 345 and specific messages, in order to prevent a "replay" attack which 346 causes and earlier authorization to enable a later dial-out by a 347 different (and unauthorized) sender. A non-malicious example of such 348 a replay would be to have an email recipient reply to all original 349 recipients -- including an offramp IFax recipient -- and have the 350 original sender's authorization cause the reply to be sent. 352 5.2.4 Sender accountability 354 In many countries, there is a legal requirement that the "sender" be 355 disclosed on a facsimile message. Email From addresses are trivial 356 to fake, so that using only the MAIL FROM [1, 3] or From [2, 3] 357 header is not sufficient. 359 Offramps SHOULD ensure that the recipient is provided contact 360 information about the offramp, in the event of problems. 362 The G3Fax recipient SHOULD be provided with sufficient information 363 which permits tracing the originator of the IFax message. Such 364 information might include the contents of the MAIL FROM, From, Sender 365 and Reply-To headers, as well as Message-Id and Received headers. 367 5.2.5 Message disclosure 369 Users of G3Fax devices have an expectation of a level of message 370 privacy which is higher than the level provided by Internet mail 371 without security enhancements. 373 This expectation of privacy by G3Fax users SHOULD be preserved as 374 much as possible. 376 Sufficient physical and software control may be acceptable in 377 constrained environments. The usual mechanism for ensuring data 378 confidentially entail encryption, as discussed below. 380 5.2.6 Non private mailboxes 382 With email, bounces (delivery failures) are typically returned to the 383 sender and not to a publicly-accessible email account or printer. 384 With facsimile, bounces do not typically occur. However, with IFax, 385 a bounce could be sent elsewhere (see section [Delivery Failure]), 386 such as a local system administrator's account, publicly-accessible 387 account, or an IFax printer (see also [Traffic Analysis]). 389 5.2.7 Traffic analysis 391 Eavesdropping of senders and recipients is easier on the Internet 392 than GSTN. Note that message object encryption does not prevent 393 traffic analysis, but channel security can help to frustrate attempts 394 at traffic analysis. 396 5.3 Security Techniques 398 There are two basic approaches to encryption-based security which 399 support authentication and privacy: 401 5.3.1 Channel security 403 As with all email, an IFax message can be viewed as it traverses 404 internal networks or the Internet itself. 406 Virtual Private Networks (VPN), IPSec [18], or transport layer 407 security [20], can be used to prevent eavesdropping of a message 408 as it traverses such networks. It also provides some protection 409 against traffic analysis, as described above. 411 5.3.2 Object security 413 As with all email, an IFax message can be viewed while it resides on, 414 or while it is relayed through, an intermediate Mail Transfer Agent. 416 Message encryption, such as OPEN-PGP [13] and S/MIME [21], can be 417 used to provide end-to-end encryption. 419 6 REFERENCES 421 [1] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 422 821, December 1982. 424 [2] Crocker, D., "Standard for the Format of ARPA Internet 425 Text Messages", STD 11, RFC 822, December l982. 427 [3] Braden, R., "Requirements for Internet hosts - application 428 and support", RFC 1123, October 1989. 430 [4] Borenstein, N., and N. Freed, " Multipurpose Internet 431 Mail Extensions (MIME) Part Five: Conformance Criteria and 432 Examples ", RFC 2049, November 1996. 434 [5] Parsons, G., and J. Rafferty, "Tag Image File Format 435 (TIFF) -- F Profile for Facsimile", RFC 2306, March 1998. 437 [6] McIntyre, L., Zilles, S., Buckley, R., Venable, D., 438 Parsons, G., and J. Rafferty, "File Format for Internet Fax", 439 RFC 2301, March 1998. 441 [7] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", RFC 2119, March 1997. 444 [8] ITU-T (CCITT), "Standardization of Group 3 facsimile 445 apparatus for document transmission", ITU-T (CCITT), 446 Recommendation T.4. 448 [9] Myers, J., and M. Rose, "Post Office Protocol - Version 449 3", STD 53, RFC 1939, May 1996. 451 [10] Crispin, M., "Internet Message Access Protocol - Version 452 4Rev1", RFC 2060, December 1996. 454 [11] Allocchio, C., "Minimal PSTN address format for Internet 455 mail", RFC 2303, March 1998. 457 [12] Allocchio, C., "Minimal fax address format for Internet 458 mail", RFC 2304, March 1998. 460 [13] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, 461 "OpenPGP Message Format", RFC 2440, November 1998 463 [14] Moore, K., and G. Vaudreuil, "An Extensible Message Format 464 for Delivery Status Notifications", RFC 1894, January 1996. 466 [15] Moore, K., "SMTP Service Extension for Delivery Status 467 Notifications", RFC 1891, January 1996. 469 [16] Freed, N., and N. Borenstein, "Multipurpose Internet 470 Mail Extensions (MIME) Part Two: Media Types", RFC 2046, 471 November 1996. 473 [17] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 474 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 475 November 1996. 477 [18] Kent, S. and R. Atkinson, "Security Architecture for the 478 Internet Protocol", RFC 2401, November 1998. 480 [19] Parsons, G. and J. Rafferty, "Tag Image File Format 481 (TIFF) -- image/TIFF: MIME Sub-type Registration", RFC 2302, 482 March 1998. 484 [20] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", 485 RFC 2487, January 1999. 487 [21] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 488 L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, 489 March 1998. 491 7 ACKNOWLEDGEMENTS 493 This specification was produced by the Internet Engineering Task 494 Force Fax Working Group, over the course of more than one year's 495 online and face-to-face discussions. As with all IETF efforts, many 496 people contributed to the final product. 498 Active for this document were: Steve Huston, Jeffrey Perry, Greg 499 Vaudreuil, Richard Shockey, Charles Wu, Graham Klyne, Robert A. 500 Rosenberg, Larry Masinter, Dave Crocker, Herman Silbiger, James 501 Rafferty. 503 8 AUTHORS' ADDRESSES 505 Kiyoshi Toyoda 506 Matsushita Graphic Communication Systems, Inc. 507 2-3-8 Shimomeguro, Meguro-ku 508 Tokyo 153 Japan 509 Fax: +81 3 5434 7166 510 Email: ktoyoda@rdmg.mgcs.mei.co.jp 512 Hiroyuki Ohno 513 Tokyo Institute of Technology 514 2-12-1 O-okayama, Meguro-ku 515 Tokyo 152 Japan 516 FAX: +81 3 5734 2754 517 Email: hohno@is.titech.ac.jp 519 Jun Murai 520 Keio University 521 5322 Endo, Fujisawa 522 Kanagawa 252 Japan 523 Fax: +81 466 49 1101 524 Email: jun@wide.ad.jp 526 Dan Wing 527 Cisco Systems, Inc. 528 101 Cooper Street 529 Santa Cruz, CA 95060 USA 530 Phone: +1 831 457 5200 531 Fax: +1 831 457 5208 532 Email: dwing@cisco.com 534 9 APPENDIX A: Exceptions to MIME 536 * IFax senders are NOT REQUIRED to be able to send 537 text/plain messages (RFC 2049 requirement 4), although IFax 538 recipients are required to accept such messages, and to process 539 them. 541 * IFax recipients are NOT REQUIRED to offer to put results 542 in a file. (Also see 2.3.2.) 544 * IFax recipients MAY directly print/fax the received 545 message rather than "display" it, as indicated in RFC 2049. 547 10 Full Copyright Statement 549 Copyright (C) The Internet Society (1999). All Rights Reserved. 551 This document and translations of it may be copied and furnished to 552 others, and derivative works that comment on or otherwise explain it 553 or assist in its implementation may be prepared, copied, published 554 and distributed, in whole or in part, without restriction of any 555 kind, provided that the above copyright notice and this paragraph are 556 included on all such copies and derivative works. However, this 557 document itself may not be modified in any way, such as by removing 558 the copyright notice or references to the Internet Society or other 559 Internet organizations, except as needed for the purpose of 560 developing Internet standards in which case the procedures for 561 copyrights defined in the Internet Standards process must be 562 followed, or as required to translate it into languages other than 563 English. 565 The limited permissions granted above are perpetual and will not be 566 revoked by the Internet Society or its successors or assigns. 568 This document and the information contained herein is provided on an 569 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 570 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 571 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 572 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 573 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 -- 576 KiyoshiToyoda 577 ktoyoda@rdmg.mgcs.mei.co.jp 578 M.G.C.S