Network Working Group K. Mimura
Request for Comments: 4160 K. Yokoyama
Category: Informational T. Satoh
C. Kanaide
TOYO Communication Equipment
C. Allocchio
Consortium GARR
August 2005
Network Working Group K. Mimura
Request for Comments: 4160 K. Yokoyama
Category: Informational T. Satoh
C. Kanaide
TOYO Communication Equipment
C. Allocchio
Consortium GARR
August 2005
Internet Fax Gateway Requirements
因特网传真网关要求
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
To allow connectivity between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax) an "Internet Fax Gateway" is required. This document provides recommendations for the functionality of Internet Fax Gateways. In this context, an "offramp gateway" provides facsimile data transmission from i-fax to GSTN fax; vice versa, an "onramp gateway" provides data transmission form GSTN fax to i-fax. The recommendations in this document apply to the integrated service including Internet Fax terminals, computers with i-fax software on the Internet, and GSTN Fax terminals on the GSTN.
为了实现通用交换电话网络传真服务（GSTN传真）和基于电子邮件的互联网传真服务（i-fax）之间的连接，需要一个“互联网传真网关”。本文档提供了有关Internet传真网关功能的建议。在这种情况下，“出口网关”提供从i-fax到GSTN fax的传真数据传输；反之亦然，“入口网关”提供从GSTN传真到i-fax的数据传输。本文件中的建议适用于综合服务，包括互联网传真终端、互联网上带有i-Fax软件的计算机以及GSTN上的GSTN传真终端。
An Internet Fax Gateway provides connectivity and translation between the General Switched Telephone Network facsimile service (GSTN fax) and the e-mail-based Internet Fax service (i-fax). This document defines the recommended behavior of an Internet Fax Gateway. An Internet Fax Gateway can be classified as "onramp", when a facsimile is transferred from GSTN fax to the Internet Fax, and as "offramp", when a facsimile is transferred from Internet Fax to GSTN fax. For a more detailed definition of "onramp" and "offramp" within i-fax service, see [1].
Internet传真网关提供通用交换电话网络传真服务（GSTN传真）和基于电子邮件的Internet传真服务（i-Fax）之间的连接和转换。本文档定义了建议的Internet传真网关行为。当传真从GSTN传真传输到Internet传真时，Internet传真网关可分为“入口”，当传真从Internet传真传输到GSTN传真时，可分为“出口”。有关i-fax服务中“入站”和“出站”的更详细定义，请参见[1]。
This document provides recommendations only for the specific case hereunder:
本文件仅针对以下具体情况提供建议：
1) the operational mode of the Internet Fax is "store and forward", as defined in Section 2.5 of [1].
1) 互联网传真的操作模式为[1]第2.5节中定义的“存储转发”。
2) The format of image data is the data format defined by "simple mode" in [4].
2) 图像数据的格式为[4]中“简单模式”定义的数据格式。
This document does not apply to the gateway functions for "real-time Internet Fax", as described and defined in [3]. Additional recommendations for optional functionality are described in [24].
本文件不适用于[3]中描述和定义的“实时互联网传真”网关功能。[24]中描述了可选功能的其他建议。
The key words "MUST", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in [5].
本文件中的关键词“必须”、“应该”、“不应该”和“可能”应按照[5]中所述进行解释。
An onramp gateway receives a facsimile from a GSTN fax device (which may include an offramp gateway itself), and generates an Internet Fax over the Internet, which is sent to any Internet Fax device.
入口网关从GSTN传真设备（可能包括出口网关本身）接收传真，并通过互联网生成互联网传真，该传真被发送到任何互联网传真设备。
An offramp gateway receives an Internet Fax over the Internet from any Internet Fax-capable device (which may include an onramp gateway or a PC), and generates a GSTN fax, which is sent to any GSTN fax device.
出口网关通过互联网从任何具有互联网传真功能的设备（可能包括入口网关或PC）接收互联网传真，并生成GSTN传真，该传真发送到任何GSTN传真设备。
In both of these cases, the Internet side of the gateway acts as an Internet Fax device, as described in [4], while the GSTN side of the gateway acts as a GSTN fax device, as described in [6].
在这两种情况下，网关的互联网侧充当互联网传真设备，如[4]所述，而网关的GSTN侧充当GSTN传真设备，如[6]所述。
In this document we will only thus recommend the actions that occur while
在本文件中，我们仅建议在
1) the onramp gateway converts a fax received from GSTN and forwards it to the Internet Fax service;
1) 入口网关转换从GSTN接收的传真，并将其转发至互联网传真服务；
2) the offramp gateway converts a fax received from the Internet and forwards it to the GSTN fax service.
2) 出口网关转换从互联网接收的传真，并将其转发至GSTN传真服务。
An offramp gateway MUST, as a minimal requirement, perform the following functions:
作为最低要求，出口网关必须执行以下功能：
- address translation/mapping, - image format conversion, and - error/return notification handling
- 地址转换/映射、-图像格式转换和-错误/返回通知处理
and MAY also perform
也可以表演
- user authorization.
- 用户授权。
An offramp gateway MAY have a user authorization function to confirm that a user is allowed to transmit its Internet Fax to the GSTN fax service.
出口网关可具有用户授权功能，以确认允许用户将其互联网传真发送至GSTN传真服务。
Because an Internet Fax is sent as a MIME e-mail message to the offramp gateway, digital signatures can be used to authenticate and authorize the user. S/MIME is one example of a protocol that includes digital signature services. S/MIME is described in [9][10][11][12][13]. Other methods of adding a digital signature to a mail message (such as OpenPGP [17] [25]) MAY also be used to authenticate and authorize the user.
由于Internet传真作为MIME电子邮件发送到出口网关，因此可以使用数字签名对用户进行身份验证和授权。S/MIME是包含数字签名服务的协议的一个示例。[9][10][11][12][13]中描述了S/MIME。向邮件消息添加数字签名的其他方法（例如OpenPGP[17][25]）也可用于认证和授权用户。
The agent sending the Internet Fax (which may include an onramp gateway) sends the digitally-signed S/MIME or OpenPGP Fax message to the offramp gateway. The offramp gateway then compares the credentials of the user to determine if he/she is authorized to send faxes to the GSTN fax service. If the authorization process fails, then the offramp gateway MUST generate an error delivery notification for the sender of the Internet Fax.
发送Internet传真（可能包括入口网关）的代理将数字签名的S/MIME或OpenPGP传真消息发送到入口网关。出口网关然后比较用户的凭据，以确定他/她是否有权向GSTN传真服务发送传真。如果授权过程失败，则出口网关必须为Internet传真的发送者生成错误传递通知。
An Internet Fax may contain multiple e-mail addresses, both as originators, and as recipients. For its forwarding function to GSTN fax service, an offramp gateway MUST only consider those addresses which are explicitly itself, i.e., those where the right-hand side of the e-mail address corresponds to the offramp gateway.
Internet传真可以包含多个电子邮件地址，既可以是原始发件人，也可以是收件人。对于转发到GSTN传真服务的功能，OFFAMP网关必须只考虑那些显式自身的地址，即电子邮件地址的右侧对应于OFFAMP网关的那些地址。
Because addresses on the Internet Fax service are e-mail addresses, in order to reach a destination in the GSTN fax service, the offramp gateway MUST convert e-mail addresses into GSTN addresses.
由于Internet传真服务上的地址是电子邮件地址，为了到达GSTN传真服务中的目的地，出口网关必须将电子邮件地址转换为GSTN地址。
The GSTN destination address SHOULD normally be encoded inside the left-hand side of the e-mail address, according to [7]. However, an offramp gateway MAY use locally implemented translation rules to map left-hand side strings into GSTN addresses.
根据[7]，GSTN目标地址通常应编码在电子邮件地址的左侧。然而，出口网关可以使用本地实现的转换规则将左侧字符串映射到GSTN地址。
In any case, the offramp gateway MUST process the resultant GSTN address and convert it to a "local-phone", in accordance with local dialing rules.
在任何情况下，出口网关必须根据本地拨号规则处理生成的GSTN地址并将其转换为“本地电话”。
"Global-phone" is defined in Section 2 of [7]. "Local-phone" is defined in Section 2 of [8]. "Exit-code" is defined in Section 2.1 of [8].
“全球电话”的定义见[7]第2节。“本地电话”的定义见[8]第2节。“退出代码”的定义见[8]第2.1节。
The offramp gateway SHOULD also have a function to apply translation to originator addresses and other addresses referred to into the Internet Fax, in order to ensure a possible return path from GSTN fax service to Internet Fax destinations, including other offramp gateways. These functions MUST be compliant with the address handling of onramp gateways that is described in Section 4.2 of this document.
出口网关还应具有将翻译应用于发起者地址和互联网传真中提及的其他地址的功能，以确保从GSTN传真服务到互联网传真目的地（包括其他出口网关）的可能返回路径。这些功能必须符合本文件第4.2节中描述的入口网关地址处理。
3.2.1. Examples of Local Dialing Rules Applied to GSTN Destination Addresses
3.2.1. 应用于GSTN目标地址的本地拨号规则示例
The first example shows how an offramp gateway converts a "global-phone" to a "local-phone" by removing the "+" and "44" (recognizing the international country code is local), and then knowing it can dial directly without an exit-code:
第一个示例显示了出站网关如何通过删除“+”和“44”（识别国际国家代码是本地的）将“全球电话”转换为“本地电话”，然后知道无需出口代码即可直接拨号：
global-phone: +441164960348
全球电话：+441164960348
resulting in:
导致：
local-phone: 1164960348
本地电话：1164960348
The next example shows how an offramp gateway converts a "global-phone" to a "local-phone" by removing the "+" and "44" (recognizing the international country code is local), and then adding the exit-code "0" in front of the string:
下一个示例显示了出口网关如何通过删除“+”和“44”（识别国际国家代码为本地），然后在字符串前面添加出口代码“0”，将“全球电话”转换为“本地电话”：
global-phone: +441164960348
全球电话：+441164960348
resulting in:
导致：
local-phone: 01164960348
本地电话：01164960348
The next example shows how an offramp gateway converts a "global-phone" to "local-phone" by removing the "+" and "44" (recognizing the international country code is local), and then adding the long distance "0" in front of the string:
下一个示例显示了出口网关如何通过删除“+”和“44”（识别国际国家代码为本地），然后在字符串前面添加长距离“0”，将“全球电话”转换为“本地电话”：
global-phone: +441164960348
全球电话：+441164960348
resulting in:
导致：
local-phone: 01164960348
本地电话：01164960348
The last example shows how an offramp gateway converts a "global-phone" to a "local-phone" by removing the "+", recognizing the international country code is non-local, and adding the local international dialing prefix "00" in front of the string:
最后一个示例显示了出口网关如何通过删除“+”，识别国际国家代码为非本地代码，并在字符串前面添加本地国际拨号前缀“00”，将“全球电话”转换为“本地电话”：
global-phone: +441164960348
全球电话：+441164960348
resulting in:
导致：
local-phone: 00441164960348
本地电话：00441164960348
An offramp gateway SHOULD support the subaddress. If a subaddress is encoded into the left-hand side of the e-mail address [7], then it MUST be used by the offramp gateway, as specified in T.33 [15], to reach the final GSTN fax recipient.
出站网关应支持子地址。如果子地址编码到电子邮件地址[7]的左侧，则出口网关必须使用该子地址，如T.33[15]中所述，以到达最终的GSTN传真收件人。
An offramp gateway MUST convert the file format from TIFF Profile-S for Internet Fax (defined in [16]) into the GSTN fax image format. Other Internet Fax file formats are not considered in this document.
出站网关必须将互联网传真的TIFF Profile-S文件格式（定义见[16]）转换为GSTN传真图像格式。本文件不考虑其他互联网传真文件格式。
An offramp gateway SHOULD have a function that allows it to send a return notice to the originator Internet Fax device (defined in [4]) when a transmission error occurs over the GSTN fax service and the facsimile is not delivered to the destination. The return notice MUST be in Message Delivery Notification (MDN) format and delivered by the offramp gateway over the Internet e-mail transport service used by Internet Fax. The MDN disposition-type MUST be set as "processed", and the disposition-modifier MUST be set as an "error".
当GSTN传真服务发生传输错误且传真未送达目的地时，出站网关应具有允许其向发端人互联网传真设备（定义见[4]）发送返回通知的功能。退货通知必须采用邮件发送通知（MDN）格式，并由出口网关通过互联网传真使用的互联网电子邮件传输服务发送。MDN处置类型必须设置为“已处理”，处置修饰符必须设置为“错误”。
If the offramp gateway fails to transmit the MDN, the error information MAY be recorded to a log, and processing MAY end, or the administrator of the gateway system MAY be notified of these errors through a specific method (for example, by an e-mail message).
如果出口网关未能传输MDN，则可能会将错误信息记录到日志中，并且处理可能会结束，或者可能会通过特定方法（例如，通过电子邮件消息）将这些错误通知网关系统的管理员。
The more complex case of Delivery Status Notification (DSN) requests handling is not considered in this document.
本文档不考虑更复杂的传递状态通知（DSN）请求处理情况。
An onramp gateway MUST, as minimal requirement, perform the following functions:
作为最低要求，入口网关必须执行以下功能：
- address translation/mapping, - image format conversion, and - error/return notification handling,
- 地址转换/映射、-图像格式转换和-错误/返回通知处理，
and MAY also perform
也可以表演
- user authorization.
- 用户授权。
An onramp gateway MAY have a user authorization function to confirm that the user is authorized to transmit a facsimile to the Internet fax service. For example, user authorization may be accomplished by getting a user-ID and password received by Dual Tone Multi-Frequency (DTMF), or via a local authorization table based on the GSTN caller-ID.
入口网关可以具有用户授权功能，以确认用户被授权向因特网传真服务发送传真。例如，用户授权可以通过获取由双音多频（DTMF）接收的用户ID和密码，或者通过基于GSTN呼叫者ID的本地授权表来实现。
If the authorization process fails, then the onramp gateway MUST generate an error message/code for the sender of the GSTN Fax.
如果授权过程失败，则入口网关必须为GSTN传真的发送者生成错误消息/代码。
Addresses on Internet Fax service are e-mail addresses, thus a recipient of an Internet Fax might be either an e-mail user, an Internet Fax device with its own recipients/users, or an offramp gateway. The onramp gateway SHOULD have a functionality in order to receive from GSTN (via DTMF) destination addresses. However, there are two categories of destination addresses:
Internet传真服务上的地址是电子邮件地址，因此Internet传真的收件人可能是电子邮件用户、具有自己的收件人/用户的Internet传真设备或出口网关。入口匝道网关应具有从GSTN（通过DTMF）接收目标地址的功能。但是，有两类目标地址：
- e-mail users and Internet Fax recipient/users - real GSTN addresses reached via an offramp gateway
- 电子邮件用户和Internet传真收件人/用户-通过出口网关到达的真实GSTN地址
We define "indirect address mapping" as the functionality for the first category, and "direct address mapping" as the functionality for the second category.
我们将“间接地址映射”定义为第一类的功能，将“直接地址映射”定义为第二类的功能。
The onramp gateway MAY implement local address mapping mechanisms (via a table, directory lookup, or something similar) that permit translation from addresses (called "indirect address numbers") received from the GSTN fax sending device into e-mail addresses. A single e-mail address or a list of e-mail addresses MAY correspond to a single indirect address number.
入口网关可实现本地地址映射机制（通过表、目录查找或类似方式），允许将从GSTN传真发送设备接收的地址（称为“间接地址号”）转换为电子邮件地址。单个电子邮件地址或电子邮件地址列表可能对应于单个间接地址号。
Here is one mapping example:
以下是一个映射示例：
(1) An onramp gateway receives the indirect address number "1234" from the source GSTN facsimile by DTMF.
(1) 入口网关通过DTMF从源GSTN传真接收间接地址号码“1234”。
1234
1234
(2) The destination address is looked up in the address mapping table.
(2) 在地址映射表中查找目标地址。
address mapping table 1234 : ifax@example.com
地址映射表1234：ifax@example.com
(3) An Internet Fax is sent to the address ("addr-spec")
(3) 互联网传真发送至地址（“地址规范”）
ifax@example.com
ifax@example.com
"Addr-spec" is defined in Section 3.4.1 of [14].
[14]第3.4.1节定义了“Addr规范”。
If the address mapping lookup fails, an error MUST be reported to the originating GSTN fax device.
如果地址映射查找失败，则必须向发起GSTN传真设备报告错误。
If the indirect address mapping specified in 4.2.1 is not implemented, then only "direct address mapping" can be used. The GSTN sending device SHOULD send the full numeric destination address to the onramp gateway via DTMF. Direct address mapping can also be used if indirect address mapping is implemented.
如果未实现4.2.1中规定的间接地址映射，则只能使用“直接地址映射”。GSTN发送设备应通过DTMF向入口匝道网关发送完整的数字目的地地址。如果实现了间接地址映射，也可以使用直接地址映射。
An example:
例如：
(1) An onramp gateway receives the destination telephone number "441164960348" from the source facsimile by DTMF.
(1) 入口网关通过DTMF从源传真接收目标电话号码“441164960348”。
441164960348
441164960348
(2) The destination number is encoded as a "global-phone", so "+" is added to the head of the string.
(2) 目的地号码被编码为“全局电话”，因此“+”被添加到字符串的开头。
+441164960348
+441164960348
(3) "FAX=" is added in order to build the "fax-mbox" address item
(3) 添加“FAX=”是为了构建“FAX mbox”地址项
FAX=+441164960348
传真：+441164960348
(4) The destination address is completed, adding the specification of the appropriate offramp gateway, which is supposed to handle the delivery of the fax message to a global-phone address.
(4) 目标地址已完成，添加了相应的出口网关规范，该网关负责处理传真消息到全局电话地址的传递。
FAX=+441164960348@example.com
FAX=+441164960348@example.com
The procedure for choosing the domain name of an offramp gateway is defined in Section 4.3 ("Relay Function").
第4.3节（“中继功能”）规定了选择出口网关域名的程序。
"Global-phone", "fax-mbox", and "fax-address" are defined in Section 2 of [7]. "Mta-I-fax" is defined in Section 3 of [7]. "Fax-email" is defined in Section 4 of [7].
“全球电话”、“传真mbox”和“传真地址”的定义见[7]第2节。“Mta-I-fax”的定义见[7]第3节。“传真电子邮件”的定义见[7]第4节。
The onramp gateway SHOULD gather information about the GSTN fax sender address (for example, via Caller-ID, if available) and encode it as the sender of the Internet Fax, using the direct address mapping (see Section 4.2.2 of this document). The sender address SHOULD be completed using the onramp gateway address, unless the onramp gateway has additional information with which to specify a different return path.
入口网关应收集有关GSTN传真发送方地址的信息（例如，通过呼叫者ID，如果可用），并使用直接地址映射将其编码为互联网传真的发送方（见本文件第4.2.2节）。发送方地址应使用入站网关地址填写，除非入站网关具有用于指定不同返回路径的附加信息。
If the onramp gateway does not have any sender address information, the Internet Fax sender address SHOULD be set to either a "no-reply" address or an appropriate default mailbox.
如果入口网关没有任何发件人地址信息，则应将Internet传真发件人地址设置为“无回复”地址或相应的默认邮箱。
An onramp gateway SHOULD support the subaddress. In the case of direct address mapping, the subaddress is specified using the T.33 [15] specification, and encoded as given in [7]. In the case of indirect address mapping, the subaddress MAY be contained inside the address mapping table.
入口网关应支持子地址。在直接地址映射的情况下，使用T.33[15]规范指定子地址，并按照[7]中给出的方式进行编码。在间接地址映射的情况下，子地址可能包含在地址映射表中。
The onramp gateway SHOULD provide functionality for choosing the destination offramp gateway by analyzing a destination fax number. A possible method to expand or acquire information from the onramp gateway about offramp gateways MAY include keeping cached information about sender addresses that was sent by other onramp gateways.
入口匝道网关应提供通过分析目标传真号码选择目标出口匝道网关的功能。从入口网关扩展或获取关于出口网关的信息的可能方法可以包括保留关于由其他入口网关发送的发送者地址的缓存信息。
An onramp gateway MUST convert the file format from a facsimile over the GSTN to the file format TIFF Profile-S for Internet Fax, as defined in [16].
入口网关必须将GSTN上的传真文件格式转换为互联网传真的文件格式TIFF Profile-S，如[16]中所定义。
When an onramp gateway receives and analyzes a return notice from the Internet Fax destination, it MAY have the functionality to send the delivery status to a suitable facsimile device on the GSTN through an appropriate offramp gateway. The generated notice sent via GSTN fax SHOULD contain both the human-readable notice information, and the original delivery codes.
当入口网关接收并分析来自互联网传真目的地的返回通知时，其可能具有通过适当的出口网关将递送状态发送到GSTN上的适当传真设备的功能。通过GSTN传真发送的生成通知应包含人类可读的通知信息和原始交付代码。
If the onramp gateway fails in the transmission of the return notice back to GSTN fax service, the information MAY be recorded into a log, and processing MAY end. As an alternate, the administrator of the gateway system MAY be notified of this notice with a specific method (for example, by sending an e-mail message to a mailbox).
如果入口匝道网关未能将返回通知传输回GSTN传真服务，则信息可能会记录到日志中，并且处理可能会结束。作为替代方案，网关系统的管理员可以通过特定方法（例如，通过向邮箱发送电子邮件消息）被通知该通知。
Refer to Section 3.1 ("User Authorization") for authentication for an offramp gateway. OpenPGP [17] [25] can be used to provide authorization services instead of S/MIME. Refer to Section 4.1 ("User Authorization") for authentication for an onramp gateway.
关于出口网关的认证，请参考第3.1节（“用户授权”）。OpenPGP[17][25]可以用来提供授权服务，而不是S/MIME。请参阅第4.1节（“用户授权”），了解入口网关的身份验证。
S/MIME and OpenPGP can also be used to encrypt a message. A signed or encrypted message is protected while transported along the network; however, when a message reaches an Internet Fax Gateway, either onramp or offramp, this kind of protection cannot be applied anymore. Here, security must rely on trusted operations of the gateway itself. A gateway might have its own certificate/key to improve security operations when sending Internet Faxes, but, as with any gateway, it breaks the end-to-end security pattern of both S/MIME and PGP.
S/MIME和OpenPGP也可用于加密消息。签名或加密的消息在网络上传输时受到保护；但是，当消息到达Internet传真网关时，无论是入站还是出站，都无法再应用这种保护。在这里，安全性必须依赖于网关本身的可信操作。网关可能有自己的证书/密钥来改进发送Internet传真时的安全操作，但与任何网关一样，它打破了S/MIME和PGP的端到端安全模式。
Other security mechanisms, like IPsec [18][19][20][21][2] or TLS [23] also do not ensure a secure gateway operation.
其他安全机制，如IPsec[18][19][20][21][2]或TLS[23]也不能确保安全的网关操作。
Denial-of-service attacks are beyond the scope of this document. Host compromise caused by flaws in the implementation is beyond the scope of this document.
拒绝服务攻击超出了本文档的范围。由实现中的缺陷导致的主机泄露超出了本文档的范围。
[1] Masinter, L., "Terminology and Goals for Internet Fax", RFC 2542, March 1999.
[1] Masinter，L.，“因特网传真的术语和目标”，RFC 25421999年3月。
[2] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security Document Roadmap", RFC 2411, November 1998.
[2] R.Thayer、N.Doraswamy和R.Glenn，“IP安全文档路线图”，RFC 24111998年11月。
[3] "Procedures for real-time Group 3 facsimile communication over IP networks", ITU-T Recommendation T.38, June 1998.
[3] “通过IP网络进行实时第3组传真通信的程序”，ITU-T建议T.38，1998年6月。
[4] Toyoda, K., Ohno, H., Murai, J., and D. Wing, "A Simple Mode of Facsimile Using Internet Mail", RFC 3965, December 2004.
[4] 丰田章男，K.，大野，H.，村井，J.，和D.Wing，“使用互联网邮件的简单传真模式”，RFC 3965，2004年12月。
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[6] "Procedures for document facsimile transmission in the general switched telephone network", ITU-T Recommendation T.30, April 1999.
[6] “通用交换电话网中文件传真传输的程序”，ITU-T建议T.30，1999年4月。
[7] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001.
[7] Allocchio，C.，“因特网邮件中的最小传真地址格式”，RFC3192，2001年10月。
[8] Allocchio, C., "GSTN Address Element Extensions in E-mail Services", RFC 2846, June 2000.
[8] Allocchio，C.，“电子邮件服务中的GSTN地址元素扩展”，RFC 28462000年6月。
[9] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3852, July 2004.
[9] Housley，R.，“加密消息语法（CMS）”，RFC3852，2004年7月。
[10] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, June 1999.
[10] Rescorla，E.，“Diffie-Hellman密钥协商方法”，RFC 26311999年6月。
[11] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
[11] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1证书处理”，RFC 38502004年7月。
[12] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[12] Ramsdell，B.，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 3851，2004年7月。
[13] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[13] Hoffman，P.，“S/MIME的增强安全服务”，RFC 2634，1999年6月。
[14] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[14] Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[15] "Facsimile routing utilizing the subaddress", ITU recommendation T.33, July 1996.
[15] “利用子地址的传真路由”，国际电联建议T.33，1996年7月。
[16] Buckley, R., Venable, D., McIntyre, L., Parsons, G., and J. Rafferty, "File Format for Internet Fax", RFC 3949, February 2005.
[16] Buckley，R.，Venable，D.，McIntyre，L.，Parsons，G.，和J.Rafferty，“互联网传真的文件格式”，RFC 3949，2005年2月。
[17] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998.
[17] Callas，J.，Donnerhacke，L.，Finney，H.，和R.Thayer，“OpenPGP消息格式”，RFC2440，1998年11月。
[18] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[18] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
[19] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998.
[19] Kent，S.和R.Atkinson，“IP认证头”，RFC 2402，1998年11月。
[20] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[20] Ramakrishnan，K.，Floyd，S.，和D.Black，“向IP添加显式拥塞通知（ECN）”，RFC 3168，2001年9月。
[21] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
[21] Piper，D.，“ISAKMP解释的互联网IP安全域”，RFC 2407，1998年11月。
[23] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 3546, June 2003.
[23] Blake Wilson，S.，Nystrom，M.，Hopwood，D.，Mikkelsen，J.，和T.Wright，“传输层安全（TLS）扩展”，RFC 35462003年6月。
[24] Mimura, K., Yokoyama, K., Satoh, T., Watanabe, K., and C. Kanaide, "Guidelines for Optional Services for Internet Fax Gateways", RFC 4161, August 2005.
[24] Mimura，K.，Yokoyama，K.，Satoh，T.，Watanabe，K.，和C.Kanaide，“互联网传真网关可选服务指南”，RFC 41612005年8月。
[25] Elkins, M., Del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", RFC 3156, August 2001.
[25] Elkins，M.，Del Torto，D.，Levien，R.，和T.Roessler，“OpenPGP的MIME安全性”，RFC 3156，2001年8月。
Authors' Addresses
作者地址
Katsuhiko Mimura TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan
三村胜彦东洋通信设备有限公司，日本神奈川县三川町市高山町2-1-1号
Fax: +81 467 74 5743
EMail: mimu@miyabi-labo.net
Fax: +81 467 74 5743
EMail: mimu@miyabi-labo.net
Keiichi Yokoyama TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan
日本神奈川县小川町市小山町2-1-1号惠一横山东洋通信设备有限公司
Fax: +81 467 74 5743
EMail: keiyoko@msn.com
Fax: +81 467 74 5743
EMail: keiyoko@msn.com
Takahisa Satoh TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan
高久佐藤东洋通信设备有限公司2-1-1，日本神奈川县三川町市高山町
Fax: +81 467 74 5743
EMail: zsatou@t-ns.co.jp
Fax: +81 467 74 5743
EMail: zsatou@t-ns.co.jp
Chie Kanaide TOYO Communication Equipment CO., LTD. 2-1-1 Koyato, Samukawa-machi, Koza-gun Kanagawa, Japan
Chie Kanaide TOYO通信设备有限公司2-1-1 Koyato，日本神奈川县三川町
Fax: +81 467 74 5743
EMail: icemilk77@yahoo.co.jp
Fax: +81 467 74 5743
EMail: icemilk77@yahoo.co.jp
Claudio Allocchio Consortium GARR Viale Palmiro Togliatti 1625 00155 Roma, Italy
Claudio Allocchio Consortium GARR Viale Palmiro Togliatti 1625 00155意大利罗马
Fax: +39 040 3758565
EMail: Claudio.Allocchio@garr.it
Fax: +39 040 3758565
EMail: Claudio.Allocchio@garr.it
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。