idnits 2.17.1 draft-ietf-fax-gateway-options-08.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 23. -- Found old boilerplate from RFC 3978, Section 5.5 on line 430. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 430), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 27. ** 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 556 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 10 instances of too long lines in the document, the longest one being 1079 characters in excess of 72. ** 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 115: '... offramp gateway SHOULD implement tech...' RFC 2119 keyword, line 130: '...cessing, then it MUST use it to determ...' RFC 2119 keyword, line 138: '... "Message-ID" (see [7]) MAY be used to check if a message has...' RFC 2119 keyword, line 151: '...he offramp gateway SHOULD re-queue the...' RFC 2119 keyword, line 161: '... offramp gateway SHOULD NOT attempt re...' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 14 has weird spacing: '...licable pate...' == Line 34 has weird spacing: '...rovides guide...' == Line 36 has weird spacing: '...on from i-fax...' == Line 56 has weird spacing: '... onramp gatew...' == Line 424 has weird spacing: '... of any inte...' == (1 more instance...) -- 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 355 looks like a reference -- Missing reference section? '2' on line 398 looks like a reference -- Missing reference section? '3' on line 402 looks like a reference -- Missing reference section? '5' on line 408 looks like a reference -- Missing reference section? '4' on line 405 looks like a reference -- Missing reference section? '6' on line 411 looks like a reference -- Missing reference section? '7' on line 414 looks like a reference -- Missing reference section? '8' on line 417 looks like a reference -- Missing reference section? '9' on line 420 looks like a reference -- Missing reference section? '10' on line 358 looks like a reference -- Missing reference section? '19' on line 384 looks like a reference -- Missing reference section? '20' on line 387 looks like a reference -- Missing reference section? '21' on line 390 looks like a reference -- Missing reference section? '22' on line 393 looks like a reference -- Missing reference section? '11' on line 360 looks like a reference -- Missing reference section? '18' on line 381 looks like a reference -- Missing reference section? '12' on line 363 looks like a reference -- Missing reference section? '13' on line 366 looks like a reference -- Missing reference section? '14' on line 369 looks like a reference -- Missing reference section? '15' on line 372 looks like a reference -- Missing reference section? '16' on line 375 looks like a reference -- Missing reference section? '17' on line 378 looks like a reference Summary: 18 errors (**), 0 flaws (~~), 9 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K.Mimura 3 Internet-Draft: draft-ietf-fax-gateway-options-08.txt K.Yokoyama 4 T.Satoh 5 K.Watanabe 6 C.Kanaide 7 TOYO Communication Equipment 8 January 21 2005 10 Guideline of optional services for Internet FAX Gateway 12 Status Of This Memo 14 By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been 15 disclosed, and any of which I become aware will be disclosed, in 16 accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed 23 at http://www.ietf.org/shadow.html. 25 Copyright Notice 27 Copyright (C) The Internet Society (2005). All Rights Reserved. 29 Abstract 31 To allow connectivity between the general switched telephone network 32 facsimile service (GSTN fax) and the e-mail based Internet Fax 33 service (i-fax) an "Internet FAX Gateway" is required. This document 34 provides guidelines for the optional functionality of Internet FAX 35 Gateways. In this context, an "offramp gateway" provides facsimile 36 data transmission from i-fax to GSTN fax; viceversa an "onramp 37 gateway" provides data transmission form GSTN fax to i-fax. The 38 recommendations in this document apply to the integrated service 39 including Internet Fax terminals, computers with i-fax software on 40 the Internet, and GSTN Fax terminals on the GSTN. 42 This document supplements the recommendation for minimal features 43 of an Internet Fax Gateway. In particular it covers techniques to 44 drop duplicated fax messages, automatic fax re-transmission, error, 45 return notice and log handling and possible authorization methods 46 by DTMF (Dual Tone Multi-Frequency) for onramp gateways. 48 1. Introduction 50 An Internet FAX Gateway can be classified as either an offramp 51 gateway or an onramp gateway. This document provides guidelines 52 for optional services and examples of an Internet FAX Gateway 53 operations. In particular it covers techniques to drop duplicated 54 fax messages, automatic fax re-transmission, error, return notice 55 and log handling and possible authorization methods by DTMF (Dual 56 Tone Multi-Frequency) for onramp gateways. 58 A more detailed definition of onramps and offramps is provided in 59 [1]. Information on recommended behaviors for Internet FAX Gateway 60 functions are defined in [2]. 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", 66 as 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 functions for 72 "real-time Internet Fax", as described and defined in [5]. 74 1.1 Key words 76 The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this 77 document are to be interpreted as described in [4]. 79 2. Optional Services for an Offramp Gateway 81 2.1 Drop duplicated GSTN fax transmission 83 Electronic mail transport agents (MTA) deliver an Internet fax 84 message either into the recipient's or an offramp gateway mailbox; 85 hence the message is retrieved for further action, which in the case 86 of the offramp gateway, will result in its delivery to the GSTN fax 87 service. 89 The offramp gateway mailbox will thus receive all messages which 90 the gateway shall process, regardless of their final distinct GSTN 91 destination. As such, addresses like 93 Fax=+12224567654@example.com 94 Fax=+38155234578@example.com 95 Fax=+3904567437777@example.com 97 will all end up into the offramp gateway mailbox corresponding to 98 the "example.com" domain. 100 The handling of e-mail messages (including Internet fax ones) 101 containing more than one recipient, but directed to the same final 102 MTA can however be different, depending on the MTA configuration or 103 features: a single message with multiple recipients in the SMTP 104 envelope [6] is likely to be the most common case on the mail 105 transport system, but it may happen that multiple copies of the 106 same message are transmitted, one per each recipient. Or it may 107 happen that the final MTA is set to deliver a separate copy of the 108 message per each recipient into the final mailbox, supposing it is 109 delivering messages to real separate end user's mailboxes. 111 It may thus happen that the offramp gateway receives multiple 112 copies of the same Internet fax message, to be delivered to 113 different GSTN destinations, all listed together, and repeatedly, 114 into the e-mail message headers [7] of the Internet fax. In such 115 cases, the offramp gateway SHOULD implement techniques to avoid 116 duplicate or even multiple transmission over GSTN of the same fax 117 message to the same recipient. 119 Here are some possible, but non-exclusive examples of these 120 techniques. 122 2.1.1 SMTP envelope addresses check 124 Using the SMTP [6] envelope destination address given as "RCPT TO" 125 field is usually the best technique to ensure that a received 126 message must be delivered to that address, and to avoid duplicate 127 deliveries. 129 If the offramp gateway has the "RCPT TO" information still 130 available during processing, then it MUST use it to determine the 131 recipients over GSTN fax service. 133 2.1.2 Message-ID check 135 If the SMTP "RCPT TO" information is not available, for example 136 in the case the offramp gateway retrieves messages from its mailbox 137 using either POP [8] or IMAP [9] protocols, the message header 138 "Message-ID" (see [7]) MAY be used to check if a message has 139 already been processed, and hence avoid retransmission to all its 140 GSTN recipients handled by the offramp gateway. 142 2.2 Error handling 144 2.2.1 Recoverable errors 146 Recoverable errors happening during GSTN transmission are those 147 where there is good chance that the error may not occur at the next 148 attempt. This category includes "busy signal", "no line/carrier 149 signal", etc. 151 For all these errors, the offramp gateway SHOULD re-queue the 152 message and perform a retransmission attempt later on, as specified 153 in section 2.3 155 2.2.2 Non-recoverable errors 157 If the error occurring during GSTN transmission is likely to be a 158 non recoverable one, such as for example remote device paper 159 related errors (jam, empty tray, ...), no response from remote 160 destination, voice response, data modem response, or a stop event 161 error, the offramp gateway SHOULD NOT attempt retransmission, and 162 an error Message Delivery Notification (MDN) with appropriate error 163 codes MUST be generated for the Internet fax message sender. 165 2.3 Automatic re-transmission handling 167 An offramp gateway SHOULD implement a function that automatically 168 tries to send facsimile data again if recoverable delivery failure 169 occurs. If this function is implemented, then: 171 - the retry times and retry interval MAY be specified as options 172 by the administrator of the offramp gateway; 174 - any error return notice SHOULD be sent only when the number of 175 retries has been completed without success; 177 - if transmission is suspended due to an error, then the 178 subsequent transmission attempt SHOULD avoid retransmitting the 179 pages already delivered successfully, if any. 181 2.4 Multiple return notice handling 183 An offramp gateway can receive an Internet fax for delivery to 184 multiple GSTN recipients. If errors occur, thus requiring to 185 inform the Internet fax sender about them, or if the Internet fax 186 sender himself requested delivery notifications, then the offramp 187 gateway has various possibilities to handle these multiple return 188 notices: 190 1) an offramp gateway sends a return notice as soon as an error or 191 a successful delivery occurs, per single GSTN recipient; 193 2) an offramp gateway gathers all information about the message, 194 but sends a return notice only after all or a number of GSTN 195 recipients have been handled (successfully or not); 197 If case 2 is implemented, then the offramp gateway MAY choose also 198 to send separate successful and failure notices, or to limit the 199 number of GSTN recipients handled per single return note, for 200 example no more than 10 recipients per return note. 202 2.5 Handling transmission errors for a return notice 204 When an offramp gateway fails in the transmission of a return 205 notice, the Internet FAX Gateway SHOULD process the notice in 206 either of the following ways: 208 1) the return notices SHOULD be re-queued, and delivery retried 209 later. The number of retry attempts and the time interval among 210 then MAY be a feature configured by the offramp gateway 211 administrator. This is preferred method to implement; however, 212 if all the retransmission attempts fails, processing SHOULD 213 continue as in case 2; 215 2) if the gateway does not have enough capabilities to handle notice 216 re-queuing, but has a log information preservation function, the 217 error information SHOULD be recorded to a log, and processing 218 SHOULD end. At this time, the administrator of the gateway system 219 SHOULD be notified of these errors using a specific method (for 220 example by sending him an e-mail message). 222 3) If the gateway does not even have a log information preservation 223 function, the administrator SHOULD be notified about the failure, 224 for example via an e-mail message, and processing SHOULD end. 226 2.6 Offramp gateway log 228 An offramp gateway SHOULD have a function which keeps information 229 listed as a log, either specific to the fax gateway, or inside some 230 other log file existing locally on the gateway itself or remotely. 231 If the fax gateway or the remote system are equipped with a recording 232 media the log information SHOULD be saved as a log file. As a last 233 resort, if no recording media are available, the log MAY be printed. 235 The information listed in the log MAY be the following: 237 - Date and time when the Internet fax is received 238 - Sender address 239 - Recipient address(es) 240 - Start date and time of transmission over GSTN 241 - End date and time of transmission over GSTN 242 - Number of actually transmitted pages 243 - Number of actually transmitted bytes 244 - Fax resolution used 245 - Error codes/text occurred during transmission 246 - Number of transmission attempts (retries) 247 - Date and time of transmission of the (eventual) delivery notice 249 3. Optional Services for an Onramp Gateway 251 3.1 Examples of user authorization 253 An onramp gateway MAY have a user authorization function to confirm 254 that the user is authorized to transmit facsimile into the Internet 255 fax service. For example, user authorization may be accomplished by 256 getting a user-ID and password received by DTMF, or via a local 257 authorization table based on the GSTN caller-ID. The following 258 sub-sections give some possible examples, but other methods are also 259 possible. 261 3.1.1 Authorization via GSTN caller-ID 263 The most simple method to authenticate and authorize a GSTN fax 264 service user is by using the GSTN caller-ID. If available, in fact, 265 the caller-ID is generated by the GSTN network service itself, and 266 it is quite difficult to produce fake ones. In other words, the 267 security related to this authentication method rely on the confidence 268 that the GSTN caller-ID service is secure by itself. 270 The GSTN sender MAY be authorized via a lookup into a table managed 271 by the onramp gateway administrator, both via complete or partial 272 (wildcard) matches. 274 3.1.2 Authorization via GSTN fax "station ID" 276 During the initial GSTN fax service negotiation, the sender fax 277 can send to the onramp gateway various information, including the 278 "station ID" alphanumeric string. This string MAY thus be used to 279 transmit authentication and authorization information for subsequent 280 lookup by the onramp gateway. Thus user-id and an eventual password 281 MAY be sent inside this string. 283 If used as the only authentication, this method is however much less 284 secure than the caller-ID one, as the user of the calling GSTN station 285 can decide which string to send, and the string itself travels in 286 clear form over the GSTN. Given this security warning, this method 287 however allows more flexibility to the GSTN user: in fact it is not 288 tied to a single GSTN fax terminal, and authorization can be obtained 289 from anywhere, provided the sender has the possibility to configure 290 the "station ID" on the device being used. 292 A combination of caller-ID and station ID check MAY, on the other 293 hand, result in a greatly improved level of security. 295 3.1.3 Authorization via DTMF 297 An onramp gateway MAY implement the Authorization function by 298 requesting that a user ID and password information are sent over 299 GSTN via DTMF. For example, this function MAY be accomplished 300 requesting this DTMF information is send just after the connection 301 over GSTN is established, before starting the GSTN fax negotiation, 302 but other methods are also possible. 304 3.2 Onramp gateway log 306 An onramp gateway SHOULD have a function which keeps information 307 listed as a log, either specific to the fax gateway, or inside some 308 other log file existing locally on the gateway itself or remotely. 309 If the fax gateway or the remote system are equipped with a recording 310 media the log information SHOULD be saved as a log file. As a last 311 resort, if no recording media are available, the log MAY be printed. 313 The information listed in the log MAY be the following: 315 - Start date and time of transmission from GSTN 316 - End date and time of transmission from GSTN 317 - Number of actually received pages 318 - Number of actually received bytes 319 - Fax resolution used 320 - Sender address (if available) 321 - Recipient address(es) 322 - Date and time when the Internet fax is sent 323 - Error codes/text occurred during Internet fax transmission 324 - Number of transmission attempts (retries) 325 - Date and time of transmission of the (eventual) delivery notice 327 4. Security Considerations 329 Refer to Section 3.1 (User authorization) for authentication for an 330 onramp gateway. In particular, sending the user IDs and password in 331 clear, as described in section 3.1.2 can pose high security risks, 332 and thus is NOT RECOMMENDED. 334 S/MIME [10][19][20][21][22] ]and OpenPGP [11] [18] can also be used 335 to encrypt an Internet fax message. A signed or encrypted message is 336 protected while transported along the network; however when a message 337 reach an Internet fax gateway, either onramp or offramp, this kind 338 of protection cannot be applied anymore. Security must rely here on 339 trusted operations of the gateway itself. A gateway might have its 340 own certificate/key to improve security operations when sending 341 Internet faxes, but as any gateway it breaks the end to end security 342 pattern of both S/MIME and OpenPGP. 344 Other security mechanisms, like IPsec [12][13][14][15][16] or TLS [17] 345 also do not ensure a secure gateway operation. 347 Denial of Service attacks are beyond the scope of this document. 348 Host Compromise caused by flaws in the implementation is beyond the 349 scope of this document. 351 5. References 353 5.1 Informative group 355 [1] L. Masinter, "Terminology and Goals for Internet Fax", RFC 2542, 356 March 1999. 358 [10] R. Housley, "Cryptographic Message Syntax", RFC3852, July 2004. 360 [11] J. Callas, L. Donnerhacke, H. Finney, R. Thayer, , 361 "OpenPGP Message Format", RFC2440, November 1998. 363 [12] Kent, S. and R. Atkinson, "Security Architecture for the 364 Internet Protocol", RFC 2401, November 1998. 366 [13] Kent, S. and R. Atkinson, "IP Authentication Header", RFC2402, 367 November 1998. 369 [14] K. Ramakrishnan, S. Floyd, D. Black, "The Addition of Explicit 370 Congestion Notification (ECN) to IP", RFC3168, September 2001. 372 [15] Piper, D., "The Internet IP Security Domain of Interpretation 373 for ISAKMP", RFC 2407, November 1998. 375 [16] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security Document 376 Roadmap", RFC2411, November 1998. 378 [17] Dierks, T. and C. Allen, "Transport Layer Security (TLS) 379 Extensions", RFC3456, June 2003. 381 [18] Elkins et. al., "MIME Security with OpenPGP", RFC 3156, 382 August 2001. 384 [19] E. Rescorla, "Diffie-Hellman Key Agreement Method", RFC2631, 385 June 1999. 387 [20] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 388 (S/MIME) Version 3.1 Certificate Handling ", RFC3850, June 1999. 390 [21] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 391 (S/MIME) Version 3.1 Message Specification ", RFC3851, June 1999. 393 [22] P. Hoffman, "Enhanced Security Services for S/MIME", RFC2634, 394 June 1999. 396 5.2 Normative group 398 [2] K. Mimura, K. Yokoyama, T. Satoh, C. Kanaide, "Internet FAX 399 Gateway Requirements", draft-ietf-fax-gateway-protocol, 400 January 2005. 402 [3] K. Toyoda, H. Ohno, J. Murai, and D. Wing, "A Simple Mode of 403 Facsimile Using Internet Mail", RFC 3965, December 2004. 405 [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement 406 Levels", RFC 2119, March 1997. 408 [5] "Procedures for real-time Group 3 facsimile communication over IP 409 networks", ITU-T Recommendation T.38, June 1998. 411 [6] Postel, J. "Simple Mail Transfer Protocol", STD 10, RFC 821, 412 August 1982. 414 [7] Crocker, D., "Standard for the format of ARPA Internet text 415 messages", STD 11, RFC 822, August 1982. 417 [8] Myers, J., Rose, M. "Post Office Protocol - Version 3", RFC1939, 418 May 1996 420 [9] Crispin, M. "Internet Message Access Protocol - Version 4rev1", 421 RFC3501, March 2003. 423 6. Intellectual Property Statement 424 The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 426 7. Full Copyright Statement 428 Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 429 This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 430 8. Acknowledgments 432 Thanks to Claudio Allocchio (Consortium GARR, Italy) for its final 433 review of this document, and for contributing the authorization 434 and security sections of this document. 436 9. Author's Address 438 Katsuhiko Mimura 439 TOYO Communication Equipment CO., LTD. 440 2-1-1 Koyato, Samukawa-machi, Koza-gun 441 Kanagawa-pref., Japan 442 Fax: +81 467 74 5743 443 Email: mimu@macroware.co.jp 445 Keiichi Yokoyama 446 TOYO Communication Equipment CO., LTD. 447 2-1-1 Koyato, Samukawa-machi, Koza-gun 448 Kanagawa-pref., Japan 449 Fax: +81 467 74 5743 450 Email:keiyoko@msn.com 452 Takahisa Satoh 453 TOYO Communication Equipment CO., LTD. 454 2-1-1 Koyato, Samukawa-machi, Koza-gun 455 Kanagawa-pref., Japan 456 Fax: +81 467 74 5743 457 Email: zsatou@toyocom.co.jp 459 Ken Watanabe 460 TOYO Communication Equipment CO., LTD. 461 2-1-1 Koyato, Samukawa-machi, Koza-gun 462 Kanagawa-pref., Japan 463 Fax: +81 467 74 5743 464 Email: knabe@toyocom.co.jp 466 Chie Kanaide 467 TOYO Communication Equipment CO., LTD. 468 2-1-1 Koyato, Samukawa-machi, Koza-gun 469 Kanagawa-pref., Japan 470 Fax: +81 467 74 5743 471 Email: kanaide@toyocom.co.jp 473 Claudio Allocchio 474 Consortium GARR 475 Viale Palmiro Togliatti 1625 476 00155 Roma, Italy 477 Fax: +39 040 3758565 478 Email: Claudio.Allocchio@garr.it 480 Revision history (to be deleted before publication) 482 00a 31-Oct-2000 Initial draft. 483 01a 21-Feb-2001 Rebuild next definition 484 2.6 keep log 485 3.2 keep log 486 Added next definition 487 2.5 When a transmitting error occurred in return notice 488 02a 22-May-2001 Rebuild next definition 489 2.6 keep log 490 3.2 keep log 491 4. Security Considerations 492 03a 28-June-2001 Rebuild next definition 493 3.1 Example of User authorization 494 04a 19-September-2001 Rebuild next definition 495 4. Security Considerations 496 4a 20-March-2002 Corrections and clarifications. 497 Dropped reference to RFC2119. 498 Moved Intellectual Property after section 1. 499 Fixed Security considerations. 500 4b 25-March-2002 Reword first paragraph of section 2.1 501 Arrange 5. References again. 502 06 25-July 2004 Corrections and clarifications. 503 07 20-July-2004 5. References 504 split to Informative and Normative 505 08 21-Jan-2005 Full review/rewrite to clean up language 506 and address IESG "Discuss". 508 Mimura, et. al. Expires January 2005 [Page9]