idnits 2.17.1 draft-ietf-fax-gateway-protocol-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 546. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 546), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 697 lines 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. ** There are 20 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 111: '... offramp gateway MUST, as minimal requ...' RFC 2119 keyword, line 118: '... and MAY also perform...' RFC 2119 keyword, line 124: '... offramp gateway MAY have a user autho...' RFC 2119 keyword, line 133: '... OpenPGP [16] [24]) MAY also be used to authenticate and authorize the...' RFC 2119 keyword, line 141: '... offramp gateway MUST generate an erro...' (38 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 45 has weird spacing: '... from i-fax...' -- 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) -- Missing reference section? '1' on line 442 looks like a reference -- Missing reference section? '3' on line 453 looks like a reference -- Missing reference section? '2' on line 633 looks like a reference -- Missing reference section? '23' on line 510 looks like a reference -- Missing reference section? '4' on line 456 looks like a reference -- Missing reference section? '5' on line 459 looks like a reference -- Missing reference section? '8' on line 469 looks like a reference -- Missing reference section? '9' on line 471 looks like a reference -- Missing reference section? '10' on line 474 looks like a reference -- Missing reference section? '11' on line 477 looks like a reference -- Missing reference section? '12' on line 480 looks like a reference -- Missing reference section? '16' on line 492 looks like a reference -- Missing reference section? '24' on line 513 looks like a reference -- Missing reference section? '6' on line 463 looks like a reference -- Missing reference section? '7' on line 466 looks like a reference -- Missing reference section? '14' on line 486 looks like a reference -- Missing reference section? '15' on line 489 looks like a reference -- Missing reference section? '13' on line 483 looks like a reference -- Missing reference section? '17' on line 495 looks like a reference -- Missing reference section? '18' on line 498 looks like a reference -- Missing reference section? '19' on line 501 looks like a reference -- Missing reference section? '20' on line 504 looks like a reference -- Missing reference section? '21' on line 445 looks like a reference -- Missing reference section? '22' on line 507 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 4 warnings (==), 28 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K.Mimura 2 Internet-Draft: draft-ietf-fax-gateway-protocol-13.txt K.Yokoyama 3 T.Satoh 4 C.Kanaide 5 TOYO Communication Equipment 6 C. Allocchio 7 Consortium GARR 8 January 18 2005 10 Internet FAX Gateway Requirements 12 Status Of This Memo 14 By submitting this Internet-Draft, we certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). All Rights Reserved. 38 Abstract 40 To allow connectivity between the general switched telephone network 41 facsimile service (GSTN fax) and the e-mail based Internet Fax service 42 (i-fax) an "Internet FAX Gateway" is required. This document provides 43 recommendations for the functionality of Internet FAX Gateways. In 44 this context, an "offramp gateway" provides facsimile data transmission 45 from i-fax to GSTN fax; viceversa an "onramp gateway" provides data 46 transmission form GSTN fax to i-fax. The recommendations in this 47 document apply to the integrated service including Internet Fax 48 terminals, computers with i-fax software on the Internet, and GSTN Fax 49 terminals on the GSTN. 51 1. Introduction 53 An Internet FAX Gateway provides connectivity and translation between 54 the General Switched Telephone Network facsimile service (GSTN fax) and 55 the e-mail based Internet Fax service (i-fax). This document defines 56 the recommended behavior of an Internet Fax Gateway. An Internet Fax 57 Gateway can be classified as "onramp", when a facsimile is transferred 58 from GSTN fax to the Internet Fax, and as "offramp", when a facsimile 59 is transferred from Internet Fax to GSTN fax. For a more detailed 60 definition of "onramp" and "offramp" within i-fax service, see [1]. 62 This document provides recommendations only for the specific case 63 hereunder: 65 1) the operational mode of the Internet Fax is "store and forward", as 66 defined in Section 2.5 of [1]. 68 2) The format of image data is the data format defined by "simple 69 mode" in [3]. 71 This document does not apply to the gateway funcions for "real-time 72 Internet Fax", as described and defined in [2]. Additional 73 recommendations for optional functionality are described in [23]. 75 1.1 Key words 77 The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this 78 document are to be interpreted as described in [4]. 80 1.2 Intellectual property 81 The IETF has been notified of intellectual property rights claimed in 82 regard to some or all of the specification contained in this 83 document. For more information consult the online list of claimed 84 rights in . 86 2. Internet FAX Gateway operations 88 An onramp gateway receives a facsimile from a GSTN fax device (which 89 may include an offramp gateway itself), and generates an Internet Fax 90 over the Internet which is sent to any Internet Fax device. 92 An offramp gateway receives an Internet Fax over the Internet from 93 any Internet Fax-capable device (which may include an onramp gateway 94 or a PC), and generates a GSTN fax which is sent to any GSTN fax device. 96 In both of these cases, the Internet side of the gateway acts as an 97 Internet Fax device, as described in [3], while the GSTN side of the 98 gateway acts as a GSTN fax device, as described in [5]. 100 In this document we will only thus recommend the actions which occur 101 while 103 1) the onramp gateway converts a fax received from GSTN to forward it 104 to the Internet Fax service; 106 2) the offramp gateway converts a fax received from the Intenret and 107 forwards it to the GSTN fax service. 109 3. The Offramp Gateway operations 111 An offramp gateway MUST, as minimal requirement, perform the 112 following functions: 114 - addresses translation/mapping; 115 - image format conversion; 116 - error/return notification handling; 118 and MAY also perform 120 - user authorization; 122 3.1 User authorization 124 An offramp gateway MAY have a user authorization function to confirm 125 that an user is allowed to transmit its Internet fax to the GSTN fax 126 service. 128 As an Internet Fax is sent as a MIME e-mail message until the 129 offramp gateway, digital signatures can be used to authenticate and 130 authorize the user. S/MIME is one example of a protocol that includes 131 digital signature services. S/MIME is described in [8][9][10][11][12]. 132 Other methods to add a digital signature to a mail message (like 133 OpenPGP [16] [24]) MAY also be used to authenticate and authorize the 134 user. 136 The agent sending the Internet Fax (which may include an an onramp 137 gateway) sends the digitally-signed S/MIME or OpenPGP Fax message to 138 the offramp gateway. The offramp gateway then compares the credentials 139 of the user to determine if he/she is authorized to send faxes to 140 the GSTN fax service. In case the authorization process fails, then 141 the offramp gateway MUST generate an error delivery notification for 142 the sender of the Internet Fax. 144 3.2 Addressing 146 An Internet fax may contain multiple e-mail addresses, both as 147 originators, and as recipients. For its forwarding function to GSTN 148 fax service, an offramp gateway MUST only consider those ones which 149 are explicitly addressed to itself, i.e. those where the right hand 150 side of the e-mail address corresponds to the offramp gateway itself. 152 As addresses on Internet Fax service are e-mail addresses, in order to 153 reach a destination in GSTN fax service, the offramp gateway MUST 154 convert e-mail addresses into GSTN addresses. 156 The GSTN destination address SHOULD normally be encoded inside the 157 left hand side of the e-mail address, according to [6]. However, an 158 offramp gateway MAY use locally implemented translation rules to map 159 left hand side strings into GSTN addresses. 161 In any case the offramp gateway MUST process the resultant GSTN 162 address, and convert it to a "local-phone" according to local 163 dialing rules. 165 "Global-phone" is defined in Section 2 of [6]. "Local-phone" is 166 defined in Section 2 of [7]. "Exit-code" is defined in Section 2.1 of 167 [7]. 169 The offramp gateway SHOULD also have a function to apply translation 170 to originator and other addresses referred to into the Internet fax 171 in order to ensure a possible return path from GSTN fax service 172 into Internet fax destinations, including other offramp gateways. 173 These functions MUST be compliant with the address handling of 174 onramp gateways described in this document, section 4.2. 176 3.2.1 Examples of local dialing rules applied to GSTN destination 177 addresses 179 The first example shows how an offramp gateway converts a 180 "global-phone" to a "local-phone" by removing the "+", recognizing 181 the international country code "1" as the local one and thus removing 182 it, and knowing it can directly dial without any exit code: 184 global-phone: +441164960348 186 resulting into: 188 local-phone: 1164960348 190 The next example shows how an offramp gateway converts a 191 "global-phone" to "local-phone" by removing the "+", recognizing 192 the international country code as local, and then adding the 193 "exit-code" "0" in front of the string: 195 global-phone: +441164960348 197 resulting into 199 local-phone: 01164960348 201 The next example shows how an offramp gateway converts a 202 "global-phone" to "local-phone" by removing the "+", recognizing 203 the international country code as local, and then adding the long 204 distance "0" in front of the string: 206 global-phone: +441164960348 208 resulting into 210 local-phone: 01164960348 212 The last example shows how an offramp gateway converts a 213 "global-phone" to "local-phone" by removing the "+", recognizing 214 the international country code as non local, and then adding the 215 local international dialling prefix "00" in front of the string: 217 global-phone: +441164960348 219 resulting into 221 local-phone: 00441164960348 223 3.2.2 Support for subaddress 225 An offramp gateway SHOULD support the subaddress. In case a subaddress 226 is encoded into the left-hand-side of the e-mail address [6], then 227 it MUST be used by the offramp gateway as specified in T.33 [14] to 228 reach the final GSTN fax recipient. 230 3.3 Image format conversion 232 An offramp gateway MUST convert the file format from TIFF Profile-S 233 for Internet Fax (defined in [15]) into the GSTN fax image format. 234 The case of other Internet fax file formats is not considered in 235 this document. 237 3.4 Error/return notification handling 239 An offramp gateway SHOULD have a function which allows it to send a 240 return notice to the originator Internet fax device (defined in 241 [3]) when a transmission error occurs over the GSTN fax service and 242 the facsimile is not delivered to destination. The return notice 243 MUST be in Message Delivery Notification (MDN) format, delivered 244 by the offramp gateway over the Internet e-mail transport service 245 used by Internet fax. The MDN disposition-type MUST be set as 246 "processed", and the dispoistion-modifier MUST be set as an "error". 248 If the offramp gateway fails to transmit the MDN, the error information 249 MAY be recorded to a log, and processing MAY end, or the administrator 250 of the gateway system MAY be notified of these errors through a specific 251 method (for example, by sending him/her an e-mail message). 253 The more complex case of Delivery Status Notification (DSN) requests 254 handling is not considered in this document. 256 4. The Onramp Gateway operations 258 An onramp gateway MUST, as minimal requirement, perform the 259 following functions: 261 - addresses translation/mapping; 262 - image format conversion; 263 - error/return notification handling. 265 and MAY also perform 267 - user authorization; 269 4.1 User authorization 271 An onramp gateway MAY have a user authorization function to confirm 272 that the user is authorized to transmit facsimile into the Internet 273 fax service. For example, user authorization may be accomplished by 274 getting a user-ID and password received by DTMF, or via a local 275 authorization table based on the GSTN caller-ID. 277 In case the authorization process fails, then the onramp gateway MUST 278 generate an error message/code for the sender of the GSTN Fax. 280 4.2 Address translation/mapping 282 Addresses on Internet Fax service are e-mail addresses, thus a 283 recipient of an Internet fax might be either an e-mail user, 284 an Internet fax device with its own recipients/users or an offramp 285 gateway. The onramp gateway SHOULD have a functionality in order to 286 receive from GSTN (via DTMF) destination addresses. However, there 287 are two categories of destination addresses: 289 - e-mail users and Internet Fax recipient/users; 290 - real GSTN addresses reached via an offramp gateway. 292 We define thus "indirect address mapping" the functionality for 293 the first category, and "direct address mapping" the one for the 294 second category. 296 4.2.1 Indirect address mapping 298 The onramp gateway MAY implement local address mapping mechanisms 299 (via a table or a directory lookup or similar) which permit 300 translation from addresses (called "indirect address number") received 301 from the GSTN fax sending device into e-mail addresses. A single or a 302 list of e-mail addresses MAY correspond to a single indirect address 303 number. 305 Here is one mapping example: 307 (1) An onramp gateway receives the indirect address number "1234" 308 from the source GSTN facsimile by DTMF. 310 1234 312 (2) The destination address is looked up in the address mapping table. 314 address mapping table 315 1234 : ifax@example.com 317 (3) An Internet Fax is sent to the address ("addr-spec") 319 ifax@example.com 321 "Addr-spec" is defined in Section 6.1 of [13]. 323 If the address mapping lookup fails, and error MUST be reported back 324 to the oriiginating GSTN fax device. 326 4.2.2 Direct address mapping 328 If the indirect address mapping specified in 4.2.1 is not implemented 329 then only "direct address mapping" can be used. The GSTN sending 330 device SHOULD send the full numeric destination address via DTMF 331 to the onramp gateway. Direct address mapping can be used also if the 332 indirect address mapping is implemented. 334 An example: 336 (1) An onramp gateway receives the destination telephone number 337 "441164960348" from the source facsimile by DTMF (Dual Tone 338 Multi-Frequency). 340 441164960348 342 (2) The destination number is encoded as a "global-phone", so "+" is 343 added at the head of the string. 345 +441164960348 347 (3) "FAX=" is added in order to build the "fax-mbox" address item 349 FAX=+441164960348 351 (4) The destination address is completed, adding the specification 352 of the appropriate offramp gateway which is suppoused to handle 353 the delivery of the fax message to global-phone address. 355 FAX=+441164960348@example.com 357 The procedure for choosing the domain name of an offramp gateway is 358 defined in Section 4.3 (Relay function). 360 "Global-phone", "fax-mbox", and "fax-address" are defined in Section 361 2 of [6]. "Mta-I-fax" is defined in Section 3 of [6]. "Fax-email" is 362 defined in Section 4 of [6]. 364 4.2.3 Sender addresses handling 366 The onramp gateway SHOULD gather information about the GSTN fax 367 sender address (for example via Caller-ID, if available), and encode 368 it as the sender of the Internet fax, using the direct address 369 mapping (sections 4.2.2 in this document). The sender address SHOULD 370 be completed using the onramp gateway address, unless the onramp 371 gateway has available additional information to specify a different 372 return path. 374 If the onramp gateway does not have any sender address information, 375 the Internet fax sender address SHOULD be set either to a "no-reply" 376 address, or to an appropriate default mailbox. 378 4.2.4 Support for subaddress 380 An onramp gateway SHOULD support the subaddress. In the case of 381 direct address mapping, the subaddress is specified using the 382 T.33 [14] specification, and encoded as given in [6]. In the case 383 of indirect address mapping, the subaddress MAY be contained inside 384 the address mapping table. 386 4.3 Relay function 388 The onramp gateway SHOULD provide functionality to choose the 389 destination offramp gateway by analyzing a destination fax number. 390 A possible method to expand or acquire information by the onramp 391 gateway about offramp gateways MAY include keeping cached information 392 about sender addresses sent by other onramp gateways. 394 4.4 File format conversion 396 An onramp gateway MUST convert the file format from a facsimile over 397 the GSTN to the file format TIFF Profile-S for Internet Fax, as 398 defined in [15]. 400 4.6 Return notice handling 402 When an onramp gateway receives and analyzes a return notice from the 403 Internet fax destination, it MAY have the functionality to send the 404 delivery status to a suitable facsimile device on the GSTN through an 405 appropriate offramp gateway. The generated notice sent via GSTN fax 406 SHOULD contain both the human readable notice information, and the 407 original delivery codes. 409 If the onramp gateway fails in the transmission of the return 410 notice back to GSTN fax service, the information MAY be recorded 411 into a log, and processing MAY end. As an alternate, the administrator 412 of the gateway system MAY be notified of these notice with a specific 413 method (for example by sending an e-mail message to a mailbox). 415 5. Security Considerations 417 Refer to Section 3.1 (User authorization) for authentication for an 418 offramp gateway. OpenPGP [16] [24] can be used to provide authorization 419 services instead of S/MIME. Refer to Section 4.1 (User authorization) 420 for authentication for an onramp gateway. 422 S/MIME and OpenPGP can also be used to encrypt a message. A signed 423 or encrypted message is protected while transported along the 424 network; however when a message reach an Internet fax gateway, 425 either onramp or offramp, this kind of protection cannot be applied 426 anymore. Security must rely here on trusted operations of the gateway 427 itself. A gateway might have its own certificate/key to improve 428 security operations when sending Internet faxes, but as any gateway 429 it breaks the end to end security pattern of both S/MIME and PGP. 431 Other security mechanisms, like IPsec [17][18][19][20][21] or TLS [22] 432 also do not ensure a secure gateway operation. 434 Denial of Service attacks are beyond the scope of this document. 435 Host Compromise caused by flaws in the implementation is beyond the 436 scope of this document. 438 6. References 440 6.1 Informative group 442 [1] L. Masinter, "Terminology and Goals for Internet Fax", RFC2542, 443 March 1999. 445 [21] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 446 Roadmap", RFC2411, November 1998. 448 6.2 Normative group 450 [2] "Procedures for real-time Group 3 facsimile communication over IP 451 networks", ITU-T Recommendation T.38, June 1998. 453 [3] K. Toyoda, H. Ohno, J. Murai and D. Wing, "A Simple Mode of 454 Facsimile Using Internet Mail", RFC 3965, December 2004. 456 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 457 Levels", RFC 2119, March 1997. 459 [5] "Procedures for document facsimile transmission in the general 460 switched telephone network", ITU-T Recommendation T.30, April 461 1999. 463 [6] C. Allocchio, "Minimal FAX address format in Internet Mail", RFC 464 3192, October 2001. 466 [7] C. Allocchio, "GSTN Address Element Extensions in E-mail 467 Services", RFC2846, June 2000. 469 [8] R. Housley, "Cryptographic Message Syntax", RFC3852, July 2004. 471 [9] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC2631, 472 June 1999. 474 [10] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 475 (S/MIME) Version 3.1 Certificate Handling ", RFC3850, June 1999. 477 [11] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 478 (S/MIME) Version 3.1 Message Specification ", RFC3851, June 1999. 480 [12] P. Hoffman, "Enhanced Security Services for S/MIME", RFC2634, 481 June 1999. 483 [13] D. Crocker, "Standard for the format of ARPA Internet text 484 messages", STD 11, RFC 822, August 1982. 486 [14] "Facsimile routing utilizing the subaddress", ITU recommendation 487 T.33, July 1996. 489 [15] L. McIntyre, S. Zilles, R. Buckley, D. Venable, G. Parsons, J. 490 Rafferty, "File Format for Internet Fax", RFC 2301, March 1998. 492 [16] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, , 493 "OpenPGP Message Format", RFC2440, November 1998. 495 [17] Kent, S. and R. Atkinson, "Security Architecture for the 496 Internet Protocol", RFC 2401, November 1998. 498 [18] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402, 499 November 1998. 501 [19] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit 502 Congestion Notification (ECN) to IP", RFC3168, September 2001. 504 [20] Piper, D., "The Internet IP Security Domain of Interpretation 505 for ISAKMP", RFC 2407, November 1998. 507 [22] Dierks, T. and C. Allen, "Transport Layer Security (TLS) 508 Extensions", RFC3456, June 2003. 510 [23] Mimura et. al., "Guideline of optional services for 511 Internet FAX Gateway", draft-ietf-fax-gateway-options 513 [24] Elkins et. al., "MIME Security with OpenPGP", RFC 3156, 514 August 2001. 516 7. Intellectual Property Statement 517 The IETF takes no position regarding the validity or scope of any 518 intellectual property or other rights that might be claimed to 519 pertain to the implementation or use of the technology described in 520 this document or the extent to which any license under such rights 521 might or might not be available; neither does it represent that it 522 has made any effort to identify any such rights. Information on the 523 IETF's procedures with respect to rights in standards-track and 524 standards-related documentation can be found in BCP-11. Copies of 525 claims of rights made available for publication and any assurances of 526 licenses to be made available, or the result of an attempt made to 527 obtain a general license or permission for the use of such 528 proprietary rights by implementors or users of this specification can 529 be obtained from the IETF Secretariat. 530 The IETF invites any interested party to bring to its attention any 531 copyrights, patents or patent applications, or other proprietary 532 rights which may cover technology that may be required to practice 533 this standard. Please address the information to the IETF Executive 534 Director. 535 8. Full Copyright Statement 537 Copyright (C) The Internet Society (2005). This document is subject 538 to the rights, licenses and restrictions contained in BCP 78, and 539 except as set forth therein, the authors retain all their rights. 540 This document and the information contained herein are provided on an 541 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 542 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 543 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 544 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 545 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 546 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 548 9. Author's Address 550 Katsuhiko Mimura 551 TOYO Communication Equipment CO., LTD. 552 2-1-1 Koyato, Samukawa-machi, Koza-gun 553 Kanagawa, Japan 554 Fax: +81 467 74 5743 555 Email: mimu@macroware.co.jp 557 Keiichi Yokoyama 558 TOYO Communication Equipment CO., LTD. 559 2-1-1 Koyato, Samukawa-machi, Koza-gun 560 Kanagawa, Japan 561 Fax: +81 467 74 5743 562 Email: keiyoko@msn.com 564 Takahisa Satoh 565 TOYO Communication Equipment CO., LTD. 566 2-1-1 Koyato, Samukawa-machi, Koza-gun 567 Kanagawa, Japan 568 Fax: +81 467 74 5743 569 Email: zsatou@toyocom.co.jp 571 Chie Kanaide 572 TOYO Communication Equipment CO., LTD. 573 2-1-1 Koyato, Samukawa-machi, Koza-gun 574 Kanagawa, Japan 575 Fax: +81 467 74 5743 576 Email: c-miwa@mail.nissan.co.jp 578 Claudio Allocchio 579 Consortium GARR 580 Viale Palmiro Togliatti 1625 581 00155 Roma, Italy 582 Fax: +39 040 3758565 583 Email: Claudio.Allocchio@garr.it 585 Revision history 587 [[[RFC editor: Please remove this section on publication]]] 589 00a 10-Jul-2000 Initial draft. 590 01a 16-Aug-2000 Remove next section. 591 Authentication 592 Authentication toward Offramp gateway 593 Option function 594 Multicasts transmit request 595 Rename next section 596 to Relay function from Choice of Offramp gateway 597 to User authorization from User authentication 598 to Immediate address designation from Direct 599 address designation 600 Section Drop the duplicate mail was moved to a part 601 of the section Offramp functions. 602 Corrections and clarifications. 603 02a 30-Oct-2000 Title is changed from Internet FAX Gateway Protocol 604 to Internet FAX Gateway Functions 605 Remove next definition. 606 Drop duplications for Broadcast 607 When send return notice 608 Automatic re-transmission 609 keep log for offramp gateway 610 Example of User authorization 611 keep log for onramp gateway 612 Rebuild next definition 613 3.2 Addressing 614 3.2.1 example of local dialing rules 615 4.2.1 Immediate address designation 616 4.2.2 Indirect address designation 617 4.4 File format conversion 618 03a 21-Feb-2001 Rebuild next definition 619 1. 1) 620 3.4 Return notice 621 4.6 Return notice 622 Add next definition 623 3.3 User authorization 624 04a 22-May-2001 Rebuild next definition 625 3.4 Return notice 626 4.6 Return notice 627 5. Security Considerations 628 05a 28-June-2001 Rebuild next definition 629 Abstract 630 1. Introduction 631 4.2 Address designation 632 Add to References 633 [2] 635 06a 19-Septembert-2001 Rebuild next definition 636 5. Security Considerations 638 6a 20-March-2002 Corrections and clarifications. 639 Moved Intellectual Property and keywords 640 after section 1. 641 Fixed Security considerations. 642 07 25-March-2002 Separate 6.References into 6.1 Normative groups 643 and 6.2 Informative groups. 644 08 28-March-2002 Changed sentences in 3.3 user authorization, 645 4.1 Onramp Functions, 646 4.2 Address designation 647 and 5 Security Considerations 648 Rebuild 6. References 649 09 14-July 2004 Corrections and clarifications. 650 10 18-July-2004 Rebuild next definition 651 3.3 User authorization 652 3.4 Return notice 653 4.2.1 Immediate address designation 654 4.2.2 Indirect address designation 655 4.3 Relay function 656 5. Security Considerations 657 11 20-July-2004 6. References 658 split to Informative and Normative 659 12 21-Jan-2005 full editorial review 660 13 23-Feb-2005 Change the example telephone numbers 661 in Sections 3.2.1 and 4.2.2 663 Mimura, et. al. Expires January 2005 [Page12