Document: draft-ietf-fax-gateway-options-07.txt Reviewer: Spencer Dawkins Date: 17 augusti 2004 The following is my Gen-ART review of draft-ietf-fax-gateway-options-07.txt, with this focus: 3.1 WG Submissions Reviews should focus on these questions: "Is this document a reasonable contribution to the area of Internet engineering which it covers? If not, what changes would make it so?" My comments: Yes, a document on this topic could be a reasonable contribution, but additional editing is needed. Although Gen-ART reviews don't have to contain detailed comments, I'm providing them in this case. "Status Of This Memo" is RFC 2026-era (needs to refer to the current boilerplate for 3668/IPR) Abstract An Internet FAX Gateway provides functions which translate a facsimile?@between the general switched telephone network (GSTN) and There's a typo here ("?@") the Internet. This document provides guidelines of optional services and examples of an Internet FAX Gateway, with respect to the onramp gateway and offramp gateway. This document does not intend to specify the actions to which the IFax offramp and onramp gateways (defined in [3]) conform. I don't understand this sentence This document covers drop duplication, automatic re-transmission, Is this "dropping duplicate transmissions"? error behavior, when sending return notice, and the keep log for an Is this "when to send a return notice"? offramp gateway. Also covered are examples of authorization by DTMF (Dual Tone Multi-Frequency) and the keep log for an onramp gateway. 1. Introduction An Internet FAX Gateway can be classified as an offramp gateway and onramp gateway. This document provides information on the guidelines of optional services and examples of an Internet FAX Gateway. This document covers drop duplication, automatic re-transmission, error This paragraph is duplicated in the Abstract - my suggestions there apply here, too. behavior, when sending return notice, and the keep log for an offramp gateway. Also included are examples of authorization by DTMF and the keep log for an onramp gateway. A more detailed definition of onramps and offramps is provided in [1]. 2. Optional Services for an Offramp Gateway 2.1 Drop duplications Sometimes overlapped mail is received by an offramp gateway. In such I'm not getting "duplications" from "overlapped mail". cases the offramp gateway is required to drop the overlapped mail. The purpose of this is to prevent the offramp gateway from transmitting the overlapped facsimile data to a facsimile device over the GSTN. 2.2 Automatic re-transmission in the occurrence of a delivery error An offramp gateway MAY add a function that automatically tries to This document uses a fair amount of RFC 2119 language. It's targeted as Informational, so I'd downshift the "MAY"s to "may"s, and so forth. send facsimile data again if delivery failure occurs. If this function is added, the retry times and retry interval MAY be Is this "the number of retries"? specified as options by the administrator of the offramp gateway. If this function is set, a return notice SHOULD be sent only when the specified number of retries has been completed and the last facsimile transmission is an error. When transmission is suspended by the error, transmission is again started to send an error page on the Is this "the next transmission begins with the page where the previous error was encountered"? next transmission. For example, assume that an offramp gateway is sending a total of Five pages of facsimile data. But, an error occurs after two pages of normal transmission and the transmission is stopped. The offramp gateway should re-transmit the facsimile data, beginning with page 3. 2.3 Error behavior Retransmission behavior depends on the kinds of errors. In Calling Errors, such as a busy signal, line errors, and so on, the offramp gateway can perform retransmission. In Connecting Errors, such as a paper error, stop event error - but not a FAX error (voice response) - the offramp gateway sends a return notice to the sender without any retransmission. Thus, Calling Errors can probably be recovered, but Connecting errors Is this "can usually be recovered"? can rarely be recovered. 2.4 When sending return notice When an offramp gateway receives broadcast mail, there are two ways to send a return notice. 1) An offramp gateway sends a return notice as soon as an error occurs. 2) An offramp gateway sends a return notice after every completion of the specified number of transmissions. These features should be options selected by the user. Is there a standard, or even "usual", way to select these options? It should be referenced here. 2.5 When a transmitting error occurs in a return notice When an offramp gateway fails in the transmission of a return notice, the Internet FAX Gateway SHOULD process the notice in either of the following ways. 1) When the gateway has a log information preservation function, the error information SHOULD be recorded to a log, and processing SHOULD end. At this time, the administrator of the gateway system SHOULD be notified of these errors using a specific process (for example, SMTP). 2) If the gateway does not have a log information preservation function, the administrator SHOULD be told about the failure, and Cases 1 and 3 mention SMTP as an example, but case 2 doesn't. Why this omission? processing SHOULD end. 3) If the gateway has a high hardware capability and sufficient time margin, it is a beneficial service to perform the following processing. When notice of a result fails in transmission, the fixed time interval is vacated, and the output of the notice is repeated for a specified number of times. Even if the specified number of times continues to fail, the error information is "number of retries still result in failure"? recorded to a log, and processing is finished. Also, at this time, the administrator of the gateway system SHOULD be notified of these errors by a specific process (for example, SMTP). 2.6 Keep log An offramp gateway MAY have a function which keeps the information listed below as a log. For security and message traces, the Internet FAX Gateway MAY use the following format for a system log or event log of the Operation System. - Date and time when transmit request is received - Source address - Destination address - Date and time when transmitted over the GSTN Is this "over the GSTN began"? - Date and time when transmission over the GSTN was finished - Number of real transmitted pages What does "real" mean in this list element? - Byte count of transmitted data - Type of data (resolution) - Occurrence of errors - Number of retries automatically sent Is this "automatically attempted"? - Date and time of transmission of delivery notice The goal of the log information preservation function is mainly to improve security or charge calculation processing. When the hardware system is equipped with recording media (HDD, FDD, These abbreviations should be expanded. etc.), the log information SHOULD be saved as a log file. The following are three opportunities to save log information. 1) When an offramp gateway receives a distribution demand. 2) When an offramp gateway starts distribution. 3) When an offramp gateway ends distribution. When the hardware system does not use a recording medium, log information cannot be saved locally. In this case, it is desirable to use the save function at other PCs using existing network communication means, such as a function to save log information as a file using Network File System, SMTP, SNMP, or the function to periodically print log information. To strengthen security, it is desirable to save log information in the Internet FAX Gateway using a database system. I don't understand this ("strengthen security" compared to what?). 3. Optional Services for an Onramp Gateway 3.1 Example of user authorization An onramp gateway MAY have a user authorization function to confirm that the user is authorized to transmit data. In the case of onramp action, there are many methods to send authentication information. The method chosen depends on the provider's services. Consequently, an example is not described. 3.2 Keep log Is "Keep" a noun, verb, or adjective? the phrase is confusing to native English speakers. Isn't this section a duplicate of 2.6? If not, my comments on the elements in the following list from 2.6 apply here as well. An onramp gateway MAY have a function that keeps information as a log. For security and message traces, the Internet FAX gateway MAY use the following format of a system log or event log of the Operation System. - Date and time when transmission request was received - Source address - Destination address - Date and time of transmission over the GSTN - Date and time when transmission over the GSTN was finished - Date and time of transmission over the Internet - Number of real transmitted pages - Byte count of transmitted data - Type of data (resolution) - Occurrence of errors - Number of retries sent automatically - Date and time of transmission of delivery notice The purpose of the log information preservation function is mainly to improve security or charge calculation processing. When the hardware system is equipped with recording media (HDD, FDD, etc.), the log information SHOULD be saved as a log file. The following are three possible opportunities to save log information. 1) When an onramp gateway receives a distribution demand. 2) When an onramp gateway starts distribution. 3) When an onramp gateway ends distribution. When a hardware system without a recording medium is used, log information cannot be saved locally. In this case, it is desirable to use a function that saves at other PCs using existing network communication means, such as a function to save log information as a file using Network File System, SMTP, SNMP, or a function that periodically prints log information. In order to strengthen security, it is desirable to save log information in the Internet FAX Gateway using a database system. 4. Security Considerations An offramp and onramp gateway MAY have a user authorization function to confirm that they are authorized to transmit facsimile data. Encryption of facsimile data could be performed by the existing SMTP, using an available security technique. The security consideration sections of [3] apply to this document.